From clonvick@cisco.com Mon May 3 06:49:11 2010 Return-Path: X-Original-To: syslog@core3.amsl.com Delivered-To: syslog@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB12C28C1B0 for ; Mon, 3 May 2010 06:49:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.467 X-Spam-Level: X-Spam-Status: No, score=-9.467 tagged_above=-999 required=5 tests=[AWL=-0.668, BAYES_50=0.001, GB_I_LETTER=-2, J_CHICKENPOX_24=0.6, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RvZ6BJBakop1 for ; Mon, 3 May 2010 06:49:10 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 0852328C1A7 for ; Mon, 3 May 2010 06:49:09 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.52,319,1270425600"; d="scan'208";a="123871641" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-4.cisco.com with ESMTP; 03 May 2010 13:48:55 +0000 Received: from sjc-cde-011.cisco.com (sjc-cde-011.cisco.com [171.69.16.68]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o43Dmtqg015077; Mon, 3 May 2010 13:48:55 GMT Date: Mon, 3 May 2010 06:48:54 -0700 (PDT) From: Chris Lonvick To: "tom.petch" , Joe Salowey , Sean Turner In-Reply-To: <000401cae617$c56ef520$0601a8c0@allison> Message-ID: References: <4BBE4541.9080200@ieca.com> <4BD0D3BB.8040404@ieca.com> <000401cae617$c56ef520$0601a8c0@allison> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: syslog@ietf.org Subject: Re: [Syslog] AD review comments for draft-ietf-syslog-dtls X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 May 2010 13:49:11 -0000 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: > ----- Original Message ----- > From: "Joseph Salowey (jsalowey)" > To: "Sean Turner" ; "Chris Lonvick (clonvick)" > > Cc: > 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:turners@ieca.com] >>> Sent: Thursday, April 22, 2010 3:55 PM >>> To: Joseph Salowey (jsalowey); Chris Lonvick (clonvick) >>> Cc: syslog@ietf.org >>> 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: syslog-bounces@ietf.org [mailto:syslog-bounces@ietf.org] On >>>> Behalf >>>>> Of Chris Lonvick (clonvick) >>>>> Sent: Monday, April 12, 2010 6:40 AM >>>>> To: syslog@ietf.org >>>>> 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 >> > > From turners@ieca.com Mon May 3 06:57:34 2010 Return-Path: X-Original-To: syslog@core3.amsl.com Delivered-To: syslog@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 52CCB28C1D3 for ; Mon, 3 May 2010 06:57:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.466 X-Spam-Level: X-Spam-Status: No, score=-2.466 tagged_above=-999 required=5 tests=[AWL=0.932, BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_24=0.6, J_CHICKENPOX_35=0.6, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9vRGtak-mpkn for ; Mon, 3 May 2010 06:57:33 -0700 (PDT) Received: from smtp112.biz.mail.re2.yahoo.com (smtp112.biz.mail.re2.yahoo.com [66.196.116.97]) by core3.amsl.com (Postfix) with SMTP id EDB4628C1CB for ; Mon, 3 May 2010 06:57:29 -0700 (PDT) Received: (qmail 67985 invoked from network); 3 May 2010 13:57:13 -0000 Received: from thunderfish.local (turners@96.231.127.156 with plain) by smtp112.biz.mail.re2.yahoo.com with SMTP; 03 May 2010 06:57:12 -0700 PDT X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: .eoY_SsVM1l_5W5IlaSq8dw2MoY0036OHMoWZxvR6pfw1BBMnU25NO3MsDxsf6pwU0oz0vpVVBo4eVdn_kjUIX8aova8ds.wDB3MhGyM2JJWeKiTOO8DIpOtJPeGBADfLaCbKcKYJl7LTrdbUFNMoBvla3Xgkkq62Ujw70w4xJ2tE4iJ7Ug_.26UpBpCkEWNto4zzbieInm2bwblZU9LOhjBs3.N6LKsc9UCoJAKIqQDd76ZOba_2NNLetil2ZHjpwAZhkOt77gGSx7QqGzpGRPZCdruvew_trruxM9zI3QPSI.htf_NyyFu7K883Qq3mnc6jG5muTAyECweJhrF4EDOCembiOHfTqVR_uKuP7Ule3d7ltOJDZx.IRBsjLJOpbcIKfsfxocCFsYmffbxiYfGbwS3uz8cJbpr8V24RoDsYwOX_Qo.Q8J5EXCnzrdxnndFjdf8ZHMtt7y2jQw- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4BDED638.8090604@ieca.com> Date: Mon, 03 May 2010 09:57:12 -0400 From: Sean Turner User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Chris Lonvick References: <4BBE4541.9080200@ieca.com> <4BD0D3BB.8040404@ieca.com> <000401cae617$c56ef520$0601a8c0@allison> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: syslog@ietf.org Subject: Re: [Syslog] AD review comments for draft-ietf-syslog-dtls X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 May 2010 13:57:34 -0000 Chris Lonvick wrote: > 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? The day I see the publication note will be the day I issue the IETF LC. I will also put it on the IESG telechat that comes immediately after the IETF LC ends. I'd like to put it on the 5/20 telechat, but that would probably mean the new version has to be published today or tomorrow. At the latest, it will be on the 6/3 telechat. Obviously, all of this depends on the number of comments we get. spt > Thanks, > Chris > > On Tue, 27 Apr 2010, tom.petch wrote: > >> ----- Original Message ----- >> From: "Joseph Salowey (jsalowey)" >> To: "Sean Turner" ; "Chris Lonvick (clonvick)" >> >> Cc: >> 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:turners@ieca.com] >>>> Sent: Thursday, April 22, 2010 3:55 PM >>>> To: Joseph Salowey (jsalowey); Chris Lonvick (clonvick) >>>> Cc: syslog@ietf.org >>>> 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: syslog-bounces@ietf.org [mailto:syslog-bounces@ietf.org] On >>>>> Behalf >>>>>> Of Chris Lonvick (clonvick) >>>>>> Sent: Monday, April 12, 2010 6:40 AM >>>>>> To: syslog@ietf.org >>>>>> 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 >>> >> >> > From root@core3.amsl.com Tue May 4 09:00:02 2010 Return-Path: X-Original-To: syslog@ietf.org Delivered-To: syslog@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 0BCEF3A6A21; Tue, 4 May 2010 09:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100504160002.0BCEF3A6A21@core3.amsl.com> Date: Tue, 4 May 2010 09:00:02 -0700 (PDT) Cc: syslog@ietf.org Subject: [Syslog] I-D Action:draft-ietf-syslog-dtls-05.txt X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 May 2010 16:00:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Security Issues in Network Event Logging Working Group of the IETF. Title : Datagram Transport Layer Security (DTLS) Transport Mapping for Syslog Author(s) : J. Salowey, et al. Filename : draft-ietf-syslog-dtls-05.txt Pages : 18 Date : 2010-05-04 This document describes the transport of syslog messages over DTLS (Datagram Transport Level Security). It provides a secure transport for syslog messages in cases where a connection-less transport is desired. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-syslog-dtls-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-syslog-dtls-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-05-04084828.I-D@ietf.org> --NextPart-- From wwwrun@core3.amsl.com Tue May 4 09:33:24 2010 Return-Path: X-Original-To: syslog@ietf.org Delivered-To: syslog@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 18A4B3A6CA6; Tue, 4 May 2010 09:33:23 -0700 (PDT) X-idtracker: yes To: IETF-Announce From: The IESG Message-Id: <20100504163324.18A4B3A6CA6@core3.amsl.com> Date: Tue, 4 May 2010 09:33:24 -0700 (PDT) Cc: syslog@ietf.org Subject: [Syslog] Last Call: draft-ietf-syslog-dtls (Datagram Transport Layer Security (DTLS) Transport Mapping for Syslog) to Proposed Standard X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 May 2010 16:33:24 -0000 The IESG has received a request from the Security Issues in Network Event Logging WG (syslog) to consider the following document: - 'Datagram Transport Layer Security (DTLS) Transport Mapping for Syslog ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2010-05-18. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-syslog-dtls-05.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=19136&rfc_flag=0 From turners@ieca.com Tue May 4 09:45:02 2010 Return-Path: X-Original-To: syslog@core3.amsl.com Delivered-To: syslog@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C30923A68AC for ; Tue, 4 May 2010 09:45:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.067 X-Spam-Level: X-Spam-Status: No, score=-2.067 tagged_above=-999 required=5 tests=[AWL=0.531, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JCeCb7KbCC+9 for ; Tue, 4 May 2010 09:45:02 -0700 (PDT) Received: from smtp112.biz.mail.re2.yahoo.com (smtp112.biz.mail.re2.yahoo.com [66.196.116.97]) by core3.amsl.com (Postfix) with SMTP id F22073A68A0 for ; Tue, 4 May 2010 09:45:01 -0700 (PDT) Received: (qmail 17247 invoked from network); 4 May 2010 16:44:45 -0000 Received: from thunderfish.local (turners@96.231.127.156 with plain) by smtp112.biz.mail.re2.yahoo.com with SMTP; 04 May 2010 09:44:45 -0700 PDT X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: kkDv39sVM1k7yiFz8gLnSaeUNAe19Hi3fytU1h8Rjd3lLLPwMmN3TSNmVB3zezwqO1FZsvchxjV0YBHFVf7GFDZjxzR9lVS8w2bweMI8Op7K43Oj4VRuIDBCmZKmTM1cFrk3ynr92qPbltfiG9t5cG8Dcgel9iANd2I1lOwTAxufGX1G3xkypllHlzPYlE96N78PbqYQUPVbWQnvmjiacAB4oUjov..nMLofLwtUN3xgnFTY2SkGGcax8BTIA6ezBHHnyLlkWv_TWvG2fFVnjZDG6RMW2KekffLRGEHOqQXdQrqNMsRjlaBj1HLbdiFube7h9HJ8gt05TBppdjPvb_PPs3jcRCA3e5zhxbGllT7yXcOcsHrklO8sECMTsgj6er3lxDrM2APChVid4K1ZQsr0vyJkZ5Tu.PWDAg0bZq5RWrUfmgEljEhlCEURdA11_AjCk8xdQuwSAzcw4QA- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4BE04EFD.4030909@ieca.com> Date: Tue, 04 May 2010 12:44:45 -0400 From: Sean Turner User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: syslog@ietf.org References: <20100504160002.0BCEF3A6A21@core3.amsl.com> In-Reply-To: <20100504160002.0BCEF3A6A21@core3.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Syslog] I-D Action:draft-ietf-syslog-dtls-05.txt X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 May 2010 16:45:02 -0000 Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Security Issues in Network Event Logging Working Group of the IETF. > > > Title : Datagram Transport Layer Security (DTLS) Transport Mapping for Syslog > Author(s) : J. Salowey, et al. > Filename : draft-ietf-syslog-dtls-05.txt > Pages : 18 > Date : 2010-05-04 > > This document describes the transport of syslog messages over DTLS > (Datagram Transport Level Security). It provides a secure transport > for syslog messages in cases where a connection-less transport is > desired. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-syslog-dtls-05.txt I have requested an IETF LC and placed this ID on the 5/20 IESG telechat. spt From tim@evensweb.com Wed May 5 13:02:33 2010 Return-Path: X-Original-To: syslog@core3.amsl.com Delivered-To: syslog@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5745D3A6C8C for ; Wed, 5 May 2010 13:02:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.285 X-Spam-Level: X-Spam-Status: No, score=-0.285 tagged_above=-999 required=5 tests=[AWL=-1.014, BAYES_50=0.001, GB_I_LETTER=-2, HTML_MESSAGE=0.001, J_CHICKENPOX_24=0.6, J_CHICKENPOX_35=0.6, MIME_QP_LONG_LINE=1.396, SARE_UNSUB18=0.131] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ymWvicfHAm3 for ; Wed, 5 May 2010 13:02:31 -0700 (PDT) Received: from outbound2.bluetie.com (outbound002.bluetie.com [206.65.164.141]) by core3.amsl.com (Postfix) with ESMTP id 22B553A6CA6 for ; Wed, 5 May 2010 13:02:27 -0700 (PDT) Received: from web4.nyc1.bluetie.com ([10.102.1.186]) by outbound2.bluetie.com with bizsmtp id Dw2E1e00340nUHE01w2E0m; Wed, 05 May 2010 16:02:14 -0400 X-CMAE-Score: 0.00 X-CMAE-Analysis: v=1.1 cv=XDvYJvxkJd9pOQOd2aai3EDQwB3csjaZ3p0g00nCMGA= c=1 sm=1 a=4ZZ7scPsdmMA:10 a=AUd_NHdVAAAA:8 a=o4D-YMODAAAA:8 a=48vgC7mUAAAA:8 a=I0CVDw5ZAAAA:8 a=Fn8PaRmu9rwOWPAmfKMA:9 a=LeBHeHVitqAlds65SLkA:7 a=I4yX159oSnWw67trg4UQ5itqaRYA:4 a=QEXdDO2ut3YA:10 a=JfD0Fch1gWkA:10 a=De4saq_zUVgA:10 a=lZB815dzVvQA:10 a=4fByoXqwgwQf3En-:21 a=1XSSs9R0OpRIjO6W:21 a=FrvpURYbAAAA:8 a=hys-s_LZDV6ZaaXpUr4A:9 a=_C35LegMzBglw8rJ4q0A:7 a=EmrnvoHH12ju1duxrdHVHUoYAfsA:4 a=3BuQvuyjSHIA:10 a=dpsC0jy_mCoA:10 a=gHoKoOl0LmUA:10 a=ItR5S0iU1VMA:10 a=_ZzulCCf0S0A:10 a=Lc85SrTrvaEwOMYz:21 a=uOa7-aalBUZGSm02:21 a=sYQYHbgkV8ARn8H0MaeVLw==:117 Received: from web4.nyc1.bluetie.com (localhost.localdomain [127.0.0.1]) by web4.nyc1.bluetie.com (Postfix) with ESMTP id 2FEED5B6967; Wed, 5 May 2010 16:02:14 -0400 (EDT) Message-ID: <20100505160214.21688@web4.nyc1.bluetie.com> X-HTTP-Received: from tim.evensweb [74.114.41.32] by web4.nyc1.bluetie.com (BlueTie WebMail ); Wed, 05 May 2010 16:02:14 -0400 X-Mailer: BlueTie MTA Date: Wed, 05 May 2010 16:02:14 -0400 To: cfinss@dial.pipex.com,jsalowey@cisco.com, turners@ieca.com,clonvick@cisco.com From: "Tim Evens" Importance: normal Content-Type: multipart/alternative; boundary="297777811-1273089734=:21688" MIME-Version: 1.0 Cc: syslog@ietf.org Subject: Re: [Syslog] AD review comments for draft-ietf-syslog-dtls X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 May 2010 20:02:33 -0000 --297777811-1273089734=:21688 Content-transfer-encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Hopefully this isn't too late for a review comment...It appears to me that D= TLS as a SYSLOG-MSG transport introduces a new variable that isn't present w= ith traditional TCP and UDP based transports with regards to SYSLOG-MSG frag= ments. =C2=A0 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. =C2=A0 IP/TCP as a transport supports mess= age segments that can span multiple packets.=C2=A0 Per RFC4347 section 4.1.1= ,=C2=A0 "each DTLS record MUST fit within a single datagram." DTLS introduce= s a sequence_number field to the record layer, which facilitates reassembly = providing the receiving station queues and reorders. =C2=A0 =C2=A0 In this draft, section 5.1 suggests that it's optional for the implementer t= o adopt a queue mechanism to resolve reordering.=C2=A0 Later in section 5.4 = it suggests that a single SYSLOG-MSG can be transferred in multiple DTLS rec= ords. =C2=A0 If it is optional to implement DTLS sequence numbers, how does the originato= r of the SYSLOG-MSG know that the collector will not reorder messages?=C2= =A0 If the originator knows that the collector will not reorder DTLS fragmen= ts, then it can truncate messages prior to transmission. In lieu of truncati= on, the originator could generate multiple SYSLOG-MSG's using structured dat= a that enables the collector to piece them together.=C2=A0 There doesn't appear to be a SYSLOG-FRAME ID as part of each DTLS applicatio= n-data record.=C2=A0 If a message of say 1400 bytes is sent in 3 packets/DTL= S 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 SYSLO= G-MSG? Without a SYSLOG-FRAME identifier, the collector would have to assume= invalid based on messages not structured per RFC5424.=C2=A0 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 wro= ng message, causing a valid message to be corrupt.=C2=A0 It seems this would= be moot if when using DTLS a SYSLOG-MSG must not span multiple DTLS records= .=C2=A0 Thanks,Tim-----Original Message-----From: "Chris Lonvick" [clonvick@cisco.co= m]Date: 05/03/2010 06:49 AMTo: "tom.petch" , "Joe Salowey" , "Sean Turner" C= C: syslog@ietf.orgSubject: Re: [Syslog] AD review comments for draft-ietf-sy= slog-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 i= t on the IESG agenda, and when can we see IETF LC? Thanks, Chris On Tue, = 27 Apr 2010, tom.petch wrote: > ----- Original Message ----- > From: "Josep= h Salowey (jsalowey)" ; > To: "Sean Turner" ;; "Chris Lonvick (clonvick)" > ; > Cc: ; > Sent: Friday, April 23, 2010 5:02 PM > > >> Anybody on the list h= ave objection to adding the Chris' suggested text >> and the DCCP service co= de SYLG? > > I see SYSL used as a four character code for syslog in other se= ttings and would > prefer that. Else, following the principle of dropping v= owels, SSLG, but I > think that not as good. > > Tom Petch > >> Thanks, >> >= > Joe >> >>> -----Original Message----- >>> From: Sean Turner [mailto:turner= s@ieca.com] >>> Sent: Thursday, April 22, 2010 3:55 PM >>> To: Joseph Salowe= y (jsalowey); Chris Lonvick (clonvick) >>> Cc: syslog@ietf.org >>> 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 >>> th= at 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 r= egister >> the >>> following DCCP service code: >>> >>> 1398361159 SYLG= SYSLOG Protocol [TBD] >>> >>> spt >>> >>> Joseph Salowey (jsalowey) wr= ote: >>>> 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. Sin= ce >> the >>>> service identifier applies to more than DCCP, it probably mak= es 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=3Dx53594C47 >>>> SC=3D1398361159 >>>> >>>> Cheers, >= >>> >>>> Joe >>>>> -----Original Message----- >>>>> From: syslog-bounces@iet= f.org [mailto:syslog-bounces@ietf.org] On >>>> Behalf >>>>> Of Chris Lonvick= (clonvick) >>>>> Sent: Monday, April 12, 2010 6:40 AM >>>>> To: syslog@ietf= .org >>>>> Subject: Re: [Syslog] AD review comments for draft-ietf-syslog-dt= ls >>>>> >>>>> Hi Folks, >>>>> >>>>> I'll suggest CCID 3 because that's my l= ucky number. ;-) >>>>> >>>>> Seriously, here is a relevant point from RFC 5= 238: >>>>> =3D=3D=3Dvvv=3D=3D=3D >>>>> 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 congesti= on control in a state that is not immediately >>>>> suitable for the app= lication data that will follow. For >> example, >>>>> DCCP Congestion C= ontrol Identifier (CCID) 2 ([RFC4341]) >> congestion >>>>> control uses = an Additive Increase Multiplicative Decrease >> (AIMD) >>>>> algorithm s= imilar 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 >>>>> ap= plication 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. >>>>> =3D=3D=3D^^^=3D=3D=3D >= >>>> >>>>> My reasoning for choosing CCID 3 is that when some devices start = up >>>> they >>>>> will queue up syslog messages until the network is up, an= d then >> they >>>> will >>>>> start to deliver them. I don't want a large = handshake to throttle >>>> that >>>>> initial burst of messages. (Please ch= allenge this assumption if >> you >>>> have >>>>> a better understanding of = the process.) >>>>> >>>>> I'll suggest that the specific wording will need t= o be: "MUST >>>> implement >>>>> CCID 3 and SHOULD implement CCID 2 to ensur= e 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 Tur= ner 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 addr= essed this, but that RFC >>>> doesn't >>>>> pick >>>>>> one it leaves this c= hoice to the "application". >>>>>> >>>>>> Can you also confirm that the Port= # is used as the DCCP service >>>> code? >>>>>> spt >> > > ________________= _______________________________ Syslog mailing list Syslog@ietf.org https://= www.ietf.org/mailman/listinfo/syslog = --297777811-1273089734=:21688 Content-transfer-encoding: quoted-printable Content-Type: text/html; charset=UTF-8 Hopefully this isn't too late for a review comment...

