Last Call Review of draft-ietf-manet-olsrv2-

Request Review of draft-ietf-manet-olsrv2
Requested rev. no specific revision (document currently at 19)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2012-08-22
Requested 2012-08-01
Authors Thomas Clausen, Christopher Dearlove, Philippe Jacquet, Ulrich Herberg
Draft last updated 2012-08-24
Completed reviews Genart Last Call review of -?? by Wassim Haddad
Secdir Last Call review of -?? by Taylor Yu
Secdir Telechat review of -?? by Taylor Yu
Assignment Reviewer Taylor Yu
State Completed
Review review-ietf-manet-olsrv2-secdir-lc-yu-2012-08-24
Review completed: 2012-08-24


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 document's Security Considerations section (Section 23) analyzes
some of the protocol's vulnerabilities, but provides no concrete
actionable advice.  The overall wording in that section suggests
directions for future work, but the document does not describe actual
protocol elements that are capable of providing the needed

Section 23.1 describes confidentiality considerations for the
protocol, but does not explain what situations merit confidentiality
protection for the network topology.  It mentions the possibility of
protecting confidentiality in OLSRv2 by using PGP or shared key
encryption, but provides no indication of how to do so, nor does it
indicate how participants should conduct key management.

Section 23.2 describes integrity considerations.  The text presents
several examples where invalid control traffic may disrupt the
network, and distinguishes the situations where data origin
authentication for the control message is sufficient from situations
that require additional authentication of link states, for example.

Authentication of link states seems potentially complicated, because
it seems that both ends of a link would have to authenticate the
validity of the link between them in a way that third parties could
verify.  This document does not detail how such link validity
authentication would work.

Section 23.2 also mentions thwarting replay attacks using temporal
information, but there are no obvious places for the protocol to carry
such information.

Section 23.2 mentions using IPsec authentication headers for
authenticating entire control packets, but offers no suggestions about
how to perform key distribution.

Section 23.3 describes interactions with external routing domains, and
makes reasonable suggestions.