Re: revised IPsec processing model

[Joe Touch <touch@ISI.EDU>]

Mark Duffy wrote:

> Hi all,
> 
> I'm a bit mystified about this line of discussion.  The change that 
> Steve has proposed in the processing model is IMO a clarification (in 
> that the packet forwarding decision that takes place in an IP device is 
> explicitly recognized) and a generalization (in that it recognizes that 
> an implementation *may* make more than one "forwarding" decision on a 
> packet, an implementation *may* pass a packet through more than one SPD 
> and IPsec treatment, and the "forwarding" function used is beyond the 
> scope of IPsec.)  There is nothing in this that *requires* any 
> implementation to take advantage of any of that.  So I would expect that 
> if the RFC 2401 model is sufficient for a given purpose, the proposed 
> one should be also.  No?

This "clarification" highlights an undesirable interaction between 
dynamic routing and IPsec. While we wouldn't want that interaction to be 
'required', highlighting it alone is insufficient if the interaction has 
undesirable consequences.

> There is always the risk of misconfiguring the device (any configurable 
> IPsec device) and thereby compromising security. 

Agreed; however, what we've been talking about is a properly configured 
device. Unless

	a) all tunnels with overlapping traffic selectors must have
	identical security

	or

	b) IPsec is not run in conjunction with dynamic routing

 > I agree that as
> flexibility of a device goes up (e.g. from 1 SPD per box to one per 
> interface, or to more complex behaviors) the risk of misconfiguration 
> generally goes up.  But the benefits of using the device also go up.  
> This tradeoff between functionality and risk is for those deploying 
> equipment to make.  (Obviously, anyone would be ill-advised to 
> manufacture or deploy devices that perform improperly as with the 
> hypothetical race conditions described below.)

These 'race' conditions are the result of normal operation, not 
misconfiguration or misimplementation.

Joe


> At 04:39 PM 8/4/2003 -0700, Joe Touch wrote:
> 
> 
>> Stephen Kent wrote:
>>
>>> At 14:00 -0700 8/4/03, Joe Touch wrote:
>>>
>>>> One other question:
>>>>
>>>> What happens to packets when the IPsec-time forwarding lookup 
>>>> differs from the forwarding that actually happens when the packet 
>>>> would be emitted?
>>>>
>>>> I.e., it seems possible that if I had weak or no encryption on one 
>>>> link, that it might be possible to leak such packets out onto a link 
>>>> that I needed strong protection on. If this is not the case, a 
>>>> specific example would help.
>>>
>>> If I understand correctly, your concern is that there could be a 
>>> mismatch between an SPD lookup that maps a packet to a interface that 
>>> is deemed implicitly secure and thus does not warrant IPsec 
>>> protection, but a later forwarding decision that puts the packet out 
>>> over a link that does warrant protection.  Is that right?
>>
>>
>> Yes.
>>
>>> I certainly agree that this would be a "bad thing" and one must 
>>> configure the SPDs and the forwarding tables to avoid the problem.
>>
>>
>> IPsec can have no control over the forwarding tables.
>>
>> Other than ensuring that one can -never- configure two tunnels with 
>> one being weaker, there doesn't seem to be a solution that is 
>> enforceable within IPsec using this architecture.
>>
>>> If we allow the first forwarding table to select the appropriate SPD, 
>>> then we have to rely on that forwarding function to operate 
>>> correctly, IF we allow any sensitive traffic to be emitted without 
>>> IPsec protection on ANY link.
>>
>>
>> I'm considering a case where the forwarding table isn't malicious; the 
>> trick is that this model (using forwarding inside IPsec) requires that 
>> there be a lock between doing a forwarding lookup and emitting the 
>> packet.
>>
>> A forwarding table must be able to change, e.g., that's the definition 
>> of dynamic routing.
>>
>>> Otherwise, the first forwarding lookup could map the traffic to an 
>>> SPD that allowed bypass such traffic for a specific interface, but 
>>> then the traffic could be emitted via a different interface, thus 
>>> defeating the intent of the policy specification.
>>
>>
>> That's the problem I'm worried about.
>>
>>> Also, if the SPD does allow bypassing of any sensitive traffic, then 
>>> the post IPsec processing forwarding lookup also must function 
>>> properly, lest the same bad effect take place despite the correct 
>>> functioning of the first lookup (and the correct config of the 
>>> corresponding SPD).
>>
>>
>> Aggred - but again, it's not malicious behavior, but normal operation 
>> that might cause this.
>>
>>> Frankly, this is why I worry about anything other than the trivial 
>>> case with one SPD and no per-interface distinctions about what 
>>> classes of traffic to protect.  If the WG feels that we do not 
>>> require per-interface SPDs, as Mark suggested, I am happy to make 
>>> that change. But I note that Mark did call for multiple SPDs (just 
>>> not tied to an interface by the first forwarding function), and I see 
>>> the same opportunity for security problems due to lookup errors in 
>>> that case as well.
>>
>>
>> Agreed. Note that this is not a problem with the solution we propose, 
>> because the routing table is involved exactly once for each packet for 
>> us.
>>
>>> I think the fundamental problem here is the opportunity to emit 
>>> traffic without appropriate protection, due to a mismatch between 
>>> what an SPD says and what a forwarding function does.  This is 
>>> ultimately a config management problem, made worse by a desire to 
>>> support fancier access controls and fancier forwarding options.
>>
>>
>> Agreed - except that, as above, I don't see how to configure dynamic 
>> routing except across two _identically protected_ tunnels. That is a 
>> requirement that severely limits the utility of such a solution, IMO.
>>
>> Joe