Estensione heartbeat: ha senso consentire il carico utile arbitrario?

Question

https://tools.ietf.org/html/rfc6520 non spiega perché un round-trip di richiesta/risposta di heartbeat deve contenere un payload. Specifica solo che c'è spazio per il payload e che la risposta deve contenere lo stesso carico utile della richiesta.

A cosa serve questo payload? Le mie domande sono:

• Quale potrebbe essere che gli ingegneri pensavano quando hanno progettato il protocollo per consentire compreso payload arbitraria nella richiesta di battito cardiaco? Quali sono i vantaggi?

• Quali sono i motivi per cui questo payload deve essere contenuto nella risposta?

Vedo che, consentendo il carico utile arbitrario, l'applicazione è in grado di corrispondere in modo univoco a una determinata risposta con una determinata richiesta. È l'unico vantaggio? Se sì, allora perché non forzare il carico utile di una certa lunghezza? Qual è la flessibilità nella lunghezza del carico utile? Ha a che fare con un concetto crittografico, in modo tale che la durata delle richieste di heartbeat debba essere imprevedibile?

Altre estensioni di protocollo "heartbeat" semplicemente pre-definiscono la richiesta esatta (ad esempio "ping") e la risposta corrispondente (ad esempio "pong"). Perché lo https://tools.ietf.org/html/rfc6520 ha preso una strada diversa?

È importante comprendere il ragionamento alla base delle scelte fatte in RFC6520 al fine di valutare correttamente le ipotesi che tutto ciò potesse essere una backdoor posizionata in modo intelligente.

Answer 1

• Per quanto riguarda la dimensione arbitraria: RFC abtract afferma che l'estensione Hearbeat è una base per il percorso MTU (PMTU) scoperta per DTLS. Variare le dimensioni è una base per implementare tale protocollo (http://en.wikipedia.org/wiki/Path_MTU_Discovery)

• Per quanto riguarda il contenuto arbitrario: la consegna del pacchetto potrebbe non essere conservata o i pacchetti potrebbero andare persi. variando il contenuto aiuta a identificarli