> 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 ``3.2.1.8 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
          below).

> 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.

Absolutely.

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...

References:

RFC1122 Requirements for Internet hosts - communication layers. R.T.
        Braden. Oct-01-1989. (Format: TXT=295992 bytes)

--
John Hawkinson
jhawk@panix.com