Reverse Traceroute

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


Ah, apologies, I misunderstood:

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

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 slabnet.com> 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 hs-augsburg.de>
> 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 "playground.net...." 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
>> >> (https://github.com/HSAnet/reverse-traceroute/blob/main/ENDPOINTS).
>> >> 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 https://ring.nlnog.net/.
>> >
>> > Tore
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20230225/be38d169/attachment.html>


More information about the NANOG mailing list