BEP 5 DHT token about bittorrent.org HOT 5 CLOSED

You will find that most BEPs are specified in a fairly lax manner and do not spell out all the possible sanity-checking / quality of implementation things (see my doc on DHT sanitizing) that one should do in reality. Neither do they spell out algorithmic approaches commonly used for certain problems (e.g. see #22).

I think the assumption is that the reader is a systems engineer familiar with the pitfalls of writing network protocols.

For this particular issue my implementation is using the following to derive a token:

hash(secret, timestamp, remote_socket, remote_id, target_id)

But this particular approach is not necessary. If the implementation has some sort of bounded storage policy, e.g. only allowing one value per source IP address to be stored, then such flooding attacks will also be ineffective, But the storage policy is implementation-defined and only tangentially related to the token (other BEPs allow you to omit the token when storage is exhausted).

What i'm trying to say is that your concern is valid, but I don't think the BEP should mandate solutions, just mention the issue.

And this is just one among many. Listing them all would probably require a separate document, or at least a long list of terse bullet points.

from bittorrent.org.

Oh, and at least for put/get queries BEP44 allows a stricter policy.

http://bittorrent.org/beps/bep_0044.html#messages

from bittorrent.org.

Neither do they spell out algorithmic approaches commonly used for certain problems

Then why mention the BitTorrent implementation then ?

The main problem here is that the BEP 05 says:

For a node to announce that its controlling peer is downloading a torrent, it must present the token received from the same queried node in a recent query for peers

[ ... ]

The queried node must verify that the token was previously sent to the same IP address as the querying node

So one can assume that the returned token can be stored and reused for announcing with a different hash_id, which will not be possible with an implementation that also tight the token to the hash_id.

While I understand that BEP purpose is not to mandate some specific implementation, it should prevent such incompatibilities.

from bittorrent.org.

In practice this is unlikely to be a problem because you won't end up announcing two distinct infohashes to the same node.

from bittorrent.org.

Mixing the infohash into the token alone would not prevent flooding. It would only make it slightly more expensive by requiring a separate get_peers for each announce_peer. The storage policy is where protection against flooding is done. As @the8472 points out, that is an implementation detail which would not be appropriate to specify in BEP 5.

It would be nice if we had more informational BEPs to document best practices for things like this, but the people qualified to write them are few and their time is limited.

from bittorrent.org.