From owner-freebsd-net Wed Jan 10 1:49: 9 2001 Delivered-To: freebsd-net@freebsd.org Received: from gatekeeper.tsc.tdk.com (gatekeeper.tsc.tdk.com [207.113.159.21]) by hub.freebsd.org (Postfix) with ESMTP id 2FB4337B400 for ; Wed, 10 Jan 2001 01:48:51 -0800 (PST) Received: from imap.gv.tsc.tdk.com (imap.gv.tsc.tdk.com [192.168.241.198]) by gatekeeper.tsc.tdk.com (8.8.8/8.8.8) with ESMTP id BAA18702; Wed, 10 Jan 2001 01:48:48 -0800 (PST) (envelope-from gdonl@tsc.tdk.com) Received: from salsa.gv.tsc.tdk.com (salsa.gv.tsc.tdk.com [192.168.241.194]) by imap.gv.tsc.tdk.com (8.9.3/8.9.3) with ESMTP id BAA23165; Wed, 10 Jan 2001 01:48:47 -0800 (PST) (envelope-from Don.Lewis@tsc.tdk.com) Received: (from gdonl@localhost) by salsa.gv.tsc.tdk.com (8.8.5/8.8.5) id BAA20498; Wed, 10 Jan 2001 01:48:46 -0800 (PST) From: Don Lewis Message-Id: <200101100948.BAA20498@salsa.gv.tsc.tdk.com> Date: Wed, 10 Jan 2001 01:48:46 -0800 In-Reply-To: <20010109181609.B10100@skriver.dk> References: <20001218182600.C1856@skriver.dk> <20001219222730.A29741@skriver.dk> <200012201046.CAA19456@salsa.gv.tsc.tdk.com> <20001220155118.N81814@skriver.dk> <20001231210746.A81834@skriver.dk> <200101090702.XAA15712@salsa.gv.tsc.tdk.com> <20010109181609.B10100@skriver.dk> X-Mailer: Mail User's Shell (7.2.6 beta(5) 10/07/98) To: Jesper Skriver , Don Lewis Subject: Re: ICMP error processing (was: Re: what to do now ? Was: cvs commit: src/sys/netinet ip_icmp.c tcp_subr.c tcp_var.h) Cc: freebsd-net@FreeBSD.ORG Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Jan 9, 6:16pm, Jesper Skriver wrote: } Subject: Re: ICMP error processing (was: Re: what to do now ? Was: cvs co } On Mon, Jan 08, 2001 at 11:02:17PM -0800, Don Lewis wrote: } > In the current code, it looks like an ICMP error that the addresses } > and ports zeroed out will erroneously affect many sessions (what do } > the RFCs say?). } } rfc793 doesn't mention any specific range for port numbers apart form } being a 16 bit number, but it does say explicitly (in section 3.3) that } the sequence number is a range from 0 to 2**32 - 1 } } If the port numbers and/or addresses are zero we affect many (or even all) } sessions, I don't have anything near a full overview of the kernel, so I } don't know if there is any check anywhere else for zero in those addresses } and/or port numbers. There's none that I'm aware of. We just blindly copy whatever is in the payload of the ICMP error packet and feed that to in_pcbnotify(). If the data happens to be zero, then in_pcbnotify() treats it as a wildcard. } > Another bit of strangeness is pfctlinput(PRC_IF{UP,DOWN}, ...) which } > is passed the interface address, which is matched against the } > *destination* address in the TCP and UDP PCBs. Fortunately these } > protocols seem to ignore these commands ... } } As I see this we need a new function to do the same just for the source } address in TCP and UDP PCBs, right ? Or an API change to the wildcard version of PCB lookup allows the destination address to be wildcarded. The PRC_IF{UP,DOWN} handlers in the raw IP stack would need to be tweaked to compensate, and we'd need to sweep the source for other pieces of code that might be affected. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message