Messages in this thread | | | Subject | Re: Network Security hole (was -> Re: arp bug ) | Date | Sat, 2 Mar 2002 20:22:51 +0000 (GMT) | From | 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |