Two routers protect their GRE traffic with IPsec ESP; why is transport mode allowed there, and how many bytes does it save over tunnel mode?

## The rule that normally forbids it RFC 4301 §4.1 says that whenever either end of a security association is a **security gateway**, the SA MUST be tunnel mode. The reasons it gives are practical: packets must reach the gateway that holds the SA, and fragments need separate inner and outer headers to keep their state straight. Two exceptions follow: 1. Traffic **addressed to the gateway itself** — management traffic, for instance — where the gateway is acting as a host. 2. Transport mode **between intermediate systems**, which RFC 4301 names as a way to protect IP-in-IP, GRE or dynamic routing traffic between gateways. The second exception has a precise boundary: an intermediate system may use transport mode only for packets whose **source address (outbound) or destination address (inbound) belongs to the system itself**. It cannot use transport mode to protect a host's packet it merely forwards. ## Why GRE fits the exception GRE (RFC 2784) puts a **4-byte** base header (8 with the optional checksum) in front of the payload packet and a **delivery header** — a new IPv4 header with protocol 47 — in front of that. The router that encapsulates writes its own address as the delivery header's source and the far router's as the destination. To IPsec, that GRE packet is traffic the router originates, so a transport-mode SA between the two routers is legal. In transport mode, ESP goes after the delivery header and before the GRE header, so the GRE header and the inner packet are encrypted, the IP protocol field becomes 50, and the trailer's `Next Header` holds 47. ## The bytes, computed Take a 1,400-byte inner IPv4 packet and ESP with AES-GCM (8-byte IV, 16-byte ICV, 4-byte alignment): | Step | Transport mode | Tunnel mode | |---|---|---| | GRE packet | 20 + 4 + 1,400 = 1,424 | 20 + 4 + 1,400 = 1,424 | | Encrypted portion before padding | 4 + 1,400 + 2 = 1,406 | 1,424 + 2 = 1,426 | | Padding to a 4-byte boundary | 2 → 1,408 | 2 → 1,428 | | Header in front of ESP | 20 (the delivery header) | 20 (a new outer header) | | On the wire | 20 + 8 + 8 + 1,408 + 16 = **1,460** | 20 + 8 + 8 + 1,428 + 16 = **1,480** | Transport mode saves **20 bytes per packet**, which is exactly the redundant header: in tunnel mode the outer header and the encrypted delivery header carry the same pair of router addresses. On a 1,500-byte path the saving is also 20 bytes of inner MTU. ## What an observer sees, and what policy loses On the path, the two choices look the same: two router addresses and protocol 50. Tunnel mode adds no extra hiding — it encrypts a copy of addresses that are already visible outside. What transport mode does give up is **access control**. RFC 4301 warns that IPsec's access control functions are "significantly limited" here, because they cannot be applied to the end-to-end headers inside the GRE payload. The SA's policy sees only "GRE between router A and router B"; whatever hosts and ports ride inside the GRE tunnel pass if the GRE packet does. Any per-host or per-port filtering has to be done before encapsulation, by the routers' own filtering, rather than by the IPsec policy. ## Fragments under a transport-mode SA Transport mode cannot carry IP fragments. RFC 4301 Appendix D explains why this does not break the GRE design: the GRE encapsulation already provides an inner header, so an oversized inner packet can be fragmented **before** GRE encapsulation. Each piece gets its own GRE and delivery header and reaches IPsec as a whole datagram; IPsec never looks at the inner header and does not see a fragment. ## Summary for the operator - Transport mode is legal because the router sources and sinks the GRE packets itself. - It saves 20 bytes per packet with AES-GCM, and the same 20 bytes of MTU. - It hides nothing less than tunnel mode does. - It moves host-level filtering out of the IPsec policy and into the routers' own filters.