RE: IKEv2 transport concerns

[Black_David@emc.com]

> >>>>> "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 ...

>     Black> (2) Repeat after me ... "IKEv2 will not negotiate transport
QoS".
> 
>   Okay, I'm not even sure that we all know what it is that we won't be
doing.

Neither do I, which is one of the reasons I want to keep it out of IKEv2 ...
 
>   Are you telling me that, if a gateway system is aware of QoS that was
> requested by an end system, that it can never inform the other gateway of
> this fact?

No - it's welcome to inform the other gateway, just not via IKEv2.

>   Clearly, a gateway system that knows of a QoS requested by an end system
> (whether via RSVP or other) could easily present appropriate signaling for
> the resulting tunnel.

Yes, via an appropriate QoS signaling protocol, which is *not* IKEv2, IMHO.

>     Black> 	For diffserv code points, the proposal is for IKEv2 to have
>     Black> 	each endpoint of a tunnel-mode or
UDP-encapsulated-tunnel-mode
>     Black> 	SA report to the other how it treats the outer DSCP values
>     Black> 	on decapsulation (copy to inner vs. discard - nothing more
>     Black> 	complex is needed, see RFC 2983 for a longer discussion).
> 
>     Black> 	Negotiating or configuring this ought to be out of scope for
>     Black> 	IKEv2, but reporting what will be done can be a useful check
>     Black> 	that something stupid isn't about to happen.
> 
>   Okay, so this is just advice.

Right it's reporting on what's going to occur, so the "Oh, sh*t, that's not
right" reaction can take place before any real traffic is affected.  The
endpoints are free to ignore the reports if they don't have anything useful
to do with them.

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
----------------------------------------------------