Re: Reverse Traceroute

[Hugo Slabbert <hugo () slabnet com>]

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 () 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 () 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