Re: revised IPsec processing model

[Mark Duffy <mduffy@quarrytech.com>]

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?

There is always the risk of misconfiguring the device (any configurable 
IPsec device) and thereby compromising security.  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.)

Mark

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