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
- Re: FWD:: Re: [e2e] Re: Question on "identificati… Joe Touch
- Re: FWD:: Re: [e2e] Re: Question on "identificati… Mark Allman
- Re: FWD:: Re: [e2e] Re: Question on "identificati… Alan Cox
- Re: FWD:: Re: [e2e] Re: Question on "identificati… Joe Touch
- Re: FWD:: Re: [e2e] Re: Question on "identificati… Mark Allman
- Re: FWD:: Re: [e2e] Re: Question on "identificati… Alan Cox