While I am enjoying our rendition of Mr. Toad's Wild Ride (i.e. the meanderings of this thread, http://en.wikipedia.org/wiki/Mr._Toad%27s_Wild_Ride#Disneyland_version ), I suspect others on the list may be growing tired of it. I will try to prune my blow-by-blow to just what seems important:
On Mar 21, 2012, at 2:06 PM, Stephen Kent wrote: > At 10:48 PM -0400 3/20/12, Eric Osterweil wrote: >> On Mar 20, 2012, at 4:50 PM, Stephen Kent wrote: >> ... >> >> > Let me try another, more concise phrasing. When one adds secruity to a >> > protocol, the goal is to enable it to operate in a hostile environment >> > with the same semantics that it offered in a non-hostile environment. Of >> > course a secure version of a protocol will exhibit some differences in its >> > operation from an insecure version, especially when one compares the two >> > version in attacks scenarios. >> >> Exactly! This is exactly what a semantic difference is! :) > > I think I see how we disagree. Historically (here comes those annoying 30+ > years of experience again) designers of most protocols have not considered > how assumed a benign (or at least non-adversarial) environment for protocol > operation. In the today's world that is not a good assumption. So, when we > add security mechanisms to a protocol to try to allow it to operate > successfully in a hostile environment, one ought to expect the behavior to > differ in attacks scenarios. I assert that this does not change the > semantics, because protocol behavior outside of the benign environment was > out of scope for the non-secure protocol design. How about we turn this around with a simple question: Suppose two different feasible paths are being evaluated for a single prefix/origin pair and one was delivered via a signed bgpsec update, and the other was delivered via an unsigned update. What annotations/influencers/considerations/etc. does the bgpsec design suggest when the router is making its path selection between these two? > >> >>> The relevant question is whether the fundamental nature of the protocol is >>> altered by the addition of security. >> >> That may be a question you care about... It might even be one that the rest >> of us care about, but that is different than claiming you have not added >> semantics (which is where this started). This comment is changing the >> subject. > > OK, where we started, to be brutally honest, was an attempt by you and Brian > to find a way for Brian's proposal on route leaks to be considered in scope > for SIDR. The SIDR charter is clear about the scope, and route leaks are not > part of what we are currently chartered to do. So we really ought not be > having this discussion. I'll do my part to help, by not replying to further > messages on this topic. *sigh* This again? You have to be kidding me... 1) I have no involvement w/ Brian's route leak work. 2) Honestly, if I _were_ involved in Brian's work, I would be happy to announce it, and I would have asked to be listed as a coauthor. I really don't think there would be any value in pretending _not_ to be involved, as I have always felt that my ideas stand on their own merit. I don't hide my involvement in ideas. :) Why not keep the discussion on topic for a while? > >> > And, yes, maybe it is just you. >> >> Or maybe a line of thought (``thinking'' as you put it) that has gone >> unchanged in over 30 years is overdue for having its assumptions challenged. >> Security (in particular) is a field in which the landscape changes, and >> stale vision can lead to myopia... Many things in the Internet security >> theater have obviously changed in 30 years, so the age of lessons does not >> necessarily correlate with their relevance. :) > > Your comment suggests that no wisdom has accrued, at least to me, with 30 > years of experience. I beg to differ. When someone proposes an approach that > has been proposed and rejected previously, I usually ask myself "why did we > reject this before, and what has changed that might make the decision be > different this time?" Usually the answer is that the reasons for rejecting > an approach are still valid, but the proposer of the "new" approach was > unaware of the history. On some occasions the answer is yes, we ought to > revisit the decision (which may of may not still be correct). I am fortunate > to have had firsthand experiences over the last 3 decades that allow me to > have this perspective. ``Wisdom ceases to be wisdom when it becomes too proud to weep, too grave to laugh, and too selfish to seek other than itself.'' -- Kahlil Gibran I (for one) certainly respect experience, but I don't think it should earn a blank check. If the approach is so sound, it should stand on its own technical merit without needing to be vetted by the pedigree of its designer, right? ;) Eric _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
