|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: address spoofing
Greg A. Woods wrote: > > So are you making a case to allow RFC1918 source addresses out into the > > network? > > Huh? No, I thought I was saying very much the opposite! I don't want > my upstream provider to use RFC1918 on inter-router links, but they do > anyway. I'd like them to filter those addresses too, but they won't. I do agree they should be filtered out. 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? > If you do all your internal routing over ATM or FR virtual circuits then > you won't need to (and in fact cannot) use IP numbers for those circuits > -- it all looks like the physical layer from IP's perspective (the > theory being that if you don't need IPs for inter-router links then you > won't be using precious unique IPs and feel the pressure to use RFC1918 > numbers instead). I'm certainly no expert at this, but from the outside > I've seen it done quite successfully. It sure cuts down on the hop > count visible from traceroute too! The FR cloud will look like one hop as far as I can see. But none of my RFC1918 links are FR or ATM. They are plain DS1/24*N (aside from the internal aliases, but those aren't even links). > It's damn near impossible to debug from the outside, of course, but > sometimes that's desirable! ;-) 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. > > If you're proposing another set of addresses be reserved for uses like > > this, then I'd be in favor of it with you. Using RFC1918 is certainly > > not the best way to do this, but using allocated space is no better as > > long as allocations are tight. > > Using any other set of reserved addresses would have exactly the same > problem as using RFC1918 addresses has. The only two viable options are > to either use globally unique addresses, or not to use any IP routing > internally at all. 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. > > People don't know how to separate their internet DNS from intranet DNS. > > Or maybe they don't want to put the money into that kind of structure. > > If BIND could be modified to deliver different results depending on the > > source of the request, or it's interface, then it might become easy for > > people to setup DNS to avoid this. > > Yes, it can be done, but even I am not yet using the latest software, > which makes this much easier, on all the machines I manage. I haven't seen how to do it in the newest BIND. I tried some tricks but haven't managed to accomplish it. -- Phil Howard KA9WGN [email protected] [email protected]
|