9.1 IP packets encapsulated in IP

9.1 IP packets encapsulated in IP

IP packet header encapsulation is used in tunnels in many places, including IPsec and IP in IP [RFC2003]. This section considers issues related to the interaction between ECN and IP tunnels, and specifies two alternative solutions. This discussion is complemented by RFC 2983's discussion of the interaction between Differentiated Services and various forms of IP tunnels [RFC2983], since Differentiated Services uses the remaining six bits of the IP header byte used by ECN (see Figure 2 in Section 5).

Some IP tunneling modes are based on adding a new "outer" IP header that encapsulates the original or "inner" IP header and its associated packet. In many cases, the new "outer" IP header can be added and removed at intermediate points along the connection, allowing the network to establish tunnels without requiring endpoint participation. We will refer to tunnels that discard the outer header at the tunnel egress as "simple tunnels".

ECN uses the ECN field in the IP header for signaling between routers and connection endpoints. ECN interacts with IP tunnels based on the treatment of the ECN field in the IP header within IP tunnels. In a simple IP tunnel, the byte containing the ECN field is either copied or mapped from the inner IP header to the outer IP header at the IP tunnel entrance, and the copy of this field in the outer header is discarded at the IP tunnel exit. If the outer header is simply discarded without attention to processing the ECN field, and an ECN-capable router sets the CE (Congestion Experienced) codepoint in a packet within a simple IP tunnel, this indication will be discarded at the tunnel exit, losing the congestion indication.

Therefore, use of ECN over a simple IP tunnel will result in routers attempting to use the outer IP header to send congestion signals to endpoints, but these congestion warnings never arrive because the outer header is discarded at the tunnel egress point. RFC 2481 encountered this problem of ECN and IPsec in tunnel mode, and recommended not using ECN with older simple IPsec tunnels to avoid this behavior and its consequences. When ECN is widely deployed, simple tunnels that may carry ECN-capable traffic will have to be modified. If ECN-capable traffic is transmitted through a simple tunnel with a congested ECN-capable router, this may result in subsequent packets of that flow being dropped as the average queue size at the congested router increases, as discussed in Section 8 above.

From a security perspective, the use of ECN in the outer header of IP tunnels may raise security concerns because adversaries may tamper with ECN information that propagates beyond the tunnel endpoints. Based on the analysis of these issues and resulting risks in Sections 18 and 19, our overall approach is to make support for ECN an option for IP tunnels, so that IP tunnels can be specified or configured to use or not use ECN in the outer header of the tunnel. Thus, in environments or tunnel protocols where the risks of using ECN are considered to exceed its benefits, tunnels can simply not use ECN in the outer header. The only indication of congestion experienced at routers within the tunnel will then be through packet drops.

As a result, there are two viable options for the behavior of ECN-capable connections over IP tunnels (including IPsec tunnels):

• The limited-functionality option, where ECN is preserved in the inner header but disabled in the outer header. In this case, the only mechanism for indicating congestion occurring within the tunnel is lost packets.

• The full-functionality option, where ECN is supported in both inner and outer headers, and congestion warnings from nodes within the tunnel are propagated to the endpoints.

Supporting these options requires different degrees of changes to IP header processing at tunnel entrances and exits. A small subset of these changes required to support only the limited-functionality option is sufficient to eliminate any incompatibility between ECN and IP tunnels.

One goal of this document is to provide guidance on the tradeoffs between the limited-functionality and full-functionality options. Sections 18 and 19 discuss in detail the potential impact of adversaries modifying the ECN field.