From 05f8202714d7fe00a274635e1ece13652ac4899b Mon Sep 17 00:00:00 2001
From: Sergey Matveev <stargrave@stargrave.org>
Date: Mon, 9 Nov 2020 15:33:18 +0300
Subject: [PATCH] =?utf8?q?=D0=9F=D0=BE=D1=87=D0=B5=D0=BC=D1=83=20IPsec=20?=
 =?utf8?q?=D0=B2=D0=BC=D0=B5=D1=81=D1=82=D0=BE=20WireGuard=3F?=
MIME-Version: 1.0
Content-Type: text/plain; charset=utf8
Content-Transfer-Encoding: 8bit

В 1d5bc1731a1e8f77fed6e7c60bbdeb9db421a87d написал что всё равно
использую IPsec по возможности. Если забыть про то, что IPsec тесно
интегрирован в ОС/ядро и позволяет делать далеко не только VPN туннели,
то всё равно остаётся вопрос эффективности.

IPsec ESP это отдельный тип IP-пакета, в котором (для AES-GCM) : SPI
(4B) + SEQ (4B) + IV (8B) + padLen (1B) + PAD (0-3B) + NextHdr (1B) = 18
+ 0-3 байта overhead. Причём от IV (вместо него использовать ESN) или
SEQ можно было бы для AEAD-ов где это всё счётчики и избавиться уж, но
стандарты гласят вот так.

WireGuard (из его whitepaper): type+reserved (4B) + counter (8B) + I_m
(4B) + UDP заголовок (8B) = 24 байта. В любом случае чуть больше ESP.
Но, при этом ещё и CRC надо считать в UDP заголовке! Хотя он и не нужен,
ибо и так данные аутентифицируются. Так что даже в теории он любом
случае чуть менее эффективен. На практике парсинг ESP возможно отъедает
и больше CPU из-за if-ов всяких, но это уже вопрос конкретной
реализации, которую можно и упростить/ускорить.

Ну а ChaCha20+Poly1305 для ESP уже есть: https://tools.ietf.org/html/rfc7634

И если мне нужно обеспечить защиту только между двумя IP-адресами, двумя
хостями, то в WireGuard-е пришлось бы шифровать IP-пакеты -- это же VPN,
а в IPsec использовать транспортный режим где внутри ESP будет лежать
сразу же TCP/UDP/SCTP/whatever. Но это конечно вопрос решаемых задач. Но
вот у меня по факту нигде нет туннельного режима IPsec, хотя есть пара
туннелей gif-туннелей между двумя хостами, а в остальном только
транспортные между хостами, чтобы не городить между ними никаких
костылей в виде TLS.
-- 
2.51.0