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

Alan Cox <alan@lxorguk.ukuu.org.uk> Mon, 30 December 2002 01:01 UTC

X-Authentication-Warning: irongate.swansea.linux.org.uk: alan set sender to alan@lxorguk.ukuu.org.uk using -f
Subject: Re: FWD:: Re: [e2e] Re: Question on "identification" field of IP
From: Alan Cox <alan@lxorguk.ukuu.org.uk>
To: tcp-impl@grc.nasa.gov
In-Reply-To: <200212272222.RAA15264@lawyers.ir.bbn.com>
References: <200212272222.RAA15264@lawyers.ir.bbn.com>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10)
Date: Mon, 30 Dec 2002 01:01:43 +0000
Message-Id: <1041210103.1215.13.camel@irongate.swansea.linux.org.uk>
Mime-Version: 1.0
Sender: owner-tcp-impl@grc.nasa.gov
Precedence: bulk
Status: RO
Content-Length: 1113
Lines: 24

On Fri, 2002-12-27 at 22:22, Mark Allman wrote:
> The most common scenario in my experience is VPN boxes not 
> 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.

> 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).

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