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

["Sharma, Suman" <suman.sharma@intel.com>]

This is the description I got from Steve about this,

"Once we have determined that the inbound packet appears to be an IPsec
protected packet addressed to us, and not ICMP, then we need to match
the packet to an appropriate SAD entry. the two-bit flag is a way of
saying how to perform the match against the SAD entry parameters. If the
flags are set for unicast, then just match using the SPI. If the flags
say sender-specific multicast, match using SPI and source address. If
the flags say multicast but not SSM, match using SPI plus destination
address." 

From this it looks like that SAD lookup will be done using SPI. Once SA
is known, 2-bit flag will be read to find the entries to match for
verification (if this SA is the right one or not). So, in case this bit
is 0, just SPI will be checked. If any of the bits of two bit vecotor is
set, that indicates which all IP addr (dst/src) to match other then SPI.


Doing three lookups (as mentioned by George) will have big performance
impact for unicast.

-suman

-----Original Message-----
From: George Gross [mailto:gmgross@nac.net] 
Sent: Friday, April 09, 2004 5:25 PM
To: Sharma, Suman
Cc: ipsec@lists.tislabs.com; gmgross@nac.net
Subject: Re: Question on Issue#74: Inbound SA lookup - multicast &
unicast 

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
>