> 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
Hi Job, Good work on this, thanks. One thing to note though, If you ask RIPE to provide an ASN to use with anycast, they'll say use a private ASN to match what's recommended in the RFCs. This happened with me. But I insisted on getting them and RIPE did provide proper ASNs in the end. So for people who just went on using private ones, this will be a problem. Kareem. On 03/06/16 12:00, [email protected] wrote: > Send uknof mailing list submissions to > [email protected] > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.uknof.org.uk/cgi-bin/mailman/listinfo/uknof > or, via email, send a message with subject or body 'help' to > [email protected] > > You can reach the person managing the list at > [email protected] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of uknof digest..." > > > Today's Topics: > > 1. IANA AS Numbers registry update (Selina Harrington) > 2. Bogon ASN Filter Policy (Job Snijders) > 3. Re: Bogon ASN Filter Policy (James Bensley) > 4. Re: Bogon ASN Filter Policy (Job Snijders) > 5. Re: Bogon ASN Filter Policy (James Bensley) > 6. Re: Bogon ASN Filter Policy (Job Snijders) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 2 Jun 2016 18:20:06 +0000 > From: Selina Harrington <[email protected]> > To: Selina Harrington <[email protected]> > Subject: [uknof] IANA AS Numbers registry update > Message-ID: <[email protected]> > Content-Type: text/plain; charset="utf-8" > > Hi, > > The IANA AS Numbers registry was updated on 25 May 2016 to reflect the > allocation of the following blocks to APNIC: > > 64297-64395 > 135581-136505 > 136506-137529 > > You can find the IANA AS Numbers registry at: > > http://www.iana.org/assignments/as-numbers/as-numbers.xml > > The allocation was made in accordance with the Policy for Allocation of ASN > Blocks to Regional Internet Registries: > > https://www.icann.org/resources/pages/global-policy-asn-blocks-2010-09-21-en > > Regards, > > Selina Harrington > IANA Senior Specialist > ICANN > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > <https://lists.uknof.org.uk/cgi-bin/mailman/private/uknof/attachments/20160602/704c4707/attachment-0001.html> > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: smime.p7s > Type: application/pkcs7-signature > Size: 2039 bytes > Desc: not available > URL: > <https://lists.uknof.org.uk/cgi-bin/mailman/private/uknof/attachments/20160602/704c4707/attachment-0001.bin> > > ------------------------------ > > Message: 2 > Date: Thu, 2 Jun 2016 21:56:31 +0200 > From: Job Snijders <[email protected]> > To: [email protected] > Cc: Jared Mauch <[email protected]> > Subject: [uknof] Bogon ASN Filter Policy > Message-ID: <[email protected]> > Content-Type: text/plain; charset=us-ascii > > 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 > > > > ------------------------------ > > Message: 3 > Date: Fri, 3 Jun 2016 10:12:42 +0100 > From: James Bensley <[email protected]> > To: Job Snijders <[email protected]>, "[email protected]" > <[email protected]> > Subject: Re: [uknof] Bogon ASN Filter Policy > Message-ID: > <caawx_puerdgk7xysnnxug4thxmlszqzpdxhm00pzzi5ne9w...@mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > On 2 June 2016 at 20:56, Job Snijders <[email protected]> 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 > > > Hi Job, > > Good effort from NTT. I work for an access provider and we have rolled > out the same policy already. There are definately valid arguments > against this (I think) however I think the arguments for this approach > outweigh them. > > It's good to see the larger carriers doing this, at $dayjob we have > often see bogons IP prefixes coming from the larger carries (they > aren't filtering their customer announcements) and the same goes for > not dropping private ASNs in the path on prefixes receiveed from their > customer announcements. > > This is the config we have used on IOS boxes; > https://null.53bits.co.uk/index.php?page=asn-filtering > > I will fish out an IOS-XR config we have used too if anyone is > interested in doing the same. > > Has anyone got a Junos config snippet they can share to do the same? > If not I can splurge it out in the lab but I'm feeling Friday lazy. > > Cheers, > James. > > > > ------------------------------ > > Message: 4 > Date: Fri, 3 Jun 2016 11:26:38 +0200 > From: Job Snijders <[email protected]> > To: James Bensley <[email protected]> > Cc: "[email protected]" <[email protected]> > Subject: Re: [uknof] Bogon ASN Filter Policy > Message-ID: <[email protected]> > Content-Type: text/plain; charset=us-ascii > > On Fri, Jun 03, 2016 at 10:12:42AM +0100, James Bensley wrote: >> It's good to see the larger carriers doing this, > > GTT also committed > http://mailman.nanog.org/pipermail/nanog/2016-June/086081.html > >> This is the config we have used on IOS boxes; >> https://null.53bits.co.uk/index.php?page=asn-filtering > > Cool! > >> I will fish out an IOS-XR config we have used too if anyone is >> interested in doing the same. >> >> Has anyone got a Junos config snippet they can share to do the same? >> If not I can splurge it out in the lab but I'm feeling Friday lazy. > > Here are JunOS, IOS XR & BIRD examples: > > http://as2914.net/bogon_asns/configuration_examples.txt > > With your permission I'd like to add the IOS flavor > > Kind regards, > > Job > > > > ------------------------------ > > Message: 5 > Date: Fri, 3 Jun 2016 11:05:41 +0100 > From: James Bensley <[email protected]> > To: Job Snijders <[email protected]>, "[email protected]" > <[email protected]> > Subject: Re: [uknof] Bogon ASN Filter Policy > Message-ID: > <caawx_pxmpzgzckbdqi+fn+8qlwfuc3antqownhb77ntmdsg...@mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > On 3 June 2016 at 10:26, Job Snijders <[email protected]> wrote: >> On Fri, Jun 03, 2016 at 10:12:42AM +0100, James Bensley wrote: >>> It's good to see the larger carriers doing this, >> >> GTT also committed >> http://mailman.nanog.org/pipermail/nanog/2016-June/086081.html > > Even better! Just need to ensure everyone is applying prefix filters > too. Still seeing RFC1918 leakages from time to time. > >> Here are JunOS, IOS XR & BIRD examples: >> >> http://as2914.net/bogon_asns/configuration_examples.txt > > Many thanks! :) > > Just an FYI with "passes-through" on IOS-XR support for "0" as a value > was |deprecated | doesn't work anymore | was "Cisco'ed" ] ... > > as-path-set BOGONS-ASNs > #rfc7607 > ios-regex '_0_', > #2 to 4 byte ASN migrations > passes-through '23456', > #rfc5398 > passes-through '[64496..64511]', > passes-through '[65536..65551]', > #rfc6996 > passes-through '[64512..65534]', > passes-through '[4200000000..4294967294]', > #rfc7300 > passes-through '65535', > passes-through '4294967295', > #IANA reserved > passes-through '[65552..131071]' > end-set > > >> With your permission I'd like to add the IOS flavor > > Yea sure, help your self. > > > Cheers, > James. > > > > ------------------------------ > > Message: 6 > Date: Fri, 3 Jun 2016 12:29:12 +0200 > From: Job Snijders <[email protected]> > To: James Bensley <[email protected]> > Cc: "[email protected]" <[email protected]> > Subject: Re: [uknof] Bogon ASN Filter Policy > Message-ID: <[email protected]> > Content-Type: text/plain; charset=us-ascii > > On Fri, Jun 03, 2016 at 11:05:41AM +0100, James Bensley wrote: >> On 3 June 2016 at 10:26, Job Snijders <[email protected]> wrote: >>> On Fri, Jun 03, 2016 at 10:12:42AM +0100, James Bensley wrote: >>>> It's good to see the larger carriers doing this, >>> >>> GTT also committed >>> http://mailman.nanog.org/pipermail/nanog/2016-June/086081.html >> >> Even better! Just need to ensure everyone is applying prefix filters >> too. Still seeing RFC1918 leakages from time to time. > > KPN / 286 also committed: https://www.ripe.net/s/awesomepostbymarkus > >>> Here are JunOS, IOS XR & BIRD examples: >>> >>> http://as2914.net/bogon_asns/configuration_examples.txt >> >> Many thanks! :) >> >> Just an FYI with "passes-through" on IOS-XR support for "0" as a value >> was |deprecated | doesn't work anymore | was "Cisco'ed" ] ... > > Excellent feedback, I've updated the doc. > > Kind regards, > > Job > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > uknof mailing list > [email protected] > https://lists.uknof.org.uk/cgi-bin/mailman/listinfo/uknof > > ------------------------------ > > End of uknof Digest, Vol 90, Issue 2 > ************************************ > -- Abdulkareem H. Ali Network Operations Engineer CentralNic Group PLC London Stock Exchange Symbol: CNIC +44 20 3388 0600 www.CentralNic.com CentralNic Group PLC is a company registered in England and Wales with company number 8576358. Registered Offices: 35-39 Moorgate, London, EC2R 6AR.
