Page MenuHomeFreeBSD

ipsec: Add support for PMTUD for IPv6 tunnels
ClosedPublic

Authored by bag_semihalf.com on Sep 1 2021, 11:45 AM.
Tags
None
Referenced Files
Unknown Object (File)
Sun, Apr 21, 10:12 PM
Unknown Object (File)
Sun, Apr 21, 10:12 PM
Unknown Object (File)
Sun, Apr 21, 10:12 PM
Unknown Object (File)
Sun, Apr 21, 9:39 PM
Unknown Object (File)
Sun, Apr 21, 5:15 PM
Unknown Object (File)
Sun, Apr 21, 5:15 PM
Unknown Object (File)
Sat, Apr 20, 7:26 AM
Unknown Object (File)
Sun, Apr 7, 4:43 PM

Details

Summary

Discard and send ICMPv6 Packet Too Big to sender when we try to encapsulate
and forward a packet which total length exceeds the PMTU.
Logic is based on the IPv4 implementation.
Common code was moved to a separate function.

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

bz added inline comments.
sys/netipsec/ipsec_output.c
747

I may not have read the full logic and by description cannot fully follow either which exact case we handle here these days.
Can we possibly in any case send an ICMP6 PTB here out unencrypted anywhere with data which previously came from an encrypted session?
For a long time this has been a serious concern when sending PTB related to IPsec to leak any previously encrypted data back as that opens up to possible attack vectors.

sys/netipsec/ipsec_output.c
747

This isn’t the case here. When a tunnel gateway receives ICMPv6 PTB (which contains encrypted data), a new PMTU is recorded in the host cache and that’s it, the packet is discarded. We do try not forward this ICMPv6 message to the original sender.
After that when we try to forward a new incoming packet with ip6_forward function, it is handed to IPsec for encryption and there we call
ipsec6_check_pmtu. Here, if we detect that a packet is exceeding the PMTU, we notify the sender with a new PMTU and discard the packet.
The line you are referring to, sends ICMPv6 PTB to its original sender, when we detect that the packet is exceeding the PMTU stored to the host cache. This results in both packets being dropped, and only the second is being sent in the ICMPv6 unencrypted and only to its original sender.

This revision was not accepted when it landed; it landed in state Needs Review.Sep 24 2021, 8:31 AM
This revision was automatically updated to reflect the committed changes.