Comments on draft-ietf-ipsec-rfc2402bis-03.txt based on SEND WG experiences

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

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

Based on our experiences in the SEND WG, I would like
to offer the following comments to the IPSEC WG, regarding
to the AHbis draft.

> 1.  Introduction
>
>  ....
>
>  host.  ESP may be used to provide the same anti-replay and similar
>  integrity services, and it also provides a confidentiality
>  (encryption) service.  The primary difference between the integrity
>  provided by ESP and AH is the extent of the coverage. Specifically,
>  ESP does not protect any IP header fields unless those fields are
>  encapsulated by ESP (e.g., via use of tunnel mode). ...

Comments:

  - Even though the text above is true and correct, it may give a wrong
    impression.  The most important difference is packet size.  If ESP
    is used, it is necessary to copy all the important information from
    the fields that precede ESP into ESP (typically by employing
    tunneling), thereby making the packet larger.  Additionally, if the
    protocols protected by ESP rely on any fields that precede ESP, ESP
    processing should check that the fields within the ESP header and
    the fields outside of it are equal.  This is, by no means, trivial,
    since tunnel mode is not always a solution, depending on context.

    Hence, I would suggest adding the following piece of text:

    It should be noticed that some applications (such as IPv6
    Neighbor Discovery or Mobile IPv6) rely on the integrity of some
    of the fields in the IP header.  Furthermore, using tunnel mode
    may not be an option, since the very precense of a tunnel may
    open attacks.  Finally, the incresed packet size caused by
    tunneling may be unacceptable to some applications.

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

> 3.2  Integrity Algorithms
>
>  The integrity algorithm employed for the ICV computation is specified
>  by the SA.  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.).  For multicast
>  communication, a variety of cryptographic strategies for providing
>  integrity have been developed and research continues in this area.

Comment:

  - In the current SEND working group proposal, a public key algorithm
    is proposed to be used even for point-to-point communication.
    However, this probably does not warrant changing the text above.

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

> 3.4.2  Security Association Lookup
>
>  ....
>  document.)  The SAD entry for the SA also [...]
>  indicates the key required to validate the ICV.

Comment

  - In the current SEND WG proposal, the SA does not indicate the key
    to be used.  Instead, the AH header itself contains the public
    key.  However, I don't know if the text above should be changed.

--Pekka Nikander
   SEND WG co-chair