Reverse Traceroute

Wed Mar 1 08:19:09 UTC 2023

Am 28.02.23 um 20:05 schrieb Hugo Slabbert:
>  > It is not so bad. But you are still raising a valid point and we have 
> been pondering over this and indeed this is one of the reasons why we 
> have posted our work here.
>  >
>  > I think, if you want to mount an amplification attack, you would be way
> better off using DNS :)
> 
> Agreed; it's a very low level of amplification, and there are lower 
> hanging fruit. I do think it's worthwhile to still indicate, though, in 
> a similar vein overall in the security considerations re: rate limiting 
> server side.
> 

We have that, plus a few other things in the security consideration 
section. But we probably should quantify the level of amplification, too.

>  > We could easily specify payload to be added to the request so that 
> the request and the respective response and probe as equivalent in size.
> 
> I'm still a fan of the notion that, for a connectionless protocol, the 
> response size should not exceed the request size, to eliminate that risk 
> entirely. I think that does become a bit much in this case, though, if 
> we have to factor in the spoofing scenario, as you have:
> 
> 1. client: traceroute request -> server
> 2. server: probe -> client
> 3. client: probe response -> server (may be missing)
> 4. server: traceroute response -> client
> 
> The client gets both the traceroute response (4) as well as the 
> traceroute probe (2). If padding were to be required in the traceroute 
> request, it would need to account for *both* the +24 bytes delta between 
> the traceroute request and response probes, as well as for the actual 
> probe size, including its L3 headers. imho that starts to balloon the 
> traceroute request a good bit, and also feels clunky that we're now 
> coupling things such that the traceroute request also needs to calculate 
> or be aware of the size of the actual probe in order to craft its 
> traceroute request.

Yes, that is the dilemma. To make things a bit more complicated, RFC 792 
(the original ICMP RFC) specifies, that the Time Exceeded Message 
contains the original IP header plus next 64 bits following it. On 
today's internet, there actually might be a few more bits. One could 
make a conservative estimate and use that.

I also got off-list feedback that basicaclly said, if you don't add this 
now, and people find a way to exploit it later, operators will block it 
and once it is blocked, it won't be unblocked again".

> 
>  > Also, I think it would be worth while discussing over at the IETF.
> 
> Sure thing. Should I try to piggyback on an existing thread in Int-area 
> or start a new thread there?

Please start a new thread. Thanks!

Rolf

> 
> -- 
> Hugo Slabbert
> 
> 
> On Sun, Feb 26, 2023 at 1:39 AM Rolf Winter <rolf.winter at hs-augsburg.de 
> <mailto:rolf.winter at hs-augsburg.de>> wrote:
> 
>     Hi Hugo,
> 
>     correct. It is not so bad. But you are still raising a valid point and
>     we have been pondering over this and indeed this is one of the reasons
>     why we have posted our work here.
> 
>     I think, if you want to mount an amplification attack, you would be way
>     better off using DNS :) A response and probe, as you said, is a little
>     more than a request in terms of bytes on the wire. We could easily
>     specify payload to be added to the request so that the request and the
>     respective response and probe as equivalent in size. Would you, or
>     anybody on this list be worried about amplification given that it
>     only a
>     little bit more? This would be really interesting input to us. Also, I
>     think it would be worth while discussing over at the IETF.
> 
>     Just as some additional information, we expect people to rate limit
>     reverse traceroute, which our implementation already allows.
> 
>     Best,
> 
>     Rolf
> 
> 
> 
>     Am 25.02.23 um 21:00 schrieb Hugo Slabbert:
>      > 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
>     <mailto:hugo at slabnet.com>
>      > <mailto:hugo at slabnet.com <mailto: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
>     <mailto:rolf.winter at hs-augsburg.de>
>     <mailto:rolf.winter at hs-augsburg.de
>     <mailto: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
>     <https://github.com/HSAnet/reverse-traceroute/blob/main/ENDPOINTS>
>     <https://github.com/HSAnet/reverse-traceroute/blob/main/ENDPOINTS
>     <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/
>     <https://ring.nlnog.net/>
>      >         <https://ring.nlnog.net/ <https://ring.nlnog.net/>>.
>      >          >
>      >          > Tore
>      >
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4757 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20230301/a01f17f8/attachment.bin>