Subject: Re: FWD:: Re: [e2e] Re: Question on "identification" field of IP

From: Mark Allman <[email-masked]>
Date: Fri, 27 Dec 2002 17:22:55 -0500

------- Forwarded Message

Date: Thu, 19 Dec 2002 12:53:26 +0100
From: Andi Kleen <[email-masked]>
To: Joe Touch <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: FWD:: Re: [e2e] Re: Question on "identification" field of IP

> I mean that anyone who clears the DF bit gets what they deserve - a 
> nonfunctioning brick.

The most common scenario in my experience is VPN boxes not 
copying DF when they encapsulate a TCP packet into an IPSEC header.

The reason is that doing so would require working path mtu discovery
to the TCP sender to tell it about the smaller MTU, and path mtu
discovery is often broken due to packet filters blocking all of
ICMP or NAT gateways not properly rewriting ICMP frag-needed.

This has the same effect in the network. Worse as noted earlier
in the thread some routers do not send enough headers
to reconstruct the original sender after IPSEC decapsulation.

(I don't know if it is still the case but at one point routers
from a particular popular router vendor were notorious for this
in their default configuration - they only returned 64bits of 
payload)

The worst part is that many IPSEC implementations drop ICMPs
for security reasons when they don't contain the full
original packet, because it is impossible to authenticate
it otherwise (and they would be vunerable to a DoS of 
an attacker forcing an unusable small MTU on them with
forged ICMPs).

ICMPs are only required to fill up 576 bytes to avoid
fragmentation, but TCP packets tend to be much bigger
than that. In fact the ICMP cannot be bigger than
the MTU and when the MTU the TCP/IPSEC packet was 
formatted for is the same as the ICMP is sending then
the ICMP sender has no choice but to drop some part of
the payload because the ICMP header takes space too (or fragment, 
which is forbidden)

The only alternative they have is to not copy DF and don't
do path MTU discovery. Of course for a common scenario
(VPN gateway receiving and sending on the same MTU) 
after adding the IPSEC header this results in getting
every full sized packet being fragmented into two
packets. This disturbs all the TCP packet accounting
mechanisms and makes the connection react very badly
to any packet loss.

- -Andi

------- End of Forwarded Message

---

From: Alan Cox <[email-masked]>
Date: 30 Dec 2002 01:01:43 +0000

> copying DF when they encapsulate a TCP packet into an IPSEC header.

There are reasons for doing this. Given an ICMP must fragment response
to an IPSEC frame how do you prove the ICMP frame is valid. DF and IPSEC
don't mix. When you mix them via a magic box in the middle its even
worse because the ICMP may be hostile and the man in the middle box is
hard pushed to tell. Certainly it would have to keep state and handle
rate filtering and issue its own equivalent 'vetted' icmp frames.

> an attacker forcing an unusable small MTU on them with

It happens unfortunately. Several years ago people were trying to drop
BGP peering sessions down to 68 byte frames (which really messes things
up).

Rock and a hard place..IPv6 makes it even more fun