|
|
|
|
|
|
|
|
|
|
|
|
| home | help | back | first | fref | pref | prev | next | nref | lref | last | post |
From: Mark Tinka <mark.tinka@seacom.mu> To: refresh.lsong@gmail.com Date: Fri, 21 Feb 2014 11:13:20 +0200 In-Reply-To: <5306F8C3.8070400@gmail.com> Cc: nanog list <nanog@nanog.org> Reply-To: mark.tinka@seacom.mu Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org --nextPart2393892.O9lA037NvG Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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=20 general best practice filtering rules, unless transit is=20 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.=20 In Provider-1's mind, Peer-AS3 could (suddenly) be a=20 customer of AS1. And since AS1 is a customer of Provider-1,=20 Provider-1 will be happy to move those packets along as it=20 represents more revenue for Provider-1 (more so if traffic=20 is sold on a 95th percentile or volume utilization basis). It is, really, up to AS3 to detect that AS1 has leaked its=20 routes (or paths, to be precise) to Provider-1, and then=20 pick up the phone and scream at AS1 to get that leak fixed=20 plugged. Of course, all of this is a moot point if Provider-1 is a=20 good provider and makes sure they only accept routes and=20 paths from AS3 that AS3 should be sending to Provider-1 in=20 the first place. But as we know, some providers are a bit=20 (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=20 public route servers, one could "infer" (to a certain degree=20 of error) business relationships between peering=20 relationships, i.e., whether they relationships are=20 customer, peer or provider. But in your particular case, unless AS3 has a direct=20 connection toward Provider-1/2 (where a route leak would=20 introduce more problems), Provider-1/2 don't really care=20 about whether this is a leak or not from AS1. But again, this whole discussion is mooted if Provider-1/2=20 do proper background checks and filtering before they turn- up the service for AS1. Mark. --nextPart2393892.O9lA037NvG Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) iQIcBAABAgAGBQJTBxizAAoJEGcZuYTeKm+GUX0P/3/LwXmUMsXJTgw9pDHVkYNN gINj+b0a3f0igCj0yf/8GoQnyygf7SVGwwiQnChdiwxlOl8DHP8dSeTdyE4MybZi My34xNxJSI5kziuKoDJBBtHNusQBdvLT8tD3ufvaeeig/dBPNgiH0qR377T8ztgi doBnabbyYwvS2+PZDSjnxp6tqrmk8ab7kGyJe6kG9Us3yAD8SLhaFbNumqyosikU sw9C3MRgNRsSvtiOAGo7PSFdJcZDuk6SkfW4AFjff2yACmSRZQNYOz9QBgM/KPtz yh0VVBGG1iCF/KQ2xfdPV1g6Amb1ClW0M8ONvkp8JACo8SKBdpPy2RcD4/OuSHxn Xm0h5rDyF9xTxW16MUNiua6I8hIW3vu4/hLJmzRVDinkUvcD7gDc/xBw3mcagOJ1 tLgoM8g6p+T0JQfnJi5/wWFFaq+C5ixZOAFZSui8jWgSK9yTy0SWLKV7jnL/j8Wv 6oqXDqwgaR3s+l8cd6dGLpzGXeisaQL1Ag4j9x6gYwPZc9eyGFTrAEskcy+9gtkp CQnA22xW/xIX3cklRzJg3F9eYHOdL1AYqZyXv4hM+zE4s3SibociNt8k7egm39Ry v5BAYkY23sfFWGP9/NXxZwO3D64wCeN2RW+AaIThESpgckmKOufhGwgd4XWBTg5g TzblxSr/QCDHv/oNG8yC =IFdv -----END PGP SIGNATURE----- --nextPart2393892.O9lA037NvG--
|
|
|
|
|
|
|
|
|
|
|
|
| home | help | back | first | fref | pref | prev | next | nref | lref | last | post |