On 1/17/20 1:51 AM, Eugene Grosbein wrote:
17.01.2020 16:36, Victor Sudakov пишет:

Back to the point. I've figured out that both encrypted (in transport
mode) and unencrypted TCP segments have the same MSS=1460. Then I'm
completely at a loss how the encrypted packets avoid being fragmented.
TCP has no way to know in advance that encryption overhead will be
added.
Using multiple routing tables we could add a mechanism to the ipsec
code so that encapsulated sessions are referred to one routing table
and that the "envelope" routes are referencing another (specified in
ipsec setup) routing table.  The two routing tables would have different
MTUs.  This mechanism/framework would also be useful for other
tunneling protocols in general.
If outgoing route (f.e. default route) has lower MTU, kernel should respond 
with EMSGSIZE
to TCP's attempt to send oversized packet when PMTUD is enabled.

If PMTUD discovers that path mtu is low, it should store this information in 
the hostcache
(see sysctl net.inet.tcp.hostcache.list) and use hostcache's MTU for same goal.

_______________________________________________
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"



_______________________________________________
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Reply via email to