GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc6040

Internet Engineering Task Force (IETF) B. Briscoe Request for Comments: 6040 BT Updates: 3168, 4301, 4774 November 2010 Category: Standards Track ISSN: 2070-1721

           Tunnelling of Explicit Congestion Notification

Abstract

 This document redefines how the explicit congestion notification
 (ECN) field of the IP header should be constructed on entry to and
 exit from any IP-in-IP tunnel.  On encapsulation, it updates RFC 3168
 to bring all IP-in-IP tunnels (v4 or v6) into line with RFC 4301
 IPsec ECN processing.  On decapsulation, it updates both RFC 3168 and
 RFC 4301 to add new behaviours for previously unused combinations of
 inner and outer headers.  The new rules ensure the ECN field is
 correctly propagated across a tunnel whether it is used to signal one
 or two severity levels of congestion; whereas before, only one
 severity level was supported.  Tunnel endpoints can be updated in any
 order without affecting pre-existing uses of the ECN field, thus
 ensuring backward compatibility.  Nonetheless, operators wanting to
 support two severity levels (e.g., for pre-congestion notification --
 PCN) can require compliance with this new specification.  A thorough
 analysis of the reasoning for these changes and the implications is
 included.  In the unlikely event that the new rules do not meet a
 specific need, RFC 4774 gives guidance on designing alternate ECN
 semantics, and this document extends that to include tunnelling
 issues.

Status of This Memo

 This is an Internet Standards Track document.
 This document is a product of the Internet Engineering Task Force
 (IETF).  It represents the consensus of the IETF community.  It has
 received public review and has been approved for publication by the
 Internet Engineering Steering Group (IESG).  Further information on
 Internet Standards is available in Section 2 of RFC 5741.
 Information about the current status of this document, any errata,
 and how to provide feedback on it may be obtained at
 http://www.rfc-editor.org/info/rfc6040.

Briscoe Standards Track [Page 1] RFC 6040 ECN Tunnelling November 2010

