There is no upper limit for a message
length per se. As stated in [RFC4347], each DTLS record MUST fit
within a single DTLS datagram. When mapping onto different
transports, DTLS has different record size limitations. The
application implementer SHOULD determine the maximum record size
allowed by DTLS protocol running over the transport in use. The
message size SHOULD NOT exceed the DTLS maximum record size
limitation of 2^14 bytes.
Why is this "SHOULD NOT" and not a "MUST NOT"? The quoted requirement
from [RFC4347] doesn't seem to give any excuses.
Tom Petch wrote:
On the question of maximum size, I think we should not change the text.
RFC4347 has a should not and not a must not so I think that we need a good
reason to change.
And in fact, the opposite is true. There has been pressure on the syslog
list to allow 65,535 byte messages - healthcare as I recall - so limiting
the size to 2**14 would exclude a known application
On avoiding long packets: A.4 of syslog (RFC5424), I believe,
addresses this. Additionally, syslog over UDP (RFC5426) also
addresses this. Both are normative references.
The text from RFC 4347 is:
Identical to the length field in a TLS 1.1 record. As in TLS
1.1, the length should not exceed 2^14.
I think they're not trying to up the requirements in RFC 4347. They
are however using 2119 language ;)
Tom also wrote:
I see that this I-D had entered 'Revised I-D needed' which I would like to
I see several comments about maximum record size, including a suggestion
that we should make the 'SHOULD NOT' a 'MUST NOT' exceed 2**14.
I am dead set against this change. We had a clear requirment, early on,
to allow 65k messages, and I think it wrong to MUST NOT that requirement.
The text in the other I-Ds is a compromise to strke a balance between this
and having everything fit in 576 byte; I think we have the balance right.
Rainer strongly agrees with this and gives examples from use.
I haven't followed this discussion in detail, but it looks like
there's some confusion about the basic "units" of transmission. As far
as I can tell, we have four different layers:
- a syslog message (SYSLOG-FRAME in ABNF)
- a DTLS record
- a UDP datagram
- an IP packet
As noted in Section 5.4, "It is possible that multiple syslog messages
be contained in one DTLS record, or that a syslog message be
transferred in multiple DTLS records."
The maximum size of a single DTLS record is 2^14 bytes (this limit
comes from TLS). One DTLS record must fit in one UDP datagram, but one
UDP datagram can contain more than one DTLS record.
The maximum size of UDP datagram is 64K (this limit comes from UDP),
but it can be fragmented to multiple IP packets as needed.
There's one additional restriction that I'm not sure is really
mentioned anywhere: A single syslog message has to fit in a single UDP
datagram. So while it can be split to multiple DTLS records, all those
records have to be in a single UDP datagram (so the syslog layer does
not reassemble syslog message pieces from multiple UDP datagrams --
SYSLOG-FRAME does not have sufficient information to do this
In addition to the "hard" size limits (coming from DTLS and UDP),
we probably need a recommendation saying that it's better if you
can avoid IP fragmentation -- but this is precisely the same as normal
syslog-over-UDP (minus the small overhead from DTLS).
Robert Horn wrote:
In this case, could the requirement be rephrased in syslog over dtls.
Rather than imply that the 2**14 limit is de novo in syslog, a phrasing
like "RFC 4347 limits the size of DTLS message bodies to 2**14 bytes"
would be preferable. The limit will still be an issue for some parts of
healthcare and this kind of phrasing points to the real source of the
limit. Then, if some later version of DTLS changes that limit, the syslog
over dtls would inherit that change. This would be consistent with the
approach taken in syslog over UDP, where the size limits are
recommendations up until the hard limit for the size of a UDP message, and
it is made clear that UDP is the reason for the hard limit.
ACTION: Authors need to clarify this and obtain WG consensus.