Skip to main content

Last Call Review of draft-ietf-manet-rfc6779bis-05
review-ietf-manet-rfc6779bis-05-secdir-lc-roca-2016-05-26-00

Request Review of draft-ietf-manet-rfc6779bis
Requested revision No specific revision (document currently at 07)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2016-05-31
Requested 2016-05-05
Authors Ulrich Herberg , Robert Cole , Ian Chakeres , Thomas H. Clausen
Draft last updated 2016-05-26
Completed reviews Genart Last Call review of -05 by Elwyn B. Davies (diff)
Genart Last Call review of -05 by Elwyn B. Davies (diff)
Secdir Last Call review of -05 by Vincent Roca (diff)
Assignment Reviewer Vincent Roca
State Completed
Review review-ietf-manet-rfc6779bis-05-secdir-lc-roca-2016-05-26
Reviewed revision 05 (document currently at 07)
Result Ready
Completed 2016-05-26
review-ietf-manet-rfc6779bis-05-secdir-lc-roca-2016-05-26-00
Hello,

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.

Summary:

 ready

The security considerations section is a carbon copy of that of RFC 6779
published in 2012. The only modification is the addition of a reference to
"Mobile Ad Hoc Network (MANET)".

As explained by the authors, information contained in this MIB is highly
sensitive, both from the security and privacy point of views. This is all the
most true when considering some of the target use-cases (emergency services or
military tactical applications).

If I find this section globally well written. I'm just a bit surprised by the
following sentence:

"It is thus important to control even GET and/or NOTIFY access to these objects



and possibly to even encrypt the values of these objects

 when sending them

over the network via SNMP."

I would rather say that it is essential to encrypt and verify the integrity of
all the SNMP traffic. Here I find the style not sufficiently directive... But
this is a detail.

Cheers,

  Vincent

Attachment:

signature.asc

Description:

 Message signed with OpenPGP using GPGMail