Re: [TLS] tsv-dir review of draft-ietf-tls-dtls-heartbeat-01

[Michael Tüxen <[e-mail]>]

Hi Pasi,

thank you very much for the review. Please see
my comments in-line.

Best regards
Michael

On Mar 22, 2011, at 10:01 AM, Pasi Sarolahti wrote:

> Hi,
> 
> I've reviewed this document as part of the transport area directorate's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors for their information and to allow them to address any issues raised. Please always CC [e-mail] if you reply to or forward this review.
> 
> 
> Path MTU discovery:
> 
> There should be more about how PMTUD is done than the one sentence in the Intro, probably somewhere near section 4 (about when to send the padded packets, how to set the DF bit in HeartbeatRequest packets with padding, probably also mentioning about handling the possibly resulting ICMP, etc.). You could also refer to the appropriate section in the main DTLS spec.
I don't think this spec should specify how PMTU discovery should
be performed, since this is described in RFC 4821 in detail. The
HB mechanism just provides the probe packets.

However, this should be described in a better place than just the introduction.
So I have added a section "5 Use cases" which contains a subsection "5.1 PMTU Discovery"
and "5.2 Liveliness check":
<section title="Use Cases">

<section title="Path MTU Discovery">
<t>DTLS performs path MTU discovery as described in Section 4.1.1.1
of <xref target='RFC4347'/>. A detailed description how to perform
path MTU discovery is given in <xref target='RFC4821'/>.
The necessary probe packets are the HeartbeatRequest messages.</t>
<t>This method using HeartbeatRequest messages for DTLS is similar
to the one for the Stream Control Transmission Protocol (SCTP)
using the padding chunk (PAD-chunk) defined in <xref target="RFC4820"/>.</t>
</section>

<section title="Liveliness check">
<t>Sending HeartbeatRequest messages allows the sender to
make sure that it can reach the peer and the peer is alive.
Even in case of TLS/TCP this allows this check at a much
higher rate than the TCP keepalive feature would allow.</t>
<t>Besides making sure that the peer is still reachable,
sending HeartbeatRequest messages refreshes the NAT state
of all involved NATs.</t>
<t>HeartbeatRequest messages SHOULD only be sent after an idle
period that is at least multiple round trip times long.</t>
</section>

> 
> 
> Reliability & congestion control:
> 
> Using DTLS' simple timeout scheme seems ok here (but it would be additional help for the reader to give exact reference, e.g., [RFC 4347, Section 4.2.4])
The reference has been added.
> 
> With TLS there shouldn't be any congestion control issues, but you might want to discuss the relationship of this mechanism and TCP's keepalive messages. Is TCP's mechanism sufficient, and if not, why not?
I added text for this in section 5.2.
> 
> If DTLS is used over a congestion controlled transport protocol, there shouldn't be any issues for congestion control.
> 
> Also DTLS/UDP seems ok from congestion control viewpoint, because the document allows at most one HeartbeatRequest message to be in flight at a (round-trip) time, and for unacknowledged Heartbeats it mandates the use of the timeout algorithm that applies exponential backoff. (You might want to use an extra sentence mentioning that for these reasons the scheme handles congestion control appropriately)
OK. I added:
<t>The retransmission scheme in combination with the restriction
that only one HeartbeatRequest is allowed to be in flight ensures
that the congestion control is handled appropriately in case of the
transport protocol not providing one, like in the case of DTLS over UDP.</t>

> 
> For clarity, the document could say a bit more about when the HeartbeatRequest is in flight, for example:
>   "There MUST NOT be more than one HeartbeatRequest message in flight at
>   a time."
>   ==>
>   "There MUST NOT be more than one HeartbeatRequest message in flight at
>   a time. HeartbeatRequest message is considered to be in flight until
>   HeartbeatResponse is received, or until the retransmit timer expires"
Added. Thanks.
> 
> I think an additional guideline about how often to send keepalive packets would be useful. The intent hardly is to send a heartbeat every round-trip time, even if that is given as the upper bound, right? Perhaps something like:
> 
> * SHOULD only be sent after an idle period (that is at least multiple RTTs long), AND
> 
> * MUST NOT be sent if there are pending unacknowledged data in flight. (If the HeartbeatRequest is the only message type expected to generate response, this would just restate what was already said above. But if there are also other packets waiting to be replied, then this might be useful clarification.)
Added to the text in section 5.2
> 
> - Pasi
> 
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>