> Having read through RFC 6520, I don't understand why the payload is necessary. Neither the server nor the client appears to be using it for anything? RFC 652

> Having read through RFC 6520, I don't understand why the payload is necessary. Neither the server nor the client appears to be using it for anything? RFC 6520: "To perform PMTU discovery, HeartbeatRequest messages containing padding can be used as probe packets, as described in [RFC4821]." "In particular, after a number of retransmissions without receiving a corresponding HeartbeatResponse message having the expected payload, the DTLS connection SHOULD be terminated. " "When a HeartbeatRequest message is received and sending a HeartbeatResponse is not prohibited as described elsewhere in this document, the receiver MUST send a corresponding HeartbeatResponse message carrying an exact copy of the payload of the received HeartbeatRequest. If a received HeartbeatResponse message does not contain the expected payload, the message MUST be discarded silently. If it does contain the expected payload, the retransmission timer MUST be stopped." The "use" of the payload is in the RFC. What the RFC omits is the "why" for why the payload exists in the first place. Omission of this "why" is likely because the authors expected that their readers would inherently understand why given that the RFC is for network protocols and meant to be read by those understanding network protocols. The "why" is that networks are subject to packet loss, and to timing delays. If you send out two heartbeats 10s apart, and only receive one reply back, then is the reply responsive to the first heartbeat, or to the second 10s later? Without some unique data in each of the packets you send, which is echoed by the other end, you can not disambiguate this question. Now, one could argue that a simple sequence counter defined by the protocol would suffice. But that is open to exploit by a misbehaving server because once the server recognizes your heartbeat counter pattern, it can issue anticipatory heartbeat replies with the proper sequence number that you will accept as valid. By making the payload arbitrary bytes, then you have the option of sending a sequence number, or generating random data (and tracking it yourself), or both. The random data aspect thwarts misbehaving servers from determining your pattern and replying with the right data without ever receiving your requests. The arbitrary sized payload also makes the packet useful for path MTU discovery as the first paragraph I quoted from the RFC indicates.