Re: Network Security hole (was -> Re: arp bug )

[Alan Cox]

> I would argue that this is a work-around to a problem, serves no
> useful purpose, and in general this is violating the "principle of
> least surprise".

I strongly disagree. The RFCs _are_ expected behaviour (with the odd
exception like URG which BSD redefined by force)

>   2)  In my example above (and in fact any case of very asymmetric
>       bandwidth) it ends up causing weird and highly suboptimal
>       misbehavior.

Because you ran two different speed networks over the same cable without
any seperation ?

> Can you give me an argument for why these should be present?  (like
> some kind of use for it?)

Internet standards. Along with the fact your perceived safety isnt there
in the first place. Consider a source routed frame. Consider the fact
most of your daemons bind to INADDR_ANY. It would be a false and misleading
appearance of security at best.

If you want a firewall use firewall rules. If an end user is not sure how to
set up a basic firewall they can run tools like gnome-lokkit and answer simple
questions.

> the arp thing, because I saw warning messages from my FreeBSD boxen
> about these weird arps.

FreeBSD binds arp to the specific interface, but accepts packets on any
(from memory). The warnings it issues about the ARPs are a bug because the
RFC's make no assertions about ARP replies being host or address based.

> on reception, just check against the exact expected input address,
> would actually be a performance improvement on machines with multiple
> NICs.

Hardly. You can have multiple addresses per nic anyway so its all the same
routing hashes. You can also have multiple nics with the same address. Its
already many<->many.

Alan