[secdir] secdir re-review of draft-ietf-manet-olsrv2-16

[Tom Yu <[e-mail]>]

I have re-reviewed this document, primarily by examining the changes
from the -15 version.  The authors have added references to RFC 6622,
which specifies some protocol elements that could in principle provide
any needed security properties.  These changes relegate most of my
previous concerns to RFC 6622.

Unfortunately, most of my concerns still apply to RFC 6622, which has
already been approved as Standards Track.  I am undecided as to
whether the Area Directors should treat my concerns with RFC 6622 as
reasons to block this document.  It does appear to me that a number of
security aspects of this protocol suite are deferred to possible
future work.  This may even be appropriate, depending on the risk
profile of the likely deployments.

It is not clear to me that RFC 6622 is implementable as written (are
there multiple existing implementations?), because it seems that it
leaves a number of things underspecified.  As an example, although
future specifications that register ICV (integrity check value)
algorithms might resolve these ambiguities, RFC 6622 appears to make
an underlying assumption that it is possible to decompose ICVs as:

      ICV-value = cryptographic-function(hash-function(content))

which is not in general possible.  (HMAC is but one example of how
this assumption is invalid.)  In some cases where it is possible to
make such a decomposition, such as encrypting a hash value using a
symmetric cipher, RFC 6622 does not specify necessary parameters such
as the cipher mode.  (Also, producing a message authentication code by
encrypting a hash value using a symmetric cipher can lead to
forgeries.)

RFC 6622 leaves key management issues unresolved.

In the next to last paragraph of Section 23.2, the word "valid" should
probably be "invalid":

   Failure to
   verify an ICV included can be used as a reason to reject an incoming
   message or packet as "valid", according to Section 12.1 of [RFC6130]

should be

   Failure to
   verify an ICV included can be used as a reason to reject an incoming
   message or packet as "invalid", according to Section 12.1 of [RFC6130]