Subject: RE: ECN and issue 58

From: [email-masked]
Date: Wed, 3 Sep 2003 12:45:33 -0400

> I think the text could be something like this:
> ----------------------------------------------------------------------
> 2.24 ECN (Explicit Congestion Notification)
> 
>    The RFC 3168 includes two ECN operating modes. In order to avoid
>    multiple ECN operating modes and negotiation, tunnel decapsulators
>    for tunnel-mode Security Associations (SAs) created by IKEv2 MUST
>    implement the full-functionality option processing specified in
>    [RFC3168] and [RFC2401bis] to prevent discarding of ECN congestion
>    indications.

My proposed text:

When IPsec tunnels behave as originally specified in [RFC 2401], ECN usage
is not appropriate for the outer IP headers because tunnel decapsulation
processing discards ECN congestion indications to the detriment of the
network.  ECN support for IPsec tunnels for IKEv1-based IPsec requires
multiple  operating modes and negotiation (see [RFC 3168]).  IKEv2
simplifies this situation requiring that ECN be usable in the outer IP
headers of all tunnel-mode IPsec SAs created by IKEv2.  Specifically,
tunnel encapsulators and decapsulators for all tunnel-mode Security
Associations (SAs) created by IKEv2 MUST support the ECN full-functionality
option for tunnels specified in [RFC3168] and MUST implement the tunnel
encapsulation and decapsulation processing specified in [RFC2401bis] to
prevent discarding of ECN congestion indications.

NB: [RFC 2401] reference is informative, [RFC 3168] and [2401bis] are
normative.

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: Joe Touch <[email-masked]>
Date: Thu, 04 Sep 2003 11:28:53 -0700

> NB: [RFC 2401] reference is informative, [RFC 3168] and [2401bis] are

It might be useful to consider that RFC2168 already specifies how ECN 
interacts with IP in IP (RFC2003) tunneling (sec 9.1), and that IPsec 
tunnels should follow that convention.

This is keeping with another goal, i.e., having 2401bis point to RFC2003 
excepting only security caveats, rather than (largely) respecifying an 
existing specification.

The security caveat is that an IPsec tunnel SA MAY set the DF bit but 
MUST NOT not clear it; the latter case should be interpreted (IMO) as 
"pass/encapsulate only if the inner packet's DF is not set, and drop 
otherwise" rather than actually clearing the bit in the header.

(this is addressed in draft-touch-ipsec-vpn-05.txt, Appendix A).

Joe