Subject: new versions of IPsec AH and ESP specs

From: Karen Seo <[email-masked]>
Date: Fri, 4 Apr 2003 16:06:52 -0500

Barbara, Ted,

We have submitted revised drafts for AH & ESP with the changes listed 
at the end of this message.
	- draft-ietf-ipsec-esp-v3-04.txt
	- draft-ietf-ipsec-rfc2402bis-02.txt

We believe these revisions address all comments received to-date. So 
we'd like to request that the working group initiate Last Call on 
these two drafts.

Thank you,
Karen

In addition to minor edits for clarity and consistency, typo fixes, 
and updates to dates and references, the following changes were made 
to both AH and ESP (see details below)

	1. The MSEC working group has published an ID that makes it
	   clear that multicast support will require additional changes
	   beyond the demultiplexing and sequence number management
	   changes that were made in the previous versions of these
	   drafts to better accommodate multicast.  Therefore, we have
	   changed the drafts to make whether or not multicast
	   requirements for SA lookup are mandatory, dependent on
	   whether the IPsec implementation supports multicast.  This
	   avoids burdening unicast-only implementations with
	   multicast-related requirements.

	2. To clarify SA lookup for multicast traffic, we removed
	   use of protocol field for SA lookup.

	3. We moved references to mandatory algorithms to a separate
	   document

IP Authentication Header (AH)
=============================

Section 2.4 Security Parameters Index (SPI), Paragraph 2, first 2 sentences

    From:
	IPsec implementations SHOULD be prepared to support both
	unicast and multicast SAs using the following algorithm
	for mapping inbound IPsec datagrams to SAs.  Each entry
	in the Security Association Database (SAD) [KA97a] must
	indicate whether the SA lookup makes use of the source and
	destination IP addresses, in addition to the SPI (and,
	optionally, the protocol field).

    To:
	If an IPsec implementation supports multicast, then it MUST
	support multicast SAs using the following algorithm for
	mapping inbound IPsec datagrams to SAs. (Implementations
	that support only unicast traffic need not implement this
	demultiplexing algorithm.) Each entry in the Security
	Association Database (SAD) [KA97a] must indicate whether
	the SA lookup makes use of the source and destination IP
	addresses, in addition to the SPI. (For multicast SAs, the
	protocol field is not employed for SA lookups.)

Section 2.4 Security Parameters Index (SPI), Paragraph 2, sentence 7

    From:
	For multicast methods that rely only on the destination
	address to specify a multicast group, only the second bit
	would be set to "1," implying the need to use the destination
	address plus the SPI (and, optionally the protocol) to
	determine the appropriate SA.

    To:
	For multicast methods that rely only on the destination
	address to specify a multicast group, only the second bit
	would be set to "1," implying the need to use the destination
	address plus the SPI to determine the appropriate SA.

Section 3.2 Integrity Algorithms, Paragraph 1, last 2 sentences

    Deleted:
	The mandatory-to-implement integrity algorithms are described
	in Section 5 "Conformance Requirements". Other algorithms MAY
	be supported.

Section 3.4.2  Security Association Lookup, Paragraph 1, sentence 3

    From:
	For multicast SAs, the destination address is also employed
	in the lookup (in addition to the SPI and, optionally the
	protocol), and the sender address also may be employed, as
	described in Section 2.4.

    To:
	If an implementation supports multicast traffic, the
	destination address is also employed in the lookup (in
	addition to the SPI), and the sender address also may be
	employed, as described in Section 2.4.

Section 5. Conformance Requirements, Paragraph 1

    From:
	Implementations that claim conformance or compliance with this
	specification MUST fully implement the AH syntax and processing
	described here and MUST comply with all requirements of the
	Security Architecture document.  If the key used....

    To.
	Implementations that claim conformance or compliance with this
	specification MUST fully implement the AH syntax and processing
	described here for unicast traffic, and MUST comply with all
	requirements of the Security Architecture document [KA98a].
	Additionally, if an implementation claims to support multicast
	traffic, it MUST comply with the additional requirements
	specified for support of such traffic. If the key used....

Section 5. Conformance Requirements, Paragraph 1, last sentence

    From:
	A compliant AH implementation MUST support the following
	mandatory-to-implement algorithms:
		- HMAC with MD5 [MG97a]
		- HMAC with SHA-1 [MG97b]

    To:
	The mandatory-to-implement algorithms for use with AH are
	described in a separate RFC, to facilitate updating the
	algorithm requirements independently from the protocol per
	se. Additional algorithms, beyond those mandated for AH, MAY
	be supported.

Section 7. Differences from RFC 2402, Bullet 1

    From:
       o SPI -- modified to specify a uniform algorithm for SAD lookup
	for unicast and multicast SAs, covering a wider range of
	multicast technologies. For unicast, the SPI may be used
	alone to select an SA; for multicast, the SPI is combined
	with the destination address, and optionally the source
	address, to select an SA.  If the receiver (unicast) or the
	multicast controller (multicast) opted to use the security
	protocol (AH) in selecting the SPI, then the security
	protocol is also used in the lookup.

    To:
       o SPI -- modified to specify a uniform algorithm for SAD lookup
	for unicast and multicast SAs, covering a wider range of
	multicast technologies. For unicast, the SPI may be used
	alone to select an SA, or may be combined with the protocol,
	at the option of the receiver. For multicast SAs, the SPI
	is combined with the destination address, and optionally the
	source address, to select an SA.

