Re: ECN and issue 58

[Joe Touch <touch@ISI.EDU>]

Black_David@emc.com wrote:

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

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