Hello Martin,
thanks a lot for your answer!
That helps very much to overcome my UDP confusion :-).
best regards
Achim
Am 15.07.20 um 08:41 schrieb Martin Thomson:
On Tue, Jul 14, 2020, at 22:41, Achim Kraus wrote:
For me it seems, that an agreement about this message buffer size is
still missing.
This is a question we dealt with in QUIC by limiting UDP datagram size rather
than the record size (or packet size in QUIC terminology).
In this case, the spec doesn't really say the most helpful thing about UDP
datagram size in DTLS. Indeed, you might say that pointing to the ability to
include multiple records per datagrams is an invitation to do bad things.
After all, a receiver that receives a datagram that is too large for it likely
has to drop it or only process part of it. The partial processing is possible
if there are small records, but it does lead to lots of losses.
The way I would approach this is to send one record per datagram in DTLS, no
matter what the spec says.
(NSS implements this spec, but does not assume any limits, it only respects a
limit set by a peer. For DTLS it sends one record per datagram, outside of the
handshake.)
Assuming that you do have a constrained implementation that can't receive large
datagrams, then we probably need different signaling. But there are
workarounds.
If you start receiving large UDP datagrams, then it is possible to drop those
and hope that your peer has some sort of PMTU discovery (NSS has something, but
it is crude). At that point, the size of datagrams is limited as though it
were a path limitation. That likely gets you down to the minimum MTU for the
IP version you are using. For IPv6, that's not so different from the 1400-odd
that you describe, but IPv4 - and therefore some implementations - might go as
low as the IPv4 minimum MTU.
(FWIW, NSS will go as low as a 228 byte MTU, which is pretty extreme. And it
takes a lot of failed retransmissions to get that low. I wouldn't expect that
small an MTU from other implementations.)
All that said, if you have a size constraint smaller than a typical UDP MTU,
then you have a very constrained implementation. Not being able to spare ~1k
but expecting to do TLS is something I struggle to comprehend.
_______________________________________________
TLS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tls
_______________________________________________
TLS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tls
