Speaking as regular ol' wg member: Thanks for all of this John. Excellent thoughts.
>Philosophically, the thing that makes me worry the most is that we're >cutting out one of BGP's fundamental elements and replacing it with one >which provides only a subset of its semantics. Specific things missing >include: I'm very interested in exploring semantics of the AS_PATH that the signature attribute does not capture. As for the particular uses you note: > >- Confederations. But we are discussing ways to fix this. >- Extensibility to include new segment types. In principle this is a fairly >serious omission, but one can argue that new segment types can't be >introduced in practice, since existing implementations will treat them >as fatal errors. As you note, there was a good discussion at the Apr 30 interim about confederations. We probably need to document it, a minor question being where it belongs (what document). About extensibility - as you say, any new segment type not built into implementations would result in fatal errors. So any new segment type would need to be built into implementations before use. The question then becomes - can the signature attributes also be augmented at the same time to deal with the new segment types? If a new segment type has a trust model, then there could be a simultaneously developed new security attribute to protect it. If the new type's trust model matches the existing AS_PATH trust model, then new protections could be a new type or version of the existing signature attribute. So the AS_PATH extensibility could be maintained in the security protections - as long as the new extension is "protectable". >The other issue is one Shane already brought up on this thread -- >the fact that some of the more egregious AS_PATH editing hacks >that exist in the wild may not be supportable in the AS_PATH-less >new world order. I am quite sure I don't know the complete list of AS_PATH knobs! But some of those I do know are hacks that would allow attacks as well. The fact that the security protections prohibit the attacks is a good thing. If there's a way to identify good, not evil, uses, then we can design for that. But in cases where there's no real way to distinguish the good from the evil, we're in a hard place. Shoot a hole in the protection to allow the hack or prohibit the hack. --Sandy, speaking as regular ol' wg member ________________________________________ From: [email protected] [[email protected]] on behalf of John G. Scudder [[email protected]] Sent: Tuesday, May 29, 2012 2:21 PM To: Matt Lepinski Cc: [email protected] list Subject: Re: [sidr] request for agenda items for interim meeting 6 Jun On May 22, 2012, at 5:46 PM, Matt Lepinski wrote: > Other than confeds are there any other potentially open issues related to the > removal of AS_Path? (I think this just recapitulates what I said at the interim, but maybe it's worth saying again for the list.) Philosophically, the thing that makes me worry the most is that we're cutting out one of BGP's fundamental elements and replacing it with one which provides only a subset of its semantics. Specific things missing include: - Confederations. But we are discussing ways to fix this. - Extensibility to include new segment types. In principle this is a fairly serious omission, but one can argue that new segment types can't be introduced in practice, since existing implementations will treat them as fatal errors. And actually, that's it for my list of specifics. I think we can check off the "done, in principle" box for confeds. So the remaining issue is extensibility. One may or may not find the "extensibility doesn't work anyway" argument compelling, I'm not entirely sure *I* do. In any case, I think this deserves a good airing before we commit. The other issue is one Shane already brought up on this thread -- the fact that some of the more egregious AS_PATH editing hacks that exist in the wild may not be supportable in the AS_PATH-less new world order. (Many of the less egregious ones seem to be OK with appropriate pcount gyrations.) The pros and cons are a bit slippery here since even if we continue to carry AS_PATH, if the BGPSEC_Path_Signatures attribute can't represent the semantics of what's in that AS_PATH, then validation will fail. But at least there's scope for a network operator on the receiving end to tolerate the validation failure and use the route anyway, if desired. In the case where there's no AS_PATH, the data are just gone with no chance for appeal. It's also worth noting that leaving AS_PATH in would not be without cost. In the cases where the content of AS_PATH is isomorphic to that of BGPSEC_Path_Signatures, there's no problem -- but in those cases AS_PATH clearly could have been left out. In the remaining cases, what is the implementation supposed to do? It would be necessary to carefully specify. The easiest cop-out would be to say that in all such cases, the route fails validation. But I have a feeling that it's not that easy. Leaving AS_PATH out reduces that particular maze of twisty passages, although it replaces it with another: making sure it was really OK to axe AS_PATH to begin with (i.e., the discussion above). I'm going to forward this to IDR to ensure that those who aren't following SIDR are aware there's a proposal to phase out AS_PATH in favor of a simplified replacement in BGPSEC. --John _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