It appears to me that DTLS as a SYSLO= G-MSG transport introduces a new variable that isn't present with traditiona= l TCP and UDP based transports with regards to SYSLOG-MSG fragments.  <= /p>


IP/UDP transport allows fo= r IPv4 based fragmentation, even though it should be avoided for several rea= sons, there could be useful and valid application uses for fragmenting UDP p= ackets.   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 intr= oduces a sequence_number field to the record layer, which facilitates reasse= mbly providing the receiving station queues and reorders.    

In this draft, section 5.1 suggest= s that it's optional for the implementer to adopt a queue mechanism to resol= ve reordering.  Later in section 5.4 it suggests that a single SYSLOG-M= SG can be transferred in multiple DTLS records.  


If it is optional to imple= ment DTLS sequence numbers, how does the originator of the SYSLOG-MSG know t= hat the collector will not reorder messages?  If the originator knows t= hat the collector will not reorder DTLS fragments, then it can truncate mess= ages prior to transmission. In lieu of truncation, the originator could gene= rate 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-FR= AME identifier, the collector would have to assume invalid based on messages= not structured per RFC5424.  Also, if there is no frame ID and sequenc= e reordering isn't implemented, a out-of-sequence DTLS record could possibly= inadvertently be prepended or appended to the wrong message, causing a vali= d message to be corrupt.  It seems this would be moot if when using DTL= S a SYSLOG-MSG must not span multiple DTLS records. 


Thanks,
Tim



-----Original Message-----
From: "Chris Lonvick" [clonvick@cisco.com]
Date: 05/03/2010 06:49 AM
To: "tom.petch" , "Joe Salowey" , "Sean Turner"
CC: syslog@ietf.org
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:

> ----- Original Message -----
> From: "Joseph Salowey (jsalowey)" <','','','');">jsalowey@cisco.com>;=
> To: "Sean Turner" <','','','');">turners@ieca.com>;; "Chris Lonvick (cl= onvick)"
> <','','','');">clonvick@cisco.com>;
> Cc: <','','','');">syslog@ietf.org>;
> 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:turners@ieca.com]
>>> Sent: Thursday, April 22, 2010 3:55 PM
>>> To: Joseph Salowey (jsalowey); Chris Lonvick (clonvick)
>>> Cc: syslog@ietf.org
>>> Subject: Re: [Syslog] AD review comments for draft-ietf-syslog= -dtls
>>>
>>> I'm fine with either. Regardless, the IANA considerations sec= tion
>> needs
>>> to be updated to register the service code - unless some other=
>> document
>>> that I don't know about already did. Notes for the registrati= on can
>> be
>>> found here:
>>> http://www.iana.org/assignments/service-co= des/service-codes.xhtml
>>>
>>> But, all that I think is needed is some text asking IANA to re= gister
>> 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 co= de. Since
>> the
>>>> service identifier applies to more than DCCP, it probably = makes more
>>>> sense the follow the scheme defined in RFC4340 where a 4 l= etter
>> string
>>>> is used as the service identifier, such as the following:<= br> >>>>
>>>> SC:SYLG
>>>> SC=3Dx53594C47
>>>> SC=3D1398361159
>>>>
>>>> Cheers,
>>>>
>>>> Joe
>>>>> -----Original Message-----
>>>>> From: syslog-bounces@ietf.org [mailto:syslog-bounces@ietf.org] On
>>>> Behalf
>>>>> Of Chris Lonvick (clonvick)
>>>>> Sent: Monday, April 12, 2010 6:40 AM
>>>>> To: syslog@ietf.org
>>>>> Subject: Re: [Syslog] AD review comments for draft-iet= f-syslog-dtls
>>>>>
>>>>> Hi Folks,
>>>>>
>>>>> I'll suggest CCID 3 because that's my lucky number. ;= -)
>>>>>
>>>>> Seriously, here is a relevant point from RFC 5238:
= >>>>> =3D=3D=3Dvvv=3D=3D=3D
>>>>> In addition to the retransmission issues, if the t= hroughput
>> needs
>>>> of
>>>>> the actual application data differ from the needs = of the DTLS
>>>>> handshake, it is possible that the handshake trans= ference 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 ([RFC4= 341])
>> congestion
>>>>> control uses an Additive Increase Multiplicative D= ecrease
>> (AIMD)
>>>>> algorithm similar to TCP congestion control. If i= t is used,
>> then
>>>> it
>>>>> is possible that transference of a large handshake= could cause
>> a
>>>>> multiplicative decrease that would not have happen= ed with the
>>>>> application data. The application might then be t= hrottled
>> 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-Friendl= y Rate
>> Control
>>>>> (TFRC, [RFC3448])). TFRC varies the allowed throu= ghput more
>>>> slowly
>>>>> than AIMD and might avoid the discontinuities poss= ible with
>> CCID
>>>> 2.
>>>>> =3D=3D=3D^^^=3D=3D=3D
>>>>>
>>>>> My reasoning for choosing CCID 3 is that when some dev= ices 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 ass= umption 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 interoper= ability".
>> 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 th= e DCCP service
>>>> code?
>>>>>> spt
>>
>
>
_______________________________________________
Syslog mailing list
Syslog@ietf.org
= https://www.ietf.org/mailman/listinfo/syslog

