Re: [routing-wg] Bogon ASN Filter Policy

[Michael Perzi]

Hi,

> On 14.06.2016, at 20:43, Gert Doering  wrote:
> 
> Hi,
> 
> On Tue, Jun 14, 2016 at 04:51:40PM +0300, Alexander Azimov wrote:
>> 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. 
> 
> This is good.  A transit ISP stupid enough to make such mistakes need
> to pay in blood and money.

+1


-- 
DI (FH) Michael Perzi
UniVie / ACOnet / VIX
michael.pe...@univie.ac.at // MP4729-RIPE
Tel: +43 1 4277 - 14083 // Fax: - 814038

Re: [routing-wg] Bogon ASN Filter Policy

[Sander Steffann]

Hi,

Op 14 jun. 2016, om 20:43 heeft Gert Doering  het volgende 
geschreven:

> This is good.  A transit ISP stupid enough to make such mistakes need
> to pay in blood and money.

+1

Sander



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [routing-wg] Bogon ASN Filter Policy

[Alexander Azimov]

Dear colleagues,

I've made small observation to check existence of alternative paths - from
more then 8k prefixes, that are announced by private ASNs, only 2k of them
have alternative with not-private origin. So I waive from my suggestion,
it's not going to work.

Thank you all for comments!


2016-06-15 16:16 GMT+03:00 Sebastian Becker :

>
> > Am 14.06.2016 um 20:43 schrieb Gert Doering :
> >
> > Hi,
> >
> > On Tue, Jun 14, 2016 at 04:51:40PM +0300, Alexander Azimov wrote:
> >> 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.
> >
> > This is good.  A transit ISP stupid enough to make such mistakes need
> > to pay in blood and money.
>
> +1
>
> --
> Sebastian Becker
> s...@lab.dtag.de
>
>


-- 
| Alexander Azimov  | HLL l QRATOR
| tel.: +7 499 241 81 92
| mob.: +7 915 360 08 86
| skype: mitradir
| mailto: a...@qrator.net
| visit: www.qrator.net

Re: [routing-wg] Bogon ASN Filter Policy

[heasley]

Tue, Jun 14, 2016 at 04:51:40PM +0300, Alexander Azimov:
> 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.

These should not appear in the DFZ.  I can think of no better way to
encourage resolution than dropping such routes.

Re: [routing-wg] Bogon ASN Filter Policy

[Gert Doering]

Hi,

On Tue, Jun 14, 2016 at 04:51:40PM +0300, Alexander Azimov wrote:
> 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. 

This is good.  A transit ISP stupid enough to make such mistakes need
to pay in blood and money.

Gert Doering
-- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AGVorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14  Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen   HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444   USt-IdNr.: DE813185279


signature.asc
Description: PGP signature

Re: [routing-wg] Bogon ASN Filter Policy

[Job Snijders]

Hi Colin,

On Mon, Jun 13, 2016 at 04:19:38PM +0200, Colin Petrie wrote:
> On 02/06/16 21:43, Job Snijders wrote:
> > 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.
> 
> However, I do want to mention that filtering route announcements with
> Bogon ASNs in the AGGREGATOR attribute will result in dropping the
> current RIS Routing Beacon announcements.

This is an astute observation! Thanks for spotting that :)

> If there is a desire to block the propagation of routes with these
> attributes, we will need to investigate alternatives to the current
> beacon encoding.
> 
> We are, of course, happy to consider any community input into how this
> should be handled.

The aggregator IP address can still be used to encode information. I
recommend using AS  as the aggregator AS. Furthermore one could use
32-bit BGP communities (and possibly extended BGP communities too for a
level of information redundancy) to encode additional meta information. 

Kind regards,

Job

Re: [routing-wg] Bogon ASN Filter Policy

[Colin Petrie]

On 02/06/16 21:43, Job Snijders wrote:
> 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.

Hi,

I have no problem with filtering Bogon ASNs from the AS_PATH.

However, I do want to mention that filtering route announcements with
Bogon ASNs in the AGGREGATOR attribute will result in dropping the
current RIS Routing Beacon announcements.

They overload the AGGREGATOR attribute with extra information to encode
the time of the announcement, a sequence number, and the originating
RRC, into the AGGREGATOR using private ASNs. The schema is documented here:
https://www.ripe.net/analyse/internet-measurements/routing-information-service-ris/current-ris-routing-beacons


This information has been used in many studies into prefix propagation
and convergence, flap dampening, etc.

If there is a desire to block the propagation of routes with these
attributes, we will need to investigate alternatives to the current
beacon encoding.

We are, of course, happy to consider any community input into how this
should be handled.

Kind Regards,
Colin 

--
Colin Petrie
Systems Engineer
RIPE NCC

Re: [routing-wg] Bogon ASN Filter Policy

[Hank Nussbacher]

On 02/06/2016 22:43, 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
> 42-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 , Jared Mauch ,
> NTT Communications NOC 
>
> 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
>
You guys are my heroes!If 4-5 tier-0 ISPs would do exactly this,
bogus ASNs would disappear in a week.
Instead everyone talks while the problem gets larger (now over 5000):
http://www.cidr-report.org/as2.0/bogus-as-advertisements.html

-Hank

[routing-wg] Bogon ASN Filter Policy

[Job Snijders]

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
42-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 , Jared Mauch ,
NTT Communications NOC 

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