Hi Sandy, Reply is inline.
On Feb 23, 2011, at 2:52 AM, Sandra Murphy wrote: > On Tue, 22 Feb 2011, Andrew Lange wrote: > >> 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. > > "Plausible" is a rather weak security property. Is that your > recommendation of what you want out of a secure solution from this working > group? Given the thread, I can understand your frustration. And, I could have made myself more clear. I'll try: given the policies that AS_B might be implementing, we cannot know for certain, without AS_B publishing their policies, if AS_B should in fact be announcing which of AS_A's routes or in what form, hence the use of the term "Plausible." I agree "Plausible" is not security property, but a business/routing policy. From a work item perspective, it would be useful to have a relationship object signed that says "I'm AS_A, and I have AS_B and AS_Q as legitimate connections." This information, combined with AS_A's signed route-objects means that downstream ASes would be able to verify that a route 1.2.0.0/16 coming in with an AS PATH of [AS_A, AS_B] or [AS_A, AS_Q] would be AS PATHs that could be authorized. Effectively solving the Origin + Upstream issue would solve most of the problems. Yes, someone could then spoof an announcement of origin+upstream+self, but then we're looking at a minimum of a 3-AS path and the likelihood of that being best drops. We can also do this with a simple route-filter and does not require on-system crypto calculations. Andrew > --Sandy > >> >> 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
