Re: Access to the Internic Blocked -- LSRR, traceroute with ICMP
Speaking of which, is anyone going to implement traceroute for UNIX which using icmp echo requests, instead of (semi-)random udp packets, as the ammo? This is one way which I think Microsoft out did the old UNIX implementations.
Then how come UNIX traceroute works in so many places where MSloth's traceroute falls flat on it's face? Remember, an ICMP packet doesn't generate TIME EXCEEDED messages in many applications. It's listed as something the system MAY implement, not SHOULD or MUST. Time exceeded messages are a MUST for UDP and TCP packets.
They're not semi (or quasi) random udp packets. They're sequential packets.
Secondly, current router vendors' decisions to prioritize ICMP echo request as dung-level packets means that traceroute's UDP packets actually get through at times when pings don't.
This is both good and bad.
Third, I'd be happy to implement it... but I'm not sure this would be a win. I can see the loss (see paragraph 2), but WHAT is the big win???
Compatibility with Whine-Doze? :-)
E p.s. The original question was based on Vadim's rhetorical query as to router vendors. Learn to differentiate between WISHFUL THINKING and routing reality. When router vendors pledge to not drop, and properly route lsrr icmp echo request/reply that code will be online within 24 hours.
:-) Owen
The combination of the above and the below would give us the usefulness we want and the security we want. (I don't think the below would work with Van Jacobsen's traceroute 1.2)
On Wed, 21 Aug 1996, Vadim Antonov wrote:
On itself, LSRR is a godsend to hackers (i can think of about a dozen of very nasty attacks using general LSRR). The only useful application for it is traceroute.
Why don't router vendors provide an option to turn it off for everything but ICMP ECHO?
--vadim
Speaking of which, is anyone going to implement traceroute for UNIX which using icmp echo requests, instead of (semi-)random udp packets, as the ammo? This is one way which I think Microsoft out did the old UNIX implementations.
Then how come UNIX traceroute works in so many places where MSloth's traceroute falls flat on it's face? Remember, an ICMP packet doesn't generate TIME EXCEEDED messages in many applications. It's listed as something the system MAY implement, not SHOULD or MUST. Time exceeded messages are a MUST for UDP and TCP packets.
I've just got to be missing something here. Microsoft is confused about ICMP if they are really doing what you say. On Page 1 ("Introduction") of RFC 792: 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. [...] So, an ICMP [8,0] (Echo Request) whose TTL falls to 0 cannot cause an ICMP [11,0] (Time Exceeded) from an RFC 792 compliant gateway. BSD (all versions) gets this right. What gateways are doing this wrong, and are their vendors represented on NANOG? Or was RFC 792 amended and I didn't hear about it?
In message <9608221619.AA21183@wisdom.home.vix.com> Paul Vixie wrote:
Or was RFC 792 amended and I didn't hear about it?
Both RFC1122 and RFC1812 specifically say "ICMP error message", and classify ECHO_REQUEST as an "ICMP query message". RFC1122 seems to claim that it amends RFC792. Bill
participants (3)
-
Bill Fenner -
owen＠DeLong.SJ.CA.US -
Paul A Vixie