IETF Logo Mail Archive

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

Michael Tüxen <Michael.Tuexen@lurchi.franken.de> Wed, 09 February 2011 22:54 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 E7B883A67F3 for <tls@core3.amsl.com>; Wed, 9 Feb 2011 14:54:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.299
X-Spam-Level:
X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[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 WWEitmNyd9gX for <tls@core3.amsl.com>; Wed, 9 Feb 2011 14:54:10 -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 A2DCB3A672E for <tls@ietf.org>; Wed, 9 Feb 2011 14:54:09 -0800 (PST)
Received: from [192.168.1.113] (p508FA862.dip.t-dialin.net [80.143.168.98]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 309F81C0C0BD8; Wed, 9 Feb 2011 23:54:18 +0100 (CET)
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset="iso-8859-1"
From: Michael Tüxen <Michael.Tuexen@lurchi.franken.de>
In-Reply-To: <82sjvxxyey.fsf@mid.bfk.de>
Date: Wed, 09 Feb 2011 23:54:17 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <C0B73988-B0EE-4808-832D-5C6B163F0369@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> <82wrl9zjy9.fsf@mid.bfk.de> <0FF8EA81-FDC9-48A2-BE2B-2937095CF5C7@lurchi.franken.de> <82sjvxxyey.fsf@mid.bfk.de>
To: Florian Weimer <fweimer@bfk.de>
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: Wed, 09 Feb 2011 22:54:13 -0000

On Feb 9, 2011, at 12:03 PM, Florian Weimer wrote:

> * Michael Tüxen:
> 
>> On Feb 9, 2011, at 9:33 AM, Florian Weimer wrote:
>> 
>>> * t. petch:
>>> 
>>>> The intention of the sentence in the ID is that you can not send
>>>> multiple HeartbeatRequest out.
>>> 
>>> But you actually can because the transport layer may duplicate
>>> datagrams.  In particular, recipients MUST be prepared to deal with
>>> such duplicates.
> 
>> If the transport layer does (like TCP or SCTP), it has a CC.
> 
> Duplicates can result from other phenomena, not just deliberate
> retransmission.
What is the point here? The rule is to protect the network.
The receiver has to handle any kind of duplication, but that
is not the point here.

I'm not sure what you are suggesting.

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
>

v2.23.0 | Report a Bug | By Email