On 23 Apr 99, at 11:26, Bret wrote:
> Hmm.. I think that something is not being communicated correctly here..
I agree. I wish I knew what -- I think I'd learn something from it.
> 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)..
Since the addresses are "unroutable", I'd suggest that a router that doesn't
deny them is, more or less by definition, broken or misconfigured.
> 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..
A light begins to dawn. Packets between my external address and yours may
traverse routers that are internal to some provider and use only private
addresses! These shouldn't normally be visible, but may leak, and specifically
are likely leak when tracert tries to traverse such an intermediate net. And
there's no way for my resolver to choose that provider's internal DNS to
resolve names to go with those addresses.
> 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)..
Now that I think I understand how this can arise from intermediary networks,
it's not clear to me that this configuration is necessarily incorrect; nor, still,
that providing global resolution for these addresses fixes (or, for that matter,
breaks) anything.
> 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)..
This I think I finally understand; it seems like for an intermediary configured
this way to allow tracert, they must leak such traffic.
I think the use of RFC1918 addresses for routers which may join two external
segments implies a policy of not leaking/broadcasting internal topology, and
so policy should be to block leakage of these addresses. OF COURSE this
makes it very hard for external customers to diagnose failures inside the
intermediary, but that's consistent with the policy. A provider who wants to
let outsiders perform diagnoses should not use RFC1918 addresses, right?
[I can see either policy being a legitimate choice; leaking addresses is a
failure of implementation to accurately track policy, rather than "incorrect"
in some objective sense.]
> >> 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..
Now here I'm lost again. I might query a local host's name to find its IP; if
I send that query externally, it will (should...) fail. But if I'm doing a
reverse query, it's probably because I don't know this host -- its IP arrived
externally -- and so externally is the reasonable query to make.
> 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..
Those externals (a) should never see these internal addresses, and (b) have no
reason to guess that there's a server inside that network that can resolve them.
I guess it's possible that some of the root-server traffic is from people
internal to such a provider, trying to resolve local addresses to names. I
wouldn't have thought there would be that many of them, but I honestly don't
know how common this configuration is or how widespread. Do we know what
proportion of reverse lookups against RFC1918 addresses reaching the root
servers are from RFC 1918 addresses themselves? (And therefore unable to
receive the "you should have queried an internal nameserver for this"
answer....)
> 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..
There's nothing on an RFC1918 address seen externally that would tell me
where some net might have an internal nameserver that can resolve it -- since
the traffic came from the outside, my query will be external and will go to
the root servers. Even if the network provider who leaked the RFC1918
address has a nameserver for it, my query will never see it. The volume of
my reverse queries to the root servers will not change, nor will the leakage
of RFC1918 addresses that prompts those queries.
David G
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
