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

RE: IBM VPN Bakeoff Issues



Title: RE: IBM VPN Bakeoff Issues

> -----Original Message-----
> From: Markku Savela [mailto:msa@anise.tte.vtt.fi]
> Sent: Thursday, November 05, 1998 9:43 AM
> To: tjenkins@TimeStep.com
> Cc: ipsec@tis.com
> Subject: RE: IBM VPN Bakeoff Issues
>
>
>
> > 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.
>
> To me this logic appears right, as per IPSEC architecture.
>
> I guess the point culminates on something I don't know (I am not
> familiar with IKE/ISAMKP details), the question:
>
>   Why does IKE/ISKAMP need to know the ordering of negotiated SAs?
>

Maybe IKE itself doesn't. But somewhere in the implementation, the proper order of transforms must be created as a result of the negotiation. As we discovered at the interoperability test, it's not well enough defined.

> > 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.
>
> I'm not quite sure... my thoughts went somehow.. why do you need to
> care about the ordering if it is already fixed by policy? And it
> seemed indicate that the ordering was something that ISAKMP/IKE could
> decide on (which is false).

I think I see where you're coming from here. However, the order isn't fixed by policy; it's fixed by the documents. We MUST put IPCOMP before ESP. I think it also says that we MUST put ESP before AH (this makes sense, anyway). So if we also disallow ESP+ESP in the same SA payload, it makes the order very determinable, regardless of the order the proposals appear in inside the SA payload.

So even though IKE can negotiate AH over ESP over IPCOMP, that's not what should be implemented. So we need to determine what should be implemented when IKE does negotiate AH over ESP over IPCOMP, so that interoperability is more reasonably assured.

>
> --
> 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/
>
> ps. Do you really want to include this HTML version of the text in
>     each of your messages, perhaps tick the "send text only" on?
>
>       <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
>       <HTML>
>       <HEAD>
>

I didn't know I was. I thought I had the equivalent of "send text only" turned on.