From owner-freebsd-net Mon Feb 18 21: 0:59 2002 Delivered-To: freebsd-net@freebsd.org Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26]) by hub.freebsd.org (Postfix) with ESMTP id E113937B417; Mon, 18 Feb 2002 21:00:54 -0800 (PST) Received: from arch20m.dellroad.org (arch20m.dellroad.org [10.1.1.20]) by InterJet.dellroad.org (8.9.1a/8.9.1) with ESMTP id UAA70142; Mon, 18 Feb 2002 20:44:22 -0800 (PST) Received: (from archie@localhost) by arch20m.dellroad.org (8.11.6/8.11.6) id g1J4hji92220; Mon, 18 Feb 2002 20:43:45 -0800 (PST) (envelope-from archie) From: Archie Cobbs Message-Id: <200202190443.g1J4hji92220@arch20m.dellroad.org> Subject: Re: rdr 127.0.0.1 and blocking 127/8 in ip_output() In-Reply-To: <20020218201311.V48401@blossom.cjclark.org> "from Crist J. Clark at Feb 18, 2002 08:13:11 pm" To: "Crist J. Clark" Date: Mon, 18 Feb 2002 20:43:45 -0800 (PST) Cc: Archie Cobbs , Ruslan Ermilov , Garrett Wollman , net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL88 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII 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 Crist J. Clark writes: > No, RFC1122 is a set of requirements for hosts implementing _the > Internet protocol._ OK... > > 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. Obviously, because 1918 > 1122. But I don't understand your point. My point is that if it's a private network, you can do whatever you want -- standards that were created to make machines on the same network interoperate don't apply to X if X is on a separate network. There are real people with valid reasons for doing "weird" things, for testing or whatever, on private networks. We shouldn't make life hard for them. If your host sends a 127/8 packet, I'd say chances are better than 90% that you intentionally configured it to do so. Note that "normal" people will still get the standard configuration which prevents transmitting 127/8 packets, as it has for many years, without this new change. So I don't see what the conflict is here, or why this extra check, which adds complexity and confusion, is needed. > > 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 Yes, of course. We're talking about sending, not receiving, packets though. -Archie __________________________________________________________________________ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message