Bogon ASN Filter Policy

Mailman List Mirror (Read Only)
1

Dear fellow network operators,

In July 2016, NTT Communications' Global IP Network AS2914 will deploy a
new routing policy to block Bogon ASNs from its view of the default-free
zone. This notification is provided as a courtesy to the network
community at large.

After the Bogon ASN filter policy has been deployed, AS 2914 will not
accept route announcements from any eBGP neighbor which contains a Bogon
ASN anywhere in the AS_PATH or its atomic aggregate attribute.

The reasoning behind this policy is twofold:

    - Private or Reserved ASNs have no place in the public DFZ. Barring
      these from the DFZ helps improve accountability and dampen
      accidental exposure of internal routing artifacts.

    - All AS2914 devices support 4-byte ASNs. Any occurrence of "23456"
      in the DFZ is a either a misconfiguration or software issue.

We are undertaking this effort to improve the quality of routing data as
part of the global ecosystem. This should improve the security posture
and provide additional certainty [1] to those undertaking network
troubleshooting.

Bogon ASNs are currently defined as following:

    0 # Reserved RFC7607
    23456 # AS_TRANS RFC6793
    64496-64511 # Reserved for use in docs and code RFC5398
    64512-65534 # Reserved for Private Use RFC6996
    65535 # Reserved RFC7300
    65536-65551 # Reserved for use in docs and code RFC5398
    65552-131071 # Reserved
    4200000000-4294967294 # Reserved for Private Use RFC6996
    4294967295 # Reserved RFC7300

A current overview of what are considered Bogon ASNs is maintained at
NTT's Routing Policies page [2]. The IANA Autonomous System Number
Registry [3] is closely tracked and the NTT Bogon ASN definitions are
updated accordingly.

We encourage network operators to consider deploying similar policies.
Configuration examples for various platforms can be found here [4].

NTT staff is monitoring current occurrences of Bogon ASNs in the routing
system and reaching out to impacted parties on a weekly basis.

Kind regards,

Job

Contact persons:

    Job Snijders <job@ntt.net>, Jared Mauch <jmauch@us.ntt.net>,
    NTT Communications NOC <noc@ntt.net>

References:
[1]: https://tools.ietf.org/html/draft-thomson-postel-was-wrong-00
[2]: http://www.us.ntt.net/support/policy/routing.cfm#bogon
[3]: https://www.iana.org/assignments/as-numbers/as-numbers.xhtml
[4]: http://as2914.net/bogon_asns/configuration_examples.txt

2

I personally applaud this effort as initiatives like this that help prevent the global propagation of Bogons and other "bad things" only serves to help us all. With that said, notice went out to potentially affected GTT / AS3257 customers this week that by the end of June we too will be filtering prefixes that contain any of the Bogon ASNs listed below in the in the as-path. I highly encourage other networks to follow suit, as again it only helps us all.

Thanks Job for kicking this one off, and I look forward to others to doing the same!

Adam Davenport / adam.davenport@gtt.net

3

AT&T/as7018 is also now in the process of updating its as-path bogon
filters to match those cited below. We have long employed such
filters, and our changes at this time are primarily to extend them to
prohibit as23456 and the reserved blocks > as65535.

So to Job and Adam and anyone else who deploys such filters: Thanks!
I would like to extend to you this laurel, and hearty handshake...

4

AT&T/as7018 is also now in the process of updating its as-path bogon
filters to match those cited below. We have long employed such
filters, and our changes at this time are primarily to extend them to
prohibit as23456 and the reserved blocks > as65535.

So to Job and Adam and anyone else who deploys such filters: Thanks!
I would like to extend to you this laurel, and hearty handshake...

Well done, NTT, GTT, AT&T. You may want to notice that most of the IXP
around the world which operate route servers since long do strict
filtering. Both on ASN as well as on prefixes. So it's really nice to
see, that the big ISP take care as well now.

As I have learnt yesterday at ENOG11 a way more challenging issue is to
cope with route leaks.

Cheers and cu in chi
Arnold

5

I'm not against the theory of what is being proposed, but I was surprised to see little discussion of this announcement on list.

Upon examination on my view of the DFZ from AS3128 I see over 400 upstream routes falling into this category, mostly in the 64512 - 65534 range. Based on our flow bandwidth stats we chose to reach out to several origin ASN, two fairly well known, as a courtesy.

For the *TT's who are planning on implementing shortly, have you went through a similar diagnostic effort and what might you share or report on such endeavors?

-Michael

6

At the very least, "remove-private-as" should be a standard step in the
procedure of turning up any eBGP session.

Mark.

7

Dear Michael,

Upon examination on my view of the DFZ from AS3128 I see over 400
upstream routes falling into this category, mostly in the 64512 -
65534 range. Based on our flow bandwidth stats we chose to reach out
to several origin ASN, two fairly well known, as a courtesy.

For the *TT's who are planning on implementing shortly, have you went
through a similar diagnostic effort and what might you share or report
on such endeavors?

Below is a copy+paste from the weekly report which drives our outreach
effort. We recognise two types of prefixes: "Problem prefixes" and
"problems resolved by a less specific".

It seems likely that the "saved by overlapping less-specific" ones are
the result of accidental exposure of something that should remain
internal, and the "problem prefixes" are likely to be misconfigurations
or software issues.

Hopefully, by the time we actually deploy the new policy, all of these
have been resolved. When we started the outreach 3 weeks ago, the
"problem prefixes" count was at ~ 250 prefixes, and today its just 100.

8

Hi all,

a quick update from the DE-CIX side: we see in total 25 routes containing bogon ASNs at all the route servers at all DE-CIX IXPs (so far we just filtered the private ASN space). We directly contacted the customers sending the routes to inform them about the upcoming change in filtering.

Best regards,
Thomas