Re: Question on Issue#74: Inbound SA lookup - multicast & unicast

[George Gross <gmgross@nac.net>]

Hi Suman,

	I agree that the language in this section is mildly confusing, I
had a hard time parsing it on my first read.  For my GSAKMP/IPsec
implementation, I interpreted that section to mean that the SAD was
conceptually three databases, not one.

The three SAD databases are indexed and searched as follows:

1) First you search SAD-1 using the SAD index triple {source address,
destination multicast address, SPI}. If the search finds a matching SAD-1
entry, then use its associated SA state to process the ESP payload.

2) Second, you search SAD-2 using the SAD index pair {destination
multicast address, SPI}. If the search finds a matching SAD-2 entry, then
use its SA state.

3) third you search SAD-3 using only the SPI as the index. If the search
finds a matching SAD-3 entry, then use its SA state.

4) discard the packet if none of the above searches got a match.

Typically, SAD-1 is assigned to the Source-Specific Multicast group SA(s),
SAD-2 to Any-Source Multicast group SA(s), and SAD-3 is for unicast SA(s).
The SAD-1 would also be used for any group SA that required anti-replay
protection using ESP sequence numbers.

Steve: If the above procedure is what was intended, then I would like to
suggest that it would be helpful if some additional language be added to
rfc2401-bis describing the above SAD search order (i.e. use SAD longest
search indice first).

The above procedure in principal would allow unicast and multicast SA to
happen to have duplicate SPI assignments. Was that the intention? I infer
that the unmentioned goal is allowing a multicast key management protocol,
such as GSAKMP, to be autonomous from the IKE SPI allocations. would it be
good for rfc2401-bis to explicitly point this out? AFAIK, no MSEC doc
covers this facet of the MSEC/IPsec interaction yet...

tia,
	George

On Fri, 9 Apr 2004, Sharma, Suman wrote:

> Statement below is part of Issue 74 resolution,
>
> "If an IPsec implementation supports multicast SAs as well as
> unicast SAs, then it MUST use the following algorithm for
> mapping all inbound IPsec datagrams to SAs. (Implementations
> that support only unicast traffic need not implement this
> algorithm.)  Each entry in the Security Association Database
> (SAD) must indicate whether the SA lookup makes use of (a)
> the SPI but neither the source or destination address
> (unicast), (b) the destination IP address plus the SPI, or
> (c) source plus 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 required for SA matching."
>
> My question is for implementation supporting multicast & unicast:
>   From the above statement, it looks like that 2 bit flag will be stored
> inside SAD.
> But To get to SAD, lookup is required? And what all fields to use for
> lookup is inside SAD (in 2 bit flag)?
> So how this is supposed to work?
>
>
> -suman
>