Issue 2 - Fragmentation
Joe summarized:
Tim Evans brought up the problem of fragmentation and reordering that
may not be taken care of by the DTLS layer. I'm not sure I fully
understand this issue. It seems that there is an issue here. The issue
seems to be that a SYSLOG application message can span multiple DTLS
records. Is it feasible to restrict this behavior?
Pasi wrote the following:
vvv
I would prefer to keep syslog-over-DTLS-over-UDP as similar to RFC 5246
(syslog-over-UDP) as possible -- i.e. don't add any kind of
fragmentation/reassembly in syslog layer. Both syslog-over-UDP and
syslog-over-DTLS-over-UDP already support messages up to ~64K; they're
just not very efficient if your MTU is small (and you need IP layer
fragmentation). But for administrators that know they'll need efficient
transport of large messages, we already have a solution: RFC 5425.
^^^
Tom Petch responded to Pasi with:
vvv
The maximum size of a single DTLS record is 2^14 bytes (this limit
comes from TLS).
<tp>
Where?:-)
TLS provides fragmentation and says that
"length MUST NOT exceed 2^14." [RFC5246 s6.2.1]
so that the upper layers can send larger messages which TLS then fragments
for them.
DTLS provides fragmentation for handshake messages [RFC4347 s3.2.3] but
not for the record layer; rather it says,
" As in TLS 1.1, the length should not exceed 2^14."
should not, no MUST NOT as in [RFC5246]
(and draft-ietf-tls-rfc4347-bis has the same text)
So while 65535 byte messages are not generally acceptable, where the users
know their network and its MTU, then we should let them do what they know
best. I see the main use of syslog in switched Enterprise LAN where large
MTU are a commonplace.
^^^
Pasi responded with:
vvv
RFC 4346 (from which this text comes from) mostly did not use
RFC2119 keywords, but instead informal language like the
lowercase "should not" you quoted. AFAIK it was meant to
express a strict limit, not a recommendation (this is implied
by other text in the spec, and as you noticed, we clarified
this in RFC 5246).
But even though DTLS records are limited to 2^14 bytes, syslog
messages are not! The current spec seems to support 64K (minus
some small number of overhead) just fine -- the message will be
split to multiple DTLS records (max. 2^14 bytes each), but those
DTLS records are then combined to a single UDP datagram.
^^^
Tim wrote something (badly formatted) and Pasi responded:
vvv
Tim Evens wrote:
But even though DTLS records are limited to 2^14 bytes, syslog
messages are not! The current spec seems to support 64K (minus some
small number of overhead) just fine -- the message will be split to
multiple DTLS records (max. 2^14 bytes each), but those DTLS
records are then combined to a single UDP datagram.
Ahh... Only if DTLS sequence numbers are used and if they are
implemented using a reorder queueing method can a message be split
into "chunks" that are transmitted over multiple DTLS records.
No -- even if you split a message to multiple DTLS records, all those
records are sent in a *single* UDP datagram, in order. So there's
no need to queue/reorder packets based on DTLS sequence numbers.
(The one UDP datagram might, of course, get fragmented to several
IP packets, but this happens below UDP and DTLS, so DTLS sequence
numbers are not involved...)
^^^
Tim wrote:
Interesting because RFC4347 IMHO states clearly that IP fragmentation
(IP not UDP) must be avoided and thus dtls must determine the MTU.
Final word from Pasi was:
RFC 4347 does strongly recommend avoiding IP fragmentation
(which doesn't necessarily work all that great through broken
middleboxes, and won't lead to good performance), but it
does not forbid it.
ACTION: WG consensus is to support very large syslog messages. Authors
need to explain this in the document.
_______________________________________________
Syslog mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/syslog
