Subject: IKEv2: ECN hack for broken h/w?

From: [email-masked]
Date: Mon, 24 Mar 2003 15:10:13 -0500

Folks,

I got tagged with an action item to send this email as
a result of several hallway discussions in SF.  I don't
think a change is needed here, but this is a "due diligence"
exercise to make sure that this issue gets attended to.

The current ECN text in the IKEv2 draft requires a tunnel
decapsulation change to propagate ECN congestion indications
from the outer header to the inner header.  If the
decapsulation is implemented in hardware, a system that is
composed of hardware acceleration (e.g., crypto, tunnel,
ESP) plus software IKE may be unable to upgrade to IKEv2
due to an inability to change the decapsulation hardware.

It appears to be the case that the encapsulation side
is easier to change and/or may not be broken wrt ECN, so
an IKEv2 hack is possible to notify the encapsulator that
the decapsulator can't cope with ECN - the encapsulator would
either disable ECN in the outer headers or fail the SA setup
in tunnel-mode.

OTOH:
- The fact that ipsec tunnels require changes for ECN
	is old news.  This has been discussed in the ipsec
	WG at least as far back as 1999.  One really cannot
	claim that changes in this area are a surprise.
- Any hardware that doesn't implement ECN correctly for
	ipsec tunnels (i.e., does RFC 2401, and nothing
	more) is already broken (does not conform to the
	relevant RFCs), and has been since the publication
	of RFC 3168 in 2001.
- IKEv2 will make AES mandatory.  Hardware that doesn't
	implement AES will be either out of conformance,
	or slow (courtesy of software AES).  I suspect that
	much of the hardware in question doesn't implement
	AES.
- RFC 2401bis will incorporate the ECN changes.  So, even
	if an implementer ignored RFC 3168 (bad idea), the ECN
	changes are coming in a form that can't be ignored.

The upshot (IMHO) is that I don't see a case for putting a
hack into IKEv2 to cope with existing "broken" hardware, but
I thought I'd put this message out to allow those with
differing views to express them.

Thanks,
--David

----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------

---

From: Bill Sommerfeld <[email-masked]>
Date: Mon, 24 Mar 2003 16:13:07 -0500

> differing views to express them.

Agree.  Moreover, should evidence surface that this is a more common
case than we currently think, it's clear to me at that the base ikev2
spec contains sufficient flexibility to allow a critical "broken-hardware"
payload to be specified later in a separate document.

I see no reason to hold ikev2 for this.

						- Bill