Subject: Re: Should loose source routing be enabled if not IPFORWARDING?
To: George Michaelson <G.Michaelson@cc.uq.oz.au>
From: John Hawkinson <email@example.com>
Date: 12/14/1994 00:41:12
> From: George Michaelson <G.Michaelson@cc.uq.oz.au>
> We've been using Net/FreeBSD as firewall boxes here, disabling
> IP forwarding and gateway options. A quick test revealed that if packets
> with IP options set to loose source route flow, they still transit in
> the kernel following the explicit route.
This is correct behavior, as documented by RFC1122, which states on
page 35, under section ``18.104.22.168 Options: RFC-791 Section 3.2'',
subsection (c) Source Route Options:
A host MUST support originating a source route and MUST be
able to act as the final destination of a source route.
If host receives a datagram containing a completed source
route (i.e., the pointer points beyond the last field), the
datagram has reached its final destination; the option as
received (the recorded route) MUST be passed up to the
transport layer (or to ICMP message processing). This
recorded route will be reversed and used to form a return
source route for reply datagrams (see discussion of IP
Options in Section 4). When a return source route is built,
it MUST be correctly formed even if the recorded route
included the source host (see case (B) in the discussion
> Locally the firewall expert has #ifdef'd this out, but theres an idea
> floating around the hosts requirements or related docs may obligate
> leaving lsr enabled.
Source routing by itself, either loose or strict, is not a security
risk. It is only a risk when it is misinterpreted (in this respect, it
is much like identd). Specifically, if, on a source-routed connection,
an application relies upon the IP address of the other end of a
connection for authentication purposes, then that application is
broken and insecure.
This is an issue for the application level, not for the operating
system. Admittedly, there are pieces of NetBSD-current that are not
conformant to the previous paragraph. If we want to fix this (which
sounds reasonable), then we should fix it "right", rather than wrongly.
Fixing it with a hammer (removing source routing support) has the unfortunate
consequence of breaking legitimate uses of source routing (right now
they're essentially confined to traceroute -g and telnet @site1:site2),
which many of us use every day and find to be particularly convenient. Fixing
it the right way has none of these disadvantages; the only problem is that
a poorly designed application can be fooled -- but poorly defined
applications can always be fooled.
> Anybody have any idea what NetBSD maybe should do by default? Seems to
> me that disabling forwarding doesn't neccessarily imply no packet transit
> through the kernel, and that a distinct option in the kernel config might
> be wanted to make a box into a firewall.
I think that NetBSD's proper default is clear -- it should continue
to support RFC1122; whether there ought to be an option to disable
source routing is not clear to me. There are arguments for and against,
but I fear that people would turn off source routing for the wrong reason,
and because of that, I think that such an option is a bad idea.
Again, a number of NetBSD programs probably ought to be a little more
careful with regard to source routing (for instance, the information
written to utmp/wtmp ought to be tagged in some way, Berkely-style
authentication should not succeed on source routed sockets, etc.).
I hadn't thought much about this with regard to NetBSD, but I'm certainly
willing to spend some time dealing with these problems...
RFC1122 Requirements for Internet hosts - communication layers. R.T.
Braden. Oct-01-1989. (Format: TXT=295992 bytes)