I think your last statement missed the concept of paid peering. That is TIER 1 ISPs frequently announce TIER2 routes but consider the TIER2 "customer" as a "peer". Or am I missing something?
> [2] For the more security-oriented folks in the room, at a very high- > level, peer's only announce their transit customer's routes to each > other. As a peer, you do not announce your other peer's routes on to > other peer's ... Sharing: Author's permission required. [email protected] > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of > Shane Amante > Sent: Monday, February 21, 2011 11:40 AM > To: Jason Schiller > Cc: [email protected]; Russ White > Subject: Re: [sidr] SIDR ReCharter - to capture/cover path validation > work > > Jason, All, > > On Feb 21, 2011, at 09:02 MST, Jason Schiller wrote: > > On Mon, 21 Feb 2011, Russ White wrote: > > > > |So the only security problem anyone faces, currently, is people > cheating > > |on the AS Path length? > > > > I thougth my previous post (as well as other) have been pretty clear > on > > this topic. The Kapella style attacks are sucessful because an > > organization can add ASes that they are not autorized to use to the > > AS-path. > > But, who is certifying what are legitimate vs. illegitimate AS_PATH's > when the AS_PATH is greater than 2? > > IOW, let's take a simple case of a stub AS, (AS_A), who is purchasing > transit from two upstream providers: AS_B and AS_C. In that case, the > originating AS, AS_A, certainly has 'authority' on who (or, what set of > AS'es) should be providing it with transit. And, I can see the origin > AS, AS_A, having something analogous to an IRR 'aut-num' object to tell > the world what AS'es it is exporting/importing routes/AS'es to/from. > Operationally, this is already done today (for those that use IRR aut- > num objects, at least). I get it. If this is where we draw a line in > the sand that we want SIDR work to go, but no farther (at least for > now), then OK. (However, I'm still not sure if REQ #4.1 in draft-ymbk- > bgpsec-reqs-00 is intended to address an origin ASN -> transit > provider's AS_PATH relationship reqm't or is restating what the concept > of ROA's do today. Can someone clarify?) > > > However, the impression I'm getting is that folks want SIDR to go a > step beyond that. For example, AS_B and AS_C announce AS_A on to their > upstreams/peers -- and, this is where I don't get it. Let's use just > the case of transit provider AS_B. Let's say he announces AS_A onto > AS_X, AS_Y and AS_Z, so you have an AS_PATH that looks like the > following: > AS_X AS_B AS_A > AS_Y AS_B AS_A > AS_Z AS_B AS_A > > At this point: > a) There is no *direct* contractual linkage from AS_A to AS_X, Y or Z > ... and, just as importantly, /further beyond AS_X, Y and Z/. > b) Just as importantly, there is no IANA or RIR -- currently! -- that > certifies the contractual linkage between AS_B and AS_X, Y and Z. > > From a contractual PoV, AS_A has very little to do with _who_, beyond > his directly connected transit providers/peers (AS_B and AS_C in this > example), his routes are announced to. Instead, AS_B is contractually > obligated to announce, or not announce, AS_A's routes based on whether > AS_B's connected AS'es are peers or transit providers.[1] (Yes, there > are exceptions like AS_A tagging routes with "NO_EXPORT", but > operationally those are most likely an exception, IMO, intended to > withhold more-specifics ... not 'general' reachability/connectedness). > > I believe this, potentially, ties back to REQ's #3.14 and #4.2 in > draft-ymbk-bgpsec-reqs-00, which (depending on your PoV) either > conflict with each other or REQ #3.14 makes the 'assurances' people > desire in REQ #4.2 not any better than we have in BGP today at AS_PATH > lengths greater than 2. Specifically, let's assume that AS_Z is > contractually a 'peer' of AS_B and that AS_Z has suddenly gone "rogue". > AS_Z is now starting to announce AS_B, (and AS_A), on to AS_Z's > __peers__ (AS_J, not depicted)[2]. AS_Z can sign AS_B's (and, AS_A's) > routes all day long and they'll look "legitimate" from the PoV that a > "recipient of an UPDATE [will know] that that UPDATE has traversed that > AS_PATH in the update". But, and here's the key point: a recipient of > routes from AS_Z shouldn't *really* accept them, correct, because that > AS_Z is breaching their contract with AS_B? Or, to look at it in a > completely different light, what 'value' does a signature provide in > this case compared to today > 's non-signature based AS_PATH? > > In summary, an AS_PATH is more than just a series of "breadcrumbs" on > where an UPDATE has been. In reality, there's a lot of very, very > complicated 'policy' (really, dollars) on where it's _allowed_ to go, > as well, that ultimately matters if you're going to provide assurances > that it's "legitimate" or not. I highly, highly recommend the reqmt's > draft is much, much more clear on what assurances folks are attempting > to make at, for example, various AS_PATH lengths, otherwise the > signatures are likely to be, at best, meaningless. > > -shane > > [1] REQ 3.14 of draft-ymbk-bgpsec-reqs-00 states that a "BGPsec design > MUST NOT require operators to reveal proprietary data ... [that] > includes peering, customer and provider relationships". This seems to > ignore the reality that a recipient would need to know this if you're > going to understand that, for example, a peer should only be sending > you their transit customer's routes ... not their other peer's routes > ... > [2] For the more security-oriented folks in the room, at a very high- > level, peer's only announce their transit customer's routes to each > other. As a peer, you do not announce your other peer's routes on to > other peer's ... > _______________________________________________ > sidr mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/sidr This communication is the property of Qwest and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
