Hi Erik, thanks for the feedback.
There is already some text (and a proposed solution in the draft). Here is the text from the security consideration section:
"Both client and server endpoints SHOULD support and make use of the Padding extension object (Section 5) to further reduce the potential of amplification attacks. The server endpoint SHOULD require enough padding so that the total size of the packets triggered by a request does not exceed the size of the request itself."
You are probably right, that we could write a little more and we do plan to add more text to the actual padding section of the document. During the last meeting I talked a little bit about padding and amplification:
https://youtu.be/OGE5onPY7NM?t=3058But there are certainly some details, which we will add, probably with the next version of the document.
The real potential victim here however is not the receiver of the actual probe packet, but the server sending the probes. In your scenario, the attacker still needs to send one packet to make the victim send one back. The server needs to do a little more work though, which is why the server SHOULD require the requestor to add sufficient padding to not have any amplification in traffic volume.
Hope that made sense. Best, Rolf Am 30.08.24 um 16:59 schrieb Erik Auerswald:
Hi Rolf, I think that it might be useful to also mention the possibility for packet amplification in the security considerations section. I am referring to the basic reflection / amplification scenario in which the attacker sends one packet to the server and the server sends two packets to the victim: 1. Attacker sends a reverse traceroute request with a spoofed source address, the address of the victim, with an Exp value sufficiently high that the probe from the server can reach the victim. 2. The reverse traceroute server sends a probe to the victim. 3. The victim responds to the probe from the server. 4. The reverse traceroute server sends a traceroute response to the victim. Br, Erik On Wed, Aug 28, 2024 at 05:18:49PM +0200, Rolf Winter wrote:Dear Int-Area WG, we just updated the Stateless Reverse Traceroute document. https://datatracker.ietf.org/doc/html/draft-heiwin-intarea-reverse-traceroute-stateless-03 The changes are: - changed "TTL" to "TTL/Hop Limit" throughout the text, as was requested. We also changed the name of the "TTL" field in the request to "EXP" (for expiry) to use an IP version-independent term - updated the requirements language section to the newest version of that text - a bunch of other nits that were suggested were fixed - added a reference to a paper that has contains some measurement results Next steps: - Clarify some of the text - Add a little text around padding We still believe this work is ready for WG adoption, if the WG thinks this is something we should work on. Best, Rolf
smime.p7s
Description: Kryptografische S/MIME-Signatur
_______________________________________________ Int-area mailing list -- [email protected] To unsubscribe send an email to [email protected]
