IPSec transport mode, mtu, fragmentation...
Andrey V. Elsukov
bu7cher at yandex.ru
Mon Dec 23 11:29:59 UTC 2019
On 23.12.2019 14:08, Eugene Grosbein wrote:
>>> Sample patch creates another sysctl but we should do it unconditionally, don't we?
>>
>> As I said I didn't find that other OSes do this. Linux has enabled by
>> PMTUD by default, strongswan doesn't set SADB_SAFLAGS_NOPMTUDISC flag,
>> OpenBSD hasn't such quirk. Why should we add this instead of try to fix
>> PMTUD?
>
> RFC 2401 Appendix B https://tools.ietf.org/html/rfc2401#page-1-48 states
> that packets generated by IPSec transport mode must be "fragmentable" over the path
> and this is incompatible with DF=1.
I don't see such requirements here, I think you read this somewhere
between lines :-)
"If required, IP fragmentation occurs after IPsec processing within an
IPsec implementation. Thus, transport mode AH or ESP is applied only
to whole IP datagrams (not to IP fragments)."
This is exactly how it works now. IPsec does encryption and passes ESP
packet to IP stack, then it can be fragmented if it is allowed (i.e. no
DF bit set).
"An IP packet to which AH or ESP has been applied may itself be
fragmented by routers en route, and such fragments MUST be reassembled
prior to IPsec processing at a receiver."
If fragmentation was allowed at previous step, the receiver will have
several fragments that will be reassembled into single ESP packet, and
then it will be decrypted and passed to IP stack. I.e. IPsec will not
try to decrypt each fragment before reassembly.
--
WBR, Andrey V. Elsukov
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 554 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freebsd.org/pipermail/freebsd-net/attachments/20191223/1cd31b41/attachment.sig>
More information about the freebsd-net
mailing list