[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

At 23:15 -0400 8/29/03, Michael Richardson wrote:
-----BEGIN PGP SIGNED MESSAGE-----


"Angelos" == Angelos D Keromytis <angelos@xxxxxxxxxxxxxxx> 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