IPsec Overhead и MTU

[KorDen]

Пригодится тем, кто создает ручные туннели. Возможно где-то ошибся.

Оверхед ESP (в байтах)

20 IP Header
8 ESP Header (4 SPI + 4 Sequence)
[8|16] - IV, для DES/3DES - 8, для AES - 16
<данные>
4 ESP Trailer
12 ESP Auth Trailer

Итого: для DES/3DES - 56 байт, для AES - 60 байт

Оверхед туннелирования

IPIP - 20 (IP Header) = 20
GRE - 20 (IP Header) + 4 (GRE) = 24
EoIP - 20 (IP Header) + 8 (GRE) [+ 14 (ETH)] = 28 (42)

Итого, скажем, для туннеля IPIP over IPsec (AES) оверхед будет равен 80 байт, т.е. например при канале с MTU 1500 у туннеля будет 1420.

Для вычисления MSS - добавьте в оверхед TCP Header (20 байт)

----------

Небольшая путанница у меня с режимом IPsec Tunnel, там получается оверхед варьируется в пределах 58-65 байт (для AES). Тут не уверен до конца.

[gaaronk]

Для AES еще используется ESP Pad, идущий после данных перед ESP Trailer. Например расклад для данных размером в 1400 в туннельном режиме

 

AES, SHA-1

 

PACKET DETAILS
Field	Bytes	
New IPv4 Header (Tunnel Mode)	20	
SPI (ESP Header)	4	
Sequence (ESP Header)	4	
ESP-AES (IV)	16	
Original Data Packet	1400	
ESP Pad (ESP-AES)	6	
Pad length (ESP Trailer)	1	
Next Header (ESP Trailer)	1	
ESP-SHA-HMAC ICV (ESP Trailer)	12	
Total IPSec Packet Size	1464	

 

AES, SHA-256

 

PACKET DETAILS
Field	Bytes	
New IPv4 Header (Tunnel Mode)	20	
SPI (ESP Header)	4	
Sequence (ESP Header)	4	
ESP-AES (IV)	16	
Original Data Packet	1400	
ESP Pad (ESP-AES)	6	
Pad length (ESP Trailer)	1	
Next Header (ESP Trailer)	1	
ESP-SHA-256-HMAC ICV (ESP Trailer)	16	
Total IPSec Packet Size	1468	

 

AES, SHA-1, NAT-T, 1420 payload

PACKET DETAILS
Field	Bytes	
New IPv4 Header (Tunnel Mode)	20	
UDP Header (NAT-T)	8	
SPI (ESP Header)	4	
Sequence (ESP Header)	4	
ESP-AES (IV)	16	
Original Data Packet	1420	
ESP Pad (ESP-AES)	2	
Pad length (ESP Trailer)	1	
Next Header (ESP Trailer)	1	
ESP-SHA-HMAC ICV (ESP Trailer)	12	
Total IPSec Packet Size	1488	

 

Если есть CCO, то вот отличный калькулятор

[ImP]

Возможно, будет полезно - сервис для расчета оверхеда от cisco (нужен аккаунт): https://cway.cisco.com/tools/ipsec-overhead-calc/

[Le ecureuil]

Начиная с версии 3.3 сильной необходимости нет - нужная фрагментация до и после шифрования теперь полностью поддерживается аппаратно.

[KorDen]

25 минут назад, Le ecureuil сказал:

Начиная с версии 3.3 сильной необходимости нет - нужная фрагментация до и после шифрования теперь полностью поддерживается аппаратно.

Но если хочется максимальной производительности, лишней фрагментации надо по максимуму избегать.

Какая именно фрагментация поддерживается теперь аппаратно?

[Le ecureuil]

1 минуту назад, KorDen сказал:

Но если хочется максимальной производительности, лишней фрагментации надо по максимуму избегать.

Какая именно фрагментация поддерживается теперь аппаратно?

Любая. И до шифрования, и после.

[CBLoner]

Подскажите, надеюсь в тему попал!

Есть схема Кинетик 1 (серый IP) - Роутер Билайн (не знаю какой IP, наверное тоже серый) - Облако Билайн (для супер Интернета) - Выход в интернет через белый IP (трафик вход / выход валится на серый IP Кинетика).

Между Кинетик 1 и Кинетик 2 (Белый IP) поднят IPSEC VPN, использовал DN как идентификаторы

Туннель поднимается, но трафик не идёт! Баловались с MTU. на WAN порту Кинетика 1 - не помогает.

Билайн заявил, что нам надо установить MSS = 1200 для IPSEC VPN на Кинетик 1! Идёт фраментация из-за его хитрого облака!

Такое можно сделать и как?

Спасибо!

[Le ecureuil]

В crypto map есть параметр tcp mss, ну и вообще начиная с 3.3 фрагментированный IPsec больше не проблема, и работает хорошо.

[CBLoner]

19 часов назад, Le ecureuil сказал:

В crypto map есть параметр tcp mss, ну и вообще начиная с 3.3 фрагментированный IPsec больше не проблема, и работает хорошо.

Спасибо огромное, что ткнули носом, всё нашёл!

Увы, вы видимо правы, и Билайном это пока не помогло! Роют дальше!