Re: "Microsoft Location Finder" - how is it supposed to work ?

On Thu, 27 Oct 2005 22:13:17 -0500, ibuprofin@xxxxxxxxxxxxxxxxxxxxxx
(Moe Trin) wrote:

>In the Usenet newsgroup alt.internet.wireless, in article
><p49vl1pqrd066s730tmfi4b5fq15hdin0i@xxxxxxx>, Jeff Liebermann wrote:
>
>>ICMP traceroute echoes can easily be forged.
>
>Not exactly sure what you mean by that.

I can fake the response that traceroute sees on machines that I have
control. For a while, I was having my firewall report that it was
routed through an IP address owned by the CIA.
http://www.thoughtcrime.org/fakeroute.html

>Intermediate routers can have a RFC1918 address without any problems.

Agreed. It just looks weird for traceroute. I was never quite sure
if it was acceptable practice or just offended my sense of propriety.
My only real complaint was that if the subnet matched the one I was
using for my inside LAN, reverse DNS would report that it was a local
machine.

>The only thing "magic"
>about RFC1918 addresses is that they are not supposed to be used across
>"enterprise" boundaries. This means that a customer could use such a
>range, but the ISP should drop them at it's interface, because if
>they received a packet from 192.168.1.1, they wouldn't have a clue
>where they should direct the reply - _which_ customer is using that?

Just about all Cisco ACL's drop non-routeable source IP's at the
external interface as a security measure to prevent outside attackers
from spoofing that they're coming from inside the firewall. Where the
fun starts is when the ISP assigns dual IP's to an external interface,
and one of them is RFC1918 non-routeable. That's what TCI (now
Comcast) did for some unknown reason. Fortunately, it didn't last
more than a few months.

>Looking at traceroute outputs, I've seen it used on national backbones,
>never mind ISPs. An ICMP error packets (such as types 3, 4, 11, and so
>on) do not allow for a reply (see the last paragraph on the first page
>of RFC0792). Those who follow RFC2827/3704 will normally drop packets
>with RFC3330 addresses (RFC1918 and a whole lot more) as source, because
>of the inability to use them with TCP, but may pass ICMP with the same
>source addresses.

Yep. That's how I spoofed the traceroute results without breaking the
routeing. I haven't seen any non-routeable IP's on the traceroute
results in quite a while.

>>Large system may have only one or two DNS servers located almost
>>anywhere on the planet.

The authoritative DNS servers for one of my domains are in Germany and
New Yuck. Another is in Pennsylvania and Smog Angeles. Globalization
in action.

>IANA registry requirements is a minimum of two servers.

I've lost count of how many DNS servers run dual IP's in order to meet
that requirement. It's actually the same server, but it shows up as
primary and backup DNS servers.

>>I'm not sure why anyone would even want to know the location of a DNS
>>server.

>Neither am I, but RFC1712 pertained to all hosts, not just DNS servers.

OK, then it was one of the early attempts to do geographic routing.
The theory was that everyone would eventually connect to everyone else
forming a networking "cloud". Instead of fixed routes, routes would
be assigned dynamically by the shortest distance the packet travelled.
That made quite a bit of sense in the days of dialup Telebit modems,
UUCP, and NFSNet running on DS0 (56Kbit/sec) lines.

--
Jeff Liebermann jeffl@xxxxxxxxxxxxxxxxxxxxxx
150 Felker St #D http://www.LearnByDestroying.com
Santa Cruz CA 95060 http://802.11junk.com
Skype: JeffLiebermann AE6KS 831-336-2558
.

Relevant Pages

  • Re: "Microsoft Location Finder" - how is it supposed to work ?
    ... The UNIX version of traceroute ... >interface, and one of them is RFC1918 non-routeable. ... >I've lost count of how many DNS servers run dual IP's in order to meet ... The availability of Geographical location ...
    (alt.internet.wireless)
  • Re: slow dsl/traceroute doesnt work
    ... has been extremely slow over the last period of time (three ... solved which may end up in a timeout for traceroute. ... T-Online will negotiate one or more dns servers to be ...
    (comp.os.linux.networking)
  • Re: Traceroute anomaly
    ... source of this traceroute - in C, of course - on the system. ... on the packet path over the IP network. ... is not open on the destination IP node. ... The ICMP packet contains the address of the receiving ...
    (comp.dcom.sys.cisco)
  • Re: Neotrace program snoops on me
    ... >> DNS servers. ... A client starts a traceroute to some computer. ... the TTL field in the IP packet by one. ... > those hops from McAfee's database. ...
    (alt.computer.security)
  • Re: It is a astonishing circumstance about trace route....
    ... >and the TraceRoute didn't stop when ICMP packet arrive at destination. ... the windoze version of traceroute uses ping. ... same host you reported the problem with, as this _is_ a dynamic address. ... TTL of zero. ...
    (comp.os.linux.networking)