Reverse Traceroute

Mon Feb 27 20:29:55 UTC 2023

On 2/27/23 1:13 AM, Rolf Winter wrote:
> But feedback from the operational community on this would be 
> valuable. Our reverse traceroute currently restricts the server to 
> trace back to the issuing client. We did this for security reasons.

I understand the motivation for your team's caution / security posture.

> The question was "why should anybody on the internet be able to do 
> a traceroute from my server to a destination of choice?".

How many times have we been out and about in our daily lives and 
received a text / phone call that prompted us to initiate diagnostic 
between two locations other than where we were at or where our traffic 
appeared to originate from?

> Lifting this restriction would allow a functionality similar to 
> "https://downforeveryoneorjustme.com/". But, somebody might use your 
> server for this. How do people feel about this? Restrict the reverse 
> traceroute operation to be done back to the source or allow it more 
> freely to go anywhere?

I'm already trusting the RIPE team and their security measures for the 
Atlas probe that's in my network.  I'm okay continuing to rely on them 
to monitor and react to this if it becomes a problem.

Perhaps the RIPE team could make a test to an arbitrary destination 
(considerably ~> 10 x) more expensive (in credits) than to the 
destination that you're initiating from.

Just my 2¢.

-- 
Grant. . . .
unix || die

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4017 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20230227/1e6f4c7a/attachment.bin>