Re: IPsec issue #46 -- No need for nested SAs or SA bundles

[Stephen Kent <kent@bbn.com>]

At 23:15 -0400 8/29/03, Michael Richardson wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>
>
>>>>>>  "Angelos" == Angelos D Keromytis <angelos@cs.columbia.edu> writes:
>     Angelos> Just to start some discussion on this issue: wouldn't this break
>     Angelos> (or make it very difficult) for IPSP to deal with intermediate
>     Angelos> gateways etc. ? The advantage of the current model with respect
>
>   It isn't clear to me if it does or doesn't.
>
>   Just because IKEv2 can't negotiate bundles, doesn't mean that I can't
>negotiate multiple things to do a 5-tuple with different end
>points. FreeS/WAN is currently dealing with the question of how much
>information we can derive from the policy about the ordering of this
>nesting, vs how much we need to be told about.
>
>   It also isn't clear to me why it is any business of 2401bis to say anything
>about this. Permitting looping in SA processing is not a good idea - the
>policy daemon should do the looping and tell the kernel what to do. But
>again, WHY IS THIS THE DOMAIN OF THE IETF?
>
>   As expressed, it appears that 2401bis is addressing the "kernel" issues,
>not the architecture. It is turning the problem into a design issue,
>rather than a functional requirements issue.
>
>   There is a functional requirement for the *SYSTEM* to deal with multiple
>operations on a 5-tuple. It is not the place for the IETF to tell me where
>to put that functionality.

Michael,

2401 does not mandate a particular processing implementation, and 
2401bis will not. But, we do provide a model for processing as a 
concrete means of describing what needs to be done within an IPsec 
implementation. The processing model is a form of state machine, and 
we certainly specify state machines for protocol standards, at least 
when we do a good job.

A primary goal of IETF standards is to promote interoperability. To 
that end, it is necessary to specify minimum capabilities for 
implementations, not only in terms of the syntax of what data is 
exchanged over the net, but also in terms of processing. Failure to 
do so will result in non-interoperability.

The crux of your argument seems to be where we draw a boundary as to 
what is IPsec and what is the province of some larger system. 
However, we have no specs for the larger "system" to which you refer, 
so there will be no basis for interoperability for it.  That is not, 
IMHO, a desirable outcome.

Steve