<snip> > > Remember that requiring peers to not interleave messages severely > restricts the amount of buffer space required (to essentially max > message size + max out of order (10 is very reasonable) * MTU per > connection. Obviously there can be an attack on network resources, > but it's true that you can DoS any node in the Internet by flooding it > with random data. That's not a protocol-specific attack. >
Exactly. And, given that this is possible, it does not make sense to provide point solutions to mitigate DoS attacks. If there are multiple ways of launching an attack, mitigating it in one place achieves nothing. > FWIW, storing forwarding state vs appending to the via list is a > long-standing option in the protocol. The only thing that is new is > whether to do hop-by-hop reassembly. > > I'd be interested in seeing a proposal for a DoS mitigation technique > on this type of attack that has nearly the effectiveness or simplicity > of hop-by-hop reassembly. For that matter, I'd be interested in a DoS > mitigation approach for storing return path state that is simpler than > using reassembly as a fall-back strategy. > But, the hop-by-hop reassembly does not quite mitigate the attack. Timers and any limits on number of messages from a given node are required in both cases. The buffer size for keeping forwarding state will be lower than that required for fragments and the timers for the former will be longer than the latter. However, as a function of memory, they amount to more or less the same thing. The per hop reassembly unnecessarily removes the ability to have a windowed protocol. I can't see how it is useful. Vidya _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
