Internet DRAFT - draft-ipsec-ecn

draft-ipsec-ecn




INTERNET DRAFT
draft-ipsec-ecn-00.txt                                  February 1999





                      IPsec Interactions with ECN


                          Status of this Memo


   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet- Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

Abstract

   IPsec supports secure communication over potentially insecure network
   components such as intermediate routers.  IPsec protocols support two
   operating modes, transport mode and tunnel mode.  Explicit Congestion
   Notification (ECN) is an experimental addition to the IP architecture
   that provides indication of onset of congestion to delay- or loss-
   sensitive applications.  ECN provides the congestion indication so as
   to enable adaptation to network conditions without the impact of
   dropped packets [RFC 2481].  Currently, the way ECN is specified does
   not conform to the manner in which IPsec tunnels are defined to be
   used.  This document considers issues related to interactions between
   ECN and IPsec tunnel mode, and proposes two alternative solutions.




Floyd, Black, and Ramakrishnan                                  [Page 1]





draft-ipsec-ecn        IPsec Interactions with ECN         February 1999


1.  Introduction.

   IPsec supports secure communication over potentially insecure network
   components such as intermediate routers.  IPsec protocols support two
   operating modes, transport mode and tunnel mode that span a wide
   range of security requirements and operating environments.  Transport
   mode security protocol header(s) are inserted between the IP (IPv4 or
   IPv6) header and higher layer protocol headers (e.g., TCP), and hence
   transport mode can only be used for end-to-end security on a
   connection.  IPsec tunnel mode is based on adding a new "outer" IP
   header that encapsulates the original, or "inner" IP header and its
   associated packet.  Tunnel mode security headers are inserted between
   these two IP headers.  In contrast to transport mode, the new "outer"
   IP header and tunnel mode security headers may be added and removed
   at intermediate points along a connection, enabling security gateways
   to secure vulnerable portions of a connection without requiring
   endpoint participation in the security protocols.  An important
   aspect of tunnel mode security is that the outer header is discarded
   at tunnel egress, ensuring that security threats based on modifying
   the IP header do not propagate beyond that tunnel endpoint.  Further
   discussion of IPsec can be found in [RFC 2401].

   Explicit Congestion Notification (ECN) is an experimental addition to
   the IP architecture that provides congestion indication to delay- or
   loss-sensitive applications to enable them to adapt to network
   conditions without the impact of dropped packets [RFC 2481].  An ECN-
   capable router uses the ECN mechanism to signal congestion to
   connection endpoints by setting a bit in the IP header.  These
   endpoints then react as if a packet had been dropped (e.g., TCP
   halves its congestion window).  This ability to avoid dropping
   packets in response to congestion is supported by the use of active
   queue management mechanisms (e.g., RED) in routers; such mechanisms
   begin to mark or drop packets as a consequence of congestion before a
   congested router queue is completely full.  ECN is defined to be used
   as an optimization -- routers are not required to support ECN, and
   even an ECN-capable router may drop packets from ECN-capable
   connections when necessary.  The advantage to a router of not
   dropping such packets is that ECN can provide a more timely reaction
   to congestion than reactions based on drop detection via duplicate
   ACKs or timeout.

   Currently, the way ECN is specified does not conform to the manner in
   which IPsec tunnels are defined to be used.  Current use of ECN over
   an IPsec tunnel results in routers attempting to use the outer IP
   header to signal congestion to endpoints, but those congestion
   warnings never arrive because the outer header is discarded.  RFC
   2481 currently recommends that ECN not be used with IPsec tunnels in
   order to avoid this behavior and its consequences.



Floyd, Black, and Ramakrishnan                                  [Page 2]





draft-ipsec-ecn        IPsec Interactions with ECN         February 1999


   This document considers issues related to interactions between ECN
   and IPsec tunnel mode.  In principle the use of ECN in the outer
   header of an IPsec tunnel raises security concerns because an
   adversary could tamper with the ECN information that propagates
   beyond the tunnel endpoint.  Based on an analysis (included in this
   document) of these concerns and the resultant risks, our overall
   approach is to make support for ECN a configurable part of an IPsec
   tunnel mode Security Association (SA), so that ECN can be disabled
   for an IPsec tunnel in situations where the risks of using ECN are
   judged to outweigh its benefits.  The result is that the security
   administrator is presented with two options for the behavior of ECN-
   capable connections over an IPsec tunnel:
      - A limited-functionality option in which ECN is preserved in the
      inner header, but disabled in the outer header.  The only
      mechanism available for signaling congestion occurring within the
      tunnel in this case is dropped packets.
      - A full functionality option that supports ECN in both the inner
      and outer headers, and propagates congestion warnings from nodes
      within the tunnel to endpoints.

   Support for these options requires changes to IP header processing at
   tunnel ingress and egress.  A subset of these changes sufficient to
   support only the limited-functionality option SHOULD be applied to
   all IPsec implementations in order to eliminate the current
   incompatibility between ECN and IPsec tunnels.

   The main goal of this document is to give guidance about the
   tradeoffs between the limited-functionality and full-functionality
   options.  This includes a full discussion of the potential effects of
   an adversary's modifications of the CE and ECT bits.

2.  Architecture.

   ECN uses two bits in the IP header (ECT - ECN Capable Transport, CE -
   Congestion Experienced) for signaling between routers and connection
   endpoints, and uses two flags in the TCP header (ECN-Echo - Echo ECN
   bit in IP header, CWR - Congestion Window Reduced) for TCP-endpoint
   to TCP-endpoint signaling.  For a TCP connection, a typical sequence
   of events in an ECN-based reaction to congestion is as follows:
      - The ECT bit is set in all packets transmitted by the sender to
      indicate that ECN is supported on this TCP connection.
      - An ECN-capable router detects impending congestion and detects
      that the ECT bit is set in the packet it is about to drop.
      Instead of dropping the packet, the router sets the CE bit and
      forwards the packet.
      - The receiver receives the packet with CE set, and sets the ECN-
      Echo flag in its next TCP ACK sent to the sender.
      - The sender receives the TCP ACK with ECN-Echo set, and reacts to



