ietf
[Top] [All Lists]

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

2011-02-08 14:59:08
On Mon, Dec 20, 2010 at 11:01 AM, Juho Vähä-Herttua <juhovh(_at_)iki(_dot_)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
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf

<Prev in Thread] Current Thread [Next in Thread>
  • Re: [TLS] Last Call: <draft-ietf-tls-rfc4347-bis-04.txt> (Datagram Transport Layer Security version 1.2) to Proposed Standard, Eric Rescorla <=