Re: [TLS] DTLS and large messages

"t.petch" <ietfc@btconnect.com> Wed, 16 June 2010 09:10 UTC

Return-Path: <ietfc@btconnect.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 1845C3A6AFC for <tls@core3.amsl.com>; Wed, 16 Jun 2010 02:10:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.08
X-Spam-Level:
X-Spam-Status: No, score=-0.08 tagged_above=-999 required=5 tests=[AWL=-0.981, BAYES_50=0.001, J_CHICKENPOX_15=0.6, 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 bP9ddG14oc69 for <tls@core3.amsl.com>; Wed, 16 Jun 2010 02:10:22 -0700 (PDT)
Received: from c2beaomr08.btconnect.com (c2beaomr08.btconnect.com [213.123.26.186]) by core3.amsl.com (Postfix) with ESMTP id 5FB8A3A6AC2 for <tls@ietf.org>; Wed, 16 Jun 2010 02:10:21 -0700 (PDT)
Received: from pc6 (host81-153-11-165.range81-153.btcentralplus.com [81.153.11.165]) by c2beaomr08.btconnect.com with SMTP id EWR61710; Wed, 16 Jun 2010 10:10:10 +0100 (BST)
X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=0001.0A0B0301.4C1894F1.02BE, actions=tag
Message-ID: <000b01cb0d2a$db84eba0$4001a8c0@gateway.2wire.net>
From: "t.petch" <ietfc@btconnect.com>
To: Michael Tüxen <Michael.Tuexen@lurchi.franken.de>, Juho Vähä-Herttua <juhovh@iki.fi>
References: <E1ONiI8-0001C6-Ln@wintermute02.cs.auckland.ac.nz><4C149556.7040008@gnutls.org> <03826B11-ABC0-4F5B-A636-A07DECDF428C@iki.fi><AANLkTimYxYX8KqZ09bC-aglGU6D6W3JGH4gSlpmP4QCG@mail.gmail.com> <516FD065-D91B-4281-8448-5C79FADDD69A@ll.mit.edu> <00f301cb0c5b$f98cc2a0$4001a8c0@gateway.2wire.net> <4C1742A6.1050807@iki.fi> <772A444B-116B-4CC2-A63D-A2D15565E20F@lurchi.franken.de>
Date: Wed, 16 Jun 2010 10:06:35 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Junkmail-Status: score=10/50, host=c2beaomr08.btconnect.com
X-Junkmail-SD-Raw: score=unknown, refid=str=0001.0A0B0209.4C1894F7.04A5, ss=1, fgs=0, ip=0.0.0.0, so=2009-07-20 21:54:04, dmn=5.7.1/2009-08-27, mode=single engine
X-Junkmail-IWF: false
Cc: tls@ietf.org
Subject: Re: [TLS] DTLS and large messages
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, 16 Jun 2010 09:10:23 -0000

----- Original Message -----
From: "Michael Tüxen" <Michael.Tuexen@lurchi.franken.de>
Sent: Tuesday, June 15, 2010 3:29 PM

On Jun 15, 2010, at 11:06 AM, Juho Vähä-Herttua wrote:

> 15.6.2010 10:25, t.petch kirjoitti:
>> How may an application send a 64kbyte (less headers) message over DTLS,
assuming
>> that the substrate is UDP and that UDP can carry 64kbyte datagrams without
>> fragmentation?
>
> This sounds like another argument for max_fragment_length extension allowing
lengths larger than 2^14...
>
>> A usually reliable source has surprised me on two counts:
>>
>> First, I am told that when rfc4347-bis says
>> "As in TLS
>>        1.2, the length should not exceed 2^14.
>> "
>> then that is the authors' way of saying
>> "As in TLS 1.2, the length MUST NOT exceed 2^14."
>> which I had not guessed.
>
> That wording is indeed confusing and should probably be changed, TLS 1.2 uses
MUST NOT so a "should not" is not "as in TLS 1.2". With current wording I
wouldn't recommend exceeding 2^14 length, since it is quite likely to break with
some implementations.
>
>> Second, that DTLS will break up the message into fragments of 2**14 or less
but
>> will then place them in a single UDP datagram so that they will transit the
>> network as one, and can be safely reassembled at the far end.
>
> The specification says: "Multiple DTLS records may be placed in a single
datagram. They are simply encoded consecutively." So in case of 64kB datagrams
there can be either multiple complete records (with fragments of 2^14 or less)
included in a single datagram or each record having its own datagram, in the
receiving end both cases should be handled. It's basically the same as in TLS
1.2 where large handshake messages need to be fragmented into fragments of 2^14
or less and sent consecutively.

DTLS will not fragment any user data. So the application is limited by the path
mtu.
When running DTLS/SCTP, SCTP announces a MTU of 2**14 and uses its own
fragmentation,
but for UDP this is not possible.
To use user messages larger than 2^14, you need a link layer with an MTU of 2^14
or
higher. Do you?

<tp>

I am assuming UDP, no SCTP, and a link layer MTU of at least 64kbyte, with a a
message something under 64kbyte to allow for potentially multiple DTLS headers
to still fit the original application message in a single UDP datagram.

(In passing, I would love to see documentation on DTLS implementations but what
is publicly available seems scarce to non-existent).

Tom Petch

</tp>





Best regards
Michael
>
> This is just my interpretation, but I think the specification is quite clear
on this, and your source is probably correct.
>
>
> Juho
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>