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