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