[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: issue with "per-interface SAD/SPD"
>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
>>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?
>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.