RE: IKEv2 transport concerns

[Stephen Kent <kent@bbn.com>]

David,

>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

OK, I now understand the rationale for including a mention of this in 
IKE v2, because of the IKE v1 negotiation issue. I concur.

Steve