> >
> > 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.
> 

Sorry, perhaps what I wrote wasn't clear.  The buffer exhaustion attack is 
accomplished in several ways, including when a large amount of traffic is sent 
to a node.  Plus, please see my earlier email on the math - I think that the 
attack is actually easier when intermediate nodes are reassembling fragments. 

> 
> 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.  

That is a big cost to pay in terms of latency.  After some real data from 
experience, IPv6 corrected the shortcoming of IPv4 in the fragmentation case - 
overlay routing is not all that different from IP routing in terms of the 
architecture and function (differences in magnitude and capabilities of the 
devices may even out).  So, both in terms of the threat model and tradeoffs 
like these in fragmentation, we should be learning from the same lessons.  Of 
course, even going with the math points to the same thing to me. 

Vidya 
_______________________________________________
P2PSIP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/p2psip

Reply via email to