Re: [TLS] Last Call: <draft-ietf-tls-rfc4347-bis-04.txt> (Datagram Transport Layer Security version 1.2) to Proposed Standard
Florian Weimer <fweimer@bfk.de> Mon, 20 December 2010 14:48 UTC
Return-Path: <fweimer@bfk.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 C8B5F3A68B5; Mon, 20 Dec 2010 06:48:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.082
X-Spam-Level:
X-Spam-Status: No, score=-2.082 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, HELO_EQ_DE=0.35]
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 bKdK1GCaQWqn; Mon, 20 Dec 2010 06:48:11 -0800 (PST)
Received: from mx01.bfk.de (mx01.bfk.de [193.227.124.2]) by core3.amsl.com (Postfix) with ESMTP id 88F9E3A6897; Mon, 20 Dec 2010 06:48:10 -0800 (PST)
Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) id 1PUh3o-0002Et-8l; Mon, 20 Dec 2010 14:50:00 +0000
Received: by bfk.de with local id 1PUh3o-0003LK-45; Mon, 20 Dec 2010 14:50:00 +0000
To: Pekka Savola <pekkas@netcore.fi>
References: <20101130132359.32419.3777.idtracker@localhost> <alpine.LRH.2.02.1012201513440.26448@netcore.fi>
From: Florian Weimer <fweimer@bfk.de>
Date: Mon, 20 Dec 2010 14:50:00 +0000
In-Reply-To: <alpine.LRH.2.02.1012201513440.26448@netcore.fi> (Pekka Savola's message of "Mon\, 20 Dec 2010 15\:15\:18 +0200 \(EET\)")
Message-ID: <8262uo5wiv.fsf@mid.bfk.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: draft-ietf-tls-rfc4347-bis@tools.ietf.org, ietf@ietf.org, tls-chairs@tools.ietf.org, tls@ietf.org
Subject: Re: [TLS] Last Call: <draft-ietf-tls-rfc4347-bis-04.txt> (Datagram Transport Layer Security version 1.2) to Proposed Standard
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: Mon, 20 Dec 2010 14:48:12 -0000
* Pekka Savola: > If there is a transport protocol indication (either via ICMP or via a > refusal to send the datagram as in DCCP Section 14), then DTLS record > layer should inform the upper layer protocol of the error. > > .. is this too weak? I've have thought that it would be natural that if > DTSLS record layer gets this notification (which, in the case of ICMP and > omitting information, is not necessarily given), it MUST pass this > information up. Note that the refusal to send could also apply to UDP > if packet is bigger than PMTU and DF bit is set or IPv6 is used. > What is the alternative if it doesn't? It would be fine if > the alternative is that the DTLS record layer react to that information > itself, but completely ignoring e.g. ICMP packet too big would lead to > communication failure. ICMP packet too big is typically handled by the stack, not the application. The stack updates the stored path MTU, the application tries again, and this time, the stack produces smaller fragments. AFAIUI, requiring ICMP processing in applications prescribes an implementation model based on connected UDP sockets (in the terminology of the BSD sockets API). This is not always desirable or possible. -- 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] Last Call: <draft-ietf-tls-rfc4347-bis-04.t… The IESG
- Re: [TLS] Last Call: <draft-ietf-tls-rfc4347-bis-… Florian Weimer
- Re: [TLS] Last Call: <draft-ietf-tls-rfc4347-bis-… Pekka Savola
- Re: [TLS] Last Call: <draft-ietf-tls-rfc4347-bis-… Juho Vähä-Herttua
- Re: [TLS] Last Call: <draft-ietf-tls-rfc4347-bis-… Eric Rescorla