Date: Sat, 20 Aug 2016 22:44:02 +0100 From: Bruce Simpson <bms@fastmail.net> To: Slawa Olhovchenkov <slw@zxy.spb.ru> Cc: Ryan Stone <rysto32@gmail.com>, "svn-src-head@freebsd.org" <svn-src-head@freebsd.org>, Ryan Stone <rstone@freebsd.org>, "src-committers@freebsd.org" <src-committers@freebsd.org>, "svn-src-all@freebsd.org" <svn-src-all@freebsd.org>, Adrian Chadd <adrian@freebsd.org> Subject: Re: svn commit: r304436 - in head: . sys/netinet Message-ID: <b4ff2915-3f12-4e63-e85c-6cd8a57c7f3f@fastmail.net> In-Reply-To: <0acba141-4701-d9c2-0ddb-46d1f60ff55b@fastmail.net> References: <fcb33eac-ec99-03c7-57b5-f24f86c4f41a@fastmail.net> <CAFMmRNwDPy4Hd35DrfREZQzjvd89qw=zhEriddG8U8NV7tD=EA@mail.gmail.com> <6f4449f2-d145-8b49-c3f0-433e8ff4d2a2@fastmail.net> <CAFMmRNypgJc00XH277oB3EEGje4xq%2B8_qcJfZu4jjBfTfa7GGQ@mail.gmail.com> <20160820173050.GQ22212@zxy.spb.ru> <CAFMmRNx=2v=M8GCBQ_cN4pnuZ4VnyzncwAgsqMUE=ebz7pkp2A@mail.gmail.com> <20160820184506.GV8192@zxy.spb.ru> <CAFMmRNy-e1uzdtz2cb5DAa9kRd%2BkHg%2BmWbf=HNDWVdGGjOPUWA@mail.gmail.com> <eb4c228e-8efe-b519-e85b-87800b3ec7a1@fastmail.net> <0f42c5fb-f930-c6e3-75d6-df97f67c201d@fastmail.net> <20160820204106.GW8192@zxy.spb.ru> <0acba141-4701-d9c2-0ddb-46d1f60ff55b@fastmail.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 20/08/16 22:17, Bruce Simpson wrote: > However, we still have to keep the FreeBSD-on-Ethernet ship sailing > smoothly. The intent of the original input path change is clearly for > performance, but perhaps slipping the M_BCAST tag in the stack is the > right way forward. > > I would also suggest: we add ability to qualify where in the stack > M_BCAST was raised (in case of any possible re-entry), by allocating one > more MBUF flag to Layer 2. > > Then, the same M_PROMISC flag trick can be applied... and Ryan's > broadcast performance boost could perhaps even carry across L2 bridging > tiers, e.g. stacked if_bridge or netgraph, providing we know what > direction in the stack it's traveling in (and its absolute ifnet origin) The main motivation for this: retain the original meaning of M_BCAST. (in addition to Ryan's intended new meaning that IP indicate to itself "This is IPv4 broadcast" and to others - it could be used to expedite delivery with some form of map). But, say, let's add a second flag which allows for controlled stacking of L2 in situations like this. Let's call it M_BCPROXY. It can be tracked for the original meaning, i.e. without the new meaning Ryan proposes for M_BCAST. When M_BCAST is set and M_BCPROXY is clear, we know the packet is broadcast, but we don't know for sure that this isn't because IP inspected it, and set the M_BCAST flag due to the destination IPv4 address being identified as such (and valid for its link, if you are enforcing the Strong IP End-Station model, RFC 1122 style, as is the BSD default). However, if we set M_BCPROXY at the same time, then, in situations where we might potentially re-enter the stack holding the same broadcast packet, we know that IP marked the packet as broadcast, and - on entry - can change our routing/switching/allocation/replication strategies accordingly. (This is not information which, on its own, holding the origin ifnet pointer provides; the flag is needed to sense direction in the stack.) So, as the mbuf chain is handed-off between other L2 entities (this can easily happen with stacked VLAN tags, in Q-in-Q and provider environments, which pfSense can service very well) - and, if the node itself determines that it is also a recipient of the broadcast, for correct hand-off if the broadcast does need to be forwarded by some other FreeBSD subsystem. It could also be checked by firewalls: e.g. for a corroborated check, from the mask of these two flags, where in the stack (or link forest) a purported broadcast packet actually originated from. (Pretty much essential for maintaining audit trail if a Smurf-like amplification attack is caught in the act, or if an NTP relay (or other association) terminates in an NTP broadcast association. And, of course, to trace dodgy broadcast Sun-style XDR RPC back to its source.)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?b4ff2915-3f12-4e63-e85c-6cd8a57c7f3f>