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

[Eric Rescorla <[e-mail]>]

On Mon, Dec 20, 2010 at 11:01 AM, Juho Vähä-Herttua <[e-mail]> 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