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.
Best regards, Pasi ________________________________ From: ext Tim Evens [[email protected]] Sent: Monday, May 24, 2010 7:34 PM To: [email protected]; [email protected]; Eronen Pasi (Nokia-NRC/Helsinki) Cc: [email protected] Subject: Re: [Syslog] AD review discuss/comments for draft-ietf-syslog-dtls 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] Date: 05/24/2010 04:23 AM To: [email protected], [email protected] CC: [email protected] Subject: 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]<https://mail.nokia.com/owa/UrlBlockedError.aspx> [[email protected]<https://mail.nokia.com/owa/UrlBlockedError.aspx>] On Behalf Of ext Sean Turner [[email protected]<https://mail.nokia.com/owa/UrlBlockedError.aspx>] 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://mail.nokia.com/owa/UrlBlockedError.aspx> https://www.ietf.org/mailman/listinfo/syslog _______________________________________________ Syslog mailing list [email protected]<https://mail.nokia.com/owa/UrlBlockedError.aspx> https://www.ietf.org/mailman/listinfo/syslog
_______________________________________________ Syslog mailing list [email protected] https://www.ietf.org/mailman/listinfo/syslog
