Re: issue with "per-interface SAD/SPD"

[Stephen Kent <kent@bbn.com>]

>At 6:06 PM +0200 6/9/03, Francis Dupont wrote:
>>The RFC 2401 mandates (section 4.4, page 13) separate inbound and
>>outbound databases (SAD and SPD) for each IPsec-enabled interface.
>>This doesn't work in a dynamic environment where for instance dynamic
>>routing makes the arrival of a packet for an address of a node possible
>>on more than one interface in a long term, or where the peer is a mobile
>>node.
>>The problem exists at least in SAD lookup for incoming traffic and for
>>SPD matching in IKE... IMHO the simplest (so the best :-) solution is
>>to introduce an interface selector: the "firewall" properties are kept
>>but a SPD entry can be "shared" between some interfaces.
>>How this will be handled in the revision of RFC 2401?
>>
>>Regards
>>
>>Francis.Dupont@enst-bretagne.fr
>
>Francis,
>
>Good points.  We'll be presenting a new IPsec processing model to 
>the list next week, and one facet of it will be a clarification of 
>the relationship between SPDs, SADs, interfaces and routing.  We 
>will be introducing an explicit forwarding function call, that will 
>select an interface prior to SPD lookup.
>
>Going forward, we still need per (logical) interface SPDs, but the 
>SAD is really per implementation, not per interface.  By this I mean 
>that if a  device centrally manages SPI assignment, then only one 
>SAD is needed. In contrast, if a router had one IPsec process on 
>each interface card, it would probably want an SAD per card (because 
>of the difficulties of coordination across interfaces) and that is a 
>reasonable implementation strategy as well.
>
>Steve