Early Review of draft-ietf-grow-bmp-15

Request Review of draft-ietf-grow-bmp
Requested rev. no specific revision (document currently at 17)
Type Early Review
Team Security Area Directorate (secdir)
Deadline 2015-09-15
Requested 2015-08-20
Authors John Scudder, Rex Fernando, Stephen Stuart
Draft last updated 2015-09-10
Completed reviews Genart Last Call review of -15 by Vijay Gurbani (diff)
Secdir Early review of -15 by Hannes Tschofenig (diff)
Opsdir Last Call review of -15 by Mahesh Jethanandani (diff)
Assignment Reviewer Hannes Tschofenig 
State Completed
Review review-ietf-grow-bmp-15-secdir-early-tschofenig-2015-09-10
Reviewed rev. 15 (document currently at 17)
Review result Has Issues
Review completed: 2015-09-10


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 am not an expert in this field and cannot judge whether the designed protocol makes sense. The content did, however, look complete to me.

The security consideration section talks about different security threats and focused on confidentiality protection quite a bit (but  dismisses it in the end). I would think that authentication and integrity are probably more important in this context. I suspect that a monitoring station will react on information it receives (somehow) and false information could potentially be a problem. How likely is it that an attacker injects false information that will then the processed by a monitoring station (which could be located anywhere)?

Currently, it appears that no specific security solution is mandatory to implement. There are only examples listed, such as IPsec and TCP-AO. (For IPsec I guess you would also use IKEv2 as a key management?) Would it be useful to have one security mechanism mandatory to implement?

The sentence "Implementations of this protocol SHOULD require manual configuration of the monitored and monitoring devices." feels a bit out of context in the security consideration section. I would delete it from the security consideration section or, alternatively, what it implies in terms of security.

The term 'transport' for a security protocol appears incorrect. For example, instead of writing "... users of this protocol should consider using some type of transport that provides mutual authentication, data integrity, and transport protection, ... " you could write "... users of this protocol should consider using a security protocol that provides mutual authentication, data integrity, and confidentiality protection, ... ".

-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium.  Thank you.

ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No:  2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No:  2548782