RE: IKEv2 transport concerns

[Black_David@emc.com]

> >Steve,
> >
> >Would you be amenable to an approach based on a small draft that
> >contains just the tunnel encapsulation/decapsulation material needed
> >to specify ECN handling for tunnel-mode SAs?  That could be put
> >together in short enough order to allow IKEv2 to use a "MUST" to
> >reference it without delaying IKEv2.  When 2401bis is ready, it
> >would obsolete both the new small tunnel draft and 2401 itself,
> >so that the requirement winds up in the right place.  I'll sign
> >up to write the small ECN handling draft on a schedule that won't
> >hold up IKEv2. 
> >
> >If 2401bis gets done faster than expected, the new small ECN handling
> >draft could vanish without a trace, having served its purposes
> >of preventing 2401-classic tunnel (mis)handling of ECN in SAs set up
> >by IKEv2, and allowing us to leave the IKEv1 ECN negotiation
> >kludge on the scrap heap where it belongs.
> >
> >Thanks,
> >--David
> 
> David,
> 
> I'm in favor of keeping the ECN processing separate from IKE v2, so 
> to that extent the separate draft sounds good. However, I would like 
> to be reminded of the reason for having a reference to the separate 
> draft in IKE v2.
> 
> Steve

Steve,

The goal here is that any use of IKEv2 to negotiate a tunnel-mode SA
(or UDP-encapsulated tunnel-mode SA for NAT traversal) carry an implied
promise that ECN will be supported and handled correctly for that
tunnel.  This avoids any need for IKEv2 to negotiate/report/etc.
ECN handling, in contrast to IKEv1 where a negotiable SA attribute
and some other stuff was necessary to deal with the installed base
(see Section 9.2 of RFC 3168 and its subsections for details).

I like this sort of simple solution, and it fits with IKEv2's goal of
simplifying negotiation, but for this solution to work, it has to be
required of implementations before any IKEv2 installed base has a
chance to develop, otherwise we wind up back in the IKEv1 situation
of having to ask whether the other end of the SA supports ECN correctly
or not and be prepared to behave differently depending on the answer.
Not having to ask seems preferable.

An alternative would be to put a normative reference to 2401bis into the
IKEv2 draft, although that may not be consistent with the intended
time schedules of the two drafts.

Thanks,
--David
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953 **NEW**     FAX: +1 (508) 293-7786
black_david@emc.com        Mobile: +1 (978) 394-7754
----------------------------------------------------