Minor comments to draft-ietf-ipsec-esp-v3-05.txt

[Pekka Nikander <pekka.nikander@nomadiclab.com>]

[Resending to the list, the original did not get through.]

Barbara Fraser wrote:
> This is a working group last call for comments on the following drafts, 
> for progression to Proposed Standard:
> 
> ...
> draft-ietf-ipsec-rfc2402bis-03.txt

Enclosed a set of minor comments to the rfc2402bis draft.

I am reviewing the draft from the SEND WG point of view, and
these comments are ones that do involve any SEND specific issues.
However, even though these are really minor, they are not purely
editorial, and may have some WG interest.

I will shortly send another set of comments, more from the SEND WG
point of view.

--Pekka Nikander
   SEND WG co-chair



> 2.2  Payload Length
> 
>    This 8-bit field specifies the length of AH in 32-bit words (4-byte
>    units), minus "2".  (This means of expressing the length of AH was
>    selected to allow its use as an IPv6 extension header. Thus the
>    length computation is consistent with the algorithm described in RFC
>    1883.)  In the case of an integrity algorithm that yields a 96-bit
>    authentication value, plus the 3 32-bit word fixed portion, this
>    length field will be "4". See Section 2.6, "Integrity Check Value
>    (ICV)", for comments on padding of this field, and Section 3.3.3.2.1
>    "ICV Padding".

Comments: 

 - Shouldn't the reference to RFC1883 be replaced with a reference
   to RFC2460, or better, to [DH95]?

 - It is probably far too late to change this, but all the other 
   IPv6 extension headers define the length in 8-octet units, 
   not 4-byte units.  If possible, it *would* be desirable to 
   update this for IPv6.  However, I fully understand that such
   a change may not be possible at this late in standardization.
   (This comment may be ignored, as it most probably has been
    extensively discussed in the past by the WG.)

 - For IPv6, there should be a requirement that the length MUST
   be integral in 8-octet units, i.e., that the length must be
   evenly divisible by two.  The requirement for that does exist
   in 3.3.3.2.1, but it would be good to briefly repeat it here.

   Suggestion:  Insert the following text before "See Section 2.6"

     For IPv6, the total length of the header must be a multiple of
     8-octet units.  

--------------

> 2.3  Reserved
> 
>    This 16-bit field is reserved for future use.  It MUST be set to
>    "zero." (Note that the value is included in the ICV calculation, but
>    is otherwise ignored by the recipient.)

Comments:

 - Why is the value of the field defined as it is?  The more usual
   wording seems to be 'MUST be set to "zero" by the sender, and
   SHOULD be ignored by the recipient'.  The effect of the text above
   is the same, but someone may try to read it is the value must
   always be zero, and e.g. implement a firewall that drops packets
   where it is non-zero.

   Suggestion:  Replace with the following text.

     This 16-bit field is reserved for future use.  It MUST be set to
     "zero" by the sender, and it SHOULD be ignored by the recipient.
     (Note that the value is included in the ICV calculation, but is
     currently otherwise ignored by the recipient.)

--------------

> 3.3.3.1.2.1  Base Header Fields
> 
>    The IPv6 base header fields are classified as follows:
> 
>    Immutable
>              Version
>              Payload Length
>              Next Header (This should be the value for AH.)

Comments:

 - The note in the paranthesis is both unnecessary and misleading,
   as there may well be intevening extension headers.  

   Suggestion:  Remove the text in paranthesis.

--------------

>    [DH95]    Deering, S., and B. Hinden, "Internet Protocol version 6
>              (IPv6) Specification", RFC 1883, December 1995.

Comments:

 - Should this be replaced with a reference to RFC 2460?

   Suggestion: Replace with a reference to RFC2460.