Re: [Ipsec] IPsec AH and ESP -- changes

[Brian Weis <bew@cisco.com>]

Markku Savela wrote:

>I'm wondering about one minor detail in the changed text...
>
>  
>
>>From: kseo@bbn.com
>>    
>>
>
>  
>
>>2. AH and ESP (and 2401bis)-- Thanks go to Suman Sharma and George 
>>Gross for their input re: SAD entry lookup for inbound traffic in the 
>>presence of multicast SAs.  Also, thanks go to George for draft text. 
>>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
>>	compromise 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. ....
>>    
>>
>
>Why is protocol not employed? Protocol is either AH or ESP, and that
>has always been a part of the SA identification. Why make an
>unnecessary special case for multicast SA here?
>  
>
 From my recollection, the rationale was that a single key server would 
likely be choosing SPIs for a single {source addr, destination addr} 
pair.  That key server could probably be trusted to not choose the same 
SPI for both an AH and ESP SA matching that flow. Therefore keeping the 
protocol in the SA lookup was seen as unnecessary.

You're right though, it does special case the SA lookup logic. If the 
protocol were optionally included in the multicast SA lookup as well as 
the unicast SA lookup, the semantics would be consistent. This might 
simplify the implementation of an SA lookup. I.e.,

  unicast: {SPI, [protocol]}
  ASM multicast: {SPI, destination, [protocol]}
  SSM multicast: {SPI, destination, source, [protocol]}

With today's drafts, we have:

  unicast: {SPI, [protocol]}
  ASM multicast: {SPI, destination}
  SSM multicast: {SPI, destination, source}

Brian

>Or, did I misunderstood something?
>
>_______________________________________________
>Ipsec mailing list
>Ipsec@ietf.org
>https://www1.ietf.org/mailman/listinfo/ipsec
>
>  
>
-- 
Brian Weis
Advanced Security Development, ITD, Cisco Systems
Telephone: +1 408 526 4796
Email: bew@cisco.com


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