Until now, the probes payload consisted of a 4-byte payload
which was computed by simple addition/subtraction to balance
out the checksum.
As payload computation was fully predictable with the operands
set by the client (and extracted by the server from the tr-requests),
the client had the ability to create a potentially malicious payload
that could be delivered to targets via IP spoofing.
Now the payload size is increased to 8-bytes, 6 of which are pseudo-randomly
generated. The last 2 bytes are used to balance out the checksum.
By introducing randomness into the computation, a malicious user no
longer has the ability to take control over the payload.
Updated ICMP Probe Encoding
Until now, the ICMP identifier of the probe contained the constant probe ID,
which was used to check if the response may be an answer to a probe.
This has the drawback that when ping/traceroute are run on the server
machine, the ICMP identifier could overlap, leading to ping/traceroutes
responses being dropped by reverse traceroute or worse, invalid measurements.
Now the constant probe identifier is encoded into the ICMP sequence,
setting it to the highest possible value 0xffff.
The requests query identifier is encoded into the probe's ICMP identifier.
This has the following advantage:
As classic traceroute uses its process ID (or an incremental value) to encode it inside the
ICMP identifier of generated probes and sequentially increments the
ICMP sequence field to match individual probes with responses,
the likelihood of clashes with a reverse traceroute server is
minimal: That is because we chose the highest possible value for the
probe identifier to be encoded into the ICMP sequence field. Classic
traceroute/ping will terminate before they reach such a high
sequence, and even if they do, this will lead to a single response
being dropped by the interference of reverse traceroute.
Paris-Traceroute on the other hand increments the ICMP identifier
and keeps the sequence at 0. There should be no clashes with
this tool either.
Dropping Traceroute Responses with no active Session
All possible reverse traceroute responses are now dropped when no corresponding session can be found by the server.
As both UDP and TCP probes are identified by the source port 1021, a port number reserved for experimental use,
traffic should not be disrupted (unless of course other software relies on the use of this port number).
With the updated probe encoding ICMP probes use the sequence 0xffff.
Possible responses that reflect this value are therefore dropped as well.
Introducing Probe Randomization
Until now, the probes payload consisted of a 4-byte payload which was computed by simple addition/subtraction to balance out the checksum. As payload computation was fully predictable with the operands set by the client (and extracted by the server from the tr-requests), the client had the ability to create a potentially malicious payload that could be delivered to targets via IP spoofing.
Now the payload size is increased to 8-bytes, 6 of which are pseudo-randomly generated. The last 2 bytes are used to balance out the checksum. By introducing randomness into the computation, a malicious user no longer has the ability to take control over the payload.
Updated ICMP Probe Encoding
Until now, the ICMP identifier of the probe contained the constant probe ID, which was used to check if the response may be an answer to a probe. This has the drawback that when ping/traceroute are run on the server machine, the ICMP identifier could overlap, leading to ping/traceroutes responses being dropped by reverse traceroute or worse, invalid measurements.
Now the constant probe identifier is encoded into the ICMP sequence, setting it to the highest possible value
0xffff. The requests query identifier is encoded into the probe's ICMP identifier. This has the following advantage:As classic traceroute uses its process ID (or an incremental value) to encode it inside the ICMP identifier of generated probes and sequentially increments the ICMP sequence field to match individual probes with responses, the likelihood of clashes with a reverse traceroute server is minimal: That is because we chose the highest possible value for the probe identifier to be encoded into the ICMP sequence field. Classic traceroute/ping will terminate before they reach such a high sequence, and even if they do, this will lead to a single response being dropped by the interference of reverse traceroute.
Paris-Traceroute on the other hand increments the ICMP identifier and keeps the sequence at 0. There should be no clashes with this tool either.
Dropping Traceroute Responses with no active Session
All possible reverse traceroute responses are now dropped when no corresponding session can be found by the server. As both UDP and TCP probes are identified by the source port
1021, a port number reserved for experimental use, traffic should not be disrupted (unless of course other software relies on the use of this port number).With the updated probe encoding ICMP probes use the sequence
0xffff. Possible responses that reflect this value are therefore dropped as well.