gtaylor at tnetconsulting.net
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...
Size: 4017 bytes
Desc: S/MIME Cryptographic Signature
More information about the NANOG