Subject: RE: [Ipsec] Technical change needed to IKEv2 before publication

From: [email-masked]
Date: Tue, 1 Mar 2005 19:07:04 +0200

Tom Stiemerling writes:
> 
> The problem that was found at the bake-off is that some
> vendors implementations (correctly) insisted that the ESN(off)
> transform was included in all proposals, since they did not
> support ESN, and not including the ESN transform meant ESN was
> on (as specified in the draft). Therefore to interoperate with
> all responders - without knowing whether they supported ESN or
> not - the initiator always has to include either ESN(off) if
> it does not support ESN, or ESN(off) | ESN(on) if the
> responder does support ESN. So the ESN transform is then not
> really optional any more, and it was decided to make this
> explicit in the draft.

According to the current draft, it's optional only if the
initiator insists on using ESNs (and wants the negotiation to
fail otherwise).  I can't think of any reason why any sane
initiator would want to do this, so at least a clarification
explicitly saying so is needed: but we do not necessarily need
any technical changes in the protocol.

This clarification could be either in the IKEv2 draft, or the
separate "IKEv2 Clarifications" draft I've been working on.
I think getting IKEv2 out as RFC is more important than making 
it perfect, so any minor clarifications should probably go to 
the separate draft... but this might be important enough to go 
to the IKEv2 spec (considering the bakeoff situation). So either 
way is fine with me.

Best regards,
Pasi

_______________________________________________
Ipsec mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipsec

---

From: "Scott Fanning" <[email-masked]>
Date: Tue, 1 Mar 2005 09:17:29 -0800

So, I guess the advantage of having IKEv2 described in one doc is out the
door? <*sigh*>. I would rather see the current doc correct. You would have
to add a pointer to the "clarifications draft" in the IKEv2 doc at the very
least, or we end up with interop issues. A complete and accurate protocol
specification avoids many interop issues IMHO.

Scott 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Tuesday, March 01, 2005 9:07 AM
To: [email-masked]
Cc: [email-masked]
Subject: RE: [Ipsec] Technical change needed to IKEv2 before publication

Tom Stiemerling writes:
> 
> The problem that was found at the bake-off is that some vendors 
> implementations (correctly) insisted that the ESN(off) transform was 
> included in all proposals, since they did not support ESN, and not 
> including the ESN transform meant ESN was on (as specified in the 
> draft). Therefore to interoperate with all responders - without 
> knowing whether they supported ESN or not - the initiator always has 
> to include either ESN(off) if it does not support ESN, or ESN(off) | 
> ESN(on) if the responder does support ESN. So the ESN transform is 
> then not really optional any more, and it was decided to make this 
> explicit in the draft.

According to the current draft, it's optional only if the initiator insists
on using ESNs (and wants the negotiation to fail otherwise).  I can't think
of any reason why any sane initiator would want to do this, so at least a
clarification explicitly saying so is needed: but we do not necessarily need
any technical changes in the protocol.

This clarification could be either in the IKEv2 draft, or the separate
"IKEv2 Clarifications" draft I've been working on.
I think getting IKEv2 out as RFC is more important than making it perfect,
so any minor clarifications should probably go to the separate draft... but
this might be important enough to go to the IKEv2 spec (considering the
bakeoff situation). So either way is fine with me.

Best regards,
Pasi

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 1 Mar 2005 11:20:22 -0800

At 9:17 AM -0800 3/1/05, Scott Fanning wrote:
>door? <*sigh*>.

We knew that years ago. Given our experience with IKEv1, and the kind 
of mishmash that went into the development of IKEv2, we knew this 
would happen.

>  I would rather see the current doc correct.

...and never come out.

>  You would have
>least, or we end up with interop issues.

We will end up with interop issues regardless; the idea is to reduce 
them where possible.

>  A complete and accurate protocol

That can happen later. That is, we can do a rewrite of the IKEv2 
document itself, making no technical changes, just clarifications. 
This has happened before, in PKIX.

--Paul Hoffman, Director
--VPN Consortium