Reverse Traceroute

Hugo Slabbert hugo at
Sat Feb 25 20:00:17 UTC 2023

Ah, apologies, I misunderstood:

One reverse traceroute request => one probe + one reverse traceroute

So it is *slightly* additive, but does not multiply out to the distance
between the reverse traceroute server and the target.

On Sat, Feb 25, 2023, 11:19 Hugo Slabbert <hugo at> wrote:

> Is there a possible reflection & amplification vector here?
> * The client sends a reverse traceroute request to the server. This has a
> 12-byte ICMP header as indicated in 3.1
> * The server responds to the client with a traceroute response. This has a
> 12-byte ICMP header as indicated in 3.2, but also a traceroute payload of
> 24 bytes as indicated in 3.3
> So the total response from client to server has at least +24 bytes beyond
> the original client request? And a spoofed source address on a reverse
> traceroute request would then direct the reverse traceroute response to the
> spoofed victim?
> +24 bytes is not a huge amount in terms of amplification, but if this is
> accurate, is that perhaps worth calling out in the security considerations?
> Actually: Would there not also be a slight additional bit of traffic to
> the spoofed address, in that the actual traceroute probe itself, that is
> sent from the reverse traceroute server, is also directed towards the
> spoofed source IP address? The last probe in the series, that has a TTL
> equal to the distance between the reverse traceroute server and the probe
> target, would reach the target, but additional probes (with TTL shorter
> than the distance from server to target) would still be flung from the
> server across intermediate hops.
> E.g. if I spoof a client address that is 15 hops away from the reverse
> traceroute server, then my single reverse traceroute request would result
> in:
> * 15 probes initiated from the reverse traceroute server toward the
> spoofed target (with each probe progressing one hop closer to the target)
> * one reverse traceroute response that is +24 bytes from my original
> request, also directed toward the spoofed target
> Am I understanding the structure correctly there?
> --
> Hugo Slabbert
> On Sat, Feb 25, 2023 at 5:40 AM Rolf Winter <rolf.winter at>
> wrote:
>> Hi Tore,
>> thanks for the suggestion. We are already in touch with the NLNOG Ring
>> folks. They are really helpful! But, the more the better.
>> Also, for people playing with the client, it would be helpful to us if
>> you use the --transmit command line switch. This will send information
>> about the traceroute operation to us for further analysis.
>> Additionally, the endpoint "" is currently used for
>> some variations of reverse traceroute, so some measurements might not
>> work currently. You can just use any of the other endpoints.
>> Best,
>> Rolf
>> Am 25.02.23 um 11:09 schrieb Tore Anderson:
>> > * Rolf Winter
>> >
>> >
>> >> If you would like to play with reverse traceroute, the easiest option
>> >> is to work with the client and use one of the public server instances
>> >> (
>> >> If you would be willing to host a public server instance yourself,
>> >> please reach out to us.
>> >
>> > I suggest you get in touch with the fine folks at NLNOG RING and ask it
>> > they would be interested in setting this up on the 600+ RING nodes all
>> > over the world. See
>> >
>> > Tore
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the NANOG mailing list