From owner-freebsd-security@FreeBSD.ORG  Fri May  2 19:42:30 2014
Return-Path: <owner-freebsd-security@FreeBSD.ORG>
Delivered-To: freebsd-security@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
 [IPv6:2001:1900:2254:206a::19:1])
 (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits))
 (No client certificate requested)
 by hub.freebsd.org (Postfix) with ESMTPS id F348A453
 for <freebsd-security@freebsd.org>; Fri,  2 May 2014 19:42:29 +0000 (UTC)
Received: from outgoing.tristatelogic.com (segfault.tristatelogic.com
 [69.62.255.118]) by mx1.freebsd.org (Postfix) with ESMTP id D4E101374
 for <freebsd-security@freebsd.org>; Fri,  2 May 2014 19:42:29 +0000 (UTC)
Received: from segfault-nmh-helo.tristatelogic.com (localhost [127.0.0.1])
 by segfault.tristatelogic.com (Postfix) with ESMTP id B80E43B014
 for <freebsd-security@freebsd.org>; Fri,  2 May 2014 12:42:23 -0700 (PDT)
From: "Ronald F. Guilmette" <rfg@tristatelogic.com>
To: freebsd-security@freebsd.org
Subject: Re: FreeBSD Security Advisory FreeBSD-SA-14:08.tcp
In-Reply-To: <CAABACD8BCAE7B4B8A7906EEDC9DEBC5024EFDCD@IAD-WPRD-XCHB01.corp.verio.net>
Date: Fri, 02 May 2014 12:42:23 -0700
Message-ID: <3867.1399059743@server1.tristatelogic.com>
X-BeenThere: freebsd-security@freebsd.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Security issues \[members-only posting\]"
 <freebsd-security.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-security>, 
 <mailto:freebsd-security-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-security/>
List-Post: <mailto:freebsd-security@freebsd.org>
List-Help: <mailto:freebsd-security-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-security>, 
 <mailto:freebsd-security-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 02 May 2014 19:42:30 -0000


In message <CAABACD8BCAE7B4B8A7906EEDC9DEBC5024EFDCD@IAD-WPRD-XCHB01.corp.verio
.net>, "David DeSimone" <ddesimone@verio.net> wrote:

>Are you perhaps confusing IP Fragment Reassembly with the similar but
>unrelated TCP Segment Reassembly?

That's entirely possible.  I have near zero experience with or understanding
of either of these types of packet fragmentation.

>My understanding is that TCP stacks normally try very hard not to
>generate IP fragments in a TCP stream.
>
>It appears that this bug report relates only to TCP Reassembly, and has
>nothing to do with IP Fragments.  But perhaps I am misreading it?

OK, so how would one block all incoming *TCP* fragments... you know...
in order to render this specific security issue a non-issue?  (I personally
am already blocking inbound IP fragments viw ipfw.)