Re: revised IPsec processing model

[Mark Duffy <mduffy@quarrytech.com>]

At 03:22 PM 7/31/2003 -0400, Stephen Kent wrote:
>Mark,
>
>I've trimmed the message to keep it readable, since I think we agree on 
>the facts, just not what to do as a result :-).
>
>So we agree that there is a way to achieve source-based SPD selection, and 
>to provide independent forwarding, but you don't think the mechanism is 
>not elegant.

Well of course a device can select an SPD in any way it wants; the issue 
here is about whether the IPsec standard sanctions it or not.  With the 
proposed model of 2401bis it might be debatable whether certain behaviors 
comply, as it would depend on how liberal one is in defining "interface" 
and "forwarding function".  If 2401bis makes it clear that these terms may 
be widely construed, then I agree that the proposed model is flexible 
enough at least for the devices I am envisioning.


>   If I understand your suggestion, though, you would remove all 
> specification of this functionality, and I don't think we have a useful 
> spec if we do that.  Did I misunderstand what you were suggesting here?

I think maybe you did.  My suggestion in a nutshell is not to remove 
specification but to modify it thus:

  1.  Say that the SPD is selected by an "SPD selection function" rather 
than by a "forwarding function".  If we are considering that the 
"forwarding function" may be arbitrary anyway, this wording change seems to 
me to be no more than being honest with ourselves.

  2.  Explicitly recognize that the forwarding function that chooses an 
outgoing IP interface (i.e. for bypassed packets and for packets that have 
just been encrypted or just been decrypted) need not be the same function 
as the SPD selection function.

The important *results* of those two points are that: outgoing packets A 
and B may be treated under different SPDs but be sent out the same IP 
interface, and outbound packets C and D may be treated under the same SPD 
but be sent out different interfaces.  (And similarly for inbound packets.)



>I agree that one could manage to configure SPDs so that nested SA could 
>result.   But, it's probably hard for most folks to do this, and without 
>explicit, support in IKE, if this fails the results will be hard to 
>diagnose. Also, because one would have to effect two IKE negotiations to 
>create both sets of SAs, there are timing issues that could arise that 
>also would result in possibly confusing behavior.
>
>It's easy to have 2401bis not say that nesting of SAs is prohibited. It's 
>harder to say that that nesting MUST or MAY be supported, and how. What do 
>you think should be said here? My concern, in part, is that if we say 
>nothing, then users don't know what to expect re functionality, nor do 
>they have any sense of whether two implementations by two different 
>vendors will support this sort of nesting. That's not a good thing for a 
>standard.

I would propose to say nothing about the nesting of SAs.  I agree with you 
that the standard must be clear on how implementations behave, but I think 
the issue here is one level above the IPsec protocol itself, dealing 
instead with multiple applications of the protocol.  Consider placing 2 
security gateways in "series" so that the AH or ESP packets emitted by the 
first are considered as plaintext or subscriber packets by the second, and 
nested into another SA.  Each SG is just doing a vanilla thing but the 
network administrator has created nested SAs.  What difference should it 
make to the standard whether someone combines both those SGs into one device?

--Mark


>Steve