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.
I mentioned the solution in an earlier post:
http://www.ietf.org/mail-archive/web/p2psip/current/msg04541.html
For return path state, one solution is to limit the inprogress
messages from a certain peer to a configured number. If the peer still
sends more messages, it can be informed to do ROUTE-QUERY, thereby
preventing further consumption of memory on the intermediary nodes.
-s
_______________________________________________
P2PSIP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/p2psip