Floyd, Black, and Ramakrishnan                                  [Page 3]





draft-ipsec-ecn        IPsec Interactions with ECN         February 1999


      the congestion as if a packet had been dropped.
      - The sender sets the CWR flag in the TCP header of the next
      packet sent to the receiver to acknowledge its receipt of and
      reaction to the ECN-Echo flag.

   Further details on ECN functionality including negotiation of ECN-
   capability as part of connection setup as well as the
   responsibilities and requirements of ECN-capable routers and
   transports can be found in [RFC2481].

   ECN interacts with IPsec tunnels because the two ECN bits in the IP
   header are in what IPsec refers to as the IPv4 TOS octet or IPv6
   Traffic Class octet; this field is copied or mapped from the inner IP
   header to the outer IP header at IPsec tunnel ingress, and the outer
   header's copy of this field is discarded at IPsec tunnel egress
   [RFC2401].  If an ECN-capable router were to set the CE (Congestion
   Experienced) bit in an IPsec-tunneled packet, this indication would
   be discarded at tunnel egress, losing the indication of congestion.
   As a consequence of this behavior, ECN usage over IPsec tunnels is
   not currently recommended [RFC2481].

   The IPsec limited-functionality option for ECN encapsulation is for
   the ECT bit in the outside (encapsulating) header to be off (i.e.,
   set to 0), regardless of the value of the ECT bit in the inside
   (encapsulated) header.  With this option, the ECN field in the inner
   header is not altered upon de-capsulation.  The disadvantage of this
   approach is that the flow does not have ECN support for that part of
   the path that is using IPsec tunneling, even if the encapsulated
   packet is ECN-Capable.  That is, if the encapsulated packet arrives
   at a congested router that is ECN-capable, and the router decides to
   drop or mark the packet as an indication of congestion to the end
   nodes, the router will not be permitted to set the CE bit in the
   packet header, but instead will have to drop the packet.

   The IPsec full-functionality option for ECN encapsulation follows the
   description in Section 10.1 of RFC 2481 of tunneling with ECN.  This
   option is to copy the ECT bit of the inside header to the outside
   header on encapsulation, and to OR the CE bit from the outer header
   with the CE bit of the inside header on decapsulation.  With the
   full-functionality option, a flow can take advantage of ECN for those
   parts of the path that might use IPsec tunneling.  The disadvantage
   of the full-functionality option is that IPsec cannot protect the
   flow from certain modifications to the ECN bits in the IP header
   within the tunnel.  The potential dangers from modifications to the
   ECN bits in the IP header are described in detail in Section 4 below.

   This document proposes minor changes to IPsec in order to enable ECN
   experimentation over IPsec tunnels, and avoid losing congestion



Floyd, Black, and Ramakrishnan                                  [Page 4]





draft-ipsec-ecn        IPsec Interactions with ECN         February 1999


   indications in the case that an ECN-capable router or routers are
   traversed by an IPsec tunnel carrying ECN-capable connections.  In
   summary, two changes are proposed to IPsec functionality:

      (1) Modify the handling of the IPv4 TOS octet and IPv6 Traffic
      Class octet at IPsec tunnel endpoints to prevent loss of
      congestion indications when an IPsec tunnel traverses an ECN-
      capable router.

      (2) Enable the endpoints of an IPsec tunnel to negotiate the usage
      of ECN in the outer headers of that tunnel based on security
      policy.  ECN is only used in the outer header of packets from
      connections that support ECN.

   The minimum required to make ECN usable with IPsec tunnels is a
   simplified version of the first change that prevents ECN from being
   enabled in the outer header of an IPsec tunnel.  Full support for ECN
   requires the ability to negotiate ECN usage between tunnel endpoints,
   including the ability of a security administrator to disable ECN in
   situations where she believes the risks (e.g., of lost congestion
   notifications) outweigh the benefits of ECN.

3.  IPsec Changes for ECN support

   This section describes the detailed changes for support of ECN over
   IPsec tunnels, including the negotiation of ECN support between
   tunnel endpoints.  In order to avoid the loss of congestion
   indication at tunnel egress, full ECN functionality for an IPsec
   tunnel requires that both ends of the tunnel agree that ECN is being
   used.  This is supported by three changes to IPsec:
      - A Security Association Database (SAD) field indicating whether
      tunnel encapsulation and decapsulation processing should allow or
      forbid ECN usage in the outer IP header.
      - A Security Association Attribute for negotiation of this SAD
      field between the two endpoints of an SA that supports tunnel
      mode.
      - Changes to tunnel mode encapsulation and decapsulation
      processing to allow or forbid ECN usage in the outer IP header
      based on the value of the SAD field.  When ECN usage is allowed in
      the outer IP header, ECT is set in the outer header for ECN-
      capable connections and congestion indications (CE bit) from such
      connections are propagated to the inner header at tunnel egress.

   The first two changes are OPTIONAL.  The encapsulation and
   decapsulation processing changes are RECOMMENDED, but MAY be
   implemented without the other two changes by assuming that ECN usage
   is always forbidden. These changes are covered in the following three
   subsections.



Floyd, Black, and Ramakrishnan                                  [Page 5]





draft-ipsec-ecn        IPsec Interactions with ECN         February 1999


3.1.1.  ECN Tunnel Security Association Database Field

   Full ECN functionality requires a new field be added to the SAD (see
   [RFC2401]):

      ECN Tunnel: allowed or forbidden.
      Indicates whether ECN-capable connections using this SA in tunnel
      mode may receive ECN congestion notifications for congestion
      occurring within the tunnel.  The allowed value enables ECN
      congestion notifications.  The forbidden value disables such
      notifications, causing all congestion to be indicated via dropped
      packets.

      [OPTIONAL.  The value of this field SHOULD be assumed to be
      forbidden in implementations that do not support it.]

   Support for this attribute REQUIRES that the SA specification in a
   Security Policy Database (SPD) entry support a corresponding
   attribute, and that this SPD attribute be covered by the SPD
   administrative interface described in Section 4.4.1 of [RFC2401].

