Re: Blocked incoming ICMP, getting outgoing ICMP [3] Destination Unreachable


On Sat, 25 Feb 2006, in the Usenet newsgroup, in article
<44011981$0$46421$892e7fe2@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>, Dom wrote:

windoze imitation version of traceroute
The real LBL traceroute

How 'bout clearing up this distinction between real and imitation
traceroute. I just don't understand the contention surrounding
Microsoft's traceroute. Do they both not accomplish the same thing?

As you demonstrate in the following post, no. In (roughly) 1987, Van
Jacobson (then at Lawrence Berkeley National Lab) created traceroute to
debug networking problems based on a suggestion from Prof. Steve Deering
(then at Stanford). Since then, there have been several other versions
inspired by the LBL version, and several other tools that use the same
concept for different ends.

I would argue that ICMP echo is the proper protocol for a traceroute
because a firewalled target host is most likely to reply to an echo

Watch the line wrap here:

The original ip spec (rfc791) said that you should never send an
icmp error in reponse to an icmp packet. Several years later
this was amended to "... in response to an icmp *error* packet" but,
at the time that traceroute was written, most router vendors had
implemented according to the original spec & wouldn't send an
icmp time exceeded in response to an icmp echo or echo reply.

I would place hping above all other traceroute utilities. Hping
can perform traceroutes with many protocols and ports.

Yes, but hping is not primarily a traceroute tool. I also have... I was
going to say some number, but realize I don't know how many different
tools on this system can do a traceroute type function - it's at least
a dozen.

On Sun, 26 Feb 2006, in the Usenet newsgroup, in article
<44016b8b$0$49311$892e7fe2@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>, Dom wrote:

Dur, that's how they all work regardless of the protocol used. However,
I think it's important that the target host respond to the protocol
used, else you end up with something like the following.

And there you hit the nail squarely. ICMP (and indeed several protocols
and services) have been abused quite badly over the years, resulting in
firewalls that block many helpful tools. In the late 1990s, the skript
kiddiez discovered that microsoft's usual incompetent programming skills
had created a b0rken network stack that could be kicked over by sending
one of a number of different specially crafted packets - I'll mention only
the "ping-of-death" so fondly enjoyed by wankers everywhere. The result
was that a lot of networks suddenly got firewall rules that dropped ICMP
echo (silently, as per RFC0792).

People seem to forget that the (big I) Internet is a _cooperative_
network, and members of that network are under no compulsion to accept
_any_ traffic from _anywhere_ or anyone. If I decide not to allow traffic
from hosts that have the digit '2' in their IP address - that's my business,
and if that prevents you from connecting - tough nuggies. The statement
is more commonly seen on posting is as
"my servers, my rules", but it applies to networking just as much.

$ traceroute6

And of course none of the original traceroute versions supported the then
non-existant IPv6.

traceroute6 to (2001:440:2000:1::21) from
2001:5c0:8ec3:0:211:11ff:fe33:e364, 64 hops max, 12 byte packets

4 299.767 ms * 92.365 ms

10 296.599 ms 299.514 ms 301.235 ms

17 335.771 ms 327.331 ms 330.071 ms

Reminds me of the original traceroute - half way around the world to get
to a place a few hundred miles away. For people who aren't aware, Dom seems
to be in Quebec, Canada, and the trace to ARIN (in the Washington, DC metro
area) has wandered all over h*ll and gone ( is near Tokyo)
because this is an IPv6 trace.

[compton ~/IP.ADDR/stats]$ zwc -l [ALR]* | column
1002 AFRINIC.gz 36528 ARIN.gz 20431 RIPE.gz
12127 APNIC.gz 1619 LACNIC.gz 71707 total
[compton ~/IP.ADDR/stats]$ zwc -l
[compton ~/IP.ADDR/stats]$

71707 IPv4 assignments world wide verses 1410 IPv6. It's the coming thing,
but "it ain't here yet".

I'd like to see that you're right. But ICMP echo filtering is a
widespread disease in the days of "Personal Firewalls" and "stealthing".

Which would you consider more likely: A firewall that blocks echo
requests without stealthing udp 34000-35000 (or whatever the hell ports
it is)

33434 + 1 for each hop - call it 33434 -33500, chosen because there was
little likelihood of the port being in use.

or a firewall that stealths udp and allows echo requests.

And the answer is "that depends". A web page at the NSA (National Security
Agency) recommended:

deny icmp any any echo
deny icmp any any redirect
deny icmp any any mask-request
permit icmp any

The web page now 404's, but that seems to have been derived from page 89 of
the Cisco Security Guide. Translated, that is block Type 8, 5, 17. I
disagree, suggesting that you allow types 0, 3, 4 and 11 INBOUND, 3, 4, and
8 OUTBOUND, while denying all else (remember that statement above - "my
servers, my rules"). Some may consider type 4 (Source Quench) as undesirable
(possible DOS). YMMV. ICMP type 3 code 4 is necessary to support Path MTU.
See RFC2923. As regards blocking UDP - at home I ignore 1025-1100 inbound
unsolicited - as a result of microsoft's incompetent re-invention of the
talk daemon being used as a spamming tool. At work, the perimeter firewalls
port translate outbound 1025-1050ish to a higher range, so there is never
any legitimate inbound traffic on that range. This allows our upstream to
silently drop that traffic. At a half Meg of crap per day per IP address,
this adds up to a substantial number with a /16 or greater.

Mind that I'm not accusing anyone of getting overzealous in this thread,
but I've seen some fierce debate in the past on this subject and I fail
to perceive the superiority of udp trace over icmp.

I haven't seen that much in debate, although google seems to indicate
otherwise, but it's starting to become a moot point. As a WAG, about 20%
of my UDP traces die before or at the destination, compared to maybe 33% for
ICMP. I have much better luck using "other" protocols, and only run into
problems where there is a block of ICMP 3 or 11. I suppose if I were
tracing to "home" IP ranges, that 20% or 33% figure would be much higher,
but I rarely have the need to make such a trace.

Old guy

Relevant Pages

  • Re: icmp type 11 not go via nat POSTROUTING table
    ... everthing is working as it "should", there is no reason for a "ICMP ... I generated two test icmp packets ... This is how traceroute knows the IP of the ... If x.y.z.t is a private IP address, it cannot be tracerouted anyway, so ...
  • Re: Traceroute anomaly
    ... Hm - checking back on previous exchanges I have had over traceroute I ... I'm sorry I "muddied the water" with RFC 1393 and the IP "route ... Do remember that I said I used to teach ICMP and what seems to have ... generated when the packet which might give rise to the ICMP packet is ...
  • Re: set srcIP for ICMP replies, or for locally sourced connections?
    ... I just performed a traceroute from a Windows XP host through my IPSec+ GRE VPN, and captured it with Wireshark to confirm my beliefs. ... The router that gets the packet with a TTL of 1 will reply with an ICMP TTL exceeded message. ... Extended ping permits you to specify the source IP address that will be used in the outbound ping, which then becomes the destination IP address in the reply packet. ... But that would block replies from simple outbound pings and traceroutes from router CLI sessions. ...
  • ICMP pokes holes in firewalls...
    ... Traceroute uses two protocols: UDP and ICMP ... A system inside a firewall performs a traceroute to a system ... Traceroute chooses the next available UDP port. ...
  • Re: Linux Routing Issue
    ... I'm hoping some of you network experts out there ... Ping uses ICMP. ... traceroute and ping should give identical results. ...