nanog mailing list archives
Re: Traceroute and random UDP ports
From: "Crist Clark" <Crist.Clark () globalstar com>
Date: Wed, 13 Aug 2008 10:02:03 -0700
On 8/13/2008 at 6:13 AM, Jeff Aitken <jaitken () aitken com> wrote:On Wed, Aug 13, 2008 at 07:56:53AM -0500, John Kristoff wrote:Also, why do we increase the UDP port number with each subsequent traceroute packet that is sent?I don't know definitively, but I have an of educated guessFrom /usr/src/contrib/traceroute/traceroute.c:/* * Notes * ----- * [...] * The udp port usage may appear bizarre (well, ok, it is bizarre). * The problem is that an icmp message only contains 8 bytes of * data from the original datagram. 8 bytes is the size of a udp * header so, if we want to associate replies with the original * datagram, the necessary information must be encoded into the * udp header (the ip id could be used but there's no way to * interlock with the kernel's assignment of ip id's and, anyway, * it would have taken a lot more kernel hacking to allow this * code to set the ip id). So, to allow two or more users to * use traceroute simultaneously, we use this task's pid as the * source port (the high bit is set to move the port number out * of the "likely" range). To keep track of which probe is being * replied to (so times and/or hop counts don't get confused by a * reply that was delayed in transit), we increment the destination * port number before each probe. * [...] * -- Van Jacobson (van () ee lbl gov) * Tue Dec 20 03:50:13 PST 1988 */
Yep. That explains it pretty well. When I added an option to the FreeBSD traceroute to use a fixed destination port with TCP or UDP traceroutes, I had to overload the source port with the PID and the traceroute sequence number for UDP, http://www.freebsd.org/cgi/cvsweb.cgi/src/contrib/traceroute/traceroute.c.diff?r1=1.28;r2=1.29 Not to open a whole new can of worms, but in TCP traceroutes, which most "modern" traceroute implementations offer in addition to UDP and ICMP echo options, you can use the TCP sequence number as payload that will get reflected back in that 8-bytes of IP data that come back in the ICMP time-exceeded (or in the RST if you reach the target host). The overall lesson is that IP traceroutes are a kludge. But a fairly robust (i.e. you can get around/through lots of ACLs and firewalls) one given all of the options available in a good implementation. -- Crist J. Clark crist.clark () globalstar com Globalstar Communications (408) 933-4387 BĀ¼information contained in this e-mail message is confidential, intended only for the use of the individual or entity named above. If the reader of this e-mail is not the intended recipient, or the employee or agent responsible to deliver it to the intended recipient, you are hereby notified that any review, dissemination, distribution or copying of this communication is strictly prohibited. If you have received this e-mail in error, please contact postmaster () globalstar com
Current thread:
- Traceroute and random UDP ports Glen Kent (Aug 12)
- Re: Traceroute and random UDP ports Patrick W. Gilmore (Aug 12)
- Re: Traceroute and random UDP ports John Kristoff (Aug 13)
- Re: Traceroute and random UDP ports Jeff Aitken (Aug 13)
- Re: Traceroute and random UDP ports Crist Clark (Aug 13)
- Re: Traceroute and random UDP ports Joe Abley (Aug 13)
- Re: Traceroute and random UDP ports Matthew Luckie (Aug 13)
- Re: Traceroute and random UDP ports Jeff Aitken (Aug 13)