Hiya, Snipped various bits... On 12/12/2013 12:22 PM, Stewart Bryant wrote: > On 12/12/2013 11:21, Stephen Farrell wrote: >> Stewart, >> >> On 12/12/2013 10:42 AM, Stewart Bryant wrote: >> I'll note that many of the 2119 MUSTs in 3552 aren't >> enforced in practice - generally secdir reviews and >> the like are much more reasonable and try to figure >> out whether or not a draft has done a good enough >> job and those reviews do not include mindless checking >> of boxes as to whether the MUSTs from 3552 have been >> met. I'm sure the same is true for other area reviews >> as well - we're all basically a fairly practical bunch >> who want work to get done and done well, but we don't >> want to build a form-filling bureaucracy. (Well, the >> IETF does have a tendency to wander in that direction >> but then some of us also push back the other way as >> well:-) > Sure, and I think I am looking for considered text in > the BCP that ensures, to be able to "do the right thing". I'd argue its not needed on the basis that the draft just highlights the consensus on this threat but makes no process innovation. But if you want to suggest text... > Please remember, not so long ago, we had a situation > where routing protocols and updates to existing routing > protocols consistently stalled on concerns about > their security. Ok, I get the concern. One could argue that the better routing security we hope to have soon was actually a good outcome though:-) But we don't have to go there. > So, let's go back to the example, or use IPv6 if you prefer, > and explain what technical changes (if any) we would > need to make to it to be able to publish, post the publication > of this BCP, or tell me what an acceptable security > considerations section would look like for the existing packet > design. Honest answer? I don't know. Let's consider source addresses say. I for one would not try to make a case that we could do away with those, nor that we know for sure how to make them less leaky when considered as identifying meta-data, when operating at the scale of the Internet. So for me, its similar to the e2e email security situation, which I understand a lot better. We do know there are issues but I don't think we have a practical mitigation that we could stand over as "the" way to solve either problem. But other folks know a *lot* more about lower layers than me, so what'd happen would likely depend on their analysis of the situation and of what's practical. And that analysis should be done in whatever is the relevant WG and should consider the pervasive monitoring threat. But from what I know, I don't think this BCP as-written could justify blocking say some new IPv6 transition mechanism just because source addresses were leaky assuming that there really is no good mitigation for the transition mechanism in question. If at some point someone does come up with a good practical way to mitigate the threat for a protocol that is being developed or updated then this BCP would call for that mitigation to be seriously considered. And the usual set of judgement calls as to whether or not that has happened would follow. So YMMV as usual. Again, I don't think there's any process change here - sometimes we just don't have good mitigations ready to go, even where we do know a threat exists. And even when we do, or someone claims we do, have a good mitigation the usual engineering analysis and consensus processes are how we figure out what to do. Does that help? S. PS: "hasty" - are you trying to sound like an Ent? :-)