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

Pasi Sarolahti <pasi.sarolahti@iki.fi> Tue, 22 March 2011 08:59 UTC

Return-Path: <pasi.sarolahti@iki.fi>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id 4E8DE3A67EA; Tue, 22 Mar 2011 01:59:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.599
X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id iKEeDJcl39MR; Tue, 22 Mar 2011 01:59:53 -0700 (PDT)
Received: from smtp.netlab.hut.fi (luuri.netlab.hut.fi []) by core3.amsl.com (Postfix) with ESMTP id A93393A67E7; Tue, 22 Mar 2011 01:59:52 -0700 (PDT)
Received: from localhost (localhost.localdomain []) by smtp.netlab.hut.fi (Postfix) with ESMTP id C10F81E1C6; Tue, 22 Mar 2011 11:01:24 +0200 (EET)
X-Virus-Scanned: by amavisd-new at luuri.netlab.hut.fi
Received: from smtp.netlab.hut.fi ([]) by localhost (luuri.netlab.hut.fi []) (amavisd-new, port 10024) with LMTP id 7DITdFZEkAoa; Tue, 22 Mar 2011 11:01:20 +0200 (EET)
Received: from [] (cs181059059.pp.htv.fi []) by smtp.netlab.hut.fi (Postfix) with ESMTPSA id B3BE81E139; Tue, 22 Mar 2011 11:01:20 +0200 (EET)
From: Pasi Sarolahti <pasi.sarolahti@iki.fi>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 22 Mar 2011 11:01:19 +0200
Message-Id: <90CF1CC0-75A0-42FC-ADCA-57A25FD5DAC4@iki.fi>
To: tls@ietf.org, tsv-ads@tools.ietf.org
Mime-Version: 1.0 (Apple Message framework v1082)
X-Mailer: Apple Mail (2.1082)
X-Mailman-Approved-At: Tue, 22 Mar 2011 07:46:45 -0700
Cc: draft-ietf-tls-dtls-heartbeat@tools.ietf.org, tsv-dir@ietf.org
Subject: [TLS] tsv-dir review of draft-ietf-tls-dtls-heartbeat-01
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 22 Mar 2011 08:59:54 -0000


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