Re: Comments on draft-ietf-ipsec-rfc2402bis-03.txt based on SENDWG experiences

[Stephen Kent <kent@bbn.com>]

At 11:20 AM +0300 6/15/03, Pekka Nikander wrote:
>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.

The extant text is correct. Until SEND has a comprehensive, coherent 
model for using AH that does not require changes to other parts of 
IPsec processing, I think it is appropriate to retain the current 
text.

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

No, it does not.

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

This is not consistent with the IPsec specs! Remember that a protocol 
such as AH is not just syntax; it also encompasses the rules for 
processing packets.  In IPsec, the SAD entry for an SA stores the 
keys that are employed to process packets. In turn, the SAD entry is 
located by using the SPI from an inbound packet (for unicast 
traffic). If SEND wants to use AH then you need to use the protocol 
(including the processing spec) as defined in IPsec, not just the 
syntax from 2402. Suggesting that we change AH to accommodate SEND's 
possible use of it, in a fashion not consistent with the current 
specs, is asking quite a lot.

Steve