On Mon, 20 May 2019 23:09:02 +0000 Seth Mattinen <sethm@rollernet.us> wrote:
A good start would be killing any /24 announcement where a covering aggregate exists.
I wouldn't do this as a general rule. If an attacker knows networks are 1) not pointing default, 2) dropping /24's, 3) not validating the aggregates, and 4) no actual legitimate aggregate exists, (all reasonable assumptions so far for many /24's), then they have a pretty good opportunity to capture that traffic. John
On 5/20/19 4:26 PM, John Kristoff wrote: > On Mon, 20 May 2019 23:09:02 +0000 > Seth Mattinen<sethm@rollernet.us> wrote: > >> A good start would be killing any /24 announcement where a covering >> aggregate exists. > I wouldn't do this as a general rule. If an attacker knows networks are > 1) not pointing default, 2) dropping /24's, 3) not validating the > aggregates, and 4) no actual legitimate aggregate exists, (all > reasonable assumptions so far for many /24's), then they have a pretty > good opportunity to capture that traffic. I'm talking about the case where someone has like a /20 and announces the /20 plus every /24 it contains. I regard those as garbage announcements.
On Mon, May 20, 2019 at 5:59 PM Seth Mattinen <sethm@rollernet.us> wrote: > On 5/20/19 4:26 PM, John Kristoff wrote: > > On Mon, 20 May 2019 23:09:02 +0000 > > Seth Mattinen<sethm@rollernet.us> wrote: > > > >> A good start would be killing any /24 announcement where a covering > >> aggregate exists. > > I wouldn't do this as a general rule. If an attacker knows networks are > > 1) not pointing default, 2) dropping /24's, 3) not validating the > > aggregates, and 4) no actual legitimate aggregate exists, (all > > reasonable assumptions so far for many /24's), then they have a pretty > > good opportunity to capture that traffic. > > > I'm talking about the case where someone has like a /20 and announces > the /20 plus every /24 it contains. I regard those as garbage > announcements. The lesson for all is — do not expect /24s to reach all edges. People have been doing this since we hit 512k routes, and will do it more often, regardless of how much shade you throw on this mailer. Like NAT, this is another way that IPv4 is buckling >
On 5/20/19 7:26 PM, John Kristoff wrote: > On Mon, 20 May 2019 23:09:02 +0000 > Seth Mattinen <sethm@rollernet.us> wrote: > >> A good start would be killing any /24 announcement where a covering >> aggregate exists. > I wouldn't do this as a general rule. If an attacker knows networks are > 1) not pointing default, 2) dropping /24's, 3) not validating the > aggregates, and 4) no actual legitimate aggregate exists, (all > reasonable assumptions so far for many /24's), then they have a pretty > good opportunity to capture that traffic. +1 John Seth approach could be an option _only_ if prefix has an aggregate exists && as origin are the same > John
There are sometimes legitimate reasons to have a covering aggregate with some more specific announcements. Certainly there's a lot of cleanup that many should do in this area, but it might not be the best approach to this issue. On Tue, May 21, 2019 at 5:30 AM Alejandro Acosta < alejandroacostaalamo@gmail.com> wrote: > > On 5/20/19 7:26 PM, John Kristoff wrote: > > On Mon, 20 May 2019 23:09:02 +0000 > > Seth Mattinen <sethm@rollernet.us> wrote: > > > >> A good start would be killing any /24 announcement where a covering > >> aggregate exists. > > I wouldn't do this as a general rule. If an attacker knows networks are > > 1) not pointing default, 2) dropping /24's, 3) not validating the > > aggregates, and 4) no actual legitimate aggregate exists, (all > > reasonable assumptions so far for many /24's), then they have a pretty > > good opportunity to capture that traffic. > > > +1 John > > Seth approach could be an option _only_ if prefix has an aggregate > exists && as origin are the same > > > > John >
Hello.., you are totally right, the first reason that came to my mind is traffic engineering but there are other reasons too. On 5/22/19 12:40 PM, Tom Beecher wrote:
There are sometimes legitimate reasons to have a covering aggregate with some more specific announcements. Certainly there's a lot of cleanup that many should do in this area, but it might not be the best approach to this issue.
On Tue, May 21, 2019 at 5:30 AM Alejandro Acosta <alejandroacostaalamo@gmail.com <mailto:alejandroacostaalamo@gmail.com>> wrote:
On 5/20/19 7:26 PM, John Kristoff wrote: > On Mon, 20 May 2019 23:09:02 +0000 > Seth Mattinen <sethm@rollernet.us <mailto:sethm@rollernet.us>> wrote: > >> A good start would be killing any /24 announcement where a covering >> aggregate exists. > I wouldn't do this as a general rule. If an attacker knows networks are > 1) not pointing default, 2) dropping /24's, 3) not validating the > aggregates, and 4) no actual legitimate aggregate exists, (all > reasonable assumptions so far for many /24's), then they have a pretty > good opportunity to capture that traffic.
+1 John
Seth approach could be an option _only_ if prefix has an aggregate exists && as origin are the same
> John
Hi, One legitimate reason is the split of companies. In some cases, IP space needs to be divided up. For example, company A splits up in AA and AB, and has a /20. Company AA may advertise the /20, while the new AB may advertise the top or bottom /21. I know of at least one worldwide e-commerce company that is in that situation. Thanks, Sabri ----- On May 22, 2019, at 9:40 AM, Tom Beecher <beecher@beecher.cc> wrote: > There are sometimes legitimate reasons to have a covering aggregate with some > more specific announcements. Certainly there's a lot of cleanup that many > should do in this area, but it might not be the best approach to this issue. > On Tue, May 21, 2019 at 5:30 AM Alejandro Acosta < [ > mailto:alejandroacostaalamo@gmail.com | alejandroacostaalamo@gmail.com ] > > wrote: >> On 5/20/19 7:26 PM, John Kristoff wrote: >> > On Mon, 20 May 2019 23:09:02 +0000 >> > Seth Mattinen < [ mailto:sethm@rollernet.us | sethm@rollernet.us ] > wrote: >> >> A good start would be killing any /24 announcement where a covering >> >> aggregate exists. >> > I wouldn't do this as a general rule. If an attacker knows networks are >> > 1) not pointing default, 2) dropping /24's, 3) not validating the >> > aggregates, and 4) no actual legitimate aggregate exists, (all >> > reasonable assumptions so far for many /24's), then they have a pretty >> > good opportunity to capture that traffic. >> +1 John >> Seth approach could be an option _only_ if prefix has an aggregate >> exists && as origin are the same >> > John
In that case shouldn't each company advertise a /21? On Wed, May 22, 2019, 1:11 PM Sabri Berisha <sabri@cluecentral.net> wrote: > Hi, > > One legitimate reason is the split of companies. In some cases, IP space > needs to be divided up. For example, company A splits up in AA and AB, and > has a /20. Company AA may advertise the /20, while the new AB may advertise > the top or bottom /21. I know of at least one worldwide e-commerce company > that is in that situation. > > Thanks, > > Sabri > > > ----- On May 22, 2019, at 9:40 AM, Tom Beecher <beecher@beecher.cc> wrote: > > There are sometimes legitimate reasons to have a covering aggregate with > some more specific announcements. Certainly there's a lot of cleanup that > many should do in this area, but it might not be the best approach to this > issue. > > On Tue, May 21, 2019 at 5:30 AM Alejandro Acosta < > alejandroacostaalamo@gmail.com> wrote: > >> >> On 5/20/19 7:26 PM, John Kristoff wrote: >> > On Mon, 20 May 2019 23:09:02 +0000 >> > Seth Mattinen <sethm@rollernet.us> wrote: >> > >> >> A good start would be killing any /24 announcement where a covering >> >> aggregate exists. >> > I wouldn't do this as a general rule. If an attacker knows networks are >> > 1) not pointing default, 2) dropping /24's, 3) not validating the >> > aggregates, and 4) no actual legitimate aggregate exists, (all >> > reasonable assumptions so far for many /24's), then they have a pretty >> > good opportunity to capture that traffic. >> >> >> +1 John >> >> Seth approach could be an option _only_ if prefix has an aggregate >> exists && as origin are the same >> >> >> > John >> > >
Hi, They can, but they don't necessarily have to. In the example I mentioned, there was a private peering between them. Well, until very recently. My point being that it's not always black and white, and sometimes deaggregation is necessary for operational purposes. That's not to excuse lazy operators of course. Thanks, Sabri ----- On May 22, 2019, at 11:23 AM, Ross Tajvar <ross@tajvar.io> wrote: > In that case shouldn't each company advertise a /21? > On Wed, May 22, 2019, 1:11 PM Sabri Berisha < [ mailto:sabri@cluecentral.net | > sabri@cluecentral.net ] > wrote: >> Hi, >> One legitimate reason is the split of companies. In some cases, IP space needs >> to be divided up. For example, company A splits up in AA and AB, and has a /20. >> Company AA may advertise the /20, while the new AB may advertise the top or >> bottom /21. I know of at least one worldwide e-commerce company that is in that >> situation. >> Thanks, >> Sabri >> ----- On May 22, 2019, at 9:40 AM, Tom Beecher <beecher@beecher.cc> wrote: >>> There are sometimes legitimate reasons to have a covering aggregate with some >>> more specific announcements. Certainly there's a lot of cleanup that many >>> should do in this area, but it might not be the best approach to this issue. >>> On Tue, May 21, 2019 at 5:30 AM Alejandro Acosta < [ >>> mailto:alejandroacostaalamo@gmail.com | alejandroacostaalamo@gmail.com ] > >>> wrote: >>>> On 5/20/19 7:26 PM, John Kristoff wrote: >>>> > On Mon, 20 May 2019 23:09:02 +0000 >>>> > Seth Mattinen < [ mailto:sethm@rollernet.us | sethm@rollernet.us ] > wrote: >>>> >> A good start would be killing any /24 announcement where a covering >>>> >> aggregate exists. >>>> > I wouldn't do this as a general rule. If an attacker knows networks are >>>> > 1) not pointing default, 2) dropping /24's, 3) not validating the >>>> > aggregates, and 4) no actual legitimate aggregate exists, (all >>>> > reasonable assumptions so far for many /24's), then they have a pretty >>>> > good opportunity to capture that traffic. >>>> +1 John >>>> Seth approach could be an option _only_ if prefix has an aggregate >>>> exists && as origin are the same >>>> > John
If networks are going to make unconventional announcements, I'm not concerned if they suffer because of it. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Sabri Berisha" <sabri@cluecentral.net> To: "Ross Tajvar" <ross@tajvar.io> Cc: "nanog" <nanog@nanog.org> Sent: Friday, May 24, 2019 12:03:52 PM Subject: Re: BGP prefix filter list Hi, They can, but they don't necessarily have to. In the example I mentioned, there was a private peering between them. Well, until very recently. My point being that it's not always black and white, and sometimes deaggregation is necessary for operational purposes. That's not to excuse lazy operators of course. Thanks, Sabri ----- On May 22, 2019, at 11:23 AM, Ross Tajvar <ross@tajvar.io> wrote: In that case shouldn't each company advertise a /21? On Wed, May 22, 2019, 1:11 PM Sabri Berisha < sabri@cluecentral.net > wrote: <blockquote> Hi, One legitimate reason is the split of companies. In some cases, IP space needs to be divided up. For example, company A splits up in AA and AB, and has a /20. Company AA may advertise the /20, while the new AB may advertise the top or bottom /21. I know of at least one worldwide e-commerce company that is in that situation. Thanks, Sabri ----- On May 22, 2019, at 9:40 AM, Tom Beecher <beecher@beecher.cc> wrote: <blockquote> There are sometimes legitimate reasons to have a covering aggregate with some more specific announcements. Certainly there's a lot of cleanup that many should do in this area, but it might not be the best approach to this issue. On Tue, May 21, 2019 at 5:30 AM Alejandro Acosta < alejandroacostaalamo@gmail.com > wrote: <blockquote> On 5/20/19 7:26 PM, John Kristoff wrote: > On Mon, 20 May 2019 23:09:02 +0000 > Seth Mattinen < sethm@rollernet.us > wrote: > >> A good start would be killing any /24 announcement where a covering >> aggregate exists. > I wouldn't do this as a general rule. If an attacker knows networks are > 1) not pointing default, 2) dropping /24's, 3) not validating the > aggregates, and 4) no actual legitimate aggregate exists, (all > reasonable assumptions so far for many /24's), then they have a pretty > good opportunity to capture that traffic. +1 John Seth approach could be an option _only_ if prefix has an aggregate exists && as origin are the same > John </blockquote> </blockquote> </blockquote>
On Fri, May 24, 2019 at 10:29 AM Mike Hammett <nanog@ics-il.net> wrote:
If networks are going to make unconventional announcements, I'm not concerned if they suffer because of it.
No, no no. You're not getting it. I'm a customer of Verizon. I'm a customer of CenturyLink. I get a /24 from CenturyLink and announce it via my two carriers: Verizon and CenturyLink. CenturyLink also announces the aggregate, let's say /16 that the /24 is a part of because all of the /16 containing my /24 is their allocation. Get it? I announce the /24 via both so that you can reach me when there is a problem with one or the other. If you drop the /24, you break the Internet when my connection to CenturyLink is inoperable. Good job! There is nothing unconventional about this arrangement. It was commonplace before ARIN dropped the minimum end-user assignment to /24 and many networks who themselves up that way have found it inconvenient to renumber. Regards, Bill Herrin -- William Herrin bill@herrin.us https://bill.herrin.us/
William Herrin wrote on 5/24/2019 1:22 PM:
If you drop the /24, you break the Internet when my connection to CenturyLink is inoperable.
Not really. The remote networks that drop visibility to your /24 announcement still have a default route. They just just leave the decision of the best path to your /24 up to their upstream provider(s) rather than having direct knowledge.
On Fri, May 24, 2019 at 11:34 AM Blake Hudson <blake@ispn.net> wrote:
William Herrin wrote on 5/24/2019 1:22 PM:
If you drop the /24, you break the Internet when my connection to CenturyLink is inoperable.
Not really. The remote networks that drop visibility to your /24 announcement still have a default route. They just just leave the decision of the best path to your /24 up to their upstream provider(s) rather than having direct knowledge.
If you're talking about a leaf node in the BGP system then sure. You can ditch whatever you want and replace it with default routes. Ditch whole /8's if it floats your boat. Partial feed has always been acceptable for leaf nodes. If you're talking about a transit node then no, you're breaking the Internet. Even if you have a default route, your downstream customer, to whom you fail to provide the /24, will suffer malfunction. Regards, Bill Herrin -- William Herrin bill@herrin.us https://bill.herrin.us/
On Fri, May 24, 2019 at 11:22:48AM -0700, William Herrin wrote:
Get it? I announce the /24 via both so that you can reach me when there is a problem with one or the other. If you drop the /24, you break the Internet when my connection to CenturyLink is inoperable. Good job!
Or also likely, in the event of your CenturyLink circuit outage, the following is likely to happen: 1. traffic comes into CenturyLink, dragged in by their /16 aggregate announcement 2. CenturyLink hears your more specific /24 from Verizon PX 3. CenturyLink sends traffic received from one peer, and out to another (Verizon), without touching a revenue side customer interface (temporary free transit situation, or temporary onintended hairpinning) This assumes you're getting /24 allocation from an aggregate CenturyLink finds acceptable to reassign to BGP multihomed customers, where they won't filter it out right from their peers (for Level3, 8.0.0.0/8 space is used for this typically). I agree that this is very common. I also found, not having LSP setup between peering-only designated routers (who would've thought a peering router needs to provide transit to another peering router that has no customers on it?!?) breaks connectivity to customers that find themselves in this very situation, due to the temporary hairpinning of traffic from one (peer|transit) interface out to another. James
On 5/24/19 2:22 PM, William Herrin wrote:
Get it? I announce the /24 via both so that you can reach me when there is a problem with one or the other. If you drop the /24, you break the Internet when my connection to CenturyLink is inoperable. Good job!
It would be dropped only if the origin-as was the same. Your AS and your carriers aggregate announcement would be from two different origin AS. At least that's the gist of it... -- inoc.net!rblayzor XMPP: rblayzor.AT.inoc.net PGP: https://pgp.inoc.net/rblayzor/
On Thu, May 30, 2019 at 8:30 AM Robert Blayzor <rblayzor.bulk@inoc.net> wrote:
On 5/24/19 2:22 PM, William Herrin wrote:
Get it? I announce the /24 via both so that you can reach me when there is a problem with one or the other. If you drop the /24, you break the Internet when my connection to CenturyLink is inoperable. Good job!
It would be dropped only if the origin-as was the same. Your AS and your carriers aggregate announcement would be from two different origin AS. At least that's the gist of it...
Hi Robert, Error #1: https://tools.ietf.org/html/rfc6996 section 4. It's permissible to announce to your transits with a private AS which they remove before passing the announcement to the wider Internet. As a result, the announcement from each provider will have that provider's origin AS when you see it even though it's actually from a downstream multihomed customer. Error #2: An AS is an informative handle, not a route. In routing research parlance, an identifier not a locator. Prefixes from the same AS are not required to have direct connectivity to each other and many do not. The origin AS could solve this by disaggregating the announcement and sending no covering route, but that's exactly what you DON'T want them to do. Regards, Bill Herrin -- William Herrin bill@herrin.us https://bill.herrin.us/
Bill, Are your sure about your Error #2, where you say "Prefixes from the same AS are not required to have direct connectivity to each other and many do not."? From BGP definitions: The AS represents a connected group of one or more blocks of IP addresses, called IP prefixes, that have been assigned to that organization and provides a single routing policy to systems outside the AS. “...a connected group..." implies that all the prefixes in an AS must have direct connectivity to each other (direct meaning within the IGP of the AS). I realize that some AS’s have hot backup facilities that they advertise with heavy prefixing, but in my experience, the backup facility must still be interconnected with the rest of the AS, because prefixing doesn’t guarantee no packets will its that border router. -mel On May 30, 2019, at 9:54 AM, William Herrin <bill@herrin.us<mailto:bill@herrin.us>> wrote: On Thu, May 30, 2019 at 8:30 AM Robert Blayzor <rblayzor.bulk@inoc.net<mailto:rblayzor.bulk@inoc.net>> wrote: On 5/24/19 2:22 PM, William Herrin wrote:
Get it? I announce the /24 via both so that you can reach me when there is a problem with one or the other. If you drop the /24, you break the Internet when my connection to CenturyLink is inoperable. Good job!
It would be dropped only if the origin-as was the same. Your AS and your carriers aggregate announcement would be from two different origin AS. At least that's the gist of it... Hi Robert, Error #1: https://tools.ietf.org/html/rfc6996 section 4. It's permissible to announce to your transits with a private AS which they remove before passing the announcement to the wider Internet. As a result, the announcement from each provider will have that provider's origin AS when you see it even though it's actually from a downstream multihomed customer. Error #2: An AS is an informative handle, not a route. In routing research parlance, an identifier not a locator. Prefixes from the same AS are not required to have direct connectivity to each other and many do not. The origin AS could solve this by disaggregating the announcement and sending no covering route, but that's exactly what you DON'T want them to do. Regards, Bill Herrin -- William Herrin bill@herrin.us<mailto:bill@herrin.us> https://bill.herrin.us/
On Thu, May 30, 2019 at 10:11 AM Mel Beckman <mel@beckman.org> wrote:
Are your sure about your Error #2, where you say "Prefixes from the same AS are not required to have direct connectivity to each other and many do not."?
From BGP definitions:
The AS represents a connected group of one or more blocks of IP addresses, called IP prefixes, that have been assigned to that organization and provides a single routing policy to systems outside the AS.
From -what- BGP definitions? This one? https://www.scribd.com/document/202454953/Computer-Networking-Definitions
Lots of things get claimed in books and CS courses that are neither reflected in the standards nor match universal practice. Heck, most networking courses still teach class A, B and C... definitions which were explicitly invalidated a quarter of a century ago. Even where authors are knowledgeable, they're constrained to present approximate explanations lest the common use get lost in the minutiae. When you want to act on the knowledge in an unusual way, you do not have that luxury. The experts in the IRTF Routing Research Group spent something like 6 years trying to find a way to filter the BGP RIB in the middle without damaging the Internet. They came up with zip. A big zero. They all but proved that it's impossible to build a routing protocol that aggregates anything anywhere but at the edges while still obeying the most basic policy constraints like not stealing transit. Forget getting BGP to do it, they couldn't come up with an entirely new protocol that did better. Regards, Bill Herrin -- William Herrin bill@herrin.us https://bill.herrin.us/
Bill, Come on now. The definition of an autonomous system is well established in RFC1930, which is still Best Current Practice: https://tools.ietf.org/html/rfc1930#section-3 An AS is a connected group of one or more IP prefixes run by one or more network operators which has a SINGLE and CLEARLY DEFINED routing policy. This is not an “approximate explanation“. It’s a standard, as strong as any standard that exists for the Internet. How is your statement "Prefixes from the same AS are not required to have direct connectivity to each other and many do not” supported by the published standard? :-) -mel On May 30, 2019, at 10:42 AM, William Herrin <bill@herrin.us<mailto:bill@herrin.us>> wrote:
On Thu, May 30, 2019 at 10:11 AM Mel Beckman <mel@beckman.org<mailto:mel@beckman.org>> wrote:
Are your sure about your Error #2, where you say "Prefixes from the same AS are not required to have direct connectivity to each other and many do not."?
From BGP definitions:
The AS represents a connected group of one or more blocks of IP addresses, called IP prefixes, that have been assigned to that organization and provides a single routing policy to systems outside the AS.
From -what- BGP definitions? This one? https://www.scribd.com/document/202454953/Computer-Networking-Definitions Lots of things get claimed in books and CS courses that are neither reflected in the standards nor match universal practice. Heck, most networking courses still teach class A, B and C... definitions which were explicitly invalidated a quarter of a century ago. Even where authors are knowledgeable, they're constrained to present approximate explanations lest the common use get lost in the minutiae. When you want to act on the knowledge in an unusual way, you do not have that luxury. The experts in the IRTF Routing Research Group spent something like 6 years trying to find a way to filter the BGP RIB in the middle without damaging the Internet. They came up with zip. A big zero. They all but proved that it's impossible to build a routing protocol that aggregates anything anywhere but at the edges while still obeying the most basic policy constraints like not stealing transit. Forget getting BGP to do it, they couldn't come up with an entirely new protocol that did better. Regards, Bill Herrin -- William Herrin bill@herrin.us<mailto:bill@herrin.us> https://bill.herrin.us/
On Thu, May 30, 2019 at 10:58 AM Mel Beckman <mel@beckman.org> wrote:
Come on now. The definition of an autonomous system is well established in RFC1930, which is still Best Current Practice: https://tools.ietf.org/html/rfc1930#section-3
Your quote wasn't from the RFC. Sorry, my google fu is only good enough to find your actual quote, not the similar one you didn't reference.
An AS is a connected group of one or more IP prefixes run by one or more network operators which has a SINGLE and CLEARLY DEFINED routing policy.
Interesting but it bears little resemblance to modern practice. Consider an anycast announcement, for example, where multiple distributed servers at isolated pops terminate the packet. Consider Amazon where both region-local unicast announcements and global anycast announcements all originate from AS 16509. Indeed the whole concept of traffic engineering rests on the premise that an AS' routing policy is NOT the same at every border. Regsards, Bill Herrin -- William Herrin bill@herrin.us https://bill.herrin.us/
Yes, my original quote wasn’t exactly word-for-word from the standard, but it was semantically identical. I’m sure we can find corner cases, but it’s clear that the vast majority of BGP users are following the standard. Anycast isn’t a violation of the standards because it’s defined in BGP as a single destination address having multiple routing paths to two or more endpoints. -mel On May 30, 2019, at 12:48 PM, William Herrin <bill@herrin.us<mailto:bill@herrin.us>> wrote:
On Thu, May 30, 2019 at 10:58 AM Mel Beckman <mel@beckman.org<mailto:mel@beckman.org>> wrote:
Come on now. The definition of an autonomous system is well established in RFC1930, which is still Best Current Practice: https://tools.ietf.org/html/rfc1930#section-3
Your quote wasn't from the RFC. Sorry, my google fu is only good enough to find your actual quote, not the similar one you didn't reference.
An AS is a connected group of one or more IP prefixes run by one or more network operators which has a SINGLE and CLEARLY DEFINED routing policy.
Interesting but it bears little resemblance to modern practice. Consider an anycast announcement, for example, where multiple distributed servers at isolated pops terminate the packet. Consider Amazon where both region-local unicast announcements and global anycast announcements all originate from AS 16509. Indeed the whole concept of traffic engineering rests on the premise that an AS' routing policy is NOT the same at every border. Regsards, Bill Herrin -- William Herrin bill@herrin.us<mailto:bill@herrin.us> https://bill.herrin.us/
On 2019-05-30 20:00 +0000, Mel Beckman wrote:
I’m sure we can find corner cases, but it’s clear that the vast ^^^^^ majority of BGP users are following the standard.
"Citation needed". :-) How is it clear that the vast majority are following this? I wouldn't be at all surprised if it *is* literally true; e.g, quite a lot of BGP users are probably single-homed and thus are forced to use private ASNs for talking BGP to their ISP; and lots of BGP users are also single-site, and don't engage in traffic engineering. But those cases are also not very interresting for this. It is more interresting to look at those that according to RFC 1930 *should* use multiple ASNs; how many of those *do* have separate ASNs for each group of prefixes with a "single and clearly defined routing policy", and how many *don't*? Any organization that has multiple sites with their own Internet connections, would then need an AS number for each site. How many people follow that? Can I get multiple ASNs from RIPE/ARIN/et.c for this case? (That's an honest question; the policies I found does mention sites or connected groups of networks, but they also mention organizations in a way that makes me wonder.) As others have mentioned, if you do traffic engineering by announcing prefixes with e.g. different BGP communities, or different amounts of ASN prefixing, you should according to RFC 1930 get a separate ASN for each unique combination of communities and ASN prefixing. Will RIPE/APNIC/et.c grant us multiple ASNs for that? I kind of suspect that we would be told to get lost if we requested 256 ASNs from RIPE for traffic engineering our /16 into 256 /24:s... /Bellman
"Citation needed". :-) How is it clear that the vast majority are following this? Uh, because the Internet works? Think about it. If an AS advertises prefixes that can’t be reached through all of its border routers, those prefixes would lose packets. But I don’t need to provide a citation. The burden of proof is on the person making the assertion, and the assertion by Bill was that having disconnected prefixes in an AS was common. That’s the assertion that needs a citation. My statement is just an opinion that it is clear that most AS’s are following the standard. And we’re not talking about single-homed AS’s using private ASNs. Those are definition excluded, because, being single homed, there is only one path to their prefixes. Any organization that has multiple sites with their own Internet connections, would then need an AS number for each site. What are you talking about? Do you use multi homed BGP? If so, I’d expect you to know that an organization with multiple sites having their own Internet still uses a single AS. They have IGP paths to route traffic between sites (e.g., by using dedicated circuits). -mel On May 30, 2019, at 3:55 PM, Thomas Bellman <bellman@nsc.liu.se<mailto:bellman@nsc.liu.se>> wrote: On 2019-05-30 20:00 +0000, Mel Beckman wrote: I’m sure we can find corner cases, but it’s clear that the vast ^^^^^ majority of BGP users are following the standard. "Citation needed". :-) How is it clear that the vast majority are following this? I wouldn't be at all surprised if it *is* literally true; e.g, quite a lot of BGP users are probably single-homed and thus are forced to use private ASNs for talking BGP to their ISP; and lots of BGP users are also single-site, and don't engage in traffic engineering. But those cases are also not very interresting for this. It is more interresting to look at those that according to RFC 1930 *should* use multiple ASNs; how many of those *do* have separate ASNs for each group of prefixes with a "single and clearly defined routing policy", and how many *don't*? Any organization that has multiple sites with their own Internet connections, would then need an AS number for each site. How many people follow that? Can I get multiple ASNs from RIPE/ARIN/et.c for this case? (That's an honest question; the policies I found does mention sites or connected groups of networks, but they also mention organizations in a way that makes me wonder.) As others have mentioned, if you do traffic engineering by announcing prefixes with e.g. different BGP communities, or different amounts of ASN prefixing, you should according to RFC 1930 get a separate ASN for each unique combination of communities and ASN prefixing. Will RIPE/APNIC/et.c grant us multiple ASNs for that? I kind of suspect that we would be told to get lost if we requested 256 ASNs from RIPE for traffic engineering our /16 into 256 /24:s... /Bellman
On Fri, 31 May 2019 00:10:42 -0000, Mel Beckman said:
What are you talking about? Do you use multi homed BGP? If so, I’d expect you to know that an organization with multiple sites having their own Internet still uses a single AS. They have IGP paths to route traffic between sites (e.g., by using dedicated circuits).
The situation being discussed is an organization with multiple sites that *don't* have a behind-the-scenes dedicated circuit, tunnel, or other interconnect. For example, XYZ Corp has a POP in Tokyo announcing a /16 to their provider there, and a POP in DC announcing a different /16 to their North American provider, using the same ASN for both - but traffic between the two /16s traverses the commodity Internet. Or they advertise the same /16 and pray to the anycast gods. :) (Actually, that's OK too, as long as both Tokyo and DC also announce a second route (possibly a more-specific, or different address space) for their interconnect needs)
No, that's not the situation being discussed. As I've pointed out, a multi homed AS without an IGP connecting all prefixes is non-compliant with the BGP definition of an AS. Your Tokyo/DC example is additionally non-compliant because it doesn't have a single routing policy. It has two policies. That this may work in certain circumstances doesn't make it compliant with the standard. I can stop a car by throwing out a boat anchor, but that doesn't comply with DOT standards for braking :) ________________________________ From: Valdis Kletnieks <valdis@vt.edu> on behalf of Valdis Klētnieks <valdis.kletnieks@vt.edu> Sent: Thursday, May 30, 2019 5:58:34 PM To: Mel Beckman Cc: Thomas Bellman; nanog@nanog.org Subject: Re: BGP prefix filter list On Fri, 31 May 2019 00:10:42 -0000, Mel Beckman said:
What are you talking about? Do you use multi homed BGP? If so, I???d expect you to know that an organization with multiple sites having their own Internet still uses a single AS. They have IGP paths to route traffic between sites (e.g., by using dedicated circuits).
The situation being discussed is an organization with multiple sites that *don't* have a behind-the-scenes dedicated circuit, tunnel, or other interconnect. For example, XYZ Corp has a POP in Tokyo announcing a /16 to their provider there, and a POP in DC announcing a different /16 to their North American provider, using the same ASN for both - but traffic between the two /16s traverses the commodity Internet. Or they advertise the same /16 and pray to the anycast gods. :) (Actually, that's OK too, as long as both Tokyo and DC also announce a second route (possibly a more-specific, or different address space) for their interconnect needs)
On 2019-05-31 01:18 +0000, Mel Beckman wrote:
No, that's not the situation being discussed.
Actually, that *was* the example I was trying to give, where I suspect many are *not* following the rules of RFC 1930.
As I've pointed out, a multi homed AS without an IGP connecting all prefixes is non-compliant with the BGP definition of an AS. Your Tokyo/DC example is additionally non-compliant because it doesn't have a single routing policy. It has two policies. That this may work in certain circumstances doesn't make it compliant with the standard.
So, an *organization* with one Tokyo office and one DC office, each having a PI prefix, and with their own Internet connection(s), and no private interconnect with an IGP connecting the sites. They can handle this in several ways: 1) Use the same ASN for both sites, each site announcing only its own, prefix over eBGP to its ISPs. They won't be able to receive the other site's prefix over eBGP, since the loop detection in BGP will see the common ASN in the announcments from the other site and drop it, but that can be easily handled by the sites adding static routes via their ISPs (or by just getting default routes from their ISPs). This violates RFC 1930; I agree with that. But does it fail in the real world? Will ARIN/APNIC revoke their ASN and/or prefixes due to violating RFC 1930? Will the rest of the Internet try to route the Tokyo prefix to DC, or vice versa, due to them being originated from the same ASN? Any other problems? 2) Get a separate ASN for each site. Continue with not having an IGP between the sites, and continue with announcing different prefixes from each site. They can however now receive each others prefixes over BGP. This does not violate RFC 1930; nowhere in that document does it say that an organization can only have a single ASN. But will ARIN/APNIC be willing to give out two ASNs to that one organization? Does the answer change if it is not one site in Asia and one in America, but one site in every US state? Or one such site in each of the 290 municipalities in Sweden (and pre- sumably trying to get ASNs from RIPE instead of ARIN)? 3) Pay the high fees for getting private interconnects between the continents (or for each of the 290 offices in the Swedish example), and let all sites announce all of each others prefixes, acting as transits for reaching the other sites. This obviously costs more money. I have never priced such an interconnect, so I don't know how much it would cost, but I expect it to be fairly expensive. Also: what happens if the interconnect breaks, partitioning the AS? Then they are in effect at situation (1), violating RFC 1930, with of course the same questions/problems. 4) Pay the high fees for private interconnects, use the same ASN at both sites, but let each site announce the other's prefix with larger amounts of AS path prepending so "no-one" tries to send their traffic to the wrong site. This also violates RFC 1930, as far as I understand, as the two sites have different routing policies. But does it cause any real- world problems? Does the IP police arrest them? Will the rest of the world ignore the policies and send their traffic to the wrong site since the prefixes are originated from the same ASN? I suspect that there are a fair number of organizations that does one of (1), (2) or (4) above, and I *believe* that it actually works. And some of the things I see in our ISP's BGP tables looks like at least some people are doing (4), or possibly (1). RFC 1930 might be the law on the book, but does people actually follow it? Or is it just an outdated law that no-one knows or cares about, but no-one has bothered to formally deprecate? (The parts of RFC 1930 implying that we should have migrated to IDRP by now are obviously not in touch with current reality. :-) My personal feelings is that requiring (3) would be a bad thing, as it would cost lots of money. (2) is OK, but I think many people would forget or ignore getting a separate ASN for each site. But I have only a little experience in running BGP, and have only done so for a single-site organization (or at least single-site in terms of where we have our Internet connection). Answers to the questions I make above are appreciated. /Bellman
On Thu, 30 May 2019 10:42:17 -0700, William Herrin said:
Heck, most networking courses still teach class A, B and C... definitions which were explicitly invalidated a quarter of a century ago.
If you had asked me back in 1993 if I was going to be retired before class A/B/C was gone from common usage and documentation, I'd have called you a crazy person. I have to wonder how much the IPv6 deployment has been stalled by similar outdated documentation and coursework (like the "security" recommendation to "block all ICMP").
Required or not, I've seen a number of networks doing this. At some point "single global ASN" became a marketable pitch and folks realized they don't actually have to have a single Network to get it. Matt (Oops +nanog, sorry Mel + William)
On May 30, 2019, at 13:10, Mel Beckman <mel@beckman.org> wrote:
Bill,
Are your sure about your Error #2, where you say "Prefixes from the same AS are not required to have direct connectivity to each other and many do not."?
From BGP definitions:
The AS represents a connected group of one or more blocks of IP addresses, called IP prefixes, that have been assigned to that organization and provides a single routing policy to systems outside the AS.
“...a connected group..." implies that all the prefixes in an AS must have direct connectivity to each other (direct meaning within the IGP of the AS). I realize that some AS’s have hot backup facilities that they advertise with heavy prefixing, but in my experience, the backup facility must still be interconnected with the rest of the AS, because prefixing doesn’t guarantee no packets will its that border router.
-mel
On May 30, 2019, at 9:54 AM, William Herrin <bill@herrin.us> wrote:
On Thu, May 30, 2019 at 8:30 AM Robert Blayzor <rblayzor.bulk@inoc.net> wrote: On 5/24/19 2:22 PM, William Herrin wrote:
Get it? I announce the /24 via both so that you can reach me when there is a problem with one or the other. If you drop the /24, you break the Internet when my connection to CenturyLink is inoperable. Good job!
It would be dropped only if the origin-as was the same. Your AS and your carriers aggregate announcement would be from two different origin AS. At least that's the gist of it...
Hi Robert,
Error #1: https://tools.ietf.org/html/rfc6996 section 4.
It's permissible to announce to your transits with a private AS which they remove before passing the announcement to the wider Internet. As a result, the announcement from each provider will have that provider's origin AS when you see it even though it's actually from a downstream multihomed customer.
Error #2: An AS is an informative handle, not a route. In routing research parlance, an identifier not a locator. Prefixes from the same AS are not required to have direct connectivity to each other and many do not. The origin AS could solve this by disaggregating the announcement and sending no covering route, but that's exactly what you DON'T want them to do.
Regards, Bill Herrin
-- William Herrin bill@herrin.us https://bill.herrin.us/
Hey William,
Error #1: https://tools.ietf.org/html/rfc6996 section 4.
It's permissible to announce to your transits with a private AS which they remove before passing the announcement to the wider Internet. As a result, the announcement from each provider will have that provider's origin AS when you see it even though it's actually from a downstream multihomed customer.
This may not be common interpretation of the section you cite. Remove-private-asn implementation (CSCO, JNPR) does not remove privates after head. As your transit provider will receive head having your public ASN, they cannot remove any subsequent private ASNs. Only one who can remove private-asn is the originator. Your transit provider can only drop the route or propagate route with private asn in it. It would be inadvisable to send paths with private ASN to your transit operator, as not all transit operators are comfortable propagating those. -- ++ytti
On 5/30/19 12:54 PM, William Herrin wrote:
It's permissible to announce to your transits with a private AS which they remove before passing the announcement to the wider Internet. As a result, the announcement from each provider will have that provider's origin AS when you see it even though it's actually from a downstream multihomed customer.
If you were a multi-homed customer the route would still originate from two different AS's, both of your upstream ISP's. If it's the same ISP, then that would not apply. But then again, if it were the same ISP they could filter the more specific and learn downstream customer routes either by IGP, filtering or tagging the /24 with no-export. -- inoc.net!rblayzor XMPP: rblayzor.AT.inoc.net PGP: https://pgp.inoc.net/rblayzor/
On Thu, May 30, 2019 at 10:43 AM Robert Blayzor <rblayzor.bulk@inoc.net> wrote:
On 5/30/19 12:54 PM, William Herrin wrote:
It's permissible to announce to your transits with a private AS which they remove before passing the announcement to the wider Internet. As a result, the announcement from each provider will have that provider's origin AS when you see it even though it's actually from a downstream multihomed customer.
If you were a multi-homed customer the route would still originate from two different AS's, both of your upstream ISP's. If it's the same ISP, then that would not apply. But then again, if it were the same ISP they could filter the more specific and learn downstream customer routes either by IGP, filtering or tagging the /24 with no-export
Hi Robert, Figured someone would stumble in to this one. 1. What happens to the packets when the /24 gets filtered from one source (in favor of an aggregate) but not from the other? 2. In exchange for this liability, did you gain any capacity in your router? Regards, Bill Herrin -- William Herrin bill@herrin.us https://bill.herrin.us/
On 5/30/19 1:48 PM, William Herrin wrote:
1. What happens to the packets when the /24 gets filtered from one source (in favor of an aggregate) but not from the other?
2. In exchange for this liability, did you gain any capacity in your router?
It was my understanding that the argument for filtering at your own edge, routes which you receive that has an aggregate covering route and a /24 more specific prefix. For a single multi-homed network with two transit ISP's it won't make much of a difference unless you are strapped for outbound bandwidth. Filter away, because you have a covering aggregate route. I'm not saying this will work for ALL networks of any size, but for organizations with just a couple of transit links and not much TE going on, it would be a perfectly viable option rather than overloading your TCAM due to budget constraints... -- inoc.net!rblayzor XMPP: rblayzor.AT.inoc.net PGP: https://pgp.inoc.net/rblayzor/
participants (17)
-
Alejandro Acosta -
Blake Hudson -
Ca By -
James Jun -
John Kristoff -
Matt Corallo -
Mel Beckman -
Mike Hammett -
Robert Blayzor -
Ross Tajvar -
Sabri Berisha -
Saku Ytti -
Seth Mattinen -
Thomas Bellman -
Tom Beecher -
Valdis Klētnieks -
William Herrin