---Reply to mail from David Gillett about read-rfc1918-for-details.iana.net
>> Technically yes, however in theory that doesnt work right.. People config
>> routers with the primary interface being a RFC1918 addr.. If I do a
>> traceroute to see if something is broke, then I may find that it goes to
>> provider A and then hits a RFC1918 addr, then breaks.. Well that lets me
>> know that it at least got to that router and gives me a little more info
>> to try to get a problem resolved (quicker)..
>
> Sorry, you've lost me.
>
> If you do a tracert against an RFC1918 address, the first thing that's going
> to happen is a reverse DNS lookup -- which, as I understand it, is part of
> what has prompted this change. I know that we have DNS set up locally *for
> the RFC1918 addresses that we use locally*, so my reasonable(?) expectation
> is that reverse lookups hitting the root servers are against RFC1918 ranges
> *not in use at the querying sites*. [Of course, my idea of "reasonable" may
> not apply elsewhere.]
> Having done a reverse-DNS lookup, tracert is then going to try to send to
> the RFC1918 address. This, of course, will die at the first router it hits;
> AFAIK, this is regardless of whether that router happens to use an RFC addr
> on its primary interface. I suppose it's possible that it will show slightly
> different results if the greakage that leaked the packet is actually *on* the
> router nearest to me, but what are the odds of that?
>
Hmm.. I think that something is not being communicated correctly here..
To comment on the RFC1918 router issue.. Only routers configured to deny
packets being sent to RFC1918 addrs will die at the first router.. Take
for instance the samples below (psi lets this get kinda far inside their
network before squashing it)..
My comment before was when people set up routers with an RFC1918 addr, and
I do a traceroute through their network, and they return that address..
That means they are sending out packets externally that arent addresses
they own.. I was commenting on that policy (becuase I think the fact that
IANA made dns entries for IPs they own to have been a subject that should
die (why I am no longer cross posting anything to the bind groups).. The
problem was that people didnt set up their networks correctly, it has been
identified and solutions mentioned, so I shifted my comments to one of a
firewall policy)..
My comment was on the fact that if you do block all of the outbound
traffic limiting it to IPs that you own, I wouldnt see the RFC1918 router
that my packets may get to and may help diagnose the problem faster
(sometimes stuff breaks from external paths, but not from internal, and a
lot of sites the people that fix problems dont care/too busy/dont know ...
etc)..
>> Net admins/firewall admins should filter all outbound traffic that isnt
>> from one of their assigned network numbers.. This makes it harder for
>> people to accidentally or intentionally spew out garbage (but wont prevent
>> a dns lookup on a RFC1918 addr) that shouldnt go outside.. But experience
>> shows that this isnt gonna happen globally any time soon :)
>
> I agree -- they (we!) should do it, and, by and large, can't or won't.
> BUT ... I assume that hosts don't just sit there all day doing reverse
> lookups against random RFC1918 addresses. They do lookups (quite possibly
> automatically...) against specific addresses to try and see where traffic
> from unrecognized hosts is coming from. The volume of traffic to root
> servers that prompted this change isn't IMHO "the problem", it's a *symptom*,
> and I don't see that the answer "somebody has misconfigured something
> somewhere" fixes anything. Putting recognition of RFC1918 addresses into the
> world's resolver libraries (like that would ever happen!) would at least cut
> down on the root server traffic, but still doesn't help locate address leaks
> or sources of spoofed traffic.
Yes, I would wager that the VAST majority of RFC1918 lookups are done from
internal connections.. How many people commented that they had problems
(one person with an MTA!) that was configured to use a RFC1918 address and
they had no local maps.. That is a misocnfiguration on their part, that
sholud be fixed..
If they didnt querry externally for internal hosts, they wouldnt querry
IANA.. The occasion that people traceroute through a network and see
a RFC1918 addr on a router, you will do a lookup (unless you do tracert
-d ... or traceroute -n ...) on that, but how often does that happen vs
people that use the addresses do not set up a DNS server (or other name
server since it really doesnt matter what the initial stuff is) to prevent
external lookups for internal addrs..
I would say that is a problem and not a symptom.. The problem is people
are looking outside rather than inside for internal connections.. I would
also say that the total quantity of packets that are spoofed from RFC1918
addresses are limited, and are more likely much smaller than the total
number of 'legit' packets sent from RFC1918 addresses..
--
Bret McDanel http://www.rehost.com
Realistic Technologies, Inc. 973-514-1144
These opinions are mine, and may not be the same as my employer
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
