Hi Rolf, thanks for your explanation. I'd think that there are more details to cover.
* Traffic volume and packet rate affect different systems differently. A system may be able to handle a fixed amount of traffic volume with packet rate R, but not with a packet rate of, e.g., 1.5*R. Thus packet rate amplification should be considered in addition to traffic volume amplification. * Should reverse traceroute become successful and widely deployed, there would be not just one such server available for abuse by an attacker, but many. Thus a single attacker could make use of many servers to attack a single victim. In that case, the receiver of the probe packets, i.e., the intended victim of the attacker, is the real victim. There is another security consideration with reverse traceroute, I'd say. Since as described currently it is quite flexible, it allows an attacker to easily vary the reflected and amplified attack traffic. This would make it harder to filter out attack traffic. Br, Erik On Sat, Aug 31, 2024 at 04:19:26PM +0200, Rolf Winter wrote: > 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=3058 > > But 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 _______________________________________________ Int-area mailing list -- [email protected] To unsubscribe send an email to [email protected]
