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 > -----Original Message----- > From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Arnold Nipper > Sent: Wednesday, June 08, 2016 12:37 AM > To: Jay Borkenhagen <j...@att.com>; nanog@nanog.org > Subject: Re: Bogon ASN Filter Policy > > On 03.06.2016 15:08, Jay Borkenhagen wrote: > > > 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 > > > > > On 02-June-2016, Adam Davenport writes: > > > 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.davenp...@gtt.net > > > > > > > > > > > > On 6/2/16 3:41 PM, Job Snijders wrote: > > > > 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 <j...@ntt.net>, Jared Mauch <jma...@us.ntt.net>, > > > > NTT Communications NOC <n...@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 > > > > > -- > Arnold Nipper / nIPper consulting, Sandhausen, Germany > email: arn...@nipper.de phone: +49 6224 5593407 2 > mobile: +49 172 2650958 fax: +49 6224 5593407 9