To divert the discussion a bit back into the realm of requirements. What is the current "diameter" of the Internet? From my recollections it was converging toward about 4 ASes in diameter. This would mean that for most paths we have:
AS_A <--> AS_B <--> AS_C <--> AS_D If we have already authenticated the route origin, with either offline or online enforcement depending on your preference, we have cryptographically bound a route object to an aut num. Okay, this is good. This is the current scope of the work. Now it's tougher for people to fake announcements, intentionally or otherwise. This solves a lot of the problem. Now, next step, we're looking at cryptographically signing the AS PATH, but as Russ points out that isn't really what we want, at least I don't think it is. What we seem to be trying to get at is what is to vet the relationship between the ASes in the list. For example, is AS_B really an upstream of AS_A? And it is therefore plausible that they would legitimately want to announce AS_A's routes. Of course, as Shane points out, there is absolutely no way in BGP (nor should their be, IMHO), of expressing the actual relationship between AS_A and AS_B. They could be peers, confeds, paid peers, customers, etc. The requirement seems to be the ability to cryptographically sign an object expressing the relationship between AS_A and AS_B. Is AS_B allowed, by AS_A, to announce AS_A's routes? BGP seems impractical as a mechanism, however, we could use RPSL to do this. We simply offer the origin AS, in this case AS_A, an option to express it's commercial relationship with its upstreams (or vice versa). It can say "AS_B" can announce these routes, AS_Q can announce these, etc. Yes, this does require that we announce "confidential" information, but, being realistic, anyone can figure most of this out by looking at a routing table. Given the small diameter, then we've solved 90% of the problem, as we only have to then trust the big carriers in the core. If AS_B and AS_C are Level 3 and Verizon, we can be reasonably assured that they will get things right more often than not. They've been doing this a while, and tend to know what they are doing. There is strong commercial pressure not to blow it, and become subject to an attack or a highly visible misconfiguration. Andrew On Feb 22, 2011, at 8:40 AM, Sandra Murphy wrote: > Randy, please do not indulge in ad-hominem attacks. It does nothing to > help in finding the right answer. > > --Sandy > > On Tue, 22 Feb 2011, Randy Bush 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. >> >> they were. you are dealing with a one man dos. do not feed the troll. >> >> randy >> _______________________________________________ >> sidr mailing list >> sidr@ietf.org >> https://www.ietf.org/mailman/listinfo/sidr >> > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
