9.2.1.3 Changes to IPsec Tunnel Header Processing

This section describes the changes to IPsec tunnel mode header processing required to support ECN. These changes modify the procedures specified in [RFC2401] for handling the TOS/Traffic Class byte during encapsulation and decapsulation.

Encapsulation (Tunnel Entrance)

When encapsulating a packet at the tunnel entrance, the tunnel endpoint MUST:

Check the ECN_TUNNEL field in the SA Database for this SA
If ECN_TUNNEL indicates "not permitted":
- Set the ECN field in the outer header to not-ECT (00)
- Do not change the ECN field in the inner header
If ECN_TUNNEL indicates "permitted":
- Apply the full-functionality option as specified in Section 9.1.1:
  - If the inner header ECN field is not-ECT or ECT, copy it to the outer header
  - If the inner header ECN field is CE, set the outer header ECN field to ECT(0)

The rest of the DS field (DSCP bits) in the outer header is set according to the existing IPsec specifications [RFC2401].

Decapsulation (Tunnel Exit)

When decapsulating a packet at the tunnel exit, the tunnel endpoint MUST:

Check the ECN_TUNNEL field in the SA Database for this SA
If ECN_TUNNEL indicates "not permitted":
- If the outer header has the CE codepoint set, the packet SHOULD be dropped (as this indicates potential tampering or misconfiguration)
- Otherwise, do not change the inner header ECN field; simply remove the outer header
If ECN_TUNNEL indicates "permitted":
- Apply the full-functionality option as specified in Section 9.1.1:
  - If the outer header CE codepoint is set, set the CE codepoint in the inner header
  - Otherwise, leave the inner header ECN field unchanged
- If the outer header has the CE codepoint set but the inner header has not-ECT, the packet SHOULD be dropped

These processing rules ensure that ECN congestion indications are properly preserved across IPsec tunnels when permitted, and that security is maintained by detecting and rejecting packets with unexpected ECN codepoint combinations.