Dear Job,

First of all - I admire that huge ASes are ready to become pioneers and adopt new techniques to stop route propagation of bogon routes. Leading by example - is a perfect way to start curing current ecosystem of BGP.

But I have security consideration that filtering isn't a proper mechanism to reach this goal. Imagine next situation - if transit accidently prepends its paths with private AS number it will result in DoS for all stub networks connected to this transit. I think, better way is deprioritize bogon routes - this will stop propagation of such routes if there is any alternative and will not affect reachability in other cases.

2016-06-02 22:43 GMT+03:00 Job Snijders <job@ntt.net>:
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




--
| Alexander Azimov  | HLL l QRATOR
| tel.: +7 499 241 81 92
| mob.: +7 915 360 08 86
| skype: mitradir
| mailto: aa@qrator.net
| visit: www.qrator.net