Re: SPD issues

[Joe Touch <touch@ISI.EDU>]

Stephen Kent wrote:

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

That was a straw-man intended to demonstrate that having a forwarding 
function inside IPsec would create a security hole. This creates the 
same hole, by analogy.

> Many IPsec implementations will need only one SPD, so this whole issue 
> is a no-op in those cases. 

Agreed.

> 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

This level of 'flexibility' opens a large door, especially if there are 
no constraints on that function. If such a door is unspecified, how can 
we trust a particular implementation?

Joe