From owner-freebsd-bugs@FreeBSD.ORG Thu Jan 8 03:00:40 2004 Return-Path: Delivered-To: freebsd-bugs@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DF33916A4D2 for ; Thu, 8 Jan 2004 03:00:40 -0800 (PST) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 901C843D5C for ; Thu, 8 Jan 2004 03:00:38 -0800 (PST) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) i08B0cFR032078 for ; Thu, 8 Jan 2004 03:00:38 -0800 (PST) (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.12.10/8.12.10/Submit) id i08B0cFD032075; Thu, 8 Jan 2004 03:00:38 -0800 (PST) (envelope-from gnats) Date: Thu, 8 Jan 2004 03:00:38 -0800 (PST) Message-Id: <200401081100.i08B0cFD032075@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org From: Richard Wendland Subject: Re: kern/60889: 5.2RC2 - zero IP id change not effective for TCP, detrimental to security/privacy and maybe interoperation X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Richard Wendland List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2004 11:00:41 -0000 The following reply was made to PR kern/60889; it has been noted by GNATS. From: Richard Wendland To: freebsd-gnats-submit@FreeBSD.org, richard@wendland.org.uk Cc: Subject: Re: kern/60889: 5.2RC2 - zero IP id change not effective for TCP, detrimental to security/privacy and maybe interoperation Date: Thu, 8 Jan 2004 10:59:32 +0000 (GMT) I have identified a further problem with this change: This change causes ip_id for non-DF to be output in native byte order in ip_output.c. Unfortunately ip_id is still output in Network Byte Order in ip_mroute.c and raw_ip.c, so this change risks little-endian machines emitting the same IP fragmentation id at about the same time from these different modules (after another 255 packets), rather than after the usual 64k cycle; creating a small but real risk of fragment re-assembly errors. Richard -- Richard Wendland richard@wendland.org.uk