[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Comments on draft-ietf-ipsec-rfc2402bis-03.txt based on SEND WG experiences
- To: email@example.com
- Subject: Comments on draft-ietf-ipsec-rfc2402bis-03.txt based on SEND WG experiences
- From: Pekka Nikander <firstname.lastname@example.org>
- Date: Mon, 16 Jun 2003 10:31:54 +0300
- In-Reply-To: <email@example.com>
- References: <firstname.lastname@example.org>
- Sender: email@example.com
- User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.3) Gecko/20030312
[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). ...
- 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.
- 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.
- 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.
SEND WG co-chair