Re: [TLS] DTLS and large messages

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?

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
> 