Last Call Review of draft-farrell-perpass-attack-03

Request Review of draft-farrell-perpass-attack
Requested rev. no specific revision (document currently at 06)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2014-01-21
Requested 2014-01-02
Draft last updated 2014-01-23
Completed reviews Genart Last Call review of -03 by Scott Brim (diff)
Genart Last Call review of -04 by Scott Brim (diff)
Genart Telechat review of -05 by Scott Brim (diff)
Secdir Last Call review of -02 by Adam Montville (diff)
Opsdir Last Call review of -03 by Dan Romascanu (diff)
Assignment Reviewer Dan Romascanu
State Completed
Review review-farrell-perpass-attack-03-opsdir-lc-romascanu-2014-01-23
Reviewed rev. 03 (document currently at 06)
Review result Has Issues
Review completed: 2014-01-23


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.