Re: Traceroute anomaly

My first attempt to respond didn't appear in the Google archive so I'm
trying again. My apologies if this appears twice.

Bri - short for Brian I guess

Hm - checking back on previous exchanges I have had over traceroute I
see that I have had something like this discussion before.

I believe my description of what seems universally to be called the
UNIX traceroute - to my mind, the "original" traceroute - is solid,
explains the reported behaviour with the UNIX traceroute[1] but
classifies it correctly as proper rather than anomalous behaviour.

I'm sorry I "muddied the water" with RFC 1393 and the IP "route
recording" option.

Do remember that I said I used to teach ICMP and what seems to have
happened is that I was so outraged that the ICMP-based "traceroute"
violated one of the principle dictates of ICMP that, although I have
had this ICMP-based "traceroute" explained to me before, I must just
have put it out of my mind.

The cardinal ICMP rule which is violated by this ICMP-based
"traceroute" is that an ICMP packet is never - supposed to be -
generated when the packet which might give rise to the ICMP packet is
itself an ICMP packet.

A clear illustration of the application of this rule is that the
author of the "original" UNIX traceroute chose to use an UDP packet as
his "probe" packet rather than an ICMP packet - and than had the
problem of how to try to be sure that the UDP packet would be rejected
at the destination IP node.

RFC 792 states as the last paragraph of the introduction:

<quote>

The ICMP messages typically report errors in the processing of
datagrams. To avoid the infinite regress of messages about messages
etc., no ICMP messages are sent about ICMP messages. Also ICMP
messages are only sent about errors in handling fragment zero of
fragmented datagrams. (Fragment zero has the fragment offset equal
zero).

</quote>

I constructed my presentation on ICMP in 1993 based on information I
had to hand which I imagined was the then current description of how
ICMP was supposed to behave. It may be that there is some later
approved RFC which somehow permits the ICMP-based "traceroute" to
operate as you describe - and illustrate.

The most recent RFC regarding ICMP I can find is RFC 4884 (one author
being from Cisco) dated April 2007. It specifies that it updates RFC
792 (which applies to ICMP for IP v4 and RFC 4443 which applies to IP
v6.)

RFC 4884 mentions qualifying RFCs later than RFC 792. It mentions RFC
1191, the Path MTU Discovery RFC, and RFC 1812, the requirements for
IP v4 routers RFC.

In reviewing RFC 1191 I noticed that I did not describe the source
address in the ICMP with the code for "destination unreachable"
correctly - and Barry did, although his use of the word "through"
rather than "from" confused me a bit. It is the IP address of the
interface over which the ICMP packet is *sent*, not the IP address of
the interface over which the "problem" packet was received. The
interface will tend to be - but may not be - the same. This is a key
consideration for the operation of the/a traceroute program and
relates directly to the subject of the original post.

Interestingly, if the interface is "unnumbered", the router's "router-
id" is used, the router-id being the IP address of another interface -
if I have understood section 2.2.7 correctly, Again this relates
directly to the subject of the original post.

In effect RFC 1812 appears to redefine the ICMP "cardinal rule" - and
may well perform the same "service" for other protocols for all I know
- by, when describing when an ICMP packet should *not* be sent -
section 4.2.3.7, slipping in the adjective "error" - in reference to
*unsolicited* ICMP packets - in

<quote>

An ICMP error message MUST NOT be sent as the result of receiving:

o An ICMP error message, or ...

</quote>

Interestingly, nowhere does it appear to justify this exception with
reference to the requirements of traceroute - but I expect that is
what is in mind. I imagine that it is logically considered sufficient
that the requirement to avoid ICMP "storms" is still met by allowing
*unsolicited* ICMP packets - described as "error" ICMP packets in RFC
1812 - to be sent in response to problems with *solicited* ICMP
packets - described as "query" ICMP packets in RFC 1812.

I guess it's just possible that there are still routers out there
which are not aware of Mr Baker's embellishment of RFC 792 as hidden
away in RFC 1812 - despite the June 1995 date. Such a router will not
feature in an ICMP-based "traceroute".

[1] Just to state again in order to "clarify the water":

The specified destination address is used as the actual destination
address with the ICMP-based "traceroute" because it is taken from an
ICMP response packet, which has had the source and destination
addresses exchanged, to the "probe" ICMP packet - that managed to
reach the destination IP node.

The specified destination address *may be* used as the actual
destination address with the UNIX traceroute if it happens to be the
IP address of the interface over which the final ICMP packet with the
code for "destination unreachable" is sent.

