Re: Problem about reassembly and fragmentation

[Michael Richardson <mcr@sandelman.ottawa.on.ca>]

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


>>>>> "David" == David Waitzman <djw@bbn.com> writes:
    David> Scott Fluhrer wrote:

    David> I assume that the following are recurring arguments:

    >> - The end application is too stupid to understand PMTU

    David> I would think this only applies in the transmport mode case.  The
    David> end application shouldn't be the issue -- its OS should take care
    David> of this. If the OS is too stupid to have PMTU then it likely won't
    David> have IPsec.

    >> - There's a firewall between the security gateway and the end system
    >> which drops all ICMP messages

    David> If someone has a broken or misconfigured firewall, then why do we
    David> presume it will pass any of the IPsec traffic (ports 500, 50 or
    David> 51)?  Ex: if someone has some clampled down firewall that only
    David> allows initiating tcp/25 outgoing, then it's not going to allow
    David> IPsec through either.

  You are assuming a standard VPN scenario. The places where one runs into
this are when doing different things. For instance, the road warrior with the 
policy that *all* traffic goes to HQ (and is thus virus scanned, etc.) looks
like the extruded subnet in effect:

     RW=============GW----Internet----SillyISP----www.example.com
         tunnel

  The problem is that SillyISP has turned off all of ICMP, making any attempt 
by GW to send PMTU ICMPs useless. The same things happens if "tunnel" is in
fact a PPPoE connection. Of course SillyISP is too stupid to actually know
that they have done this or to even understand it, and "it works" when they
test things themselves.

    >> In either of these cases, PMTU doesn't work.  And hence, we're either
    >> going to stop supporting those legacy networks, or we're just going to
    >> allow security gateways to fragment anyways.

    David> Are these old legacy networks with obsolete firewalls and OSs a
    David> problem worth solving?  Disallowing fragments is a big win, If it

  No, these are modern networks with obsolete operators.

  In general, I prefer to send PMTU ICMPs, and then encrypt the too large
packet, and fragment the resulting ESP. This violates the many
specificiations, but it results in things working *and the ICMP is still out
there*. The ICMP has to be rate limited, or one can form a kind of "ping laser"
if, given
    A---------SG-A=============SG-B---------B

someone does something like:
	   A# ping -s 8192 B

  because ping tends to send a new packet each time it sees *any* ICMP :-)

  Also, if encrypted fragments are lost, then they are discarded before we
waste crypto bandwidth to decrypting them. (If you fragment and then encrypt,
then you waste more crypto bandwidth) 

]       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

iQCVAwUBPIzyAoqHRg3pndX9AQFYggQA6OIIdU69YLyTU300CdGctUwL5e3ZrBBv
0sAShfsUND4xzWQD88yGRGSNI1Bi5jmqthueLQsykD/K0ZK+WxqmRA0ey3IKQ0RO
1xjcewNmaRA/undfdXH8hK7sVjyehCFNA6hdUV/Q0HiUq7jAqBIl+gqZn7tsXN/B
OlQtCfmtA1s=
=f9QR
-----END PGP SIGNATURE-----