Re: revised IPsec processing model

[Joe Touch <touch@ISI.EDU>]

Stephen Kent wrote:

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

An implementation may certainly control both the SPDs and forwarding
tables in concert. However, short of specifying that in 2401bis, it
would not be required, and thus open a substantial security hole.

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

That's assumed when we're talking about dynamic routing; otherwise, the
traffic doesn't go out two different SAs depending on the routing table ;-)

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

The remainder is basically what I said. And (again) this isn't an
'error'; it's normal operation _whenever_ the routing table changes
under constant packet load.

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

I believe I have given an entirely reasonable set of configurations that
are desired for those using dynamic routing. It would rarely be the case
that two alternate forwarding tunnels would have _exactly_ the same
security properties.

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

Agreed. If the proposed solution is limited to static routing
environments, sure, fine - there's still the issue of the missing 
next-hop info (which hasn't been addressed yet), but no  issue of 
leakage. However all my issues with this solution have presumed
the primary reason for its use, or at least a major reason, is to
support dynamic routing.

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

Or the mechanism. ;-)

> If that possibility can 
> be detected by a config admin tool, then the admin can be warned.

That puts the reliability of security in a tool that needs to look at
more than the SPD, i.e., confirming that IPsec isn't a 'closed bottle'.

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

In our solution, a packet A is forwarded to an encapsulation interface
where it is wrapped B(A) and the result [header=B] is indexed in an SPD
and the result is forwarded.

Dynamic routing, in this case, determines whether A is wrapped with B or
another header (e.g., C). The encryption step - whether involving
routing lookups to resolve the SPD or not - relies on routing table 
entries and SPD entries that are, by _construction_, static, _even in a 
dynamically-routed environment_ (the entries at issue are internal to 
the node, by the way in which we create 'tunneled IPsec traffic' - see 
our ID for those details).

It seems easier to control the interaction between forwarding and IPsec
in the above, notably because dynamic routing would affect only the A->B 
or A->C step.

And as a result, typical changes in the dynamic routing do not affect
whether packets using different paths could go to the incorrect next-hop.

Note that under this solution:

	1. the routing table doesn't determine security policy,
	only IPsec does

	2. correct configuration of the tunnels _does_ involve
	coordianted configuration of the encapsulation and
	encryption steps, but isn't compromised by expected
	routing table changes

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

Agreed. We're certainly focusing on support for dynamic routing, or at
least the impact of dynamic routing on any IPsec configuration. The key
issue is that dynamic routing is often enabled independently of IPsec;
coupling them together and describing the constraints is, I believe, a
significant issue that probably warrants a separate document (e.g, our
ID ;-)

However, if your proposed solution precludes dynamic routing altogether, 
it may not be a viable alternative.

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

Certainly. However, that would require that this document, beyond adding
forwarding as an explicit step, further describe the scope under which
IPsec could be deployed in dynamically routed environments at all. IMO, 
since there are ways of making security independent of expected routing 
changes while allowing alternate paths for the same packet, further 
limiting the scope of IPsec can and should be avoided.

Joe