Copyright Notice

 Copyright (c) 2010 IETF Trust and the persons identified as the
 document authors.  All rights reserved.
 This document is subject to BCP 78 and the IETF Trust's Legal
 Provisions Relating to IETF Documents
 (http://trustee.ietf.org/license-info) in effect on the date of
 publication of this document.  Please review these documents
 carefully, as they describe your rights and restrictions with respect
 to this document.  Code Components extracted from this document must
 include Simplified BSD License text as described in Section 4.e of
 the Trust Legal Provisions and are provided without warranty as
 described in the Simplified BSD License.

Briscoe Standards Track [Page 2] RFC 6040 ECN Tunnelling November 2010

Table of Contents

 1. Introduction ....................................................4
    1.1. Scope ......................................................5
 2. Terminology .....................................................6
 3. Summary of Pre-Existing RFCs ....................................7
    3.1. Encapsulation at Tunnel Ingress ............................7
    3.2. Decapsulation at Tunnel Egress .............................8
 4. New ECN Tunnelling Rules ........................................9
    4.1. Default Tunnel Ingress Behaviour ..........................10
    4.2. Default Tunnel Egress Behaviour ...........................10
    4.3. Encapsulation Modes .......................................12
    4.4. Single Mode of Decapsulation ..............................14
 5. Updates to Earlier RFCs ........................................15
    5.1. Changes to RFC 4301 ECN Processing ........................15
    5.2. Changes to RFC 3168 ECN Processing ........................16
    5.3. Motivation for Changes ....................................17
         5.3.1. Motivation for Changing Encapsulation ..............17
         5.3.2. Motivation for Changing Decapsulation ..............18
 6. Backward Compatibility .........................................21
    6.1. Non-Issues Updating Decapsulation .........................21
    6.2. Non-Update of RFC 4301 IPsec Encapsulation ................21
    6.3. Update to RFC 3168 Encapsulation ..........................22
 7. Design Principles for Alternate ECN Tunnelling Semantics .......22
 8. Security Considerations ........................................24
 9. Conclusions ....................................................26
 10. Acknowledgements ..............................................26
 11. References ....................................................27
    11.1. Normative References .....................................27
    11.2. Informative References ...................................27
 Appendix A.  Early ECN Tunnelling RFCs ............................29
 Appendix B.  Design Constraints ...................................29
   B.1.  Security Constraints ......................................29
   B.2.  Control Constraints .......................................31
   B.3.  Management Constraints ....................................32
 Appendix C.  Contribution to Congestion across a Tunnel ...........33
 Appendix D.  Compromise on Decap with ECT(1) Inner and ECT(0)
              Outer ................................................34
 Appendix E.  Open Issues ..........................................35

Briscoe Standards Track [Page 3] RFC 6040 ECN Tunnelling November 2010

1. Introduction

 Explicit congestion notification (ECN [RFC3168]) allows a forwarding
 element (e.g., a router) to notify the onset of congestion without
 having to drop packets.  Instead, it can explicitly mark a proportion
 of packets in the two-bit ECN field in the IP header (Table 1 recaps
 the ECN codepoints).
 The outer header of an IP packet can encapsulate one or more IP
 headers for tunnelling.  A forwarding element using ECN to signify
 congestion will only mark the immediately visible outer IP header.
 When a tunnel decapsulator later removes this outer header, it
 follows rules to propagate congestion markings by combining the ECN
 fields of the inner and outer IP header into one outgoing IP header.
 This document updates those rules for IPsec [RFC4301] and non-IPsec
 [RFC3168] tunnels to add new behaviours for previously unused
 combinations of inner and outer headers.  It also updates the ingress
 behaviour of RFC 3168 tunnels to match that of RFC 4301 tunnels.
 Tunnel endpoints complying with the updated rules will be backward
 compatible when interworking with tunnel endpoints complying with RFC
 4301, RFC 3168, or any earlier specification.
 When ECN and its tunnelling was defined in RFC 3168, only the minimum
 necessary changes to the ECN field were propagated through tunnel
 endpoints -- just enough for the basic ECN mechanism to work.  This
 was due to concerns that the ECN field might be toggled to
 communicate between a secure site and someone on the public Internet
 -- a covert channel.  This was because a mutable field like ECN
 cannot be protected by IPsec's integrity mechanisms -- it has to be
 able to change as it traverses the Internet.
 Nonetheless, the latest IPsec architecture [RFC4301] considered a
 bandwidth limit of two bits per packet on a covert channel to be a
 manageable risk.  Therefore, for simplicity, an RFC 4301 ingress
 copied the whole ECN field to encapsulate a packet.  RFC 4301
 dispensed with the two modes of RFC 3168, one which partially copied
 the ECN field, and the other which blocked all propagation of ECN
 changes.
 Unfortunately, this entirely reasonable sequence of standards actions
 resulted in a perverse outcome; non-IPsec tunnels (RFC 3168) blocked
 the two-bit covert channel, while IPsec tunnels (RFC 4301) did not --
 at least not at the ingress.  At the egress, both IPsec and non-IPsec
 tunnels still partially restricted propagation of the full ECN field.

Briscoe Standards Track [Page 4] RFC 6040 ECN Tunnelling November 2010

 The trigger for the changes in this document was the introduction of
 pre-congestion notification (PCN [RFC5670]) to the IETF Standards
 Track.  PCN needs the ECN field to be copied at a tunnel ingress and
 it needs four states of congestion signalling to be propagated at the
 egress, but pre-existing tunnels only propagate three in the ECN
 field.
 This document draws on currently unused (CU) combinations of inner
 and outer headers to add tunnelling of four-state congestion
 signalling to RFC 3168 and RFC 4301.  Operators of tunnels who
 specifically want to support four states can require that all their
 tunnels comply with this specification.  However, this is not a fork
 in the RFC series.  It is an update that can be deployed first by
 those that need it, and subsequently by all tunnel endpoint
 implementations (RFC 4301, RFC 3168, RFC 2481, RFC 2401, RFC 2003),
 which can safely be updated to this new specification as part of
 general code maintenance.  This will gradually add support for four
 congestion states to the Internet.  Existing three state schemes will
 continue to work as before.
 In fact, this document is the opposite of a fork.  At the same time
 as supporting a fourth state, the opportunity has been taken to draw
 together divergent ECN tunnelling specifications into a single
 consistent behaviour, harmonising differences such as perverse covert
 channel treatment.  Then, any tunnel can be deployed unilaterally,
 and it will support the full range of congestion control and
 management schemes without any modes or configuration.  Further, any
 host or router can expect the ECN field to behave in the same way,
 whatever type of tunnel might intervene in the path.

1.1. Scope

 This document only concerns wire protocol processing of the ECN field
 at tunnel endpoints and makes no changes or recommendations
 concerning algorithms for congestion marking or congestion response.
 This document specifies common ECN field processing at encapsulation
 and decapsulation for any IP-in-IP tunnelling, whether IPsec or non-
 IPsec tunnels.  It applies irrespective of whether IPv4 or IPv6 is
 used for either the inner or outer headers.  It applies for packets
 with any destination address type, whether unicast or multicast.  It
 applies as the default for all Diffserv per-hop behaviours (PHBs),
 unless stated otherwise in the specification of a PHB (but Section 4
 strongly deprecates such exceptions).  It is intended to be a good
 trade off between somewhat conflicting security, control, and
 management requirements.

Briscoe Standards Track [Page 5] RFC 6040 ECN Tunnelling November 2010

 [RFC2983] is a comprehensive primer on differentiated services and
 tunnels.  Given ECN raises similar issues to differentiated services
 when interacting with tunnels, useful concepts introduced in RFC 2983
 are used throughout, with brief recaps of the explanations where
 necessary.

2. Terminology

 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
 document are to be interpreted as described in RFC 2119 [RFC2119].
 Table 1 recaps the names of the ECN codepoints [RFC3168].
   +------------------+----------------+---------------------------+
   | Binary codepoint | Codepoint name | Meaning                   |
   +------------------+----------------+---------------------------+
   |        00        | Not-ECT        | Not ECN-capable transport |
   |        01        | ECT(1)         | ECN-capable transport     |
   |        10        | ECT(0)         | ECN-capable transport     |
   |        11        | CE             | Congestion experienced    |
   +------------------+----------------+---------------------------+
        Table 1: Recap of Codepoints of the ECN Field [RFC3168]
                           in the IP Header
 Further terminology used within this document:
 Encapsulator:  The tunnel endpoint function that adds an outer IP
    header to tunnel a packet (also termed the 'ingress tunnel
    endpoint' or just the 'ingress' where the context is clear).
 Decapsulator:  The tunnel endpoint function that removes an outer IP
    header from a tunnelled packet (also termed the 'egress tunnel
    endpoint' or just the 'egress' where the context is clear).
 Incoming header:  The header of an arriving packet before
    encapsulation.
 Outer header:  The header added to encapsulate a tunnelled packet.
 Inner header:  The header encapsulated by the outer header.
 Outgoing header:  The header constructed by the decapsulator using
    logic that combines the fields in the outer and inner headers.
 Copying ECN:  On encapsulation, setting the ECN field of the new
    outer header to be a copy of the ECN field in the incoming header.

Briscoe Standards Track [Page 6] RFC 6040 ECN Tunnelling November 2010

 Zeroing ECN:  On encapsulation, clearing the ECN field of the new
    outer header to Not-ECT ("00").
 Resetting ECN:  On encapsulation, setting the ECN field of the new
    outer header to be a copy of the ECN field in the incoming header
    except the outer ECN field is set to the ECT(0) codepoint if the
    incoming ECN field is CE.

3. Summary of Pre-Existing RFCs

 This section is informative not normative, as it recaps pre-existing
 RFCs.  Earlier relevant RFCs that were either Experimental or
 incomplete with respect to ECN tunnelling (RFC 2481, RFC 2401, and
 RFC 2003) are briefly outlined in Appendix A.  The question of
 whether tunnel implementations used in the Internet comply with any
 of these RFCs is not discussed.

3.1. Encapsulation at Tunnel Ingress

 At the encapsulator, the controversy has been over whether to
 propagate information about congestion experienced on the path so far
 into the outer header of the tunnel.
 Specifically, RFC 3168 says that, if a tunnel fully supports ECN
 (termed a 'full-functionality' ECN tunnel in [RFC3168]), the
 encapsulator must not copy a CE marking from the incoming header into
 the outer header that it creates.  Instead, the encapsulator must set
 the outer header to ECT(0) if the ECN field is marked CE in the
 arriving IP header.  We term this 'resetting' a CE codepoint.
 However, the new IPsec architecture in [RFC4301] reverses this rule,
 stating that the encapsulator must simply copy the ECN field from the
 incoming header to the outer header.
 RFC 3168 also provided a Limited Functionality mode that turns off
 ECN processing over the scope of the tunnel by setting the outer
 header to Not-ECT ("00").  Then, such packets will be dropped to
 indicate congestion, rather than marked with ECN.  This is necessary
 for the ingress to interwork with legacy decapsulators ([RFC2481],
 [RFC2401], and [RFC2003]) that do not propagate ECN markings added to
 the outer header.  Otherwise, such legacy decapsulators would throw
 away congestion notifications before they reached the transport
 layer.

Briscoe Standards Track [Page 7] RFC 6040 ECN Tunnelling November 2010

 Neither Limited Functionality mode nor Full Functionality mode are
 used by an RFC 4301 IPsec encapsulator, which simply copies the
 incoming ECN field into the outer header.  An earlier key-exchange
 phase ensures an RFC 4301 ingress will not have to interwork with a
 legacy egress that does not support ECN.
 These pre-existing behaviours are summarised in Figure 1.
  +-----------------+-----------------------------------------------+
  | Incoming Header |             Departing Outer Header            |
  | (also equal to  +---------------+---------------+---------------+
  | departing Inner |  RFC 3168 ECN |  RFC 3168 ECN | RFC 4301 IPsec|
  |     Header)     |    Limited    |     Full      |               |
  |                 | Functionality | Functionality |               |
  +-----------------+---------------+---------------+---------------+
  |    Not-ECT      |   Not-ECT     |   Not-ECT     |   Not-ECT     |
  |     ECT(0)      |   Not-ECT     |    ECT(0)     |    ECT(0)     |
  |     ECT(1)      |   Not-ECT     |    ECT(1)     |    ECT(1)     |
  |       CE        |   Not-ECT     |    ECT(0)     |      CE       |
  +-----------------+---------------+---------------+---------------+
  Figure 1: IP-in-IP Encapsulation: Recap of Pre-Existing Behaviours

3.2. Decapsulation at Tunnel Egress

 RFC 3168 and RFC 4301 specify the decapsulation behaviour summarised
 in Figure 2.  The ECN field in the outgoing header is set to the
 codepoint at the intersection of the appropriate arriving inner
 header (row) and arriving outer header (column).

Briscoe Standards Track [Page 8] RFC 6040 ECN Tunnelling November 2010

          +---------+------------------------------------------------+
          |Arriving |            Arriving Outer Header               |
          |   Inner +---------+------------+------------+------------+
          |  Header | Not-ECT | ECT(0)     | ECT(1)     |     CE     |
          +---------+---------+------------+------------+------------+
RFC 3168->| Not-ECT | Not-ECT |Not-ECT     |Not-ECT     |  <drop>    |
RFC 4301->| Not-ECT | Not-ECT |Not-ECT     |Not-ECT     |Not-ECT     |
          |  ECT(0) |  ECT(0) | ECT(0)     | ECT(0)     |     CE     |
          |  ECT(1) |  ECT(1) | ECT(1)     | ECT(1)     |     CE     |
          |    CE   |      CE |     CE     |     CE     |     CE     |
          +---------+---------+------------+------------+------------+
 In pre-existing RFCs, the ECN field in the outgoing header was set to
 the codepoint at the intersection of the appropriate arriving inner
 header (row) and arriving outer header (column), or the packet was
 dropped where indicated.
   Figure 2: IP in IP Decapsulation; Recap of Pre-Existing Behaviour
 The behaviour in the table derives from the logic given in RFC 3168
 and RFC 4301, briefly recapped as follows:
 o  On decapsulation, if the inner ECN field is Not-ECT the outer is
    ignored.  RFC 3168 (but not RFC 4301) also specified that the
    decapsulator must drop a packet with a Not-ECT inner and CE in the
    outer.
 o  In all other cases, if the outer is CE, the outgoing ECN field is
    set to CE; otherwise, the outer is ignored and the inner is used
    for the outgoing ECN field.
 Section 9.2.2 of RFC 3168 also made it an auditable event for an
 IPsec tunnel "if the ECN Field is changed inappropriately within an
 IPsec tunnel...".  Inappropriate changes were not specifically
 enumerated.  RFC 4301 did not mention inappropriate ECN changes.

4. New ECN Tunnelling Rules

 The standards actions below in Section 4.1 (ingress encapsulation)
 and Section 4.2 (egress decapsulation) define new default ECN tunnel
 processing rules for any IP packet (v4 or v6) with any Diffserv
 codepoint.
 If these defaults do not meet a particular requirement, an alternate
 ECN tunnelling scheme can be introduced as part of the definition of
 an alternate congestion marking scheme used by a specific Diffserv
 PHB (see [RFC4774] and Section 5 of [RFC3168]).  When designing such
 alternate ECN tunnelling schemes, the principles in Section 7 should

Briscoe Standards Track [Page 9] RFC 6040 ECN Tunnelling November 2010

 be followed.  However, alternate ECN tunnelling schemes SHOULD be
 avoided whenever possible as the deployment burden of handling
 exceptional PHBs in implementations of all affected tunnels should
 not be underestimated.  There is no requirement for a PHB definition
 to state anything about ECN tunnelling behaviour if the default
 behaviour in the present specification is sufficient.

4.1. Default Tunnel Ingress Behaviour

 Two modes of encapsulation are defined here; a REQUIRED 'normal mode'
 and a 'compatibility mode', which is for backward compatibility with
 tunnel decapsulators that do not understand ECN.  Note that these are
 modes of the ingress tunnel endpoint only, not the whole tunnel.
 Section 4.3 explains why two modes are necessary and specifies the
 circumstances in which it is sufficient to solely implement normal
 mode.
 Whatever the mode, an encapsulator forwards the inner header without
 changing the ECN field.
 In normal mode, an encapsulator compliant with this specification
 MUST construct the outer encapsulating IP header by copying the
 two-bit ECN field of the incoming IP header.  In compatibility mode,
 it clears the ECN field in the outer header to the Not-ECT codepoint
 (the IPv4 header checksum also changes whenever the ECN field is
 changed).  These rules are tabulated for convenience in Figure 3.
          +-----------------+-------------------------------+
          | Incoming Header |    Departing Outer Header     |
          | (also equal to  +---------------+---------------+
          | departing Inner | Compatibility |    Normal     |
          |     Header)     |     Mode      |     Mode      |
          +-----------------+---------------+---------------+
          |    Not-ECT      |   Not-ECT     |   Not-ECT     |
          |     ECT(0)      |   Not-ECT     |    ECT(0)     |
          |     ECT(1)      |   Not-ECT     |    ECT(1)     |
          |       CE        |   Not-ECT     |      CE       |
          +-----------------+---------------+---------------+
            Figure 3: New IP in IP Encapsulation Behaviours

4.2. Default Tunnel Egress Behaviour

 To decapsulate the inner header at the tunnel egress, a compliant
 tunnel egress MUST set the outgoing ECN field to the codepoint at the
 intersection of the appropriate arriving inner header (row) and outer
 header (column) in Figure 4 (the IPv4 header checksum also changes

Briscoe Standards Track [Page 10] RFC 6040 ECN Tunnelling November 2010

 whenever the ECN field is changed).  There is no need for more than
 one mode of decapsulation, as these rules cater for all known
 requirements.
          +---------+------------------------------------------------+
          |Arriving |            Arriving Outer Header               |
          |   Inner +---------+------------+------------+------------+
          |  Header | Not-ECT | ECT(0)     | ECT(1)     |     CE     |
          +---------+---------+------------+------------+------------+
          | Not-ECT | Not-ECT |Not-ECT(!!!)|Not-ECT(!!!)| <drop>(!!!)|
          |  ECT(0) |  ECT(0) | ECT(0)     | ECT(1)     |     CE     |
          |  ECT(1) |  ECT(1) | ECT(1) (!) | ECT(1)     |     CE     |
          |    CE   |      CE |     CE     |     CE(!!!)|     CE     |
          +---------+---------+------------+------------+------------+
  The ECN field in the outgoing header is set to the codepoint at the
    intersection of the appropriate arriving inner header (row) and
    arriving outer header (column), or the packet is dropped where
 indicated.  Currently unused combinations are indicated by '(!!!)' or
                                 '(!)'
            Figure 4: New IP in IP Decapsulation Behaviour
 This table for decapsulation behaviour is derived from the following
 logic:
 o  If the inner ECN field is Not-ECT, the decapsulator MUST NOT
    propagate any other ECN codepoint onwards.  This is because the
    inner Not-ECT marking is set by transports that rely on dropped
    packets as an indication of congestion and would not understand or
    respond to any other ECN codepoint [RFC4774].  Specifically:
  • If the inner ECN field is Not-ECT and the outer ECN field is

CE, the decapsulator MUST drop the packet.

  • If the inner ECN field is Not-ECT and the outer ECN field is

Not-ECT, ECT(0), or ECT(1), the decapsulator MUST forward the

       outgoing packet with the ECN field cleared to Not-ECT.
 o  In all other cases where the inner supports ECN, the decapsulator
    MUST set the outgoing ECN field to the more severe marking of the
    outer and inner ECN fields, where the ranking of severity from
    highest to lowest is CE, ECT(1), ECT(0), Not-ECT.  This in no way
    precludes cases where ECT(1) and ECT(0) have the same severity;
 o  Certain combinations of inner and outer ECN fields cannot result
    from any transition in any current or previous ECN tunneling
    specification.  These currently unused (CU) combinations are

Briscoe Standards Track [Page 11] RFC 6040 ECN Tunnelling November 2010

    indicated in Figure 4 by '(!!!)' or '(!)', where '(!!!)' means the
    combination is CU and always potentially dangerous, while '(!)'
    means it is CU and possibly dangerous.  In these cases,
    particularly the more dangerous ones, the decapsulator SHOULD log
    the event and MAY also raise an alarm.
    Just because the highlighted combinations are currently unused,
    does not mean that all the other combinations are always valid.
    Some are only valid if they have arrived from a particular type of
    legacy ingress, and dangerous otherwise.  Therefore, an
    implementation MAY allow an operator to configure logging and
    alarms for such additional header combinations known to be
    dangerous or CU for the particular configuration of tunnel
    endpoints deployed at run-time.
    Alarms SHOULD be rate-limited so that the anomalous combinations
    will not amplify into a flood of alarm messages.  It MUST be
    possible to suppress alarms or logging, e.g., if it becomes
    apparent that a combination that previously was not used has
    started to be used for legitimate purposes such as a new standards
    action.
 The above logic allows for ECT(0) and ECT(1) to both represent the
 same severity of congestion marking (e.g., "not congestion marked").
 But it also allows future schemes to be defined where ECT(1) is a
 more severe marking than ECT(0), in particular, enabling the simplest
 possible encoding for PCN [PCN3in1] (see Section 5.3.2).  Treating
 ECT(1) as either the same as ECT(0) or as a higher severity level is
 explained in the discussion of the ECN nonce [RFC3540] in Section 8,
 which in turn refers to Appendix D.

4.3. Encapsulation Modes

 Section 4.1 introduces two encapsulation modes: normal mode, and
 compatibility mode, defining their encapsulation behaviour (i.e.,
 header copying or zeroing, respectively).  Note that these are modes
 of the ingress tunnel endpoint only, not the tunnel as a whole.
 To comply with this specification, a tunnel ingress MUST at least
 implement normal mode.  Unless it will never be used with legacy
 tunnel egress nodes (RFC 2003, RFC 2401, or RFC 2481 or the limited
 functionality mode of RFC 3168), an ingress MUST also implement
 compatibility mode for backward compatibility with tunnel egresses
 that do not propagate explicit congestion notifications [RFC4774].
 We can categorise the way that an ingress tunnel endpoint is paired
 with an egress as either static or dynamically discovered:

Briscoe Standards Track [Page 12] RFC 6040 ECN Tunnelling November 2010

 Static:  Tunnel endpoints paired together by prior configuration.
    Some implementations of encapsulator might always be statically
    deployed, and constrained to never be paired with a legacy
    decapsulator (RFC 2003, RFC 2401 or RFC 2481 or the limited
    functionality mode of RFC 3168).  In such a case, only normal mode
    needs to be implemented.
    For instance, IPsec tunnel endpoints compatible with RFC 4301
    invariably use Internet Key Exchange Protocol version 2 (IKEv2)
    [RFC5996] for key exchange, the original specification of which
    was introduced alongside RFC 4301.  Therefore, both endpoints of
    an RFC 4301 tunnel can be sure that the other end is compatible
    with RFC 4301, because the tunnel is only formed after IKEv2 key
    management has completed, at which point both ends will be
    compliant with RFC 4301 by definition.  Therefore an IPsec tunnel
    ingress does not need compatibility mode, as it will never
    interact with legacy ECN tunnels.  To comply with the present
    specification, it only needs to implement the required normal
    mode, which is identical to the pre-existing RFC 4301 behaviour.
 Dynamic Discovery:  Tunnel endpoints paired together by some form of
    tunnel endpoint discovery, typically finding an egress on the path
    taken by the first packet.
    This specification does not require or recommend dynamic discovery
    and it does not define how dynamic negotiation might be done, but
    it recognises that proprietary tunnel endpoint discovery protocols
    exist.  It therefore sets down some constraints on discovery
    protocols to ensure safe interworking.
    If dynamic tunnel endpoint discovery might pair an ingress with a
    legacy egress (RFC 2003, RFC 2401, or RFC 2481 or the limited
    functionality mode of RFC 3168), the ingress MUST implement both
    normal and compatibility mode.  If the tunnel discovery process is
    arranged to only ever find a tunnel egress that propagates ECN
    (RFC 3168 full functionality mode, RFC 4301, or this present
    specification), then a tunnel ingress can be compliant with the
    present specification without implementing compatibility mode.
    While a compliant tunnel ingress is discovering an egress, it MUST
    send packets in compatibility mode in case the egress it discovers
    is a legacy egress.  If, through the discovery protocol, the
    egress indicates that it is compliant with the present
    specification, with RFC 4301 or with RFC 3168 full functionality
    mode, the ingress can switch itself into normal mode.  If the
    egress denies compliance with any of these or returns an error

Briscoe Standards Track [Page 13] RFC 6040 ECN Tunnelling November 2010

    that implies it does not understand a request to work to any of
    these ECN specifications, the tunnel ingress MUST remain in
    compatibility mode.
 If an ingress claims compliance with this specification, it MUST NOT
 permanently disable ECN processing across the tunnel (i.e., only
 using compatibility mode).  It is true that such a tunnel ingress is
 at least safe with the ECN behaviour of any egress it may encounter,
 but it does not meet the central aim of this specification:
 introducing ECN support to tunnels.
 Instead, if the ingress knows that the egress does support
 propagation of ECN (full functionality mode of RFC 3168 or RFC 4301
 or the present specification), it SHOULD use normal mode, in order to
 support ECN where possible.  Note that this section started by saying
 an ingress "MUST implement" normal mode, while it has just said an
 ingress "SHOULD use" normal mode.  This distinction is deliberate, to
 allow the mode to be turned off in exceptional circumstances but to
 ensure all implementations make normal mode available.
 Implementation note:  If a compliant node is the ingress for multiple
    tunnels, a mode setting will need to be stored for each tunnel
    ingress.  However, if a node is the egress for multiple tunnels,
    none of the tunnels will need to store a mode setting, because a
    compliant egress only needs one mode.

4.4. Single Mode of Decapsulation

 A compliant decapsulator only needs one mode of operation.  However,
 if a compliant egress is implemented to be dynamically discoverable,
 it may need to respond to discovery requests from various types of
 legacy tunnel ingress.  This specification does not define how
 dynamic negotiation might be done by (proprietary) discovery
 protocols, but it sets down some constraints to ensure safe
 interworking.
 Through the discovery protocol, a tunnel ingress compliant with the
 present specification might ask if the egress is compliant with the
 present specification, with RFC 4301 or with RFC 3168 full
 functionality mode.  Or an RFC 3168 tunnel ingress might try to
 negotiate to use limited functionality or full functionality mode
 [RFC3168].  In all these cases, a decapsulating tunnel egress
 compliant with this specification MUST agree to any of these
 requests, since it will behave identically in all these cases.

Briscoe Standards Track [Page 14] RFC 6040 ECN Tunnelling November 2010

 If no ECN-related mode is requested, a compliant tunnel egress MUST
 continue without raising any error or warning, because its egress
 behaviour is compatible with all the legacy ingress behaviours that
 do not negotiate capabilities.
 A compliant tunnel egress SHOULD raise a warning alarm about any
 requests to enter modes it does not recognise but, for 'forward
 compatibility' with standards actions possibly defined after it was
 implemented, it SHOULD continue operating.

5. Updates to Earlier RFCs

5.1. Changes to RFC 4301 ECN Processing

 Ingress:  An RFC 4301 IPsec encapsulator is not changed at all by the
    present specification.  It uses the normal mode of the present
    specification, which defines packet encapsulation identically to
    RFC 4301.
 Egress:  An RFC 4301 egress will need to be updated to the new
    decapsulation behaviour in Figure 4, in order to comply with the
    present specification.  However, the changes are backward
    compatible; combinations of inner and outer that result from any
    protocol defined in the RFC series so far are unaffected.  Only
    combinations that have never been used have been changed,
    effectively adding new behaviours to RFC 4301 decapsulation
    without altering existing behaviours.  The following specific
    updates to Section 5.1.2 of RFC 4301 have been made:
  • The outer, not the inner, is propagated when the outer is

ECT(1) and the inner is ECT(0);

  • A packet with Not-ECT in the inner and an outer of CE is

dropped rather than forwarded as Not-ECT;

  • Certain combinations of inner and outer ECN field have been

identified as currently unused. These can trigger logging

       and/or raise alarms.
 Modes:  RFC 4301 tunnel endpoints do not need modes and are not
    updated by the modes in the present specification.  Effectively,
    an RFC 4301 IPsec ingress solely uses the REQUIRED normal mode of
    encapsulation, which is unchanged from RFC 4301 encapsulation.  It
    will never need the OPTIONAL compatibility mode as explained in
    Section 4.3.

Briscoe Standards Track [Page 15] RFC 6040 ECN Tunnelling November 2010

5.2. Changes to RFC 3168 ECN Processing

 Ingress:  On encapsulation, the new rule in Figure 3 that a normal
    mode tunnel ingress copies any ECN field into the outer header
    updates the full functionality behaviour of an RFC 3168 ingress
    (Section 9.1.1 of [RFC3168]).  Nonetheless, the new compatibility
    mode encapsulates packets identically to the limited functionality
    mode of an RFC 3168 ingress.
 Egress:  An RFC 3168 egress will need to be updated to the new
    decapsulation behaviour in Figure 4, in order to comply with the
    present specification.  However, the changes are backward
    compatible; combinations of inner and outer that result from any
    protocol defined in the RFC series so far are unaffected.  Only
    combinations that have never been used have been changed,
    effectively adding new behaviours to RFC 3168 decapsulation
    without altering existing behaviours.  The following specific
    updates to Section 9.1.1 of RFC 3168 have been made:
  • The outer, not the inner, is propagated when the outer is

ECT(1) and the inner is ECT(0);

  • Certain combinations of inner and outer ECN field have been

identified as currently unused. These can trigger logging

       and/or raise alarms.
 Modes:  An RFC 3168 ingress will need to be updated if it is to
    comply with the present specification, whether or not it
    implemented the optional full functionality mode of Section 9.1.1
    of RFC 3168.
    Section 9.1 of RFC 3168 defined a (required) limited functionality
    mode and an (optional) full functionality mode for a tunnel.  In
    RFC 3168, modes applied to both ends of the tunnel, while in the
    present specification, modes are only used at the ingress -- a
    single egress behaviour covers all cases.
    The normal mode of encapsulation is an update to the encapsulation
    behaviour of the full functionality mode of an RFC 3168 ingress.
    The compatibility mode of encapsulation is identical to the
    encapsulation behaviour of the limited functionality mode of an
    RFC 3168 ingress, except it is not always obligatory.
    The constraints on how tunnel discovery protocols set modes in
    Sections 4.3 and 4.4 are an update to RFC 3168, but they are
    unlikely to require code changes as they document existing safe
    practice.

Briscoe Standards Track [Page 16] RFC 6040 ECN Tunnelling November 2010

5.3. Motivation for Changes

 An overriding goal is to ensure the same ECN signals can mean the
 same thing whatever tunnels happen to encapsulate an IP packet flow.
 This removes gratuitous inconsistency, which otherwise constrains the
 available design space and makes it harder to design networks and new
 protocols that work predictably.

5.3.1. Motivation for Changing Encapsulation

 The normal mode in Section 4 updates RFC 3168 to make all IP-in-IP
 encapsulation of the ECN field consistent -- consistent with the way
 both RFC 4301 IPsec [RFC4301] and IP-in-MPLS or MPLS-in-MPLS
 encapsulation [RFC5129] construct the ECN field.
 Compatibility mode has also been defined so that an ingress compliant
 with a version of IPsec prior to RFC 4301 can still switch to using
 drop across a tunnel for backward compatibility with legacy
 decapsulators that do not propagate ECN.
 The trigger that motivated this update to RFC 3168 encapsulation was
 a Standards-Track proposal for pre-congestion notification (PCN
 [RFC5670]).  PCN excess-traffic-marking only works correctly if the
 ECN field is copied on encapsulation (as in RFC 4301 and RFC 5129);
 it does not work if ECN is reset (as in RFC 3168).  This is because
 PCN excess-traffic-marking depends on the outer header revealing any
 congestion experienced so far on the whole path, not just since the
 last tunnel ingress.
 PCN allows a network operator to add flow admission and termination
 for inelastic traffic at the edges of a Diffserv domain, but without
 any per-flow mechanisms in the interior and without the generous
 provisioning typical of Diffserv, aiming to significantly reduce
 costs.  The PCN architecture [RFC5559] states that RFC 3168 IP-in-IP
 tunnelling of the ECN field cannot be used for any tunnel ingress in
 a PCN domain.  Prior to the present specification, this left a stark
 choice between not being able to use PCN for inelastic traffic
 control or not being able to use the many tunnels already deployed
 for Mobile IP, VPNs, and so forth.
 The present specification provides a clean solution to this problem,
 so that network operators who want to use both PCN and tunnels can
 specify that every tunnel ingress in a PCN region must comply with
 this latest specification.
 Rather than allow tunnel specifications to fragment further into one
 for PCN, one for IPsec, and one for other tunnels, the opportunity
 has been taken to consolidate the diverging specifications back into

Briscoe Standards Track [Page 17] RFC 6040 ECN Tunnelling November 2010

 a single tunnelling behaviour.  Resetting ECN was originally
 motivated by a covert channel concern that has been deliberately set
 aside in RFC 4301 IPsec.  Therefore, the reset behaviour of RFC 3168
 is an anomaly that we do not need to keep.  Copying ECN on
 encapsulation is simpler than resetting.  So, as more tunnel
 endpoints comply with this single consistent specification,
 encapsulation will be simpler as well as more predictable.
 Appendix B assesses whether copying rather than resetting CE on
 ingress will cause any unintended side effects, from the three
 perspectives of security, control, and management.  In summary, this
 analysis finds that:
 o  From the control perspective, either copying or resetting works
    for existing arrangements, but copying has more potential for
    simplifying control and resetting breaks at least one proposal
    that is already on the Standards Track.
 o  From the management and monitoring perspective, copying is
    preferable.
 o  From the traffic security perspective (enforcing congestion
    control, mitigating denial of service, etc.), copying is
    preferable.
 o  From the information security perspective, resetting is
    preferable, but the IETF Security Area now considers copying
    acceptable given the bandwidth of a two-bit covert channel can be
    managed.
 Therefore, there are two points against resetting CE on ingress while
 copying CE causes no significant harm.

5.3.2. Motivation for Changing Decapsulation

 The specification for decapsulation in Section 4 fixes three problems
 with the pre-existing behaviours found in both RFC 3168 and RFC 4301:
 1.  The pre-existing rules prevented the introduction of alternate
     ECN semantics to signal more than one severity level of
     congestion [RFC4774], [RFC5559].  The four states of the two-bit
     ECN field provide room for signalling two severity levels in
     addition to not-congested and not-ECN-capable states.  But, the
     pre-existing rules assumed that two of the states (ECT(0) and
     ECT(1)) are always equivalent.  This unnecessarily restricts the
     use of one of four codepoints (half a bit) in the IP (v4 and v6)
     header.  The new rules are designed to work in either case;
     whether ECT(1) is more severe than or equivalent to ECT(0).

Briscoe Standards Track [Page 18] RFC 6040 ECN Tunnelling November 2010

     As explained in Appendix B.1, the original reason for not
     forwarding the outer ECT codepoints was to limit the covert
     channel across a decapsulator to 1 bit per packet.  However, now
     that the IETF Security Area has deemed that a two-bit covert
     channel through an encapsulator is a manageable risk, the same
     should be true for a decapsulator.
     As well as being useful for general future-proofing, this problem
     is immediately pressing for standardisation of pre-congestion
     notification (PCN), which uses two severity levels of congestion.
     If a congested queue used ECT(1) in the outer header to signal
     more severe congestion than ECT(0), the pre-existing
     decapsulation rules would have thrown away this congestion
     signal, preventing tunnelled traffic from ever knowing that it
     should reduce its load.
     Before the present specification was written, the PCN working
     group had to consider a number of wasteful or convoluted work-
     rounds to this problem.  Without wishing to disparage the
     ingenuity of these work-rounds, none were chosen for the
     Standards Track because they were either somewhat wasteful,
     imprecise, or complicated.  Instead, a baseline PCN encoding was
     specified [RFC5696] that supported only one severity level of
     congestion but allowed space for these work-rounds as
     experimental extensions.
     By far the simplest approach is that taken by the current
     specification: just to remove the covert channel blockages from
     tunnelling behaviour -- now deemed unnecessary anyway.  Then,
     network operators that want to support two congestion severity
     levels for PCN can specify that every tunnel egress in a PCN
     region must comply with this latest specification.  Having taken
     this step, the simplest possible encoding for PCN with two
     severity levels of congestion [PCN3in1] can be used.
     Not only does this make two congestion severity levels available
     for PCN, but also for other potential uses of the extra ECN
     codepoint (e.g., [VCP]).
 2.  Cases are documented where a middlebox (e.g., a firewall) drops
     packets with header values that were currently unused (CU) when
     the box was deployed, often on the grounds that anything
     unexpected might be an attack.  This tends to bar future use of
     CU values.  The new decapsulation rules specify optional logging
     and/or alarms for specific combinations of inner and outer
     headers that are currently unused.  The aim is to give
     implementers a recourse other than drop if they are concerned
     about the security of CU values.  It recognises legitimate

Briscoe Standards Track [Page 19] RFC 6040 ECN Tunnelling November 2010

     security concerns about CU values, but still eases their future
     use.  If the alarms are interpreted as an attack (e.g., by a
     management system) the offending packets can be dropped.
     However, alarms can be turned off if these combinations come into
     regular use (e.g., through a future standards action).
 3.  While reviewing currently unused combinations of inner and outer
     headers, the opportunity was taken to define a single consistent
     behaviour for the three cases with a Not-ECT inner header but a
     different outer.  RFC 3168 and RFC 4301 had diverged in this
     respect and even their common behaviours had never been
     justified.
     None of these combinations should result from Internet protocols
     in the RFC series, but future standards actions might put any or
     all of them to good use.  Therefore, it was decided that a
     decapsulator must forward a Not-ECT inner header unchanged when
     the arriving outer header is ECT(0) or ECT(1).  For safety, it
     must drop a combination of Not-ECT inner and CE outer headers.
     Then, if some unfortunate misconfiguration resulted in a
     congested router marking CE on a packet that was originally
     Not-ECT, drop would be the only appropriate signal for the egress
     to propagate -- the only signal a non-ECN-capable transport
     (Not-ECT) would understand.
     It may seem contradictory that the same argument has not been
     applied to the ECT(1) codepoint, given it is being proposed as an
     intermediate level of congestion in a scheme progressing through
     the IETF [PCN3in1].  Instead, a decapsulator must forward a
     Not-ECT inner unchanged when its outer is ECT(1).  The rationale
     for not dropping this CU combination is to ensure it will be
     usable if needed in the future.  If any misconfiguration led to
     ECT(1) congestion signals with a Not-ECT inner, it would not be
     disastrous for the tunnel egress to suppress them, because the
     congestion should then escalate to CE marking, which the egress
     would drop, thus at least preventing congestion collapse.
 Problems 2 and 3 alone would not warrant a change to decapsulation,
 but it was decided they are worth fixing and making consistent at the
 same time as decapsulation code is changed to fix problem 1 (two
 congestion severity levels).

Briscoe Standards Track [Page 20] RFC 6040 ECN Tunnelling November 2010

6. Backward Compatibility

 A tunnel endpoint compliant with the present specification is
 backward compatible when paired with any tunnel endpoint compliant
 with any previous tunnelling RFC, whether RFC 4301, RFC 3168 (see
 Section 3), or the earlier RFCs summarised in Appendix A (RFC 2481,
 RFC 2401, and RFC 2003).  Each case is enumerated below.

6.1. Non-Issues Updating Decapsulation

 At the egress, this specification only augments the per-packet
 calculation of the ECN field (RFC 3168 and RFC 4301) for combinations
 of inner and outer headers that have so far not been used in any IETF
 protocols.
 Therefore, all other things being equal, if an RFC 4301 IPsec egress
 is updated to comply with the new rules, it will still interwork with
 any ingress compliant with RFC 4301 and the packet outputs will be
 identical to those it would have output before (fully backward
 compatible).
 And, all other things being equal, if an RFC 3168 egress is updated
 to comply with the same new rules, it will still interwork with any
 ingress complying with any previous specification (both modes of RFC
 3168, both modes of RFC 2481, RFC 2401, and RFC 2003) and the packet
 outputs will be identical to those it would have output before (fully
 backward compatible).
 A compliant tunnel egress merely needs to implement the one behaviour
 in Section 4 with no additional mode or option configuration at the
 ingress or egress nor any additional negotiation with the ingress.
 The new decapsulation rules have been defined in such a way that
 congestion control will still work safely if any of the earlier
 versions of ECN processing are used unilaterally at the encapsulating
 ingress of the tunnel (any of RFC 2003, RFC 2401, either mode of RFC
 2481, either mode of RFC 3168, RFC 4301, and this present
 specification).

6.2. Non-Update of RFC 4301 IPsec Encapsulation

 An RFC 4301 IPsec ingress can comply with this new specification
 without any update and it has no need for any new modes, options, or
 configuration.  So, all other things being equal, it will continue to
 interwork identically with any egress it worked with before (fully
 backward compatible).

Briscoe Standards Track [Page 21] RFC 6040 ECN Tunnelling November 2010

6.3. Update to RFC 3168 Encapsulation

 The encapsulation behaviour of the new normal mode copies the ECN
 field, whereas an RFC 3168 ingress in full functionality mode reset
 it.  However, all other things being equal, if an RFC 3168 ingress is
 updated to the present specification, the outgoing packets from any
 tunnel egress will still be unchanged.  This is because all variants
 of tunnelling at either end (RFC 4301, both modes of RFC 3168, both
 modes of RFC 2481, RFC 2401, RFC 2003, and the present specification)
 have always propagated an incoming CE marking through the inner
 header and onward into the outgoing header; whether the outer header
 is reset or copied.  Therefore, if the tunnel is considered a black
 box, the packets output from any egress will be identical with or
 without an update to the ingress.  Nonetheless, if packets are
 observed within the black box (between the tunnel endpoints), CE
 markings copied by the updated ingress will be visible within the
 black box, whereas they would not have been before.  Therefore, the
 update to encapsulation can be termed 'black-box backward compatible'
 (i.e., identical unless you look inside the tunnel).
 This specification introduces no new backward compatibility issues
 when a compliant ingress talks with a legacy egress, but it has to
 provide similar safeguards to those already defined in RFC 3168.  RFC
 3168 laid down rules to ensure that an RFC 3168 ingress turns off ECN
 (limited functionality mode) if it is paired with a legacy egress
 (RFC 2481, RFC 2401, or RFC 2003), which would not propagate ECN
 correctly.  The present specification carries forward those rules
 (Section 4.3).  It uses compatibility mode whenever RFC 3168 would
 have used limited functionality mode, and their per-packet behaviours
 are identical.  Therefore, all other things being equal, an ingress
 using the new rules will interwork with any legacy tunnel egress in
 exactly the same way as an RFC 3168 ingress (still black-box backward
 compatible).

7. Design Principles for Alternate ECN Tunnelling Semantics

 This section is informative, not normative.
 Section 5 of RFC 3168 permits the Diffserv codepoint (DSCP)[RFC2474]
 to 'switch in' alternative behaviours for marking the ECN field, just
 as it switches in different per-hop behaviours (PHBs) for scheduling.
 [RFC4774] gives best current practice for designing such alternative
 ECN semantics and very briefly mentions in Section 5.4 that
 tunnelling needs to be considered.  The guidance below complements
 and extends RFC 4774, giving additional guidance on designing any
 alternate ECN semantics that would also require alternate tunnelling
 semantics.

Briscoe Standards Track [Page 22] RFC 6040 ECN Tunnelling November 2010

 The overriding guidance is: "Avoid designing alternate ECN tunnelling
 semantics, if at all possible".  If a scheme requires tunnels to
 implement special processing of the ECN field for certain DSCPs, it
 will be hard to guarantee that every implementer of every tunnel will
 have added the required exception or that operators will have
 ubiquitously deployed the required updates.  It is unlikely a single
 authority is even aware of all the tunnels in a network, which may
 include tunnels set up by applications between endpoints, or
 dynamically created in the network.  Therefore, it is highly likely
 that some tunnels within a network or on hosts connected to it will
 not implement the required special case.
 That said, if a non-default scheme for tunnelling the ECN field is
 really required, the following guidelines might prove useful in its
 design:
 On encapsulation in any alternate scheme:
    1.  The ECN field of the outer header ought to be cleared to Not-
        ECT ("00") unless it is guaranteed that the corresponding
        tunnel egress will correctly propagate congestion markings
        introduced across the tunnel in the outer header.
    2.  If it has established that ECN will be correctly propagated,
        an encapsulator also ought to copy incoming congestion
        notification into the outer header.  The general principle
        here is that the outer header should reflect congestion
        accumulated along the whole upstream path, not just since the
        tunnel ingress (Appendix B.3 on management and monitoring
        explains).
        In some circumstances (e.g., PCN [RFC5559] and perhaps some
        pseudowires [RFC5659]), the whole path is divided into
        segments, each with its own congestion notification and
        feedback loop.  In these cases, the function that regulates
        load at the start of each segment will need to reset
        congestion notification for its segment.  Often, the point
        where congestion notification is reset will also be located at
        the start of a tunnel.  However, the resetting function can be
        thought of as being applied to packets after the encapsulation
        function -- two logically separate functions even though they
        might run on the same physical box.  Then, the code module
        doing encapsulation can keep to the copying rule and the load
        regulator module can reset congestion, without any code in
        either module being conditional on whether the other is there.

Briscoe Standards Track [Page 23] RFC 6040 ECN Tunnelling November 2010

 On decapsulation in any alternate scheme:
    1.  If the arriving inner header is Not-ECT, the transport will
        not understand other ECN codepoints.  If the outer header
        carries an explicit congestion marking, the alternate scheme
        would be expected to drop the packet -- the only indication of
        congestion the transport will understand.  If the alternate
        scheme recommends forwarding rather than dropping such a
        packet, it will need to clearly justify this decision.  If the
        inner is Not-ECT and the outer carries any other ECN codepoint
        that does not indicate congestion, the alternate scheme can
        forward the packet, but probably only as Not-ECT.
    2.  If the arriving inner header is one other than Not-ECT, the
        ECN field that the alternate decapsulation scheme forwards
        ought to reflect the more severe congestion marking of the
        arriving inner and outer headers.
    3.  Any alternate scheme will need to define a behaviour for all
        combinations of inner and outer headers, even those that would
        not be expected to result from standards known at the time and
        even those that would not be expected from the tunnel ingress
        paired with the egress at run-time.  Consideration should be
        given to logging such unexpected combinations and raising an
        alarm, particularly if there is a danger that the invalid
        combination implies congestion signals are not being
        propagated correctly.  The presence of currently unused
        combinations may represent an attack, but the new scheme
        should try to define a way to forward such packets, at least
        if a safe outgoing codepoint can be defined.
        Raising an alarm allows a management system to decide whether
        the anomaly is indeed an attack, in which case it can decide
        to drop such packets.  This is a preferable approach to hard-
        coded discard of packets that seem anomalous today, but may be
        needed tomorrow in future standards actions.

8. Security Considerations

 Appendix B.1 discusses the security constraints imposed on ECN tunnel
 processing.  The new rules for ECN tunnel processing (Section 4)
 trade-off between information security (covert channels) and traffic
 security (congestion monitoring and control).  Ensuring congestion
 markings are not lost is itself an aspect of security, because if we
 allowed congestion notification to be lost, any attempt to enforce a
 response to congestion would be much harder.

Briscoe Standards Track [Page 24] RFC 6040 ECN Tunnelling November 2010

 Security issues in unlikely, but possible, scenarios:
 Tunnels intersecting Diffserv regions with alternate ECN semantics:
    If alternate congestion notification semantics are defined for a
    certain Diffserv PHB, the scope of the alternate semantics might
    typically be bounded by the limits of a Diffserv region or
    regions, as envisaged in [RFC4774] (e.g., the pre-congestion
    notification architecture [RFC5559]).  The inner headers in
    tunnels crossing the boundary of such a Diffserv region but ending
    within the region can potentially leak the external congestion
    notification semantics into the region, or leak the internal
    semantics out of the region.  [RFC2983] discusses the need for
    Diffserv traffic conditioning to be applied at these tunnel
    endpoints as if they are at the edge of the Diffserv region.
    Similar concerns apply to any processing or propagation of the ECN
    field at the endpoints of tunnels with one end inside and the
    other outside the domain.  [RFC5559] gives specific advice on this
    for the PCN case, but other definitions of alternate semantics
    will need to discuss the specific security implications in each
    case.
 ECN nonce tunnel coverage:  The new decapsulation rules improve the
    coverage of the ECN nonce [RFC3540] relative to the previous rules
    in RFC 3168 and RFC 4301.  However, nonce coverage is still not
    perfect, as this would have led to a safety problem in another
    case.  Both are corner-cases, so discussion of the compromise
    between them is deferred to Appendix D.
 Covert channel not turned off:  A legacy (RFC 3168) tunnel ingress
    could ask an RFC 3168 egress to turn off ECN processing as well as
    itself turning off ECN.  An egress compliant with the present
    specification will agree to such a request from a legacy ingress,
    but it relies on the ingress always sending Not-ECT in the outer
    header.  If the egress receives other ECN codepoints in the outer
    it will process them as normal, so it will actually still copy
    congestion markings from the outer to the outgoing header.
    Referring, for example, to Figure 5 (Appendix B.1), although the
    tunnel ingress 'I' will set all ECN fields in outer headers to
    Not-ECT, 'M' could still toggle CE or ECT(1) on and off to
    communicate covertly with 'B', because we have specified that 'E'
    only has one mode regardless of what mode it says it has
    negotiated.  We could have specified that 'E' should have a
    limited functionality mode and check for such behaviour.  However,
    we decided not to add the extra complexity of two modes on a
    compliant tunnel egress merely to cater for an historic security
    concern that is now considered manageable.

Briscoe Standards Track [Page 25] RFC 6040 ECN Tunnelling November 2010

9. Conclusions

 This document allows tunnels to propagate an extra level of
 congestion severity.  It uses previously unused combinations of inner
 and outer headers to augment the rules for calculating the ECN field
 when decapsulating IP packets at the egress of IPsec (RFC 4301) and
 non-IPsec (RFC 3168) tunnels.
 This document also updates the ingress tunnelling encapsulation of
 RFC 3168 ECN to bring all IP-in-IP tunnels into line with the new
 behaviour in the IPsec architecture of RFC 4301, which copies rather
 than resets the ECN field when creating outer headers.
 The need for both these updated behaviours was triggered by the
 introduction of pre-congestion notification (PCN) onto the IETF
 Standards Track.  Operators wanting to support PCN or other alternate
 ECN schemes that use an extra severity level can require that their
 tunnels comply with the present specification.  This is not a fork in
 the RFC series, it is an update that can be deployed first by those
 that need it, and subsequently by all tunnel endpoint implementations
 during general code maintenance.  It is backward compatible with all
 previous tunnelling behaviours, so existing single severity level
 schemes will continue to work as before, but support for two severity
 levels will gradually be added to the Internet.
 The new rules propagate changes to the ECN field across tunnel
 endpoints that previously blocked them to restrict the bandwidth of a
 potential covert channel.  Limiting the channel's bandwidth to two
 bits per packet is now considered sufficient.
 At the same time as removing these legacy constraints, the
 opportunity has been taken to draw together diverging tunnel
 specifications into a single consistent behaviour.  Then, any tunnel
 can be deployed unilaterally, and it will support the full range of
 congestion control and management schemes without any modes or
 configuration.  Further, any host or router can expect the ECN field
 to behave in the same way, whatever type of tunnel might intervene in
 the path.  This new certainty could enable new uses of the ECN field
 that would otherwise be confounded by ambiguity.

10. Acknowledgements

 Thanks to David Black for his insightful reviews and patient
 explanations of better ways to think about function placement and
 alarms.  Thanks to David and to Anil Agarwal for pointing out cases
 where it is safe to forward CU combinations of headers.  Also, thanks
 to Arnaud Jacquet for the idea for Appendix C.  Thanks to Gorry
 Fairhurst, Teco Boot, Michael Menth, Bruce Davie, Toby Moncaster,

Briscoe Standards Track [Page 26] RFC 6040 ECN Tunnelling November 2010

 Sally Floyd, Alfred Hoenes, Gabriele Corliano, Ingemar Johansson,
 Philip Eardley, and David Harrington for their thoughts and careful
 review comments, and to Stephen Hanna, Ben Campbell, and members of
 the IESG for respectively conducting the Security Directorate,
 General Area, and IESG reviews.
 Bob Briscoe is partly funded by Trilogy, a research project (ICT-
 216372) supported by the European Community under its Seventh
 Framework Programme.

11. References

11.1. Normative References

 [RFC2003]  Perkins, C., "IP Encapsulation within IP", RFC 2003,
            October 1996.
 [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
            Requirement Levels", BCP 14, RFC 2119, March 1997.
 [RFC3168]  Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
            of Explicit Congestion Notification (ECN) to IP",
            RFC 3168, September 2001.
 [RFC4301]  Kent, S. and K. Seo, "Security Architecture for the
            Internet Protocol", RFC 4301, December 2005.

11.2. Informative References

 [PCN3in1]  Briscoe, B., Moncaster, T., and M. Menth, "Encoding 3 PCN-
            States in the IP header using a single DSCP", Work
            in Progress, July 2010.
 [RFC2401]  Kent, S. and R. Atkinson, "Security Architecture for the
            Internet Protocol", RFC 2401, November 1998.
 [RFC2474]  Nichols, K., Blake, S., Baker, F., and D. Black,
            "Definition of the Differentiated Services Field (DS
            Field) in the IPv4 and IPv6 Headers", RFC 2474,
            December 1998.
 [RFC2481]  Ramakrishnan, K. and S. Floyd, "A Proposal to add Explicit
            Congestion Notification (ECN) to IP", RFC 2481,
            January 1999.
 [RFC2983]  Black, D., "Differentiated Services and Tunnels",
            RFC 2983, October 2000.

Briscoe Standards Track [Page 27] RFC 6040 ECN Tunnelling November 2010

 [RFC3540]  Spring, N., Wetherall, D., and D. Ely, "Robust Explicit
            Congestion Notification (ECN) Signaling with Nonces",
            RFC 3540, June 2003.
 [RFC4774]  Floyd, S., "Specifying Alternate Semantics for the
            Explicit Congestion Notification (ECN) Field", BCP 124,
            RFC 4774, November 2006.
 [RFC5129]  Davie, B., Briscoe, B., and J. Tay, "Explicit Congestion
            Marking in MPLS", RFC 5129, January 2008.
 [RFC5559]  Eardley, P., "Pre-Congestion Notification (PCN)
            Architecture", RFC 5559, June 2009.
 [RFC5659]  Bocci, M. and S. Bryant, "An Architecture for Multi-
            Segment Pseudowire Emulation Edge-to-Edge", RFC 5659,
            October 2009.
 [RFC5670]  Eardley, P., "Metering and Marking Behaviour of PCN-
            Nodes", RFC 5670, November 2009.
 [RFC5696]  Moncaster, T., Briscoe, B., and M. Menth, "Baseline
            Encoding and Transport of Pre-Congestion Information",
            RFC 5696, November 2009.
 [RFC5996]  Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,
            "Internet Key Exchange Protocol Version 2 (IKEv2)",
            RFC 5996, September 2010.
 [VCP]      Xia, Y., Subramanian, L., Stoica, I., and S. Kalyanaraman,
            "One more bit is enough", Proc. SIGCOMM'05, ACM
            CCR 35(4)37--48, 2005,
            <http://doi.acm.org/10.1145/1080091.1080098>.

Briscoe Standards Track [Page 28] RFC 6040 ECN Tunnelling November 2010

Appendix A. Early ECN Tunnelling RFCs

 IP-in-IP tunnelling was originally defined in [RFC2003].  On
 encapsulation, the incoming header was copied to the outer and on
 decapsulation, the outer was simply discarded.  Initially, IPsec
 tunnelling [RFC2401] followed the same behaviour.
 When ECN was introduced experimentally in [RFC2481], legacy (RFC 2003
 or RFC 2401) tunnels would have discarded any congestion markings
 added to the outer header, so RFC 2481 introduced rules for
 calculating the outgoing header from a combination of the inner and
 outer on decapsulation.  RFC 2481 also introduced a second mode for
 IPsec tunnels, which turned off ECN processing (Not-ECT) in the outer
 header on encapsulation because an RFC 2401 decapsulator would
 discard the outer on decapsulation.  For RFC 2401 IPsec, this had the
 side effect of completely blocking the covert channel.
 In RFC 2481, the ECN field was defined as two separate bits.  But
 when ECN moved from Experimental to Standards Track [RFC3168], the
 ECN field was redefined as four codepoints.  This required a
 different calculation of the ECN field from that used in RFC 2481 on
 decapsulation.  RFC 3168 also had two modes; a 'full functionality
 mode' that restricted the covert channel as much as possible but
 still allowed ECN to be used with IPsec, and another that completely
 turned off ECN processing across the tunnel.  This 'limited
 functionality mode' both offered a way for operators to completely
 block the covert channel and allowed an RFC 3168 ingress to interwork
 with a legacy tunnel egress (RFC 2481, RFC 2401, or RFC 2003).
 The present specification includes a similar compatibility mode to
 interwork safely with tunnels compliant with any of these three
 earlier RFCs.  However, unlike RFC 3168, it is only a mode of the
 ingress, as decapsulation behaviour is the same in either case.

Appendix B. Design Constraints

 Tunnel processing of a congestion notification field has to meet
 congestion control and management needs without creating new
 information security vulnerabilities (if information security is
 required).  This appendix documents the analysis of the trade-offs
 between these factors that led to the new encapsulation rules in
 Section 4.1.

B.1. Security Constraints

 Information security can be assured by using various end-to-end
 security solutions (including IPsec in transport mode [RFC4301]), but
 a commonly used scenario involves the need to communicate between two

Briscoe Standards Track [Page 29] RFC 6040 ECN Tunnelling November 2010

 physically protected domains across the public Internet.  In this
 case, there are certain management advantages to using IPsec in
 tunnel mode solely across the publicly accessible part of the path.
 The path followed by a packet then crosses security 'domains'; the
 ones protected by physical or other means before and after the tunnel
 and the one protected by an IPsec tunnel across the otherwise
 unprotected domain.  The scenario in Figure 5 will be used where
 endpoints 'A' and 'B' communicate through a tunnel.  The tunnel
 ingress 'I' and egress 'E' are within physically protected edge
 domains, while the tunnel spans an unprotected internetwork where
 there may be 'men in the middle', M.
              physically       unprotected     physically
          <-protected domain-><--domain--><-protected domain->
          +------------------+            +------------------+
          |                  |      M     |                  |
          |    A-------->I=========>==========>E-------->B   |
          |                  |            |                  |
          +------------------+            +------------------+
                         <----IPsec secured---->
                                 tunnel
                    Figure 5: IPsec Tunnel Scenario
 IPsec encryption is typically used to prevent 'M' seeing messages
 from 'A' to 'B'.  IPsec authentication is used to prevent 'M'
 masquerading as the sender of messages from 'A' to 'B' or altering
 their contents.  'I' can use IPsec tunnel mode to allow 'A' to
 communicate with 'B', but impose encryption to prevent 'A' leaking
 information to 'M'.  Or 'E' can insist that 'I' uses tunnel mode
 authentication to prevent 'M' communicating information to 'B'.
 Mutable IP header fields such as the ECN field (as well as the Time
 to Live (TTL) / Hop Limit and DS fields) cannot be included in the
 cryptographic calculations of IPsec.  Therefore, if 'I' copies these
 mutable fields into the outer header that is exposed across the
 tunnel it will have allowed a covert channel from 'A' to 'M' that
 bypasses its encryption of the inner header.  And if 'E' copies these
 fields from the outer header to the outgoing, even if it validates
 authentication from 'I', it will have allowed a covert channel from
 'M' to 'B'.
 ECN at the IP layer is designed to carry information about congestion
 from a congested resource towards downstream nodes.  Typically, a
 downstream transport might feed the information back somehow to the
 point upstream of the congestion that can regulate the load on the
 congested resource, but other actions are possible [RFC3168], Section
 6.  In terms of the above unicast scenario, ECN effectively intends

Briscoe Standards Track [Page 30] RFC 6040 ECN Tunnelling November 2010

 to create an information channel (for congestion signalling) from 'M'
 to 'B' (for 'B' to feed back to 'A').  Therefore, the goals of IPsec
 and ECN are mutually incompatible, requiring some compromise.
 With respect to using the DS or ECN fields as covert channels,
 Section 5.1.2 of RFC 4301 says, "controls are provided to manage the
 bandwidth of this channel".  Using the ECN processing rules of RFC
 4301, the channel bandwidth is two bits per datagram from 'A' to 'M'
 and one bit per datagram from 'M' to 'B' (because 'E' limits the
 combinations of the 2-bit ECN field that it will copy).  In both
 cases, the covert channel bandwidth is further reduced by noise from
 any real congestion marking.  RFC 4301 implies that these covert
 channels are sufficiently limited to be considered a manageable
 threat.  However, with respect to the larger (six-bit) DS field, the
 same section of RFC 4301 says not copying is the default, but a
 configuration option can allow copying "to allow a local
 administrator to decide whether the covert channel provided by
 copying these bits outweighs the benefits of copying".  Of course, an
 administrator who plans to copy the DS field has to take into account
 that it could be concatenated with the ECN field, creating a covert
 channel with eight bits per datagram.
 For tunnelling the six-bit Diffserv field, two conceptual models have
 had to be defined so that administrators can trade off security
 against the needs of traffic conditioning [RFC2983]:
 The uniform model:  where the Diffserv field is preserved end-to-end
    by copying into the outer header on encapsulation and copying from
    the outer header on decapsulation.
 The pipe model:  where the outer header is independent of that in the
    inner header so it hides the Diffserv field of the inner header
    from any interaction with nodes along the tunnel.
 However, for ECN, the new IPsec security architecture in RFC 4301
 only standardised one tunnelling model equivalent to the uniform
 model.  It deemed that simplicity was more important than allowing
 administrators the option of a tiny increment in security, especially
 given not copying congestion indications could seriously harm
 everyone's network service.

B.2. Control Constraints

 Congestion control requires that any congestion notification marked
 into packets by a resource will be able to traverse a feedback loop
 back to a function capable of controlling the load on that resource.
 To be precise, rather than calling this function the data source, it
 will be called the 'Load Regulator'.  This allows for exceptional

Briscoe Standards Track [Page 31] RFC 6040 ECN Tunnelling November 2010

 cases where load is not regulated by the data source, but usually the
 two terms will be synonymous.  Note the term "a function _capable of_
 controlling the load" deliberately includes a source application that
 doesn't actually control the load but ought to (e.g., an application
 without congestion control that uses UDP).
               A--->R--->I=========>M=========>E-------->B
                   Figure 6: Simple Tunnel Scenario
 A similar tunnelling scenario to the IPsec one just described will
 now be considered, but without the different security domains,
 because the focus now shifts to whether the control loop and
 management monitoring work (Figure 6).  If resources in the tunnel
 are to be able to explicitly notify congestion and the feedback path
 is from 'B' to 'A', it will certainly be necessary for 'E' to copy
 any CE marking from the outer header to the outgoing header for
 onward transmission to 'B'; otherwise, congestion notification from
 resources like 'M' cannot be fed back to the Load Regulator ('A').
 But it does not seem necessary for 'I' to copy CE markings from the
 incoming to the outer header.  For instance, if resource 'R' is
 congested, it can send congestion information to 'B' using the
 congestion field in the inner header without 'I' copying the
 congestion field into the outer header and 'E' copying it back to the
 outgoing header.  'E' can still write any additional congestion
 marking introduced across the tunnel into the congestion field of the
 outgoing header.
 All this shows that 'E' can preserve the control loop irrespective of
 whether 'I' copies congestion notification into the outer header or
 resets it.
 That is the situation for existing control arrangements but, because
 copying reveals more information, it would open up possibilities for
 better control system designs.  For instance, resetting CE marking on
 encapsulation breaks the Standards-Track PCN congestion marking
 scheme [RFC5670].  It ends up removing excessive amounts of traffic
 unnecessarily (Section 5.3.1).  Whereas copying CE markings at
 ingress leads to the correct control behaviour.

B.3. Management Constraints

 As well as control, there are also management constraints.
 Specifically, a management system may monitor congestion markings in
 passing packets, perhaps at the border between networks as part of a
 service level agreement.  For instance, monitors at the borders of

Briscoe Standards Track [Page 32] RFC 6040 ECN Tunnelling November 2010

 autonomous systems may need to measure how much congestion has
 accumulated so far along the path, perhaps to determine between them
 how much of the congestion is contributed by each domain.
 In this document, the baseline of congestion marking (or the
 Congestion Baseline) is defined as the source of the layer that
 created (or most recently reset) the congestion notification field.
 When monitoring congestion, it would be desirable if the Congestion
 Baseline did not depend on whether or not packets were tunnelled.
 Given some tunnels cross domain borders (e.g., consider 'M' in
 Figure 6 is monitoring a border), it would therefore be desirable for
 'I' to copy congestion accumulated so far into the outer headers, so
 that it is exposed across the tunnel.
 For management purposes, it might be useful for the tunnel egress to
 be able to monitor whether congestion occurred across a tunnel or
 upstream of it.  Superficially, it appears that copying congestion
 markings at the ingress would make this difficult, whereas it was
 straightforward when an RFC 3168 ingress reset them.  However,
 Appendix C gives a simple and precise method for a tunnel egress to
 infer the congestion level introduced across a tunnel.  It works
 irrespective of whether the ingress copies or resets congestion
 markings.

Appendix C. Contribution to Congestion across a Tunnel

 This specification mandates that a tunnel ingress determines the ECN
 field of each new outer tunnel header by copying the arriving header.
 Concern has been expressed that this will make it difficult for the
 tunnel egress to monitor congestion introduced only along a tunnel,
 which is easy if the outer ECN field is reset at a tunnel ingress
 (RFC 3168 full functionality mode).  However, in fact copying CE
 marks at ingress will still make it easy for the egress to measure
 congestion introduced across a tunnel, as illustrated below.
 Consider 100 packets measured at the egress.  Say it measures that 30
 are CE marked in the inner and outer headers and 12 have additional
 CE marks in the outer but not the inner.  This means packets arriving
 at the ingress had already experienced 30% congestion.  However, it
 does not mean there was 12% congestion across the tunnel.  The
 correct calculation of congestion across the tunnel is p_t = 12/
 (100-30) = 12/70 = 17%.  This is easy for the egress to measure.  It
 is simply the proportion of packets not marked in the inner header
 (70) that have a CE marking in the outer header (12).  This technique
 works whether the ingress copies or resets CE markings, so it can be
 used by an egress that is not sure with which RFC the ingress
 complies.

Briscoe Standards Track [Page 33] RFC 6040 ECN Tunnelling November 2010

 Figure 7 illustrates this in a combinatorial probability diagram.
 The square represents 100 packets.  The 30% division along the bottom
 represents marking before the ingress, and the p_t division up the
 side represents marking introduced across the tunnel.
      ^ outer header marking
      |
 100% +-----+---------+       The large square
      |     |         |       represents 100 packets
      | 30  |         |
      |     |         |   p_t = 12/(100-30)
  p_t +     +---------+       = 12/70
      |     |   12    |       = 17%
    0 +-----+---------+--->
      0    30%       100%  inner header marking
     Figure 7: Tunnel Marking of Packets Already Marked at Ingress

Appendix D. Compromise on Decap with ECT(1) Inner and ECT(0) Outer

 A packet with an ECT(1) inner and an ECT(0) outer should never arise
 from any known IETF protocol.  Without giving a reason, RFC 3168 and
 RFC 4301 both say the outer should be ignored when decapsulating such
 a packet.  This appendix explains why it was decided not to change
 this advice.
 In summary, ECT(0) always means 'not congested' and ECT(1) may imply
 the same [RFC3168] or it may imply a higher severity congestion
 signal [RFC4774], [PCN3in1], depending on the transport in use.
 Whether or not they mean the same, at the ingress the outer should
 have started the same as the inner, and only a broken or compromised
 router could have changed the outer to ECT(0).
 The decapsulator can detect this anomaly.  But the question is,
 should it correct the anomaly by ignoring the outer, or should it
 reveal the anomaly to the end-to-end transport by forwarding the
 outer?
 On balance, it was decided that the decapsulator should correct the
 anomaly, but log the event and optionally raise an alarm.  This is
 the safe action if ECT(1) is being used as a more severe marking than
 ECT(0), because it passes the more severe signal to the transport.
 However, it is not a good idea to hide anomalies, which is why an
 optional alarm is suggested.  It should be noted that this anomaly
 may be the result of two changes to the outer: a broken or
 compromised router within the tunnel might be erasing congestion
 markings introduced earlier in the same tunnel by a congested router.

Briscoe Standards Track [Page 34] RFC 6040 ECN Tunnelling November 2010

 In this case, the anomaly would be losing congestion signals, which
 needs immediate attention.
 The original reason for defining ECT(0) and ECT(1) as equivalent was
 so that the data source could use the ECN nonce [RFC3540] to detect
 if congestion signals were being erased.  However, in this case, the
 decapsulator does not need a nonce to detect any anomalies introduced
 within the tunnel, because it has the inner as a record of the header
 at the ingress.  Therefore, it was decided that the best compromise
 would be to give precedence to solving the safety issue over
 revealing the anomaly, because the anomaly could at least be detected
 and dealt with internally.
 Superficially, the opposite case where the inner and outer carry
 different ECT values, but with an ECT(1) outer and ECT(0) inner,
 seems to require a similar compromise.  However, because that case is
 reversed, no compromise is necessary; it is best to forward the outer
 whether the transport expects the ECT(1) to mean a higher severity
 than ECT(0) or the same severity.  Forwarding the outer either
 preserves a higher value (if it is higher) or it reveals an anomaly
 to the transport (if the two ECT codepoints mean the same severity).

Appendix E. Open Issues

 The new decapsulation behaviour defined in Section 4.2 adds support
 for propagation of two severity levels of congestion.  However,
 transports have no way to discover whether there are any legacy
 tunnels on their path that will not propagate two severity levels.
 It would have been nice to add a feature for transports to check path
 support, but this remains an open issue that will have to be
 addressed in any future standards action to define an end-to-end
 scheme that requires two severity levels of congestion.  PCN avoids
 this problem because it is only for a controlled region, so all
 legacy tunnels can be upgraded by the same operator that deploys PCN.

Author's Address

 Bob Briscoe
 BT
 B54/77, Adastral Park
 Martlesham Heath
 Ipswich  IP5 3RE
 UK
 Phone: +44 1473 645196
 EMail: bob.briscoe@bt.com
 URI:   http://bobbriscoe.net/

Briscoe Standards Track [Page 35]

/data/webs/external/dokuwiki/data/pages/rfc/rfc6040.txt · Last modified: 2010/11/30 05:35 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki