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 rev. 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
Draft 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 LIU (diff)
Assignment Reviewer Dacheng Zhang
State Completed
Review review-ietf-manet-olsrv2-dat-metric-08-secdir-lc-zhang-2015-11-19
Reviewed rev. 08 (document currently at 12)
Review result Has Issues
Review completed: 2015-11-19

Review
review-ietf-manet-olsrv2-dat-metric-08-secdir-lc-zhang-2015-11-19



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