Re: [TLS] Last Call: <draft-ietf-tls-rfc4347-bis-04.txt> (Datagram Transport Layer Security version 1.2) to Proposed Standard

Eric Rescorla <ekr@rtfm.com> Tue, 08 February 2011 20:58 UTC

Return-Path: <ekr@rtfm.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 83CD43A6857; Tue, 8 Feb 2011 12:58:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.677
X-Spam-Level:
X-Spam-Status: No, score=-102.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
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 TwX5-+4TBvBO; Tue, 8 Feb 2011 12:58:32 -0800 (PST)
Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by core3.amsl.com (Postfix) with ESMTP id 79D503A684C; Tue, 8 Feb 2011 12:58:32 -0800 (PST)
Received: by yie19 with SMTP id 19so2791594yie.31 for <multiple recipients>; Tue, 08 Feb 2011 12:58:40 -0800 (PST)
MIME-Version: 1.0
Received: by 10.90.68.4 with SMTP id q4mr460212aga.54.1297198719438; Tue, 08 Feb 2011 12:58:39 -0800 (PST)
Received: by 10.90.117.9 with HTTP; Tue, 8 Feb 2011 12:58:39 -0800 (PST)
In-Reply-To: <DD68C5E0-BBE9-4F8A-87EA-2192ED24B158@iki.fi>
References: <20101130132359.32419.3777.idtracker@localhost> <alpine.LRH.2.02.1012201513440.26448@netcore.fi> <DD68C5E0-BBE9-4F8A-87EA-2192ED24B158@iki.fi>
Date: Tue, 8 Feb 2011 12:58:39 -0800
Message-ID: <AANLkTimUZ6VavWenYR8Ai2D0it7_jWCLpXdvu20N7jMX@mail.gmail.com>
From: Eric Rescorla <ekr@rtfm.com>
To: =?ISO-8859-1?Q?Juho_V=E4h=E4=2DHerttua?= <juhovh@iki.fi>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: tls@ietf.org, ietf@ietf.org, Pekka Savola <pekkas@netcore.fi>, tls-chairs@tools.ietf.org, draft-ietf-tls-rfc4347-bis@tools.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: Tue, 08 Feb 2011 20:58:33 -0000

On Mon, Dec 20, 2010 at 11:01 AM, Juho Vähä-Herttua <juhovh@iki.fi> wrote:
> On 20.12.2010, at 15.15, Pekka Savola wrote:
>> 3.2.3. Message Size
>>
>>   TLS and DTLS handshake messages can be quite large (in theory up to
>>   2^24-1 bytes, in practice many kilobytes).  By contrast, UDP
>>   datagrams are often limited to <1500 bytes if fragmentation is not
>>   desired.  In order to compensate for this limitation, each DTLS
>>   handshake message may be fragmented over several DTLS records.  Each
>>   DTLS handshake message contains both a fragment offset and a fragment
>>   length.
>>
>> 4.1.1. Transport Layer Mapping
>>
>>   Each DTLS record MUST fit within a single datagram.  In order to
>>   avoid fragmentation, clients of the DTLS record layer SHOULD attempt
>>   to size records so that they fit within any PMTU estimates obtained
>>   from the record layer.
>>
>> ... these seem somewhat contradictory.  Maybe I'm missing something.  The
>> latter seems to be saying that DTLS implementations should try to avoid IP
>> fragmentation, but the former seems to imply that it's de-facto mode of
>> operation.
>
> These are not contradictory. If a handshake message size and record header don't fit inside single datagram, it should be fragmented into several small handshake messages and each of these is put into a separate DTLS record. The resulting DTLS record after encryption should not exceed the maximum UDP (or DCCP or whatever) datagram size and therefore doesn't need IP level fragmentation.
>
> I think what you "missed" was simply the difference of IP level fragmentation and DTLS handshake protocol level fragmentation.

I think that is a lot of the issue here. We probably don't distinguish
these clearly. Given that I don't want to change terminology now
I suggest we just say "DTLS fragmentation" and "IP fragmentation".
It's clunky but serviceable.

WRT to the ICMP issue, my take on this is that ICMP Isn't reliable
both because of filtering and that it implies connected
sockets. So, the application needs to be able to determine PMTU even
if it never gets any kind of error indication. However,
I agree that if the stack does get an explicit error it MUST adjust.

The rest of Pekka's suggestions make sense and I should be able to
implement them.
-Ekr