[SOLVED] Heartbleed: Payloads and padding

Heartbleed: Payloads and padding

I am left with a few questions after reading the RFC 6520 for Heartbeat:

Specifically, I don't understand why a heartbeat needs to include arbitrary payloads or even padding for that matter. From what I can understand, the purpose of the heartbeat is to verify that the other party is still paying attention at the other end of the line.

What does these variable length custom payloads provide that a fixed request and response do not?

E.g.

Alice: still alive?
Bob: still alive!

After all, FTP uses the NOOP command to keep connections alive, which seem to work fine.

Solution

There is, in fact, a reason for this payload/padding within RFC 6520

From the document:

The user can use the new HeartbeatRequest message, which has to be answered by the peer with a HeartbeartResponse immediately. 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.

Credit to pwg at HackerNews. There is a good and relevant discussion there as well.