Don, On Feb 21, 2011, at 12:17 MST, Smith, Donald wrote: > 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?
I purposefully glanced over paid peering, in an attempt to keep things relatively simple (for now), in a meager attempt to figure out what are the requirements with respect to assertions on the "data" contained in an AS_PATH. The concept of paid-peering, etc. may have to be revisited depending on where present conversations lead us. -shane >> [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
