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

Nikos Mavrogiannopoulos <nmav@gnutls.org> Wed, 23 March 2011 10:52 UTC

Return-Path: <n.mavrogiannopoulos@gmail.com>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D950A3A6806; Wed, 23 Mar 2011 03:52:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.977
X-Spam-Level:
X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UZQ0r8sX8idm; Wed, 23 Mar 2011 03:52:21 -0700 (PDT)
Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id B97583A6800; Wed, 23 Mar 2011 03:52:21 -0700 (PDT)
Received: by iyi12 with SMTP id 12so9864775iyi.31 for <multiple recipients>; Wed, 23 Mar 2011 03:53:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=hxLfnsoSUeqlydcF4i+I3HV09TOYa1FBsMRS51pJ5YM=; b=SEK8oxWThoxdBNyUw5boIXTVE6sYNXoO4fPBe9+3cQunv0gbmV0nrgJe4tVBXgP/1W tMl7/qA7ujV0WZLMMwrUrvjN2YyX98NlQ7AhvSB3CuJdXHZhn+pGTHO45DY1MLVSq4B9 Nr9dZYLGm0DK/ryZD/x/d8xUgxJ7/jjpxn7jQ=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=Rfb2iLVmSS+nnBfvthfuRDj4rKSCnRfLoSIzErctj1mTW0Ijz66NL8FzhcEGER+wkp cXLbiB2qB0XeYEPb+B6Br/1BM8AhkgVHfVe49nCBiJ53g7Gr+ERojqal5M9+pvidqnE7 ARUZGsnSJTwcqsKwEG0qKlGGtwEnZW+fiU+aw=
MIME-Version: 1.0
Received: by 10.42.247.200 with SMTP id md8mr1024174icb.111.1300877635437; Wed, 23 Mar 2011 03:53:55 -0700 (PDT)
Sender: n.mavrogiannopoulos@gmail.com
Received: by 10.231.42.202 with HTTP; Wed, 23 Mar 2011 03:53:55 -0700 (PDT)
In-Reply-To: <90CF1CC0-75A0-42FC-ADCA-57A25FD5DAC4@iki.fi>
References: <90CF1CC0-75A0-42FC-ADCA-57A25FD5DAC4@iki.fi>
Date: Wed, 23 Mar 2011 11:53:55 +0100
X-Google-Sender-Auth: CAGLGRBIcGWuBWgPfletsCR4fL0
Message-ID: <AANLkTi=BXQLgE123GnsVWAeDyApB1t4cxHPStGV3p2xg@mail.gmail.com>
From: Nikos Mavrogiannopoulos <nmav@gnutls.org>
To: Pasi Sarolahti <pasi.sarolahti@iki.fi>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: draft-ietf-tls-dtls-heartbeat@tools.ietf.org, tls@ietf.org, tsv-dir@ietf.org
Subject: Re: [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: Wed, 23 Mar 2011 10:52:23 -0000

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
>