Re: [Gen-art] Gen-ART Review of draft-ietf-manet-rfc6622-bis-02

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

Comments below, marked >>>. I think (though I need my co-authors to agree of course) that a draft with these revisions (and any others we need) will be appropriate following any other IETF LC comments.

-- 
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: [e-mail] [mailto:[e-mail]] On Behalf Of Russ Housley
Sent: 14 June 2013 21:24
To: IETF
Cc: IETF Gen-ART; [e-mail]
Subject: Gen-ART Review of draft-ietf-manet-rfc6622-bis-02

----------------------! 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 am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-manet-rfc6622-bis-02
Reviewer: Russ Housley
Review Date: 2013-06-15
IETF LC End Date: 2013-06-27
IESG Telechat date: Unknown

Summary:  The document is almost ready for publication as a
standards track RFC.  I raise one major concern, and once it
is resolved, the document will be ready.

Major Concern:

In Section 12.2.3, is there any difference in processing when the
source IP address is IPv4 as opposed to IPv6?  Obviously, the two have
a different length.  Off the top of my head I cannot find a way for an
attacker to exploit one party using IPv4 in the ICV calculation and the
other party using IPv6.  Since the IPv6 address is 12 octets longer
than the IPv4 address, there may be some opportunity for an attacker.
Anyway, concerns like this are usually thwarted by including the length
of the overall hash function input as the first octet or two of the
value-to-be-hashed.  Such a value does not need to be transmitted.
Each party knows how many octets it passed to the hash function.

>>> As it happens, this value is present in the packet header, but not in the message header, and we do not want to introduce a difference between them. In addition, being after the address might not work.
>>> Like you, I can't see how to exploit and still maintain a legal structure following, but attackers can be very resourceful. and I don't see that this can be guaranteed.
>>> Thus, this appears a good suggestion, with minimal computational overhead and no over the air overhead.


Minor Concerns:  

I find Section 1.1 a bit confusing.  I think it should start by saying
that RFC 6622 defined two ICV TLV extension types (0 and 1).  This
document repeats those definitions and adds a third ICV TLV extension
type (2).

>>> OK.

Section 5 says:

  An ICV TLV with type extension = 2 specifies a modified version of
  this definition.
 
This is unclear.  I believe that an ICV TLV with type extension = 2 is
an update to ICV TLV with type extension = 1.  It would be good to
introduce the need for this update.  I suggest:

  An ICV TLV with type extension = 2 is the same as an ICV TLV with
  type extension = 1, except that the integrity protection also covers
  the source address of the IP datagram carrying the packet, message,
  or address block.

>>> Might tweak that a little, but OK.

If you accept this suggestion, the following paragraph should also be
revised.  I suggest:

  Specifically, with type extension = 1 or type extension = 2, the
  <value> field contains the result of combining a cryptographic
  function and a hash function.  The <value> field contains multiple
  sub-fields indicating which hash function and cryptographic function
  have been used as specified in Section 12.

>>> Essentially moving detail from this paragraph to previous one.


********************************************************************
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.
********************************************************************