get_connection_id() is unsuitable/ peer cache poisoning

[the-real-tokai]

In BEP15 the idea of the separate "connect request" packet and subsequent use of a connection ID is to protect against spoofing of the UDP packet's source address. For this to work the connection ID must not be easy to guess by the client.

The current implementation of get_connection_id() is entirely unsuitable for that purpose. A bad actor simply could create their own "connection ID", entirely skip the connect request, and simply start sending announce requests from random IPs. E.g. for the purpose to poison the peer cache of the tracker with tons of fake entries, and other kind of schabernack.

Solution:

the connection ID should be some sort of (simple) cryptographic hash over some data (time factor, source IP, source port, server ip/ port, and a random(*) server internal secret), e.g. SipHash could be used (Linux kernel uses that for TCP SYN cookies), but even something simple like FNV-1a would be an improvement already.

*) with "random" I mean a static secret that's generated once, e.g. when the server launches, but is not hard coded into the code.

Extra Notes:

Additionally the designed timeout/ precision (1h) is too high: according to BEP15 the connection ID only should be valid for 1 to ~2m (personally I also think that's a bit too short, but there's probably a smart reason for that).