Date: Mon, 18 Feb 2002 23:35:54 -0800 From: "Crist J. Clark" <crist.clark@attbi.com> To: Archie Cobbs <archie@dellroad.org> Cc: Ruslan Ermilov <ru@FreeBSD.ORG>, Garrett Wollman <wollman@khavrinen.lcs.mit.edu>, net@FreeBSD.ORG Subject: Re: rdr 127.0.0.1 and blocking 127/8 in ip_output() Message-ID: <20020218233554.X48401@blossom.cjclark.org> In-Reply-To: <200202190443.g1J4hji92220@arch20m.dellroad.org>; from archie@dellroad.org on Mon, Feb 18, 2002 at 08:43:45PM -0800 References: <20020218201311.V48401@blossom.cjclark.org> <200202190443.g1J4hji92220@arch20m.dellroad.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Feb 18, 2002 at 08:43:45PM -0800, Archie Cobbs wrote:
> 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.
:) Good point. I meant references to the subject matter of
RFC1918. (Not that RFCs don't frequently reference other RFCs with
numbers greater than theirs.)
> 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.
You can always do what you want. No one says you have to use the
Internet protocol to have your systems communicate.
> 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.
I have no problem making life easy 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.
Exactly. I don't think anyone has a problem with letting people
configure their machines to do something pathological like sending
loopback packets outside of a host. But a stock system, that is, one
out of the box, should be compliant with the Standard and NOT do
this.
> 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.
No, as I have had to repeat many times, a stock FreeBSD system did NOT
behave properly in this respect. Take a stock FreeBSD system before
the change, sniff the default route, and type,
$ ping 127.0.0.2
And watch the loopback packets head out onto the wire.
> So I don't see what the conflict is here, or why this extra check,
> which adds complexity and confusion, is needed.
I'd personally prefer someone just fix lo0 so that,
$ ifconfig lo0 inet 127.0.0.1
Actually added the route,
127 127.0.0.1 UGSc 0 0 lo0
Like,
$ ifconfig lo0
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
inet 127.0.0.1 netmask 0xff000000
Would imply, but it doesn't. I started digging into the code to see
about fixing this, but no one seems to be sure if this brokeness is
intentional or not, so I never got too enthusiastic.
Short of fixing this, blocking 127/8 in the kernel makes life a little
harder for those who want to do exotic things on their own nets, but
it does prevent the leakage.
> > > 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.
But what's the point of sending them if systems can't receive them? If
you need to remove five lines ip_input.c to get them in the machine,
why not just remove the same five from ip_output.c too (not that
in_canforward(), in.c, hasn't blocked loopback packets for even longer
than the input and output routines).
One more time, my opinion on the best balance between having a default
compliant system, but something people can do whatever kinky things
they want in the privacy of their own ASs is (and the coding for
this is trivial... once I find where the heck the loopback isn't being
configured):
1) Remove the ip_output.c code blocking 127/8 destinations once the
lo0 puts a route for 127/8 into the routing table.
2) Put a sysctl(8) wrapper on the ip_input.c check,
net.inet.ip.acceptloopback.
3) Put a sysctl(8) wrapper on the in_canforward() check and 127/8 as a
source address, net.inet.ip.fwdloopback.
Would anyone be terribly unhappy with that or something like that?
--
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020218233554.X48401>