Bogon ASN Filter Policy

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