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