[Ipsec] IPsec AH & ESP -- final summary of changes

[kseo@bbn.com]

Folks,

No further comments have been received.  The final consensus re: the 
proposed changes (from 4/25) appears to be:

	1. No changes to the proposal to add back the text re:
	   a default padding scheme (to ESP).

	2. Re: clarification of SAD entry lookup for inbound traffic
	   in the presence of multicast SAs.

	   a. It's OK for Searches (1) and (2) to NOT use protocol
	      (AH or ESP). With unicast SAs, the receiver chooses the
	      SPI and can have separate SPI spaces for AH and ESP if
	      it wishes; but for multicast/etc SAs, a central Group
	      Controller/Key server is assigning the SPIs and will
	      ensure that there is no overlap between AH SPIs and ESP
	      SPIs.

	   b. Searches (1) and (2) will be changed from "destination
	      multicast address" to "destination address".

	   c. Search (3) will be changed to "Search the SAD for a match
	      on only {SPI} if the receiver has chosen to maintain a
	      single SPI space for AH and ESP, and on {SPI, protocol}
	      otherwise".

The resulting changes to the AH and ESP drafts are shown below.

1. ESP -- We propose to put the following text back into Section 2.4. 
(The ESPv2 padding text (Section 2.4) will otherwise remain 
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.)"

2. AH and ESP (and 2401bis)--  We propose to replace 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.

References will be 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.

Thank you,
Karen

_______________________________________________
Ipsec mailing list
Ipsec@ietf.org
https://www1.ietf.org/mailman/listinfo/ipsec