Re: [TLS] I-D Action:draft-ietf-tls-dtls-heartbeat-01.txt

"t.petch" <ietfc@btconnect.com> Tue, 01 February 2011 10:46 UTC

Return-Path: <ietfc@btconnect.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 25B2A3A6C04 for <tls@core3.amsl.com>; Tue, 1 Feb 2011 02:46:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.228
X-Spam-Level:
X-Spam-Status: No, score=-2.228 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
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 C0hcwC2NVelr for <tls@core3.amsl.com>; Tue, 1 Feb 2011 02:46:50 -0800 (PST)
Received: from mail.btconnect.com (c2beaomr06.btconnect.com [213.123.26.184]) by core3.amsl.com (Postfix) with ESMTP id BBB6F3A6C19 for <tls@ietf.org>; Tue, 1 Feb 2011 02:46:49 -0800 (PST)
Received: from host217-44-202-151.range217-44.btcentralplus.com (HELO pc6) ([217.44.202.151]) by c2beaomr06.btconnect.com with SMTP id BUG32985; Tue, 01 Feb 2011 10:50:00 +0000 (GMT)
Message-ID: <00cf01cbc1f4$dc962700$4001a8c0@gateway.2wire.net>
From: "t.petch" <ietfc@btconnect.com>
To: =?iso-8859-1?Q?Michael_T=FCxen?= <Michael.Tuexen@lurchi.franken.de>, "Florian Weimer" <fweimer@bfk.de>
References: <20110127114502.24680.73782.idtracker@localhost><8239oeqz6c.fsf@mid.bfk.de> <4848B682-273F-4B52-B9E2-ACBFDFDAAB7F@lurchi.franken.de>
Date: Tue, 1 Feb 2011 10:23:25 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=tid=0001.0A0B0301.4D47E558.0062, actions=TAG
X-Junkmail-Status: score=10/50, host=c2beaomr06.btconnect.com
X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0208.4D47E559.00B2, ss=1, fgs=0, ip=0.0.0.0, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=single engine
X-Junkmail-IWF: false
Cc: tls@ietf.org
Subject: Re: [TLS] I-D Action:draft-ietf-tls-dtls-heartbeat-01.txt
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, 01 Feb 2011 10:46:51 -0000

----- Original Message -----
From: "Michael Tüxen" <Michael.Tuexen@lurchi.franken.de>
To: "Florian Weimer" <fweimer@bfk.de>
Cc: <tls@ietf.org>
Sent: Thursday, January 27, 2011 2:49 PM

On Jan 27, 2011, at 2:00 PM, Florian Weimer wrote:

>> This document describes the Heartbeat Extension for the Transport
>> Layer Security (TLS) and Datagram Transport Layer Security (DTLS)
>> protocol.
>
> I think this paragraph
>
> | There MUST NOT be more than one HeartbeatRequest message in flight
> | at a time.
>
> should be changed to:
>
> | Retransmissions MUST use the same payload as the original
> | HeartbeatRequest message.
The intention of the sentence in the ID is that you can not send
multiple HeartbeatRequest out. This could overload the network since
DTLS uses transport layers which do not necessary provide a congestion
control. That is why you can only have one request in flight.
Please note that it is not in flight anymore if the corresponding
HeartbeatReply has been received or the retransmission timer fires.

Michael

My experience of the IESG is that they will insist on a paragraph about
Congestion Control (lack of) and mitigation thereof.  At the same time,
I find it very hard to know what words will satisfy them; my most recent
experience was with RFC6012, albeit a more complex scenario.

Tom Petch

>
> The original requirement seems to be pretty much unimplementable
> because of transport layer characteristics.
Not sure what problem you are thinking about.
An implementation of the ID for OpenSSL is available at
http://sctp.fh-muenster.de/dtls-patches.html

Best regards
Michael
>
> --
> Florian Weimer                <fweimer@bfk.de>
> BFK edv-consulting GmbH       http://www.bfk.de/
> Kriegsstraße 100              tel: +49-721-96201-1
> D-76133 Karlsruhe             fax: +49-721-96201-99
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls