Abstract

The aim of this bep is to solve two problems with BitTorrent:

1. The barrier of entry to a swarm may be high when most peers (or at least most early peers with most of the data) are all fully connected at all times, never having a connection slot for new incoming connections. Peers are likely to attempt a new outgoing connection immediately when a peer is dropped, to reach the connection limit. This means that the number of connected peers + half-open outgoing connections always reaches the limit, resulting in new incoming connections being refused.
2. There's an opportunity to DDoS a swarm by filling up everyone's connections slots, and continuously making incoming connections at such rate that peers won't have an opportunity to connect to anyone else.

The solution to these problems is to come up with a formula that all peers agree on to prioritize certain IP addresses for peers over others. As long as this formula is correctly defined, and all (or at least most) peers agree on what it is, all peers have equal footing on joining swarms, and a DDoS attack is only as affective as the proportion of attackers to legitimate peers.

Overview

The formula to be used in prioritizing peers is this:

priority = crc32-c(sort(masked_client_ip, masked_peer_ip))

If the IP addresses are the same, the port numbers (16-bit integers) should be used instead:

priority = crc32-c(sort(client_port, peer_port))

For an IPv4 address, the mask to be used should be FF.FF.55.55 unless the IP addresses are in the same /16. In that case, the mask to be used should be FF.FF.FF.55. If the IP addresses are in the same /24, the entire address should be used (mask FF.FF.FF.FF).

For an IPv6 address, the mask should be derived in the same way, beginning with FFFF:FFFF:FFFF:5555:5555:5555:5555:5555. If the IP addresses are in the same /48, the mask to be used should be FFFF:FFFF:FFFF:FF55:5555:5555:5555:5555. If the IP addresses are in the same /56, the mask to be used should be FFFF:FFFF:FFFF:FFFF:5555:5555:5555:5555, etc...

The client should aways derive its own IP part from the IP address that the peer sees it as, so that both the client and peer arrive at the same hash. The client can use an IP address given via BEP 10 [1] as a hint, but should not blindly trust it.

Examples

If the client is 123.213.32.10 and the peer is 98.76.54.32, the hash that they should both arrive at is crc32-c(624C14007BD50000) or ec2d7224.

If the client is 123.213.32.10 and the peer is 123.213.32.234, the hash that they should both arrive at is crc32-c[(7BD5200A7BD520EA) or 99568189.

Notes

A peer's priority can be computed before connecting, so it may be beneficial for clients to take that into consideration when deciding which peers to connect to.

Prioritization should be used within torrents only (not at a global level). This specification is not intended to influence the method by which peer slots are divided up among torrents.

Google provides a CRC32-C reference implementation.

References

Copyright

This document has been placed in the public domain.