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

Juho Vähä-Herttua <juhovh@iki.fi> Mon, 20 December 2010 18:59 UTC

Return-Path: <juhovh@iki.fi>
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 A3C783A6A4C; Mon, 20 Dec 2010 10:59:13 -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 TQp-9XNjr+Qx; Mon, 20 Dec 2010 10:59:12 -0800 (PST)
Received: from smtp03.tky.fi (smtp03.tky.fi [82.130.63.73]) by core3.amsl.com (Postfix) with SMTP id 19F923A67F4; Mon, 20 Dec 2010 10:59:11 -0800 (PST)
Received: from smtp.vaha-herttua.fi ([82.130.44.233]) by smtp03.tky.fi (SMSSMTP 4.1.9.35) with SMTP id M2010122021010409156 ; Mon, 20 Dec 2010 21:01:04 +0200
Received: from vagabond.lan (pyq1.kyla.fi [82.130.44.193]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.vaha-herttua.fi (Postfix) with ESMTPSA id 8084A1FCFE; Mon, 20 Dec 2010 21:01:24 +0200 (EET)
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: multipart/signed; boundary=Apple-Mail-29-1031850430; protocol="application/pkcs7-signature"; micalg=sha1
From: =?iso-8859-1?Q?Juho_V=E4h=E4-Herttua?= <juhovh@iki.fi>
In-Reply-To: <alpine.LRH.2.02.1012201513440.26448@netcore.fi>
Date: Mon, 20 Dec 2010 21:01:02 +0200
Message-Id: <DD68C5E0-BBE9-4F8A-87EA-2192ED24B158@iki.fi>
References: <20101130132359.32419.3777.idtracker@localhost> <alpine.LRH.2.02.1012201513440.26448@netcore.fi>
To: Pekka Savola <pekkas@netcore.fi>
X-Mailer: Apple Mail (2.1082)
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 18:59:13 -0000

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.


Juho