svn commit: r304436 - in head: . sys/netinet

[Bruce Simpson]

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.)