Subject: [Ipsec] resend --> IPsec -- new AH and ESP drafts

From: Karen Seo <[email-masked]>
Date: Tue, 28 Sep 2004 16:49:18 -0400

Folks,

[First version of this email is being held for list moderator due to 
being too long. I accidentally included a bit of non-ASCII text... 
Apologies if you receive both that one and this one.]

We have just submitted new versions of the AH and ESP drafts that 
incorporate the following changes, most of which have been discussed 
on the list or are typo/clarification fixes.  Hopefully, all are 
acceptable to the working group.

Thank you,
Karen

1. AH and ESP -- As discussed Navin Kuma and Sheila Frankel (on the 
IPsec mailing list)... The AH RFC, in section 3.3.3.2.2, exempts MD5 
and SHA-1 from the implicit packet padding requirements, since they 
have their own padding conventions. AES-XCBC-MAC was not defined when 
the AH RFC was written. Thus, implicit padding will be performed per 
the AH RFC, "If the IP packet length (including AH and the 32 high 
order bits of the ESN, if enabled) does not match the blocksize 
requirements for the algorithm. However, the AES-XCBC-MAC RFC, in 
section 4.2, states "with regard to 'implicit packet padding' as 
defined in [AH], no implicit padding is required." We therefore 
propose to remove the exemption for MD5 and SHA-1 and refer folks to 
the documents that define the specific integrity algorithms for 
guidance on how to use the algorithms with AH and ESP, with regard to 
padding.  Thus,

    AH section 3.3.3.2.2, paragraph 2, will change
      From:
	For some integrity algorithms, the byte string over which the
	ICV computation is performed must be a multiple of a blocksize
	specified by the algorithm.  If the IP packet length
	(including AH and the 32 high order bits of the ESN, if
	enabled) does not match the blocksize requirements for the
	algorithm, implicit padding MUST be appended to the end of the
	packet, prior to ICV computation.  The padding octets
	MUST have a value of zero.  The blocksize (and hence the
	length of the padding) is specified by the algorithm
	specification.  This padding is not transmitted with the
	packet.  Note that MD5 and SHA-1 are viewed as having a
	1-byte blocksize because of their internal padding conventions
	and thus no implicit packet padding is required.

      To:
	For some integrity algorithms, the byte string over which the
	ICV computation is performed must be a multiple of a blocksize
	specified by the algorithm.  If the IP packet length
	(including AH and the 32 high order bits of the ESN, if
	enabled) does not match the blocksize requirements for the
	algorithm, implicit padding MUST be appended to the end of the
	packet, prior to ICV computation.  The padding octets
	MUST have a value of zero.  The blocksize (and hence the
	length of the padding) is specified by the algorithm
	specification.  This padding is not transmitted with the
	packet. The document that defines an integrity algorithm
	MUST be consulted to determine if implicit padding is
	required as described above. If the document does not
	specify an answer to this, then the default is to assume
	that implicit padding is required (as needed to match the
	packet length to the algorithm's blocksize.) If padding bytes
	are needed but the algorithm does not specify the padding
	contents, then the padding octets MUST have a value of zero.

    ESP section 3.3.2.1, last paragraph, will change
      From:
	For some integrity algorithms, the byte string over which the
	ICV computation is performed must be a multiple of a block
	size specified by the algorithm. If the length of ESP packet
	(as described above) does not match the block size
	requirements for the algorithm, implicit padding MUST be
	appended to the end of the ESP packet. (This padding is added
	after the Next Header field, or after the high-order 32 bits
	of the Sequence Number, if ESN is selected.) The padding
	octets MUST have a value of zero.  The block size (and hence
	the length of the padding) is specified by the integrity
	algorithm specification. This padding is not transmitted with
	the packet. Note that MD5 and SHA-1 are viewed as having a
	1-byte block size because of their internal padding
	conventions.

      To:
	For some integrity algorithms, the byte string over which the
	ICV computation is performed must be a multiple of a block
	size specified by the algorithm. If the length of ESP packet
	(as described above) does not match the block size
	requirements for the algorithm, implicit padding MUST be
	appended to the end of the ESP packet. (This padding is added
	after the Next Header field, or after the high-order 32 bits
	of the Sequence Number, if ESN is selected.) The block size
	(and hence the length of the padding) is specified by the
	integrity algorithm specification. This padding is not
	transmitted with the packet. The document that defines an
	integrity algorithm MUST be consulted to determine if
	implicit padding is required as described above. If the
	document does not specify an answer to this question, then
	the default is to assume that implicit padding is required
	(as needed to match the packet length to the algorithm's
	blocksize.) If padding bytes are needed but the algorithm
	does not specify the padding contents, then the padding
	octets MUST have a value of zero.

2. AH -- As discussed with Francis Dupont, John Spence, and Jari Arkko (on
    the IPsec mailing list)... The flow label in IPv6 is chosen by the
    source node, and must be delivered to the ultimate destination
    without having been changed in transit. So in theory the flow
    label is "immutable."  However, the flow label was specified in
    detail only by RFC 3697 (published in March 2004).  And there is
    no real need to protect the flow label (see the RFC 3697 security
    considerations for attacks based on altered flow labels). Therefore,
    for compatibility with current IPv6/IPsec implementations, it was
    agreed to keep the current situation, i.e., flow label field *not*
    in "immutable" and to add a comment explaining this to AH (see (*)
    comment below).

    3.3.3.1.2.1  Base Header Fields

    The IPv6 base header fields are classified as follows:

    Immutable
	Version
	Payload Length
	Next Header
	Source Address
	Destination Address (without Routing Extension Header)

    Mutable but predictable
	Destination Address (with Routing Extension Header)

    Mutable (zeroed prior to ICV calculation)
	DSCP (6 bits, see RFC2474 [NBBB98])
	ECN (2 bits, see RFC3168 [RFB01])
	Flow Label (*)
	Hop Limit

      (*) The flow label described in AH v1 was mutable,
	  and in RFC 2460 [DH98] was potentially mutable.
	  To retain compatibility with existing AH
	  implementations, the flow label is not included
	  in the ICV in AH v2.

3. AH and ESP -- As discussed with Andrea Colegrove in private 
communication... ESP does not contain a version number, therefore if 
there are concerns about backward compatibility, they need to be 
managed by a signaling mechanism between the two IPsec peers.  We do 
not require that ESPv2 and ESPv3 interoperate.   So it might be a 
good idea to point out this situation.  This would seem to apply to 
AH as well.  Therefore, we propose to add something along the lines 
of the following text:
	AH Section 2.0, at the end, before Section 2.1
	ESP Section 2.0, at the end, before Section 2.1

    "AH [ESP] does not contain a version number, therefore if there
    are concerns about backward compatibility, they MUST be addressed
    by using a signaling mechanism between the two IPsec peers to ensure
    compatible versions of AH [ESP], e.g., IKE or an out-of-band
    configuration mechanism."

4. AH and ESP -- Francis Dupont brought up the following concern on 
the IPsec list (9/10/03)... We propose to add the sentence "Mixed 
inner and outer IP versions are allowed, i.e., IPv6 over IPv4 and 
IPv4 over IPv6." as shown in the paragraphs below:

    AH 3.1.2 Tunnel Mode

    In tunnel mode, the "inner" IP header carries the ultimate (IP)
    source and destination addresses, while an "outer" IP header
    contains the addresses of the IPsec "peers," e.g., addresses of
    security gateways. Mixed inner and outer IP versions are allowed,
    i.e., IPv6 over IPv4 and IPv4 over IPv6.  In tunnel mode, AH
    protects the entire inner IP packet, including the entire inner
    IP header. The position of AH in tunnel mode, relative to the
    outer IP header, is the same as for AH in transport mode. The
    following diagram illustrates AH tunnel mode positioning for
    typical IPv4 and IPv6 packets.

    ESP 3.1.2 Tunnel Mode Processing

    In tunnel mode, the "inner" IP header carries the ultimate (IP)
    source and destination addresses, while an "outer" IP header
    contains the addresses of the IPsec "peers", e.g., addresses of
    security gateways. Mixed inner and outer IP versions are allowed,
    i.e., IPv6 over IPv4 and IPv4 over IPv6. In tunnel mode, ESP
    protects the entire inner IP packet, including the entire inner
    IP header.  The position of ESP in tunnel mode, relative to the
    outer IP header, is the same as for ESP in transport mode. The
    following diagram illustrates ESP tunnel mode positioning for
    typical IPv4 and IPv6 packets.

5. ESP typo

    3.4.4.2 Combined Confidentiality and Integrity Algorithms

    If a combined confidentiality and integrity algorithm is employed,
    then the receiver proceeds as follows:

          1. Decryps and integrity check the ESP Payload Data,

    "Decryps" should be "Decrypt" and "check" should be "checks"

6. AH & ESP -- Under IKEv2, ESN is the default.  The ESN addendum to 
the ISAKMP DOI doesn't need to be changed.  But to minimize the 
chance of confusion, a sentence should be added to AH and ESP as 
shown below:

      2.5.1 Extended (64-bit) Sequence Number

	To support high-speed IPsec implementations, a new option for
	sequence numbers SHOULD be offered, as an extension to the
	current, 32-bit sequence number field. Use of an Extended
	Sequence Number (ESN) MUST be negotiated by an SA management
	protocol. Note that in IKEv2, this negotiation is implicit; the
	default is ESN unless 32-bit Sequence Numbers are explicitly
	negotiated.
:
      2.2.1  Extended (64-bit) Sequence Number (added last sentence)

	To support high-speed IPsec implementations, extended sequence
	numbers SHOULD be implemented, as an extension to the current,
	32-bit sequence number field. Use of an Extended Sequence
	Number (ESN) MUST be negotiated by an SA management protocol.
	Note that in IKEv2, this negotiation is implicit; the default
	is ESN unless 32-bit Sequence Numbers are explicitly negotiated.

7. ESP -- Reviewed and approved by working group. We put the 
following text back into Section 2.4. (The ESPv2 padding text 
(Section 2.4) is otherwise unchanged.):

	"If Padding bytes are needed but the encryption
	algorithm does not specify the padding contents,
	then the following default processing MUST be used.
	The Padding bytes are initialized with a series of
	(unsigned, 1-byte) integer values.  The first
	padding byte appended to the plaintext is numbered
	1, with subsequent padding bytes making up a
	monotonically increasing sequence: 1, 2, 3, ...
	When this padding scheme is employed, the receiver
	SHOULD inspect the Padding field.  (This scheme was
	selected because of its relative simplicity, ease
	of implementation in hardware, and because it offers
	limited protection against certain forms of "cut and
	paste" attacks in the absence of other integrity
	measures, if the receiver checks the padding values
	upon decryption.)"

8. AH and ESP -- Reviewed and approved by working group.  We replaced 
the current text re: multicast lookup in
	o AH Section 2.4 "Security Parameters Index (SPI)", paragraph 2
	o ESP Section 2.1 "Security Parameters Index (SPI)", paragraph 2

    with the following text:

	"If an IPsec implementation supports multicast, then it MUST
	support multicast SAs using the algorithm below for mapping
	inbound IPsec datagrams to SAs. Implementations that support
	only unicast traffic need not implement this demultiplexing
	algorithm.

	In many secure multicast architectures, e.g., [RFC3740], a
	central Group Controller/Key Server unilaterally assigns the
	group security association's SPI. This SPI assignment is not
	negotiated or coordinated with the key management (e.g., IKE)
	subsystems that reside in the individual end systems that
	comprise the group. Consequently, it is possible that a
	group security association and a unicast security association
	can simultaneously use the same SPI. A multicast-capable IPsec
	implementation MUST correctly de-multiplex inbound traffic
	even in the context of SPI collisions.

	Each entry in the Security Association Database (SAD)
	[Ken-Arch] must indicate whether the SA lookup makes use of
	the destination, or destination and source, IP addresses, in
	addition to the SPI. For multicast SAs, the protocol field is
	not employed for SA lookups. For each inbound, IPsec-protected
	packet, an implementation must conduct its search of the SAD
	such that it finds the entry that matches the "longest" SA
	identifier. In this context, if two or more SAD entries match
	based on the SPI value, then the entry that also matches based
	on destination, or destination and source, address comparison
	(as indicated in the SAD entry) is the "longest" match. This
	implies a logical ordering of the SAD search as follows:

	   1. Search the SAD for a match on {SPI, destination
	      address, source address}. If a SAD entry
	      matches then process the inbound ESP packet with that
	      matching SAD entry. Otherwise, proceed to step 2.

	   2. Search the SAD for a match on {SPI, destination
	      address}. If the SAD entry matches then
	      process the inbound ESP packet with that matching SAD
               entry. Otherwise, proceed to step 3.

	   3. Search the SAD for a match on only {SPI} if the receiver
               has chosen to maintain a single SPI space for AH and ESP,
               or on {SPI, protocol} otherwise. If an SAD
	      entry matches then process the inbound ESP packet with
	      that matching SAD entry. Otherwise, discard the packet
	      and log an auditable event.

	In practice, an implementation MAY choose any method to
	accelerate this search, although its externally visible
	behavior MUST be functionally equivalent to having searched
	the SAD in the above order. For example, a software-based
	implementation could index into a hash table by the SPI. The
	SAD entries in each hash table bucket's linked list are kept
	sorted to have those SAD entries with the longest SA
	identifiers first in that linked list. Those SAD entries
	having the shortest SA identifiers are sorted so that they
	are the last entries in the linked list. A hardware-based
	implementation may be able to effect the longest match
	search intrinsically, using commonly available TCAM features.

	The indication of whether source and destination address
	matching is required to map inbound IPsec traffic to SAs MUST
	be set either as a side effect of manual SA configuration or
	via negotiation using an SA management protocol, e.g., IKE or
	GDOI [RFC3547]. Typically, Source-Specific Multicast (SSM)
	[HC03] groups use a 3-tuple SA identifier composed of an SPI,
	a destination multicast address, and source address. An
	Any-Source Multicast group SA requires only an SPI and a
	destination multicast address as an identifier.

    As part of this change, the references were updated with:

	[RFC3547] Baugher, M., Weis, B., Hardjono, T., Harney, H.,
	"The Group Domain of Interpretation", RFC 3547, July 2003.

	[RFC3740]	Hardjono, T., Weis, B., "The Multicast Group
	Security Architecture", RFC 3740, March 2004.

9. ESP typo

3.3.2.1 Separate Confidentiality and Integrity Algorithms

       4. Compute the ICV over the ESP packet minus the ICV field.
          Thus the ICV computation encompasses the SPI, Sequence
          Number, Payload Data, Padding (if present), Pad Length, and
          Next Header. (Note that the last 4 fields will be in
          ciphertext form, since encryption is performed first.) If
          the ESN option is enabled for the SA, it the high-order 32
          bits of the Sequence Number are appended after the Next
          Header field for purposes of this computation, but are not
          transmitted.

	The last sentence "If the ESN option is enabled for the
	SA, it the high-order 32...." has an extra "it" that
	should be removed.

10. We also updated the boilerplate and Notes sections per the ID-Checklist.

_______________________________________________
Ipsec mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipsec

---

From: "Theodore Ts'o" <[email-masked]>
Date: Tue, 28 Sep 2004 20:53:42 -0400

> Apologies if you receive both that one and this one.]

I've found the mail in the moderation queue and suppressed it since
Karen has resent it w/o the non-ASCII text.

						- Ted

---

From: Paul Hoffman / VPNC <[email-masked]>
Date: Wed, 29 Sep 2004 12:44:55 -0700

These drafts got stuck in the Internet Drafts queue. They are 
temporarily available as 
<http://www.vpnc.org/ietf-ipsec/TEMP-draft-ietf-ipsec-rfc2402bis-09.txt> 
and 
<http://www.vpnc.org/ietf-ipsec/TEMP-draft-ietf-ipsec-esp-v3-09.txt>. 
Those links will be removed with the drafts are officially posted.

--Paul Hoffman, Director
--VPN Consortium