Skip to main content

Early Review of draft-ietf-grow-bmp-15
review-ietf-grow-bmp-15-secdir-early-tschofenig-2015-09-10-00

Request Review of draft-ietf-grow-bmp
Requested revision 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
I-D last updated 2015-09-10
Completed reviews Genart Last Call review of -15 by Vijay K. 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
Request Early review on draft-ietf-grow-bmp by Security Area Directorate Assigned
Reviewed revision 15 (document currently at 17)
Result Has issues
Completed 2015-09-10
review-ietf-grow-bmp-15-secdir-early-tschofenig-2015-09-10-00
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