Re: address spoofing

[woods () most weird com (Greg A. Woods)]

[ On Sunday, April 25, 1999 at 02:46:31 (-0500), Phil Howard wrote: ]
> Subject: Re: address spoofing
>
> At what point should we draw the line and say who can, and who cannot,
> use RFC1918 addresses on links?  My first thought would be any link over
> which traffic from more than one AS transits, or between AS's, should
> always be fully routable.  Any better ideas?

I think the line's trivial to draw.  You can use RFC 1918 addresses on
any interfaces so long as the router can never generate a packet with
that address in it (either as a source address, or as part of the
protocol payload for something like "echo reply" which would confuse the
recipient).  I don't know if this is actually possible, but that's
irrelevant, of course!  ;-)

I.e. RFC1918 addressing for private links is fine so long as the outside
world will never see mention of those addresses.

> I remember the first place I put up a firewall, I blocked pretty much
> everything, include ping (from outside) and traceroute (from outside).
> The reason was to conform to corporate policy regarding confidentiality
> of facilities and resources to guard against competitors snooping around.
> Even so much as seeing how many IPs would answer ping was considered to
> be proprietary company information.  It was my goal to limit access to
> just those resources required for the company's business.  I think I did
> it pretty well.  I only got one complaint about it and that was from
> Randy Bush.

:-)

> I do see another possibility.  I would call these "public overload"
> addresses.  By public, they would be allowed to transit as sources.
> By overload, more than one use at a time could be made, although they
> should be unique within an administrative scope much as RFC1918 is.
> As to the impact that may cause on the net, I cannot say.  There could
> very well be more impact than RFC1918 has, so it's probably it a good
> idea.  I just see it as a possibility.

Hmmm... Yes.  I wonder if there's any way to prove that if such
addresses are used only as *source* addresses (and perhaps "echo reply"
values, etc.) that they'll never cause any packets to be generated in
response.  That way the overloading wouldn't cause as much of a problem.

I meant to mention last time that the use of a specific public block for
this purpose only is better than using RFC 1918 addresses because then
there's less confusion between internal management LANs and other truly
private uses.  If I use RFC 1918 addresses behind a firewall then I
cannot permit those packets on the public side.

Of course any overloading of a block of addresses means that you've got
to be particularly careful never to introduce routing in your "public"
infrastructure for the overloaded block -- I think that would be a clear
indication that you're using such addresses for the wrong purpose.

> I haven't seen how to do it in the newest BIND.  I tried some tricks but
> haven't managed to accomplish it.

I'm working on setting up a brand new set of systems for a client and
I'm going to try doing some split-brained DNS in production for them --
I'll try to remember to let you know how it works out and how I did it
if I'm successful.  Maybe something like this is worth writing a paper
or article about too, though I think I already have some references
squirrelled away somewhere.

-- 
                                                        Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods () acm org>      <robohack!woods>
Planix, Inc. <woods () planix com>; Secrets of the Weird <woods () weird com>