Date: Tue, 9 Jan 2001 18:57:04 -0800 From: Don Lewis <Don.Lewis@tsc.tdk.com> To: Wes Peters <wes@softweyr.com>, Mike Silbersack <silby@silby.com> Cc: Umesh Krishnaswamy <umesh@juniper.net>, freebsd-security@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: Spoofing multicast addresses Message-ID: <200101100257.SAA19637@salsa.gv.tsc.tdk.com> In-Reply-To: <3A5BC1D5.E5F57AE0@softweyr.com> References: <Pine.BSF.4.31.0101082237330.11619-100000@achilles.silby.com> <3A5BC1D5.E5F57AE0@softweyr.com>
next in thread | previous in thread | raw e-mail | index | archive | help
[ 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200101100257.SAA19637>