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.)
_______________________________________________
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