3.1.2.  ECN Tunnel Security Association Attribute

   A new IPsec Security Association Attribute is defined to enable the
   use of ECN for IPsec tunnels to be negotiated (see [RFC2407]).  This
   attribute is OPTIONAL, although any implementation that supports it
   SHOULD also support the SAD field defined in Section 3.1.1.

   Attribute Type

           class               value           type
     -------------------------------------------------
     ECN Tunnel                TBD             Basic

   NB: The attribute identification value will be determined by IANA.

   Class Values

     ECN Tunnel

       Specifies whether ECN may be used with Tunnel Encapsulation Mode.
       This affects tunnel encapsulation and decapsulation processing -
       see Section 3.1.3.

       RESERVED          0
       Allowed           1
       Forbidden         2




Floyd, Black, and Ramakrishnan                                  [Page 6]





draft-ipsec-ecn        IPsec Interactions with ECN         February 1999


       Values 3-61439 are reserved to IANA.  Values 61440-65535 are for
       private use.

       If unspecified, the default shall be assumed to be Forbidden.

3.1.3. Changes to IPsec Tunnel Header Processing

   Subsequent to the publication of the IPsec RFCs, the TOS octet of
   IPv4 and the Traffic Class octet of IPv6 have been superseded by the
   DS Field octet as defined in [RFC2474].  The two ECN bits in the IP
   header, ECT and CE, occupy bits 6 and 7 of the DS Field octet
   [RFC2481].  For full ECN support the encapsulation and decapsulation
   processing for the IPv4 TOS field and the IPv6 Traffic Class field
   are changed from what is specified in [RFC2401] to the following:

                           <-- How Outer Hdr Relates to Inner Hdr -->
                           Outer Hdr at                 Inner Hdr at
      IPv4                 Encapsulator                 Decapsulator
        Header fields:     --------------------         ------------
          DS Field         constructed (5)              constructed (7)

      IPv6
        Header fields:
          DS Field         constructed (6)              constructed (7)

      (5)(6) Copy the Differentiated Services Codepoint (DSCP, bits
      0-5).  If the value of the ECN Tunnel field in the SAD entry for
      this SA is "allowed" and the value of ECT (bit 6) is 1 in the
      inner header, set ECT to 1 in the outer header, else set ECT to 0
      in the outer header.  Set CE (bit 7) to 0 in the outer header.

      (7) If the value of the ECN tunnel field in the SAD entry for this
      SA is "allowed" and the value of ECT (bit 6) in the inner header
      is 1, and the value of CE (bit 7) in the outer header is 1, then
      set CE to 1 in the inner header, else make no change to this field
      of the inner header.

   NB: (5) and (6) are identical to match usage in [RFC2401] where they
   are different.

   This description applies to implementations that support the ECN
   Tunnel field in the SAD; such implementations MUST implement this
   processing of the DS field instead of the processing of the IPv4 TOS
   octet and IPv6 Traffic Class octet defined in [RFC2401].  This
   constitutes complete ECN support for IPsec tunnels.

   An implementation that does not support the ECN Tunnel field in the
   SAD SHOULD implement processing of the DS Field by assuming that the



Floyd, Black, and Ramakrishnan                                  [Page 7]





draft-ipsec-ecn        IPsec Interactions with ECN         February 1999


   value of the ECN Tunnel field of the SAD is "forbidden" for every SA.
   In this case, the RECOMMENDED processing reduces to:

      (5)(6) Copy the Differentiated Services Codepoint (DSCP, bits
      0-5).  Set bits 6 and 7 (ECT and CE) of the DS field to zero.
      (7) Make no change to DS field in the inner header.

   This constitutes partial ECN support for IPsec tunnels.

   In addition, it is RECOMMENDED for that packets with ECN and CE both
   set to 1 in the outer header be dropped if they arrive on an SA that
   forbids or is assumed to forbid ECN usage in tunnel mode.  This
   applies to both the complete ECN support and partial ECN support
   implementation approaches.  This is motivated by backwards
   compatibility and is discussed further in Section 6.

4.  Possible Changes to the ECN Field

   This section considers the issues when a router is operating,
   possibly maliciously, to modify either of the bits in the ECN field.
   In this section we represent the ECN field in the IP header by the
   tuple (ECT bit, CE bit).  The ECT bit, when set to 1, indicates an
   ECN-Capable Transport.  The CE bit, when set to 1, indicates that
   Congestion was Experienced in the path.

   By tampering with the bits in the ECN field, an adversary (or a
   broken router) could do one or more of the following: erase the ECN
   congestion indication, falsely report congestion, disable ECN-
   Capability for an individual packet, or falsely indicate ECN-
   Capability.  We systematically examine the various cases by which the
   ECN field could be modified.  The important criterion we consider in
   determining the consequences of such modifications is whether it is
   likely to lead to poorer behavior in any dimension (throughput,
   delay, fairness or functionality) than if a router were to drop a
   packet.

4.1.  Erasing the Congestion Indication

   First, we consider the changes that a router could make that would
   result in effectively erasing the congestion indication after it had
   been set by a router upstream.  The convention followed is:
   (ECT, CE) of received packet -> (ECT, CE) of packet transmitted.

   (1, 1) -> (1, 0):  erase only the CE bit that was set.
   (1, 1) -> (0, 0): erase both the ECT bit and the CE bit.
   (1, 1) -> (0, 1): erase the ECT bit

   The first change turns off the CE bit after it has been set by some



Floyd, Black, and Ramakrishnan                                  [Page 8]





