See inline marked <tievens>-----Original Message-----From: "tom.petch" [[email protected]]date: 05/08/2010 12:17 PMTo: [email protected], [email protected], [email protected], "Tim Evens" CC: [email protected]: Re: [Syslog] AD review comments for draft-ietf-syslog-dtls---- Original Message ----- From: "Tim Evens" <[email protected]>; Sent: Wednesday, May 05, 2010 10:02 PM Hopefully this isn't too late for a review comment...It appears to me that DTLS as a SYSLOG-MSG transport introduces a new variable that isn't present with traditional TCP and UDP based transports with regards to SYSLOG-MSG fragments. IP/UDP transport allows for IPv4 based fragmentation, even though it should be avoided for several reasons, there could be useful and valid application uses for fragmenting UDP packets. <tp> True, but RFC5426 says "It is RECOMMENDED that syslog senders restrict message sizes such that IP datagrams do not exceed the smallest MTU of the network in use. This avoids datagram fragmentation and possible issues surrounding fragmentation such as incorrect MTU discovery. Fragmentation can be undesirable because it increases the risk of the message being lost due to loss of just one datagram fragment. Syslog has no acknowledgement facility, and therefore there is no effective way to handle retransmission. This makes it impossible for syslog to utilize packetization layer path MTU discovery [9]. When network MTU is not known in advance, the safest assumption is to restrict messages to 480 octets for IPv4 and 1180 octets for IPv6." so my take has always been, forget fragmentation, or use TCP. I would apply that to a DTLS mapping. <tievens>The problem persists in that logging from within 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. I suppose it might be out of scope for this draft with regards for how the transport implementer handles a message that meets RFC5424, but cannot fit within the constraints of UDP/DTLS packet size limitations. In section 5.4.1 it states that "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." If a single syslog message can't span multiple DTLS records and if DTLS doesn't support packet level fragmentation, then the message size will always be less than MTU + transport overhead. Am I reading that correctly? If that's correct, a method will need to be defined and implemented in order to handle the truncation of the valid RFC5424 message when transporting it over UDP/DTLS. </tievens> Tom Petch </tp> IP/TCP as a transport supports message segments that can span multiple packets. Per RFC4347 section 4.1.1, "each DTLS record MUST fit within a single datagram." DTLS introduces a sequence_number field to the record layer, which facilitates reassembly providing the receiving station queues and reorders. In this draft, section 5.1 suggests that it's optional for the implementer to adopt a queue mechanism to resolve reordering. Later in section 5.4 it suggests that a single SYSLOG-MSG can be transferred in multiple DTLS records. If it is optional to implement DTLS sequence numbers, how does the originator of the SYSLOG-MSG know that the collector will not reorder messages? If the originator knows that the collector will not reorder DTLS fragments, then it can truncate messages prior to transmission. In lieu of truncation, the originator could generate multiple SYSLOG-MSG's using structured data that enables the collector to piece them together. There doesn't appear to be a SYSLOG-FRAME ID as part of each DTLS application-data record. If a message of say 1400 bytes is sent in 3 packets/DTLS records, and if packet 2 of the 3 was dropped by the network, how does the collector know that those packets were to be concatenated as a single SYSLOG-MSG? Without a SYSLOG-FRAME identifier, the collector would have to assume invalid based on messages not structured per RFC5424. Also, if there is no frame ID and sequence reordering isn't implemented, a out-of-sequence DTLS record could possibly inadvertently be prepended or appended to the wrong message, causing a valid message to be corrupt. It seems this would be moot if when using DTLS a SYSLOG-MSG must not span multiple DTLS records. Thanks,Tim -----Original Message-----From: "Chris Lonvick" [[email protected]]date: 05/03/2010 06:49 AM To: "tom.petch" , "Joe Salowey" , "Sean Turner" CC: [email protected] Subject: Re: [Syslog] AD review comments for draft-ietf-syslog-dtls Hi, I'm good with that as well. Joe, can you edit and resubmit a new ID? Sean, if this covers all of your edits, when can we expect to see it on the IESG agenda, and when can we see IETF LC? Thanks, Chris On Tue, 27 Apr 2010, tom.petch wrote:
_______________________________________________ Syslog mailing list [email protected] https://www.ietf.org/mailman/listinfo/syslog
