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.


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


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.

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.