[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: SPD issues
At 10:00 -0700 10/21/03, Joe Touch wrote:
>Mark Duffy wrote:
>
>>
>>>>[MD] So, there is an SPD selection function that chooses an SPD.
>>>>And there is an IP forwarding function that selects a next hop to
>>>>forward a datagram to. And the two may be comepletely
>>>>independent or completely entwined, depending on the nature of
>>>>the device.
>>>
>>>
>>>[JT] It's the entwined case that presents the largest problem.
>>>I.e., if the SPD selection is based on forwarding information that
>>>then changes by the time the subsequently tunneled (or not
>>>tunneled) packet is emitted from IPsec.
>>>
>>>This could happen whether dynamic or static routing is used; the
>>>issue is flux in the forwarding table and whether it is _allowed_
>>>to affect SPD selection.
>>>
>>>Calling the function "SPD selection" doesn't absolve the problem.
>>>
>>>Joe
>>
>>
>>No. But it isolates the problems of which SPD to use, and which
>>interface/ next hop to send the packet to. Whoever feels that
>>these are or need to be entwined for their application is free to
>>do so.. Those
>>solving simpler problems can avoid that. And 2401bis can take
>>itself out of the business of IP forwarding decisions.
>>
>>Mark
>
>I'm in favor of those last two observations, but it's the "whoever feels
>.. is free to do so" that worries me. I.e., this gives enough freedom to
>end up with a nasty loophole, e.g., "SPD selection can be supported, but
>how is up to the implementer, and whether it is secure depends on the
>implementation".
>
>Joe
Joe,
We have enough variation in how different contexts want to select
SPDs (when more than one is needed) that I don't think we can do more
than say that there is a lookup function which takes the outbound
packet and local metadata as inputs. This seems analogous to your
earlier suggestion to allow a forwarding function to have access to
the whole outbound packet to support an unspecified forwarding
lookup, when we were thinking of having an explicit forwarding
function as part of IPsec.
Many IPsec implementations will need only one SPD, so this whole
issue is a no-op in those cases. In cases where multiple SPDs are
appropriate, then yes, the implementor and the admin will have to
exercise caution in these contexts. Generally, we cannot have it
both ways. if we keep things simple, we can have more confidence in
their security, but we loose flexibility.
Steve