draft-ipsec-ecn        IPsec Interactions with ECN         February 1999


   upstream router along the path.  The consequence for the upstream
   router is that there is a potential for congestion to build for a
   time, because the congestion indication does not reach the source.
   However, the packet would be received and acknowledged.

   The potential effect of erasing the congestion indication is complex,
   and is discussed in depth in Section 5 below.  Note that the effect
   of erasing the congestion indication is different from dropping a
   packet in the network.  When a data packet is dropped, the drop is
   detected by the TCP sender, and interpreted as an indication of
   congestion.  Similarly, if a sufficient number of consecutive
   acknowledgement packets are dropped, causing the cumulative
   acknowledgement field not to be advanced at the sender, the sender is
   limited by the congestion window from sending additional packets, and
   ultimately the retransmit timer expires.

   In contrast, a systematic erasure of the CE bit by a downstream
   router can have the effect of causing a queue buildup at an upstream
   router, including the possible loss of packets due to buffer
   overflow.  There is a potential of unfairness in that another flow
   that goes through the congested router may react to the CE bit set
   while the flow that has the CE bit erased may see better performance.
   The limitations on this potential unfairness are discussed in more
   detail in Section 5 below.

   The second change is to turn off both the ECT and the CE bits, thus
   erasing the congestion indication and disabling ECN-Capability at the
   same time.  The third change turns off only the ECT bit, disabling
   ECN-Capability.  The proposal in this Internet Draft is for the
   receiver at the end of a tunnel to copy the CE bit, if set, from the
   outer header to the inner header during decapsulation, if the ECT bit
   in the inner header is set and the tunnel provides full ECN support.
   In this case, the third change within an IPsec tunnel would not erase
   the congestion indication, but would only disable ECN-Capability for
   that packet within the rest of the tunnel.  However, when performed
   outside of an IPsec tunnel, the third change would also effectively
   erase the congestion indication, because, from RFC 2481, an ECN field
   of (0, 1) is undefined.

   The `erasure' of the congestion indication is only effective if the
   packet does not end up being marked or dropped again by a downstream
   router.  With the first change, the packet remains ECN-Capable, and
   could be either marked or dropped by a downstream router as an
   indication of congestion.  With the second and third changes, the
   packet is no longer ECN-capable, and can therefore be dropped but not
   marked by a downstream router as an indication of congestion.





Floyd, Black, and Ramakrishnan                                  [Page 9]





draft-ipsec-ecn        IPsec Interactions with ECN         February 1999


4.2.  Falsely Reporting Congestion

   (1, 0) -> (1, 1)

   This change is to set the CE bit when the ECT bit was already set,
   even though there was no congestion.  This change does not affect the
   treatment of that packet along the rest of the path.  In particular,
   a router does not examine the CE bit in deciding whether to drop or
   mark an arriving packet.

   However, this could result in the application unnecessarily invoking
   end-to-end congestion control, and reducing its arrival rate.  By
   itself, this is no worse (for the application or for the network)
   than if the tampering router had actually dropped the packet.

4.3.  Disabling ECN-Capability

   (1, 0) -> (0, *)

   This change is to turn off the ECT bit of a packet that does not have
   the CE bit set.  (Section 4.1 discussed the case of turning off the
   ECT bit of a packet that does have the CE bit set.)  This means that
   if the packet later encounters congestion (e.g., by arriving to a RED
   queue with a moderate average queue size), it will be dropped instead
   of being marked.  By itself, this is no worse (for the application)
   than if the tampering router had actually dropped the packet.  The
   saving grace in this particular case is that there is no congested
   router upstream expecting a reaction from setting the CE bit.

4.4.  Falsely Indicating ECN-Capability

   This change is to incorrectly label a packet as ECN-Capable.

   (0, *) -> (1, 0);
   (0, *) -> (1, 1);

   If the packet later encounters moderate congestion at an ECN-Capable
   router, the router could set the CE bit instead of dropping the
   packet.  If the transport protocol in fact is not ECN-Capable, then
   the transport will never receive this indication of congestion, and
   will not reduce its sending rate in response.  The potential
   consequences of falsely indicating ECN-capability are discussed
   further in Section 5 below.

   If the packet never later encounters congestion at an ECN-Capable
   router, then the first of these two changes would have no effect.
   The second change, however, would have the effect of giving false
   reports of congestion to a monitoring device along the path.  If the



Floyd, Black, and Ramakrishnan                                 [Page 10]





draft-ipsec-ecn        IPsec Interactions with ECN         February 1999


   transport protocol is ECN-Capable, then the second of these two
   changes (when, for example, (0,0) was changed to (1,1)) could also
   have an effect at the transport level, by combining falsely
   indicating ECN-Capability with falsely reporting congestion.  For an
   ECN-capable transport, this would cause the transport to
   unnecessarily react to congestion.  In this particular case, the
   router that is incorrectly changing the ECN field could have dropped
   the packet. Thus for this case of an ECN-capable transport, the
   consequence of this change to the ECN field is no worse than dropping
   the packet.

4.5.   Changes with No Functional Effect

   (0, *) -> (0, *)

   The CE bit is ignored in a packet that does not have the ECT bit set.
   Thus, this change would have no effect, in terms of ECN.

4.6.  Information carried in the Transport Header

   For TCP, an ECN-capable TCP receiver informs its TCP peer that it is
   ECN-capable at the TCP level, using information in the TCP header at
   the time the connection is setup.  This document does not consider
   potential dangers introduced by changes in the transport header
   because the IPsec tunnel protects the transport header.

5.  Implications of Subverting End-to-End Congestion Control

   This section focuses on the potential repercussions of subverting
   end-to-end congestion control by either falsely indicating ECN-
   Capability, or by erasing the congestion indication in ECN (the CE-
   bit).  Subverting end-to-end congestion control by either of these
   two methods can have consequences both for the application and for
   the network.  We discuss these separately below.

   The first method to subvert end-to-end congestion control, falsely
   indicating ECN-Capability, effectively subverts end-to-end congestion
   control only if the packet later encounters congestion that results
   in the setting of the CE bit.  In this case, the transport protocol
   does not receive the indication of congestion from these downstream
   congested routers.

   The second method to subvert end-to-end congestion control, `erasing'
   the (set) CE bit in a packet, effectively subverts end-to-end
   congestion control only when the CE bit in the packet was set earlier
   by a congested router.  In this case, the transport protocol does not
   receive the indication of congestion from the upstream congested
   routers.



