With IPsec ESP and AES-CBC, how much trailer padding does a 100-byte payload need, and what do Pad Length and Next Header record?
answer
- block-size multiple
- count the two trailer bytes
- Next Header names the payload
- AEAD needs only 4-byte alignment
basics
~20 sTen bytes: AES-CBC needs payload, padding, Pad Length and Next Header to fill whole 16-byte blocks, so 100 + 2 rounds up to 112. Pad Length records 10; Next Header names the payload: 6 for TCP, 4 for IPv4.
solid answer
~50 sAES-CBC encrypts in 16-byte blocks, and RFC 3602 requires the encrypted data — payload, `Padding`, `Pad Length` and `Next Header` — to be a multiple of 16. So 100 + 2 = 102 rounds up to 112, leaving 10 padding bytes, by default the values 1, 2, ... 10. `Pad Length` is 10, so the receiver knows how much to strip. `Next Header` carries the IP protocol number of what the payload holds: 6 for a TCP segment, 4 for a whole IPv4 packet, 41 for IPv6, or 59 for a dummy packet to discard. Both sit in the encrypted trailer, so an observer cannot see what kind of traffic is inside. With a 16-byte IV and a 16-byte ICV, the ESP packet is 152 bytes; with `ENCR_AES_GCM_16`, only 4-byte alignment is needed, so 2 padding bytes and 136 bytes in all.
go deeper
Recall the three trailer fields and that ESP pads its plaintext so it fits the cipher, then records how much padding it added.
Compute the padding with the two trailer bytes included, and say what Next Header holds and why it is encrypted rather than in the clear.
Turn the trailer into an overhead budget per transform — CBC with HMAC against GCM — and use it when sizing MTU or explaining throughput differences.
Judge when TFC padding and dummy packets are worth their bandwidth against what packet sizes and timing reveal on a given link.
## The ESP trailer An ESP packet ends with three fields that RFC 4303 calls the **ESP trailer**, followed by the integrity check value: | Field | Size | Purpose | |---|---|---| | `Padding` | 0-255 bytes | fills the plaintext to the cipher's block size and the 4-byte boundary | | `Pad Length` | 1 byte | how many padding bytes precede it (0-255) | | `Next Header` | 1 byte | IP protocol number of the data in the payload | | `ICV` | algorithm-defined | integrity check value, outside the encryption | The trailer is **encrypted** together with the payload and **covered by the ICV** together with the SPI and sequence number. A separate, optional **TFC padding** can sit between the payload and `Padding` to disguise packet lengths; `Pad Length` does not count it. ## Why padding exists RFC 4303 gives two reasons: - **Block alignment.** A block cipher needs its input in whole blocks. The padding is computed over payload + `Padding` + `Pad Length` + `Next Header` — the two trailer bytes count. - **4-byte alignment.** Whatever the cipher, `Pad Length` and `Next Header` must end right-aligned in a 4-byte word, so the ICV starts on a 4-byte boundary. If the algorithm does not define padding contents, the default is a counting sequence — 1, 2, 3 and so on — and the receiver SHOULD check it after decrypting. More padding than the minimum is allowed (up to 255 bytes) but conceals little; RFC 4303 points to TFC padding when length hiding matters. ## Worked example: AES-CBC with an HMAC `ENCR_AES_CBC` uses a 16-byte block and a 16-byte random IV (RFC 3602). Pair it with `AUTH_HMAC_SHA2_256_128`, whose ICV is 128 bits, 16 bytes. 1. Payload: 100 bytes. Add the two trailer bytes: 102. 2. The next multiple of 16 is 112, so `Padding` is **10 bytes**: 01 02 03 ... 0A. 3. `Pad Length` = **10**. 4. `Next Header` = what the 100 bytes are — 6 if a TCP segment, 4 if a complete IPv4 packet, 41 if IPv6. 5. Ciphertext: 112 bytes. 6. Whole ESP packet: SPI 4 + sequence number 4 + IV 16 + ciphertext 112 + ICV 16 = **152 bytes**, so ESP added **52 bytes** to the 100. ## The same payload under an AEAD transform With `ENCR_AES_GCM_16` (RFC 4106), a counter-based mode, there is no block constraint — only the 4-byte rule: | | AES-CBC + HMAC-SHA2-256-128 | AES-GCM with 16-byte ICV | |---|---|---| | Padding for 100 bytes | 10 | 2 (102 rounds up to 104) | | IV | 16 | 8 | | ICV | 16, from the HMAC | 16, the GCM tag itself | | ESP packet size | 152 | 136 | | Bytes added | 52 | 36 | RFC 4106 confirms the arithmetic: beyond the 8-byte IV and the 8, 12 or 16-byte ICV, ESP costs 10-13 bytes for SPI, sequence number, padding, `Pad Length` and `Next Header` with minimal padding. Under an AEAD cipher there is no separate integrity algorithm; the SPI and sequence number are authenticated as additional data, not encrypted. (How the outer IP header adds to this depends on transport or tunnel mode, a separate subject.) ## Why Next Header sits at the end AH carries its `Next Header` in the clear at the front. ESP puts it in the encrypted trailer, so: - an on-path observer cannot tell whether the payload is TCP, UDP or a tunnelled IP packet; - the receiver learns the payload type only after the ICV has verified and the trailer decrypted. Value **59** ("no next header") marks a **dummy packet** for traffic-flow confidentiality: a sender MUST be able to generate it, and a receiver MUST discard it without signalling an error. ## Reading the trailer on receipt 1. After the sequence-number check, verify the ICV — or decrypt and verify in one step under an AEAD cipher. 2. Decrypt the payload and trailer. 3. Read `Pad Length` from the second-to-last plaintext byte; check and strip the padding. 4. Read `Next Header` from the last byte: 59 means discard; anything else names the protocol to hand the payload to. A wrong `Pad Length` or a mismatched padding sequence after a valid ICV most likely points at a sender bug or a transform mismatch: on-path tampering would have failed the ICV first.
- Why does ESP still pad when the cipher is a stream-like mode or NULL encryption with no block size?RFC 4303 requires `Pad Length` and `Next Header` to end right-aligned in a 4-byte word so the ICV that follows starts on a 4-byte boundary. With a block size of one byte, padding is only what that alignment needs — fewer than four bytes. A 100-byte payload plus the two trailer bytes is 102, so two padding bytes bring it to 104.
- What does a Next Header value of 59 tell an ESP receiver to do?Value 59 means "no next header": the packet is a dummy, generated for traffic-flow confidentiality to mask when real traffic is flowing. After the ICV verifies and the packet is decrypted, the receiver discards it without further processing and without reporting an error. RFC 4303 requires transmitters to be able to generate such packets and receivers to accept and drop them.
saying these in an interview costs you the question
- Padding is computed over the payload alone, not the two trailer bytes.
- ESP's Next Header is sent in the clear like AH's.
- Pad Length counts the TFC padding as well as the normal padding.
- AES-GCM in ESP needs padding to a 16-byte block like AES-CBC.
- An AEAD transform still appends a separate HMAC ICV after its tag.