skip to content

What can an on-path observer learn from an IPsec ESP packet in transport mode that tunnel mode would hide?

level: middleimportance: should knowfreq 22%

answer

  1. which header stays in clear
  2. real endpoints versus peer pair
  3. length still leaks in both
  4. padding needs a length field

basics

~20 s

In IPsec transport mode an observer reads the real source and destination hosts from the original IP header; tunnel mode shows only the two gateways. Both encrypt ports and the next-layer protocol; sizes, timing and, by default, DS marks still leak.

solid answer

~50 s

With encrypting ESP, both modes hide the next-layer protocol, the ports and the data: the IP protocol field says 50 and the real `Next Header` sits in the encrypted trailer. The difference is the clear header. **Transport mode** keeps the original IP header, so a capture shows exactly which two hosts are talking, plus their DS/ECN marks and TTL. **Tunnel mode** shows only the two IPsec peers, and every host pair behind them shares that outer pair. Neither mode hides packet sizes or timing by default: the length is within a few padding bytes of the original. RFC 4303's traffic flow confidentiality (TFC) padding helps, but it needs a length field inside the payload — always present in tunnel mode (the inner IP header), only sometimes in transport mode. And RFC 4301 copies the inner DS field to the outer header by default.

go deeper

for a junior

Recall that ESP never protects the IP header in front of it, so the visible addresses are the real hosts in transport mode and the gateways in tunnel mode.

for a middle

Walk through what stays in clear in each mode — addresses, protocol 50, SPI, sequence number, length, DS field — and what the encrypted trailer hides.

for a senior

Explain to a security reviewer what a tunnel still leaks — peer pair, sizes, timing, copied DS marks — and when TFC padding or a fixed outer DSCP is worth its cost.

for a principal

Weigh traffic-analysis resistance against bandwidth and QoS: TFC padding and dummy traffic cost capacity, and a fixed outer DSCP gives up path QoS.

## What stays readable is the header in front of ESP ESP (RFC 4303) encrypts the payload and trailer behind its own header (the IV and ICV travel in clear) and authenticates the ESP header with them, but it never protects the IP header **in front of** it. So the question "what does an observer see?" reduces to "which IP header is in front of ESP?". In both modes, the observer also reads the ESP header itself: the 32-bit **SPI** (which SA this is) and the **sequence number** (how many packets that SA has sent). This assumes an encrypting transform; with null encryption the payload is readable in either mode. | Visible to the path | Transport mode | Tunnel mode | |---|---|---| | Source and destination addresses | the two real hosts | the two IPsec peers only | | IP protocol field | 50 (ESP) | 50 (ESP) | | Next-layer protocol (TCP, UDP, ICMP) | encrypted, in the trailer's `Next Header` | encrypted | | Ports | encrypted | encrypted | | DS / ECN marks | the host's own marks | copied from the inner header by default | | TTL | the host's, so roughly its hop distance | the gateway's, constructed afresh | | Packet length | original length plus overhead and a few padding bytes | inner length plus overhead and a few padding bytes | | SPI and sequence number | visible | visible | ## Transport mode: who talks to whom Because the original header is reused, a transport-mode capture is a complete **who-talks-to-whom** map: each SA is one host pair, and its SPI separates the flows. The observer cannot see which application runs on top — the ports are encrypted — but host identity, packet counts, sizes and timing per pair are all there. ## Tunnel mode: hosts merge behind the peers In tunnel mode the outer header carries only the two IPsec peers' addresses. When one tunnel-mode SA carries many host pairs between two sites, the observer sees one stream between two gateways and cannot split it by inner host without breaking the encryption. What tunnel mode does **not** hide: - **That IPsec is in use and between which peers** — the outer addresses and protocol 50 are in clear. - **Sizes and timing.** The outer packet is the inner packet plus a fixed overhead and a few bytes of padding, so packet-size patterns survive. - **DS marks.** RFC 4301 §5.1.2.1 copies the inner DS field into the outer header by default, so QoS works on the path. RFC 4301 calls copying a possible covert channel and lets an implementation map the outer DS field to a fixed value per SA instead. ## Hiding length: TFC padding and dummy packets The ESP `Padding` field (0 to 255 bytes) exists for block alignment and is too small to disguise traffic. RFC 4303 §2.7 adds **TFC padding**: extra bytes after the payload data, before the normal padding. The receiver has to know where the real data ends, so TFC padding can be added only if the payload carries the length of the IP datagram: 1. In **tunnel mode** it always does — the inner IP header's total length. 2. In **transport mode** it depends on the next-layer protocol: UDP and ICMP carry an explicit length, TCP does not. TFC padding must be negotiated before it is sent; in IKEv2 an endpoint that will not accept it says so with `ESP_TFC_PADDING_NOT_SUPPORTED`. Separately, ESP **dummy packets** — `Next Header` 59, "no next header" — can be sent at random to mask idle periods; a receiver MUST discard them without error. Both cost bandwidth, so they are a deliberate per-SA choice rather than a default. ## What this means when you choose - If the threat is someone mapping which internal hosts talk across a link, tunnel mode between gateways hides it; transport mode does not. - If the threat is volume or timing analysis, neither mode helps until TFC padding or dummy traffic is turned on, and tunnel mode is the one where TFC padding always works. - If the path's QoS must see the marks, tunnel mode's default DS copying keeps it working; mapping to a fixed value trades that for less leakage.

  • Why can an observer count a host pair's packets even though IPsec encrypts the payload?
    The ESP header is authenticated but not encrypted: the SPI identifies the SA and the 32-bit sequence number increments with every packet the SA sends. In transport mode the SA also maps to one host pair through the clear IP header, so the observer reads per-pair packet counts, sizes and timing directly.
  • If tunnel mode hides the inner addresses, why do the path's QoS queues still see the host's DSCP?
    RFC 4301's default tunnel-mode header construction copies the inner DS field into the outer header, so routers between the gateways can honour it. The RFC treats that copy as a potential covert channel and allows an implementation to map the outer DS field to a fixed value, configurable per SA.

saying these in an interview costs you the question

  • Transport mode leaves the TCP and UDP port numbers readable on the path
  • Tunnel mode hides packet sizes and timing as well as addresses
  • In tunnel mode the path cannot tell that IPsec is in use
  • Tunnel mode encrypts the DSCP, so QoS on the path cannot see it
  • TFC padding works equally in transport and tunnel mode