Greg A. Woods
woods at most.weird.com
Sun Apr 25 17:02:23 UTC 1999
[ 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 at acm.org> <robohack!woods>
Planix, Inc. <woods at planix.com>; Secrets of the Weird <woods at weird.com>
More information about the NANOG