Heartbeat extension: does it make sense to allow for arbitrary payload?

Question

https://www.rfc-editor.org/rfc/rfc6520 does not explain why a heartbeat request/response round-trip is supposed to contain a payload. It just specifies that there is room for payload and that the response has to contain the same payload as the request.

What is this payload good for? My questions are:

• What could it be that the engineers thought when they designed the protocol to allow for including arbitrary payload into the heartbeat request? What are the advantages?

• What are the reasons that this payload must be contained in the response?

I see that by allowing for arbitrary payload the application is able to unambiguously match a certain response with a certain request. Is that the only advantage? If yes, then why did one not force the payload to be of a certain length? What is the flexibility in the payload length good for? Does it have to do with a cryptographic concept, such that the length of heartbeat requests must be unpredictable?

Other "heartbeat"-like protocol extensions simply pre-define the exact request (e.g. "ping") and the corresponding response (e.g. "pong"). Why did https://www.rfc-editor.org/rfc/rfc6520 take a different route?

It is important to understand the reasoning behind the choices made in RFC6520 in order to properly assess hypotheses that all this might have been an intelligently placed backdoor.

Answer 1

• Regarding the arbitrary size: the rfc abtract states that the Hearbeat extension is a basis for path MTU (PMTU) discovery for DTLS. Varying the size is a basis to implement that protocol (http://en.wikipedia.org/wiki/Path_MTU_Discovery)

• Regarding the arbitrary content: packet delivery may not be preserved or packets may be lost. varying the content helps to identify them