Re: revised IPsec processing model

[Stephen Kent <kent@bbn.com>]

At 14:00 -0700 8/4/03, Joe Touch wrote:
>>
>>Joe,
>>
>>Cumbersome is in the eye of the beholder :-).
>>
>>The other folks who participated in the discussions, who are 
>>vendors, did not seem to agree with the overlay net model you & 
>>Lars proposed.
>
>Having just participated in one such meeting in the U.K., at least 
>one major vendor is prescribing our model as a preferred solution.

OK.

>
>>Also, that model seems narrowly focused on end system, vs. SG or 
>>BITW, implementations.  It is preferable to have a simple model 
>>that is generally applicable, and that's what we have strived to 
>>achieve.
>
>I certainly appreciate, as you have observed, that our perspective 
>is end-system based. You have also noted:
>
>>...I am not knowledgeable enough about the details of host
>  > implementations to have provided an answer like this.
>
>It would be useful at least if this proposal could be vetted with a 
>working implementation on both a router and an end host before being 
>considered as such a major modification to the architecture.

After that exchange, two folks with knowledge of host OS internals, 
and who are implementors of IPv6 and IPsec, confirmed that they saw 
no problems with the proposed processing model via messages to the 
list. Two individuals have told me privately, in the last few weeks, 
that their implementations are equivalent to the processing model, in 
person or in e-mails.  I do not agree that there needs to be working 
examples before we proceed with a new version of 2401, although I 
think I am hearing that there will be several in the near future.

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

I certainly agree that this would be a "bad thing" and one must 
configure the SPDs and the forwarding tables to avoid the problem. 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. 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.

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

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.

Steve