[Openswan dev] Proposal for dealing with ICMP black holes for IPsec

[Michael Richardson]

-----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
    Herbert> mechanisms.

  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.

    Herbert> Comments?

  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

iQCVAwUBQOcC+oqHRg3pndX9AQGgOwP8CghDHSlzYi9VOIXiSRHwV1ILLX9OBVwg
bio47djgh+cnOmcQz+hceMC1GKrv7iM59E2M7tFUy8MEvAjxbEiTBJCbdhCUF0M3
xANS/tMnE6/Vh5NZCHEUBT+Ea2xixMnkmcXHMl78hoYXDoC63RlaeVgM6Cbbn4/3
imtNerCtzBQ=
=YvP5
-----END PGP SIGNATURE-----