|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: address spoofing
[ 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 <[email protected]> <robohack!woods> Planix, Inc. <[email protected]>; Secrets of the Weird <[email protected]>
|