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

Michael Tüxen <Michael.Tuexen@lurchi.franken.de> Tue, 01 February 2011 20:17 UTC

Return-Path: <Michael.Tuexen@lurchi.franken.de>
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 9A6543A6C6B for <tls@core3.amsl.com>; Tue, 1 Feb 2011 12:17:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.908
X-Spam-Level:
X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[AWL=-0.209, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, 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 bs1HWJ5Yuhdq for <tls@core3.amsl.com>; Tue, 1 Feb 2011 12:16:59 -0800 (PST)
Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by core3.amsl.com (Postfix) with ESMTP id 3310B3A6C42 for <tls@ietf.org>; Tue, 1 Feb 2011 12:16:58 -0800 (PST)
Received: from [192.168.1.113] (p508FB1D6.dip.t-dialin.net [80.143.177.214]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 85E971C0B4612; Tue, 1 Feb 2011 21:20:13 +0100 (CET)
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset=iso-8859-1
From: =?iso-8859-1?Q?Michael_T=FCxen?= <Michael.Tuexen@lurchi.franken.de>
In-Reply-To: <4D481926.6090409@ieca.com>
Date: Tue, 1 Feb 2011 21:20:12 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <A63E8374-1211-48E4-B9C6-BCA9119F80CB@lurchi.franken.de>
References: <20110127114502.24680.73782.idtracker@localhost><8239oeqz6c.fsf@mid.bfk.de> <4848B682-273F-4B52-B9E2-ACBFDFDAAB7F@lurchi.franken.de> <00cf01cbc1f4$dc962700$4001a8c0@gateway.2wire.net> <4D481926.6090409@ieca.com>
To: Sean Turner <turners@ieca.com>
X-Mailer: Apple Mail (2.1082)
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 20:17:01 -0000

On Feb 1, 2011, at 3:31 PM, Sean Turner wrote:

> On 2/1/11 4:23 AM, t.petch wrote:
>> ----- 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
> 
> I suspect that the transport ADs' interest will be piqued the minute they read the words: mtu ;)  The best thing to do is to ask for an early review from tsv-dir@ietf.org.  I'm willing to send it over if you'd like?
Hi Sean,

yes, please send it over to them.

Robin and myself are working on some minor text changes and it would be
nice to address also the comments we get from the tsv-dir in the next
revision.
> 
> This is my bad, because I haven't yet figured out what magic incantation needs to go in drafts to appease the transport (and probably internet area) ADs.
Hmm. Regarding path MTU discovery we made references to RFC 4821, which
should make them happy (I hope).

But let us get their comments and improve the document.

Best regards
Michael
> 
> spt
> 
>>> 
>>> 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
>> 
>> _______________________________________________
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>> 
>