Right. I wrote the following a couple weeks back:"… an application may not
directly write to the network where UDP/DTLS would be used as a transport.
More likely, the application will write to a regular file or FIFO/PIPE that may
support a larger message size. The application that reads this message may be
the application that sends the messages via UDP/DTLS. It would be more
meaningful if the application writing the message controls the truncation or if
the transport application sending the message onto the network can correctly
break up the message into parts to fit the transport message size limitations.
RFC5424 doesn't detail SD elements or methods for splitting messages.
Transports have size constraints and will require messages to be truncated or
split. For example, the CISCO-SYSLOG-MIB defines that a message larger than
255 characters will be truncated to 254 characters with a '*' as the 255th
character. "To your point there are multiple units, but I would lump three of
those units together as "transport" units considering they all have to do with
the transportation of the message on the network. In my opinion, this draft
assumes that the application logging the message will some how size the message
to fit within a single DTLS record/packet. This assumption is problematic, as
mentioned above the application writing the actual SYSLOG-MSG per RFC5424 has
no way of knowing which transport is being used and what limitations those
transports impose. For example, in my experience and in my opinion, there will
be more than one syslog receiver/collector. Remote syslog
receivers/collectors may require different transports. One may use UDP/DTLS
while the other uses TCP. Therefore, the original syslog message of say 1480
bytes may be written to the network twice, one using UDP/DTLS and the other
using TCP. The message that is transported using TCP will be receive in full
without any issues, while the one with DTLS will have to be truncated to the
MTU size limitations. RFC4347 (DTLS) refers to RFC4346 (TLS 1.1 obsoleted by
RFC5246 TLS 1.2) for record layer implementation. More specifically, as
defined in RFC4346 Section 6.2.1, "The record layer fragments information
blocks into TLSPlaintext records carrying data in chunks of 2^14 bytes or
less. Client message boundaries are not preserved in the record layer
(i.e., multiple client messages of the same ContentType MAY be coalesced
into a single TLSPlaintext record, or a single message MAY be fragmented
across several records)."It's possible for TLS 1.1 and 1.2 to support message
block (chunks) as defined because the underlining transport is TCP providing
ordered message delivery, whereas RFC4347 (DTLS) can use UDP which does not
provide ordered delivery. DTLS introduces a sequence number field in the
record structure, which if implemented for reordering, the receiver could
reorder the DTLS records so that the original message blocks are concatenated
back to form the original SYSLOG-MSG. This probably leads to why in this
draft in Section 5.1 it states that when using DTLS sequence numbers "… it
may not assure that all the messages are delivered in order when mapping on
the UDP transport."The reason is that with TCP there is a retransmission for
lost segments, whereas UDP does not implement retransmissions. Therefore, if a
DTLS sequence is dropped/lost or not received within the allotted queue buffer
time, the DTLS application doesn't have anyway of knowing if seq X1 and seq X3
can be correctly put together. How it would it know to discard X1 and X3 since
X2 was lost? In either case, this too is problematic, which leads back to why
the SYSLOG-MSG will have to fit within a single DTLS record. Thus the
SYSLOG-MSG will in most cases always be less than 1460 bytes due to MTU
DTLS/MTU limitations. The application SHOULD NOT assume that using the RFC5424
recommended minimum of 480 octets is sufficient as the IPv4 MTU still can be
less than that.I believe that this could be solved if this draft were to be
updated to require that the DTLS implementation reorder using DTLS sequence
numbers using a queue size of at least 5 or more DTLS packets/records. In
addition, Section 5.4 would need a new field in the SYSLOG-FRAME to include a
FRAME-ID. This FRAME-ID would serve as a way for the DTLS implementation to
know which DTLS records need to be discarded in the event of packet loss. For
example: FRAME-ID = NILVALUE / ("+" / "-") NONZERO-DIGIT 1*15DIGIT; uint48*
+/- is used to indicate more message blocks to come or not. "+"
indicates more to follow, "-" indicates last block. Use NILVALUE if
SYSLOG-MSG is not split across multiple DTLS records, otherwise use
first DTLS sequence number in DTLS record sequence as FRAME-ID. This is an
example only of a possible FRAME-ID. *Instead of using 1*15DIGIT, it could
be 6OCTET=uint48, which would reduce the overall size. Example
Use: DTLS seq 1 - SYSLOG-FRAME-ID=+1001 <SYSLOG-MSG> DTLS seq 2 -
SYSLOG-FRAME-ID=+1001 <SYSLOG-MSG> --> dropped by network --> DTLS seq 3 -
SYSLOG-FRAME-ID=+1001 <SYSLOG-MSG> DTLS seq 4 - SYSLOG-FRAME-ID=-1001
<SYSLOG-MSG> DTLS seq 5 - SYSLOG-FRAME-ID - <SYSLOG-MSG> DTLS seq 6 -
SYSLOG-FRAME-ID - <SYSLOG-MSG>Using a buffer/queue size of 5 DTLS
records/packets, the DTLS implementation would have been holding DTLS seq 1, 2,
and 4 waiting for 3. When it received seq 5 and 6, it reaches its buffer size
and therefore discards DTLS seq 1,2,4 since they all have SYSLOG-FRAME-ID of
1001. DTLS seq 5 and 6 are processed. Thanks,Tim-----Original
Message-----From: [email protected]: 05/24/2010 04:23 AMTo:
[email protected], [email protected]: [email protected]: Re: [Syslog]
AD review discuss/comments for draft-ietf-syslog-dtls 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
anyway). 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). Best regards, Pasi
________________________________________ From: [email protected]
[[email protected]] On Behalf Of ext Sean Turner [[email protected]] Sent:
Saturday, May 22, 2010 6:16 PM To: t.petch Cc: syslog Subject: Re: [Syslog] AD
review discuss/comments for draft-ietf-syslog-dtls t.petch wrote: > I see that
this I-D had entered 'Revised I-D needed' which I would like to > progress. > >
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. Tom, My
response to Alexey was that this I-D borrows that particular requirement from
RFC4347 and that this I-D shouldn't be upping the requirement. If it's okay
with you, I'll forward him your response. The way I read his comment was that
he's just asking why - he's not really requesting a change. spt
_______________________________________________ Syslog mailing list
[email protected] https://www.ietf.org/mailman/listinfo/syslog
_______________________________________________ Syslog mailing list
[email protected] https://www.ietf.org/mailman/listinfo/syslog
_______________________________________________
Syslog mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/syslog
