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