This is just a restatement of the key point in what Barry said but I
hope it now has a context which was the purpose for my earlier post.

Chris Mason

On May 4, 9:25 pm, bri...@xxxxxxxxxxxxxxxxx wrote:
In article <1178297176.378249.126...@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>, Chris Mason <chrisma...@xxxxxxxxxxxx> writes:

I say "supposed" "traceroute" because, from what you say, it would
appear that Windows TRACERT is actually probably PING with the route
recording option set - as I learned from exploring the possibilities
of the PING command on AIX and happily informing my most interested
students - well one in particular whose gratitude I recall!

Barry has it right (as he almost always does). Unix traceroute and Windows
tracert both operate in essentially the same way.

They send a series of probe packets out with restricted TTL's
They look for ICMP "time exceeded" responses from the intermediate
gateways. And they look for a different indication from the final
destination.

A UDP-based traceroute looks for an ICMP "port unreachable" from
the final destination.

An ICMP-based tracert looks for an ICMP echo reply from the final
destination.

I'm looking at a packet capture from a Windows tracert. No IP options
are set anywhere. The IP record route option is most definitely not in
use.

[Binary capture dumbed down to just the essentials]>>> ICMP echo request to target. TTL = 1

<<< ICMP time exceeded response from first hop gateway>>> ICMP echo request to target. TTL = 1

<<< ICMP time exceeded response from first hop gateway >>> ICMP echo request to target. TTL = 1

<<< ICMP time exceeded response from first hop gateway >>> ICMP echo request to target. TTL = 2

<<< ICMP time exceeded response from second hop gateway>>> ICMP echo request to target. TTL = 2

<<< ICMP time exceeded response from second hop gateway >>> ICMP echo request to target. TTL = 2

<<< ICMP time exceeded response from second hop gateway
...>>> ICMP echo request to target. TTL = n

<<< ICMP echo reply from target IP>>> ICMP echo request to target. TTL = n

<<< ICMP echo reply from target IP>>> ICMP echo request to target. TTL = n

<<< ICMP echo reply from target IP

I believe this "route recording" option corresponds to RFC 1393 dated
January 1993. The RFC may be read in order to get a description of the
"traceroute" I described above, identified as "Traceroute Today" in
the RFC and the newer technique identified as "Traceroute Tomorrow".

No. Nothing to do with RFC 1393. "Traceroute tomorrow" appears to have
been relegated to the dustbin of history.

The reason that the traceroute program I described may be preferred is
that it relies on basic ICMP behaviour rather than relying on routers
which understand the proposed RFC 1393 enhancement. The reason the
newer technique may be preferred is that it involves less network
traffic - but the effect on today's networks is trivial.

Microsoft doesn't need a reason to do things differently than everyone
else. But again, RFC 1393 isn't involved.

I'm told there are other flavours of "traceroute" out there which rely
purely on UDP or TCP packets in an attempt to dodge the depredations
of overzealous firewall administrators.

Google for tcptraceroute. It operates exactly like traceroute or
tracert. It sends TCP SYNs as probes, looks for ICMP time exceeded
datagrams from the intermediate hops and expects a TCP RST or TCP SYN+ACK
from the final destination.


.

Relevant Pages

  • Re: Traceroute anomaly
    ... RFC 1122, "Requirements for Internet Hosts - Communication Layers", ... interest regarding this disputed "change" to ICMP processing concerns ... ICMP packet ought not to be created - about whether or not an ICMP ... The ICMP-based traceroute relies on undocumented behaviour no matter ...
    (comp.dcom.sys.cisco)
  • RE: traceroute-like tool for UDP or TCP packet
    ... >> Linux uses UDP packets to traceroute, ... an ICMP packet is a type of UDP packet. ...
    (Security-Basics)
  • Re: Traceroute anomaly
    ... that it is concerned to prevent mistaken interpretations of RFC 792 by ... dealing with misinterpretations of how to handle ICMP. ... It was to prevent a storm of error messages being raised in response to ... routers, namely Cisco, should implement its traceroute using the UDP- ...
    (comp.dcom.sys.cisco)
  • RE: traceroute-like tool for UDP or TCP packet
    ... an ICMP packet is a type of UDP packet. ... What kind of packet traceroute sends depends on what the ...
    (Security-Basics)
  • Re: disable traceroute to my host
    ... i can't just block whole icmp .. ... block certain range,type whatever was that just for traceroute .. ... >> (udp based). ... >> seen any packet in the wild with ttl=1 wich was not a traceroute. ...
    (FreeBSD-Security)