UDP and port randomisation

Question

I'm currently programming a UDP application which allows clients to login. After that, their endpoint gets stored in a list.

private void socket_Callback(IAsyncResult result_)
{
    EndPoint remote = new IPEndPoint(IPAddress.Any, 0);
    socket.EndReceiveFrom(result_, ref remote);

    if (!listOfEndPoints.Contains(remote))
    {
        // registration process

        // add it to list
        listOfEndPoints.Add(remote)
    }
    else
    {
        // process packet
    }
}

However, sometimes a client's NAT will assign every packet a different external end point. If the registration packet's source end point is 12.34.56.78:1000, that end point gets added to the list. If the same client then however sends another packet, the NAT will assign it a different port, so its source end point will be 12.34.56.78:1001. This results in the server assuming the client is not registered and try to process the packet as a registration one. Needless to say this won't work.

A way of fixing this would be to send an ID (which could however be faked easily, if it's not super-cryptic) to the client. However, the client would have to add it to each packet it sends to the server. So it wouldn't be very effective to do it like that.

Is there any other way of telling that the packet has come from the same client as the registration packet?

Answer 1

You should definitely not use the source IP address and port of a UDP packet to associate it with a logical connection. You should include the ID of the connection in each packet and update the IP and port you respond to if you receive a new IP and port for the same logical connection. If connection hi-jacking is an issue, you may need to implement some form of security, such as a secure checksum in the datagram.

TCP handles associating packets with connections for you. With UDP, you must associate datagrams with logical sessions yourself. I don't know why you think it "wouldn't be very effective to do it like that".

One of the tradeoffs of UDP is that if you need anything TCP provides, you have to code it yourself.

By the way, I've never seen ports shift in this way. Are you sure the client code isn't broken, perhaps opening a new socket for each datagram it sends.