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

["Dearlove, Christopher (UK)" <[e-mail]>]

Note, this is a personal comment, not the collected opinions of the authors.

Thanks you for re-reviewing.

With regard to the final correction, I think neither version is good. I think the original meant to say reject it as having the status valid, the replacement is saying reject it, it has the status invalid. I think a third wording (I'm not proposing a candidate here) would be better.

With regard to RFC 6622, I should note that I'm not an author of it. But from the perspective of OLSRv2, I can only comment that it was accepted by the IESG. Stressing the speaking personally, I would be happy to reference, or not reference, it.

There are good reasons why security functionality is separated out, essentially because (as is commented on in the security considerations section) there are a wide range of circumstances that ad hoc networks are used in. To name but two, there are obviously different requirements (including key management approaches) in a community Wi-Fi network, and a military application such as a group of soldiers. It would be, for the people who will use the protocol, wrong to even consider putting a "one size fits all" mechanism for signatures, timestamps, or (probably especially) key management into the routing protocol.

-- 
Christopher Dearlove
Senior Principal Engineer, Communications Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: [phone] |  Fax: [phone]
[e-mail] | http://www.baesystems.com

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687

-----Original Message-----
From: Tom Yu [mailto:[e-mail]] 
Sent: 10 October 2012 23:58
To: [e-mail]; [e-mail]; [e-mail]
Subject: secdir re-review of draft-ietf-manet-olsrv2-16

----------------------! WARNING ! ----------------------
This message originates from outside our organisation,
either from an external partner or from the internet.
Keep this in mind if you answer this message.
Follow the 'Report Suspicious Emails' link on IT matters
for instructions on reporting suspicious email messages.
--------------------------------------------------------

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]


********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************