Re: some concerns about last IKEv2 draft

[Karen Seo <kseo@bbn.com>]

Francis,

Thank you for catching these problems.  We've submitted a revised 
draft to the IETF secretariat with the changes listed below.  These 
have been approved by Russ Housley with the observation that "... 
this puts a normative reference on 2401bis, so it will not be 
published as an RFC until 2401bis is published."

Thanks again,
Karen

>  - in 2.6  Integrity Check Value (ICV):
>
>    This is a variable-length field that contains the Integrity Check
>    Value (ICV) for this packet.  The field must be an integral multiple
>    of 32 bits (IPv4) or 64 bits (IPv6) in length.
>
>  => the wording is very misleading: one can interpret it as an ICV length
>     of 96 bits is illegal for IPv6 (when this is the currently used length
>     for IPv4 and IPv6 AH and 3.3.3.2.1  ICV Padding gives this for example).
>     IMHO the constraint is for the whole extension, the ICV has only to
>     be on a multiple of 32 bits.

	The text noted above has been changed to:

	"This is a variable-length field that contains the Integrity
	Check Value (ICV) for this packet.  The field must be an
	integral multiple of 32 bits (IPv4 or IPv6) in length.

	The paragraph also already says:

	"This field may include explicit padding, if required to
	ensure that the length of the AH header is an integral
	multiple of 32 bits (IPv4) or 64 bits (IPv6)."

>  - 3.1.2 Tunnel Mode: this section doesn't suggest the outer header can
>    use IPvX when the inner is IPvY with X != Y. IMHO we have only to confirm
>    that IPv6 over IPv4 and IPv4 over IPv6 are legal in tunnel mode.
>    I notice this because the lack of "crossed" IP versions in tunnel mode
>    comes just after the spuirous check of the outer source address in interop
>    issues in common implementations...

	To avoid delays and consolidate info that's common between AH and
	ESP, we will note in 2401bis that one can mix and match v4 and v6
	in constructing inner and outer tunnel headers.

>  - 3.1.2 Tunnel Mode: the legend:
>            * = construction of outer IP hdr/extensions and modification
>                of inner IP hdr/extensions is discussed below.
>
>    refers to a discussion which is not convincing:
>
>    In tunnel mode, the outer and inner IP header/extensions can be
>    inter-related in a variety of ways.  The construction of the outer IP
>    header/extensions during the encapsulation process is described in
>    the Security Architecture document.
>
>  => I suggest to use the same legend than in ESP-v3:
>
>             * = if present, construction of outer IP hdr/extensions and
>                 modification of inner IP hdr/extensions is discussed in
>                 the Security Architecture document.

	Done.

>- 3.2  Integrity Algorithms: there is a missing closing parenthesis.

	Changed second sentence from:

	For point-to-point communication, suitable integrity
	algorithms include keyed Message Authentication Codes (MACs)
	based on symmetric encryption algorithms (e.g., AES [AES] or
	on one-way hash functions (e.g., MD5, SHA-1, SHA-256, etc.).

	To:

	For point-to-point communication, suitable integrity
	algorithms include keyed Message Authentication Codes (MACs)
	based on symmetric encryption algorithms (e.g., AES [AES]) or
	on one-way hash functions (e.g., MD5, SHA-1, SHA-256, etc.).