IPsec
Common Header / Component Sizes
| Header | Bytes |
|---|---|
| Ethernet | 14 |
| IP | 20 |
| UDP | 8 |
| ESP-SPI | 4 |
| ESP-Sequence | 4 |
| ESP-IV-AES-128 | 16 |
| ESP-AES-128-Pad | 15 (variable, worst case) |
| ESP-Pad-Length | 1 |
| ESP-Next-Header | 1 |
| ESP-HMAC-SHA1-96 | 12 |
| AH | 24 (including 12-byte ICV) |
Note: AES-128 is known as AES-CBC in Wireshark.
Common IPsec Overhead Figures
| IPsec Mode | Overhead Elements | Maximum Bytes Overhead |
|---|---|---|
| ESP-AES-128 | ESP-SP + ESP-Sequence + ESP-IV-AES-128 + ESP-AES-128-Pad + ESP-Pad-Length + ESP-Next-Header | 4 + 4 + 16 + 15 + 1 + 1 = 41 |
| ESP-AES-128 + ESP-HMAC-SHA1-96 | ESP-AES-128 + ESP-HMAC-SHA1-96 | 41 + 12 = 53 |
Calculating MTU Deratings For IPsec VPNs
| VPN Mode | Overhead Elements | Maximum Bytes Overhead |
|---|---|---|
| Transport: IP + ESP-AES-128 | IP + ESP-AES-128 | 20 + 41 = 61 |
| Transport: IP + ESP-AES-128 + ESP-HMAC-SHA1-96 | IP + ESP-AES-128 + ESP-HMAC-SHA1-96 | 20 + 41 + 12 = 73 |
| Transport: IP + NAT-T + ESP-AES-128 + ESP-HMAC-SHA1-96 | IP + UDP + ESP-AES-128 + ESP-HMAC-SHA1-96 | 20 + 8 + 41 + 12 = 81 |
| Tunnel: IP + NAT-T + ESP-AES-128 | IP + UDP + ESP-AES-128 + IP | 20 + 8 + 41 + 20 = 89 |
| Tunnel: IP + NAT-T + ESP-AES-128 + ESP-HMAC-SHA1-96 | IP + UDP + ESP-AES-128 + ESP-HMAC-SHA1-96 + IP | 20 + 8 + 41 + 12 + 20 = 101 |
Setting Specific MTUs
In the Trusted User -> Edge Router VPN case, we use an IPsec tunnel with a maximum of 89 bytes of overhead. Our interfaces are Ethernet so the MTUs are set for 1500. Even though 1500 – 89 = 1411, larger MTUs do work in this configuration. This is because the padding and alignment to the 1500 MTU Ethernet payloads does not result in the worst-case padding situation, so an overhead of 89 bytes is overly pessimistic in this specific case.
To calculate the proper MTU for a “IP + UDP + ESP-AES-128 + IP” tunnel given a known host interface MTU, follow this process:
- Take the host MTU and subtract the static header sections up to and including the IV: 1500 – (20 + 8 + 4 + 4 + 16) = 1448
- This is the 4-byte-aligned start of your encrypted payload, and will always begin with an IP header for the tunnel, so subtract that as well: 1448 – 20 = 1428
- This is the start of tunnel-MTU-consuming payload, and is also 4-byte aligned. It causes 2 16-byte (AES 128-bit) cipher blocks to be used, with 16 (block size) – 4 (spillover from 20 byte IP header into the 2nd block) – 2 (ESP-Pad-Length and ESP-Next-Header fields) = 10 bytes left in the second block for more data.
- The next (3rd) available block starts at 1448 – (2 * 16) = 1416. Verify: 1428 – 1416 = 12. This is the 10 bytes of available data + 2 bytes for the above mentioned ESP fields.
- How many 16-byte blocks can be allocated in the remaining 1416 bytes? 1416 / 16 = 88.5, which really means 88.
- These 88 blocks will provide for 88 * 16 = 1408 additional data bytes of storage. Adding this to the existing 10 bytes of available storage in block 2 results in 1418 bytes of available MTU.
- 1418 is exactly the IPIP tunnel MTU observed through experimentation.
There should be a much simpler formula to calculate all this instead of such a lengthy explanation.
Controlling ESP-HMAC in RouterOS
The presence of ESP-HMAC in IPsec packets is set via /ip ipsec proposal set # auth-algorithms. MD5, NULL and SHA1 are the available options.
Controlling ESP-Cipher in RouterOS
The cipher used for ESP looks to be set in two places: /ip ipsec proposal set # enc-algorithms and /ip ipsec peer set # enc-algorithm. The first is used during ISAKMP negotiation, and the 2nd…? Need to experiment more to see which overrides in RouterOS.