IKEv2 transport concerns

[Black_David@emc.com]

After further thought and some discussion with Charlie Kaufman,
here are proposed approaches to dealing with two areas in which
transport concerns come up in IKEv2:

(1) Any system running IKEv2 is REQUIRED to handle ECN (Explicit
	Congestion Notification) correctly for tunnels (congestion
	notifications propagate from outer header to inner header at
	tunnel egress).  The ECN Tunnel SA attribute negotiation
	kludge was needed in IKEv1 to deal with the legacy
	installed base, which is of size zero for IKEv2 ;-).
(2) Repeat after me ... "IKEv2 will not negotiate transport QoS".
	For diffserv code points, the proposal is for IKEv2 to have
	each endpoint of a tunnel-mode or UDP-encapsulated-tunnel-mode
	SA report to the other how it treats the outer DSCP values
	on decapsulation (copy to inner vs. discard - nothing more
	complex is needed, see RFC 2983 for a longer discussion).
	Negotiating or configuring this ought to be out of scope for
	IKEv2, but reporting what will be done can be a useful check
	that something stupid isn't about to happen.

Please note that we managed to get this done without adding anything
that has to be negotiated (!).

In addition, it's important to negotiate encapsulation mode needs
separately from crypto processing - this turns out to dovetail nicely
with the NAT traversal requirements, yielding four encapsulation modes:
	- Tunnel
	- Transport
	- UDP-Encapsulated Transport
	- UDP-Encapsulated Tunnel
The latter two are defined in Section 3 of
draft-ietf-ipsec-udp-encaps-04.txt .

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