On Wed, Dec 17, 2008 at 8:04 PM, Narayanan, Vidya <[email protected]> wrote: > <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. >
I'm sorry, maybe I'm missing something, but my understanding of your argument here is that since a node can always be subjected to a random traffic flood, there's no point in defending against any other DoS attack. But the state space attack is much easier to launch than a raw traffic flood, as it takes only a small UDP datagram to consume each entry for 15 seconds. From some rough calculations, that looks like about 1MB of state per 1Mb of traffic generated through the peer. >> 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. I tried to work through some numbers in my response to Salman, but I think there are some misunderstandings here. The hop-by-hop reassembly requires no timers or limits on the number of messages from a given node. That simplification comes from the prohibition on interleaving fragments from multiple messages. In that sense, it's much cleaner. So right now I'm assuming it doesn't prohibit a windowed protocol because I'm assuming that a windowed protocol would be implemented either as an entirely separate overlay link protocol or by decomposing a larger message into smaller messages that are routed across the existing links protocols. Bruce _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
