[Openswan dev] Proposal for dealing with ICMP black holes for
mcr at sandelman.ottawa.on.ca
Sat Jul 3 16:03:24 CEST 2004
-----BEGIN PGP SIGNED MESSAGE-----
>>>>> "Herbert" == Herbert Xu <herbert at gondor.apana.org.au> writes:
Herbert> My idea is to use the information available in TCP MSS
Herbert> clamping to help IPsec gateways. This can be done by
Herbert> having the gateways establish a short-lived TCP connection
Herbert> with each other for the purposes of determining the MTU.
Herbert> Obviously this TCP connection will need to be
Herbert> authenticated. If the connection cannot be established
Herbert> (e.g., if an attacker is preventing the gateways from doing
Herbert> so), then we can fall back to the existing MTU discovery
It sounds fine in theory.
It can break for a number of reasons:
1) any kind of forced proxies for TCP.
2) Cisco-style load balancing that cause different routes to be taken.
3) causes some surprise for firewall administrators, as these new
TCP connections show up. Also, therefore, may not work through
many NAT devices -- often people do special things with port
500/4500 to get things plugged through.
Still, I think it may be worth doing it as an experiment.
When you say that the connection needs to be authenticated, are you
thinking IPsec (ESP or AH), some kind of other thing? I.e. does this
include the headers?
I guess if you intend to use various kinds of MSS clamping as a clue,
then the headers must not be authenticated, as the MSS clamping code
must be able to do its thing.
Herbert> The advantage of this over the approach taken by KLIPS (the
Herbert> FreeSWAN kernel implementation for IPsec) is that we do not
It would be good if you actually documented what this method is.
Specifically KLIPS was set to have an MTU of 16k - minus a bit, so
that SMB and NFS would appear to work. Not fast, nor well, but they do
not encounter Need-Fragments.
The resulting ESP packet is then fragmented. I.e. the DF bit on ESP
packets is never set.
RFC2401 says to fragment (if DF=0) before encryption, and provides
various notions about whether to copy the DF bit.
RFC2401bis says to fragment after encryption.
Herbert> transmit fragments where possible which is the motivation
Herbert> behind PMTU discovery. The advantage of this over the
Herbert> current implementation is that this will work correctly in
Herbert> environments where there are local ICMP black holes that
Herbert> are known through TCP MSS clamping.
I think that there are simpler mechanisms.
Implementation wise, a new vendor ID can indicate the desire to do
this. The IKE daemons can do most of the work themselves. The two ends
need a way to decide who initiates the connection. Probably the end that
initiated the IKE. We need to decide if they do the work between phase 1
and phase 2, or if we can do this after phase 2.
(or: Can the MTU of the tunnel be changed after it is created?)
Do we do this periodically?
Do we care about PMTU stuff, or just MSS?
If we care about looking at the PMTU, then we have to write(2) at
least enough data to send out a full size packet, that may get PMTU'ed.
How do we get the MSS out of a tcp socket? (there must be a sockopt)
What about assymetric MTUs?
] "Elmo went to the wrong fundraiser" - The Simpson | firewalls [
] Michael Richardson, Xelerance Corporation, Ottawa, ON |net architect[
] mcr at xelerance.com http://www.sandelman.ottawa.on.ca/mcr/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Finger me for keys
-----END PGP SIGNATURE-----
More information about the Dev