Old-duplicate data packets in TFTP protocol

Question

I found this question in Book called An Introduction to Computer Networks by Peter L Dordal, and I met with this question which I found it a little bit tricky:

In the TFTP protocol:

If the client changes its port number on a subsequent connection, but the server does not, what prevents an old-duplicate data packet sent by the server from being accepted by the new client?

If the server changes its port number on a subsequent connection, but the client does not, what prevents an old-duplicate data packet sent by the server from being accepted by the new client?

http://intronetworks.cs.luc.edu/current/html/udp.html?highlight=cumulative#old-duplicate

Answer 1

After reading the Chapter, I arrived at some conclusions:

In the TFTP protocol: If the client changes its port number on a subsequent connection, but the server does not, what prevents an old-duplicate data packet sent by the server from being accepted by the new client?

In this scenario, an old duplicate packet arriving at the client would be received on a port no longer in use. The client, seeing that the port associated with the packet is different from the one currently in use, would discard the packet and, according to TFTP specifications, the client would have to send the server an ERROR packet containing the message "Unknown Transfer ID" (Dordal, 2019, p. 343).

If the server changes its port number on a subsequent connection, but the client does not, what prevents an old-duplicate data packet sent by the server from being accepted by the new client?

This scenario is slightly more complex than the previous one since the client, seeing a packet delivered to the port currently in use, may decide to accept it. For this reason, there are two protections. The first is to number the packets so that if the client has already received a packet with the same numbering, it decides to discard the second one that has arrived. This also ensures that the client can verify the order of arrival.

Another protection mechanism is to implement a connection count that must be maintained by both sides (server and client) and sent in the application layer header or transport layer header (Dordal, 2019, 340) so that if a packet belonging to an old connection arrives at the client at the port currently in use, it will indeed have a different connection count and thus can be detected and discarded.

References

Dordal, P. (2019). An introduction to computer networks.

Answer 2

The two questions have a similar response. The reason is that, in the first question, the returning duplicate packets were using the old client port number which has changed. Therefore the packets could not be delivered to the client.

On the other hand, where the client is still using the old port number, data will not be sent if a different protocol is used or the client moved to use a different IP address.

I hope this clears your doubts a little.

Answer 3

TFTP shouldn't be used when the connection is not near-perfect (=local, few hops). UDP isn't reliable by itself and TFTP doesn't do enough to improve on that very much.

However, the example is somewhat hypothetical. Both client and server are likely to use ephemeral ports chosen by the OS. The time window for the duplicate packet to match is very small - the queue flush time of a router in between - and the ephemeral port numbers would need to wrap around on both sides simultaneously.

That said, TFTP should only be used on short connections where security doesn't matter - if at all. There are more modern alternatives for reliable and secure file transfer.