Last Call Review of draft-ietf-soc-overload-control-14

Request Review of draft-ietf-soc-overload-control
Requested rev. no specific revision (document currently at 15)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2013-12-23
Requested 2013-12-12
Authors Vijay Gurbani, Volker Hilt, Henning Schulzrinne
Draft last updated 2014-01-16
Completed reviews Genart Last Call review of -14 by Brian Carpenter (diff)
Genart Telechat review of -14 by Brian Carpenter (diff)
Secdir Last Call review of -14 by Joseph Salowey (diff)
Assignment Reviewer Joseph Salowey 
State Completed
Review review-ietf-soc-overload-control-14-secdir-lc-salowey-2014-01-16
Reviewed rev. 14 (document currently at 15)
Review result Has Issues
Review completed: 2014-01-16


I have reviewed this document as part of the security directorate's 
ongoing effort to review all IETF documents being processed by the 
IESG.  These comments were written primarily for the benefit of the 
security area directors.  Document editors and WG chairs should treat 
these comments just like any other last call comments.

I think this document is ready with some minor issues. 

First I like what you have done with the security considerations section.  It defines the attacks of concern in a clear way and describes some mitigations.  

1.   The security considerations section mentions several mitigations for false overload control messages including TCP, Websockets, BCP-38 and TLS.   While TCP and Websockets provide more protection than UDP its not clear to me that they are providing sufficient protection.   In addition, it seems that BCP-38 should be encouraged in all cases (not just the TLS case).   I'd feel better about the recommendation if it stated some thing like "TCP and Websockets in conjunction with BCP-38 make it more difficult for an attacker to insert or modify messages,  but it is still possible depending on where the attacker is positioned in the network.  TLS provides better protection from an attacker that has access to the network link."

2.  Some privacy considerations are mentioned in section 5.3.  Its not really clear to me what these considerations are so it would be good to expand upon them in the security considerations section.  

3.  Is it possible that some of the oc-agorithms might have their own security considerations.  If this is likely then it might be good to indicate the reader should check to see if the individual algorithm specifications security considerations. 

4.  Is there any mitigation for the attack involving a proxy that does not support mechanism from blindly forwarding an attacker's oc headers?