The outgoing packets from traceroute are sent towards the destination
using UDP and very high port numbers, typically in the range of 32,768
and higher. This is because no one is gernally expected to run UDP
services up there, so when the packet finally reaches the destination,
traceroute can tell that it got to the end (because the ICMP changes
from "TTL exceeded" to "port unreachable").
My question is: What if the receiver is actually listening on one of
the "random" UDP ports? What would happen in such cases?
Also, why do we increase the UDP port number with each subsequent
traceroute packet that is sent?
The outgoing packets from traceroute are sent towards the destination
using UDP and very high port numbers, typically in the range of 32,768
and higher. This is because no one is gernally expected to run UDP
services up there, so when the packet finally reaches the destination,
traceroute can tell that it got to the end (because the ICMP changes
from "TTL exceeded" to "port unreachable").
My question is: What if the receiver is actually listening on one of
the "random" UDP ports? What would happen in such cases?
Depends on what is running there.
Given people randomizing things like DNS ephemeral ports, if they're not careful, it will probably happen more often.
Also, why do we increase the UDP port number with each subsequent
traceroute packet that is sent?
The outgoing packets from traceroute are sent towards the destination
using UDP and very high port numbers, typically in the range of 32,768
and higher. This is because no one is gernally expected to run UDP
services up there, so when the packet finally reaches the destination,
traceroute can tell that it got to the end (because the ICMP changes
from "TTL exceeded" to "port unreachable").
Yes, this is correct. Note that this is all the case largely due to
historical artifact of how TCP/IP stacks at the time behaved. For
example, UDP was chosen simply because some hosts took the notion of not
replying to ICMP error messages literally, making the use of an ICMP
traceroute tool early on unreliable. This, I believe, is no longer the
primary problem now, filtering is. This is often why a TCP-based
traceroute to port 80 is so useful these days.
My question is: What if the receiver is actually listening on one of
the "random" UDP ports? What would happen in such cases?
You probably won't get a response from that message. Most UDP
listeners tend to be silent unless a well formed message arrives that
requires a response. So it may look like you have reached the host for
at least that one traceroute packet.
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 guess Since by
default the original traceroute tool sent three packets per TTL it
might not only increase likelihood of one getting through, but also the
likelihood of hitting a closed port. For further information I
sugguest consulting Stevens TCP/IP Illustrated chapter 8, dated, but
still an indispensable resource.
/*
* 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
*/
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,
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.
These days there are better implementations of traceroute that are less
likely to infer false IP paths by not playing games with the source and
destination ports.
Paris traceroute hacks the payload of the UDP probe to use the checksum
field as the probe identifier (and also uses the IPID field as a backup
since NATs will change the checksum). Paris traceroute also has an ICMP
mode.