=
--297777811-1273089734=:21688-- From cfinss@dial.pipex.com Sat May 8 12:17:31 2010 Return-Path: X-Original-To: syslog@core3.amsl.com Delivered-To: syslog@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D5F193A68B5 for ; Sat, 8 May 2010 12:17:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.044 X-Spam-Level: X-Spam-Status: No, score=-0.044 tagged_above=-999 required=5 tests=[AWL=-1.289, BAYES_50=0.001, DATE_IN_PAST_03_06=0.044, J_CHICKENPOX_35=0.6, J_CHICKENPOX_63=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1NfkBr10SF44 for ; Sat, 8 May 2010 12:17:30 -0700 (PDT) Received: from mk-outboundfilter-1.mail.uk.tiscali.com (mk-outboundfilter-1.mail.uk.tiscali.com [212.74.114.37]) by core3.amsl.com (Postfix) with ESMTP id 4718D3A6835 for ; Sat, 8 May 2010 12:17:30 -0700 (PDT) X-Trace: 352395238/mk-outboundfilter-1.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.100.253/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.100.253 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-SMTP-AUTH: X-MUA: Microsoft Outlook Express 6.00.2800.1106Produced By Microsoft MimeOLE V6.00.2800.1106 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqsKAItV5Us+vGT9/2dsb2JhbAAtgUo6ZoRGixOMGa1Ej3gOgRiDAW4E X-IronPort-AV: E=Sophos;i="4.52,353,1270422000"; d="scan'208";a="352395238" X-IP-Direction: IN Received: from 1cust253.tnt1.lnd9.gbr.da.uu.net (HELO allison) ([62.188.100.253]) by smtp.pipex.tiscali.co.uk with SMTP; 08 May 2010 20:17:15 +0100 Message-ID: <004601caeeda$51e62940$0601a8c0@allison> From: "tom.petch" To: , , , "Tim Evens" References: <20100505160214.21688@web4.nyc1.bluetie.com> Date: Sat, 8 May 2010 16:51:37 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Cc: syslog@ietf.org Subject: Re: [Syslog] AD review comments for draft-ietf-syslog-dtls X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 May 2010 19:17:32 -0000 ---- Original Message ----- From: "Tim Evens" 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. 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 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" [clonvick@cisco.com]Date: 05/03/2010 06:49 AM To: "tom.petch" , "Joe Salowey" , "Sean Turner" CC: syslog@ietf.org 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: From wwwrun@rfc-editor.org Tue May 11 12:31:07 2010 Return-Path: X-Original-To: syslog@core3.amsl.com Delivered-To: syslog@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2822C28C29E; Tue, 11 May 2010 12:31:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.921 X-Spam-Level: X-Spam-Status: No, score=-0.921 tagged_above=-999 required=5 tests=[AWL=-0.780, BAYES_20=-0.74, J_CHICKENPOX_93=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vBzp7G-x1ja7; Tue, 11 May 2010 12:31:06 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by core3.amsl.com (Postfix) with ESMTP id 6B4B03A69B3; Tue, 11 May 2010 12:28:24 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 5BA6AE0699; Tue, 11 May 2010 12:28:14 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20100511192814.5BA6AE0699@rfc-editor.org> Date: Tue, 11 May 2010 12:28:14 -0700 (PDT) Cc: syslog@ietf.org, rfc-editor@rfc-editor.org Subject: [Syslog] RFC 5848 on Signed Syslog Messages X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 May 2010 19:31:07 -0000 A new Request for Comments is now available in online RFC libraries. RFC 5848 Title: Signed Syslog Messages Author: J. Kelsey, J. Callas, A. Clemm Status: Standards Track Stream: IETF Date: May 2010 Mailbox: john.kelsey@nist.gov, jon@callas.org, alex@cisco.com Pages: 40 Characters: 102805 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-syslog-sign-29.txt URL: http://www.rfc-editor.org/rfc/rfc5848.txt This document describes a mechanism to add origin authentication, message integrity, replay resistance, message sequencing, and detection of missing messages to the transmitted syslog messages. This specification is intended to be used in conjunction with the work defined in RFC 5424, "The Syslog Protocol". [STANDARDS TRACK] This document is a product of the Security Issues in Network Event Logging Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From tim@evensweb.com Tue May 11 15:20:53 2010 Return-Path: X-Original-To: syslog@core3.amsl.com Delivered-To: syslog@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A9A873A6A9F for ; Tue, 11 May 2010 15:20:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.988 X-Spam-Level: X-Spam-Status: No, score=0.988 tagged_above=-999 required=5 tests=[AWL=-1.610, BAYES_50=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_35=0.6, J_CHICKENPOX_63=0.6, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E5UCMlLbvfeC for ; Tue, 11 May 2010 15:20:52 -0700 (PDT) Received: from outbound1.bluetie.com (outbound1.bluetie.com [206.65.164.140]) by core3.amsl.com (Postfix) with ESMTP id AE1863A6858 for ; Tue, 11 May 2010 15:20:51 -0700 (PDT) Received: from web6.nyc1.bluetie.com ([10.102.1.189]) by outbound1.bluetie.com with outbound001 id GNLg1e00144gVJ201NLgni; Tue, 11 May 2010 18:20:40 -0400 X-CMAE-Score: 0.00 X-CMAE-Analysis: v=1.1 cv=Oj7SP04cn2IcmEQf4j5VeL/9UPUJOHh/Ks6nVw0DKyU= c=1 sm=1 a=4ZZ7scPsdmMA:10 a=FrvpURYbAAAA:8 a=AUd_NHdVAAAA:8 a=o4D-YMODAAAA:8 a=_wFv0sKIAAAA:8 a=48vgC7mUAAAA:8 a=_GfffoZJzFayAPw9nekA:9 a=-lN_Ka-yFBEtcmFXH5IA:7 a=sJ9DNvSArVpsWGqE_Dyb66_vy6AA:4 a=QEXdDO2ut3YA:10 a=JfD0Fch1gWkA:10 a=De4saq_zUVgA:10 a=pN_FbJzYb_wA:10 a=lZB815dzVvQA:10 a=aM9TDeSOHZ1pgHrn9a0A:9 a=K5hX3ZJ6YTglh8_K4D4A:7 a=rgo425eFC5MshysbRtPlCUjadq4A:4 a=2e3vbxWJWpcA:10 a=gHoKoOl0LmUA:10 a=ItR5S0iU1VMA:10 a=N4+s59jGks81T4rwWNbxIQ==:117 Received: from web6.nyc1.bluetie.com (localhost.localdomain [127.0.0.1]) by web6.nyc1.bluetie.com (Postfix) with ESMTP id 816E7AE54A1; Tue, 11 May 2010 18:20:40 -0400 (EDT) Message-ID: <20100511182040.16429@web6.nyc1.bluetie.com> X-HTTP-Received: from tim.evensweb [74.114.41.32] by web6.nyc1.bluetie.com (BlueTie WebMail ); Tue, 11 May 2010 18:20:40 -0400 X-Mailer: BlueTie MTA Date: Tue, 11 May 2010 18:20:40 -0400 To: jsalowey@cisco.com,turners@ieca.com, clonvick@cisco.com,cfinss@dial.pipex.com From: "Tim Evens" Importance: normal Content-Type: multipart/alternative; boundary="832336131-1273616440=:16429" MIME-Version: 1.0 Cc: syslog@ietf.org Subject: Re: [Syslog] AD review comments for draft-ietf-syslog-dtls X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 May 2010 22:20:54 -0000 --832336131-1273616440=:16429 Content-transfer-encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 See inline marked -----Original Message-----From: "tom.petch" [cfin= ss@dial.pipex.com]Date: 05/08/2010 12:17 PMTo: jsalowey@cisco.com, turners@i= eca.com, clonvick@cisco.com, "Tim Evens" CC: syslog@ietf.orgSubject: Re: [Sy= slog] AD review comments for draft-ietf-syslog-dtls---- Original Message ---= -- From: "Tim Evens" ; 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 pre= sent with traditional TCP and UDP based transports with regards to SYSLOG-MS= G fragments. IP/UDP transport allows for IPv4 based fragmentation, even tho= ugh it should be avoided for several reasons, there could be useful and vali= d application uses for fragmenting UDP packets. True, but RFC5426 say= s "It is RECOMMENDED that syslog senders restrict message sizes such tha= t IP datagrams do not exceed the smallest MTU of the network in use. Thi= s avoids datagram fragmentation and possible issues surrounding fragmenta= tion such as incorrect MTU discovery. Fragmentation can be undesirable b= ecause it increases the risk of the message being lost due to loss of jus= t one datagram fragment. Syslog has no acknowledgement facility, and the= refore 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." s= o my take has always been, forget fragmentation, or use TCP. I would apply = that to a DTLS mapping. The problem persists in that logging from w= ithin an application may not directly write to the network where UDP/DTLS wo= uld be used as a transport.=C2=A0=C2=A0 More likely, the application will wr= ite to a regular file or FIFO/PIPE that may support a larger message size.= =C2=A0 The application that reads this message may be the application that s= ends the messages via UDP/DTLS. =C2=A0 It would be more meaningful if the ap= plication writing the message controls the truncation or if the transport ap= plication sending the message onto the network can correctly break up the me= ssage into parts to fit the transport message size limitations.=C2=A0 RFC542= 4 doesn't detail SD elements or methods for splitting messages.=C2=A0 Transp= orts have size constraints and will require messages to be truncated or spli= t.=C2=A0 For example, the CISCO-SYSLOG-MIB defines that a message larger tha= n 255 characters will be truncated to 254 characters with a '*' as the 255th= character.=C2=A0=C2=A0 I suppose it might be out of scope for this draft wi= th regards for how the transport implementer handles a message that meets RF= C5424, but cannot fit within the constraints of UDP/DTLS packet size limitat= ions. In section 5.4.1 it states that "When mapping onto different transport= s, DTLS has different record size limitations.=C2=A0 The application impleme= nter SHOULD determine the maximum record size allowed by DTLS protocol runni= ng over the transport in use." If a single syslog message can't span multipl= e DTLS records and if DTLS doesn't support packet level fragmentation, then = the message size will always be less than MTU + transport overhead.=C2=A0 Am= I reading that correctly? If that's correct, a method will need to be defin= ed and implemented in order to handle the truncation of the valid RFC5424 me= ssage when transporting it over UDP/DTLS.=C2=A0 Tom Petch = IP/TCP as a transport supports message segments that can span multiple packe= ts. Per RFC4347 section 4.1.1, "each DTLS record MUST fit within a single da= tagram." 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 t= o adopt a queue mechanism to resolve reordering. Later in section 5.4 it sug= gests that a single SYSLOG-MSG can be transferred in multiple DTLS records. = If it is optional to implement DTLS sequence numbers, how does the originat= or of the SYSLOG-MSG know that the collector will not reorder messages? If t= he 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 e= nables the collector to piece them together. There doesn't appear to be a S= YSLOG-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 w= ere to be concatenated as a single SYSLOG-MSG? Without a SYSLOG-FRAME identi= fier, the collector would have to assume invalid based on messages not struc= tured per RFC5424. Also, if there is no frame ID and sequence reordering isn= 't implemented, a out-of-sequence DTLS record could possibly inadvertently b= e 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 no= t span multiple DTLS records. Thanks,Tim -----Original Message-----From: "Ch= ris Lonvick" [clonvick@cisco.com]Date: 05/03/2010 06:49 AM To: "tom.petch" ,= "Joe Salowey" , "Sean Turner" CC: syslog@ietf.org 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: --832336131-1273616440=:16429 Content-transfer-encoding: quoted-printable Content-Type: text/html; charset=UTF-8 See inline marked <tievens>

-----Original Message-----
From: "tom.petch" [cfinss@dial.pipex.com]
Date: 05/08/2010 12:17 PM
To: jsalowey@cisco.com, turners@ieca.com, clonvick@cisco.com, "Tim Ev= ens"
CC: syslog@ietf.org
Subject: Re: [Syslog] AD review comments for draft-ietf-syslog-dtls
---- Original Message -----
From: "Tim Evens" <','','','');">tim@evensweb.com>;
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 fragmen= ts.

IP/UDP transport allows for IPv4 based fragmentation, even though it should= be
avoided for several reasons, there could be useful and valid application us= es
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 dire= ctly 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/PIP= E that may support a larger message size.  The application that reads t= his message may be the application that sends the messages via UDP/DTLS. &nb= sp; It would be more meaningful if the application writing the message contr= ols the truncation or if the transport application sending the message onto = the network can correctly break up the message into parts to fit the transpo= rt message size limitations.  RFC5424 doesn't detail SD elements or met= hods for splitting messages.  Transports have size constraints and will= require messages to be truncated or split.  For example, the CISCO-SYS= LOG-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 t= ransport implementer handles a message that meets RFC5424, but cannot fit wi= thin the constraints of UDP/DTLS packet size limitations.

In section 5.4.1 it states that "When mapping onto different transports, DTL= S has different record size limitations.  The application implementer S= HOULD determine the maximum record size allowed by DTLS protocol running ove= r 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 me= ssage size will always be less than MTU + transport overhead.  Am I rea= ding 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 pack= ets.
Per RFC4347 section 4.1.1, "each DTLS record MUST fit within a single datag= ram."
DTLS introduces a sequence_number field to the record layer, which facilita= tes
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 sugg= ests
that a single SYSLOG-MSG can be transferred in multiple DTLS records.

If it is optional to implement DTLS sequence numbers, how does the originat= or 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 i= t can
truncate messages prior to transmission. In lieu of truncation, the origina= tor
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 sin= gle
SYSLOG-MSG? Without a SYSLOG-FRAME identifier, the collector would have to<= br> 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 DT= LS
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" [clonvick@cisco.com= ]Date:
05/03/2010 06:49 AM
To: "tom.petch" , "Joe Salowey" , "Sean Turner" CC: syslog@ietf.org 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?<= br>
Sean, if this covers all of your edits, when can we expect to see it on th= e
IESG agenda, and when can we see IETF LC?
Thanks, Chris
On Tue, 27 Apr 2010, tom.petch wrote:

 --832336131-1273616440=:16429-- From ietfdbh@comcast.net Thu May 13 13:54:24 2010 Return-Path: X-Original-To: syslog@core3.amsl.com Delivered-To: syslog@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 080AA3A6837 for ; Thu, 13 May 2010 13:54:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.043 X-Spam-Level: X-Spam-Status: No, score=0.043 tagged_above=-999 required=5 tests=[AWL=-0.558, BAYES_50=0.001, J_CHICKENPOX_93=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cdZHMUIkbdfS for ; Thu, 13 May 2010 13:54:23 -0700 (PDT) Received: from qmta12.westchester.pa.mail.comcast.net (qmta12.westchester.pa.mail.comcast.net [76.96.59.227]) by core3.amsl.com (Postfix) with ESMTP id F37893A68F8 for ; Thu, 13 May 2010 13:54:22 -0700 (PDT) Received: from omta18.westchester.pa.mail.comcast.net ([76.96.62.90]) by qmta12.westchester.pa.mail.comcast.net with comcast id H8Ur1e0081wpRvQ5C8uE58; Thu, 13 May 2010 20:54:14 +0000 Received: from Harrington73653 ([67.189.235.106]) by omta18.westchester.pa.mail.comcast.net with comcast id H8uD1e00W2JQnJT3e8uENW; Thu, 13 May 2010 20:54:14 +0000 From: "David Harrington" To: References: <20100511192814.5BA6AE0699@rfc-editor.org> Date: Thu, 13 May 2010 16:54:11 -0400 Message-ID: <002e01caf2de$7077a070$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcrxQJJoK2f6lLp8Q3+ulJ+jNWyY7ABncj1w X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <20100511192814.5BA6AE0699@rfc-editor.org> Subject: Re: [Syslog] RFC 5848 on Signed Syslog Messages X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 May 2010 20:54:24 -0000 Congratulations! Work well done. dbh > -----Original Message----- > From: syslog-bounces@ietf.org > [mailto:syslog-bounces@ietf.org] On Behalf Of > rfc-editor@rfc-editor.org > Sent: Tuesday, May 11, 2010 3:28 PM > To: ietf-announce@ietf.org; rfc-dist@rfc-editor.org > Cc: syslog@ietf.org; rfc-editor@rfc-editor.org > Subject: [Syslog] RFC 5848 on Signed Syslog Messages > > > A new Request for Comments is now available in online RFC libraries. > > > RFC 5848 > > Title: Signed Syslog Messages > Author: J. Kelsey, J. Callas, > A. Clemm > Status: Standards Track > Stream: IETF > Date: May 2010 > Mailbox: john.kelsey@nist.gov, > jon@callas.org, > alex@cisco.com > Pages: 40 > Characters: 102805 > Updates/Obsoletes/SeeAlso: None > > I-D Tag: draft-ietf-syslog-sign-29.txt > > URL: http://www.rfc-editor.org/rfc/rfc5848.txt > > This document describes a mechanism to add origin authentication, > message integrity, replay resistance, message sequencing, and > detection of missing messages to the transmitted syslog messages. > This specification is intended to be used in conjunction with the > work defined in RFC 5424, "The Syslog Protocol". [STANDARDS TRACK] > > This document is a product of the Security Issues in Network > Event Logging Working Group of the IETF. > > This is now a Proposed Standard Protocol. > > STANDARDS TRACK: This document specifies an Internet standards track > protocol for the Internet community,and requests discussion > and suggestions > for improvements. Please refer to the current edition of the Internet > Official Protocol Standards (STD 1) for the standardization state and > status of this protocol. Distribution of this memo is unlimited. > > This announcement is sent to the IETF-Announce and rfc-dist lists. > To subscribe or unsubscribe, see > http://www.ietf.org/mailman/listinfo/ietf-announce > http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist > > For searching the RFC series, see > http://www.rfc-editor.org/rfcsearch.html. > For downloading RFCs, see http://www.rfc-editor.org/rfc.html. > > Requests for special distribution should be addressed to either the > author of the RFC in question, or to > rfc-editor@rfc-editor.org. Unless > specifically noted otherwise on the RFC itself, all RFCs are for > unlimited distribution. > > > The RFC Editor Team > Association Management Solutions, LLC > > > _______________________________________________ > Syslog mailing list > Syslog@ietf.org > https://www.ietf.org/mailman/listinfo/syslog > From clonvick@cisco.com Fri May 14 06:02:58 2010 Return-Path: X-Original-To: syslog@core3.amsl.com Delivered-To: syslog@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 239A53A69A8 for ; Fri, 14 May 2010 06:02:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.121 X-Spam-Level: X-Spam-Status: No, score=-9.121 tagged_above=-999 required=5 tests=[AWL=-0.611, BAYES_05=-1.11, J_CHICKENPOX_93=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1wmek8Py+qZ9 for ; Fri, 14 May 2010 06:02:55 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 4C3EC3A6B2D for ; Fri, 14 May 2010 06:02:55 -0700 (PDT) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAOTm7EurR7Hu/2dsb2JhbACdfnGiepk9hRAEg0A X-IronPort-AV: E=Sophos;i="4.53,229,1272844800"; d="scan'208";a="255900030" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-2.cisco.com with ESMTP; 14 May 2010 13:02:46 +0000 Received: from sjc-cde-011.cisco.com (sjc-cde-011.cisco.com [171.69.16.68]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o4ED2kPn009602; Fri, 14 May 2010 13:02:46 GMT Date: Fri, 14 May 2010 06:02:45 -0700 (PDT) From: Chris Lonvick To: David Harrington , syslog@ietf.org In-Reply-To: <002e01caf2de$7077a070$0600a8c0@china.huawei.com> Message-ID: References: <20100511192814.5BA6AE0699@rfc-editor.org> <002e01caf2de$7077a070$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: Re: [Syslog] RFC 5848 on Signed Syslog Messages X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 May 2010 13:02:58 -0000 Hi Folks, Let me add my congratulations to this as well. :-) Many Thanks, Chris On Thu, 13 May 2010, David Harrington wrote: > Congratulations! > Work well done. > > dbh > >> -----Original Message----- >> From: syslog-bounces@ietf.org >> [mailto:syslog-bounces@ietf.org] On Behalf Of >> rfc-editor@rfc-editor.org >> Sent: Tuesday, May 11, 2010 3:28 PM >> To: ietf-announce@ietf.org; rfc-dist@rfc-editor.org >> Cc: syslog@ietf.org; rfc-editor@rfc-editor.org >> Subject: [Syslog] RFC 5848 on Signed Syslog Messages >> >> >> A new Request for Comments is now available in online RFC libraries. >> >> >> RFC 5848 >> >> Title: Signed Syslog Messages >> Author: J. Kelsey, J. Callas, >> A. Clemm >> Status: Standards Track >> Stream: IETF >> Date: May 2010 >> Mailbox: john.kelsey@nist.gov, >> jon@callas.org, >> alex@cisco.com >> Pages: 40 >> Characters: 102805 >> Updates/Obsoletes/SeeAlso: None >> >> I-D Tag: draft-ietf-syslog-sign-29.txt >> >> URL: http://www.rfc-editor.org/rfc/rfc5848.txt >> >> This document describes a mechanism to add origin authentication, >> message integrity, replay resistance, message sequencing, and >> detection of missing messages to the transmitted syslog messages. >> This specification is intended to be used in conjunction with the >> work defined in RFC 5424, "The Syslog Protocol". [STANDARDS TRACK] >> >> This document is a product of the Security Issues in Network >> Event Logging Working Group of the IETF. >> >> This is now a Proposed Standard Protocol. >> >> STANDARDS TRACK: This document specifies an Internet standards track >> protocol for the Internet community,and requests discussion >> and suggestions >> for improvements. Please refer to the current edition of the > Internet >> Official Protocol Standards (STD 1) for the standardization state > and >> status of this protocol. Distribution of this memo is unlimited. >> >> This announcement is sent to the IETF-Announce and rfc-dist lists. >> To subscribe or unsubscribe, see >> http://www.ietf.org/mailman/listinfo/ietf-announce >> http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist >> >> For searching the RFC series, see >> http://www.rfc-editor.org/rfcsearch.html. >> For downloading RFCs, see http://www.rfc-editor.org/rfc.html. >> >> Requests for special distribution should be addressed to either the >> author of the RFC in question, or to >> rfc-editor@rfc-editor.org. Unless >> specifically noted otherwise on the RFC itself, all RFCs are for >> unlimited distribution. >> >> >> The RFC Editor Team >> Association Management Solutions, LLC >> >> >> _______________________________________________ >> Syslog mailing list >> Syslog@ietf.org >> https://www.ietf.org/mailman/listinfo/syslog >> > > _______________________________________________ > Syslog mailing list > Syslog@ietf.org > https://www.ietf.org/mailman/listinfo/syslog > From alex@cisco.com Fri May 14 10:52:09 2010 Return-Path: X-Original-To: syslog@core3.amsl.com Delivered-To: syslog@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E83143A69A9 for ; Fri, 14 May 2010 10:52:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_93=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IZSsZML0YinG for ; Fri, 14 May 2010 10:52:08 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 350FF3A6B81 for ; Fri, 14 May 2010 10:51:53 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAG0q7UurR7Ht/2dsb2JhbACdfnGkQJk1hRAEg0A X-IronPort-AV: E=Sophos;i="4.53,232,1272844800"; d="scan'208";a="197624585" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-5.cisco.com with ESMTP; 14 May 2010 17:51:44 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o4EHpiqx019841; Fri, 14 May 2010 17:51:44 GMT Received: from xmb-sjc-236.amer.cisco.com ([128.107.191.121]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 14 May 2010 10:51:44 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 14 May 2010 10:51:42 -0700 Message-ID: <85B2F271FDF6B949B3672BA5A7BB62FB0A20910C@xmb-sjc-236.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] RFC 5848 on Signed Syslog Messages Thread-Index: AcrzZcRQLUoYyywESl2izCyMA4gqdAAJ42Iw References: <20100511192814.5BA6AE0699@rfc-editor.org><002e01caf2de$7077a070$0600a8c0@china.huawei.com> From: "Alexander Clemm (alex)" To: "Chris Lonvick (clonvick)" , "David Harrington" , X-OriginalArrivalTime: 14 May 2010 17:51:44.0063 (UTC) FILETIME=[1D9414F0:01CAF38E] Subject: Re: [Syslog] RFC 5848 on Signed Syslog Messages X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 May 2010 17:52:10 -0000 Dave, Chris, thank you very much for your commitment, help and support - without you and so many others in the working group (e.g. Pasi's guidance, Martin's examples etc) this could not have been brought to successful conclusion --- Alex -----Original Message----- From: syslog-bounces@ietf.org [mailto:syslog-bounces@ietf.org] On Behalf Of Chris Lonvick (clonvick) Sent: Friday, May 14, 2010 6:03 AM To: David Harrington; syslog@ietf.org Subject: Re: [Syslog] RFC 5848 on Signed Syslog Messages Hi Folks, Let me add my congratulations to this as well. :-) Many Thanks, Chris On Thu, 13 May 2010, David Harrington wrote: > Congratulations! > Work well done. > > dbh > >> -----Original Message----- >> From: syslog-bounces@ietf.org >> [mailto:syslog-bounces@ietf.org] On Behalf Of >> rfc-editor@rfc-editor.org >> Sent: Tuesday, May 11, 2010 3:28 PM >> To: ietf-announce@ietf.org; rfc-dist@rfc-editor.org >> Cc: syslog@ietf.org; rfc-editor@rfc-editor.org >> Subject: [Syslog] RFC 5848 on Signed Syslog Messages >> >> >> A new Request for Comments is now available in online RFC libraries. >> >> >> RFC 5848 >> >> Title: Signed Syslog Messages >> Author: J. Kelsey, J. Callas, >> A. Clemm >> Status: Standards Track >> Stream: IETF >> Date: May 2010 >> Mailbox: john.kelsey@nist.gov, >> jon@callas.org, >> alex@cisco.com >> Pages: 40 >> Characters: 102805 >> Updates/Obsoletes/SeeAlso: None >> >> I-D Tag: draft-ietf-syslog-sign-29.txt >> >> URL: http://www.rfc-editor.org/rfc/rfc5848.txt >> >> This document describes a mechanism to add origin authentication, >> message integrity, replay resistance, message sequencing, and >> detection of missing messages to the transmitted syslog messages. >> This specification is intended to be used in conjunction with the >> work defined in RFC 5424, "The Syslog Protocol". [STANDARDS TRACK] >> >> This document is a product of the Security Issues in Network >> Event Logging Working Group of the IETF. >> >> This is now a Proposed Standard Protocol. >> >> STANDARDS TRACK: This document specifies an Internet standards track >> protocol for the Internet community,and requests discussion >> and suggestions >> for improvements. Please refer to the current edition of the > Internet >> Official Protocol Standards (STD 1) for the standardization state > and >> status of this protocol. Distribution of this memo is unlimited. >> >> This announcement is sent to the IETF-Announce and rfc-dist lists. >> To subscribe or unsubscribe, see >> http://www.ietf.org/mailman/listinfo/ietf-announce >> http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist >> >> For searching the RFC series, see >> http://www.rfc-editor.org/rfcsearch.html. >> For downloading RFCs, see http://www.rfc-editor.org/rfc.html. >> >> Requests for special distribution should be addressed to either the >> author of the RFC in question, or to >> rfc-editor@rfc-editor.org. Unless >> specifically noted otherwise on the RFC itself, all RFCs are for >> unlimited distribution. >> >> >> The RFC Editor Team >> Association Management Solutions, LLC >> >> >> _______________________________________________ >> Syslog mailing list >> Syslog@ietf.org >> https://www.ietf.org/mailman/listinfo/syslog >> > > _______________________________________________ > Syslog mailing list > Syslog@ietf.org > https://www.ietf.org/mailman/listinfo/syslog > _______________________________________________ Syslog mailing list Syslog@ietf.org https://www.ietf.org/mailman/listinfo/syslog From ietfc@btconnect.com Fri May 21 13:33:08 2010 Return-Path: X-Original-To: syslog@core3.amsl.com Delivered-To: syslog@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 87BBE3A6F33 for ; Fri, 21 May 2010 13:32:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.94 X-Spam-Level: X-Spam-Status: No, score=-0.94 tagged_above=-999 required=5 tests=[AWL=-0.941, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k04flzViYqmK for ; Fri, 21 May 2010 13:32:47 -0700 (PDT) Received: from c2beaomr08.btconnect.com (c2beaomr08.btconnect.com [213.123.26.186]) by core3.amsl.com (Postfix) with ESMTP id 58A1228C7E7 for ; Fri, 21 May 2010 10:47:12 -0700 (PDT) Received: from pc6 (host86-172-78-59.range86-172.btcentralplus.com [86.172.78.59]) by c2beaomr08.btconnect.com with SMTP id ESW09634; Fri, 21 May 2010 18:46:42 +0100 (BST) X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=0001.0A0B0302.4BF6C702.01A3, actions=tag Message-ID: <01c701caf904$d1662c40$4001a8c0@gateway.2wire.net> From: "t.petch" To: , "Chris Lonvick" References: <20100511182040.16429@web6.nyc1.bluetie.com> Date: Fri, 21 May 2010 18:37:52 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Junkmail-Status: score=10/50, host=c2beaomr08.btconnect.com X-Junkmail-SD-Raw: score=unknown, refid=str=0001.0A0B0209.4BF6C712.0194,ss=1,fgs=0, ip=0.0.0.0, so=2009-07-20 21:54:04, dmn=5.7.1/2009-08-27, mode=single engine X-Junkmail-IWF: false Cc: syslog Subject: [Syslog] AD review discuss/comments for draft-ietf-syslog-dtls X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 May 2010 20:33:56 -0000 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 Petch From rgerhards@hq.adiscon.com Sat May 22 04:37:01 2010 Return-Path: X-Original-To: syslog@core3.amsl.com Delivered-To: syslog@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA45C3A6C8C for ; Sat, 22 May 2010 04:37:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.601 X-Spam-Level: X-Spam-Status: No, score=0.601 tagged_above=-999 required=5 tests=[BAYES_50=0.001, J_CHICKENPOX_15=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dgekBHI1Qa6U for ; Sat, 22 May 2010 04:37:00 -0700 (PDT) Received: from mailin.adiscon.com (hetzner.adiscon.com [85.10.198.18]) by core3.amsl.com (Postfix) with ESMTP id 8BCE33A6C8D for ; Sat, 22 May 2010 04:36:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailin.adiscon.com (Postfix) with ESMTP id 72222241C002; Sat, 22 May 2010 10:19:57 +0200 (CEST) Received: from mailin.adiscon.com ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ow3zgS5EfTvm; Sat, 22 May 2010 10:19:57 +0200 (CEST) Received: from GRFEXC.intern.adiscon.com (pd95c774a.dip0.t-ipconnect.de [217.92.119.74]) by mailin.adiscon.com (Postfix) with ESMTP id F1E09241C001; Sat, 22 May 2010 10:19:56 +0200 (CEST) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Sat, 22 May 2010 13:36:50 +0200 Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7103E14@GRFEXC.intern.adiscon.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] AD review discuss/comments for draft-ietf-syslog-dtls Thread-Index: Acr5Phi7isl7IR7cQ7ipMB7F6TMCNwAY845w References: <20100511182040.16429@web6.nyc1.bluetie.com> <01c701caf904$d1662c40$4001a8c0@gateway.2wire.net> From: "Rainer Gerhards" To: "t.petch" , , "Chris Lonvick" Cc: syslog Subject: Re: [Syslog] AD review discuss/comments for draft-ietf-syslog-dtls X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 May 2010 11:37:01 -0000 Hi all, sorry I was offline a long time for good, but not to mention here, = reason. I will unfortunately be very partly available in the next few days. But I = would at least like to back Tom's argument. Bit first let me admit that I = could not follow the whole discussion, so I may have missed a point that actually demands a MUST. Out of the context of Tom's posting, I don't think so. In practice, there are some applications that require more than 16KB = within a single message, namely IHE and maybe some other applications that log application-data rather than system management data. In RFC5424, we = thought we have a good compromise by specifying a not-too-large to be supported = size but did not set an upper limit. This was done in the spirit that = transports should not impose any limits except if absolutely necessary. So if dtls can work with 64K (and my understanding is it can), we should permit it to use this max size. If that comes, for example, at the cost = of fragmentation and potential message loss, so be it for those = applications that need this functionality. After all, folks have been warnend = (RFC5424), but we should not limit those in need AND ready to accept the extra = risk. Speaking as an implementer, I know for sure that if some large-enough customer approaches us to support 64K messages, we will definitely do = that, if it is possible. I guess the same is true for other implementers. If = the customer needs it and wants to pay for it, one will implement it -- then = as a private extension of the standard. So looking at the real world, = removing that ability from the standard will not result in removing the = capability. The only thing that it will potentially remove is interoperability of different implementations that do it anyways... My 2cts, and once again my apologies for not being able to follow more timely. Rainer > -----Original Message----- > From: syslog-bounces@ietf.org [mailto:syslog-bounces@ietf.org] On > Behalf Of t.petch > Sent: Friday, May 21, 2010 6:38 PM > To: jsalowey@cisco.com; Chris Lonvick > Cc: syslog > Subject: [Syslog] AD review discuss/comments for = draft-ietf-syslog-dtls >=20 > I see that this I-D had entered 'Revised I-D needed' which I would = like > to > progress. >=20 > I see several comments about maximum record size, including a > suggestion that we > should make the 'SHOULD NOT' a 'MUST NOT' exceed 2**14. >=20 > 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. >=20 > Tom Petch >=20 > _______________________________________________ > Syslog mailing list > Syslog@ietf.org > https://www.ietf.org/mailman/listinfo/syslog From turners@ieca.com Sat May 22 08:16:36 2010 Return-Path: X-Original-To: syslog@core3.amsl.com Delivered-To: syslog@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B54633A6D24 for ; Sat, 22 May 2010 08:16:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.405 X-Spam-Level: X-Spam-Status: No, score=-0.405 tagged_above=-999 required=5 tests=[AWL=-0.407, BAYES_50=0.001, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wWOZXRcD9rSK for ; Sat, 22 May 2010 08:16:35 -0700 (PDT) Received: from smtp111.biz.mail.mud.yahoo.com (smtp111.biz.mail.mud.yahoo.com [209.191.68.76]) by core3.amsl.com (Postfix) with SMTP id C73DC3A6D23 for ; Sat, 22 May 2010 08:16:35 -0700 (PDT) Received: (qmail 48281 invoked from network); 22 May 2010 15:16:21 -0000 Received: from thunderfish.local (turners@96.241.2.192 with plain) by smtp111.biz.mail.mud.yahoo.com with SMTP; 22 May 2010 08:16:21 -0700 PDT X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: 1hTUWcUVM1kgV2FdV1jQLiqV3bxEAoJ2YztC.jf9NwixLkayt2gk152SclShFXshohOmFNTmggv7Mv_tYtcJhoCQouc3uaNaPBTgiiamu6vbRGZypYEpdFY_tGLn5K4ccF3AcmNnRnoxrNDidVfIwOweNmi6izJM0U1WCEpSWIOBWZVNFkXr7PZrjWl_ymuFgUTEO3yfsxyb_cV7ZkQ3orrc.4wCa3BJMK3ECoRGrtKPEoKc1MNC76jWzaHqopPLiujdG_S2EK9Ww66JTpW4BZsdiSMT4ERru3o5qRbkwghdMY_VwlrmYpU- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4BF7F544.70004@ieca.com> Date: Sat, 22 May 2010 11:16:20 -0400 From: Sean Turner User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: "t.petch" References: <20100511182040.16429@web6.nyc1.bluetie.com> <01c701caf904$d1662c40$4001a8c0@gateway.2wire.net> In-Reply-To: <01c701caf904$d1662c40$4001a8c0@gateway.2wire.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: syslog Subject: Re: [Syslog] AD review discuss/comments for draft-ietf-syslog-dtls X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 May 2010 15:16:36 -0000 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 From ietfc@btconnect.com Sat May 22 10:48:08 2010 Return-Path: X-Original-To: syslog@core3.amsl.com Delivered-To: syslog@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0279B3A6D63 for ; Sat, 22 May 2010 10:48:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.806 X-Spam-Level: X-Spam-Status: No, score=-0.806 tagged_above=-999 required=5 tests=[AWL=-0.807, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z2TGDzmVzonU for ; Sat, 22 May 2010 10:48:07 -0700 (PDT) Received: from c2beaomr01.btconnect.com (c2beaomr01.btconnect.com [213.123.26.179]) by core3.amsl.com (Postfix) with ESMTP id D87FF3A6D65 for ; Sat, 22 May 2010 10:48:06 -0700 (PDT) Received: from pc6 (host86-172-78-59.range86-172.btcentralplus.com [86.172.78.59]) by c2beaomr01.btconnect.com with SMTP id FFE57669; Sat, 22 May 2010 18:47:41 +0100 (BST) X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=0001.0A0B0302.4BF818BD.00DA, actions=tag Message-ID: <002f01caf9ce$1c28de20$4001a8c0@gateway.2wire.net> From: "t.petch" To: , "Chris Lonvick" Date: Sat, 22 May 2010 18:43:50 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Junkmail-Status: score=10/50, host=c2beaomr01.btconnect.com X-Junkmail-SD-Raw: score=unknown, refid=str=0001.0A0B0206.4BF818CA.01FF,ss=1,fgs=0, ip=0.0.0.0, so=2009-07-20 21:54:04, dmn=5.7.1/2009-08-27, mode=single engine X-Junkmail-IWF: false Cc: syslog Subject: [Syslog] AD review discuss/comments for draft-ietf-syslog-dtls - DCCP and UDP X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 May 2010 17:48:08 -0000 Another issue that came up from the IESG is the relative roles of UDP and DCCP as a substrate. In this context, the discussions on tsvwg which Lars is steering about SCTP, DCCP and UDP make interesting reading, with some contributors asserting that the only way to get a packet through a complex network is with UDP, that SCTP and DCCP are (comparative) failures that just don't get recognised widely enough. Certainly my (limited) view is that UDP is the MUST HAVE, the one that will give maximum interoperability so while DCCP is technically superior, making it the MUST implement will simply cause this I-D to be ignored by most. I haven't seen any response from Lars on this issue. Tom Petch From Pasi.Eronen@nokia.com Mon May 24 00:58:30 2010 Return-Path: X-Original-To: syslog@core3.amsl.com Delivered-To: syslog@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B08C33A6AB1 for ; Mon, 24 May 2010 00:58:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.646 X-Spam-Level: X-Spam-Status: No, score=-4.646 tagged_above=-999 required=5 tests=[AWL=-1.247, BAYES_50=0.001, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fQUep5WselfK for ; Mon, 24 May 2010 00:58:29 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 6509F3A6AA5 for ; Mon, 24 May 2010 00:58:29 -0700 (PDT) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx03.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o4O7w5c6015015; Mon, 24 May 2010 10:58:12 +0300 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 24 May 2010 10:58:11 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 24 May 2010 10:58:06 +0300 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.106]) by nok-am1mhub-02.mgdnok.nokia.com ([65.54.30.6]) with mapi; Mon, 24 May 2010 09:58:04 +0200 From: To: , Date: Mon, 24 May 2010 09:54:01 +0200 Thread-Topic: [Syslog] AD review discuss/comments for draft-ietf-syslog-dtls Thread-Index: Acr5y13nwx1KBk/MQJuf8iuF1y0JowBSugT4 Message-ID: <808FD6E27AD4884E94820BC333B2DB775BC0E09522@NOK-EUMSG-01.mgdnok.nokia.com> References: <20100511182040.16429@web6.nyc1.bluetie.com> <01c701caf904$d1662c40$4001a8c0@gateway.2wire.net>, <4BF7F544.70004@ieca.com> In-Reply-To: <4BF7F544.70004@ieca.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 24 May 2010 07:58:06.0618 (UTC) FILETIME=[D80EC7A0:01CAFB16] X-Nokia-AV: Clean Cc: syslog@ietf.org Subject: Re: [Syslog] AD review discuss/comments for draft-ietf-syslog-dtls X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 May 2010 07:58:30 -0000 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: syslog-bounces@ietf.org [syslog-bounces@ietf.org] On Behalf Of ext Se= an Turner [turners@ieca.com] 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 t= o > 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. Th= e text > in the other I-Ds is a compromise to strke a balance between this and hav= ing > 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 Syslog@ietf.org https://www.ietf.org/mailman/listinfo/syslog= From prvs=7533c0088=robert.horn@agfa.com Mon May 24 07:16:53 2010 Return-Path: X-Original-To: syslog@core3.amsl.com Delivered-To: syslog@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 58C2D3A6EA8 for ; Mon, 24 May 2010 07:16:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.399 X-Spam-Level: X-Spam-Status: No, score=-3.399 tagged_above=-999 required=5 tests=[BAYES_50=0.001, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WxyGqIUcJeoI for ; Mon, 24 May 2010 07:16:50 -0700 (PDT) Received: from mornm01-out.agfa.com (mornm01-out.agfa.com [134.54.1.75]) by core3.amsl.com (Postfix) with ESMTP id 5B0033A6EAB for ; Mon, 24 May 2010 07:16:24 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.53,291,1272837600"; d="scan'208";a="101276293" Received: from morswa037.agfa.be (HELO morswa037.be.local) ([10.232.220.21]) by mornm01-out.agfa.com with ESMTP; 24 May 2010 16:16:13 +0200 In-Reply-To: <4BF7F544.70004@ieca.com> To: turners@ieca.com MIME-Version: 1.0 Message-ID: From: robert.horn@agfa.com Date: Mon, 24 May 2010 10:13:23 -0400 Content-Type: text/plain; charset="US-ASCII" Cc: syslog Subject: Re: [Syslog] AD review discuss/comments for draft-ietf-syslog-dtls X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 May 2010 14:16:53 -0000 syslog-bounces@ietf.org wrote on 05/22/2010 11:16:20 AM: > 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. > > 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. > In this case, could the requirement be rephrased in syslog over dtls. Rather than imply that the 2**14 limit is de novo in syslog, a phrasing like "RFC 4347 limits the size of DTLS message bodies to 2**14 bytes" would be preferable. The limit will still be an issue for some parts of healthcare and this kind of phrasing points to the real source of the limit. Then, if some later version of DTLS changes that limit, the syslog over dtls would inherit that change. This would be consistent with the approach taken in syslog over UDP, where the size limits are recommendations up until the hard limit for the size of a UDP message, and it is made clear that UDP is the reason for the hard limit. Kind Regards, Robert Horn | Agfa HealthCare Research Scientist | HE/Technology Office T +1 978 897 4860 Agfa HealthCare Corporation, 100 Challenger Road, Ridgefield Park, NJ, 07660-2199, United States http://www.agfa.com/healthcare/ Click on link to read important disclaimer: http://www.agfa.com/healthcare/maildisclaimer From tim@evensweb.com Mon May 24 09:34:43 2010 Return-Path: X-Original-To: syslog@core3.amsl.com Delivered-To: syslog@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E2AA3A6C8D for ; Mon, 24 May 2010 09:34:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.09 X-Spam-Level: * X-Spam-Status: No, score=1.09 tagged_above=-999 required=5 tests=[AWL=-0.908, BAYES_50=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3uQB71tCXVJr for ; Mon, 24 May 2010 09:34:41 -0700 (PDT) Received: from outbound2.bluetie.com (outbound002.bluetie.com [206.65.164.141]) by core3.amsl.com (Postfix) with ESMTP id 6EB7A3A6C95 for ; Mon, 24 May 2010 09:34:33 -0700 (PDT) Received: from web3.nyc1.bluetie.com ([10.102.1.187]) by outbound2.bluetie.com with bizsmtp id MUaQ1e00B4258dW01UaQ2n; Mon, 24 May 2010 12:34:24 -0400 X-CMAE-Score: 0.00 X-CMAE-Analysis: v=1.1 cv=VLDqXFi0LPnZZ+UpaFydONtV6EwCqtyOMjcXCFxpMmc= c=1 sm=1 a=YtVw0_ETJMMA:10 a=uEzv4HemXiYA:10 a=o4D-YMODAAAA:8 a=48vgC7mUAAAA:8 a=YgXnU3eixpzVRjIoo1kA:9 a=k85kuYLYMqVz0j8rzhkA:7 a=dvKHR9D_t1tuwkxApRj4oIXWPFQA:4 a=QEXdDO2ut3YA:10 a=De4saq_zUVgA:10 a=lZB815dzVvQA:10 a=h_R0mb1liMR25R75:21 a=g5FJbbLiuUPSJUlI:21 a=9qxNCY_qAAAA:8 a=voZKSeMjAAAA:8 a=bvrffulIqa9TJ0fEDp4A:9 a=pNl6vOljL7ymZa_ZlC8A:7 a=XC3LlEfp6UJgoiftPRVEzpGmuTEA:4 a=_ZzulCCf0S0A:10 a=dpsC0jy_mCoA:10 a=ItR5S0iU1VMA:10 a=1pxjJC3EenQA:10 a=8I_KKyVBtz8A:10 a=LSDp6X2UVz9peDkD:21 a=lTm-q-pNKn7gLT59:21 a=ZexAb3Vcgjt8ZV0CTeya/g==:117 Received: from web3.nyc1.bluetie.com (localhost.localdomain [127.0.0.1]) by web3.nyc1.bluetie.com (Postfix) with ESMTP id D01FF30048; Mon, 24 May 2010 12:34:20 -0400 (EDT) Message-ID: <20100524123420.23843@web3.nyc1.bluetie.com> X-HTTP-Received: from tim.evensweb [24.19.97.0] by web3.nyc1.bluetie.com (BlueTie WebMail ); Mon, 24 May 2010 12:34:20 -0400 X-Mailer: BlueTie MTA Date: Mon, 24 May 2010 12:34:20 -0400 To: turners@ieca.com,ietfc@btconnect.com, Pasi.Eronen@nokia.com From: "Tim Evens" Importance: normal Content-Type: multipart/alternative; boundary="748647915-1274718860=:23843" MIME-Version: 1.0 Cc: syslog@ietf.org Subject: Re: [Syslog] AD review discuss/comments for draft-ietf-syslog-dtls X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 May 2010 16:34:43 -0000 --748647915-1274718860=:23843 Content-transfer-encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Right. =C2=A0I wrote the following a couple weeks back:"=E2=80=A6 an applica= tion may not directly write to the network where UDP/DTLS would be used as a= transport. =C2=A0 More likely, the application will write to a regular file= or FIFO/PIPE that may support a larger message size. =C2=A0The application = that reads this message may be the application that sends the messages via U= DP/DTLS. =C2=A0 It would be more meaningful if the application writing the m= essage controls the truncation or if the transport application sending the m= essage onto the network can correctly break up the message into parts to fit= the transport message size limitations. =C2=A0RFC5424 doesn't detail SD ele= ments or methods for splitting messages. =C2=A0Transports have size constrai= nts and will require messages to be truncated or split. =C2=A0For example, t= he CISCO-SYSLOG-MIB defines that a message larger than 255 characters will b= e truncated to 254 characters with a '*' as the 255th character. "To your po= int there are multiple units, but I would lump three of those units together= as "transport" units considering they all have to do with the transportatio= n of the message on the network. =C2=A0In my opinion, this draft assumes tha= t the application logging the message will some how size the message to fit = within a single DTLS record/packet. =C2=A0 This assumption is problematic, a= s mentioned above the application writing the actual SYSLOG-MSG per RFC5424 = has no way of knowing which transport is being used and what limitations tho= se transports impose. For example, in my experience and in my opinion, there= will be more than one syslog receiver/collector. =C2=A0 Remote syslog recei= vers/collectors may require different transports. =C2=A0One may use UDP/DTLS= while the other uses TCP. =C2=A0Therefore, the original syslog message of s= ay 1480 bytes may be written to the network twice, one using UDP/DTLS and th= e other using TCP. =C2=A0 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. =C2=A0=C2=A0RFC4347 (DTLS) refers to = RFC4346 (TLS 1.1 obsoleted by RFC5246 TLS 1.2) for record layer implementati= on. =C2=A0 More specifically, as defined in RFC4346 Section 6.2.1, =C2=A0"Th= e record layer fragments information blocks into TLSPlaintext=C2=A0=C2=A0 re= cords carrying data in chunks of 2^14 bytes or less. =C2=A0Client=C2=A0=C2= =A0 message boundaries are not preserved in the record layer (i.e.,=C2=A0= =C2=A0 multiple client messages of the same ContentType MAY be coalesced=C2= =A0=C2=A0 into a single TLSPlaintext record, or a single message MAY be=C2= =A0=C2=A0 fragmented across several records)."It's possible for TLS 1.1 and = 1.2 to support message block (chunks) as defined because the underlining tra= nsport is TCP providing ordered message delivery, whereas RFC4347 (DTLS) can= use UDP which does not provide ordered delivery. =C2=A0DTLS introduces a se= quence number field in the record structure, which if implemented for reorde= ring, the receiver could reorder the DTLS records so that the original messa= ge blocks are concatenated back to form the original SYSLOG-MSG. =C2=A0=C2= =A0This probably leads to why in this draft in Section 5.1 it states that wh= en using DTLS sequence numbers "=E2=80=A6 it may=C2=A0=C2=A0 not assure that= all the messages are delivered in order when mapping=C2=A0=C2=A0 on the UDP= transport."The reason is that with TCP there is a retransmission for lost s= egments, whereas UDP does not implement retransmissions. =C2=A0Therefore, if= a DTLS sequence is dropped/lost or not received within the allotted queue b= uffer time, the DTLS application doesn't have anyway of knowing if seq X1 an= d seq X3 can be correctly put together. =C2=A0How it would it know to discar= d X1 and X3 since X2 was lost? =C2=A0In either case, this too is problematic= , which leads back to why the SYSLOG-MSG will have to fit within a single DT= LS record. Thus the SYSLOG-MSG will in most cases always be less than 1460 b= ytes due to MTU DTLS/MTU limitations. =C2=A0The application SHOULD NOT assum= e 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 re= order using DTLS sequence numbers using a queue size of at least 5 or more D= TLS packets/records. =C2=A0 In addition, Section 5.4 would need a new field = in the SYSLOG-FRAME to include a FRAME-ID. =C2=A0This FRAME-ID would serve a= s a way for the DTLS implementation to know which DTLS records need to be di= scarded in the event of packet loss. =C2=A0For example:=C2=A0=C2=A0FRAME-ID = =3D NILVALUE / ("+" / "-") NONZERO-DIGIT 1*15DIGIT; uint48*=C2=A0=C2=A0 =C2= =A0 =C2=A0+/- is used to indicate more message blocks to come or not. =C2= =A0=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0"+" indicates more to follow, "-" indica= tes last block.=C2=A0=C2=A0 =C2=A0 =C2=A0Use NILVALUE if SYSLOG-MSG is not s= plit across multiple DTLS records, otherwise use=C2=A0=C2=A0=C2=A0 =C2=A0 = =C2=A0 =C2=A0first DTLS sequence number in DTLS record sequence as FRAME-ID.= =C2=A0=C2=A0 =C2=A0 =C2=A0This is an example only of a possible FRAME-ID.= =C2=A0=C2=A0 =C2=A0 =C2=A0*Instead of using 1*15DIGIT, it could be 6OCTET= =3Duint48, which would=C2=A0=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0reduce the over= all size.=C2=A0Example Use:=C2=A0=C2=A0DTLS seq 1 - SYSLOG-FRAME-ID=3D+1001 = =C2=A0=C2=A0DTLS seq 2 - SYSLOG-FRAME-ID=3D+1001 = =C2=A0=C2=A0--> dropped by network --> DTLS seq 3 - SYSLOG-FRAME-ID=3D+1001 = =C2=A0=C2=A0DTLS seq 4 - SYSLOG-FRAME-ID=3D-1001 = =C2=A0=C2=A0DTLS seq 5 - SYSLOG-FRAME-ID - =C2=A0=C2=A0DTLS seq = 6 - SYSLOG-FRAME-ID - Using a buffer/queue size of 5 DTLS record= s/packets, the DTLS implementation would have been holding DTLS seq 1, 2, an= d 4 waiting for 3. =C2=A0When 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. =C2=A0DTLS seq 5 and 6 are processed.=C2=A0Thanks,Tim-----Origi= nal Message-----From: Pasi.Eronen@nokia.comDate: 05/24/2010 04:23 AMTo: turn= ers@ieca.com, ietfc@btconnect.comCC: syslog@ietf.orgSubject: 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 bas= ic "units" of transmission. As far as I can tell, we have four different lay= ers: - a syslog message (SYSLOG-FRAME in ABNF) - a DTLS record - a UDP data= gram - 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 r= ecord 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 recor= d. 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 additio= nal restriction that I'm not sure is really mentioned anywhere: A single sys= log 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 datagra= m (so the syslog layer does not reassemble syslog message pieces from multip= le UDP datagrams -- SYSLOG-FRAME does not have sufficient information to do = this anyway). In addition to the "hard" size limits (coming from DTLS and U= DP), we probably need a recommendation saying that it's better if you can av= oid IP fragmentation -- but this is precisely the same as normal syslog-over= -UDP (minus the small overhead from DTLS). Best regards, Pasi ___________= _____________________________ From: syslog-bounces@ietf.org [syslog-bounces@= ietf.org] On Behalf Of ext Sean Turner [turners@ieca.com] Sent: Saturday, Ma= y 22, 2010 6:16 PM To: t.petch Cc: syslog Subject: Re: [Syslog] AD review di= scuss/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 65= k 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 re= sponse 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 th= at he's just asking why - he's not really requesting a change. spt ________= _______________________________________ Syslog mailing list Syslog@ietf.org = https://www.ietf.org/mailman/listinfo/syslog _______________________________= ________________ Syslog mailing list Syslog@ietf.org https://www.ietf.org/ma= ilman/listinfo/syslog = --748647915-1274718860=:23843 Content-transfer-encoding: quoted-printable Content-Type: text/html; charset=UTF-8
Right.  I wrote the following a couple weeks back:

"=E2=80=A6 an application may not directly write to the network w= here UDP/DTLS would be used as a transport.   More likely, the applicat= ion will write to a regular file or FIFO/PIPE that may support a larger mess= age size.  The application that reads this message may be the applicati= on that sends the messages via UDP/DTLS.   It would be more meaningful = if the application writing the message controls the truncation or if the tra= nsport application sending the message onto the network can correctly break = up the message into parts to fit the transport message size limitations. &nb= sp;RFC5424 doesn't detail SD elements or methods for splitting messages. &nb= sp;Transports have size constraints and will require messages to be truncate= d or split.  For example, the CISCO-SYSLOG-MIB defines that a message l= arger 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 w= ith the transportation of the message on the network.  

In my opinion, this draft assumes that the application logging th= e message will some how size the message to fit within a single DTLS record/= packet.   This assumption is problematic, as mentioned above the applic= ation writing the actual SYSLOG-MSG per RFC5424 has no way of knowing which = transport is being used and what limitations those transports impose. For ex= ample, in my experience and in my opinion, there will be more than one syslo= g receiver/collector.   Remote syslog receivers/collectors may require = different transports.  One may use UDP/DTLS while the other uses TCP. &= nbsp;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.   Th= e 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 li= mitations.   

RFC4347 (DTLS) refers to RFC4346 (TLS 1.1 obsoleted by RFC5246 TL= S 1.2) for record layer implementation.   More specifically, as defined= in RFC4346 Section 6.2.1,  "The record layer fragments information blo= cks into TLSPlaintext
   records carrying data in chunks= of 2^14 bytes or less.  Client
   message boundari= es are not preserved in the record layer (i.e.,
   multi= ple client messages of the same ContentType MAY be coalesced
 = ;  into a single TLSPlaintext record, or a single message MAY be
<= div>   fragmented across several records)."

It's possible for TLS 1.1 and 1.2 to support message block (chunk= s) as defined because the underlining transport is TCP providing ordered mes= sage delivery, whereas RFC4347 (DTLS) can use UDP which does not provide ord= ered delivery.  DTLS introduces a sequence number field in the record s= tructure, which if implemented for reordering, the receiver could reorder th= e 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 "=E2=80=A6 it may
 &nb= sp; 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 se= gments, whereas UDP does not implement retransmissions.  Therefore, if = a DTLS sequence is dropped/lost or not received within the allotted queue bu= ffer 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 DTL= S record. Thus the SYSLOG-MSG will in most cases always be less than 1460 by= tes due to MTU DTLS/MTU limitations.  The application SHOULD NOT assume= that using the RFC5424 recommended minimum of 480 octets is sufficient as t= he IPv4 MTU still can be less than that.

I believe that this could be solved if this draft were to be upda= ted to require that the DTLS implementation reorder using DTLS sequence numb= ers 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 implement= ation to know which DTLS records need to be discarded in the event of packet= loss.  

For example:

  FRAME-ID =3D NILVALUE / ("+" / "-") NONZERO-DIGIT 1*1= 5DIGIT; uint48*

      +/- is used to indicate more message bl= ocks to come or not.  
        "+" i= ndicates more to follow, "-" indicates last block.

      Use NILVALUE if SYSLOG-MSG is not split= across multiple DTLS records, otherwise use 
   &n= bsp;    first DTLS sequence number in DTLS record sequence as FRAM= E-ID.

      This is an example only of a possible F= RAME-ID.

      *Instead of using 1*15DIGIT, it could b= e 6OCTET=3Duint48, which would 
       &n= bsp;reduce the overall size.

 Example Use:

  DTLS seq 1 - SYSLOG-FRAME-ID=3D+1001 <SYSLOG-MSG&g= t;
  DTLS seq 2 - SYSLOG-FRAME-ID=3D+1001 <SYSLOG-MSG= >
  --> dropped by network --> DTLS seq 3 - SYS= LOG-FRAME-ID=3D+1001 <SYSLOG-MSG>
  DTLS seq 4 - S= YSLOG-FRAME-ID=3D-1001 <SYSLOG-MSG>
  DTLS seq 5 -= SYSLOG-FRAME-ID - <SYSLOG-MSG>
  DTLS seq 6 - SYS= LOG-FRAME-ID - <SYSLOG-MSG>

Using a buffer/queue size of 5 DTLS records/packets, the DTLS imp= lementation would have been holding DTLS seq 1, 2, and 4 waiting for 3. &nbs= p;When it received seq 5 and 6, it reaches its buffer size and therefore dis= cards 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: Pasi.Eronen@nokia.com
Date: 05/24/2010 04:23 AM
To: turners@ieca.com, ietfc@btconnect.com
CC: syslog@ietf.org
Subject: Re: [Syslog] AD review discuss/comments for draft-ietf-syslo= g-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: syslog-bounces@ietf.org [syslog-bounces@ietf.or= g] On Behalf Of ext Sean Turner [turners@ieca.com]
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 lik= e to
> progress.
>
> I see several comments about maximum record size, including a suggesti= on 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 o= n, 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
Syslog@ietf.org
= https://www.ietf.org/mailman/listinfo/syslog
_______________________________________________
Syslog mailing list
Syslog@ietf.org
= https://www.ietf.org/mailman/listinfo/syslog

= --748647915-1274718860=:23843-- From ietfc@btconnect.com Mon May 24 10:39:16 2010 Return-Path: X-Original-To: syslog@core3.amsl.com Delivered-To: syslog@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C58833A6C9E for ; Mon, 24 May 2010 10:39:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.405 X-Spam-Level: X-Spam-Status: No, score=-0.405 tagged_above=-999 required=5 tests=[AWL=-1.006, BAYES_50=0.001, J_CHICKENPOX_15=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f0BPyiavk3MM for ; Mon, 24 May 2010 10:39:15 -0700 (PDT) Received: from c2beaomr09.btconnect.com (c2beaomr09.btconnect.com [213.123.26.187]) by core3.amsl.com (Postfix) with ESMTP id 9CDE63A6C44 for ; Mon, 24 May 2010 10:39:15 -0700 (PDT) Received: from pc6 (host86-172-78-59.range86-172.btcentralplus.com [86.172.78.59]) by c2beaomr09.btconnect.com with SMTP id ERZ17117; Mon, 24 May 2010 18:38:44 +0100 (BST) X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=0001.0A0B0301.4BFAB9A4.01F6, actions=tag Message-ID: <00ab01cafb5f$2fece680$4001a8c0@gateway.2wire.net> From: "t.petch" To: "Sean Turner" References: <20100511182040.16429@web6.nyc1.bluetie.com> <01c701caf904$d1662c40$4001a8c0@gateway.2wire.net> <4BF7F544.70004@ieca.com> Date: Mon, 24 May 2010 18:35:40 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Junkmail-Status: score=10/50, host=c2beaomr09.btconnect.com X-Junkmail-SD-Raw: score=unknown, refid=str=0001.0A0B0207.4BFAB9B2.01C2,ss=1,fgs=0, ip=0.0.0.0, so=2009-07-20 21:54:04, dmn=5.7.1/2009-08-27, mode=single engine X-Junkmail-IWF: false Cc: syslog Subject: Re: [Syslog] AD review discuss/comments for draft-ietf-syslog-dtls X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 May 2010 17:39:16 -0000 ----- Original Message ----- From: "Sean Turner" To: "t.petch" Cc: ; "Chris Lonvick" ; "syslog" Sent: Saturday, May 22, 2010 5:16 PM 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. Sean Right, but after Alexey's comment there was one from Joe saying "let's make this change it seems reasonable", so my reaction was, no, this is not reasonable! We may want to tinker with the text, but a "MUST NOT exceed 2**14" I see as going too far. Tom Petch > spt From ietfdbh@comcast.net Mon May 24 11:38:54 2010 Return-Path: X-Original-To: syslog@core3.amsl.com Delivered-To: syslog@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA9023A7175 for ; Mon, 24 May 2010 11:38:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.136 X-Spam-Level: ** X-Spam-Status: No, score=2.136 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FRT_STRONG2=1.535, J_CHICKENPOX_15=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gxdnuZP3OvJl for ; Mon, 24 May 2010 11:38:54 -0700 (PDT) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [76.96.62.48]) by core3.amsl.com (Postfix) with ESMTP id 2D2E63A6FDC for ; Mon, 24 May 2010 11:34:41 -0700 (PDT) Received: from omta16.westchester.pa.mail.comcast.net ([76.96.62.88]) by qmta05.westchester.pa.mail.comcast.net with comcast id MPhZ1e0031uE5Es55WaahJ; Mon, 24 May 2010 18:34:34 +0000 Received: from Harrington73653 ([207.59.110.215]) by omta16.westchester.pa.mail.comcast.net with comcast id MWaE1e00G4eszMr3cWaK5A; Mon, 24 May 2010 18:34:32 +0000 From: "David Harrington" To: "'t.petch'" , , "'Chris Lonvick'" References: <002f01caf9ce$1c28de20$4001a8c0@gateway.2wire.net> Date: Mon, 24 May 2010 14:34:12 -0400 Message-ID: <093e01cafb6f$bf41c2a0$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <002f01caf9ce$1c28de20$4001a8c0@gateway.2wire.net> Thread-Index: Acr53DDHyOvFQXIhTZCZb1hCmtLy2gBkxFew X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Cc: 'syslog' Subject: Re: [Syslog] AD review discuss/comments for draft-ietf-syslog-dtls -DCCP and UDP X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 May 2010 18:38:54 -0000 Hi, Lars provided advice quite a while back. I concur with his advice. Implementers MUST implement support for DCCP (which should require minimal changes from support for UDP), so that if DCCP is available, and the operator chooses to use DCCPP, the implementation will work with DCCP. I view this as very similar to our standard security posture - stroing security is MUST implement, so it is available if the operator wants it. The operator is not required to use it. dbh > -----Original Message----- > From: syslog-bounces@ietf.org > [mailto:syslog-bounces@ietf.org] On Behalf Of t.petch > Sent: Saturday, May 22, 2010 12:44 PM > To: jsalowey@cisco.com; Chris Lonvick > Cc: syslog > Subject: [Syslog] AD review discuss/comments for > draft-ietf-syslog-dtls -DCCP and UDP > > Another issue that came up from the IESG is the relative > roles of UDP and DCCP > as a substrate. In this context, the discussions on tsvwg > which Lars is > steering about SCTP, DCCP and UDP make interesting reading, with some > contributors asserting that the only way to get a packet > through a complex > network is with UDP, that SCTP and DCCP are (comparative) > failures that just > don't get recognised widely enough. > > Certainly my (limited) view is that UDP is the MUST HAVE, the > one that will give > maximum interoperability so while DCCP is technically > superior, making it the > MUST implement will simply cause this I-D to be ignored by most. > > I haven't seen any response from Lars on this issue. > > Tom Petch > > _______________________________________________ > Syslog mailing list > Syslog@ietf.org > https://www.ietf.org/mailman/listinfo/syslog > From ietfdbh@comcast.net Mon May 24 20:39:29 2010 Return-Path: X-Original-To: syslog@core3.amsl.com Delivered-To: syslog@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F25A33A692B for ; Mon, 24 May 2010 20:39:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.136 X-Spam-Level: ** X-Spam-Status: No, score=2.136 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FRT_STRONG2=1.535, J_CHICKENPOX_15=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d2kmQQWEhFl6 for ; Mon, 24 May 2010 20:39:28 -0700 (PDT) Received: from qmta15.emeryville.ca.mail.comcast.net (qmta15.emeryville.ca.mail.comcast.net [76.96.27.228]) by core3.amsl.com (Postfix) with ESMTP id 0EDB23A67EE for ; Mon, 24 May 2010 20:39:28 -0700 (PDT) Received: from omta04.emeryville.ca.mail.comcast.net ([76.96.30.35]) by qmta15.emeryville.ca.mail.comcast.net with comcast id MY5P1e0060lTkoCAFffMpA; Tue, 25 May 2010 03:39:21 +0000 Received: from Harrington73653 ([207.59.110.215]) by omta04.emeryville.ca.mail.comcast.net with comcast id Mfey1e0024eszMr8Qff35B; Tue, 25 May 2010 03:39:19 +0000 From: "David Harrington" To: "'t.petch'" , , "'Chris Lonvick'" References: <002f01caf9ce$1c28de20$4001a8c0@gateway.2wire.net> Date: Mon, 24 May 2010 23:38:56 -0400 Message-ID: <093f01cafbbb$da81b470$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <002f01caf9ce$1c28de20$4001a8c0@gateway.2wire.net> Thread-Index: Acr53DDHyOvFQXIhTZCZb1hCmtLy2gBkxFew X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Cc: 'syslog' Subject: Re: [Syslog] AD review discuss/comments for draft-ietf-syslog-dtls -DCCP and UDP X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 May 2010 03:39:29 -0000 Hi, Lars provided advice quite a while back. I concur with his advice. Implementers MUST implement support for DCCP (which should require minimal changes from support for UDP), so that if DCCP is available, and the operator chooses to use DCCPP, the implementation will work with DCCP. I view this as very similar to our standard security posture - stroing security is MUST implement, so it is available if the operator wants it. The operator is not required to use it. dbh > -----Original Message----- > From: syslog-bounces@ietf.org > [mailto:syslog-bounces@ietf.org] On Behalf Of t.petch > Sent: Saturday, May 22, 2010 12:44 PM > To: jsalowey@cisco.com; Chris Lonvick > Cc: syslog > Subject: [Syslog] AD review discuss/comments for > draft-ietf-syslog-dtls -DCCP and UDP > > Another issue that came up from the IESG is the relative > roles of UDP and DCCP > as a substrate. In this context, the discussions on tsvwg > which Lars is > steering about SCTP, DCCP and UDP make interesting reading, with some > contributors asserting that the only way to get a packet > through a complex > network is with UDP, that SCTP and DCCP are (comparative) > failures that just > don't get recognised widely enough. > > Certainly my (limited) view is that UDP is the MUST HAVE, the > one that will give > maximum interoperability so while DCCP is technically > superior, making it the > MUST implement will simply cause this I-D to be ignored by most. > > I haven't seen any response from Lars on this issue. > > Tom Petch > > _______________________________________________ > Syslog mailing list > Syslog@ietf.org > https://www.ietf.org/mailman/listinfo/syslog > From Pasi.Eronen@nokia.com Tue May 25 02:46:10 2010 Return-Path: X-Original-To: syslog@core3.amsl.com Delivered-To: syslog@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 367133A6B1C for ; Tue, 25 May 2010 02:46:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.532 X-Spam-Level: X-Spam-Status: No, score=-4.532 tagged_above=-999 required=5 tests=[AWL=-1.134, BAYES_50=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j-ArcKVRbgiU for ; Tue, 25 May 2010 02:46:05 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id C02DE3A699E for ; Tue, 25 May 2010 02:46:04 -0700 (PDT) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx09.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o4P9jaDM003369; Tue, 25 May 2010 04:45:47 -0500 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 25 May 2010 12:44:43 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.7]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 25 May 2010 12:44:38 +0300 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.106]) by nok-am1mhub-03.mgdnok.nokia.com ([65.54.30.7]) with mapi; Tue, 25 May 2010 11:44:38 +0200 From: To: , , Date: Tue, 25 May 2010 11:44:37 +0200 Thread-Topic: [Syslog] AD review discuss/comments for draft-ietf-syslog-dtls Thread-Index: Acr7Xv4UaRnZCuTaTWeKt3W1jTmfqwAjw8wv Message-ID: <808FD6E27AD4884E94820BC333B2DB775BC0E09528@NOK-EUMSG-01.mgdnok.nokia.com> References: <20100524123420.23843@web3.nyc1.bluetie.com> In-Reply-To: <20100524123420.23843@web3.nyc1.bluetie.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_808FD6E27AD4884E94820BC333B2DB775BC0E09528NOKEUMSG01mgd_" MIME-Version: 1.0 X-OriginalArrivalTime: 25 May 2010 09:44:38.0321 (UTC) FILETIME=[E4390210:01CAFBEE] X-Nokia-AV: Clean Cc: syslog@ietf.org Subject: Re: [Syslog] AD review discuss/comments for draft-ietf-syslog-dtls X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 May 2010 09:46:10 -0000 --_000_808FD6E27AD4884E94820BC333B2DB775BC0E09528NOKEUMSG01mgd_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I would prefer to keep syslog-over-DTLS-over-UDP as similar to RFC 5246 (sy= slog-over-UDP) as possible -- i.e. don't add any kind of fragmentation/reassembly in syslo= g 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 [tim@evensweb.com] Sent: Monday, May 24, 2010 7:34 PM To: turners@ieca.com; ietfc@btconnect.com; Eronen Pasi (Nokia-NRC/Helsinki) Cc: syslog@ietf.org Subject: Re: [Syslog] AD review discuss/comments for draft-ietf-syslog-dtls Right. I wrote the following a couple weeks back: "=85 an application may not directly write to the network where UDP/DTLS wo= uld 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 appl= ication that reads this message may be the application that sends the messa= ges 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 constrain= ts and will require messages to be truncated or split. For example, the CI= SCO-SYSLOG-MIB defines that a message larger than 255 characters will be tr= uncated to 254 characters with a '*' as the 255th character. " To your point there are multiple units, but I would lump three of those uni= ts together as "transport" units considering they all have to do with the t= ransportation 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 m= y experience and in my opinion, there will be more than one syslog receiver= /collector. Remote syslog receivers/collectors may require different tran= sports. One may use UDP/DTLS while the other uses TCP. Therefore, the ori= ginal 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 transpor= ted using TCP will be receive in full without any issues, while the one wit= h 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 Se= ction 6.2.1, "The record layer fragments information blocks into TLSPlaint= ext 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 defi= ned because the underlining transport is TCP providing ordered message deli= very, whereas RFC4347 (DTLS) can use UDP which does not provide ordered del= ivery. DTLS introduces a sequence number field in the record structure, wh= ich if implemented for reordering, the receiver could reorder the DTLS reco= rds so that the original message blocks are concatenated back to form the o= riginal SYSLOG-MSG. This probably leads to why in this draft in Section 5.1 it states that when= using DTLS sequence numbers "=85 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, wh= ereas UDP does not implement retransmissions. Therefore, if a DTLS sequenc= e is dropped/lost or not received within the allotted queue buffer time, th= e 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 DTL= S/MTU limitations. The application SHOULD NOT assume that using the RFC542= 4 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 req= uire that the DTLS implementation reorder using DTLS sequence numbers using= a queue size of at least 5 or more DTLS packets/records. In addition, Se= ction 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 wh= ich DTLS records need to be discarded in the event of packet loss. For example: FRAME-ID =3D 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=3Duint48, which would reduce the overall size. Example Use: DTLS seq 1 - SYSLOG-FRAME-ID=3D+1001 DTLS seq 2 - SYSLOG-FRAME-ID=3D+1001 --> dropped by network --> DTLS seq 3 - SYSLOG-FRAME-ID=3D+1001 DTLS seq 4 - SYSLOG-FRAME-ID=3D-1001 DTLS seq 5 - SYSLOG-FRAME-ID - DTLS seq 6 - SYSLOG-FRAME-ID - Using a buffer/queue size of 5 DTLS records/packets, the DTLS implementatio= n would have been holding DTLS seq 1, 2, and 4 waiting for 3. When it rece= ived seq 5 and 6, it reaches its buffer size and therefore discards DTLS se= q 1,2,4 since they all have SYSLOG-FRAME-ID of 1001. DTLS seq 5 and 6 are = processed. Thanks, Tim -----Original Message----- From: Pasi.Eronen@nokia.com Date: 05/24/2010 04:23 AM To: turners@ieca.com, ietfc@btconnect.com CC: syslog@ietf.org 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: syslog-bounces@ietf.org [syslog-bounces@ietf.org] On Behalf Of ext Sean Turner [turners@ieca.com] 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 t= o > 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, t= o > allow 65k messages, and I think it wrong to MUST NOT that requirement. Th= e text > in the other I-Ds is a compromise to strke a balance between this and hav= ing > 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 Syslog@ietf.org https://www.ietf.org/mailman/listinfo/syslog _______________________________________________ Syslog mailing list Syslog@ietf.org https://www.ietf.org/mailman/listinfo/syslog --_000_808FD6E27AD4884E94820BC333B2DB775BC0E09528NOKEUMSG01mgd_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
I would prefer to keep syslog-over-DTLS-over-UDP as similar to RFC 524= 6 (syslog-over-UDP)
as possible -- i.e. don't add any kin= d of fragmentation/reassembly in syslog layer.
Both syslog-over-UDP and syslog-over-= DTLS-over-UDP already support messages up
to ~64K; they'r= e just not very efficient if your MTU is small (and you need IP layer fragm= entation).
But for adminis= trators that know they'll need efficient transport of = large messages, we already
have a solution: RFC 5425.

Best regards,
Pasi
=  
From: ext Tim Eve= ns [tim@evensweb.com]
Sent: Monday, May 24, 2010 7:34 PM
To: turners@ieca.com; ietfc@btconnect.com; Eronen Pasi (Nokia-NRC/He= lsinki)
Cc: syslog@ietf.org
Subject: Re: [Syslog] AD review discuss/comments for draft-ietf-sysl= og-dtls

Right.  I wrote the following a couple weeks back:

"=85 an application may not directly write to the network where U= DP/DTLS would be used as a transport.   More likely, the application w= ill 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 wou= ld be more meaningful if the application writing the message controls the t= runcation or if the transport application sending the message onto the netw= ork can correctly break up the message into parts to fit the transport message size limitations.  RFC5424 do= esn't detail SD elements or methods for splitting messages.  Transport= s 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 charact= ers with a '*' as the 255th character. "

To your point there are multiple units, but I would lump three of thos= e units together as "transport" units considering they all have t= o do with the transportation of the message on the network.  

In my opinion, this draft assumes that the application logging the mes= sage will some how size the message to fit within a single DTLS record/pack= et.   This assumption is problematic, as mentioned above the applicati= on writing the actual SYSLOG-MSG per RFC5424 has no way of knowing which transport is being used and what limit= ations those transports impose. For example, in my experience and in my opi= nion, 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 writ= ten 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 t= o 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 b= locks into TLSPlaintext
   records carrying data in chunks of 2^14 bytes or less. &n= bsp;Client
   message boundaries are not preserved in the record layer = (i.e.,
   multiple client messages of the same ContentType MAY be c= oalesced
   into a single TLSPlaintext record, or a single message MA= Y 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 ordere= d 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 b= locks 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 "=85 it may
   not assure that all the messages are delivered in order w= hen mapping
   on the UDP transport."

The reason is that with TCP there is a retransmission for lost segment= s, whereas UDP does not implement retransmissions.  Therefore, if a DT= LS sequence is dropped/lost or not received within the allotted queue buffe= r 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?  I= n 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 by= tes due to MTU DTLS/MTU limitations.  The application SHOULD NOT assum= e 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 t= o require that the DTLS implementation reorder using DTLS sequence numbers = using a queue size of at least 5 or more DTLS packets/records.   In ad= dition, 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 =3D NILVALUE / ("+" / "-"= ) NONZERO-DIGIT 1*15DIGIT; uint48*

      +/- is used to indicate more message blo= cks to come or not.  
        "+" indicates more to f= ollow, "-" indicates last block.

      Use NILVALUE if SYSLOG-MSG is not split acro= ss multiple DTLS records, otherwise use 
        first DTLS sequence number in DTLS re= cord sequence as FRAME-ID.

      This is an example only of a possible FRAME-= ID.

      *Instead of using 1*15DIGIT, it could be 6OC= TET=3Duint48, which would 
        reduce the overall size.

 Example Use:

  DTLS seq 1 - SYSLOG-FRAME-ID=3D+1001 <SYSLOG-MSG>= ;
  DTLS seq 2 - SYSLOG-FRAME-ID=3D+1001 <SYSLOG-MSG>= ;
  --> dropped by network --> DTLS seq 3 - SYSLOG-FRAME= -ID=3D+1001 <SYSLOG-MSG>
  DTLS seq 4 - SYSLOG-FRAME-ID=3D-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 implemen= tation would have been holding DTLS seq 1, 2, and 4 waiting for 3.  Wh= en it received seq 5 and 6, it reaches its buffer size and therefore discar= ds 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: Pasi.Eronen@nokia.com
Date: 05/24/2010 04:23 AM
To: turners@ieca.com, ietfc@btconnect.com
CC: syslog@ietf.org
Subject: Re: [Syslog] AD review discuss/comments for draft-ietf-sysl= og-dtls


I haven't followed this discussion in detail, but it looks like
there's some confusion about the basic "units" of transmission. A= s 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: syslog-bounces@ietf.org [syslog-bounces@ietf.org] On Be= half Of ext Sean Turner [turners@ieca.com]
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 lik= e to
> progress.
>
> I see several comments about maximum record size, including a suggesti= on 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
Syslog@ietf.org
= https://www.ietf.org/mailman/listinfo/syslog
_______________________________________________
Syslog mailing list
Syslog@ietf.org
= https://www.ietf.org/mailman/listinfo/syslog

--_000_808FD6E27AD4884E94820BC333B2DB775BC0E09528NOKEUMSG01mgd_-- From ietfc@btconnect.com Tue May 25 03:35:59 2010 Return-Path: X-Original-To: syslog@core3.amsl.com Delivered-To: syslog@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 42D3B3A707D for ; Tue, 25 May 2010 03:35:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.293 X-Spam-Level: X-Spam-Status: No, score=-0.293 tagged_above=-999 required=5 tests=[AWL=-0.894, BAYES_50=0.001, J_CHICKENPOX_15=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UejPimMcFwCH for ; Tue, 25 May 2010 03:35:58 -0700 (PDT) Received: from c2bthomr14.btconnect.com (c2bthomr14.btconnect.com [213.123.20.132]) by core3.amsl.com (Postfix) with ESMTP id EE73A3A6DEA for ; Tue, 25 May 2010 03:35:57 -0700 (PDT) Received: from pc6 (host86-172-78-59.range86-172.btcentralplus.com [86.172.78.59]) by c2bthomr14.btconnect.com with SMTP id FKZ78477; Tue, 25 May 2010 11:35:40 +0100 (BST) X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=0001.0A0B0302.4BFBA7FB.035F, actions=tag Message-ID: <000b01cafbed$37c29380$4001a8c0@gateway.2wire.net> From: "t.petch" To: , References: <20100511182040.16429@web6.nyc1.bluetie.com><01c701caf904$d1662c40$4001a8c0@gateway.2wire.net>, <4BF7F544.70004@ieca.com> <808FD6E27AD4884E94820BC333B2DB775BC0E09522@NOK-EUMSG-01.mgdnok.nokia.com> Date: Tue, 25 May 2010 11:31:07 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Junkmail-Status: score=10/50, host=c2bthomr14.btconnect.com X-Junkmail-SD-Raw: score=unknown, refid=str=0001.0A0B020A.4BFBA7FE.03EC,ss=1,fgs=0, ip=0.0.0.0, so=2009-07-20 21:54:04, dmn=5.7.1/2009-08-27, mode=single engine X-Junkmail-IWF: false Cc: syslog@ietf.org Subject: Re: [Syslog] AD review discuss/comments for draft-ietf-syslog-dtls X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 May 2010 10:35:59 -0000 ---- Original Message ----- From: To: ; Cc: Sent: Monday, May 24, 2010 9:54 AM 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). 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. Tom Petch 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: syslog-bounces@ietf.org [syslog-bounces@ietf.org] On Behalf Of ext Sean Turner [turners@ieca.com] 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 Syslog@ietf.org https://www.ietf.org/mailman/listinfo/syslog= From Pasi.Eronen@nokia.com Tue May 25 03:54:49 2010 Return-Path: X-Original-To: syslog@core3.amsl.com Delivered-To: syslog@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B1D63A7044 for ; Tue, 25 May 2010 03:54:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.738 X-Spam-Level: X-Spam-Status: No, score=-5.738 tagged_above=-999 required=5 tests=[AWL=0.261, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nfsokZLKUDqj for ; Tue, 25 May 2010 03:54:48 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 259C23A705A for ; Tue, 25 May 2010 03:54:47 -0700 (PDT) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx03.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o4PAsCil026962; Tue, 25 May 2010 13:54:34 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 25 May 2010 13:53:43 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.5]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 25 May 2010 13:53:43 +0300 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.106]) by nok-am1mhub-01.mgdnok.nokia.com ([65.54.30.5]) with mapi; Tue, 25 May 2010 12:53:43 +0200 From: To: , Date: Tue, 25 May 2010 12:53:42 +0200 Thread-Topic: [Syslog] AD review discuss/comments for draft-ietf-syslog-dtls Thread-Index: Acr79hJa9wBDkSu1RLaOgW8JblkkpgAAWRwo Message-ID: <808FD6E27AD4884E94820BC333B2DB775BC0E09529@NOK-EUMSG-01.mgdnok.nokia.com> References: <20100511182040.16429@web6.nyc1.bluetie.com><01c701caf904$d1662c40$4001a8c0@gateway.2wire.net>, <4BF7F544.70004@ieca.com> <808FD6E27AD4884E94820BC333B2DB775BC0E09522@NOK-EUMSG-01.mgdnok.nokia.com>, <000b01cafbed$37c29380$4001a8c0@gateway.2wire.net> In-Reply-To: <000b01cafbed$37c29380$4001a8c0@gateway.2wire.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 25 May 2010 10:53:43.0923 (UTC) FILETIME=[8B31AC30:01CAFBF8] X-Nokia-AV: Clean Cc: syslog@ietf.org Subject: Re: [Syslog] AD review discuss/comments for draft-ietf-syslog-dtls X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 May 2010 10:54:49 -0000 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=20 DTLS records are then combined to a single UDP datagram. Best regards, Pasi ________________________________________ From: ext t.petch [ietfc@btconnect.com] Sent: Tuesday, May 25, 2010 12:31 PM To: Eronen Pasi (Nokia-NRC/Helsinki); turners@ieca.com Cc: syslog@ietf.org Subject: Re: [Syslog] AD review discuss/comments for draft-ietf-syslog-dtls ---- Original Message ----- From: To: ; Cc: Sent: Monday, May 24, 2010 9:54 AM 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). 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. Tom Petch 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: syslog-bounces@ietf.org [syslog-bounces@ietf.org] On Behalf Of ext Se= an Turner [turners@ieca.com] 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 t= o > 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. Th= e text > in the other I-Ds is a compromise to strke a balance between this and hav= ing > 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 Syslog@ietf.org https://www.ietf.org/mailman/listinfo/syslog=3D= From ietfc@btconnect.com Tue May 25 06:26:56 2010 Return-Path: X-Original-To: syslog@core3.amsl.com Delivered-To: syslog@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4190D3A70D2 for ; Tue, 25 May 2010 06:26:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[AWL=-0.505, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tZwD1KB3r+t2 for ; Tue, 25 May 2010 06:26:55 -0700 (PDT) Received: from c2beaomr03.btconnect.com (c2beaomr03.btconnect.com [213.123.26.181]) by core3.amsl.com (Postfix) with ESMTP id 0905D3A70F6 for ; Tue, 25 May 2010 06:26:54 -0700 (PDT) Received: from pc6 (host86-172-78-59.range86-172.btcentralplus.com [86.172.78.59]) by c2beaomr03.btconnect.com with SMTP id LZE20177; Tue, 25 May 2010 14:26:38 +0100 (BST) X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=0001.0A0B0301.4BFBD00D.03B0, actions=tag Message-ID: <017101cafc05$1a752000$4001a8c0@gateway.2wire.net> From: "t.petch" To: "t.petch" , References: <20100511182040.16429@web6.nyc1.bluetie.com><01c701caf904$d1662c40$4001a8c0@gateway.2wire.net>, <4BF7F544.70004@ieca.com><808FD6E27AD4884E94820BC333B2DB775BC0E09522@NOK-EUMSG-01.mgdnok.nokia.com> <000b01cafbed$37c29380$4001a8c0@gateway.2wire.net> Date: Tue, 25 May 2010 14:19:17 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Junkmail-Status: score=10/50, host=c2beaomr03.btconnect.com X-Junkmail-SD-Raw: score=unknown, refid=str=0001.0A0B0207.4BFBD010.0027,ss=1,fgs=0, ip=0.0.0.0, so=2009-07-20 21:54:04, dmn=5.7.1/2009-08-27, mode=single engine X-Junkmail-IWF: false Cc: syslog@ietf.org Subject: [Syslog] AD review discuss/comments for draft-ietf-syslog-dtls - NULL X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 May 2010 13:26:56 -0000 Another outstanding issue is the question of NULL options in the ciphersuites with Tim Polk suggesting something along the lines of OLD: Implementations MUST support DTLS 1.1 [RFC4347] and MUST support the mandatory to implement cipher suite, which is TLS_RSA_WITH_AES_128_CBC_SHA. NEW: Implementations MUST support DTLS 1.1 [RFC4347] and MUST at a minimum support the mandatory to implement cipher suite, which is TLS_RSA_WITH_AES_128_CBC_SHA. If additional cipher suites are supported, then implementations MUST NOT negotiate a cipher suite that employs NULL encryption, integrity, or authentication algorithms. The justification is that "disclosure is one of the primary threats described in Section 4," I disagree. The threat of disclosure comes from RFC5425 s2 "Some data in syslog messages is sensitive and may be useful to an attacker, such as the password of an authorized administrator or user." but the fact that someone, somewhere may put a password in a syslog message I do not see as grounds for requiring everyone else in the world to encrypt everything. Encryption is a pain, it costs, and we should not require it unless it can be justified; these are remote, low-powered network boxes we are talking about, not enterprise servers. So while I agree we should require authentication, I see no justification for encryption. In passing, there was a request for a reference for the ciphersuite, which could be covered by adding 'as specified there' after 'cipher suite'. Tom Petch From tim@evensweb.com Tue May 25 07:14:53 2010 Return-Path: X-Original-To: syslog@core3.amsl.com Delivered-To: syslog@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1DB343A6BAF for ; Tue, 25 May 2010 07:14:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.788 X-Spam-Level: X-Spam-Status: No, score=0.788 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_05=-1.11, HTML_MESSAGE=0.001, HTML_NONELEMENT_30_40=0.001, J_CHICKENPOX_15=0.6, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NpoJxTLwp6sS for ; Tue, 25 May 2010 07:14:50 -0700 (PDT) Received: from outbound2.bluetie.com (outbound002.bluetie.com [206.65.164.141]) by core3.amsl.com (Postfix) with ESMTP id AA5A73A6BE7 for ; Tue, 25 May 2010 07:14:49 -0700 (PDT) Received: from web2.nyc1.bluetie.com ([10.102.1.161]) by outbound2.bluetie.com with bizsmtp id MqEg1e0053URfqa01qEgr1; Tue, 25 May 2010 10:14:40 -0400 X-CMAE-Score: 0.00 X-CMAE-Analysis: v=1.1 cv=VLDqXFi0LPnZZ+UpaFydONtV6EwCqtyOMjcXCFxpMmc= c=1 sm=1 a=YtVw0_ETJMMA:10 a=uEzv4HemXiYA:10 a=_wFv0sKIAAAA:8 a=o4D-YMODAAAA:8 a=voZKSeMjAAAA:8 a=48vgC7mUAAAA:8 a=9qxNCY_qAAAA:8 a=P5JcdcliMiLE5znBwCwA:9 a=_OyWFz1Jl782ln6f2gwA:7 a=_pWwohPcGLibM2r4lGcUw0_L1aIA:4 a=QEXdDO2ut3YA:10 a=pN_FbJzYb_wA:10 a=De4saq_zUVgA:10 a=8I_KKyVBtz8A:10 a=lZB815dzVvQA:10 a=1pxjJC3EenQA:10 a=230CyQIBjPjqSfUJ:21 a=E8tyCUUMR3uA9x-q:21 a=kARQ3BBTUwZ8FqTWjNYA:9 a=8RZB4YCHiJexMnSva9YA:7 a=gqzJ7S87vCdVuRMLaxWwA_aq0zAA:4 a=mAov9nt2oiSlXaFW:21 a=1MTyum70GF5gLaZY:21 a=HpjTyQb0SLWbefqTP3V6fw==:117 Received: from web2.nyc1.bluetie.com (localhost.localdomain [127.0.0.1]) by web2.nyc1.bluetie.com (Postfix) with ESMTP id CD9D940044; Tue, 25 May 2010 10:14:40 -0400 (EDT) Message-ID: <20100525101440.27134@web2.nyc1.bluetie.com> X-HTTP-Received: from tim.evensweb [24.19.97.0] by web2.nyc1.bluetie.com (BlueTie WebMail ); Tue, 25 May 2010 10:14:40 -0400 X-Mailer: BlueTie MTA Date: Tue, 25 May 2010 10:14:40 -0400 To: turners@ieca.com,ietfc@btconnect.com, Pasi.Eronen@nokia.com From: "Tim Evens" Importance: normal Content-Type: multipart/alternative; boundary="1358457554-1274796880=:27134" MIME-Version: 1.0 Cc: syslog@ietf.org Subject: Re: [Syslog] AD review discuss/comments for draft-ietf-syslog-dtls X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 May 2010 14:14:53 -0000 --1358457554-1274796880=:27134 Content-transfer-encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Correct, in RFC5426 the max size is 64K which is the max length in UDP. =C2= =A0UDP sizes of greater than MTU are only achievable via IP layer fragmentat= ion, as you also indicated. =C2=A0 =C2=A0I'm under the impression that DTLS = does NOT support IPv4 fragmentation since in RFC4347 it states in Section 4.= 1.1 "Each DTLS record MUST fit within a single datagram. =C2=A0In order to= =C2=A0=C2=A0 avoid IP fragmentation [MOGUL], DTLS implementations SHOULD det= ermine=C2=A0=C2=A0 the MTU and send records smaller than the MTU. =C2=A0DTLS= implementations=C2=A0=C2=A0 SHOULD provide a way for applications to determ= ine the value of the=C2=A0=C2=A0 PMTU (or, alternately, the maximum applicat= ion datagram size, which=C2=A0=C2=A0 is the PMTU minus the DTLS per-record o= verhead). =C2=A0If the application=C2=A0=C2=A0 attempts to send a record lar= ger than the MTU, the DTLS=C2=A0=C2=A0 implementation SHOULD generate an err= or, thus avoiding sending a=C2=A0=C2=A0 packet which will be fragmented."Whi= le UDP supports message sizes in excess of 1500 bytes, the implementation as= defined in this draft using DTLS does not. =C2=A0It does not require or use= DTLS sequence numbers nor does DTLS allow for fragmentation. =C2=A0 How exa= ctly does this draft support message sizes larger than the MTU considering t= hese restrictions? =C2=A0Few layer 2 implementations support MTU sizes great= er than 9K. =C2=A0Even with GigabitEthernet Jumbo frames (9K) the end-to-end= MTU is still limited as the frame/packet traverses various devices. =C2=A0O= nly GigabitEthernet =C2=A0requires optional support for jumbo frames, while = FastEthernet does not. =C2=A0Most 10/100 interfaces only support a maximum o= f 2K frame MTU, while Gig and TenGig support 9K.=C2=A0-----Original Message-= ----From: Pasi.Eronen@nokia.comDate: 05/25/2010 02:45 AMTo: tim@evensweb.com= , turners@ieca.com, ietfc@btconnect.comCC: syslog@ietf.orgSubject: RE: [Sysl= og] AD review discuss/comments for draft-ietf-syslog-dtls I would pr= efer to keep syslog-over-DTLS-over-UDP as similar to RFC 5246 (syslog-over-U= DP) as possible -- i.e. don't add any kind of fragmentation/reassembly in sy= slog layer. Both syslog-over-UDP and syslog-over-DTLS-over-UDP already suppo= rt messages up to ~64K; they're just not very efficient if your MTU is smal= l (and you need IP layer fragmentation). But for administrators that know t= hey'll need efficient transport of large messages, we already have a soluti= on: RFC 5425. Best regards, Pasi =C2=A0 From: ext Tim Evens [tim@evensweb= .com] Sent: Monday, May 24, 2010 7:34 PM To: turners@ieca.com; ietfc@btconne= ct.com; Eronen Pasi (Nokia-NRC/Helsinki) Cc: syslog@ietf.org Subject: Re: [S= yslog] AD review discuss/comments for draft-ietf-syslog-dtls Right. =C2= =A0I wrote the following a couple weeks back: "=E2=80=A6 an application ma= y not directly write to the network where UDP/DTLS would be used as a transp= ort. =C2=A0 More likely, the application will write to a regular file or FIF= O/PIPE that may support a larger message size. =C2=A0The application that re= ads this message may be the application that sends the messages via UDP/DTL= S. =C2=A0 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. =C2=A0RFC5424 doesn't detail SD elements= or methods for splitting messages. =C2=A0Transports have size constraints a= nd will require messages to be truncated or split. =C2=A0For example, the CI= SCO-SYSLOG-MIB defines that a message larger than 255 characters will be tr= uncated to 254 characters with a '*' as the 255th character. " To your poi= nt 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. =C2=A0 In my opinion, this draft assumes t= hat the application logging the message will some how size the message to fi= t within a single DTLS record/packet. =C2=A0 This assumption is problematic,= as mentioned above the application writing the actual SYSLOG-MSG per RFC54= 24 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, th= ere will be more than one syslog receiver/collector. =C2=A0 Remote syslog re= ceivers/collectors may require different transports. =C2=A0One may use UDP/= DTLS while the other uses TCP. =C2=A0Therefore, the original syslog message = of say 1480 bytes may be written to the network twice, one using UDP/DTLS an= d the other using TCP. =C2=A0 The message that is transported using TCP will= be receive in full without any issues, while the one with DTLS will have t= o be truncated to the MTU size limitations. =C2=A0=C2=A0 RFC4347 (DTLS) re= fers to RFC4346 (TLS 1.1 obsoleted by RFC5246 TLS 1.2) for record layer impl= ementation. =C2=A0 More specifically, as defined in RFC4346 Section 6.2.1, = =C2=A0"The record layer fragments information blocks into TLSPlaintext =C2= =A0=C2=A0 records carrying data in chunks of 2^14 bytes or less. =C2=A0Clien= t =C2=A0=C2=A0 message boundaries are not preserved in the record layer (i.e= ., =C2=A0=C2=A0 multiple client messages of the same ContentType MAY be coal= esced =C2=A0=C2=A0 into a single TLSPlaintext record, or a single message MA= Y be =C2=A0=C2=A0 fragmented across several records)." It's possible for T= LS 1.1 and 1.2 to support message block (chunks) as defined because the unde= rlining transport is TCP providing ordered message delivery, whereas RFC4347= (DTLS) can use UDP which does not provide ordered delivery. =C2=A0DTLS intr= oduces a sequence number field in the record structure, which if implemente= d for reordering, the receiver could reorder the DTLS records so that the or= iginal message blocks are concatenated back to form the original SYSLOG-MSG.= =C2=A0=C2=A0 This probably leads to why in this draft in Section 5.1 it s= tates that when using DTLS sequence numbers "=E2=80=A6 it may =C2=A0=C2=A0 n= ot assure that all the messages are delivered in order when mapping =C2=A0= =C2=A0 on the UDP transport." The reason is that with TCP there is a retra= nsmission for lost segments, whereas UDP does not implement retransmissions.= =C2=A0Therefore, 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. =C2=A0How it wo= uld it know to discard X1 and X3 since X2 was lost? =C2=A0In either case, th= is too is problematic, which leads back to why the SYSLOG-MSG will have to f= it within a single DTLS record. Thus the SYSLOG-MSG will in most cases alwa= ys be less than 1460 bytes due to MTU DTLS/MTU limitations. =C2=A0The applic= ation SHOULD NOT assume that using the RFC5424 recommended minimum of 480 oc= tets 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 si= ze of at least 5 or more DTLS packets/records. =C2=A0 In addition, Section 5= .4 would need a new field in the SYSLOG-FRAME to include a FRAME-ID. =C2= =A0This FRAME-ID would serve as a way for the DTLS implementation to know wh= ich DTLS records need to be discarded in the event of packet loss. =C2=A0 = For example: =C2=A0=C2=A0FRAME-ID =3D NILVALUE / ("+" / "-") NONZERO-DIGIT= 1*15DIGIT; uint48* =C2=A0=C2=A0 =C2=A0 =C2=A0+/- is used to indicate more= message blocks to come or not. =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0"+" = indicates more to follow, "-" indicates last block. =C2=A0=C2=A0 =C2=A0 = =C2=A0Use NILVALUE if SYSLOG-MSG is not split across multiple DTLS records, = otherwise use=C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0first DTLS sequence num= ber in DTLS record sequence as FRAME-ID. =C2=A0=C2=A0 =C2=A0 =C2=A0This is= an example only of a possible FRAME-ID. =C2=A0=C2=A0 =C2=A0 =C2=A0*Instea= d of using 1*15DIGIT, it could be 6OCTET=3Duint48, which would=C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0reduce the overall size. =C2=A0Example Use: = =C2=A0=C2=A0DTLS seq 1 - SYSLOG-FRAME-ID=3D+1001 =C2=A0=C2=A0DT= LS seq 2 - SYSLOG-FRAME-ID=3D+1001 =C2=A0=C2=A0--> dropped by n= etwork --> DTLS seq 3 - SYSLOG-FRAME-ID=3D+1001 =C2=A0=C2=A0DTL= S seq 4 - SYSLOG-FRAME-ID=3D-1001 =C2=A0=C2=A0DTLS seq 5 - SYSL= OG-FRAME-ID - =C2=A0=C2=A0DTLS seq 6 - SYSLOG-FRAME-ID - Using a buffer/queue size of 5 DTLS records/packets, the DTLS imple= mentation would have been holding DTLS seq 1, 2, and 4 waiting for 3. =C2= =A0When it received seq 5 and 6, it reaches its buffer size and therefore di= scards DTLS seq 1,2,4 since they all have SYSLOG-FRAME-ID of 1001. =C2=A0DT= LS seq 5 and 6 are processed.=C2=A0 Thanks, Tim -----Original Message= ----- From: Pasi.Eronen@nokia.com Date: 05/24/2010 04:23 AM To: turners@ieca= .com, ietfc@btconnect.com CC: syslog@ietf.org Subject: Re: [Syslog] AD revie= w discuss/comments for draft-ietf-syslog-dtls I haven't followed this disc= ussion 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 sysl= og messages be contained in one DTLS record, or that a syslog message be tra= nsferred in multiple DTLS records." The maximum size of a single DTLS recor= d 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 mul= tiple DTLS records, all those records have to be in a single UDP datagram (s= o the syslog layer does not reassemble syslog message pieces from multiple U= DP 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: syslog-bounces@ietf.org [syslog-bounces@ietf= .org] On Behalf Of ext Sean Turner [turners@ieca.com] Sent: Saturday, May 22= , 2010 6:16 PM To: t.petch Cc: syslog Subject: Re: [Syslog] AD review discus= s/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 mes= sages, 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 > ever= ything fit in 576 byte; I think we have the balance right. Tom, My respons= e to Alexey was that this I-D borrows that particular requirement from RFC43= 47 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 Syslog@ietf.org https:= //www.ietf.org/mailman/listinfo/syslog _____________________________________= __________ Syslog mailing list Syslog@ietf.org https://www.ietf.org/mailman/= listinfo/syslog = --1358457554-1274796880=:27134 Content-transfer-encoding: quoted-printable Content-Type: text/html; charset=UTF-8 Correct, in RFC5426 the max size is 64K which is the max length in UDP. &nbs= p;UDP sizes of greater than MTU are only achievable via IP layer fragmentati= on, as you also indicated.    I'm under the impression that DTLS d= oes NOT support IPv4 fragmentation since in RFC4347 it states in Section 4.1= .1 "Each DTLS record MUST fit within a single datagram.  In order to
   avoid IP fragmentation [MOGUL], DTLS implementations SHOUL= D determine
   the MTU and send records smaller than the= MTU.  DTLS implementations
   SHOULD provide a way= for applications to determine the value of the
   PMTU = (or, alternately, the maximum application datagram size, which
&nb= sp;  is the PMTU minus the DTLS per-record overhead).  If the appl= ication
   attempts to send a record larger than the MTU= , the DTLS
   implementation SHOULD generate an error, t= hus avoiding sending a
   packet which will be fragmente= d."

While UDP supports message sizes in excess of 1500 bytes, the imp= lementation as defined in this draft using DTLS does not.  It does not = require or use DTLS sequence numbers nor does DTLS allow for fragmentation. =   How exactly does this draft support message sizes larger than the MTU= considering these restrictions?  

Few layer 2 implementations support MTU sizes greater than 9K. &n= bsp;Even with GigabitEthernet Jumbo frames (9K) the end-to-end MTU is still = limited as the frame/packet traverses various devices.  Only GigabitEth= ernet  requires optional support for jumbo frames, while FastEthernet d= oes not.  Most 10/100 interfaces only support a maximum of 2K frame MTU= , while Gig and TenGig support 9K.
 



-----Original Message-----
From: Pasi.Eronen@nokia.com
Date: 05/25/2010 02:45 AM
To: tim@evensweb.com, turners@ieca.com, ietfc@btconnect.com
CC: syslog@ietf.org
Subject: RE: [Syslog] AD review discuss/comments for draft-ietf-syslo= g-dtls

I would prefer to keep syslog-over-DTLS-over-UDP as si= milar to RFC 5246 (syslog-over-UDP)
as possible -- i.e. don't add any kind of fragmentation/reassembly in= syslog layer.
Both syslo= g-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).
<= font face=3D"tahoma">But for administrators that know they'll = need efficient transport of large messages,= we already
have a solut= ion: RFC 5425.

Best regards,
Pasi
 
From: ext Tim Evens [tim@evensweb.com]
Sent: Monday, May 24, 2010 7:34 PM
To: turners@ieca.com; ietfc@btconnect.com; Eronen Pasi (Nokia-NRC/He= lsinki)
Cc: syslog@ietf.org
Subject: Re: [Syslog] AD review discuss/comments for draft-ietf-sysl= og-dtls

Right.  I wrote the fo= llowing a couple weeks back:

"=E2=80=A6 an application may not directly write to the network= where UDP/DTLS would be used as a transport.   More likely, the applic= ation will write to a regular file or FIFO/PIPE that may support a larger me= ssage size.  The application that reads this message may be the applic= ation that sends the messages via UDP/DTLS.   It would be more meaningf= ul if the application writing the message controls the truncation or if the = transport application sending the message onto the network can correctly bre= ak 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 trun= cated or split.  For example, the CISCO-SYSLOG-MIB defines that a mess= age 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 recor= d/packet.   This assumption is problematic, as mentioned above the appl= ication writing the actual SYSLOG-MSG per RFC5424 has no way of knowing whi= ch 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 sy= slog receiver/collector.   Remote syslog receivers/collectors may requi= re different transports.  One may use UDP/DTLS while the other uses TC= P.  Therefore, the original syslog message of say 1480 bytes may be wri= tten 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 si= ze limitations.   

RFC4347 (DTLS) refers to RFC4346 (TLS 1.1 obsoleted by RFC5246 = TLS 1.2) for record layer implementation.   More specifically, as defin= ed in RFC4346 Section 6.2.1,  "The record layer fragments information b= locks into TLSPlaintext
   records carrying data in chu= nks of 2^14 bytes or less.  Client
   message boun= daries 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<= /div>
   fragmented across several records)."

=
It's possible for TLS 1.1 and 1.2 to support message block (chu= nks) as defined because the underlining transport is TCP providing ordered m= essage delivery, whereas RFC4347 (DTLS) can use UDP which does not provide o= rdered delivery.  DTLS introduces a sequence number field in the recor= d 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 stat= es that when using DTLS sequence numbers "=E2=80=A6 it may
 =   not assure that all the messages are delivered in order when mapping<= /div>
   on the UDP transport."

The reason is that with TCP there is a retransmission for lost = segments, whereas UDP does not implement retransmissions.  Therefore, i= f 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 disc= ard X1 and X3 since X2 was lost?  In either case, this too is problemat= ic, 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 146= 0 bytes due to MTU DTLS/MTU limitations.  The application SHOULD NOT as= sume 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 up= dated to require that the DTLS implementation reorder using DTLS sequence nu= mbers 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 incl= ude a FRAME-ID.  This FRAME-ID would serve as a way for the DTLS implem= entation to know which DTLS records need to be discarded in the event of pac= ket loss.  

For example:

  FRAME-ID =3D 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 spl= it across multiple DTLS records, otherwise use 
  =      first DTLS sequence number in DTLS record sequence as F= RAME-ID.

      This is an example only of a possible= FRAME-ID.

      *Instead of using 1*15DIGIT, it could= be 6OCTET=3Duint48, which would 
      =  reduce the overall size.

 Example Use:

  DTLS seq 1 - SYSLOG-FRAME-ID=3D+1001 <SYSLOG-MSG= >
  DTLS seq 2 - SYSLOG-FRAME-ID=3D+1001 <SYSLOG-= MSG>
  --> dropped by network --> DTLS seq 3 -= SYSLOG-FRAME-ID=3D+1001 <SYSLOG-MSG>
  DTLS seq = 4 - SYSLOG-FRAME-ID=3D-1001 <SYSLOG-MSG>
  DTLS s= eq 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 i= mplementation would have been holding DTLS seq 1, 2, and 4 waiting for 3. &n= bsp;When it received seq 5 and 6, it reaches its buffer size and therefore d= iscards DTLS seq 1,2,4 since they all have SYSLOG-FRAME-ID of 1001.  D= TLS seq 5 and 6 are processed. 

Thanks,
Tim





-----Original Message-----
From: Pasi.Eronen@nokia.com
Date: 05/24/2010 04:23 AM
To: turners@ieca.com, ietfc@btconnect.com
CC: syslog@ietf.org
Subject: Re: [Syslog] AD review discuss/comments for draft-ietf-sysl= og-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: syslog-bounces@ietf.org [syslog-bounces@ietf.org] On Beha= lf Of ext Sean Turner [turners@ieca.com]
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 lik= e to
> progress.
>
> I see several comments about maximum record size, including a suggesti= on 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
Syslog@ietf.org
= https://www.ietf.org/mailman/listinfo/syslog
_______________________________________________
Syslog mailing list
Syslog@ietf.org
= https://www.ietf.org/mailman/listinfo/syslog

= --1358457554-1274796880=:27134-- From tim@evensweb.com Tue May 25 07:26:56 2010 Return-Path: X-Original-To: syslog@core3.amsl.com Delivered-To: syslog@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C76B3A74E7 for ; Tue, 25 May 2010 07:26:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.057 X-Spam-Level: * X-Spam-Status: No, score=1.057 tagged_above=-999 required=5 tests=[AWL=-0.341, BAYES_50=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SUjMhgb3I+kH for ; Tue, 25 May 2010 07:26:53 -0700 (PDT) Received: from outbound3.bluetie.com (outbound3.bluetie.com [206.65.163.13]) by core3.amsl.com (Postfix) with ESMTP id C57683A729B for ; Tue, 25 May 2010 07:24:11 -0700 (PDT) Received: from web3.nyc1.bluetie.com ([10.102.1.187]) by outbound3.bluetie.com with bizsmtp id MqQ31e0044258dW01qQ335; Tue, 25 May 2010 10:24:03 -0400 X-CMAE-Score: 0.00 X-CMAE-Analysis: v=1.1 cv=9a3w/t1JzCufGMGo8phnWiRF/rANpT4CXr2jTnyFA9M= c=1 sm=1 a=YtVw0_ETJMMA:10 a=uEzv4HemXiYA:10 a=YkQXWpjeXptGWEpL3VMA:9 a=taP0p1IePwkHRt3H0esA:7 a=ApPqIbMOabFULZ0TJuYLvyyHTSkA:4 a=QEXdDO2ut3YA:10 a=9qxNCY_qAAAA:8 a=bXa9qGGSC5oe9P5eCGQA:9 a=GnGaybXoEc53MaII4CAA:7 a=fp_LebUmua2G5dsgA8XY2qeIt9EA:4 a=1pxjJC3EenQA:10 a=ZexAb3Vcgjt8ZV0CTeya/g==:117 Received: from web3.nyc1.bluetie.com (localhost.localdomain [127.0.0.1]) by web3.nyc1.bluetie.com (Postfix) with ESMTP id 290FE30048; Tue, 25 May 2010 10:24:00 -0400 (EDT) Message-ID: <20100525102400.30396@web3.nyc1.bluetie.com> X-HTTP-Received: from tim.evensweb [24.19.97.0] by web3.nyc1.bluetie.com (BlueTie WebMail ); Tue, 25 May 2010 10:24:00 -0400 X-Mailer: BlueTie MTA Date: Tue, 25 May 2010 10:24:00 -0400 To: ietfc@btconnect.com,turners@ieca.com, Pasi.Eronen@nokia.com From: "Tim Evens" Importance: normal Content-Type: multipart/alternative; boundary="1784811518-1274797440=:30396" MIME-Version: 1.0 Cc: syslog@ietf.org Subject: Re: [Syslog] AD review discuss/comments for draft-ietf-syslog-dtls X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 May 2010 14:26:56 -0000 --1784811518-1274797440=:30396 Content-transfer-encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 See inline...-----Original Message-----From: Pasi.Eronen@nokia.comDate: 05/2= 5/2010 03:54 AMRFC 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 recomme= ndation (this is implied by other text in the spec, and as you noticed, we c= larified this in RFC 5246). But even though DTLS records are limited to 2^1= 4 bytes, syslog messages are not! The current spec seems to support 64K (min= us 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 th= en combined to a single UDP datagram. Ahh... Only if DTLS sequence= numbers are used and if they are implemented using a reorder queueing metho= d can a message be split into "chunks" that are transmitted over multiple DT= LS records. This leads to the issue of what happens when a packet is dropped= ? =C2=A0 Even if you follow the DTLS sequence numbers, UDP and DTLS do not s= upport retransmission, thus that lost packet is lost forever. This would lea= d to one message "chunk" being concatenated with a different message altoget= her. =C2=A0This is why I was suggesting a SYSLOG-FRAME-ID.=C2=A0 B= est regards, Pasi = --1784811518-1274797440=:30396 Content-transfer-encoding: quoted-printable Content-Type: text/html; charset=UTF-8 See inline...

-----Original Message-----
From: Pasi.Eronen@nokia.com
Date: 05/25/2010 03:54 AM

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.

<tievens> Ahh... Only if DTLS sequence numbers are used and= if they are implemented using a reorder queueing method can a message be sp= lit into "chunks" that are transmitted over multiple DTLS records. This lead= s to the issue of what happens when a packet is dropped?   Even if you = follow the DTLS sequence numbers, UDP and DTLS do not support retransmission= , thus that lost packet is lost forever. This would lead to one message "chu= nk" being concatenated with a different message altogether.  This is wh= y I was suggesting a SYSLOG-FRAME-ID. 
</tievens>
=

Best regards,
Pasi


=
--1784811518-1274797440=:30396-- From ietfc@btconnect.com Tue May 25 12:38:45 2010 Return-Path: X-Original-To: syslog@core3.amsl.com Delivered-To: syslog@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1BDBC3A6A01 for ; Tue, 25 May 2010 12:38:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.601 X-Spam-Level: X-Spam-Status: No, score=0.601 tagged_above=-999 required=5 tests=[BAYES_50=0.001, J_CHICKENPOX_15=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hS0oKiZgTSKA for ; Tue, 25 May 2010 12:38:43 -0700 (PDT) Received: from c2bthomr14.btconnect.com (c2bthomr14.btconnect.com [213.123.20.132]) by core3.amsl.com (Postfix) with ESMTP id DD2F53A69E5 for ; Tue, 25 May 2010 12:38:42 -0700 (PDT) Received: from pc6 (host86-172-78-59.range86-172.btcentralplus.com [86.172.78.59]) by c2bthomr14.btconnect.com with SMTP id FLB40272; Tue, 25 May 2010 20:38:28 +0100 (BST) X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=0001.0A0B0302.4BFC2734.0194, actions=tag Message-ID: <03fc01cafc39$0e7eb200$4001a8c0@gateway.2wire.net> From: "t.petch" To: "Tim Evens" References: <20100525101440.27134@web2.nyc1.bluetie.com> Date: Tue, 25 May 2010 20:35:24 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Junkmail-Status: score=10/50, host=c2bthomr14.btconnect.com X-Junkmail-SD-Raw: score=unknown, refid=str=0001.0A0B0206.4BFC2739.0133,ss=1,fgs=0, ip=0.0.0.0, so=2009-07-20 21:54:04, dmn=5.7.1/2009-08-27, mode=single engine X-Junkmail-IWF: false Cc: syslog@ietf.org Subject: Re: [Syslog] AD review discuss/comments for draft-ietf-syslog-dtls X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 May 2010 19:38:45 -0000 Tim I am getting your e-mails but struggling to read them, since they are a concatenated pipe of text, no fragmentation here. When I look at the source, it is in quoted-printable UTF8 and whereever I might expect a hard break, I see =A0. If I edit =A0 to =0A, then hard breaks appear where I expect them. Curious. Tom Petch ----- Original Message ----- From: "Tim Evens" To: ; ; Cc: Sent: Tuesday, May 25, 2010 4:14 PM Subject: RE: [Syslog] AD review discuss/comments for draft-ietf-syslog-dtls Correct, in RFC5426 the max size is 64K which is the max length in UDP. UDP sizes of greater than MTU are only achievable via IP layer fragmentation, as you also indicated. I'm under the impression that DTLS does NOT support IPv4 fragmentation since in RFC4347 it states in Section 4.1.1 "Each DTLS record MUST fit within a single datagram. In order to avoid IP fragmentation [MOGUL], DTLS implementations SHOULD determine the MTU and send records smaller than the MTU. DTLS implementations SHOULD provide a way for applications to determine the value of the PMTU (or, alternately, the maximum application datagram size, which is the PMTU minus the DTLS per-record overhead). If the application attempts to send a record larger than the MTU, the DTLS implementation SHOULD generate an error, thus avoiding sending a packet which will be fragmented."While UDP supports message sizes in excess of 1500 bytes, the implementation as defined in this draft using DTLS does not. It does not require or use DTLS sequence numbers nor does DTLS allow for fragmentation. How exactly does this draft support message sizes larger than the MTU considering these restrictions? Few layer 2 implementations support MTU sizes greater than 9K. Even with GigabitEthernet Jumbo frames (9K) the end-to-end MTU is still limited as the frame/packet traverses various devices. Only GigabitEthernet requires optional support for jumbo frames, while FastEthernet does not. Most 10/100 interfaces only support a maximum of 2K frame MTU, while Gig and TenGig support 9K. -----Original Message-----From: Pasi.Eronen@nokia.comDate: 05/25/2010 02:45 AMTo: tim@evensweb.com, turners@ieca.com, ietfc@btconnect.comCC: syslog@ietf.orgSubject: RE: [Syslog] AD review discuss/comments for draft-ietf-syslog-dtls 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 [tim@evensweb.com] Sent: Monday, May 24, 2010 7:34 PM To: turners@ieca.com; ietfc@btconnect.com; Eronen Pasi (Nokia-NRC/Helsinki) Cc: syslog@ietf.org 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 DTLS seq 2 - SYSLOG-FRAME-ID=+1001 --> dropped by network --> DTLS seq 3 - SYSLOG-FRAME-ID=+1001 DTLS seq 4 - SYSLOG-FRAME-ID=-1001 DTLS seq 5 - SYSLOG-FRAME-ID - DTLS seq 6 - SYSLOG-FRAME-ID - 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: Pasi.Eronen@nokia.com Date: 05/24/2010 04:23 AM To: turners@ieca.com, ietfc@btconnect.com CC: syslog@ietf.org 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: syslog-bounces@ietf.org [syslog-bounces@ietf.org] On Behalf Of ext Sean Turner [turners@ieca.com] 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 Syslog@ietf.org https://www.ietf.org/mailman/listinfo/syslog _______________________________________________ Syslog mailing list Syslog@ietf.org https://www.ietf.org/mailman/listinfo/syslog From Pasi.Eronen@nokia.com Tue May 25 23:02:07 2010 Return-Path: X-Original-To: syslog@core3.amsl.com Delivered-To: syslog@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B5F43A6862 for ; Tue, 25 May 2010 23:02:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JUVPvi9pa+yo for ; Tue, 25 May 2010 23:02:06 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 3A4E73A6872 for ; Tue, 25 May 2010 23:02:06 -0700 (PDT) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx09.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o4Q61ohO028000; Wed, 26 May 2010 01:01:51 -0500 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 26 May 2010 09:01:40 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.7]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 26 May 2010 09:01:35 +0300 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.106]) by nok-am1mhub-03.mgdnok.nokia.com ([65.54.30.7]) with mapi; Wed, 26 May 2010 08:01:34 +0200 From: To: , , Date: Wed, 26 May 2010 07:57:09 +0200 Thread-Topic: [Syslog] AD review discuss/comments for draft-ietf-syslog-dtls Thread-Index: Acr8FgfDHq3VZNKjRj2xnT/m6foTVQAgj8iR Message-ID: <808FD6E27AD4884E94820BC333B2DB775BC0E0952A@NOK-EUMSG-01.mgdnok.nokia.com> References: <20100525102400.30396@web3.nyc1.bluetie.com> In-Reply-To: <20100525102400.30396@web3.nyc1.bluetie.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 26 May 2010 06:01:35.0459 (UTC) FILETIME=[E5D41330:01CAFC98] X-Nokia-AV: Clean Cc: syslog@ietf.org Subject: Re: [Syslog] AD review discuss/comments for draft-ietf-syslog-dtls X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 May 2010 06:02:07 -0000 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...) Best regards, Pasi= From Pasi.Eronen@nokia.com Tue May 25 23:05:57 2010 Return-Path: X-Original-To: syslog@core3.amsl.com Delivered-To: syslog@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 80ECF3A6862 for ; Tue, 25 May 2010 23:05:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.554 X-Spam-Level: X-Spam-Status: No, score=-4.554 tagged_above=-999 required=5 tests=[AWL=0.556, BAYES_05=-1.11, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F4Frrv8eG0S6 for ; Tue, 25 May 2010 23:05:56 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 079243A66B4 for ; Tue, 25 May 2010 23:05:55 -0700 (PDT) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx03.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o4Q65M9C003414; Wed, 26 May 2010 09:05:40 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 26 May 2010 09:05:22 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.7]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 26 May 2010 09:05:22 +0300 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.106]) by nok-am1mhub-03.mgdnok.nokia.com ([65.54.30.7]) with mapi; Wed, 26 May 2010 08:05:21 +0200 From: To: , , Date: Wed, 26 May 2010 08:03:01 +0200 Thread-Topic: [Syslog] AD review discuss/comments for draft-ietf-syslog-dtls Thread-Index: Acr8FLlBV0YM+QjuSfWdd2YLJgHcHQAhF/hG Message-ID: <808FD6E27AD4884E94820BC333B2DB775BC0E0952B@NOK-EUMSG-01.mgdnok.nokia.com> References: <20100525101440.27134@web2.nyc1.bluetie.com> In-Reply-To: <20100525101440.27134@web2.nyc1.bluetie.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 26 May 2010 06:05:22.0502 (UTC) FILETIME=[6D281660:01CAFC99] X-Nokia-AV: Clean Cc: syslog@ietf.org Subject: Re: [Syslog] AD review discuss/comments for draft-ietf-syslog-dtls X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 May 2010 06:05:57 -0000 Tim Evens wrote: > Correct, in RFC5426 the max size is 64K which is the max length in > UDP. UDP sizes of greater than MTU are only achievable via IP layer > fragmentation, as you also indicated. I'm under the impression that > DTLS does NOT support IPv4 fragmentation since in RFC4347 it states > in Section 4.1.1 "Each DTLS record MUST fit within a single > datagram." AFAIK when running DTLS over UDP, "datagram" here refers to UDP datagrams, not IP packets (and one UDP datagram can be split to several IP packets). Best regards, Pasi= From tim@evensweb.com Tue May 25 23:17:11 2010 Return-Path: X-Original-To: syslog@core3.amsl.com Delivered-To: syslog@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 25B733A687A for ; Tue, 25 May 2010 23:17:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.74 X-Spam-Level: X-Spam-Status: No, score=-0.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HVULFfqNXQsP for ; Tue, 25 May 2010 23:17:09 -0700 (PDT) Received: from outbound1.bluetie.com (outbound1.bluetie.com [206.65.164.140]) by core3.amsl.com (Postfix) with ESMTP id 521023A6874 for ; Tue, 25 May 2010 23:17:09 -0700 (PDT) Received: from emta1.nyc1.bluetie.com ([10.102.1.160]) by outbound1.bluetie.com with outbound001 id N6H01e0023T7zWJ016H0KY; Wed, 26 May 2010 02:17:00 -0400 X-CMAE-Score: 0.00 X-CMAE-Analysis: v=1.1 cv=wBrC3rn4ndyg7G79calUHzfpKuqQZwOCAVwTYTfHEQw= c=1 sm=1 a=YtVw0_ETJMMA:10 a=uEzv4HemXiYA:10 a=kj9zAlcOel0A:10 a=paXBUIBQ3N+qoNG038GKvg==:17 a=9qxNCY_qAAAA:8 a=BofgxN_9TwrvQkb7lKEA:9 a=Ih-5s7xsTiOhWYctCQc4oijrr0sA:4 a=CjuIK1q_8ugA:10 a=1pxjJC3EenQA:10 a=J3G4CyWmZqSAU3rV:21 a=mRUqr2AHrDW4Sj49:21 a=kefG/y7aXFJRfTdPUUcKYA==:117 Received: from [10.19.220.121] (128-107-239-233.cisco.com [128.107.239.233]) by emta1.nyc1.bluetie.com (Postfix) with ESMTP id E335280081; Wed, 26 May 2010 02:11:47 -0400 (EDT) References: <20100525101440.27134@web2.nyc1.bluetie.com> <808FD6E27AD4884E94820BC333B2DB775BC0E0952B@NOK-EUMSG-01.mgdnok.nokia.com> Message-Id: From: Tim Evens To: "" In-Reply-To: <808FD6E27AD4884E94820BC333B2DB775BC0E0952B@NOK-EUMSG-01.mgdnok.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit X-Mailer: iPhone Mail (7E18) Mime-Version: 1.0 (iPhone Mail 7E18) Date: Tue, 25 May 2010 23:16:55 -0700 Cc: "" Subject: Re: [Syslog] AD review discuss/comments for draft-ietf-syslog-dtls X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 May 2010 06:17:11 -0000 Interesting because RFC4347 IMHO states clearly that IP fragmentation (IP not UDP) must be avoided and thus dtls must determine the MTU. ** Sent from my tiny phone keyboard ** On May 25, 2010, at 11:03 PM, wrote: > Tim Evens wrote: >> Correct, in RFC5426 the max size is 64K which is the max length in >> UDP. UDP sizes of greater than MTU are only achievable via IP layer >> fragmentation, as you also indicated. I'm under the impression that >> DTLS does NOT support IPv4 fragmentation since in RFC4347 it states >> in Section 4.1.1 "Each DTLS record MUST fit within a single >> datagram." > > AFAIK when running DTLS over UDP, "datagram" here refers to UDP > datagrams, not IP packets (and one UDP datagram can be split > to several IP packets). > > Best regards, > Pasi From Pasi.Eronen@nokia.com Tue May 25 23:27:42 2010 Return-Path: X-Original-To: syslog@core3.amsl.com Delivered-To: syslog@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2EA1A3A6875 for ; Tue, 25 May 2010 23:27:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.577 X-Spam-Level: X-Spam-Status: No, score=-5.577 tagged_above=-999 required=5 tests=[AWL=1.022, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w7yDjrKqWxHl for ; Tue, 25 May 2010 23:27:41 -0700 (PDT) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id D3BD43A686D for ; Tue, 25 May 2010 23:27:40 -0700 (PDT) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx06.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o4Q6R2WI030642; Wed, 26 May 2010 09:27:24 +0300 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 26 May 2010 09:27:19 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.7]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 26 May 2010 09:27:10 +0300 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.106]) by nok-am1mhub-03.mgdnok.nokia.com ([65.54.30.7]) with mapi; Wed, 26 May 2010 08:27:09 +0200 From: To: Date: Wed, 26 May 2010 08:23:41 +0200 Thread-Topic: [Syslog] AD review discuss/comments for draft-ietf-syslog-dtls Thread-Index: Acr8mxpmoIUcYlqFQ2uHSqHidn60uwAAOGT3 Message-ID: <808FD6E27AD4884E94820BC333B2DB775BC0E0952D@NOK-EUMSG-01.mgdnok.nokia.com> References: <20100525101440.27134@web2.nyc1.bluetie.com> <808FD6E27AD4884E94820BC333B2DB775BC0E0952B@NOK-EUMSG-01.mgdnok.nokia.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 26 May 2010 06:27:10.0404 (UTC) FILETIME=[78BA1840:01CAFC9C] X-Nokia-AV: Clean Cc: syslog@ietf.org Subject: Re: [Syslog] AD review discuss/comments for draft-ietf-syslog-dtls X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 May 2010 06:27:42 -0000 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. Best regards, Pasi ________________________________________ From: ext Tim Evens [tim@evensweb.com] Sent: Wednesday, May 26, 2010 9:16 AM To: Eronen Pasi (Nokia-NRC/Helsinki) Cc: ; ; Subject: Re: [Syslog] AD review discuss/comments for draft-ietf-syslog-dtls Interesting because RFC4347 IMHO states clearly that IP fragmentation (IP not UDP) must be avoided and thus dtls must determine the MTU. ** Sent from my tiny phone keyboard ** On May 25, 2010, at 11:03 PM, wrote: > Tim Evens wrote: >> Correct, in RFC5426 the max size is 64K which is the max length in >> UDP. UDP sizes of greater than MTU are only achievable via IP layer >> fragmentation, as you also indicated. I'm under the impression that >> DTLS does NOT support IPv4 fragmentation since in RFC4347 it states >> in Section 4.1.1 "Each DTLS record MUST fit within a single >> datagram." > > AFAIK when running DTLS over UDP, "datagram" here refers to UDP > datagrams, not IP packets (and one UDP datagram can be split > to several IP packets). > > Best regards, > Pasi= From clonvick@cisco.com Wed May 26 08:13:43 2010 Return-Path: X-Original-To: syslog@core3.amsl.com Delivered-To: syslog@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1DCAE3A68CB for ; Wed, 26 May 2010 08:13:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.399 X-Spam-Level: X-Spam-Status: No, score=-7.399 tagged_above=-999 required=5 tests=[BAYES_50=0.001, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yiFpPoF3-MOe for ; Wed, 26 May 2010 08:13:41 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 4D86D3A683F for ; Wed, 26 May 2010 08:13:41 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAGbX/EurR7Ht/2dsb2JhbACDF5sGcadsiQSQdYQpagSDQg X-IronPort-AV: E=Sophos;i="4.53,304,1272844800"; d="scan'208";a="535562895" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-6.cisco.com with ESMTP; 26 May 2010 15:13:32 +0000 Received: from sjc-cde-011.cisco.com (sjc-cde-011.cisco.com [171.69.16.68]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o4QFDWHH004072; Wed, 26 May 2010 15:13:32 GMT Date: Wed, 26 May 2010 08:13:32 -0700 (PDT) From: Chris Lonvick To: "t.petch" In-Reply-To: <03fc01cafc39$0e7eb200$4001a8c0@gateway.2wire.net> Message-ID: References: <20100525101440.27134@web2.nyc1.bluetie.com> <03fc01cafc39$0e7eb200$4001a8c0@gateway.2wire.net> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-630072926-1274886812=:24171" Cc: syslog@ietf.org Subject: Re: [Syslog] AD review discuss/comments for draft-ietf-syslog-dtls X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 May 2010 15:13:43 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---559023410-630072926-1274886812=:24171 Content-Type: TEXT/PLAIN; charset=utf-8; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Hi, Tim - I just rejected your latest post (it got to be way to large when you= =20 attached your previous posts as PDFs). All - things can be read on the archive. http://www.ietf.org/mail-archive/web/syslog/current/maillist.html And, apologies to all, I've gotten caught up in the day job and can't read= =20 these things yet. Hopefully over the weekend. :-) Thanks, Chris On Tue, 25 May 2010, t.petch wrote: > Tim > > I am getting your e-mails but struggling to read them, since they are a > concatenated pipe of text, no fragmentation here. > > When I look at the source, it is in quoted-printable UTF8 and > whereever I might expect a hard break, I see =3DA0. > > If I edit =3DA0 to =3D0A, then hard breaks appear where I expect them. > > Curious. > > Tom Petch > > ----- Original Message ----- > From: "Tim Evens" > To: ; ; > Cc: > Sent: Tuesday, May 25, 2010 4:14 PM > Subject: RE: [Syslog] AD review discuss/comments for draft-ietf-syslog-dt= ls > > > Correct, in RFC5426 the max size is 64K which is the max length in UDP. U= DP > sizes of greater than MTU are only achievable via IP layer fragmentation,= as you > also indicated. I'm under the impression that DTLS does NOT support IPv4 > fragmentation since in RFC4347 it states in Section 4.1.1 "Each DTLS reco= rd MUST > fit within a single datagram. In order to avoid IP fragmentation [MOGUL],= DTLS > implementations SHOULD determine the MTU and send records smaller than th= e MTU. > DTLS implementations SHOULD provide a way for applications to determine t= he > value of the PMTU (or, alternately, the maximum application datagram size= , which > is the PMTU minus the DTLS per-record overhead). If the application attem= pts to > send a record larger than the MTU, the DTLS implementation SHOULD generat= e an > error, thus avoiding sending a packet which will be fragmented."While UDP > supports message sizes in excess of 1500 bytes, the implementation as def= ined in > this draft using DTLS does not. It does not require or use DTLS sequence = numbers > nor does DTLS allow for fragmentation. How exactly does this draft suppor= t > message sizes larger than the MTU considering these restrictions? Few lay= er 2 > implementations support MTU sizes greater than 9K. Even with GigabitEther= net > Jumbo frames (9K) the end-to-end MTU is still limited as the frame/packet > traverses various devices. Only GigabitEthernet requires optional support= for > jumbo frames, while FastEthernet does not. Most 10/100 interfaces only su= pport a > maximum of 2K frame MTU, while Gig and TenGig support 9K. -----Original > Message-----From: Pasi.Eronen@nokia.comDate: 05/25/2010 02:45 AMTo: > tim@evensweb.com, turners@ieca.com, ietfc@btconnect.comCC: > syslog@ietf.orgSubject: RE: [Syslog] AD review discuss/comments for > draft-ietf-syslog-dtls I would prefer to keep syslog-over-DTLS-ov= er-UDP > as similar to RFC 5246 (syslog-over-UDP) as possible -- i.e. don't add an= y 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 j= ust not > very efficient if your MTU is small (and you need IP layer fragmentation)= =2E But > for administrators that know they'll need efficient transport of large me= ssages, > we already have a solution: RFC 5425. Best regards, Pasi From: ext T= im > Evens [tim@evensweb.com] Sent: Monday, May 24, 2010 7:34 PM To: > turners@ieca.com; ietfc@btconnect.com; Eronen Pasi (Nokia-NRC/Helsinki) C= c: > syslog@ietf.org Subject: Re: [Syslog] AD review discuss/comments for > draft-ietf-syslog-dtls Right. I wrote the following a couple weeks ba= ck: > "=E2=80=A6 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= =2E It > would be more meaningful if the application writing the message controls = the > truncation or if the transport application sending the message onto the n= etwork > can correctly break up the message into parts to fit the transport messa= ge size > limitations. RFC5424 doesn't detail SD elements or methods for splitting > messages. Transports have size constraints and will require messages to b= e > truncated or split. For example, the CISCO-SYSLOG-MIB defines that a mes= sage > 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 h= ave to > do with the transportation of the message on the network. In my opinio= n, 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 sy= slog > receivers/collectors may require different transports. One may use UDP/D= TLS > while the other uses TCP. Therefore, the original syslog message of say 1= 480 > bytes may be written to the network twice, one using UDP/DTLS and the oth= er > 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 d= efined > 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. Clien= t > message boundaries are not preserved in the record layer (i.e., multiple = client > messages of the same ContentType MAY be coalesced into a single TLSPlaint= ext > 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 delive= ry, > whereas RFC4347 (DTLS) can use UDP which does not provide ordered deliver= y. DTLS > introduces a sequence number field in the record structure, which if > implemented for reordering, the receiver could reorder the DTLS records s= o 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 "=E2=80=A6 it may not assure that a= ll the messages > are delivered in order when mapping on the UDP transport." The reason i= s that > with TCP there is a retransmission for lost segments, whereas UDP does no= t > implement retransmissions. Therefore, if a DTLS sequence is dropped/lost = or not > received within the allotted queue buffer time, the DTLS application does= n't > have anyway of knowing if seq X1 and seq X3 can be correctly put together= =2E 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 f= it > within a single DTLS record. Thus the SYSLOG-MSG will in most cases alwa= ys be > less than 1460 bytes due to MTU DTLS/MTU limitations. The application SHO= ULD NOT > assume that using the RFC5424 recommended minimum of 480 octets is suffic= ient 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 fo= r the > DTLS implementation to know which DTLS records need to be discarded in th= e event > of packet loss. For example: FRAME-ID =3D NILVALUE / ("+" / "-") > NONZERO-DIGIT 1*15DIGIT; uint48* +/- is used to indicate more message b= locks > to come or not. "+" indicates more to follow, "-" indicates last block. = Use > NILVALUE if SYSLOG-MSG is not split across multiple DTLS records, otherwi= se 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 co= uld be > 6OCTET=3Duint48, which would reduce the overall size. Example Use: DT= LS seq > 1 - SYSLOG-FRAME-ID=3D+1001 DTLS seq 2 - SYSLOG-FRAME-ID=3D+= 1001 > --> dropped by network --> DTLS seq 3 - SYSLOG-FRAME-ID=3D+1= 001 > DTLS seq 4 - SYSLOG-FRAME-ID=3D-1001 DTLS seq 5= - > SYSLOG-FRAME-ID - DTLS seq 6 - SYSLOG-FRAME-ID - > Using a buffer/queue size of 5 DTLS records/packets, the DTLS implementat= ion > would have been holding DTLS seq 1, 2, and 4 waiting for 3. When it recei= ved 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: Pasi.Eronen@nokia.com D= ate: > 05/24/2010 04:23 AM To: turners@ieca.com, ietfc@btconnect.com CC: > syslog@ietf.org Subject: Re: [Syslog] AD review discuss/comments for > draft-ietf-syslog-dtls I haven't followed this discussion in detail, bu= t it > looks like there's some confusion about the basic "units" of transmission= =2E 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 A= s noted > in Section 5.4, "It is possible that multiple syslog messages be containe= d 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 l= imit > comes from TLS). One DTLS record must fit in one UDP datagram, but one UD= P > 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, a= ll > those records have to be in a single UDP datagram (so the syslog layer do= es not > reassemble syslog message pieces from multiple UDP datagrams -- SYSLOG-FR= AME > 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 recomme= ndation > 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 fr= om > DTLS). Best regards, Pasi ________________________________________ Fro= m: > syslog-bounces@ietf.org [syslog-bounces@ietf.org] On Behalf Of ext Sean T= urner > [turners@ieca.com] Sent: Saturday, May 22, 2010 6:16 PM To: t.petch Cc: s= yslog > Subject: Re: [Syslog] AD review discuss/comments for draft-ietf-syslog-dt= ls > t.petch wrote: > I see that this I-D had entered 'Revised I-D needed' whi= ch 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 requi= rment, > 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 bala= nce > 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 tha= t > 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 w= ay I > read his comment was that he's just asking why - he's not really requesti= ng a > change. spt _______________________________________________ Syslog maili= ng list > Syslog@ietf.org https://www.ietf.org/mailman/listinfo/syslog > _______________________________________________ Syslog mailing list > Syslog@ietf.org https://www.ietf.org/mailman/listinfo/syslog > > _______________________________________________ > Syslog mailing list > Syslog@ietf.org > https://www.ietf.org/mailman/listinfo/syslog > ---559023410-630072926-1274886812=:24171--