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

[Brian Weis <bew@cisco.com>]

Karen,

The multicast changes look good to me. Just a couple of comments inline 
below:

kseo@bbn.com wrote:

>
> 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. 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
>           multicast 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
>           multicast address}. If the SAD entry matches then
>           process the inbound ESP packet with that matching SAD
>               entry. Otherwise, proceed to step 3.
>
For 1. and 2., it would be better to  state "destination address" rather 
than "destination multicast address". The current drafts (discussing 
this process in terms of "bits") don't limit these bits to be applied to 
multicast. These semantics are suitable for broadcast and anycast as 
well as multicast, and these documents should continue to implicitly 
support them in the SA lookup rules.

>        3. Search the SAD for a match on only {SPI}. 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.
>
To be consistent, the optional protocol 3. should be mentioned. E.g., 
"Search the SAD for a match on only {SPI}, or optionally {SPI, protocol}".

Thanks,
Brian

>     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.
>
>
> _______________________________________________
> 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