[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: revised IPsec processing model



At 16:39 -0700 8/4/03, 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.

I cam see how you might come to that conclusion in some contexts, but 
it certainly is not true in all contexts. For example, some vendors 
of BITW and SG IPsec products provide a unified management interface 
that allows a sys admin to configure the forwarding tables and the 
SPDs together, to avoid the sort of problems we both agree are a 
concern.

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

This is definitely not true, as stated. What I think you mean to say 
is that IF we specify two or more entries in multiple SPDs for the 
same class of traffic (e.g., the same selector sets) AND they have 
different security properties (e.g., IPsec protection vvs. bypass) 
THEN an error in the lookup that selects an SPD (and virtual 
interface) or in the lookup that selects the ultimate outbound 
interface, could result in a security breach. But, to get into this 
situation we have to have several precursor conditions satisfied, and 
I expect that in many environments the configurations will not be so 
complex as to facilitate these sorts of problems.

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

But not all routing is dynamic.  My first hop router may be fixed in 
many contexts, because I have only one choice to exit my LAN. In many 
cases where the choice of first hop router is not known in advance, 
e.g., in my hotel room, I may have only only interface to deal with 
and thus avoid the security problems in that fashion.

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

If normal behavior in common circumstances would cause this to 
happen, then the configuration is inherently insecure. If that 
possibility can be detected by a config admin tool, then the admin 
can be warned.

>
>>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 don't see how this problem is avoidable in any context where you 
maintain that a table used for forwarding is outside the scope of the 
security boundary.  Could you elaborate, without merely referring to 
your ID?

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

First, we probably do not agree on the extent to which dynamic 
routing is always going to be a factor here.  Second, there are means 
to provide security for routing data. For example, in high assurance 
contexts where IPsec-like protection is to be employed, it is 
appropriate to use S-BGP to ensure that the ability to advertise 
prefixes for the hosts "behind" a security device is done securely, 
i.e., the advertisements are authorized.

Steve