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 <[email protected]>: > 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 <[email protected]>, Jared Mauch <[email protected]>, > NTT Communications NOC <[email protected]> > > 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: [email protected] | visit: www.qrator.net
