Re: revised IPsec processing model

[Mark Duffy <mduffy@quarrytech.com>]

At 04:49 PM 8/1/2003 -0400, Stephen Kent wrote:
[snip]
>>>   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.
>
>the reason for adding the lookup was to provide a forwarding function, 
>i.e., selection of the output interface for the simple case, or the next 
>(virtual) interface in fancier cases. So I do not think it appropriate to 
>consider renaming the function to say that it is for SPD lookup. The SPD 
>is selected because it is bound to an interface not the other way around.
>
>
>>  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.
>
>As I said above, the whole point of the lookup was to select the 
>interface, and the SPD has always been bound to an interface. I'm not sure 
>why you want to reverse the meaning here.

Yes the SPD has always been bound to an interface, but that doesn't mean it 
must always be so, and the model would be more flexible if it were not so 
required.  However, maybe this is just too big a change to ask.

[snip]


>>>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?
>
>The difference arises at the device where the two SAs must be coordinated, 
>else inbound packets drop on the floor, or outbound packets fail to be 
>protected as desired. I can be persuaded that we ought to say nothing 
>about requiring support for nesting, but since we used to mandate such 
>support, we cannot just be silent on the issue. Also, since I think a good 
>standard lets users know what they can and cannot expect to achieve when 
>communicating between implementations produced by different vendors, what 
>do you propose that we say in this context?

No matter what the standard says, it will be possible for someone to apply 
the standard twice, or n times, in succession to a packet and the 
probability approaches 1 that someone will do so.

I'd propose that the standard should say that the requirement to support 
nesting (as it existed in 2401) has been removed.  And I would just stop 
there.  If folks really feel it is necessary to say more, I would add a 
statement acknowledging that it is possible to apply the standard 
iteratively to a given packet and that this will have the effect of 
"nesting" SAs.

--Mark