Skip to main content

Last Call Review of draft-ietf-manet-olsrv2-dat-metric-08
review-ietf-manet-olsrv2-dat-metric-08-secdir-lc-zhang-2015-11-19-00

Request Review of draft-ietf-manet-olsrv2-dat-metric
Requested revision No specific revision (document currently at 12)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2015-11-23
Requested 2015-11-05
Authors Henning Rogge , Emmanuel Baccelli
I-D last updated 2015-11-19
Completed reviews Genart Last Call review of -08 by Paul Kyzivat (diff)
Genart Telechat review of -10 by Paul Kyzivat (diff)
Secdir Last Call review of -08 by Dacheng Zhang (diff)
Opsdir Last Call review of -08 by Will (Shucheng) LIU (diff)
Assignment Reviewer Dacheng Zhang
State Completed
Request Last Call review on draft-ietf-manet-olsrv2-dat-metric by Security Area Directorate Assigned
Reviewed revision 08 (document currently at 12)
Result Has issues
Completed 2015-11-19
review-ietf-manet-olsrv2-dat-metric-08-secdir-lc-zhang-2015-11-19-00

Dear all,

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.

This draft is about a new routing  metro for OLSRv2.

Technical questions/comments:

1) In this draft, “RFC5444 packet” can be found in many places. I didn’t
find the definition of this term. Do you indicate this solution may need to
process a packet which is not specified in OLSRv2?

2) There is a good security consideration section in RFC 7181. Since this
draft is closely related to OLSRv2 (although this work does not specify any new
message or TLV), it will be good to build the security considerations of this
work based upon what has been discussed in RFC7181. For example, maybe the
authors could say ’there will be some new security issues introduced by this
work but not mentioned in RFC 7181, there will be some security issues if we
only use the mandatory security mechanism specified in RFC7181, or our work
does not introduce any additional security issues..

3) This question is about the last
sentence in the security consideration—“The signature scheme described in
[RFC7183] does not protect the additional sequence number of the DAT metric
because it does only sign the RFC5444 messages, not the RFC5444 packet header.”
First of all, there is no signature mechanism specified in RFC7183, only HMAC
is used to protect the message integrity. In addition, the RFC7183 reuse the
process specified in RFC7182 to generate hashes, and so it should be able to
cover the message headers.   Open for discussion.

Editorial:

Section 2:

MAX(a,b) -> MAX(a, b)

Section 3:

The administrator should take care that link layer multicast transmission do
not not have ->  The administrator should take care that link layer multicast
transmission do not have

Section 4:

The routing decision of most operation systems don't take packet size into
account. -> The routing decisions of most operation systems don't take packet
size into account.

Section 7:

with a very slow or very fast linklayer -> with a very slow or very fast link
layer

Cheers

Dacheng