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 sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
