Bogon ASN Filter Policy
Michael Hare
michael.hare at wisc.edu
Wed Jun 8 12:56:18 UTC 2016
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-bounces at nanog.org] On Behalf Of Arnold Nipper
> Sent: Wednesday, June 08, 2016 12:37 AM
> To: Jay Borkenhagen <jayb at att.com>; nanog at 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.davenport at 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 <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
> >
>
>
> --
> Arnold Nipper / nIPper consulting, Sandhausen, Germany
> email: arnold at nipper.de phone: +49 6224 5593407 2
> mobile: +49 172 2650958 fax: +49 6224 5593407 9
More information about the NANOG
mailing list