From owner-freebsd-net Tue Jan 9 18:57:43 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 2427637B401; Tue, 9 Jan 2001 18:57:22 -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 SAA12818; Tue, 9 Jan 2001 18:57:05 -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 SAA21337; Tue, 9 Jan 2001 18:57:05 -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 SAA19637; Tue, 9 Jan 2001 18:57:05 -0800 (PST) From: Don Lewis Message-Id: <200101100257.SAA19637@salsa.gv.tsc.tdk.com> Date: Tue, 9 Jan 2001 18:57:04 -0800 In-Reply-To: <3A5BC1D5.E5F57AE0@softweyr.com> References: <3A5BC1D5.E5F57AE0@softweyr.com> X-Mailer: Mail User's Shell (7.2.6 beta(5) 10/07/98) To: Wes Peters , Mike Silbersack Subject: Re: Spoofing multicast addresses Cc: Umesh Krishnaswamy , freebsd-security@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org [ freebsd-net added ] On Jan 9, 6:58pm, Wes Peters wrote: } Subject: Re: Spoofing multicast addresses } Mike Silbersack wrote: } > } > The check is done when the SYN is received, hence such a situation as you } > describe should not be able to occur. } > } > >From tcp_input.c: } > } > /* } > * RFC1122 4.2.3.10, p. 104: discard bcast/mcast SYN } > * in_broadcast() should never return true on a received } > * packet with M_BCAST not set. } > * } > * Packets with a multicast source address should also } > * be discarded. } > */ } > if (m->m_flags & (M_BCAST|M_MCAST)) } > goto drop; There are some additional sanity checks that were omitted from this message. } The real problem is this check is 675 lines into tcp_input, but probably } should be at the top. I've just rescanned this and don't recall if m->m_flags } is set before tcp_input is called, or by one of the numerous functions called } in the code leading up to this check. The flags are set before tcp_input is called based on link level information. A good reason for putting these checks in their present location is that it gets them out of the main code path. Under normal circumstances, the vast majority of the incoming packets will be for established connections and it wasteful to do unnecessary checking on these packets. We need to do a PCB lookup for each incoming packet in any case, so if we never create a PCB containing any invalid addresses, then we only need the extra sanity checking on packets that don't have a matching PCB. Optimising the most frequently used code path leaves more CPU cycles available for the application. Now if someone floods the server with garbage packets, we'll expend more CPU cycles handling them than if the sanity check was done first, but there are likely to be spare CPU cycles available because the real clients won't be getting through the flood to exercise the application code. } The comment about discarding bcast/mcast SYN is misleading, there is NO } properly formatted TCP packet *to or from* a broadcast or multicast address. See what the RFC1122 4.2.3.10 says. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message