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

[Stephen Kent <kent@bbn.com>]

At 11:57 AM -0400 4/10/04, George Gross wrote:
>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.
>

George,

Your are right that there is a need to avoid the possibility of 
matching a multicast datagram against just the SPI for a unicast SA. 
your suggestion calls for essentially ordering the search, to start 
with longest possible matches (S+D+SPI) then shorter matches (S+SPI) 
then shortest (SPI). the three SAD tables you describe represent one 
way of encoding the 2-bit field described in the latest revs of AH, 
ESP, and 2401bis.

the approach you described works, and since support for multicast is 
not mandated by 2401bis or AH or ESP, the cost of this serial search 
would not be incurred by implementations that support only unicast.

we really should have been more precise in our description to help 
people avoid the pitfall of a "too short" match.

One can get fancier, of course. Since MIKE is used to create SAs for 
multicast traffic, it can note the source addresses for SSM and the 
destination addresses for conventional multicast, to cause an inbound 
packet to be matched appropriately, without the need to do as much 
serialization as suggested.

Steve