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

[George Gross <gmgross@nac.net>]

Suman,

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

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

This statement does not clarify that the "longer" SAD search index is
examined before a shorter one, so as to discriminate those multicast and
unicast SA that have the same SPI. The benefit is that a central group key
management system can allocate SPI for a group without coordinating that
allocation with all of the group's end system IKE key management systems.

For example, if a group SA uses SPI 2059, and there is a unicast SA that
also uses SPI 2059, the SAD lookup should de-mux their packet flows
correctly. If a multicast packet is received, and the algorithm looked at
the SPI 2059 SAD entry that had both bits off before the one that
multicast address bits on, then it would match and use the wrong SAD
entry.

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

As described above, this is not quite complete unless the order of match
is sorted.

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

I expressed the procedure that way for definition purposes; in my
implementation, I use a similar approach as mentioned above but with the
distinction that multicast SA identifiers are checked before unicast. The
SPI indexes into a hash table, with the SAD entries at the hash table
bucket arranged in a linked list sorted by the longest SA id first.

	George


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