Hi everyone, I have one simple question: as for AS relationship, should customer tell its provider the AS# of its own customers, or the provider have the right to require its customers to do that? Thanks! -- Sky Li
On Thu, Feb 20, 2014 at 3:14 AM, Song Li <refresh.lsong@gmail.com> wrote:
Hi everyone,
I have one simple question: as for AS relationship, should customer tell its provider the AS# of its own customers, or the provider have the right to require its customers to do that?
in an ideal world the ISP is filtering prefixes from their customer, which means that the customer has to disclose downstream information. so, yes. pleass tell your upstream your customers so proper filtering can be automated and implemented. don't turn up bgp customers without filtering, that kills kittens. -chris
On Thursday, February 20, 2014 08:09:35 PM Christopher Morrow wrote:
so, yes. pleass tell your upstream your customers so proper filtering can be automated and implemented.
don't turn up bgp customers without filtering, that kills kittens.
For all the leaking I've seen in the last four weeks (including a well-known operator that was involved in the Youtube/Pakistan saga + other well-known global operators that could be classified as "a reasonably large tier"), we're still a long way away ensuring all customer prefixes are filtered correctly at the inter-domain peering edge. A loooooooong way away... Mark.
Thanks. In order to prevent route leaking, this imformation should be provided to providers. but another question, should the AS relationships between customer and its other neighbors (downstrem/peer/another provider) be private? -- Sky Li
On Thursday, February 20, 2014 08:09:35 PM Christopher Morrow wrote:
so, yes. pleass tell your upstream your customers so proper filtering can be automated and implemented.
don't turn up bgp customers without filtering, that kills kittens. For all the leaking I've seen in the last four weeks (including a well-known operator that was involved in the Youtube/Pakistan saga + other well-known global operators that could be classified as "a reasonably large tier"), we're still a long way away ensuring all customer prefixes are filtered correctly at the inter-domain peering edge. A loooooooong way away...
Mark.
On Friday, February 21, 2014 07:37:52 AM Song Li wrote:
Thanks. In order to prevent route leaking, this imformation should be provided to providers.
Route leaking is not only from customers-to-providers. It can also be from providers-to-providers (and from peers-to- peers). The majority of leaks I've seen in the past have been possible because some inter-provider links have not been filtered correctly, i.e., they are providing (unknown) transit where they would only be peering. It is not uncommon to see more relaxed filtering between providers/peers, e.g., AS_PATH-based only, max-prefix-based only, e.t.c., but please don't send these out to anyone else besides your customers unless the ultimate relationship calls for it. Of course, one can't guarantee that the customers you send this to won't leak it to their own transit providers. Bottom line, chasing route leaks can be a full time job.
but another question, should the AS relationships between customer and its other neighbors (downstrem/peer/another provider) be private?
What do you mean, in terms of how they connect or in terms of the business relationship? I don't think it matters either way. The common peering, filtering and re-announcement rules apply. Mark.
On Fri, Feb 21, 2014 at 12:37 AM, Song Li <refresh.lsong@gmail.com> wrote:
Thanks. In order to prevent route leaking, this imformation should be provided to providers.
but another question, should the AS relationships between customer and its other neighbors (downstrem/peer/another provider) be private?
perhaps you should draw a little ascii art, I think you're asking: DS1 - customer - you - isp "can DS1's relationship to 'customer' be secret" no. well, not if they want: 1) to use a public ASN 2) use ip space which isn't part of 'customer' aggregate 3) want to be reachable on the internet It's safe to say that your goal as an ISP and a customer of an ISP, should be: "Make sure that all of my routes and the routes of my customers and their customers, that I'm expected to provide transit for, are in my ISP's filters." -chris (and as someelse pointed out: "If they use BGP and expect global reachabilty... then the information isn't private anyway.")
-- Sky Li
On Thursday, February 20, 2014 08:09:35 PM Christopher Morrow wrote:
so, yes. pleass tell your upstream your customers so proper filtering can be automated and implemented.
don't turn up bgp customers without filtering, that kills kittens.
For all the leaking I've seen in the last four weeks (including a well-known operator that was involved in the Youtube/Pakistan saga + other well-known global operators that could be classified as "a reasonably large tier"), we're still a long way away ensuring all customer prefixes are filtered correctly at the inter-domain peering edge. A loooooooong way away...
Mark.
+----------+ +---------+ | provider1| |provider2| +----------+ +---------+ ^ ^ | | | | +--------+ ++-------++ +----------+ |peer AS2+-----+ AS 1 +----+peer AS3 | +--------+ +---------+ +----------+ ^ ^ | | +------------+ +-------------+ |customer AS4| |customer AS5 | +------------+ +-------------+ um.... sorry, my question is: the AS relationship between AS1 and AS2/3 is peer, and AS1 cannot announce routes from AS3 to provider1 by rule. But if AS1 do it, and the realtionship between AS1 and AS3 is invisible to provider1, how can provider1 detect this route leak without knowing the privacy? In other words, could the business relationship between AS1 and AS3 be known to provider1/2? Thanks. Sky li
perhaps you should draw a little ascii art, I think you're asking:
DS1 - customer - you - isp
"can DS1's relationship to 'customer' be secret"
no. well, not if they want: 1) to use a public ASN 2) use ip space which isn't part of 'customer' aggregate 3) want to be reachable on the internet
It's safe to say that your goal as an ISP and a customer of an ISP, should be: "Make sure that all of my routes and the routes of my customers and their customers, that I'm expected to provide transit for, are in my ISP's filters."
-chris (and as someelse pointed out: "If they use BGP and expect global reachabilty... then the information isn't private anyway.")
-- Sky Li
On Thursday, February 20, 2014 08:09:35 PM Christopher Morrow wrote:
so, yes. pleass tell your upstream your customers so proper filtering can be automated and implemented.
don't turn up bgp customers without filtering, that kills kittens.
For all the leaking I've seen in the last four weeks (including a well-known operator that was involved in the Youtube/Pakistan saga + other well-known global operators that could be classified as "a reasonably large tier"), we're still a long way away ensuring all customer prefixes are filtered correctly at the inter-domain peering edge. A loooooooong way away...
Mark.
On Friday, February 21, 2014 08:57:07 AM Song Li wrote:
the AS relationship between AS1 and AS2/3 is peer, and AS1 cannot announce routes from AS3 to provider1 by rule.
Or even Peer-AS2's routes to Peer-AS3 (and vice versa), in general best practice filtering rules, unless transit is requested.
But if AS1 do it, and the realtionship between AS1 and AS3 is invisible to provider1, how can provider1 detect this route leak without knowing the privacy?
Provider-1 wouldn't care whether it's a route leak or not. In Provider-1's mind, Peer-AS3 could (suddenly) be a customer of AS1. And since AS1 is a customer of Provider-1, Provider-1 will be happy to move those packets along as it represents more revenue for Provider-1 (more so if traffic is sold on a 95th percentile or volume utilization basis). It is, really, up to AS3 to detect that AS1 has leaked its routes (or paths, to be precise) to Provider-1, and then pick up the phone and scream at AS1 to get that leak fixed plugged. Of course, all of this is a moot point if Provider-1 is a good provider and makes sure they only accept routes and paths from AS3 that AS3 should be sending to Provider-1 in the first place. But as we know, some providers are a bit (actually, very) lazy here.
In other words, could the business relationship between AS1 and AS3 be known to provider1/2?
Not really (or not that easily, to be specific). With enough time and access to several looking glasses and public route servers, one could "infer" (to a certain degree of error) business relationships between peering relationships, i.e., whether they relationships are customer, peer or provider. But in your particular case, unless AS3 has a direct connection toward Provider-1/2 (where a route leak would introduce more problems), Provider-1/2 don't really care about whether this is a leak or not from AS1. But again, this whole discussion is mooted if Provider-1/2 do proper background checks and filtering before they turn- up the service for AS1. Mark.
Thanks. I'm doing some research on route leaks, you are a great help to me. Sky li
On Friday, February 21, 2014 08:57:07 AM Song Li wrote:
the AS relationship between AS1 and AS2/3 is peer, and AS1 cannot announce routes from AS3 to provider1 by rule.
Or even Peer-AS2's routes to Peer-AS3 (and vice versa), in general best practice filtering rules, unless transit is requested.
But if AS1 do it, and the realtionship between AS1 and AS3 is invisible to provider1, how can provider1 detect this route leak without knowing the privacy?
Provider-1 wouldn't care whether it's a route leak or not. In Provider-1's mind, Peer-AS3 could (suddenly) be a customer of AS1. And since AS1 is a customer of Provider-1, Provider-1 will be happy to move those packets along as it represents more revenue for Provider-1 (more so if traffic is sold on a 95th percentile or volume utilization basis).
It is, really, up to AS3 to detect that AS1 has leaked its routes (or paths, to be precise) to Provider-1, and then pick up the phone and scream at AS1 to get that leak fixed plugged.
Of course, all of this is a moot point if Provider-1 is a good provider and makes sure they only accept routes and paths from AS3 that AS3 should be sending to Provider-1 in the first place. But as we know, some providers are a bit (actually, very) lazy here.
In other words, could the business relationship between AS1 and AS3 be known to provider1/2?
Not really (or not that easily, to be specific).
With enough time and access to several looking glasses and public route servers, one could "infer" (to a certain degree of error) business relationships between peering relationships, i.e., whether they relationships are customer, peer or provider.
But in your particular case, unless AS3 has a direct connection toward Provider-1/2 (where a route leak would introduce more problems), Provider-1/2 don't really care about whether this is a leak or not from AS1.
But again, this whole discussion is mooted if Provider-1/2 do proper background checks and filtering before they turn- up the service for AS1.
Mark.
-- Song Li Room 4-204, FIT Building, Network Security, Department of Electronic Engineering, Tsinghua University, Beijing 100084, China Tel:( +86) 010-62446440 E-mail: refresh.lsong@gmail.com
On Thu, Feb 20, 2014 at 3:14 AM, Song Li <refresh.lsong@gmail.com> wrote:
I have one simple question: as for AS relationship, should customer tell its provider the AS# of its own customers, or the provider have the right to require its customers to do that?
Um... you DO tell your provider the AS numbers of your customers... in the BGP route announcement you send them. It's not a question of rights or requirements. You already do it. Because that's how the technology works. As Chris noted, telling your provider out-of-band before sending the same information via BGP is also a very good idea which enhances the security of the whole doggone Internet. Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
On Thu, 20 Feb 2014 03:14:59 -0500, Song Li <refresh.lsong@gmail.com> wrote:
I have one simple question: as for AS relationship, should customer tell its provider the AS# of its own customers, or the provider have the right to require its customers to do that?
(Having been on both ends of this...) If you want me to carry their traffic, yes, I need to know their address block(s) AND the ASN appearing behind yours. I will, in turn, have to provide that to my upstream provider(s). NOBODY should be blindly accepting routing information from ANYONE, EVER. That's how people appropriate address space. --Ricky
participants (5)
-
Christopher Morrow -
Mark Tinka -
Ricky Beam -
Song Li -
William Herrin