Last Call Review of draft-farrell-perpass-attack-03
review-farrell-perpass-attack-03-opsdir-lc-romascanu-2014-01-23-00

At the request of the OPS ADs I have performed a second OPS-DIR review of
draft-farrell-perpass-attack-05.txt.



This document does not define a new protocol and does not extend an existing
protocol, so the guidelines defined in RFC 5706 do not apply strictly. However
it provides a significant clarification concerning the way pervasive monitoring
is to be treated and recommendations for mitigation that will impact the
writing and reviewing of the future protocol documents.



This document targets BCP status, although it’s not a usual BCP but more like a
high level policy document, and the intended status was questioned during the
various reviews and discussions this document underwent. I do not have a strong
opinion on this matter, it does not change anything from the OPS perspective,
excepting the fact that probably BCP rather than Informational makes a clear
indication about the urgency of the matter from the perspective of the IETF
community.



The principal impact that this document has on operations and management of the
IETF protocol is included in the following paragraph in Section 2:



   While PM is an attack, other forms of monitoring can be beneficial

   and not part of any attack, e.g. network management functions monitor

   packets or flows and anti-spam mechanisms need to see mail message

   content.  Some monitoring can even be part of the mitigation for PM,

   for example Certificate Transparency [RFC6962] involves monitoring

   Public Key Infrastructure in ways that could detect some PM attack

   techniques.  There is though a clear potential for monitoring

   mechanisms to be abused for PM, so this tension needs careful

   consideration in protocol design.  Making networks unmanageable to

   mitigate PM is not an acceptable outcome, but ignoring PM would go

   against the consensus documented here.  An appropriate balance will

   emerge over time as real instances of this tension are considered.



The text above was carefully crafted and debated during the various reviews I
believe that it is OK as it is, but the OPS community should debate whether
work is necessary in the area (maybe in the OPSEC WG) in order to look at the
following aspects:

-



Issue recommendations that could help protect the tools (applications,
protocols, data repositories) used by operators for the day to day tasks or
running and managing the networks from being used for pervasive monitoring (in
the words of the document – how can we make sure in practical terms that useful
monitoring mechanisms are not abused for PM?)

-



Review the existing protocols designed in the OPS area which have broad
deployment and make sure that they have been designed in such a manner that the
threat of a pervasive monitoring attack can be mitigated. If necessary (gaps
were found out) issue recommendations for ‘ruggedizing’ these protocols against
PM attacks



A few more observations:



-



In Section 2 the following sentence is IMO not clear enough: ‘It means that, if
asked, there needs to be a good answer to the question "is pervasive monitoring
relevant to this work and if so how has it been considered?"’ Who asks? Is this
about the IESG reviews, or maybe about some kind of privacy assessment (done by
whom?)

-



I found too little relation between this document and RFC6973. That
Informational RFC provides actually a set of good recommendations on mitigation
for privacy issues, many of them directly applicable against PM threats. It is
also a very recent document, published only six months ago. It seems odd that
the information[RFC6973] is mentioned only once and in an unclear way – the
reference is just written in brackets between two sentences, not clear if it
belongs to the sentence before or the sentence after.



Regards,



Dan