Apololgies, I had some cut-and-paste incompetence in the example text I sent, here's a retry: "The target of pervasive monitoring attacks on the Internet is not the Internet protocols themselves, but it is the users of the protocols and the general utility of the Internet itself as a medium of communications for specific applications that are monitored. The protocol mitigations that are useful need to be applied in ways that benefit the user-oriented applications, and not necessarily other protocols in the network such as those that may be used for network management, measurements, services not linked to specific users and groups, control plane functions, or some machine-to-machine or sensor communications, for instance. IETF protocols need to assess the threat that pervasive monitoring poses to their users and usage models on a case-by-case basis, and implement appropriate mitigations, if any." On 12/5/2013 12:26 PM, Wesley Eddy wrote: > On 12/4/2013 8:09 AM, Stephen Farrell wrote: >>> >>> It is good to have the consensus recorded in a document like this, >>> but I think the current draft is too vague to be usefully cited >>> and not just abused as a club against ourselves in the future. >> >> That's a fair comment, and there are at least two ways one could >> have gone about documenting the consensus - the "bare" approach >> taken in this draft or one where we included many more details >> of the threat and mitigations. >> >> ... > > > Ok; thanks for explaining, and I buy your motivations. > > >>> - examples of instances and general cases where incorporating >>> mitigations is not a concern >> >> Hmm. Trickier. See below. >> > > > I decided I can live without this, assuming there is at least some > clear recognition included that this BCP is intended to inspire the > IETF to think about pervasive monitoring in its protocol designs, > and do at least a few things to improve the state of the art, but > that it is not to be used as a club to force every new RFC to have > some mandatory-to-implement anti-snooping capability. > > I have a couple pieces of suggested text helping with this below > that you might consider if you understand my concern. > > As a start, I would suggest we be clear that this is not an attack > against the protocols, but rather against the users. It's not > causing the protocols to break, cease to function, give incorrect > results, etc. Mitigating it, then depends on assessing for a given > protocol (or deployment), who the users are and what they're using > it for. SNMP or NTP probably don't need mitigations for pervasive > monitoring, for instance. So, maybe it would be good to have a > clear statement in Section 2 like: > > "The target of pervasive monitoring attacks on the Internet is > not the Internet protocols themselves, but it is the users of > the protocols and the general utility of the Internet itself as > a medium of communications for specific applications that are > "IETF RFCs already contain a mandatory 'Security Considerations' > section intended for discussion of the threats and available > mitigations relevant to the technologies described in the RFC. > As a type of potential attack, if pervasive monitoring is > relevant to a particular protocol, then the threat that it poses, > and the available mitigations are expected to be considered in > new IETF work. It is possible for certain technologies that > pervasive monitoring may not be viewed as a significant > threat."monitored. The protocol mitigations that are useful need to > be applied in ways that benefit the user-oriented applications, > and not necessarily other protocols in the network such as those > that may be used for network management, measurements, services > not linked to specific users and groups, control plane functions, > or some machine-to-machine or sensor communications, for instance. > IETF protocols need to assess the threat that pervasive monitoring > poses to their users and usage models on a case-by-case basis, and > implement appropriate mitigations, if any." > > >> Personally, I think its important that we not have this BCP have >> a massive get-out-of-jail clause that effectively neuters the >> impact we want it to have. And I'd be worried that the kind of >> text you're implying might have that effect. (Or did you mean >> something else?) >> >> But I do think this is an important discussion for the IETF LC. >> > > > Understood, and I agree. Probably, rather than a "get out of jail" > clause, what I think we should clarify is that this attack could > merely be considered another piece that's part of the security > considerations we already produce to explain on a case-by-case basis > what mitigations are available for the perceived threats of a given > protocol and its envisioned usages. > > >>> As an example, would we expect MPLS to do anything about >>> pervasive monitoring or can new MPLS extensions keep moving >>> through the IETF without heeding to this BCP? >> >> I don't think this would affect MPLS extensions. (Although I >> did ask about that for the last one that went by the IESG:-) >> I'd love to see some more security mechanisms defined for MPLS. >> It'd be even better if those were likely to be defined. > > > Good that we agree! I think the text that I suggested above, or > something like it, would be helpful in making this clear. > > >>> It's also not clear to me whether it's intended to only apply >>> to protocol behavior "on the wire" or also to logging behaviors, >>> log formats, and other privacy-defeating factors of implementations. >> >> Both, IMO. But in many (though not all) cases our specs are >> silent about what has to be logged. >> > > > Right; and I guess my point is that if we want that to change, > then it should be mentioned here as one type of possible mitigation, > with corresponding tradeoff in the potential log usages by admins > that would need to be made on a case-by-case basis. > > I guess my real point is that when the protocols are privacy-preserving, > but the implementations aren't as careful, then it just shifts the > focus of the attack. > > >>> It specifically says that this is about privacy, and that requires a >>> lot more than just wire protocol work in order to create. I think >>> it would be good to mention these aspects, if this as a BCP will >>> really be referenced by the community in the future. >> >> Thanks for the thoughtful comments, > > > Thanks for writing up this document, so we can record consensus > beyond the simple hum statements. > -- Wes Eddy MTI Systems