On Mar 14, 2012, at 9:50 PM, Stephen Kent wrote: > At 7:38 PM +0100 3/14/12, Eric Osterweil wrote: >> I'd also like to add that (if I'm not mistaken) much of the BGPSEC work is >> _already_ proposing to "add information to BGP updates." For example, I'm >> pretty sure there aren't any signatures in BGP right now, right? > > The addition of sigs to provide integrity and authentication for AS_path info > does not add new semantics to BGP. The sigs are used to secure the existing > semantics. I think that's what Sandy meant to convey in her message, but > maybe the wording needs to be improved.
Yup, I do think the wording needs some work, thnx for the ack. > >> I don't think this text is completely on the level, because my recollection >> of many of the sidr drafts is that they _ARE_ proposing to add data, >> semantics, and processes to the current operation of BGP. > > New data, yes, new semantics, no. We were heading in that direction with > the "beaconing" mechanism, but that seems to have gone away. So, what happens (for example) when a sig on an update can't be verified? Is an update not processed and applied as it otherwise would be? I guess it seems to me that the semantics of an update have changed if a new portion of that update (the sig) can cause interpretation of the meaning of that update to change (i.e. drop updates with unverifiable sigs, update RIB if the sigs are verifiable). > >> By my reading of the text below, it sounds like we would only add these >> things if we were going to add route leak protection, and that sentiment >> seems wrong to me. > > Add which "things?" When you break the paragraph up, the pronouns are not as easy to associate w/ their common nouns. ;) "Things," was referring to "data, semantics, and processes." > >> Moreover, the text below conflates the need for leak protection with some >> as-yet-unspecified approach that must use inline protocol changes. > > That is a fair observation, i.e., if there is agreement that route leaks > can be defined in a rigorous, unambiguous fashion, then it is appropriate > to explore various ways of detecting them. I think we agree that defining leaks and discussing any mechanisms to remediate them are separate. > >> I don't know that this has been openly agreed to by all (which is fine at >> this stage), but in reaching out to grow w/ this as a starting point I think >> we present both a problem and an unratified straw-man. I think the text >> needs to be clarified. > > I think the message asks IDR to look into this, not GROW. Yup... I had a brain fart. It's been a long week already... :-P > >> >> Also, I'd like to request in the 5th para (or the 6th sentence?): >> s/The consensus in the room was/The consensus in the room (though it is >> not clear what portion of the wg agrees) was/ > > seems like a reasonable edit. Kewl, thanks again for the ack! Eric _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
