---
Tim Jenkins TimeStep Corporation
tjenkins@timestep.com http://www.timestep.com
(613) 599-3610 x4304 Fax: (613) 599-3617
> -----Original Message-----
> From: Markku Savela [mailto:msa@anise.tte.vtt.fi]
> Sent: Thursday, November 05, 1998 4:09 AM
> To: tjenkins@TimeStep.com
> Cc: ipsec@tis.com
> Subject: Re: IBM VPN Bakeoff Issues
>
>
> > From: Tim Jenkins <tjenkins@TimeStep.com>
> >
> > In response to some of the list of issues and questions
> raised at the IBM
> > VPN interoperability workshop:
> >
> > > 9. Should the order of protocols dictate the order of security
> > > association or should AH, ESP, IPComp always be processed in a
> > > certain order? Most vendors agreed with the latter
> >
> > If we consider that a fixed order is assumed, and that we
> will never support
> > ESP and ESP, there are only 4 kinds of bundles possible: IPCOMP+ESP,
> > IPCOMP+AH, ESP+AH, and IPCOMP+ESP+AH.
>
> Looking at this from the pont of view of implemenor of a basic IPSEC +
> PFKEY in the kernel, I am perhaps a bit confused again: my
> understanding of the IPSEC architecture was
>
> for outgoing
> from policy selector -> SA bundle (list of SA's), apply them
> in whatever order the bundle lists.
I wish it was that simple. However, we have documents that state that IPCOMP must come first. Further, what is the order? >From the interoperability workshop, we know that SSH and TimeStep used ordered proposals, but had them in opposite directions.
We also had implementations that jumbled the order when they accepted. They're logic is that it doesn't matter, since order is dictated anyway.
>
> for incoming,
> apply SA's from the packet, remember the order, and after all
> done find the matching policy entry and check that the order
> applied matches the order in bundle.
>
> The order is an immutable policy decision between communicating
> partners, at least by reading the current IPSEC drafts. What is the
> problem? Can't IKE should just negotiate SAs?
>
> It looks once again that IKE/ISAMKP are trying to negotiate things
> that need to modify the policy. It may be that the current IPSEC is
> deficient in this respect for real use, and some negotiation of the
> policy aspects is also required. But I wold prefer to see a some
> separation of those parts that negotiate individual SA and those that
> negotiate policy affecting things (order of SAs). And, we might need a
> PF_KEY like interface to communicate the policy changes to the kernel?
>
> Perhaps, a solution is that the Key management daemon reads the same
> policy configuration as the kernel IPSEC is using? Then, the key
> management at least knows what order is configured in?
I don't understand where you're coming from here. Where is the policy modification occurring? All we're trying to do is nail down the usage of proposals with the same proposal number that appear in an SA payload.
>
> --
> Markku Savela (msa@hemuli.tte.vtt.fi), Technical Research
> Centre of Finland
> Multimedia Systems, P.O.Box 1203,FIN-02044
> VTT,http://www.vtt.fi/tte/staff/msa/
>