RE: IKEv2 transport concerns

[Stephen Kent <kent@bbn.com>]

At 2:45 AM -0500 12/6/02, Black_David@emc.com wrote:
>  > At 7:06 PM -0500 12/3/02, Black_David@emc.com wrote:
>>  >  > >>>>> "Black" == Black David <Black_David@emc.com> writes:
>>  >>      Black> (1) Any system running IKEv2 is REQUIRED to handle ECN
>>  >(Explicit
>>  >>
>>  >>    I think that this may be misplaced. I think that RFC2401bis is where
>>  >>  to say this.
>>  >
>>  >I think it needs to be in both places.  We have a one-time opportunity
>>  >to avoid the IKEv1 ECN negotiation kludge if all IKEv2 implementations
>>  >are REQUIRED to handle ECN correctly at tunnel egress.  IMHO, this
>>  >outcome is important enough to merit specifying the means of achieving
>>  >it in both the IKEv2 and RFC2401bis documents.  If we wind up dealing
>>  >with IKEv2 systems that get this wrong, the negotiation kludge will be
>>  >with us for much longer ...
>>
>>  David,
>>
>>  I don't think the IKE v2 document is the appropriate place to make
>>  note of the ECN handling you refer to, since it applies to the
>>  actions performed on the child SAs that IKE establishes, not on the
>>  IKE SAs, right? It really is a 2401bis matter, I believe.
>>
>>  Steve
>
>Will 2401bis progress on a timeline that will allow a normative reference
>to it from IKEv2?  If so having IKEv2 say "MUST do ECN right, see 2401bis
>for details" would be fine.  I'm concerned that no mention of this at all in
>IKEv2 implicitly allows IKEv2 to negotiate 2401classic style tunnel handling
>of ECN, and that would be unfortunate.

David,

I doubt that IKE v2 and 2401 bis will be issued concurrently. But, my 
concern is over where a requirement belongs in our documents, more 
than what gets it out soonest. I recognize the value in the time to 
market issue you raise, but I think putting requirement in the proper 
place is more important.

Steve