Floyd, Black, and Ramakrishnan                                 [Page 11]





draft-ipsec-ecn        IPsec Interactions with ECN         February 1999


   Either of these two methods of subverting end-to-end congestion
   control can potentially introduce more damage to the network (and
   possibly to the flow itself) than if the adversary had simply dropped
   packets from that flow.  However, as we discuss later in this section
   and in Section 7, this potential damage is limited.

5.1.  Implications for the Network and for Competing Flows

   The CE bit of the ECN field is only used by routers as an indication
   of congestion during periods of *moderate* congestion.  From RFC
   2481: "When severe congestion has occurred and the router's queue is
   full, then the router has no choice but to drop some packet when a
   new packet arrives." Although it is not explicitly mandated by RFC
   2481, the general guidelines are that a router should drop rather
   than mark packets during heavy congestion even if the router's queue
   is not yet full.  For example, for routers using active queue
   management based on RED, the router should drop rather than mark
   packets that arrive while the average queue sizes exceed the RED
   queue's maximum threshold.

   One consequence for the network of subverting end-to-end congestion
   control is that flows that do not receive the congestion indications
   from the network might increase their sending rate until they drive
   the network into heavier congestion.  Then, the congested router
   could begin to drop rather than mark arriving packets.  For flows
   that are not isolated by some form of per-flow scheduling or other
   per-flow mechanisms, but that are instead aggregated with other flows
   in a single queue in an undifferentiated fashion, this packet-
   dropping at the congested router would apply to all flows that share
   that queue.  Thus, the consequences would be to increase the level of
   congestion in the network.

   In some cases, the increase in the level of congestion will lead to a
   substantial buffer buildup at the congested queue that will be
   sufficient to drive the congested queue from the packet-marking to
   the packet-dropping regime.  This transition could occur either
   because of buffer overflow, or because of the active queue management
   policy described above that drops packets when the average queue is
   above RED's maximum threshold.  At this point, all flows, including
   the subverted flow, will begin to see packet drops instead of packet
   marks, and a malicious or broken router will no longer be able to
   `erase' these indications of congestion in the network.  If the end
   nodes are deploying appropriate end-to-end congestion control, then
   the subverted flow will reduce its arrival rate in response to
   congestion.  When the level of congestion is sufficiently reduced,
   the congested queue can return from the packet-dropping regime to the
   packet-marking regime.  The steady-state pattern could be one of the
   congested queue oscillating between these two regimes.



Floyd, Black, and Ramakrishnan                                 [Page 12]





draft-ipsec-ecn        IPsec Interactions with ECN         February 1999


   In other cases, the consequences of subverting end-to-end congestion
   control will not be severe enough to drive the congested link into
   sufficiently-heavy congestion that packets are dropped instead of
   being marked.  In this case, the implications for competing flows in
   the network will be a slightly-increased rate of packet marking or
   dropping, and a corresponding decrease in the bandwidth available to
   those flows.  This can be a stable state if the arrival rate of the
   subverted flow is sufficiently small, relative to the link bandwidth,
   that the average queue size at the congested router remains under
   control.  In particular, the subverted flow could have a limited
   bandwidth demand on the link at this router, while still getting more
   than its "fair" share of the link.  This limited demand could be due
   to a limited demand from the data source; a limitation from the TCP
   advertised window; a lower-bandwidth access pipe; or other factors.
   Thus the subversion of ECN-based congestion control can still lead to
   unfairness, which we believe is appropriate to note here.

   The threat to the network posed by the subversion of ECN-based
   congestion control in the network is essentially the same as the
   threat posed by an end-system that intentionally fails to cooperate
   with end-to-end congestion control.  The deployment of mechanisms in
   routers to address this threat is an open research question, and is
   discussed further in Section 7.

   Let us take the example described in Section 4.1, where the CE bit
   that was set in a packet is erased by the tunnel: {(1, 1) -> (1, 0)}.
   The consequence for the congested upstream router that set the CE bit
   is that this congestion indication does not reach the end nodes for
   that flow. The source (even one which is completely cooperative and
   not malicious) is thus allowed to continue to increase its sending
   rate (if it is a TCP flow, by increasing its congestion window).  The
   flow potentially achieves better throughput than the other flows that
   also share the congested router, especially if there are no policing
   mechanisms or per-flow queueing mechanisms at that router.  Consider
   the behavior of the other flows, especially if they are cooperative:
   that is, the flows that do not experience subverted end-to-end
   congestion control.  They are likely to reduce their load (e.g., by
   reducing their window size) on the congested router, thus benefiting
   our subverted flow. This results in unfairness.  As we discussed
   above, this unfairness could either be transient (because the
   congested queue is driven into the packet-marking regime),
   oscillatory (because the congested queue oscillated between the
   packet marking and the packet dropping regime), or more moderate but
   a persistent stable state (because the congested queue is never
   driven to the packet dropping regime).

   The results would be similar if the subverted flow was intentionally
   avoiding end-to-end congestion control.  One difference is that a



Floyd, Black, and Ramakrishnan                                 [Page 13]





draft-ipsec-ecn        IPsec Interactions with ECN         February 1999


   flow that is intentionally avoiding end-to-end congestion control at
   the end nodes can avoid end-to-end congestion control even when the
   congested queue is in packet-dropping mode, by refusing to reduce its
   sending rate in response to packet drops in the network.  Thus the
   problems for the network of the subversion of ECN-based congestion
   control are less severe than the problems caused by the intentional
   avoidance of end-to-end congestion control in the end nodes.  It is
   also the case that it is considerably more difficult to control the
   behavior of the end nodes than it is to control the behavior of the
   infrastructure itself.  This is not to say that the problems for the
   network posed by the network's subversion of ECN-based congestion
   control are small; just that they are dwarfed by the problems for the
   network posed by the subversion of either ECN-based or packet-based
   congestion control by the end nodes.

5.2.  Implications for the Subverted Flow

   When a source indicates that it is ECN-capable, there is an
   expectation that the routers in the network that are capable of
   participating in ECN will use the CE bit for indication of
   congestion. There is the potential benefit of using ECN in reducing
   the amount of packet loss (in addition to the reduced queueing delays
   because of active queue management policies).  When the packet flows
   through a tunnel where the nodes that the tunneled packets traverse
   are untrusted in some way, the expectation is that IPsec will protect
   the flow from subversion that results in undesirable consequences.

   In many cases, a subverted flow will benefit from the subversion of
   end-to-end congestion control for that flow in the network, by
   receiving more bandwidth that it would have otherwise, relative to
   competing non-subverted flows.  If the congested queue reaches the
   packet-dropping stage, then the subversion of end-to-end congestion
   control might or might not be of overall benefit to the subverted
   flow, depending on that flow's relative tradeoffs between throughput,
   loss, and delay.

   One form of subverting end-to-end congestion control is to falsely
   indicate ECN-capability by setting the ECT bit.  This has the
   consequence of downstream congested routers setting the CE bit in
   vain.  However, as we describe in the section below, if the ECT bit
   is changed in the IPsec tunnel, this can be detected at the egress
   point of the tunnel.

   The second form of subverting end-to-end congestion control is to
   erase the congestion indication, either by erasing the CE bit
   directly, or by erasing the ECT bit when the CE bit is already set.
   In this case, it is the upstream congested routers that set the CE
   bit in vain.  There are several possible scenarios for this



Floyd, Black, and Ramakrishnan                                 [Page 14]





draft-ipsec-ecn        IPsec Interactions with ECN         February 1999


   subversion of end-to-end congestion control within an IPsec tunnel.
   If the ECT bit is erased within an IPsec tunnel, then this can be
   detected at the egress point of the tunnel.  If the CE bit is set
   upstream of the IPsec tunnel, then any erasure of the outer header's
   CE bit within the tunnel will have no effect because the inner header
   preserves the set value of the CE bit.  However, if the CE bit is set
   within the tunnel, and erased either within or downstream of the
   tunnel, this is not necessarily detected at the egress point of the
   tunnel.

   With this subversion of end-to-end congestion control, an end-system
   transport does not respond to the congestion indication.  Along with
   the increased unfairness for the non-subverted flows described in the
   previous section, the congested router's queue could continue to
   build, resulting in packet loss at the congested router - which is a
   means for indicating congestion to the transport in any case.  In the
   interim, the flow might experience higher queueing delays, possibly
   along with an increased bandwidth relative to other non-subverted
   flows.  But transports do not inherently make assumptions of
   consistently experiencing carefully managed queueing in the path.  We
   believe that these forms of subverting end-to-end congestion control
   are no worse for the subverted flow than if the adversary had simply
   dropped the packets of that flow itself.

5.3.  Non-ECN-Based Methods of Subverting End-to-end Congestion Control

   We have shown that, in many cases, a malicious or broken router that
   is able to change the bits in the ECN field can do no more damage
   than if it had simply dropped the packet in question.  However, this
   is not true in all cases, in particular in the cases where the broken
   router subverted end-to-end congestion control by either falsely
   indicating ECN-Capability or by erasing the ECN congestion indication
   (in the CE-bit).  While there are many ways that a router can harm a
   flow by dropping packets, a router cannot subvert end-to-end
   congestion control by dropping packets.  As an example, a router
   cannot subvert TCP congestion control by dropping data packets,
   acknowledgement packets, or control packets.

   Even though packet-dropping cannot be used to subvert end-to-end
   congestion control, there *are* non-ECN-based methods for subverting
   end-to-end congestion control that a broken or malicious router could
   use.  For example, a broken router could duplicate data packets, thus
   effectively negating the effects of end-to-end congestion control
   along some portion of the path.  (For a router that duplicated
   packets within an IPsec tunnel, the security administrator can cause
   the duplicate packets to be discarded by configuring anti-replay
   protection for the tunnel.)  This duplication of packets within the
   network would have similar implications for the network and for the



Floyd, Black, and Ramakrishnan                                 [Page 15]





draft-ipsec-ecn        IPsec Interactions with ECN         February 1999


   subverted flow as those described in Sections 5.1 and 5.2 above.

6.   Changes to the ECN Field within an IPsec Tunnel.

   The presence of a copy of the ECN field in the inner header of an
   IPsec tunnel mode packet provides an opportunity for detection of
   modifications to the ECT bit in the outer header.  Comparison of the
   ECT bits in the inner and outer headers falls into two categories for
   implementations that conform to this document:
      (a) If the SA allows ECN usage within the tunnel, then the values
      of the ECT bits in the inner and outer headers should be
      identical.
      (b) If the SA disallows ECN usage within the tunnel, then the ECT
      bit in the outer header should be 0.

   Receipt of a packet not satisfying the appropriate condition for its
   SA is an auditable event, but an implementation MAY create audit
   records with per-SA counts of incorrect packets over some time period
   rather than creating an audit record for each erroneous packet.  Any
   such audit record SHOULD contain the headers from at least one
   erroneous packet, but need not contain the headers from every packet
   represented by the entry.

   An important and likely situation involves an IPsec implementation
   not updated to this document's requirements serving as tunnel ingress
   for a tunnel egress at an implementation that has been updated.  The
   ECN Tunnel attribute cannot be negotiated in this case because the
   tunnel ingress implementation does not support it.  If packets from
   an ECN-capable connection use this tunnel, ECT will be set in the
   outer header independent of the SA.  Congestion along the route may
   then result in ECN-capable routers setting CE in the outer header.
   All packets arriving at the tunnel egress on this SA will appear to
   be case (b) errors, but should be processed according to whether CE
   was set.  Therefore it is RECOMMENDED that packets violating the
   condition for case (b) above be dropped if CE is set to 1 in the
   outer header and forwarded if CE is 0 in the outer header.

   An IPsec tunnel cannot provide protection against erasure of
   congestion indications or false reports of congestion based on
   flipping the value of the CE bit in packets for which ECT is set in
   the outer header.  As described in Section 5, false reports of
   congestion are equivalent to dropping the packet, an action against
   which IPsec also provides no protection.  On the other hand, erasure
   of congestion indications may impact the network and other flows in
   ways that would not be possible in the absence of ECN.  It is
   important to note that erasure of congestion indications can only be
   performed to congestion indications placed by nodes within the
   tunnel; the copy of the CE bit in the inner header preserves



Floyd, Black, and Ramakrishnan                                 [Page 16]





draft-ipsec-ecn        IPsec Interactions with ECN         February 1999


   congestion notifications from nodes upstream of the tunnel ingress.
   If erasure of congestion notifications is judged to be a security
   risk that exceeds the congestion management benefits of ECN, the
   security administrator should configure the appropriate tunnel SAs to
   forbid ECN usage in the outer header.

7.  Issues Raised by Monitoring and Policing Devices

   One possibility is that monitoring and policing devices (or more
   informally, ``penalty boxes'') will be installed in the network to
   monitor whether best-effort flows are appropriately responding to
   congestion, and to preferentially drop packets from flows determined
   not to be using adequate end-to-end congestion control procedures.
   [FF98] proposes three potential classifications for high-bandwidth
   flows in times in congestion:  (1)  flows that are not TCP-friendly,
   in that the arrival rate from that flow exceeds the arrival rate of a
   conformant TCP connection under the same conditions; (2) flows that
   are unresponsive, in that they do not decrease their arrival rate
   appropriately in response to an increase in congestion;  and (3)
   flows using disproportionate bandwidth, defined as flows using a
   significantly larger share of bandwidth than other flows in times of
   high congestion.  The methods of identifying and classifying flows to
   be in one of these three categories is outside the scope of this
   discussion.

   [FF98] proposes that flows that are simply determined to be using
   disproportionate bandwidth could have their bandwidth restricted, in
   much the same way that a round-robin per-flow scheduling algorithm
   would restrict the bandwidth received by individual flows, while
   flows determined to be unresponsive or not TCP-friendly in times of
   congestion could have their bandwidth even more strongly reduced, as
   a concrete incentive to end nodes to use end-to-end congestion
   control.

   For an ECN-capable flow, an `ideal' penalty box at a router would be
   a device that, when it detected that a flow was not responding to ECN
   indications, would switch to dropping, instead of marking, those
   packets of a flow that would otherwise have been chosen to carry
   indications of congestion.  In this way, these congestion indications
   could not be `erased' later in the network, and at the same time
   there would be no change in the router's treatment of packets of
   other flows.  If a router determines that a flow is still not
   responding to congestion indications, when the congestion indications
   consist of packet drops, then the router could take whatever action
   it deems appropriate for that flow.

   We recommend that any ``penalty box'' that detects a flow or an
   aggregate of flows that is not responding to end-to-end congestion



Floyd, Black, and Ramakrishnan                                 [Page 17]





draft-ipsec-ecn        IPsec Interactions with ECN         February 1999


   control first change from marking to dropping packets from that flow,
   before taking any additional action to restrict the bandwidth
   available to that flow.  Thus, initially, the router may drop packets
   in which the router would otherwise would have set the CE bit.  This
   could include dropping those arriving packets for that flow that are
   ECN-Capable and that already have the CE bit set.  In this way, any
   congestion indications seen by that router for that flow will be
   guaranteed to also be seen by the end nodes, even in the presence of
   malicious or broken routers elsewhere in the path.  If we assume that
   the first action taken at any ``penalty box'' for an ECN-capable flow
   will be to drop packets instead of marking them, then there is no way
   that an adversary that subverts ECN-based end-to-end congestion
   control can cause a flow to be characterized as being non-cooperative
   and placed into a more severe action within the ``penalty box''.

   The monitoring and policing devices that are actually deployed could
   fall short of the `ideal' monitoring device described above, in that
   the monitoring is applied not to a single flow or to a single IPsec
   tunnel, but to an aggregate of flows.  In this case, the switch from
   marking to dropping would apply to all of the flows in that
   aggregate, denying the benefits of ECN to the other flows in the
   aggregate also.  At the highest level of aggregation, another form of
   the disabling of ECN happens even in the absence of monitoring and
   policing devices, when ECN-Capable RED queues switch from marking to
   dropping packets as an indication of congestion when the average
   queue size has exceeded some threshold.

