Subject: RE: [MSEC] [Fwd: LAST CALL: ESP and AH ESN drafts]

From: "Hardjono, Thomas" <[email-masked]>
Date: Wed, 28 May 2003 13:21:15 -0700

We've been asking for changes since the SMuG days.
So the doc is worth a look.

For those who have memorized 2406, here are the key paragraphs/changes
that affect multicast:

   For a unicast SA, the SPI can be used by itself to specify an SA, or
   it may be used in conjunction with the IPsec protocol type (in this
   case ESP). Since the SPI value is generated by the receiver for a
   unicast SA, whether the value is sufficient to identify an SA by
   itself, or whether it must be used in conjunction with the IPsec
   protocol value is a local matter. This mechanism for mapping inbound
   traffic to unicast SAs MUST be supported by all ESP implementations.

   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) [KA98] 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.)  Nominally, this indication can be
   represented by two bits, one associated with the source IP address
   and the other for the destination IP address. A "1" value for each
   bit indicates the need to match against the corresponding address
   field as part of the SA lookup process. Thus, for example, unicast
   SAs would have both bits set to zero, since neither the source nor
   destination IP address is used for SA matching. (Only the SPI, and,
   optionally, the protocol field are employed.) 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. For multicast methods (e.g., SSM [HC03]) that also require the
   source address to identify a multicast group, both bits would be set
   to "1."  (There is no current requirement to support SA mapping based
   on the source address but not the destination address, thus one of
   the possible four values is not meaningful.) The indication 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.

cheers,

thomas
------

> -----Original Message-----
> From: Brian Weis [mailto:[email-masked]] 
> Sent: Wednesday, May 28, 2003 11:37 AM
> To: [email-masked]
> Subject: [MSEC] [Fwd: LAST CALL: ESP and AH ESN drafts]
> 
> 
> Note that the new ESP and AH drafts are now officially in 
> last call. These drafts contain a number of changes from RFCs 
> 2402/2406 that make them more useful when used to protect IP 
> multicast packets. If anyone has any additional issues, now 
> is the time to speak!
> 
> From my memory, there was only one change in these latest 
> versions that affects the multicast case. That was the 
> removal of the "protocol" from the SPI lookup for multicast 
> packets. (I.e., from {destination, SPI, protocol} to 
> {destination, SPI} for any source multicast groups). 
> 
> The effect of this change seems minor. It slightly increases 
> the possibility of ambiguous SPI lookups. This should only 
> happen if two key servers are not choosing SPIs in a 
> coordinated fashion for the same destination. (E.g., if two 
> applications were using the same destination
> address.) But it is still a problem whether or not the 
> protocol field remains in the SPI lookup, so it does not seem 
> worth arguing about.
> 
> Other than that, I personally didn't have any concerns with 
> the drafts.
> 
> Brian
> -- 
> Brian Weis
> Strategic Cryptographic Development, ITD, Cisco Systems
> Telephone: +1 408 526 4796
> Email: [email-masked]
> 

_______________________________________________
msec mailing list
[email-masked]
http://www.pairlist.net/mailman/listinfo/msec