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

[Bruce Simpson]

On 20/08/16 23:05, Slawa Olhovchenkov wrote:
> I am think this substitution is very bad idea (by design).
> Also, on transmit side this is must be irrelevant on received L2
> header (and this in many cases this is will be L2 unicast packet). For
> other cases packet will be created on host and don't have any received
> information.
>

Whilst I agree with your concerns about multipoint, I support the 
motivation behind Ryan's original change: optimize the common case.

On the other hand, I'm suggesting a slight extension to it -- one which 
would probably require adoption across some L2-exposed subsystems, or 
anywhere which might reinterpret an M_BCAST from re-entrant 
encapsulation (i.e. I receive a UDP broadcast packet, but my VPN daemon 
then decides it needs to be NATted and forwarded somewhere else).

Whilst I believe the scope for problems like this are limited (and 
perhaps to Netgraph permutations), I do believe they exist, and should 
be defensively coded for.

And: If, the logic for this can be factored out into one additional bit, 
in a conditional branch (or small set of those) in terms of delta to the 
existing FreeBSD data plane path -- i.e. my suggestion;

Then: we should be able to preserve correctness for multipoint 
configurations, without sacrificing performance.

Or, a possible tie-breaker:

...we ensure that M_BCAST is cleared at all times before possible 
re-entry, and use a separate M_BCASTL3 bit. Let the ethernet protocols 
decide themselves if re-entered about M_BCAST based on DMAC.

> On received side for host relaing on L2 information for accepting
> packet as host targeting sound like security hole.
>
> In router case receiving broadcast packet in any way need additional
> check for dst IP address (host part is all zero or all one? what about
> handling this broadcast type (RFC talk about conroling variation of
> this)? what about sysctl control of receiving routed broadcast
> packets? what about handling 255.255.255.255?)

I believe most of this is already special-cased in ip_fastfwd.c (which 
gnn@ of course has merged, as it's full of sensible FIB-like operators 
which most router forwarding planes adopt on *their* IP input paths up 
to the forwarding decision), assuming the Ethernet input path colours 
packets with the right flags.

Although, no direct distinction between IPv4 directed or undirected 
broadcast is made, until that code (or a full rtalloc()) is hit.

In the past, I have tried to "hack around" the issue on the output 
(send) side, by introducing IP_ONESBCAST from BSD/OS.

The fundamental problem there is that the IPv4 socket APIs were never 
designed to deal with 'with link' as well as 'with destination' 
particularly well -- i.e. to direct traffic to a particular host, with 
correct L2 resolution, but over a specific choice of link (or even, 
class of link).

So, for correct behaviour when handling packets like this, the XORP FEA 
and libfeaclient frameworks would attempt to fully-bind control sockets 
requiring broadcast input where possible (OLSR being one candidate, but 
there are also other protocols requiring them).

> In any way, this is irrelevant to L2 broadcast MAC and present L2
> broadcast flags.

On the contrary, I believe in teasing as much explanation about the 
Layer 2 Soup 'out there' and how in FreeBSD it is treated, as this lends 
much background to the original problem posed by Ryan's change, to those 
who may not be from a primarily networking-oriented background.