Re: IPSEC transport mode w/2.2.x kernels and large packets

Andi Kleen (ak@muc.de)
Sat, 7 Aug 1999 12:00:50 +0200

On Sat, Aug 07, 1999 at 11:20:24AM +0200, Alan Cox wrote:
> > > Alan Cox suggested setting the MTU to the maximum allowed:0xfff0, then
> > > fragmenting after encryption to the MTU of the physical device.
> >
> > So when one fragment gets dropped the whole packet is lost ? This is the
> > "NFS trap" and works badly over WANs, because you would disturb path
> > MTU discovery. It is important that packets with DF get a icmp error
> > when they exceed the effective size of the tunnel.
>
> What I suggested is a bit cleverer than that
>
> Set the MTU to 64K
> Set the MSS on the routers to the estimated path mtu

You propose to rewrite the TCP MSS option on the routers while tunneling ?

>
> Now TCP generates frames the right size for optimal performance, everything
> else hands down full datagrams and the world is a happier place.
>
> You can't run path MTU discovery with IPsec. The DF could be faked and aimed
> at dropping your link to unusably low speeds. Ignoring the DF could equally
> be a complete link failure. So you don't run mtu discovery.

I'm not sure I follow. You worry about the possible slow down of the
tunnel start point return ICMP messages? So you propose to turn off all
of ICMP to avoid this potential attack? This would sound like overkill
to me, and there would be still enough other ways to generate retry packets
left (e.g. with TCP).

Also the tunnel start point has to be secured anyways, otherwise
all the encryption wouldn't make sense. Similar for the tunnel endpoint.

Or do I miss something?

-Andi

-- 
This is like TV. I don't like TV.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/