From owner-freebsd-net Mon Feb 18 20:15:33 2002 Delivered-To: freebsd-net@freebsd.org Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by hub.freebsd.org (Postfix) with ESMTP id 5A24D37B6EB; Mon, 18 Feb 2002 20:13:12 -0800 (PST) Received: from blossom.cjclark.org ([12.234.91.48]) by rwcrmhc52.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020219041312.SDVT1147.rwcrmhc52.attbi.com@blossom.cjclark.org>; Tue, 19 Feb 2002 04:13:12 +0000 Received: (from cjc@localhost) by blossom.cjclark.org (8.11.6/8.11.6) id g1J4DBq38446; Mon, 18 Feb 2002 20:13:11 -0800 (PST) (envelope-from cjc) Date: Mon, 18 Feb 2002 20:13:11 -0800 From: "Crist J. Clark" To: Archie Cobbs Cc: Ruslan Ermilov , Garrett Wollman , net@FreeBSD.ORG Subject: Re: rdr 127.0.0.1 and blocking 127/8 in ip_output() Message-ID: <20020218201311.V48401@blossom.cjclark.org> References: <20020214191906.A7309@sunbay.com> <200202190302.g1J32m991795@arch20m.dellroad.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200202190302.g1J32m991795@arch20m.dellroad.org>; from archie@dellroad.org on Mon, Feb 18, 2002 at 07:02:48PM -0800 X-URL: http://people.freebsd.org/~cjc/ Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org 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 | cjclark@alum.mit.edu | cjclark@jhu.edu http://people.freebsd.org/~cjc/ | cjc@freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message