RE: ECN and issue 58

[Black_David@emc.com]

> 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
black_david@emc.com        Mobile: +1 (978) 394-7754
----------------------------------------------------