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

Mark Allman <mallman@grc.nasa.gov> Fri, 27 December 2002 22:22 UTC

Message-Id: <200212272222.RAA15264@lawyers.ir.bbn.com>
To: tcp-impl@grc.nasa.gov
From: Mark Allman <mallman@grc.nasa.gov>
Reply-To: tcp-impl@grc.nasa.gov
Subject: Re: FWD:: Re: [e2e] Re: Question on "identification" field of IP
Organization: BBN Technologies/NASA GRC
Song-of-the-Day: Night Moves
Date: Fri, 27 Dec 2002 17:22:55 -0500
Sender: owner-tcp-impl@grc.nasa.gov
Precedence: bulk
Status: RO
Content-Length: 2286
Lines: 57

 

------- Forwarded Message

Date: Thu, 19 Dec 2002 12:53:26 +0100
From: Andi Kleen <ak@muc.de>
To: Joe Touch <touch@ISI.EDU>
Cc: richard@codeburst.co.uk, mallman@grc.nasa.gov, tcp-impl@grc.nasa.gov
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