Re: revised IPsec processing model

[Joe Touch <touch@ISI.EDU>]

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