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

My main comment on this draft is that there is not enough rationale
for the added functionality to DTLS. In the introduction it is mentioned:
 "The only mechanism available at the DTLS layer to figure
   out if a peer is still alive is performing a costly renegotiation.
   If the application uses unidirectional traffic there is no other way."
However transports like UDP that DTLS lies on, have the same
issue. There is no way to check out if peer is alive. Why should
DTLS solve that issue, that is typically solved at the application
level? [0]

regards,
Nikos

[0].  I saw arguments that it is essencial to protocols like IPFIX,
such as draft-mentz-ipfix-dtls-recommendations-02, but IMO they are
not really convincing that DTLS is the layer to solve those issues.

On Tue, Mar 22, 2011 at 10:01 AM, Pasi Sarolahti <pasi.sarolahti@iki.fi> 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 tsv-dir@ietf.org 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.
>
>
> 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])
>
> 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?
>
> 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)
>
> 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"
>
> 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.)
>
> - Pasi
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>