Section 7. Differences from RFC 2402, new bullet

    Added bullet 3
       o Moved references to mandatory algorithms to a separate document.

IP Encapsulating Security Payload (ESP)
=======================================

2.1 Security Parameters Index (SPI), paragraph 3, sentences 1 and 2.

    From:
	IPsec implementations SHOULD be prepared to support both
	unicast and multicast SAs using the following algorithm for
	mapping inbound IPsec datagrams to SAs. Each entry in the
	Security Association Database (SAD) [KA97a] must indicate
	whether the SA lookup makes use of the source and destination
	IP addresses, in addition to the SPI (and, optionally, the
	protocol field).

    To:
	If an IPsec implementation supports multicast, then it MUST
	support multicast SAs using the following algorithm for
	mapping inbound IPsec datagrams to SAs. (Implementations that
	support only unicast traffic need not implement this
	demultiplexing algorithm.) Each entry in the Security
	Association Database (SAD) [KA97a] must indicate whether the
	SA lookup makes use of the source and destination IP
	addresses, in addition to the SPI. (For multicast SAs, the
	protocol field is not employed for SA lookups.)

2.1 Security Parameters Index (SPI), paragraph 3, sentence 7

    From:
	For multicast methods that rely only on the destination
	address to specify a multicast group, only the second bit
	would be set to "1," implying the need to use the destination
	address plus the SPI (and, optionally the protocol) to
	determine the appropriate SA.

    To:
	For multicast methods that rely only on the destination
	address to specify a multicast group, only the second bit
	would be set to "1," implying the need to use the destination
	address plus the SPI to determine the appropriate SA.

3.2 Algorithms, Paragraph 1, sentences 1 and 2

    From:
	The mandatory-to-implement algorithms are described in
	Section 5, "Conformance Requirements." Other algorithms MAY
	be supported.

    To:
	The mandatory-to-implement algorithms for use with ESP are
	described in a separate RFC, to facilitate updating the
	algorithm requirements independently from the protocol per
	se. Additional algorithms, beyond those mandated for ESP,
	MAY be supported.

3.4.2 Security Association Lookup, Paragraph 1, sentence 3

    From:
	For multicast SAs, the destination address is also employed
	in the lookup (in addition to the SPI and, optionally the
	protocol), and the sender address also may be employed, as
	described in Section 2.1.

    To:
	If an implementation supports multicast traffic, the
	destination address is also employed in the lookup (in
	addition to the SPI), and the sender address also may be
	employed, as described in Section 2.1.

Section 5. Conformance Requirements, Paragraph 1, sentence 1

    From:
	Implementations that claim conformance or compliance with this
	specification MUST fully implement the ESP syntax and processing
	described here and MUST comply with all additional packet
	processing requirements levied by the Security Architecture
	document [KA98a].  If the key used....

    To.
	Implementations that claim conformance or compliance with this
	specification MUST fully implement the ESP syntax and processing
	described here for unicast traffic, and MUST comply with all
	additional packet processing requirements levied by the Security
	Architecture document [KA98a]. Additionally, if an
	implementation claims to support multicast traffic, it MUST
	comply with the additional requirements specified for support
	of such traffic. If the key used....

5. Conformance Requirements, Paragraph 1, last sentence

    From:
	A compliant ESP implementation MUST support the following
	mandatory-to-implement algorithms:
		- AES (with 128-bit keys) in CBC mode
		- HMAC with MD5 [MG98a]
		- HMAC with SHA-1 [MG98b]
		- NULL Encryption algorithm (RFC 2410)

    To:
	The mandatory-to-implement algorithms for use with ESP are
	described in a separate document, to facilitate updating the
	algorithm requirements independently from the protocol per
	se. Additional algorithms, beyond those mandated for ESP,
	MAY be supported.

7. Differences from RFC 2406, bullet 2

    From:
       o SPI -- modified to specify a uniform algorithm for SAD
	lookup for unicast and multicast SAs, covering a wider
	range of multicast technologies.  For unicast, the SPI may
	be used alone to select an SA; for multicast, the SPI is
	combined with destination address, and optionally the
	source address, to select an SA. If the receiver (unicast)
	or the multicast controller (multicast) opted to use the
	security protocol (ESP) in selecting the SPI, then the
	security protocol is also used in the lookup.

    To:
       o SPI -- modified to specify a uniform algorithm for SAD lookup
	for unicast and multicast SAs, covering a wider range of
	multicast technologies. For unicast, the SPI may be used
	alone to select an SA, or may be combined with the protocol,
	at the option of the receiver. For multicast SAs, the SPI is
	combined with the destination address, and optionally the
	source address, to select an SA.

7. Differences from RFC 2406, new bullet

    Added bullet (This is now the next to last bullet.)

       o Moved references to mandatory algorithms to a separate
	document.