You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
At the moment, an attacker could join the Network with an evil Node that accepted data to route or exit and just threw away some or all of it.
Suggested mitigation:
Establish a Time-To-Live for unrequited requests in the ProxyServer. (There may be one already, to facilitate reaping orphaned requests so that they don't clog up the HashMap.)
When an unrequited request times out, increment the (new for this card) may_have_lost_data count by one in the metadata for every Node in that request's Over and Back route segments: but if a Node appears in both segments, increment it only once.
If it's not already being done, replace the timed-out route by a newly-generated one from the Neighborhood.
When a request is satisfied by a response, set the may_have_lost_data count to zero in the metadata of every Node in that transaction's Over and Back route segments.
Modify the Routing Engine so that a Node's undesirability is augmented by the product of its may_have_lost_data value and some appropriate constant.
(Optional; we should discuss this) If, when it comes time to increment a Node's may_have_lost_data count, it exceeds some reasonable limit, malefactor-ban the Node before regenerating the route.
Note: this capability might one day be extended to also handle latency detection, so that we can identify perfectly honorable Nodes which have nonetheless been cursed with high latency and raise their undesirability. Try to avoid designs that preemptively prohibit this future enhancement.
The text was updated successfully, but these errors were encountered:
At the moment, an attacker could join the Network with an evil Node that accepted data to route or exit and just threw away some or all of it.
Suggested mitigation:
may_have_lost_data
count by one in the metadata for every Node in that request's Over and Back route segments: but if a Node appears in both segments, increment it only once.may_have_lost_data
count to zero in the metadata of every Node in that transaction's Over and Back route segments.may_have_lost_data
value and some appropriate constant.may_have_lost_data
count, it exceeds some reasonable limit, malefactor-ban the Node before regenerating the route.Note: this capability might one day be extended to also handle latency detection, so that we can identify perfectly honorable Nodes which have nonetheless been cursed with high latency and raise their undesirability. Try to avoid designs that preemptively prohibit this future enhancement.
The text was updated successfully, but these errors were encountered: