Hello list, implementing a first experimental version of RFC 8449 for DTLS 1.2 in the Eclipse Open Source Project "Californium", I got some doubts about statements, which seems for me to be only applicable, if a API for chunked read/write operations is available.
RFC 8449, Section 3, page 4 “Constraints on record size are often receiver constraints. In comparison, an implementation might be able to send data incrementally. Encryption does not have the same atomicity requirement. Some ciphers can be encrypted and sent progressively. Thus, an endpoint might be willing to send records larger than the limit it advertises for records that it receives.” That matches pretty well the TCP APIs, which supports a chunked usage (by the cost of resources in the TCP stack itself). I’m not sure, how this could be applied to UDP. I’m not aware of a “chunked” API for UDP. A web search also didn’t fill that gap, others seems also to fail as well. https://stackoverflow.com/questions/15446887/udp-read-data-from-the-queue-in-chunks So, should that be applicable for UDP? If so, would it be possible to provide some information about the API to be used for that? RFC 8449, Section 4, page 6 “PMTU governs the size of UDP datagrams, which limits the size of records, but does not prevent records from being smaller. An endpoint that sends small records is still able to send multiple records in a single UDP datagram.” I would agree, if UDP offers a “chunked API”. Without, all records must be assembled before passing them to the UDP stack. That would end up in supporting a “negotiated, limited crypto buffer” and a “not-negotiated, larger message buffer”. For me it seems, that an agreement about this message buffer size is still missing. That may be a simple agreement for minimum message buffer size (e.g. 1472 bytes), or a estimated size from this record size limit (but that would cause a conflict with the page 6 and additionally with, RFC 8449, Section 4, page 4, “Unprotected messages are not subject to this limit.”). So, how do other DTLS implementations deal with that message buffer size? Best regards Achim Kraus _______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
