UDP best practices

[choksi81]

The usual way of receiving UDP traffic on Seattle involves registering a callback (V1) or polling a listening socket for incoming messages (V2). This works fine for remote-initiated traffic (Seattle is the server) when connections from any IP address should be served.

However, there is a subtle issue with implementing a UDP client that receives a response to a query it sent: If you just send the UDP message, then register the callback/poll the socket, it is not guaranteed that the answer you will receive comes from the host you sent the message to! All an attacker needed to do was to flood the known Seattle ports with UDP messages to falsely trigger your callback.

The correct way to implement a UDP client in Seattle thus involves checking inside the callback (V1), or in the (ip, port, message) tuple returned from udpserversocket.getmessage() from an established UDP server socket in V2, whether the received message comes from the host and port that was contacted initially.

(Also, note a possible race: sending-then-registering could result in the callback not being set up before the message arrives. On the other side, registering-then-sending could trigger the callback prematurely because of attack/unsolicited traffic.)

We should (a) come up with correct, comprehensible code examples (e.g. using closures, global variables, etc.), and (b) check whether our platform code needs to be refurbished. I think #1261 shows how unsolicited incoming messages could really harm the system.