question about AS relationship

Fri Feb 21 09:13:20 UTC 2014

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20140221/39645170/attachment.sig>