address spoofing

Mailman List Mirror (Read Only)
1

Greg A. Woods wrote:

[ On Friday, April 23, 1999 at 00:59:06 (-0500), Phil Howard wrote: ]
> Subject: Re: address spoofing
>
> My outbound access lists block it, so you should never see 1918
> sources coming from me. You should see "* * *" instead, even
> if you don't block them coming in to your net.

I think this sucks big-time. It wouldn't be quite so bad if traceroute
were the only thing that were broken by it (though I do like my
traceroutes to work properly too), but when all ICMP traffic from such a
router is hosed, and one of the links my packets are trying to hop onto
through such a router is down, then I'm a particularly unhappy camper
(if I could see the !H or !N I'd still be unhappy of course, but not
throwing my arms up in disgust at the guy generating the * * *). Of
course even an upstream provider from my own home network does this,
depsite the fact I've chided and cajoled and otherwise bugged them to
change it.

So are you making a case to allow RFC1918 source addresses out into the
network?

Now in Phil's networks perhaps it is normally impossible for illegally
formed host-unreachables to be generated even in the face of outages
because hopefully he's got everything running fully redundant, but *I*
see this kind of breakage from all kinds of places many times a day in
the filter logs on my networks and those of my clients.

There's also not really any difference between you blocking those
packets on the way out, and me blocking them on the way in -- the end
result is that all ICMP and whatever else from those routers is busted.

Perhaps router vendors can figure out some way to ensure that all
packets generated by a router get a unique, valid, non-RFC1918 number
when they would otherwise have used an RFC1918 number. Maybe people who
think they need to use RFC1918 should instead just hide all their
internal crap in a big ATM or FR cloud.

How do you hide an IP network?

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.

Then there's the crap I see in the filter logs on my HTTP transparent
cache and proxy machines that seems to indicate people have publicly
published URLs (perhaps with publicly visible DNS) that point at RFC1918
space..... Grrrrr.

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.

2

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.

not running a current bind, eh? :stuck_out_tongue:

the 8.x.x series bind dynamically picks up and drops interfaces as
they appear and disappear, and can be told on which interfaces to
listen. so...you can actually have a publicly available,
non-recursive name server to answer the queries for the zones for
which you need to be authoritative on the interface(s) to which those
zones are delegated.

then, you can have (if you want) another bind listening on other
interfaces for other stuff. like the "internal dns" server that you
mentioned. or maybe a recursive, caching-only server that listens
only on 127.0.0.1. of course...they can speak to each other if need
be. :slight_smile:

3

[ On Friday, April 23, 1999 at 21:25:29 (-0500), Phil Howard wrote: ]

Subject: Re: address spoofing

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.

How do you hide an IP network?

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!

It's damn near impossible to debug from the outside, of course, but
sometimes that's desirable! :wink:

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.

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.