7.1. Complications Introduced by Split Paths

   If a router or other network element has access to all of the packets
   of a flow, then that router could do no more damage to a flow by
   altering the ECN field that it could by simply dropping all of the
   packets from that flow.  However, in some cases, a malicious or
   broken router might have access to only a subset of the packets from
   a flow.  The question is as follows:  can this router, by altering
   the ECN field in this subset of the packets, do more damage to that
   flow than if it has simply dropped that set of the packets?

   We will classify the packets in the flow as A packets and B packets,
   and assume that the adversary only has access to A packets.  Assume
   that the adversary is subverting end-to-end congestion control along
   the path traveled by A packets only, by either falsely indicating
   ECN-Capability upstream of the point where congestion occurs, or
   erasing the congestion indication downstream.  Consider also that
   there exists a monitoring device that sees both the A and B packets,
   and will "punish" both the A and B packets if the total flow is
   determined not to be properly responding to indications of
   congestion.  Another key characteristic that we believe is likely to



Floyd, Black, and Ramakrishnan                                 [Page 18]





draft-ipsec-ecn        IPsec Interactions with ECN         February 1999


   be true is that the monitoring device, before ``punishing'' the A&B
   flow, will first drop packets instead of setting the CE bit, and will
   drop arriving packets of that flow that already have the ECT and CE
   bits set.  If the end nodes are in fact using end-to-end congestion
   control, they will see all of the indications of congestion seen by
   the monitoring device, and will begin to respond to these indications
   of congestion. Thus, the monitoring device is successful in providing
   the indications to the flow at an early stage.

   It is true that the adversary that has access only to the A packets
   might, by subverting ECN-based congestion control, be able to deny
   the benefits of ECN to the other packets in the A&B aggregate.  While
   this is unfortunate, this is not a reason disable ECN within an IPsec
   tunnel.

   A variant of falsely reporting congestion occurs when there are two
   adversaries along a path, where the first adversary falsely reports
   congestion, and the second adversary `erases' those reports.  (Unlike
   packet drops, ECN congestion reports can be `reversed' later in the
   network by a malicious or broken router.)  While this would be
   transparent to the end node, it is possible that a monitoring device
   between the first and second adversaries would see the false
   indications of congestion.  Given our recommendation in this
   document, before `punishing' a flow for not responding appropriately
   to congestion, the router will first switch to dropping rather than
   marking as an indication of congestion, for that flow.  When this
   includes dropping arriving packets from that flow that have the CE
   bit set, this ensures that these indications of congestion are being
   seen by the end nodes.  Thus, there is no additional harm that we are
   able to postulate as a result of multiple conflicting adversaries.

8.  Conclusions.

   When ECN (Explicit Congestion Notification [RFC2481]) is used, it is
   desirable that congestion indications generated within an IPsec
   tunnel not be lost at the tunnel egress.  We propose a minor
   modification to the IPsec protocol's handling of the ECN field during
   encapsulation and de-capsulation to allow flows that will undergo
   IPsec tunneling to use ECN.

   Two options were proposed:
   1) A preferred alternative, which is the full-functionality option as
   described in RFC 2481. This copies the ECT bit of the inner header to
   the encapsulating header. At decapsulation, if the ECT bit is set in
   the inner header, the CE bit on the outer header is ORed with the CE
   bit of the inner header to update the CE bit of the packet.  2) A
   limited-functionality option that does not use ECN inside the IPsec
   tunnel, by turning the ECT bit in the outer header off, and not



Floyd, Black, and Ramakrishnan                                 [Page 19]





draft-ipsec-ecn        IPsec Interactions with ECN         February 1999


   altering the inner header at the time of decapsulation.

   We also proposed a new IPsec SA attribute to support negotiation of
   ECN support for tunnels between tunnel end-points and a new field in
   the Security Association database to indicate whether ECN is
   supported in tunnel mode on a SA.

   We examined the consequence of modifications of the ECN field within
   the tunnel, analyzing all the opportunities for an adversary to
   change the ECN field.  In many cases, the change to the ECN field is
   no worse than dropping a packet. However, we noted that some changes
   have the more serious consequence of subverting end-to-end congestion
   control.  However, we point out that even then the potential damage
   is limited, and is similar to the threat posed by an end-system
   intentionally failing to cooperate with end-to-end congestion
   control.

   We therefore believe that with these changes it is reasonable to use
   ECN with IPsec tunnels, as described in RFC 2481.

9. Acknowledgements

   We thank Steve Bellovin and Vern Paxson for discussions of these
   matters.



























Floyd, Black, and Ramakrishnan                                 [Page 20]





draft-ipsec-ecn        IPsec Interactions with ECN         February 1999


10. References

   [FF98] Floyd, S., and Fall, K., Promoting the Use of End-to-End
   Congestion Control in the Internet. Under submission, February 1998.
   URL "http://www-nrg.ee.lbl.gov/floyd/end2end-paper.html".

   [RFC 2401] S. Kent, R. Atkinson, Security Architecture for the
   Internet Protocol, RFC 2401, November 1998.

   [RFC2407] D. Piper, The Internet IP Security Domain of Interpretation
   for ISAKMP, RFC 2407, November 1998.

   [RFC2474] K. Nichols, S. Blake, F. Baker, D. Black, Definition of the
   Differentiated Services Field (DS Field) in the IPv4 and IPv6
   Headers, RFC 2474, December 1998.

   [RFC2481] K. Ramakrishnan, S. Floyd, A Proposal to add Explicit
   Congestion Notification (ECN) to IP, RFC 2481, January 1999.

11. Security Considerations

   Security considerations have been addressed in the main body of the
   document.

AUTHORS' ADDRESSES


   Sally Floyd
   AT&T Center for Internet Research at ICSI (ACIRI)
   Phone: +1 (510) 642-4274 x189
   Email: floyd@aciri.org
   URL: http://www-nrg.ee.lbl.gov/floyd/

   David L. Black
   EMC Corporation
   42 South St.
   Hopkinton, MA  01748
   Phone:  +1-508-435-1000 x75140
   EMail: black_david@emc.com

   K. K. Ramakrishnan
   AT&T Labs. Research
   Phone: +1 (973) 360-8766
   Email: kkrama@research.att.com
   URL: http://www.research.att.com/info/kkrama

   This draft was created in February 1999.
   It expires August 1999.



Floyd, Black, and Ramakrishnan                                 [Page 21]





draft-ipsec-ecn        IPsec Interactions with ECN         February 1999





















































Floyd, Black, and Ramakrishnan                                 [Page 22]