On Mar 15, 2012, at 6:07 PM, Stephen Kent wrote: > At 10:35 PM +0100 3/14/12, Eric Osterweil wrote: >> ... >> >> 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). > > I see your point, but disagree. Let me try to explain. > > Whenever we add secruity mechanisms to a protocol we create new ways to cause > the protocol to fail to forward data, fail to establish a connection, etc. > The model I have long (>30 years) employed is that if the secruity checks > succeed, the protocol should operate as before (i.e., w/o the added secruity > mechanisms), because the environment is seen as benign. If the checks fail, > the protocol should behave differently, e.g., something should fail, because > the environment is now perceived as hostile and the protocol (w/o benefit of > the secruity mechanisms) was not engineered to work properly in a hostile > environment. > > Consider for example the fact that many protocols incorporate an integrity > check. If the check fails, that causes a packet to be dropped. Typically the > integrity check mechanism is not secure against attacks; is just a mechanism > designed to detect benign errors. We frequently introduce crypto-based > integrity mechanisms when we want to counter attacks. Those mechanisms will > cause the protocol to behave differently in attack scenarios, e.g., an > attack that might have yielded a valid checksum will yield an invalid HMAC, > and that will cause a packet to be dropped. This is generally viewed not as a > change to the protocol semantics, but rather an appropriate and natural > effect of operating the protocol in a secure manner. > > I'd like to think that the BGPSEC mechanisms are being developed in a way > that tries to adhere to this paradigm.
This is being pedantic in a case where I do not think it is helpful. You're saying, ``yeah, we changed semantics OUTSIDE of the BGP protocol, so that once _our_ semantics have decided it is ok to proceed, we can let BGP do its thing...'' but the you basically go on to say ``oh yeah, and we put our semantics _in_ BGP (thus changing it), and the results of our process can greatly impact the global routability of BGP... but those aren't changing BGP semantics...'' This falls right into the basic definition of semantics... Also, the caveat that this is >30 year old thinking does not seem convincing of its correctness (maybe that's just 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." > > I read the text before the paragraph was sliced and diced, and I felt that > "things" was ambiguous. Now that the ambiguity is removed, I just disagree > with your reading of the text :-). Well, I'm glad we got that cleared up... ;) > >> . >> >> I think we agree that defining leaks and discussing any mechanisms to >> remediate them are separate. > > separate, but very interdependent. If the definition is squishy, > countermeasures are likely to be messy, at best. Strongly disagree: If a system is repeatedly subverted along a specific attack vector, the fact that you can see evidence of subversion, but you can't model it with a closed form equation or a formal proof does _not_ mean you should withhold the development of protections! That's like saying: I haven't got a formal proof for what a local escalation of privileges is, on my Linux box... I hope Linus comes up w/ a formal definition soon so that I stop getting pwnd! Ignoring route leaks as security threats is ludicrous. If someone _does_ formally define them, then great! Until then, the system is vulnerable and being exploited, and the bgpsec protections will _not_ protect it... If you want evidence that a solution addresses observed problems, then take them on specifically! That is the heart of the foo-sidr-simple-leak-attack-bgpsec-no-help draft: an example of something that we need to fix. tbqh, the thinking that we need to formally define all threats and completely/comprehensively quantify them before we acknowledge and address them is an extremely antiquated way to address the rapidly evolving threatscape, imho... Eric _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
