[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: fragmentation

-----BEGIN PGP SIGNED MESSAGE-----


>>>>> "Sami" == Sami Vaarala <sami.vaarala@netseal.com> writes:
    Sami> Since you can't rely on getting an icmp when your packet
    Sami> is too large, and you can't be certain that frags pass
    Sami> through routers, what is left?
    >> [...]
    >> This fails if there is ICMP hole between the near gateway and the
    >> originator. This is actually a very common occurance when one has an extruded 
    >> host/subnet (i.e. the default route for the road warrior is through the
    >> tunnel) since the "other side" is the entire Internet.

    Sami> Exactly.  What I was saying was that maybe we shouldn't rely on
    Sami> icmp.  Yes, you can always say it's the clueless X that's the fault,
    Sami> but the end result is that the tunnel isn't working as it's supposed
    Sami> to be.

  In further in person discussion with William Dixon in the lounge, we
discussed the various things to do.

To recap:

  My proposal was to have the receiving (decap end) of the tunnel note the
largest sized fragment received. {If there are fragment loss issues where
every fragmented packet is lost (due to stupid midcom boxes), then perhaps
this should be done in general - note the largest packet received period.}

  This information would be sent *through* the tunnel via ICMP Datagram Too
Big message to the originator of the packets to get them to reduce their
MTU. This packet would fit (policy-wise) by forging the source address (if
necessary) to be that of the destination address seen.

  As discussed in this thread, there are often ICMP blackholes on the that
are between the end nodes and the gateway, so this doesn't guarantee that the 
MTU will be reduced.

  The further proposal is that one might ignore the DF bit, fragment the
packet going into the tunnel first (before ESP processing), producing ESP
packets that do not need to be fragmented. The question is then, what is the
MTU of the tunnel, given that all fragments get lost, and that ICMPs
generated from DF-set are filtered, etc. 

    Sami> What I proposed was using an encrypted, ping-like protocol.  Don't
    Sami> rely on any icmp information (or lack of it) that you get from between
    Sami> the IPsec endpoints.  Instead, to ensure that you can pass a packet
    Sami> of 1234 bytes between the endpoints, send an encrypted ping (or whatever)
    Sami> of that size;  if you get a reply, you can do that.  Otherwise, you
    Sami> can't (have to send a few retries, of course).  No need to rely on icmp.

  That's an idea, but I suggest that one fragments actual data. Start with a
permitted MTU of 576. The above mechanism (of putting ICMP Datagram too big
into the tunnel periodically by the decap end) can be used. 

  There are several choices here:
	a) put a second ICMP in, addressed to the sending gateway.	
	   (problem - doesn't fit into the tunnel policy). The quoted 
	   of the packet would be constructed to show the SPI of the sender.

	b) have the sender eavesdrop on decapsulated packets, looking for
	   ICMP Need Fragments.

	c) have the information sent in an IKE notify.

  a/b have the advantage that they apply to all tunnels, not just IPsec ones.
This would really be a revision to RFC2003. Whereas (c) is key daemon specific.

  In general, this is easy for BITS implementations as they have to deal with 
the fragments anyway. For implementations that get their ESP packets at a
transport layer interface, then changes to the stack may be required to note
the fragment information.

]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another NetBSD/notebook using, kernel hacking, security guy");  [




-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: latin1
Comment: Finger me for keys

iQCVAwUBPBuuLIqHRg3pndX9AQHTtAQAmLMHCPyHbOzRkpXvzlegT2+w3Y36bslp
nx5pCy90pM0KOKL1vaP/s9i+hStbu3+W62TBG6mCKQi8amwo5IJ2tn/yMZBI3pTr
28p3425e/1sd6Mwt5DhuZydSFusukAYCiLS98GOOWUkirlIl0TlGzK9VYl1g87po
L38F58fJC8g=
=RZ4r
-----END PGP SIGNATURE-----
Follow-Ups: References: