On Mon, Feb 18, 2002 at 07:02:48PM -0800, Archie Cobbs wrote: > Ruslan Ermilov writes: > > > > ping -s 127.1 1.2.3.4 > > > > telnet -S 127.1 1.2.3.4 > > > > > > If someone explicitly overrides source-address selection, they are > > > presumed to know WTF they are doing, and the kernel should not be > > > trying to second-guess them. > > > > > That "someone" could be a bad guy playing dirty games with your box and > > certainly knowing what he's doing. :-) > > > > So far, noone gave me a real example where using of net 127 outside > > loopback would be useful. If there such an example exists, we should > > wrap all three checks into a sysctl, including ip_input(), ip_output(), > > and in_canforward() parts, where ip_input() exists for almost a year, > > and in_canforward() existed since 1987. > > No example is required. The kernel should not be implementing what > is essentially a policy decision. > > Note that the RFC you are holding up as gospel talks about hosts > on THE Internet, not hosts on some private test network. You assume > too much by assuming that all hosts running FreeBSD are connected > directly to the Internet.
No, RFC1122 is a set of requirements for hosts implementing _the Internet protocol._ 1. INTRODUCTION This document is one of a pair that defines and discusses the requirements for host system implementations of the Internet protocol suite. This RFC covers the communication protocol layers: link layer, IP layer, and transport layer. Its companion RFC, "Requirements for Internet Hosts -- Application and Support" [INTRO:1], covers the application layer protocols. This document should also be read in conjunction with "Requirements for Internet Gateways" [INTRO:2]. These documents are intended to provide guidance for vendors, implementors, and users of Internet communication software. They represent the consensus of a large body of technical experience and wisdom, contributed by the members of the Internet research and vendor communities. I believe it is the intention of FreeBSD to have a working, compliant IP implementation. > By your argument, the kernel should also block admin attempts to > configure RFC 1918 addresses (10.x.x.x, 192.168.x.x, etc.) on an > interface. That would put a lot of people behind NAT boxes out of > business. There are no requirements or references to RFC1918, 10.0.0.0/8, 172.16.0.0/12, or 192.168.0.0/16 in RFC1122. > If someone intentionally configures their machine in an unconventional > way, why automatically assume they are doing something wrong? > > My vote is to not have any special cases in the kernel for 127/8... > rc.conf, rc.network, rc.firewall, et. al. is fine, but nothing > in the kernel. You definately want to at least block incoming 127.0.0.1 in the kernel. Not doing so is a big security hole. Let's revisit that discussion all over again, http://www.securityfocus.com/archive/1/166648 -- Crist J. Clark | [EMAIL PROTECTED] | [EMAIL PROTECTED] http://people.freebsd.org/~cjc/ | [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
