Subject: Re: [Syslog] AD review comments for draft-ietf-syslog-dtls

From: "Tim Evens" <[email-masked]>
Date: Wed, 05 May 2010 16:02:14 -0400

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.   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-masked]]Date: 05/03/2010 06:49 AMTo: "tom.petch" , "Joe Salowey" , "Sean Turner" CC: [email-masked]: Re: [Syslog] AD review comments for draft-ietf-syslog-dtlsHi,  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:  > ----- Original Message ----- > From: "Joseph Salowey (jsalowey)" <[email-masked]>; > To: "Sean Turner" <[email-masked]>;; "Chris Lonvick (clonvick)" > <[email-masked]>; > Cc: <[email-masked]>; > Sent: Friday, April 23, 2010 5:02 PM > > >> Anybody on the list have objection to adding the Chris' suggested text >> and the DCCP service code SYLG? > > I see SYSL used as a four character code for syslog in other settings and would > prefer that.  Else, following the principle of dropping vowels, SSLG, but I > think that not as good. > > Tom Petch > >> Thanks, >> >> Joe >> >>> -----Original Message----- >>> From: Sean Turner [mailto:[email-masked]] >>> Sent: Thursday, April 22, 2010 3:55 PM >>> To: Joseph Salowey (jsalowey); Chris Lonvick (clonvick) >>> Cc: [email-masked] >>> Subject: Re: [Syslog] AD review comments for draft-ietf-syslog-dtls >>> >>> I'm fine with either.  Regardless, the IANA considerations section >> needs >>> to be updated to register the service code - unless some other >> document >>> that I don't know about already did.  Notes for the registration can >> be >>> found here: >>> http://www.iana.org/assignments/service-codes/service-codes.xhtml >>> >>> But, all that I think is needed is some text asking IANA to register >> the >>> following DCCP service code: >>> >>>    1398361159   SYLG   SYSLOG Protocol    [TBD] >>> >>> spt >>> >>> Joseph Salowey (jsalowey) wrote: >>>> Hi Chris, >>>> >>>> CCID 3 looks good to me, I'm OK with the text. >>>> >>>> We could just use the port number, 6514, as the service code. Since >> the >>>> service identifier applies to more than DCCP, it probably makes more >>>> sense the follow the scheme defined in RFC4340 where a 4 letter >> string >>>> is used as the service identifier, such as the following: >>>> >>>> SC:SYLG >>>> SC=x53594C47 >>>> SC=1398361159 >>>> >>>> Cheers, >>>> >>>> Joe >>>>> -----Original Message----- >>>>> From: [email-masked] [mailto:[email-masked]] On >>>> Behalf >>>>> Of Chris Lonvick (clonvick) >>>>> Sent: Monday, April 12, 2010 6:40 AM >>>>> To: [email-masked] >>>>> Subject: Re: [Syslog] AD review comments for draft-ietf-syslog-dtls >>>>> >>>>> Hi Folks, >>>>> >>>>> I'll suggest CCID 3 because that's my lucky number.  ;-) >>>>> >>>>> Seriously, here is a relevant point from RFC 5238: >>>>> ===vvv=== >>>>>     In addition to the retransmission issues, if the throughput >> needs >>>> of >>>>>     the actual application data differ from the needs of the DTLS >>>>>     handshake, it is possible that the handshake transference could >>>> leave >>>>>     the DCCP congestion control in a state that is not immediately >>>>>     suitable for the application data that will follow.  For >> example, >>>>>     DCCP Congestion Control Identifier (CCID) 2 ([RFC4341]) >> congestion >>>>>     control uses an Additive Increase Multiplicative Decrease >> (AIMD) >>>>>     algorithm similar to TCP congestion control.  If it is used, >> then >>>> it >>>>>     is possible that transference of a large handshake could cause >> a >>>>>     multiplicative decrease that would not have happened with the >>>>>     application data.  The application might then be throttled >> while >>>>>     waiting for additive increase to return throughput to >> acceptable >>>>>     levels. >>>>> >>>>>     Applications where this might be a problem should consider >> using >>>> DCCP >>>>>     CCID 3 ([RFC4342]).  CCID 3 implements TCP-Friendly Rate >> Control >>>>>     (TFRC, [RFC3448])).  TFRC varies the allowed throughput more >>>> slowly >>>>>     than AIMD and might avoid the discontinuities possible with >> CCID >>>> 2. >>>>> ===^^^=== >>>>> >>>>> My reasoning for choosing CCID 3 is that when some devices start up >>>> they >>>>> will queue up syslog messages until the network is up, and then >> they >>>> will >>>>> start to deliver them.  I don't want a large handshake to throttle >>>> that >>>>> initial burst of messages.  (Please challenge this assumption if >> you >>>> have >>>>> a better understanding of the process.) >>>>> >>>>> I'll suggest that the specific wording will need to be: "MUST >>>> implement >>>>> CCID 3 and SHOULD implement CCID 2 to ensure interoperability". >> Does >>>> that >>>>> sound OK to everyone? >>>>> >>>>> >>>>> Joe: can you look at Sean's second question and let us know about >>>> that? >>>>> Thanks, >>>>> Chris >>>>> >>>>> On Thu, 8 Apr 2010, Sean Turner wrote: >>>>> >>>>>> I have one major comment and it relates to DCCP: >>>>>> >>>>>> The DCCP chairs tell me that to specify the use of DCCP the ID >> needs >>>> to >>>>>> decide which CCID it will use (CCID 2 is AIMD and CCID 3 is TFRC). >>>> I >>>>> was >>>>>> hoping that the DTLS over DCCP RFC addressed this, but that RFC >>>> doesn't >>>>> pick >>>>>> one it leaves this choice to the "application". >>>>>> >>>>>> Can you also confirm that the Port # is used as the DCCP service >>>> code? >>>>>> spt >> > > _______________________________________________ Syslog mailing list [email-masked] https://www.ietf.org/mailman/listinfo/syslog

---

From: "tom.petch" <[email-masked]>
Date: Sat, 8 May 2010 16:51:37 +0200

---- Original Message -----
From: "Tim Evens" <[email-masked]>
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.

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-masked]]Date:
05/03/2010 06:49 AM
To: "tom.petch" , "Joe Salowey" , "Sean Turner" CC: [email-masked]
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: