New item for 2401bis

[Tero Kivinen <kivinen@ssh.fi>]

We should include the ECN support for the RFC2401bis. The text
about this is already in the IKEv2 document (where it does not belong)
and it should be moved to the RFC2401bis instead (from
draft-ietf-ipsec-ikev2-08.txt):
----------------------------------------------------------------------
2.24 ECN Notification

   Sections 5.1.2.1 and 5.1.2.2 of [RFC 2401] specify that the IPv4 TOS
   octet and IPv6 traffic class octet are to be copied from the inner
   header to the outer header by the encapsulator and that the outer
   header is to be discarded (no change to inner header) by the
   decapsulator.  If ECN (see [RFC 3168]) is in use, ECT codepoints will
   be copied to the outer header, but if a router within the tunnel
   changes an ECT codepoint to a CE codepoint to indicate congestion,
   that indication will be discarded by the decapsulator.  This behavior
   is highly undesirable, and Section 9.2 of [RFC 3168] specifies
   changes to IPsec to avoid it.  These changes include two ECN
   operating modes and negotiation support to detect and cope with IPsec
   decapsulators that discard ECN congestion indications; use of ECN in
   the outer IP header of IPsec tunnels is not permitted when such
   discarding is a possibility.

   In order to avoid multiple ECN operating modes and negotiation,
   tunnel decapsulators for tunnel-mode Security Associations (SAs)
   created by IKEv2 MUST implement the following modifications to
   prevent discarding of ECN congestion indications.  IKEv2 tunnel-mode
   SA negotiation is handled by the USE_TRANSPORT_MODE Notify message
   type (see Section 3.10.1).  The following modifications *replace*
   Section 9.2 of RFC 3168 and *update* Sections 5.1.2.1 and 5.1.2.2 of
   RFC 2401.

   Encapsulation and Decapsulation of packets for a tunnel-mode SA
   created by IKEv2 MUST NOT follow the modifications specified by
   Section 9.2 of RFC 3168 and its subsections.  Instead, the following
   modifications to encapsulation and decapsulation in Sections 5.1.2.1
   and 5.1.2.2 of RFC 2401 MUST be performed:

                         Outer Hdr at                 Inner Hdr at
    IPv4                 Encapsulator                 Decapsulator
      Header fields:     --------------------         ------------
        DS Field         copied from inner hdr (5)    no change
        ECN Field        copied from inner hdr        constructed (7)
    IPv6
      Header fields:
        DS Field         copied from inner hdr (6)    no change
        ECN Field        copied from inner hdr        constructed (7)

      (5)(6) If the packet will immediately enter a domain for which the
      DSCP value in the outer header is not appropriate, that value MUST
      be mapped to an appropriate value for the domain [RFC 2474].  Also
      see [RFC 2475] for further information.

      (7) If the ECN field in the inner header is set to ECT(0) or
      ECT(1) and the ECN field in the outer header is set to CE, then
      set the ECN field in the inner header to CE, otherwise make no
      change to the ECN field in the inner header.

      (5) and (6) are identical to match usage in [RFC2401], although
      they are different in [RFC2401].  These actions are not related to
      ECN, but are required for Differentiated Services support.  They
      are carried over to this document from RFC 3168 so that all of RFC
      3168's changes to IPsec can be made non-applicable to SAs created
      by IKEv2.
-- 
kivinen@ssh.fi
SSH Communications Security                  http://www.ssh.fi/
SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/