[routing-wg] Bogon ASN Filter Policy

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 at 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 at ntt.net>, Jared Mauch <jmauch at us.ntt.net>,
>     NTT Communications NOC <noc at 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 at qrator.net
| visit: www.qrator.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/routing-wg/attachments/20160614/27405aef/attachment.html>