From tuexen@fh-muenster.de Thu Jul 30 08:24:39 2009 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 60A2F28C2BD; Thu, 30 Jul 2009 08:24:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_35=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 xvsLWZHE1sxn; Thu, 30 Jul 2009 08:24:38 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by core3.amsl.com (Postfix) with ESMTP id 5ED5D3A6B22; Thu, 30 Jul 2009 08:24:23 -0700 (PDT) Received: from [IPv6:2001:df8::16:224:36ff:feef:67d1] (unknown [IPv6:2001:df8:0:16:224:36ff:feef:67d1]) by mail-n.franken.de (Postfix) with ESMTP id 4B7141C0B4629; Thu, 30 Jul 2009 17:24:21 +0200 (CEST) From: Michael Tuexen To: "tom.petch" In-Reply-To: <000401ca111a$3bb01da0$0601a8c0@allison> X-Priority: 3 References: <4A6EB9BB.9040002@net.in.tum.de> <000401ca111a$3bb01da0$0601a8c0@allison> Message-Id: Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 30 Jul 2009 17:24:20 +0200 X-Mailer: Apple Mail (2.935.3) X-Mailman-Approved-At: Sat, 01 Aug 2009 14:41:38 -0700 Cc: Robin Seggelmann , ipfix@ietf.org, Daniel Mentz , Gerhard Muenz , syslog@ietf.org, tls@ietf.org Subject: Re: [Syslog] Missing dead peer detection in 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: Thu, 30 Jul 2009 15:24:39 -0000 Hi Tom, a question in-line. Best regards Michael On Jul 30, 2009, at 11:44 AM, tom.petch wrote: > Gerhard > > Thank you for pointing this out; it had escaped me. > > What I had thought though was that the lack of flow control with =20 > DTLS over UDP > is a problem, and that the lack of this with syslog over UDP led the =20= > syslog RFC > [RFC5424] to make syslog over TLS the RECOMMENDED transport, not, as =20= > might be > expected, syslog over UDP. So I think it is actually congestion control what you are looking for, which is provided by TCP when using SYSLOG/TLS/TCP/IP, right? > > This in turn led me to expect that syslog over DTLS over UDP would =20 > not be > acceptable to the IESG, rather that syslog over DTLS over SCTP would =20= > become the > RECOMMENDED transport. This would mean, that * SYSLOG/TLS/TCP/IP * SYSLOG/DTLS/SCTP/IP * SYSLOG/DTLS/DCCP/IP are in principle acceptable, whereas * SYSLOG/DTLS/UDP/IP is not. You would (from the congestion control perspective) have the same classification when taking out the DTLS or TLS layer, right? > > So; several thoughts. > > This is an update to the extensions RFC, RFC4366, which itself is =20 > being updated > by the TLS working group (hence my addition of them to the list) and =20= > I would > much rather have one extensions RFC rather than several. This is a =20= > good concept > and fills a need; perhaps the TLS working group would take this on. > > Flow control remains an issue which I do not think that this extension > addresses. > > Is this a security exposure? or just, like syslog over UDP, an =20 > inconvenient > truth? > > The petch-gerhards draft allows the recipient of the unidirectional =20= > flow to > initiate the DTLS 'connection', and so enables it to re-establish =20 > the connection > when anything goes wrong. This would seem an alternative to consider. > > Tom Petch > > ----- Original Message ----- > From: "Gerhard Muenz" > To: ; > Cc: "Michael Tuexen" ; "Robin Seggelmann" > ; "Daniel Mentz" > Sent: Tuesday, July 28, 2009 10:41 AM > Subject: [Syslog] Missing dead peer detection in DTLS > > > Hi, > > This mail goes to the ipfix and syslog mailing lists in order to > summarize the common issues regarding DTLS. > > IPFIX specifies support of DTLS as mandatory for transport over UDP =20= > and > SCTP in RFC5101. In SYSLOG, it is intended to standardize DTLS for > transport over UDP. > > In IPFIX, we have a first implementation of IPFIX-over-DTLS/UDP, and =20= > we > will have a first implementation of IPFIX-over-DTLS/SCTP very soon. > During this implementation effort, we found that the current > specification of DTLS/UDP has a severe flaw when used with > unidirectional protocols (like IPFIX): The sender cannot recognize if > the receiver has crashed and lost the DTLS state. > > We discuss this issue in a draft: > http://tools.ietf.org/html/draft-mentz-ipfix-dtls-recommendations-00 > http://www.ietf.org/proceedings/75/slides/ipfix-6.pdf > > I've had a look at draft-feng-syslog-transport-dtls-01 and > draft-petch-gerhards-syslog-transport-dtls-02. It seems that this > problem has not yet been covered, although the problem should be the > same for SYSLOG. > > As a solution, the DTLS Heartbeat Extension has been proposed very =20 > recently: > http://tools.ietf.org/html/draft-seggelmann-tls-dtls-heartbeat-00 > A feature patch for OpenSSL is available: > http://sctp.fh-muenster.de/dtls-patches.html#features > > So, I think that we should support this standardization initiative =20 > as it > solves our problem. For IPFIX and SYSLOG over DTLS/UDP, we then can > specify that the DTLS Heartbeat Extension MUST be implemented. > > Dan suggested to have a single document solving the DTLS issues > regarding unidirectional protocols. I think that such a document is =20= > not > needed if we have DTLS Heartbeat Extension. > > Regards, > Gerhard > > Dipl.-Ing. Gerhard M=FCnz > Chair for Network Architectures and Services (I8) > Department of Informatics > Technische Universit=E4t M=FCnchen > Boltzmannstr. 3, 85748 Garching bei M=FCnchen, Germany > Phone: +49 89 289-18008 Fax: +49 89 289-18033 > E-mail: muenz@net.in.tum.de WWW: http://www.net.in.tum.de/~muenz > > > > From hongyanfeng@huaweisymantec.com Sat Aug 1 19:08:15 2009 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 6EA6B3A683C for ; Sat, 1 Aug 2009 19:08:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.651 X-Spam-Level: * X-Spam-Status: No, score=1.651 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_91=0.6, MIME_CHARSET_FARAWAY=2.45] 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 knt9ORJ9A0Rh for ; Sat, 1 Aug 2009 19:08:14 -0700 (PDT) Received: from mta1.huaweisymantec.com (mta1.huaweisymantec.com [218.17.155.14]) by core3.amsl.com (Postfix) with ESMTP id CC3713A66B4 for ; Sat, 1 Aug 2009 19:08:13 -0700 (PDT) MIME-version: 1.0 Content-disposition: inline Content-type: text/plain; charset=gb2312 Received: from hstml02-in.huaweisymantec.com ([172.26.3.41]) by hstga01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0KNQ00KN68LPY800@hstga01-in.huaweisymantec.com> for syslog@ietf.org; Sun, 02 Aug 2009 10:08:13 +0800 (CST) Received: from huaweisymantec.com ([127.0.0.1]) by hstml02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0KNQ00BOO8LPUS00@hstml02-in.huaweisymantec.com> for syslog@ietf.org; Sun, 02 Aug 2009 10:08:13 +0800 (CST) Received: from [123.112.56.156] by hstml02-in.huaweisymantec.com (mshttpd) ; Sun, 02 Aug 2009 10:08:13 +0800 From: fenghongyan To: Gerhard Muenz Message-id: Date: Sun, 02 Aug 2009 10:08:13 +0800 X-Mailer: Sun Java(tm) System Messenger Express 6.3-8.03 (built Apr 24 2009; 32bit) Content-language: zh-CN X-Accept-Language: zh-CN Priority: normal In-reply-to: References: Content-transfer-encoding: quoted-printable Cc: syslog@ietf.org Subject: Re: [Syslog] Missing dead peer detection in DTLS (Gerhard Muenz) 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: Sun, 02 Aug 2009 02:08:15 -0000 Hi=2C Gerhard Thanks for your comments=2C I read the proposals=2C I can see it=27s a g= ood idea to solve the dtls/udp=27s flaw=2E =22time-out=22 is a solution=2C but it=27s disadvantage here is hard to = decide an appropriate least round trip times=2C A short =22time-out=22 will cost the dtls client large calculation expen= se=2E Providing a =22heart-beat=22 solution = the sender needn=27t renegotiation at each round trip time of =22heart-b= eat=22=2C which may set a longer resume-session time and renegotiation time according to its str= ategy=2E = I prefer a =22heart-beat=22 solution than a =22time-out=22 solution for = this issue=2E The only thing left here for syslog-dlts is if we need specific using =22= heart-beat=22 in a syslog-dtls proposal=3F It=27s a problem of dtls/udp=2C which can be fixed in the implementation= of dtls and as a part of dtls protocol=2E There=27s anything need syslog-dtls to do to support it=3F what=27s your= consideration=3F Thanks Linda ----- Original Mail ----- =B7=A2=BC=FE=C8=CB=3A syslog-request=40ietf=2Eorg =C8=D5=C6=DA=3A 2009=C4=EA 7=D4=C2 29=C8=D5=2C =D0=C7=C6=DA=C8=FD=2C =C9= =CF=CE=E73=3A02 =D6=F7=CC=E2=3A Syslog Digest=2C Vol 47=2C Issue 9 =CA=D5=BC=FE=C8=CB=3A syslog=40ietf=2Eorg =3E If you have received this digest without all the individual message =3E attachments you will need to update your digest options in your lis= t =3E subscription=2E To do so=2C go to = =3E = =3E https=3A//www=2Eietf=2Eorg/mailman/listinfo/syslog =3E = =3E Click the =27Unsubscribe or edit options=27 button=2C log in=2C and= set =22Get =3E MIME or Plain Text Digests=3F=22 to MIME=2E You can set this optio= n =3E globally for all the list digests you receive at this point=2E =3E = =3E = =3E = =3E Send Syslog mailing list submissions to =3E syslog=40ietf=2Eorg =3E = =3E To subscribe or unsubscribe via the World Wide Web=2C visit =3E https=3A//www=2Eietf=2Eorg/mailman/listinfo/syslog =3E or=2C via email=2C send a message with subject or body =27help=27 t= o =3E syslog-request=40ietf=2Eorg =3E = =3E You can reach the person managing the list at =3E syslog-owner=40ietf=2Eorg =3E = =3E When replying=2C please edit your Subject line so it is more specif= ic =3E than =22Re=3A Contents of Syslog digest=2E=2E=2E=22 =3E = =3E = =3E Today=27s Topics=3A =3E = =3E 1=2E Missing dead peer detection in DTLS (Gerhard Muenz) =3E = =3E = =3E -------------------------------------------------------------------= --- =3E = =3E Message=3A 1 =3E Date=3A Tue=2C 28 Jul 2009 10=3A41=3A31 +0200 =3E From=3A Gerhard Muenz =3Cmuenz=40net=2Ein=2Etum=2Ede=3E =3E Subject=3A =5BSyslog=5D Missing dead peer detection in DTLS =3E To=3A syslog=40ietf=2Eorg=2C =22ipfix=40ietf=2Eorg=22 =3Cipfix=40ie= tf=2Eorg=3E =3E Cc=3A Michael Tuexen =3Ctuexen=40fh-muenster=2Ede=3E=2C Robin Segge= lmann =3E =3Cseggelmann=40fh-muenster=2Ede=3E=2C Daniel Mentz =3Cmentz=40in=2E= tum=2Ede=3E =3E Message-ID=3A =3C4A6EB9BB=2E9040002=40net=2Ein=2Etum=2Ede=3E =3E Content-Type=3A text/plain=3B charset=3D=22iso-8859-1=22 =3E = =3E = =3E Hi=2C =3E = =3E This mail goes to the ipfix and syslog mailing lists in order to =3E summarize the common issues regarding DTLS=2E =3E = =3E IPFIX specifies support of DTLS as mandatory for transport over UDP= and =3E SCTP in RFC5101=2E In SYSLOG=2C it is intended to standardize DTLS = for =3E transport over UDP=2E =3E = =3E In IPFIX=2C we have a first implementation of IPFIX-over-DTLS/UDP=2C= and = =3E we =3E will have a first implementation of IPFIX-over-DTLS/SCTP very soon=2E= =3E During this implementation effort=2C we found that the current =3E specification of DTLS/UDP has a severe flaw when used with =3E unidirectional protocols (like IPFIX)=3A The sender cannot recogniz= e if =3E the receiver has crashed and lost the DTLS state=2E =3E = =3E We discuss this issue in a draft=3A =3E http=3A//tools=2Eietf=2Eorg/html/draft-mentz-ipfix-dtls-recommendat= ions-00 =3E http=3A//www=2Eietf=2Eorg/proceedings/75/slides/ipfix-6=2Epdf =3E = =3E I=27ve had a look at draft-feng-syslog-transport-dtls-01 and =3E draft-petch-gerhards-syslog-transport-dtls-02=2E It seems that this= =3E problem has not yet been covered=2C although the problem should be = the =3E same for SYSLOG=2E =3E = =3E As a solution=2C the DTLS Heartbeat Extension has been proposed ver= y recently=3A =3E http=3A//tools=2Eietf=2Eorg/html/draft-seggelmann-tls-dtls-heartbea= t-00 =3E A feature patch for OpenSSL is available=3A =3E http=3A//sctp=2Efh-muenster=2Ede/dtls-patches=2Ehtml=23features =3E = =3E So=2C I think that we should support this standardization initiativ= e as = =3E it =3E solves our problem=2E For IPFIX and SYSLOG over DTLS/UDP=2C we then= can =3E specify that the DTLS Heartbeat Extension MUST be implemented=2E =3E = =3E Dan suggested to have a single document solving the DTLS issues =3E regarding unidirectional protocols=2E I think that such a document = is not =3E needed if we have DTLS Heartbeat Extension=2E =3E = =3E Regards=2C =3E Gerhard =3E = =3E -- = =3E Dipl=2E-Ing=2E Gerhard M=3Fnz =3E Chair for Network Architectures and Services (I8) =3E Department of Informatics =3E Technische Universit=3Ft M=3Fnchen =3E Boltzmannstr=2E 3=2C 85748 Garching bei M=3Fnchen=2C Germany =3E Phone=3A +49 89 289-18008 Fax=3A +49 89 289-18033 =3E E-mail=3A muenz=40net=2Ein=2Etum=2Ede WWW=3A http=3A//www=2Enet=2E= in=2Etum=2Ede/=7Emuenz =3E = =3E = =3E -------------- next part -------------- =3E A non-text attachment was scrubbed=2E=2E=2E =3E Name=3A smime=2Ep7s =3E Type=3A application/x-pkcs7-signature =3E Size=3A 3467 bytes =3E Desc=3A S/MIME Cryptographic Signature =3E Url =3A =3C =3E = =3E ------------------------------ =3E = =3E =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =3E Syslog mailing list =3E Syslog=40ietf=2Eorg =3E https=3A//www=2Eietf=2Eorg/mailman/listinfo/syslog =3E = =3E = =3E End of Syslog Digest=2C Vol 47=2C Issue 9 =3E ************************************* =3E From cfinss@dial.pipex.com Sun Aug 2 03:19:35 2009 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 F1E5B3A690C; Sun, 2 Aug 2009 03:19:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.451 X-Spam-Level: X-Spam-Status: No, score=-1.451 tagged_above=-999 required=5 tests=[AWL=-0.941, BAYES_05=-1.11, J_CHICKENPOX_35=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 lxn2lNfMndAD; Sun, 2 Aug 2009 03:19:34 -0700 (PDT) Received: from mk-outboundfilter-2.mail.uk.tiscali.com (mk-outboundfilter-2.mail.uk.tiscali.com [212.74.114.38]) by core3.amsl.com (Postfix) with ESMTP id A0B693A68B3; Sun, 2 Aug 2009 03:19:33 -0700 (PDT) X-Trace: 238410600/mk-outboundfilter-2.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.105.192/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.105.192 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: ArcEAPMEdUo+vGnA/2dsb2JhbACDLTyMZ8ByCYQPBQ X-IronPort-AV: E=Sophos;i="4.43,308,1246834800"; d="scan'208";a="238410600" X-IP-Direction: IN Received: from 1cust192.tnt2.lnd9.gbr.da.uu.net (HELO allison) ([62.188.105.192]) by smtp.pipex.tiscali.co.uk with SMTP; 02 Aug 2009 11:19:33 +0100 Message-ID: <000201ca1352$42b53ba0$0601a8c0@allison> From: "tom.petch" To: "Michael Tuexen" References: <4A6EB9BB.9040002@net.in.tum.de> <000401ca111a$3bb01da0$0601a8c0@allison> Date: Sun, 2 Aug 2009 11:11:03 +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 Cc: Robin Seggelmann , ipfix@ietf.org, Daniel Mentz , Gerhard Muenz , syslog , tls@ietf.org Subject: Re: [Syslog] Missing dead peer detection in 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: Sun, 02 Aug 2009 10:19:35 -0000 Reply inline, twice Tom Petch ----- Original Message ----- From: "Michael Tuexen" To: "tom.petch" Sent: Thursday, July 30, 2009 5:24 PM a question in-line. Michael On Jul 30, 2009, at 11:44 AM, tom.petch wrote: > Gerhard > > Thank you for pointing this out; it had escaped me. > > What I had thought though was that the lack of flow control with > DTLS over UDP > is a problem, and that the lack of this with syslog over UDP led the > syslog RFC > [RFC5424] to make syslog over TLS the RECOMMENDED transport, not, as > might be > expected, syslog over UDP. So I think it is actually congestion control what you are looking for, which is provided by TCP when using SYSLOG/TLS/TCP/IP, right? For myself, no, I was not looking for or caring about congestion control, rather security. But when the syslog I-D got to the IESG, they did care about congestion, and so the syslog I-D was modified to make syslog over TLS the RECOMMENDED transport, not because it might or might not improve security but because it offered congestion control, which UDP by itself does not. > > This in turn led me to expect that syslog over DTLS over UDP would > not be > acceptable to the IESG, rather that syslog over DTLS over SCTP would > become the > RECOMMENDED transport. This would mean, that * SYSLOG/TLS/TCP/IP * SYSLOG/DTLS/SCTP/IP * SYSLOG/DTLS/DCCP/IP are in principle acceptable, whereas * SYSLOG/DTLS/UDP/IP is not. You would (from the congestion control perspective) have the same classification when taking out the DTLS or TLS layer, right? I am unclear about your second sentence, but the first one, yes, I would expect the first three to be acceptable to the IESG (which is rather important if you want an I-D to become an RFC) and the last one not to be. TLS (by using TCP), SCTP, DCCP have acceptable congestion control, DTLS and UDP do not. Tom Petch > So; several thoughts. > > This is an update to the extensions RFC, RFC4366, which itself is > being updated > by the TLS working group (hence my addition of them to the list) and > I would > much rather have one extensions RFC rather than several. This is a > good concept > and fills a need; perhaps the TLS working group would take this on. > > Flow control remains an issue which I do not think that this extension > addresses. > > Is this a security exposure? or just, like syslog over UDP, an > inconvenient > truth? > > The petch-gerhards draft allows the recipient of the unidirectional > flow to > initiate the DTLS 'connection', and so enables it to re-establish > the connection > when anything goes wrong. This would seem an alternative to consider. > > Tom Petch From muenz@net.in.tum.de Sun Aug 2 13:05:39 2009 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 3D42F3A6C55 for ; Sun, 2 Aug 2009 13:05:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 1YAYVyZIkI+S for ; Sun, 2 Aug 2009 13:05:38 -0700 (PDT) Received: from mail-out1.informatik.tu-muenchen.de (mail-out1.informatik.tu-muenchen.de [131.159.0.8]) by core3.amsl.com (Postfix) with ESMTP id C93B33A6BDF for ; Sun, 2 Aug 2009 13:03:43 -0700 (PDT) Received: from phoenix.net.informatik.tu-muenchen.de (phoenix.net.in.tum.de [131.159.14.1]) by services.net.informatik.tu-muenchen.de (Postix Mailer @ mail) with ESMTP id 2A13B48588; Sun, 2 Aug 2009 22:03:34 +0200 (CEST) Received: from [131.159.20.251] (vpn-1.net.in.tum.de [131.159.20.251]) by phoenix.net.informatik.tu-muenchen.de (Postfix) with ESMTP id F082CB6F; Sun, 2 Aug 2009 22:03:33 +0200 (CEST) Message-ID: <4A75F11B.4050201@net.in.tum.de> Date: Sun, 02 Aug 2009 22:03:39 +0200 From: Gerhard Muenz User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: fenghongyan References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070701020402040606090604" X-Virus-Scanned: ClamAV using ClamSMTP Cc: syslog@ietf.org Subject: Re: [Syslog] Missing dead peer detection in DTLS (Gerhard Muenz) 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: Sun, 02 Aug 2009 20:05:39 -0000 This is a cryptographically signed message in MIME format. --------------ms070701020402040606090604 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Linda, fenghongyan wrote: > Hi, Gerhard >=20 > Thanks for your comments, I read the proposals, I can see it's a good i= dea to solve the dtls/udp's flaw. > "time-out" is a solution, but it's disadvantage here is hard to decide = an appropriate least round trip times, > A short "time-out" will cost the dtls client large calculation expense.= Providing a "heart-beat" solution=20 > the sender needn't renegotiation at each round trip time of "heart-beat= ", which may set > a longer resume-session time and renegotiation time according to its st= rategy.=20 > I prefer a "heart-beat" solution than a "time-out" solution for this is= sue. >=20 > The only thing left here for syslog-dlts is if we need specific using "= heart-beat" in a syslog-dtls proposal? The DTLS heartbeat extension is an individual draft which has been presented in the TLS WG session on Friday. Some reactions were that such an extension could be useful, not only for DTLS but also for TLS where detecting a timed out TCP connection may take a very long time. However, it's not clear if the TLS WG will support the draft. If not, you will have problems to use it for syslog-dtls. It's the same for IPFIX. > It's a problem of dtls/udp, which can be fixed in the implementation of= dtls and as a part of dtls protocol. I share this opinion. I think that DTLS for UDP would generally profit from such an extension. Without, DTLS for UDP is of limited utility. > There's anything need syslog-dtls to do to support it? what's your cons= ideration? Not sure. We have not tried the corresponding OpenSSL patch yet. Maybe the application (e.g. syslog) has to trigger the Heartbeat. Regards, Gerhard > Thanks > Linda --=20 Dipl.-Ing. Gerhard M=FCnz Chair for Network Architectures and Services (I8) Technische Universit=E4t M=FCnchen - Department of Informatics Boltzmannstr. 3, 85748 Garching bei M=FCnchen, Germany Phone: +49 89 289-18008 Fax: +49 89 289-18033 E-mail: muenz@net.in.tum.de WWW: http://www.net.in.tum.de/~muenz --------------ms070701020402040606090604 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ6TCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5 NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb NU1341YheILcIRk13iSx0x1G/11fZU8wggNPMIICuKADAgECAhAqxerdN2XVRkUZsuk5IKdP MA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3Vs dGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNz dWluZyBDQTAeFw0wOTAyMTkxMDI5NDVaFw0xMDAyMTkxMDI5NDVaMIGQMQ4wDAYDVQQEEwVN dWVuejEQMA4GA1UEKhMHR2VyaGFyZDEWMBQGA1UEAxMNR2VyaGFyZCBNdWVuejEwMC4GCSqG SIb3DQEJARYhbXVlbnpAaW5mb3JtYXRpay51bmktdHVlYmluZ2VuLmRlMSIwIAYJKoZIhvcN AQkBFhNtdWVuekBuZXQuaW4udHVtLmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAxC8p+6KRpyQyKvT9LAxUB2m8azrci+c5oQUYac2A4WsjoqiCqi2k/wgCrCIHrN0USQeH LmcbtSWT5O+1kMai28KGUdZG5xmJ7PLuLejKlYIu2TkR8tI1Q4gyu1Gs45yn9Rf+EGWmqa/s ebjMV3tc/zrpEN2b1ls8U9rM2/h0NcUUU+g170e8DlXNOL7+bsQD+tLH5G3nlV9mZntMQ68t PaaLG4MtupHuS99YGoo0yB4rzuTxiWRKTJgqjboQL0eS9+6dxsrT01g7sOc2QtXbO45PBnsG Ra5CAMpGLrqGT1ISZIpqYrGuMH9Rv7HTR3rLygL81WMDtNCa6W5/PPMlSwIDAQABo1MwUTBB BgNVHREEOjA4gSFtdWVuekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGWBE211ZW56QG5l dC5pbi50dW0uZGUwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQBOkMsohjpIH4Mr 33zNnhc5PkzAi0RZ6UAOB28nTtfjVZ25UVLWqmLgYEszbloTd07y5PcUZhSuPuwGzEwn4XdX i3VWl6qk5VcPpyP7+b5XEY5CU1A8cqeaXS88qWyshu1dXm2ToqueRPv+E2b3GJHAciNt2Qfc T4SNWymkvUyPSjCCA08wggK4oAMCAQICECrF6t03ZdVGRRmy6Tkgp08wDQYJKoZIhvcNAQEF BQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5 MDIxOTEwMjk0NVoXDTEwMDIxOTEwMjk0NVowgZAxDjAMBgNVBAQTBU11ZW56MRAwDgYDVQQq EwdHZXJoYXJkMRYwFAYDVQQDEw1HZXJoYXJkIE11ZW56MTAwLgYJKoZIhvcNAQkBFiFtdWVu ekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGUxIjAgBgkqhkiG9w0BCQEWE211ZW56QG5l dC5pbi50dW0uZGUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDELyn7opGnJDIq 9P0sDFQHabxrOtyL5zmhBRhpzYDhayOiqIKqLaT/CAKsIges3RRJB4cuZxu1JZPk77WQxqLb woZR1kbnGYns8u4t6MqVgi7ZORHy0jVDiDK7UazjnKf1F/4QZaapr+x5uMxXe1z/OukQ3ZvW WzxT2szb+HQ1xRRT6DXvR7wOVc04vv5uxAP60sfkbeeVX2Zme0xDry09posbgy26ke5L31ga ijTIHivO5PGJZEpMmCqNuhAvR5L37p3GytPTWDuw5zZC1ds7jk8GewZFrkIAykYuuoZPUhJk impisa4wf1G/sdNHesvKAvzVYwO00Jrpbn888yVLAgMBAAGjUzBRMEEGA1UdEQQ6MDiBIW11 ZW56QGluZm9ybWF0aWsudW5pLXR1ZWJpbmdlbi5kZYETbXVlbnpAbmV0LmluLnR1bS5kZTAM BgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAE6QyyiGOkgfgyvffM2eFzk+TMCLRFnp QA4HbydO1+NVnblRUtaqYuBgSzNuWhN3TvLk9xRmFK4+7AbMTCfhd1eLdVaXqqTlVw+nI/v5 vlcRjkJTUDxyp5pdLzypbKyG7V1ebZOiq55E+/4TZvcYkcByI23ZB9xPhI1bKaS9TI9KMYID ZDCCA2ACAQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECECrF6t03ZdVGRRmy6Tkgp08wCQYFKw4DAhoFAKCCAcMwGAYJKoZIhvcNAQkDMQsGCSqG SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDkwODAyMjAwMzM5WjAjBgkqhkiG9w0BCQQxFgQU fTosh2V7q5mVQzuja5J3ceYu1cEwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggq hkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUG CSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1 aW5nIENBAhAqxerdN2XVRkUZsuk5IKdPMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAqxerdN2XVRkUZsuk5IKdP MA0GCSqGSIb3DQEBAQUABIIBAAA0qAlq5v1lGrah2u29+k9xsXLwXoN/vlvqE2mvLHkEVR2z MNLN52PGFLXGtiZyLcGJ9152RjeeCpb1a5wW9Ri/agRj1hJSPlq4OWSRo0E+35oIqrS1Iyln UhWqP9qJIkH54mR17h4kwyXxOVaH1K7ZIK8yQzKqhGaEo24jZnqFFiUenx59TrI0WwSGyWbo 7vFDv9qzR4W1Q/KApqNJYibHpNLK560mKO27X4VxgqCzTQ1iRshe6uOIr0lw/5nakQk9sD1c k9mbqpYPELgNfbB/YWIGS0D/CH8NDCOzakqLmWkie37QYIOWx/jslDpcfz2HbMpKHc6F6OGG iGAeCnwAAAAAAAA= --------------ms070701020402040606090604-- From cfinss@dial.pipex.com Mon Aug 3 04:00:50 2009 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 3B0553A6D09 for ; Mon, 3 Aug 2009 04:00:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.361 X-Spam-Level: X-Spam-Status: No, score=-2.361 tagged_above=-999 required=5 tests=[AWL=0.238, BAYES_00=-2.599] 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 q4Bnlu2qKYrP for ; Mon, 3 Aug 2009 04:00:49 -0700 (PDT) Received: from mk-outboundfilter-6.mail.uk.tiscali.com (mk-outboundfilter-6.mail.uk.tiscali.com [212.74.114.14]) by core3.amsl.com (Postfix) with ESMTP id 0A54F3A6C1D for ; Mon, 3 Aug 2009 04:00:48 -0700 (PDT) X-Trace: 128355510/mk-outboundfilter-6.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.100.236/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.100.236 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: AsYEAEtgdko+vGTs/2dsb2JhbACDLVqMTr8NCYQPBQ X-IronPort-AV: E=Sophos;i="4.43,314,1246834800"; d="scan'208";a="128355510" X-IP-Direction: IN Received: from 1cust236.tnt1.lnd9.gbr.da.uu.net (HELO allison) ([62.188.100.236]) by smtp.pipex.tiscali.co.uk with SMTP; 03 Aug 2009 12:00:48 +0100 Message-ID: <001101ca1421$2f6365c0$0601a8c0@allison> From: "tom.petch" To: "Chris Lonvick" , "syslog" References: Date: Mon, 3 Aug 2009 11:59:04 +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 Cc: pasi.eronen@nokia.com Subject: [Syslog] Matters arising was: Re: syslog WG meeting minutes (proposed) 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: Mon, 03 Aug 2009 11:00:50 -0000 Picking up on the point of commonality between DTLS for IPFIX, ISMS and syslog: - having a common statement of how to check certificates would save work here and elsewhere ie get draft-hodges-server-ident-check-00.txt to include as a minimum the cases covered in syslog-tls and get that I-D progressing onto standards track so as to use it as a normative reference (can we steal it from apps into security:-). - syslog has tls as RECOMMENDED transport at the insistence of the IESG because it has flow control and the others do not. DTLS over UDP has no flow control and so, by analogy, I would expect it to be unacceptable to the IESG ie it will have to be DTLS over SCTP that will have to be there as well or instead (something I did not think of in 2006). - having written a DTLS I-D (and looked at many more), I am inclined to agree with Wes that there will not be much in common (apart from certificate checking - see above) Tom Petch ----- Original Message ----- From: "Chris Lonvick" To: Cc: Sent: Thursday, July 30, 2009 4:50 PM Subject: [Syslog] syslog WG meeting minutes (proposed) > Hi Folks, > > Here are the meeting minutes that I took. Please send back edits if you > want anything changed. > > === > Meeting was started, blue sheets passed around, no one in jabber room > other than the people in the room. > > Chairs went through the slides. > > Q about syslog/BEEP on slide 10: We're not proposing to standardize this; > it's already RFC 3195. Since the uptake on implementation (of this RFC, > and of BEEP overall) is low, then the WG should consider moving the RFC to > HISTORIC. > > Jurgen S. gave a review of his thoughts on the proposed new charter items: > Slide 8, > MIB, OK > DHCP, has some operational value > don't need an architectural reference to be done in the IETF > Slide 9 > might be interesting to have a guideline but not sure who would commit > the time to do that > DTLS, should be done and aligned with RFC 5425 (syslog/tls) > syslog/tcp, should be very straightforward and easy to do > syslog/BEEP, declare HISTORIC > > Dan R. - Since syslog WG is proposing to do syslog/DTLS is there enough > commonality so that ISMS/DTLS and IPFIX/DTLS can re-use? > - Consensus was that this was likely. David also noted that the others > are also doing SCTP. > > Pasi E. - syslog/DTLS should be easy since it will draw directly from > syslog/TLS. > - IPFIX also working on Dead Peer Detection (DTLS Heartbeet), we should > likely support this as well. > - There were problems with the previous IPFIX/DTLS but that was because > of bad libraries in OpenSSL which have since been fixed. > > Wes H. - there is not that much commonality between the schemes because of > a lot of useage details. > > Chris and David have asked Joe Saloway to act as WG editor for the DTLS > work. > > Meeting adjurned at 10am. > > === > > Thanks, > Chris > _______________________________________________ > Syslog mailing list > Syslog@ietf.org > https://www.ietf.org/mailman/listinfo/syslog From clonvick@cisco.com Mon Aug 3 06:52:54 2009 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 E238D28C1AF for ; Mon, 3 Aug 2009 06:52:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_35=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 W1SZfkmZX82h for ; Mon, 3 Aug 2009 06:52:53 -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 B19113A6DE8 for ; Mon, 3 Aug 2009 06:52:53 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAJuIdkqrR7MV/2dsb2JhbAC6JIgpjjAFhBg X-IronPort-AV: E=Sophos;i="4.43,314,1246838400"; d="scan'208";a="359283581" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 03 Aug 2009 13:52:56 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n73DquKY012014; Mon, 3 Aug 2009 06:52:56 -0700 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 n73DquXt004466; Mon, 3 Aug 2009 13:52:56 GMT Date: Mon, 3 Aug 2009 06:52:56 -0700 (PDT) From: Chris Lonvick To: "tom.petch" In-Reply-To: <001101ca1421$2f6365c0$0601a8c0@allison> Message-ID: References: <001101ca1421$2f6365c0$0601a8c0@allison> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4345; t=1249307576; x=1250171576; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=clonvick@cisco.com; z=From:=20Chris=20Lonvick=20 |Subject:=20Re=3A=20Matters=20arising=20was=3A=20Re=3A=20[S yslog]=20syslog=20WG=20meeting=20minutes=0A=20(proposed) |Sender:=20; bh=tph1mk+7kKb3WViN7QgDi3zFJyzYLTPvqVMFtW9Pszw=; b=PS+Couywnff0kqIcZe40Y1/nDzVuelsENhrk5j6smel6PYHosS0FQCWdqN uOUQbiMP1qwBxwdIR0GOJiOqngCr/rnuh74SC4fanqH7SEDKpKhkLc8dgIDu tr4CYO44qpgG332t3nT2Fu3vxvRAIEeSG6G5WvdUEGhvj7eG4gJlQ=; Authentication-Results: sj-dkim-1; header.From=clonvick@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: syslog , pasi.eronen@nokia.com Subject: Re: [Syslog] Matters arising was: Re: syslog WG meeting minutes (proposed) 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 Aug 2009 13:52:55 -0000 Hi Tom, On Mon, 3 Aug 2009, tom.petch wrote: > Picking up on the point of commonality between DTLS for IPFIX, ISMS and syslog: > > - having a common statement of how to check certificates would save work here > and elsewhere ie get draft-hodges-server-ident-check-00.txt to include as a > minimum the cases covered in syslog-tls and get that I-D progressing onto > standards track so as to use it as a normative reference (can we steal it from > apps into security:-). Sounds good. > > - syslog has tls as RECOMMENDED transport at the insistence of the IESG because > it has flow control and the others do not. DTLS over UDP has no flow control > and so, by analogy, I would expect it to be unacceptable to the IESG ie it will > have to be DTLS over SCTP that will have to be there as well or instead > (something I did not think of in 2006). I'm not that familiar with DTLS. Can we just specify how to put syslog over it, or do we need to also state how it is to be layered above a substrate tranport such as sctp? My preference would be to just define syslog/dtls and then have a pointer back to RFC 5424 (syslog Protocol) Section 8.6. (Congestion Control) which spells out the reason for choosing properly. I'm really hoping that we don't have to create a document for anything other than syslog/dtls. > > - having written a DTLS I-D (and looked at many more), I am inclined to agree > with Wes that there will not be much in common (apart from certificate > checking - see above) If we _can_ just do XYZ/dtls (without having to go through the lower substrate definition) then the pieces of work are (imho): - state how the specification addresses the threats identified in syslog/tls, - explain certificate checking (as you note above) - explain how records will be separated. Can anyone think of anything else that needs to be defined in this work? Tom, can a document just do XYZ/dtls, or does it also _really_ need definition for the substrate? Thanks, Chris > > Tom Petch > > ----- Original Message ----- > From: "Chris Lonvick" > To: > Cc: > Sent: Thursday, July 30, 2009 4:50 PM > Subject: [Syslog] syslog WG meeting minutes (proposed) > > >> Hi Folks, >> >> Here are the meeting minutes that I took. Please send back edits if you >> want anything changed. >> >> === >> Meeting was started, blue sheets passed around, no one in jabber room >> other than the people in the room. >> >> Chairs went through the slides. >> >> Q about syslog/BEEP on slide 10: We're not proposing to standardize this; >> it's already RFC 3195. Since the uptake on implementation (of this RFC, >> and of BEEP overall) is low, then the WG should consider moving the RFC to >> HISTORIC. >> >> Jurgen S. gave a review of his thoughts on the proposed new charter items: >> Slide 8, >> MIB, OK >> DHCP, has some operational value >> don't need an architectural reference to be done in the IETF >> Slide 9 >> might be interesting to have a guideline but not sure who would commit >> the time to do that >> DTLS, should be done and aligned with RFC 5425 (syslog/tls) >> syslog/tcp, should be very straightforward and easy to do >> syslog/BEEP, declare HISTORIC >> >> Dan R. - Since syslog WG is proposing to do syslog/DTLS is there enough >> commonality so that ISMS/DTLS and IPFIX/DTLS can re-use? >> - Consensus was that this was likely. David also noted that the others >> are also doing SCTP. >> >> Pasi E. - syslog/DTLS should be easy since it will draw directly from >> syslog/TLS. >> - IPFIX also working on Dead Peer Detection (DTLS Heartbeet), we should >> likely support this as well. >> - There were problems with the previous IPFIX/DTLS but that was because >> of bad libraries in OpenSSL which have since been fixed. >> >> Wes H. - there is not that much commonality between the schemes because of >> a lot of useage details. >> >> Chris and David have asked Joe Saloway to act as WG editor for the DTLS >> work. >> >> Meeting adjurned at 10am. >> >> === >> >> Thanks, >> Chris >> _______________________________________________ >> Syslog mailing list >> Syslog@ietf.org >> https://www.ietf.org/mailman/listinfo/syslog > > From muenz@net.in.tum.de Mon Aug 3 12:41:25 2009 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 1A7C23A6A57 for ; Mon, 3 Aug 2009 12:41:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.032 X-Spam-Level: X-Spam-Status: No, score=-2.032 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 TiztT18bc2ZO for ; Mon, 3 Aug 2009 12:41:24 -0700 (PDT) Received: from mail-out1.informatik.tu-muenchen.de (mail-out1.informatik.tu-muenchen.de [131.159.0.8]) by core3.amsl.com (Postfix) with ESMTP id EEC693A6DB8 for ; Mon, 3 Aug 2009 12:41:23 -0700 (PDT) Received: from phoenix.net.informatik.tu-muenchen.de (phoenix.net.in.tum.de [131.159.14.1]) by services.net.informatik.tu-muenchen.de (Postix Mailer @ mail) with ESMTP id 3A27448588 for ; Mon, 3 Aug 2009 21:41:23 +0200 (CEST) Received: from [131.159.20.251] (vpn-1.net.in.tum.de [131.159.20.251]) by phoenix.net.informatik.tu-muenchen.de (Postfix) with ESMTP id CC9843F04 for ; Mon, 3 Aug 2009 21:41:22 +0200 (CEST) Message-ID: <4A773D6A.8000006@net.in.tum.de> Date: Mon, 03 Aug 2009 21:41:30 +0200 From: Gerhard Muenz User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: syslog@ietf.org References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030205080401010501010807" X-Virus-Scanned: ClamAV using ClamSMTP Subject: Re: [Syslog] syslog WG meeting minutes (proposed) 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 Aug 2009 19:41:25 -0000 This is a cryptographically signed message in MIME format. --------------ms030205080401010501010807 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi, Please find some comments regarding IPFIX inline. Regards, Gerhard > Hi Folks, > > > Here are the meeting minutes that I took. Please send back edits if you want anything changed. > > === > > Meeting was started, blue sheets passed around, no one in jabber room other than the people in the room. > > Chairs went through the slides. > > > Q about syslog/BEEP on slide 10: We're not proposing to standardize this; it's already RFC 3195. Since the uptake on implementation (of this RFC, and of BEEP overall) is low, then the WG should consider moving the RFC to HISTORIC. > > Jurgen S. gave a review of his thoughts on the proposed new charter items: > Slide 8, > MIB, OK > DHCP, has some operational value > don't need an architectural reference to be done in the IETF > Slide 9 > might be interesting to have a guideline but not sure who would commit > the time to do that > DTLS, should be done and aligned with RFC 5425 (syslog/tls) > syslog/tcp, should be very straightforward and easy to do > syslog/BEEP, declare HISTORIC > > > Dan R. - Since syslog WG is proposing to do syslog/DTLS is there enough commonality so that ISMS/DTLS and IPFIX/DTLS can re-use? > > - Consensus was that this was likely. David also noted that the others > are also doing SCTP. > > > Pasi E. - syslog/DTLS should be easy since it will draw directly from syslog/TLS. > > - IPFIX also working on Dead Peer Detection (DTLS Heartbeet), we should > likely support this as well. I'm not sure if this has been said in this way. Correct is: IPFIX WG is NOT working on DTLS Heartbeat. The DTLS Heartbeat extension is an individual draft located in the TLS WG. However, it is correct that we have discussed the DTLS-over-UDP dead peer detection problem (i.e., crashed Collector) in the IPFIX WG session, including the DTLS Heartbeat extension as a possible solution to this problem. > - There were problems with the previous IPFIX/DTLS but that was because > of bad libraries in OpenSSL which have since been fixed. No bad libraries. A few years ago, when we run IPFIX interops, DTLS was just not sufficiently supported by OpenSSL. So, we could not test it. > Wes H. - there is not that much commonality between the schemes because of a lot of useage details. > > Chris and David have asked Joe Saloway to act as WG editor for the DTLS work. > > Meeting adjurned at 10am. > > === > > Thanks, > Chris --------------ms030205080401010501010807 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ6TCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5 NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb NU1341YheILcIRk13iSx0x1G/11fZU8wggNPMIICuKADAgECAhAqxerdN2XVRkUZsuk5IKdP MA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3Vs dGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNz dWluZyBDQTAeFw0wOTAyMTkxMDI5NDVaFw0xMDAyMTkxMDI5NDVaMIGQMQ4wDAYDVQQEEwVN dWVuejEQMA4GA1UEKhMHR2VyaGFyZDEWMBQGA1UEAxMNR2VyaGFyZCBNdWVuejEwMC4GCSqG SIb3DQEJARYhbXVlbnpAaW5mb3JtYXRpay51bmktdHVlYmluZ2VuLmRlMSIwIAYJKoZIhvcN AQkBFhNtdWVuekBuZXQuaW4udHVtLmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAxC8p+6KRpyQyKvT9LAxUB2m8azrci+c5oQUYac2A4WsjoqiCqi2k/wgCrCIHrN0USQeH LmcbtSWT5O+1kMai28KGUdZG5xmJ7PLuLejKlYIu2TkR8tI1Q4gyu1Gs45yn9Rf+EGWmqa/s ebjMV3tc/zrpEN2b1ls8U9rM2/h0NcUUU+g170e8DlXNOL7+bsQD+tLH5G3nlV9mZntMQ68t PaaLG4MtupHuS99YGoo0yB4rzuTxiWRKTJgqjboQL0eS9+6dxsrT01g7sOc2QtXbO45PBnsG Ra5CAMpGLrqGT1ISZIpqYrGuMH9Rv7HTR3rLygL81WMDtNCa6W5/PPMlSwIDAQABo1MwUTBB BgNVHREEOjA4gSFtdWVuekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGWBE211ZW56QG5l dC5pbi50dW0uZGUwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQBOkMsohjpIH4Mr 33zNnhc5PkzAi0RZ6UAOB28nTtfjVZ25UVLWqmLgYEszbloTd07y5PcUZhSuPuwGzEwn4XdX i3VWl6qk5VcPpyP7+b5XEY5CU1A8cqeaXS88qWyshu1dXm2ToqueRPv+E2b3GJHAciNt2Qfc T4SNWymkvUyPSjCCA08wggK4oAMCAQICECrF6t03ZdVGRRmy6Tkgp08wDQYJKoZIhvcNAQEF BQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5 MDIxOTEwMjk0NVoXDTEwMDIxOTEwMjk0NVowgZAxDjAMBgNVBAQTBU11ZW56MRAwDgYDVQQq EwdHZXJoYXJkMRYwFAYDVQQDEw1HZXJoYXJkIE11ZW56MTAwLgYJKoZIhvcNAQkBFiFtdWVu ekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGUxIjAgBgkqhkiG9w0BCQEWE211ZW56QG5l dC5pbi50dW0uZGUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDELyn7opGnJDIq 9P0sDFQHabxrOtyL5zmhBRhpzYDhayOiqIKqLaT/CAKsIges3RRJB4cuZxu1JZPk77WQxqLb woZR1kbnGYns8u4t6MqVgi7ZORHy0jVDiDK7UazjnKf1F/4QZaapr+x5uMxXe1z/OukQ3ZvW WzxT2szb+HQ1xRRT6DXvR7wOVc04vv5uxAP60sfkbeeVX2Zme0xDry09posbgy26ke5L31ga ijTIHivO5PGJZEpMmCqNuhAvR5L37p3GytPTWDuw5zZC1ds7jk8GewZFrkIAykYuuoZPUhJk impisa4wf1G/sdNHesvKAvzVYwO00Jrpbn888yVLAgMBAAGjUzBRMEEGA1UdEQQ6MDiBIW11 ZW56QGluZm9ybWF0aWsudW5pLXR1ZWJpbmdlbi5kZYETbXVlbnpAbmV0LmluLnR1bS5kZTAM BgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAE6QyyiGOkgfgyvffM2eFzk+TMCLRFnp QA4HbydO1+NVnblRUtaqYuBgSzNuWhN3TvLk9xRmFK4+7AbMTCfhd1eLdVaXqqTlVw+nI/v5 vlcRjkJTUDxyp5pdLzypbKyG7V1ebZOiq55E+/4TZvcYkcByI23ZB9xPhI1bKaS9TI9KMYID ZDCCA2ACAQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECECrF6t03ZdVGRRmy6Tkgp08wCQYFKw4DAhoFAKCCAcMwGAYJKoZIhvcNAQkDMQsGCSqG SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDkwODAzMTk0MTMwWjAjBgkqhkiG9w0BCQQxFgQU G97dhILkDtk8ad3Xz5cm0nqa284wUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggq hkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUG CSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1 aW5nIENBAhAqxerdN2XVRkUZsuk5IKdPMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAqxerdN2XVRkUZsuk5IKdP MA0GCSqGSIb3DQEBAQUABIIBAC1D9wjQEtAwQJOwzA5kFpzcDnmuQ4/08wyJFKZ+/uw9TvUH OpjpIqrjhH3I3zeREO7lMo6lqj3/pyWxb4EU4olEuR6wDP/8M0Ty5hU5BTjHQCd9omqzYEPH jyhXDzBpbZiyrTVuqOmIOW+TT9pN5m23rXyoufJppAb4/jfm2FR60/aqnVK+dQbzHNRqhAai ruf9jn9JsRlGoV1u+EfoHVzqxBovm4tX5ttbkW8ytaFHSkyW9DAK3Tn8E55ALpu2eBQQGZtK X1VhwZl0e80rAh7oUGByt5TevzU9VR5tivVsKrBM3R3qNSadrQD9Z5fKZYx64dQbJM7rwnWt NJqU7k8AAAAAAAA= --------------ms030205080401010501010807-- From hongyanfeng@huaweisymantec.com Tue Aug 4 08:45:01 2009 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 413EB28C446 for ; Tue, 4 Aug 2009 08:45:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 eb9XBvUyPRMg for ; Tue, 4 Aug 2009 08:45:00 -0700 (PDT) Received: from mta2.huaweisymantec.com (unknown [218.17.155.15]) by core3.amsl.com (Postfix) with ESMTP id 86D6728C3DA for ; Tue, 4 Aug 2009 08:44:58 -0700 (PDT) MIME-version: 1.0 Content-disposition: inline Content-type: text/plain; charset=utf-8 Received: from hstml02-in.huaweisymantec.com ([172.26.3.42]) by hstga02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0KNU007D3ZQCWHA0@hstga02-in.huaweisymantec.com> for syslog@ietf.org; Tue, 04 Aug 2009 23:44:36 +0800 (CST) Received: from huaweisymantec.com ([127.0.0.1]) by hstml02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0KNU005PSZQCWU20@hstml02-in.huaweisymantec.com> for syslog@ietf.org; Tue, 04 Aug 2009 23:44:36 +0800 (CST) Received: from [221.218.205.69] by hstml02-in.huaweisymantec.com (mshttpd) ; Tue, 04 Aug 2009 23:44:36 +0800 From: fenghongyan To: Gerhard Muenz Message-id: Date: Tue, 04 Aug 2009 23:44:36 +0800 X-Mailer: Sun Java(tm) System Messenger Express 6.3-8.03 (built Apr 24 2009; 32bit) Content-language: zh-CN X-Accept-Language: zh-CN Priority: normal In-reply-to: <4A75F11B.4050201@net.in.tum.de> References: <4A75F11B.4050201@net.in.tum.de> Content-transfer-encoding: quoted-printable Cc: syslog@ietf.org Subject: [Syslog] Issues for dtls-udp Re: Missing dead peer detection in DTLS (Gerhard Muenz) 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 Aug 2009 15:45:01 -0000 Hi Gerhard=2C ----- =E5=8E=9F=E5=A7=8B=E9=82=AE=E4=BB=B6 ----- =E5=8F=91=E4=BB=B6=E4=BA=BA=3A Gerhard Muenz =3Cmuenz=40net=2Ein=2Etum=2E= de=3E =E6=97=A5=E6=9C=9F=3A 2009=E5=B9=B4 8=E6=9C=88 3=E6=97=A5=2C =E6=98=9F=E6= =9C=9F=E4=B8=80=2C =E4=B8=8A=E5=8D=884=3A03 =E4=B8=BB=E9=A2=98=3A Re=3A Missing dead peer detection in DTLS (Gerhard= Muenz) =E6=94=B6=E4=BB=B6=E4=BA=BA=3A fenghongyan =3Chongyanfeng=40huaweisymant= ec=2Ecom=3E =E6=8A=84=E9=80=81=3A syslog=40ietf=2Eorg =3E Hi Linda=2C =3E = =3E fenghongyan wrote=3A =3E =3E Hi=2C Gerhard =3E =3E = =3E =3E Thanks for your comments=2C I read the proposals=2C I can see i= t=27s a = =3E good idea to solve the dtls/udp=27s flaw=2E =3E =3E =22time-out=22 is a solution=2C but it=27s disadvantage here is= hard to = =3E decide an appropriate least round trip times=2C =3E =3E A short =22time-out=22 will cost the dtls client large calculat= ion = =3E expense=2E Providing a =22heart-beat=22 solution = =3E =3E the sender needn=27t renegotiation at each round trip time of = =3E =22heart-beat=22=2C which may set =3E =3E a longer resume-session time and renegotiation time according t= o = =3E its strategy=2E = =3E =3E I prefer a =22heart-beat=22 solution than a =22time-out=22 solu= tion for = =3E this issue=2E =3E =3E = =3E =3E The only thing left here for syslog-dlts is if we need specific= = =3E using =22heart-beat=22 in a syslog-dtls proposal=3F =3E = =3E The DTLS heartbeat extension is an individual draft which has been =3E presented in the TLS WG session on Friday=2E Some reactions were th= at such =3E an extension could be useful=2C not only for DTLS but also for TLS = where =3E detecting a timed out TCP connection may take a very long time=2E H= owever=2C =3E it=27s not clear if the TLS WG will support the draft=2E If not=2C = you will =3E have problems to use it for syslog-dtls=2E It=27s the same for IPFI= X=2E =3E = =3E =3E It=27s a problem of dtls/udp=2C which can be fixed in the = =3E implementation of dtls and as a part of dtls protocol=2E =3E = =3E I share this opinion=2E I think that DTLS for UDP would generally p= rofit =3E from such an extension=2E Without=2C DTLS for UDP is of limited uti= lity=2E =3E = =3E =3E There=27s anything need syslog-dtls to do to support it=3F what= =27s your = =3E consideration=3F =3E = =3E Not sure=2E We have not tried the corresponding OpenSSL patch yet=2E= Maybe =3E the application (e=2Eg=2E syslog) has to trigger the Heartbeat=2E =3E = yeah=2C I see that in source code has not yet support trigger for applic= ation=2E What I considered are the issues for dtls-udp=2E I don=27t know too much= of ipfix=2C are there more than one exporter need export data to one collector=3F There may many syslog sender send logs to one receiver=2C which brings u= p an issue of dtls-udp=2E I wrote it in my proposal=2C in 5=2E3 as session demultiplexing=2E = I think if the ipfix collector need support multiple exporter=2C ipfix n= eed also support session demultiplexing=2C but I didn=27t see that in your proposal=2C what=27s your consideration=3F= Linda = =3E Regards=2C =3E Gerhard =3E = =3E =3E Thanks =3E =3E Linda =3E = =3E -- = =3E Dipl=2E-Ing=2E Gerhard M=C3=BCnz =3E Chair for Network Architectures and Services (I8) =3E Technische Universit=C3=A4t M=C3=BCnchen - Department of Informatic= s =3E Boltzmannstr=2E 3=2C 85748 Garching bei M=C3=BCnchen=2C Germany =3E Phone=3A +49 89 289-18008 Fax=3A +49 89 289-18033 =3E E-mail=3A muenz=40net=2Ein=2Etum=2Ede WWW=3A http=3A//www=2Enet=2E= in=2Etum=2Ede/=7Emuenz =3E = =3E = =3E From hongyanfeng@huaweisymantec.com Tue Aug 4 08:59:21 2009 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 D32153A6B4D for ; Tue, 4 Aug 2009 08:59:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 NZdVBGIIbZWx for ; Tue, 4 Aug 2009 08:59:21 -0700 (PDT) Received: from mta2.huaweisymantec.com (unknown [218.17.155.15]) by core3.amsl.com (Postfix) with ESMTP id 16EB528C254 for ; Tue, 4 Aug 2009 08:58:43 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; charset=us-ascii Received: from hstml02-in.huaweisymantec.com ([172.26.3.42]) by hstga02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0KNV007HF0DIWHA0@hstga02-in.huaweisymantec.com> for syslog@ietf.org; Tue, 04 Aug 2009 23:58:30 +0800 (CST) Received: from huaweisymantec.com ([127.0.0.1]) by hstml02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0KNV005NU0DISU20@hstml02-in.huaweisymantec.com> for syslog@ietf.org; Tue, 04 Aug 2009 23:58:30 +0800 (CST) Received: from [221.218.205.69] by hstml02-in.huaweisymantec.com (mshttpd) ; Tue, 04 Aug 2009 23:58:30 +0800 From: fenghongyan To: Chris Lonvick Message-id: Date: Tue, 04 Aug 2009 23:58:30 +0800 X-Mailer: Sun Java(tm) System Messenger Express 6.3-8.03 (built Apr 24 2009; 32bit) Content-language: zh-CN X-Accept-Language: zh-CN Priority: normal In-reply-to: References: Cc: syslog , pasi.eronen@nokia.com Subject: Re: [Syslog] syslog WG meeting minutes (proposed) 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 Aug 2009 15:59:21 -0000 Hi Chris, I remembered that the wg will take "draft-feng-syslog-transport-dtls" as the basic start of wg's work on syslog-dtls, does it not make as the wg's decision? If my memory is wrong, I would like recommend highly that take my proposal as the start of the wg's work, since my proposal has aligned with RFC 5425 (syslog/tls). I would like also contribute myself on the work of syslog-dtls. Linda ----- Original Mail ----- > Date: Thu, 30 Jul 2009 07:50:53 -0700 (PDT) > From: Chris Lonvick > Subject: [Syslog] syslog WG meeting minutes (proposed) > To: syslog@ietf.org > Cc: pasi.eronen@nokia.com > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > Hi Folks, > > Here are the meeting minutes that I took. Please send back edits if > you > want anything changed. > > === > Meeting was started, blue sheets passed around, no one in jabber room > > other than the people in the room. > > Chairs went through the slides. > > Q about syslog/BEEP on slide 10: We're not proposing to standardize > this; > it's already RFC 3195. Since the uptake on implementation (of this > RFC, > and of BEEP overall) is low, then the WG should consider moving the > RFC to > HISTORIC. > > Jurgen S. gave a review of his thoughts on the proposed new charter items: > Slide 8, > MIB, OK > DHCP, has some operational value > don't need an architectural reference to be done in the IETF > Slide 9 > might be interesting to have a guideline but not sure who would commit > the time to do that > DTLS, should be done and aligned with RFC 5425 (syslog/tls) > syslog/tcp, should be very straightforward and easy to do > syslog/BEEP, declare HISTORIC > > Dan R. - Since syslog WG is proposing to do syslog/DTLS is there > enough > commonality so that ISMS/DTLS and IPFIX/DTLS can re-use? > - Consensus was that this was likely. David also noted that the others > are also doing SCTP. > > Pasi E. - syslog/DTLS should be easy since it will draw directly from > > syslog/TLS. > - IPFIX also working on Dead Peer Detection (DTLS Heartbeet), we should > likely support this as well. > - There were problems with the previous IPFIX/DTLS but that was because > of bad libraries in OpenSSL which have since been fixed. > > Wes H. - there is not that much commonality between the schemes > because of > a lot of useage details. > > Chris and David have asked Joe Saloway to act as WG editor for the > DTLS > work. > > Meeting adjurned at 10am. > > === > > Thanks, > Chris > > > ------------------------------ > > _______________________________________________ > Syslog mailing list > Syslog@ietf.org > https://www.ietf.org/mailman/listinfo/syslog > > > End of Syslog Digest, Vol 47, Issue 10 > ************************************** > From muenz@net.in.tum.de Tue Aug 4 09:22:55 2009 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 38BEC3A68DC for ; Tue, 4 Aug 2009 09:22:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.105 X-Spam-Level: X-Spam-Status: No, score=-2.105 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 b9NbOt4hdbZL for ; Tue, 4 Aug 2009 09:22:54 -0700 (PDT) Received: from mail-out1.informatik.tu-muenchen.de (mail-out1.informatik.tu-muenchen.de [131.159.0.8]) by core3.amsl.com (Postfix) with ESMTP id 2E6D13A691D for ; Tue, 4 Aug 2009 09:22:54 -0700 (PDT) Received: from phoenix.net.informatik.tu-muenchen.de (phoenix.net.in.tum.de [131.159.14.1]) by services.net.informatik.tu-muenchen.de (Postix Mailer @ mail) with ESMTP id 0CE3C481D8; Tue, 4 Aug 2009 18:22:55 +0200 (CEST) Received: from [131.159.20.251] (vpn-1.net.in.tum.de [131.159.20.251]) by phoenix.net.informatik.tu-muenchen.de (Postfix) with ESMTP id C0A3D509D; Tue, 4 Aug 2009 18:22:54 +0200 (CEST) Message-ID: <4A786066.2080505@net.in.tum.de> Date: Tue, 04 Aug 2009 18:23:02 +0200 From: Gerhard Muenz User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: fenghongyan References: <4A75F11B.4050201@net.in.tum.de> In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090402070803050406050600" X-Virus-Scanned: ClamAV using ClamSMTP Cc: syslog@ietf.org Subject: Re: [Syslog] Issues for dtls-udp Re: Missing dead peer detection in DTLS (Gerhard Muenz) 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 Aug 2009 16:22:55 -0000 This is a cryptographically signed message in MIME format. --------------ms090402070803050406050600 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi, >> > There's anything need syslog-dtls to do to support it? what's your >> consideration? >> >> Not sure. We have not tried the corresponding OpenSSL patch yet. Maybe >> the application (e.g. syslog) has to trigger the Heartbeat. >> > yeah, I see that in source code has not yet support trigger for application. > What I considered are the issues for dtls-udp. I don't know too much of ipfix, > are there more than one exporter need export data to one collector? Yes, there may be multiple Exporters sending to one Collector. The definition of IPFIX Transport Sessions allows to distinguish the different sessions. In the case of UDP, the Transport Session is defined by the IP-5-Tuple plus the Observation Domain ID, which is a field in the IPFIX message header. In the case of DTLS/UDP, the Collector needs to maintain the DTLS state for each Exporter. A good question is when to remove the DTLS state because there is no connection termination. We remove it after a certain time without receiving any packets from the Exporter. However, we cannot be sure if the Exporter has also deleted its DTLS state :( This is another situation where DTLS Heartbeat extension is useful. > There may many syslog sender send logs to one receiver, which brings up an issue of dtls-udp. > I wrote it in my proposal, in 5.3 as session demultiplexing. > > I think if the ipfix collector need support multiple exporter, ipfix need also support session demultiplexing, > but I didn't see that in your proposal, what's your consideration? You talk about draft-mentz-ipfix-dtls-recommendations-00? Note that this draft does not play the same role as draft-feng-syslog-transport-dtls-01 because IPFIX over DTLS/UDP is already standardized in RFC5101. draft-mentz-ipfix-dtls-recommendations-00 only covers DTLS specific implementation problems and might be considered as an update of RFC 5153 (IPFIX Implementation Guidelines). Gerhard --------------ms090402070803050406050600 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ6TCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5 NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb NU1341YheILcIRk13iSx0x1G/11fZU8wggNPMIICuKADAgECAhAqxerdN2XVRkUZsuk5IKdP MA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3Vs dGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNz dWluZyBDQTAeFw0wOTAyMTkxMDI5NDVaFw0xMDAyMTkxMDI5NDVaMIGQMQ4wDAYDVQQEEwVN dWVuejEQMA4GA1UEKhMHR2VyaGFyZDEWMBQGA1UEAxMNR2VyaGFyZCBNdWVuejEwMC4GCSqG SIb3DQEJARYhbXVlbnpAaW5mb3JtYXRpay51bmktdHVlYmluZ2VuLmRlMSIwIAYJKoZIhvcN AQkBFhNtdWVuekBuZXQuaW4udHVtLmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAxC8p+6KRpyQyKvT9LAxUB2m8azrci+c5oQUYac2A4WsjoqiCqi2k/wgCrCIHrN0USQeH LmcbtSWT5O+1kMai28KGUdZG5xmJ7PLuLejKlYIu2TkR8tI1Q4gyu1Gs45yn9Rf+EGWmqa/s ebjMV3tc/zrpEN2b1ls8U9rM2/h0NcUUU+g170e8DlXNOL7+bsQD+tLH5G3nlV9mZntMQ68t PaaLG4MtupHuS99YGoo0yB4rzuTxiWRKTJgqjboQL0eS9+6dxsrT01g7sOc2QtXbO45PBnsG Ra5CAMpGLrqGT1ISZIpqYrGuMH9Rv7HTR3rLygL81WMDtNCa6W5/PPMlSwIDAQABo1MwUTBB BgNVHREEOjA4gSFtdWVuekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGWBE211ZW56QG5l dC5pbi50dW0uZGUwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQBOkMsohjpIH4Mr 33zNnhc5PkzAi0RZ6UAOB28nTtfjVZ25UVLWqmLgYEszbloTd07y5PcUZhSuPuwGzEwn4XdX i3VWl6qk5VcPpyP7+b5XEY5CU1A8cqeaXS88qWyshu1dXm2ToqueRPv+E2b3GJHAciNt2Qfc T4SNWymkvUyPSjCCA08wggK4oAMCAQICECrF6t03ZdVGRRmy6Tkgp08wDQYJKoZIhvcNAQEF BQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5 MDIxOTEwMjk0NVoXDTEwMDIxOTEwMjk0NVowgZAxDjAMBgNVBAQTBU11ZW56MRAwDgYDVQQq EwdHZXJoYXJkMRYwFAYDVQQDEw1HZXJoYXJkIE11ZW56MTAwLgYJKoZIhvcNAQkBFiFtdWVu ekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGUxIjAgBgkqhkiG9w0BCQEWE211ZW56QG5l dC5pbi50dW0uZGUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDELyn7opGnJDIq 9P0sDFQHabxrOtyL5zmhBRhpzYDhayOiqIKqLaT/CAKsIges3RRJB4cuZxu1JZPk77WQxqLb woZR1kbnGYns8u4t6MqVgi7ZORHy0jVDiDK7UazjnKf1F/4QZaapr+x5uMxXe1z/OukQ3ZvW WzxT2szb+HQ1xRRT6DXvR7wOVc04vv5uxAP60sfkbeeVX2Zme0xDry09posbgy26ke5L31ga ijTIHivO5PGJZEpMmCqNuhAvR5L37p3GytPTWDuw5zZC1ds7jk8GewZFrkIAykYuuoZPUhJk impisa4wf1G/sdNHesvKAvzVYwO00Jrpbn888yVLAgMBAAGjUzBRMEEGA1UdEQQ6MDiBIW11 ZW56QGluZm9ybWF0aWsudW5pLXR1ZWJpbmdlbi5kZYETbXVlbnpAbmV0LmluLnR1bS5kZTAM BgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAE6QyyiGOkgfgyvffM2eFzk+TMCLRFnp QA4HbydO1+NVnblRUtaqYuBgSzNuWhN3TvLk9xRmFK4+7AbMTCfhd1eLdVaXqqTlVw+nI/v5 vlcRjkJTUDxyp5pdLzypbKyG7V1ebZOiq55E+/4TZvcYkcByI23ZB9xPhI1bKaS9TI9KMYID ZDCCA2ACAQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECECrF6t03ZdVGRRmy6Tkgp08wCQYFKw4DAhoFAKCCAcMwGAYJKoZIhvcNAQkDMQsGCSqG SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDkwODA0MTYyMzAyWjAjBgkqhkiG9w0BCQQxFgQU DsrSLipDJzPVK2g6rAgwjZ3QEWIwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggq hkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUG CSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1 aW5nIENBAhAqxerdN2XVRkUZsuk5IKdPMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAqxerdN2XVRkUZsuk5IKdP MA0GCSqGSIb3DQEBAQUABIIBABDcXciHsOGHlNMFWz/NP4Q8EBpnixGh1QrFXFLW/DeNYwly 3PVNstFn6nlCm4EfUwXA+0BD47xg51qR31OJ8rjIporqf2eEiFFSiJN+rUwnUCCcDG2joVic C1kdcWvqvqeNXlEhsWdI6BpgT6lQkiIJ3WEpKovXlbml2lScRC7aBSuuUoMnlKp7S5xB8OjR rLyKltIdtwvcQQofB+2tkC32q+txs9Pl+gPv4iWzEFAcak0ItXw6oiGW3UUKfpL/xKQEU3BF wOi6tGsOG9DErb8vNOoNukw994opEJJXaHHXbPawbg9g9AgofMJhvfkzZFnwZmYQTqBIJZOP /B2roRsAAAAAAAA= --------------ms090402070803050406050600-- From hongyanfeng@huaweisymantec.com Wed Aug 5 02:17:56 2009 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 AE5FE3A67ED for ; Wed, 5 Aug 2009 02:17:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 hWCiHf-OtDlY for ; Wed, 5 Aug 2009 02:17:55 -0700 (PDT) Received: from mta2.huaweisymantec.com (unknown [218.17.155.15]) by core3.amsl.com (Postfix) with ESMTP id B62AC3A6B87 for ; Wed, 5 Aug 2009 02:17:55 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; charset=us-ascii Received: from hstml02-in.huaweisymantec.com ([172.26.3.42]) by hstga02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0KNW00LAPCG3BE90@hstga02-in.huaweisymantec.com> for syslog@ietf.org; Wed, 05 Aug 2009 17:16:51 +0800 (CST) Received: from huaweisymantec.com ([127.0.0.1]) by hstml02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0KNW00CTFCG36410@hstml02-in.huaweisymantec.com> for syslog@ietf.org; Wed, 05 Aug 2009 17:16:51 +0800 (CST) Received: from [10.27.154.136] by hstml02-in.huaweisymantec.com (mshttpd); Wed, 05 Aug 2009 17:16:51 +0800 From: fenghongyan To: Gerhard Muenz Message-id: Date: Wed, 05 Aug 2009 17:16:51 +0800 X-Mailer: Sun Java(tm) System Messenger Express 6.3-8.03 (built Apr 24 2009; 32bit) Content-language: zh-CN X-Accept-Language: zh-CN Priority: normal In-reply-to: <4A786066.2080505@net.in.tum.de> References: <4A75F11B.4050201@net.in.tum.de> <4A786066.2080505@net.in.tum.de> Cc: syslog@ietf.org Subject: Re: [Syslog] Issues for dtls-udp Re: Missing dead peer detection in DTLS (Gerhard Muenz) 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 Aug 2009 09:17:56 -0000 Hi, > The definition of IPFIX Transport Sessions allows to distinguish the > different sessions. In the case of UDP, the Transport Session is defined > by the IP-5-Tuple plus the Observation Domain ID, which is a field in > the IPFIX message header. > In the case of DTLS/UDP, the Collector needs to maintain the DTLS state > for each Exporter. In the case of UDP, the application can get message through udp directly. But for DTLS/UDP, each session maintains the DTLS state for each Exporter, and DTLS has no idea about which session is for which exporter. Which need application maintains, like using IP-5-Tuple plus the Observation Domain ID mapping to each session. > > A good question is when to remove the DTLS state because there is no > connection termination. We remove it after a certain time without > receiving any packets from the Exporter. However, we cannot be sure if > the Exporter has also deleted its DTLS state :( > This is another situation where DTLS Heartbeat extension is useful. I share this opinion. "timeout" can also work for it. > > There may many syslog sender send logs to one receiver, which > brings up an issue of dtls-udp. > > I wrote it in my proposal, in 5.3 as session demultiplexing. > > > > I think if the ipfix collector need support multiple exporter, > ipfix need also support session demultiplexing, > > but I didn't see that in your proposal, what's your consideration? > > You talk about draft-mentz-ipfix-dtls-recommendations-00? > Note that this draft does not play the same role as > draft-feng-syslog-transport-dtls-01 because IPFIX over DTLS/UDP is > already standardized in RFC5101. > draft-mentz-ipfix-dtls-recommendations-00 only covers DTLS specific > implementation problems and might be considered as an update of RFC 5153 > (IPFIX Implementation Guidelines). > I mean that is the application need to implement when using DTLS/UDP as transport, which is the issue of DTLS/UDP, I stated in my proposal, but I didn't see you add any comments on it:(. That is why I asked if you have any other consideration. I asked for your valuable comments. Thanks Linda > Gerhard > From tuexen@fh-muenster.de Wed Aug 5 05:35:19 2009 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 EFEFB3A6B84; Wed, 5 Aug 2009 05:35:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.169 X-Spam-Level: X-Spam-Status: No, score=0.169 tagged_above=-999 required=5 tests=[AWL=-2.169, BAYES_00=-2.599, HOST_EQ_DIP_TDIAL=2.144, HOST_MISMATCH_NET=0.311, J_CHICKENPOX_35=0.6, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1] 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 9gOAb9nhQ9-O; Wed, 5 Aug 2009 05:35:13 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by core3.amsl.com (Postfix) with ESMTP id 9F7823A6B82; Wed, 5 Aug 2009 05:35:09 -0700 (PDT) Received: from [192.168.1.100] (p508FD425.dip.t-dialin.net [80.143.212.37]) by mail-n.franken.de (Postfix) with ESMTP id 4919A1C0B4619; Wed, 5 Aug 2009 14:35:09 +0200 (CEST) From: Michael Tuexen To: "tom.petch" In-Reply-To: <000201ca1352$42b53ba0$0601a8c0@allison> X-Priority: 3 References: <4A6EB9BB.9040002@net.in.tum.de> <000401ca111a$3bb01da0$0601a8c0@allison> <000201ca1352$42b53ba0$0601a8c0@allison> Message-Id: <2534D5E9-2595-427A-86FD-562890F0D74B@fh-muenster.de> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Wed, 5 Aug 2009 14:35:07 +0200 X-Mailer: Apple Mail (2.935.3) X-Mailman-Approved-At: Wed, 05 Aug 2009 08:02:16 -0700 Cc: Robin Seggelmann , ipfix@ietf.org, Daniel Mentz , Gerhard Muenz , syslog , tls@ietf.org Subject: Re: [Syslog] Missing dead peer detection in 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 Aug 2009 12:35:19 -0000 Hi Tom, understood. Thanks for the clarification. Best regards Michael On Aug 2, 2009, at 11:11 AM, tom.petch wrote: > Reply inline, twice > > Tom Petch > > ----- Original Message ----- > From: "Michael Tuexen" > To: "tom.petch" > Sent: Thursday, July 30, 2009 5:24 PM > > a question in-line. > > Michael > > On Jul 30, 2009, at 11:44 AM, tom.petch wrote: > >> Gerhard >> >> Thank you for pointing this out; it had escaped me. >> >> What I had thought though was that the lack of flow control with >> DTLS over UDP >> is a problem, and that the lack of this with syslog over UDP led the >> syslog RFC >> [RFC5424] to make syslog over TLS the RECOMMENDED transport, not, as >> might be >> expected, syslog over UDP. > > So I think it is actually congestion control what you are looking > for, which is provided by TCP when using SYSLOG/TLS/TCP/IP, right? > > > For myself, no, I was not looking for or caring about congestion > control, rather > security. > > But when the syslog I-D got to the IESG, they did care about > congestion, and so > the syslog I-D was modified to make syslog over TLS the RECOMMENDED > transport, > not because it might or might not improve security but because it > offered congestion control, which UDP by itself does not. > >> >> This in turn led me to expect that syslog over DTLS over UDP would >> not be >> acceptable to the IESG, rather that syslog over DTLS over SCTP would >> become the >> RECOMMENDED transport. > > This would mean, that > * SYSLOG/TLS/TCP/IP > * SYSLOG/DTLS/SCTP/IP > * SYSLOG/DTLS/DCCP/IP > are in principle acceptable, whereas > * SYSLOG/DTLS/UDP/IP > is not. > You would (from the congestion control perspective) have the same > classification when taking out the DTLS or TLS layer, right? > > > I am unclear about your second sentence, but the first one, yes, I > would expect > the first three to be acceptable to the IESG (which is rather > important if you > want an I-D to become an RFC) and the last one not to be. TLS (by > using TCP), > SCTP, DCCP have acceptable congestion control, DTLS and UDP do not. > > Tom Petch > >> So; several thoughts. >> >> This is an update to the extensions RFC, RFC4366, which itself is >> being updated >> by the TLS working group (hence my addition of them to the list) and >> I would >> much rather have one extensions RFC rather than several. This is a >> good concept >> and fills a need; perhaps the TLS working group would take this on. >> >> Flow control remains an issue which I do not think that this >> extension >> addresses. >> >> Is this a security exposure? or just, like syslog over UDP, an >> inconvenient >> truth? >> >> The petch-gerhards draft allows the recipient of the unidirectional >> flow to >> initiate the DTLS 'connection', and so enables it to re-establish >> the connection >> when anything goes wrong. This would seem an alternative to >> consider. >> >> Tom Petch > > > From cfinss@dial.pipex.com Wed Aug 5 09:33:34 2009 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 447A13A7182 for ; Wed, 5 Aug 2009 09:33:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.951 X-Spam-Level: X-Spam-Status: No, score=-1.951 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, J_CHICKENPOX_35=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 xP1fN+NhTahz for ; Wed, 5 Aug 2009 09:33:33 -0700 (PDT) Received: from mk-outboundfilter-5.mail.uk.tiscali.com (mk-outboundfilter-5.mail.uk.tiscali.com [212.74.114.1]) by core3.amsl.com (Postfix) with ESMTP id 2B51E3A718B for ; Wed, 5 Aug 2009 09:33:33 -0700 (PDT) X-Trace: 185290679/mk-outboundfilter-5.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.100.17/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.100.17 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: Ap0EAK5QeUo+vGQR/2dsb2JhbACDL40zxUYJhA8F X-IronPort-AV: E=Sophos;i="4.43,329,1246834800"; d="scan'208";a="185290679" X-IP-Direction: IN Received: from 1cust17.tnt1.lnd9.gbr.da.uu.net (HELO allison) ([62.188.100.17]) by smtp.pipex.tiscali.co.uk with SMTP; 05 Aug 2009 17:33:34 +0100 Message-ID: <001301ca15e1$ff494fe0$0601a8c0@allison> From: "tom.petch" To: "Chris Lonvick" References: <001101ca1421$2f6365c0$0601a8c0@allison> Date: Wed, 5 Aug 2009 17:32:10 +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 Cc: syslog , pasi.eronen@nokia.com Subject: Re: [Syslog] Matters arising was: Re: syslog WG meeting minutes (proposed) 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: Wed, 05 Aug 2009 16:33:34 -0000 ----- Original Message ----- From: "Chris Lonvick" To: "tom.petch" Cc: "syslog" ; Sent: Monday, August 03, 2009 3:52 PM > On Mon, 3 Aug 2009, tom.petch wrote: > > > Picking up on the point of commonality between DTLS for IPFIX, ISMS and syslog: > > > > - having a common statement of how to check certificates would save work here > > and elsewhere ie get draft-hodges-server-ident-check-00.txt to include as a > > minimum the cases covered in syslog-tls and get that I-D progressing onto > > standards track so as to use it as a normative reference (can we steal it from > > apps into security:-). > > Sounds good. > > > > > - syslog has tls as RECOMMENDED transport at the insistence of the IESG because > > it has flow control and the others do not. DTLS over UDP has no flow control > > and so, by analogy, I would expect it to be unacceptable to the IESG ie it will > > have to be DTLS over SCTP that will have to be there as well or instead > > (something I did not think of in 2006). > > I'm not that familiar with DTLS. Can we just specify how to put syslog > over it, or do we need to also state how it is to be layered above a > substrate tranport such as sctp? My preference would be to just define > syslog/dtls and then have a pointer back to RFC 5424 (syslog Protocol) > Section 8.6. (Congestion Control) which spells out the reason for choosing > properly. I'm really hoping that we don't have to create a document for > anything other than syslog/dtls. > > > - having written a DTLS I-D (and looked at many more), I am inclined to agree > > with Wes that there will not be much in common (apart from certificate > > checking - see above) > > If we _can_ just do XYZ/dtls (without having to go through the lower > substrate definition) then the pieces of work are (imho): > - state how the specification addresses the threats identified in > syslog/tls, > - explain certificate checking (as you note above) > - explain how records will be separated. > > Can anyone think of anything else that needs to be defined in this work? > > Tom, can a document just do XYZ/dtls, or does it also _really_ need > definition for the substrate? I can write such a document, but will the IESG accept it? I don't know; I was surprised at Magnus's DISCUSS two years ago on syslog-protocol that led us to RECOMMEND a TLS transport, as opposed to UDP, on the grounds that it offered congestion control and I doubt that concerns about congestion have decreased since then. So I am anticipating that syslog over DTLS with no mention of underlying transport cannot be RECOMMENDED; perhaps a question for our AD to ponder, and bounce off his transport area opposite numbers. As to other points, my list, of what xxx-over-DTLS must consider is - authentication - connection set up - connection termination - choice of ciphersuite - choice of (D)TLS extensions - delineation of datagrams - invoking DTLS - fragmentation and nowadays I must add - congestion control. Tom Petch > Thanks, > Chris > > > > > Tom Petch From ietfdbh@comcast.net Wed Aug 5 13:16:00 2009 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 5F8BC3A6C1F for ; Wed, 5 Aug 2009 13:16:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.473 X-Spam-Level: X-Spam-Status: No, score=-0.473 tagged_above=-999 required=5 tests=[AWL=0.907, BAYES_00=-2.599, J_CHICKENPOX_35=0.6, RCVD_IN_SORBS_WEB=0.619] 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 XxQrbLHaoesV for ; Wed, 5 Aug 2009 13:15:59 -0700 (PDT) Received: from QMTA06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [76.96.62.56]) by core3.amsl.com (Postfix) with ESMTP id 153C83A7212 for ; Wed, 5 Aug 2009 13:15:58 -0700 (PDT) Received: from OMTA22.westchester.pa.mail.comcast.net ([76.96.62.73]) by QMTA06.westchester.pa.mail.comcast.net with comcast id Qg1K1c0041ap0As56kG2VH; Wed, 05 Aug 2009 20:16:02 +0000 Received: from Harrington73653 ([212.17.134.226]) by OMTA22.westchester.pa.mail.comcast.net with comcast id QkHp1c00B4tEd043ikHtVd; Wed, 05 Aug 2009 20:18:08 +0000 From: "David Harrington" To: "'tom.petch'" , "'Chris Lonvick'" References: <001101ca1421$2f6365c0$0601a8c0@allison> <001301ca15e1$ff494fe0$0601a8c0@allison> Date: Wed, 5 Aug 2009 22:15:39 +0200 Message-ID: <015c01ca1609$8ba20b90$db000a0a@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: AcoV6oHv+uvSQ5YKTnWcXbICGOcCjQAHWYDA In-Reply-To: <001301ca15e1$ff494fe0$0601a8c0@allison> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Cc: 'syslog' , pasi.eronen@nokia.com Subject: Re: [Syslog] Matters arising was: Re: syslog WG meeting minutes(proposed) 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 Aug 2009 20:16:00 -0000 Hi, To clarify a point ... syslog/tls is not simply RECOMMENDED; it is MANDATORY TO IMPLEMENT. syslog/dtls will be an optional transport; we do not need to RECOMMEND it. Implementers can decide for themselves whether to implement it. I agree that the IESG may not approve it with congestion control considerations. dbh > -----Original Message----- > From: syslog-bounces@ietf.org > [mailto:syslog-bounces@ietf.org] On Behalf Of tom.petch > Sent: Wednesday, August 05, 2009 5:32 PM > To: Chris Lonvick > Cc: syslog; pasi.eronen@nokia.com > Subject: Re: [Syslog] Matters arising was: Re: syslog WG > meeting minutes(proposed) > > ----- Original Message ----- > From: "Chris Lonvick" > To: "tom.petch" > Cc: "syslog" ; > Sent: Monday, August 03, 2009 3:52 PM > > > On Mon, 3 Aug 2009, tom.petch wrote: > > > > > Picking up on the point of commonality between DTLS for > IPFIX, ISMS and > syslog: > > > > > > - having a common statement of how to check certificates > would save work > here > > > and elsewhere ie get > draft-hodges-server-ident-check-00.txt to include as a > > > minimum the cases covered in syslog-tls and get that I-D > progressing onto > > > standards track so as to use it as a normative reference > (can we steal it > from > > > apps into security:-). > > > > Sounds good. > > > > > > > > - syslog has tls as RECOMMENDED transport at the > insistence of the IESG > because > > > it has flow control and the others do not. DTLS over UDP > has no flow > control > > > and so, by analogy, I would expect it to be unacceptable > to the IESG ie it > will > > > have to be DTLS over SCTP that will have to be there as > well or instead > > > (something I did not think of in 2006). > > > > I'm not that familiar with DTLS. Can we just specify how > to put syslog > > over it, or do we need to also state how it is to be layered above a > > substrate tranport such as sctp? My preference would be to > just define > > syslog/dtls and then have a pointer back to RFC 5424 > (syslog Protocol) > > Section 8.6. (Congestion Control) which spells out the > reason for choosing > > properly. I'm really hoping that we don't have to create a > document for > > anything other than syslog/dtls. > > > > > - having written a DTLS I-D (and looked at many more), I > am inclined to > agree > > > with Wes that there will not be much in common (apart > from certificate > > > checking - see above) > > > > If we _can_ just do XYZ/dtls (without having to go through the lower > > substrate definition) then the pieces of work are (imho): > > - state how the specification addresses the threats identified in > > syslog/tls, > > - explain certificate checking (as you note above) > > - explain how records will be separated. > > > > Can anyone think of anything else that needs to be defined > in this work? > > > > Tom, can a document just do XYZ/dtls, or does it also _really_ need > > definition for the substrate? > > I can write such a document, but will the IESG accept it? I > don't know; I was > surprised at Magnus's DISCUSS two years ago on > syslog-protocol that led us to > RECOMMEND a TLS transport, as opposed to UDP, on the grounds that it > offered congestion control and I doubt that concerns about > congestion have > decreased since then. > > So I am anticipating that syslog over DTLS with no mention of > underlying > transport cannot be RECOMMENDED; perhaps a question for our > AD to ponder, and > bounce off his transport area opposite numbers. > > As to other points, my list, of what xxx-over-DTLS must consider is > - authentication > - connection set up > - connection termination > - choice of ciphersuite > - choice of (D)TLS extensions > - delineation of datagrams > - invoking DTLS > - fragmentation > and nowadays I must add > - congestion control. > > Tom Petch > > > Thanks, > > Chris > > > > > > > > Tom Petch > > > _______________________________________________ > Syslog mailing list > Syslog@ietf.org > https://www.ietf.org/mailman/listinfo/syslog > From ietfdbh@comcast.net Wed Aug 5 13:35:06 2009 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 C00DC3A723D for ; Wed, 5 Aug 2009 13:35:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.227 X-Spam-Level: X-Spam-Status: No, score=-1.227 tagged_above=-999 required=5 tests=[AWL=0.754, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619] 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 Mgw9qBy3ZUAZ for ; Wed, 5 Aug 2009 13:35:05 -0700 (PDT) Received: from QMTA04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [76.96.62.40]) by core3.amsl.com (Postfix) with ESMTP id C528D28C622 for ; Wed, 5 Aug 2009 13:34:02 -0700 (PDT) Received: from OMTA14.westchester.pa.mail.comcast.net ([76.96.62.60]) by QMTA04.westchester.pa.mail.comcast.net with comcast id Qb911c0011HzFnQ54ka626; Wed, 05 Aug 2009 20:34:06 +0000 Received: from Harrington73653 ([212.17.134.226]) by OMTA14.westchester.pa.mail.comcast.net with comcast id QkZn1c0014tEd043akZrcB; Wed, 05 Aug 2009 20:34:04 +0000 From: "David Harrington" To: "'fenghongyan'" , "'Chris Lonvick'" References: Date: Wed, 5 Aug 2009 22:33:45 +0200 Message-ID: <015d01ca160c$12181ff0$db000a0a@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: AcoVHI8+g7/gYcHqTbS7ulUhDq8RZwA7RKGg In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Cc: 'syslog' , pasi.eronen@nokia.com Subject: Re: [Syslog] syslog WG meeting minutes (proposed) 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 Aug 2009 20:35:06 -0000 Hi, There is a proposed charter that the WG and the area director are considering. It proposes starting the dtls work from the feng draft, which is the closer of the two drafts to the syslog/tls draft. It is a chairs' decision who should be WG editors, and Chris and I propose Joe Saloway - editor of the syslog/tls draft and chair of TLS WG - as our recommendation. We will need commitment from members of the WG to contribute to completion of the WG effort. dbh > -----Original Message----- > From: syslog-bounces@ietf.org > [mailto:syslog-bounces@ietf.org] On Behalf Of fenghongyan > Sent: Tuesday, August 04, 2009 5:59 PM > To: Chris Lonvick > Cc: syslog; pasi.eronen@nokia.com > Subject: Re: [Syslog] syslog WG meeting minutes (proposed) > > Hi Chris, > > I remembered that the wg will take > "draft-feng-syslog-transport-dtls" as the basic start of wg's > work on syslog-dtls, > does it not make as the wg's decision? > > If my memory is wrong, I would like recommend highly that > take my proposal as the start of the wg's work, since my > proposal has aligned with RFC 5425 (syslog/tls). I would like > also contribute myself on the work of syslog-dtls. > > > > Linda > > ----- Original Mail ----- > > Date: Thu, 30 Jul 2009 07:50:53 -0700 (PDT) > > From: Chris Lonvick > > Subject: [Syslog] syslog WG meeting minutes (proposed) > > To: syslog@ietf.org > > Cc: pasi.eronen@nokia.com > > Message-ID: > > > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > > > Hi Folks, > > > > Here are the meeting minutes that I took. Please send > back edits if > > you > > want anything changed. > > > > === > > Meeting was started, blue sheets passed around, no one in > jabber room > > > > other than the people in the room. > > > > Chairs went through the slides. > > > > Q about syslog/BEEP on slide 10: We're not proposing to > standardize > > this; > > it's already RFC 3195. Since the uptake on implementation > (of this > > RFC, > > and of BEEP overall) is low, then the WG should consider > moving the > > RFC to > > HISTORIC. > > > > Jurgen S. gave a review of his thoughts on the proposed > new charter items: > > Slide 8, > > MIB, OK > > DHCP, has some operational value > > don't need an architectural reference to be done in the IETF > > Slide 9 > > might be interesting to have a guideline but not sure > who would commit > > the time to do that > > DTLS, should be done and aligned with RFC 5425 (syslog/tls) > > syslog/tcp, should be very straightforward and easy to do > > syslog/BEEP, declare HISTORIC > > > > Dan R. - Since syslog WG is proposing to do syslog/DTLS is there > > enough > > commonality so that ISMS/DTLS and IPFIX/DTLS can re-use? > > - Consensus was that this was likely. David also noted > that the others > > are also doing SCTP. > > > > Pasi E. - syslog/DTLS should be easy since it will draw > directly from > > > > syslog/TLS. > > - IPFIX also working on Dead Peer Detection (DTLS > Heartbeet), we should > > likely support this as well. > > - There were problems with the previous IPFIX/DTLS but > that was because > > of bad libraries in OpenSSL which have since been fixed. > > > > Wes H. - there is not that much commonality between the schemes > > because of > > a lot of useage details. > > > > Chris and David have asked Joe Saloway to act as WG editor for the > > DTLS > > work. > > > > Meeting adjurned at 10am. > > > > === > > > > Thanks, > > Chris > > > > > > ------------------------------ > > > > _______________________________________________ > > Syslog mailing list > > Syslog@ietf.org > > https://www.ietf.org/mailman/listinfo/syslog > > > > > > End of Syslog Digest, Vol 47, Issue 10 > > ************************************** > > > _______________________________________________ > Syslog mailing list > Syslog@ietf.org > https://www.ietf.org/mailman/listinfo/syslog > From ietfdbh@comcast.net Wed Aug 5 13:37:35 2009 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 6D5B93A7234 for ; Wed, 5 Aug 2009 13:37:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.178 X-Spam-Level: X-Spam-Status: No, score=-1.178 tagged_above=-999 required=5 tests=[AWL=0.202, BAYES_00=-2.599, J_CHICKENPOX_35=0.6, RCVD_IN_SORBS_WEB=0.619] 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 1mxiVQaY+7QD for ; Wed, 5 Aug 2009 13:37:34 -0700 (PDT) Received: from QMTA02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [76.96.62.24]) by core3.amsl.com (Postfix) with ESMTP id 2D7DA3A6BC1 for ; Wed, 5 Aug 2009 13:37:34 -0700 (PDT) Received: from OMTA07.westchester.pa.mail.comcast.net ([76.96.62.59]) by QMTA02.westchester.pa.mail.comcast.net with comcast id Qbkj1c0071GhbT852kddWl; Wed, 05 Aug 2009 20:37:37 +0000 Received: from Harrington73653 ([212.17.134.226]) by OMTA07.westchester.pa.mail.comcast.net with comcast id QkdH1c0064tEd043TkdLfF; Wed, 05 Aug 2009 20:37:35 +0000 From: "David Harrington" To: "'David Harrington'" , "'tom.petch'" , "'Chris Lonvick'" References: <001101ca1421$2f6365c0$0601a8c0@allison><001301ca15e1$ff494fe0$0601a8c0@allison> <015c01ca1609$8ba20b90$db000a0a@china.huawei.com> Date: Wed, 5 Aug 2009 22:37:15 +0200 Message-ID: <015e01ca160c$8fe6b2c0$db000a0a@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: AcoV6oHv+uvSQ5YKTnWcXbICGOcCjQAHWYDAAAEj3iA= In-Reply-To: <015c01ca1609$8ba20b90$db000a0a@china.huawei.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Cc: 'syslog' , pasi.eronen@nokia.com Subject: Re: [Syslog] Matters arising was: Re: syslog WG meetingminutes(proposed) 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 Aug 2009 20:37:35 -0000 whoops /with/without/ dbh > -----Original Message----- > From: syslog-bounces@ietf.org > [mailto:syslog-bounces@ietf.org] On Behalf Of David Harrington > Sent: Wednesday, August 05, 2009 10:16 PM > To: 'tom.petch'; 'Chris Lonvick' > Cc: 'syslog'; pasi.eronen@nokia.com > Subject: Re: [Syslog] Matters arising was: Re: syslog WG > meetingminutes(proposed) > > Hi, > > To clarify a point ... > syslog/tls is not simply RECOMMENDED; it is MANDATORY TO IMPLEMENT. > > syslog/dtls will be an optional transport; we do not need to RECOMMEND > it. > Implementers can decide for themselves whether to implement it. > I agree that the IESG may not approve it with congestion control > considerations. > > dbh > > > -----Original Message----- > > From: syslog-bounces@ietf.org > > [mailto:syslog-bounces@ietf.org] On Behalf Of tom.petch > > Sent: Wednesday, August 05, 2009 5:32 PM > > To: Chris Lonvick > > Cc: syslog; pasi.eronen@nokia.com > > Subject: Re: [Syslog] Matters arising was: Re: syslog WG > > meeting minutes(proposed) > > > > ----- Original Message ----- > > From: "Chris Lonvick" > > To: "tom.petch" > > Cc: "syslog" ; > > Sent: Monday, August 03, 2009 3:52 PM > > > > > On Mon, 3 Aug 2009, tom.petch wrote: > > > > > > > Picking up on the point of commonality between DTLS for > > IPFIX, ISMS and > > syslog: > > > > > > > > - having a common statement of how to check certificates > > would save work > > here > > > > and elsewhere ie get > > draft-hodges-server-ident-check-00.txt to include as a > > > > minimum the cases covered in syslog-tls and get that I-D > > progressing onto > > > > standards track so as to use it as a normative reference > > (can we steal it > > from > > > > apps into security:-). > > > > > > Sounds good. > > > > > > > > > > > - syslog has tls as RECOMMENDED transport at the > > insistence of the IESG > > because > > > > it has flow control and the others do not. DTLS over UDP > > has no flow > > control > > > > and so, by analogy, I would expect it to be unacceptable > > to the IESG ie it > > will > > > > have to be DTLS over SCTP that will have to be there as > > well or instead > > > > (something I did not think of in 2006). > > > > > > I'm not that familiar with DTLS. Can we just specify how > > to put syslog > > > over it, or do we need to also state how it is to be layered above > a > > > substrate tranport such as sctp? My preference would be to > > just define > > > syslog/dtls and then have a pointer back to RFC 5424 > > (syslog Protocol) > > > Section 8.6. (Congestion Control) which spells out the > > reason for choosing > > > properly. I'm really hoping that we don't have to create a > > document for > > > anything other than syslog/dtls. > > > > > > > - having written a DTLS I-D (and looked at many more), I > > am inclined to > > agree > > > > with Wes that there will not be much in common (apart > > from certificate > > > > checking - see above) > > > > > > If we _can_ just do XYZ/dtls (without having to go through the > lower > > > substrate definition) then the pieces of work are (imho): > > > - state how the specification addresses the threats identified in > > > syslog/tls, > > > - explain certificate checking (as you note above) > > > - explain how records will be separated. > > > > > > Can anyone think of anything else that needs to be defined > > in this work? > > > > > > Tom, can a document just do XYZ/dtls, or does it also _really_ > need > > > definition for the substrate? > > > > I can write such a document, but will the IESG accept it? I > > don't know; I was > > surprised at Magnus's DISCUSS two years ago on > > syslog-protocol that led us to > > RECOMMEND a TLS transport, as opposed to UDP, on the grounds that it > > offered congestion control and I doubt that concerns about > > congestion have > > decreased since then. > > > > So I am anticipating that syslog over DTLS with no mention of > > underlying > > transport cannot be RECOMMENDED; perhaps a question for our > > AD to ponder, and > > bounce off his transport area opposite numbers. > > > > As to other points, my list, of what xxx-over-DTLS must consider is > > - authentication > > - connection set up > > - connection termination > > - choice of ciphersuite > > - choice of (D)TLS extensions > > - delineation of datagrams > > - invoking DTLS > > - fragmentation > > and nowadays I must add > > - congestion control. > > > > Tom Petch > > > > > Thanks, > > > Chris > > > > > > > > > > > Tom Petch > > > > > > _______________________________________________ > > 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 muenz@net.in.tum.de Thu Aug 6 13:31:32 2009 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 23EF43A691F for ; Thu, 6 Aug 2009 13:31:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.375 X-Spam-Level: X-Spam-Status: No, score=-1.375 tagged_above=-999 required=5 tests=[AWL=-0.615, BAYES_05=-1.11, HELO_EQ_DE=0.35] 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 Rg0pSM05Yt0B for ; Thu, 6 Aug 2009 13:31:31 -0700 (PDT) Received: from mail-out1.informatik.tu-muenchen.de (mail-out1.informatik.tu-muenchen.de [131.159.0.8]) by core3.amsl.com (Postfix) with ESMTP id 504F83A69C6 for ; Thu, 6 Aug 2009 13:31:30 -0700 (PDT) Received: from phoenix.net.informatik.tu-muenchen.de (phoenix.net.in.tum.de [131.159.14.1]) by services.net.informatik.tu-muenchen.de (Postix Mailer @ mail) with ESMTP id B7DC9486B6 for ; Thu, 6 Aug 2009 22:31:31 +0200 (CEST) Received: from [131.159.20.251] (vpn-1.net.in.tum.de [131.159.20.251]) by phoenix.net.informatik.tu-muenchen.de (Postfix) with ESMTP id 91BEE2DB3 for ; Thu, 6 Aug 2009 22:31:31 +0200 (CEST) Message-ID: <4A7B3DAE.906@net.in.tum.de> Date: Thu, 06 Aug 2009 22:31:42 +0200 From: Gerhard Muenz User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: syslog@ietf.org References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080502010908040909020004" X-Virus-Scanned: ClamAV using ClamSMTP Subject: Re: [Syslog] Matters arising was: Re: syslog WG meeting minutes(proposed) 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, 06 Aug 2009 20:31:32 -0000 This is a cryptographically signed message in MIME format. --------------ms080502010908040909020004 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi, It seems that syslog is struggling with issues IPFIX has already gone through. It might be worth looking at RFC5101 and the wording in Section 10.3 about IPFIX-over-UDP: http://tools.ietf.org/html/rfc5101#section-10.3.1 Regards, Gerhard > > Hi, > > To clarify a point ... > syslog/tls is not simply RECOMMENDED; it is MANDATORY TO IMPLEMENT. > > syslog/dtls will be an optional transport; we do not need to RECOMMEND > it. > Implementers can decide for themselves whether to implement it. > I agree that the IESG may not approve it with congestion control > considerations. > > dbh > --------------ms080502010908040909020004 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ6TCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5 NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb NU1341YheILcIRk13iSx0x1G/11fZU8wggNPMIICuKADAgECAhAqxerdN2XVRkUZsuk5IKdP MA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3Vs dGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNz dWluZyBDQTAeFw0wOTAyMTkxMDI5NDVaFw0xMDAyMTkxMDI5NDVaMIGQMQ4wDAYDVQQEEwVN dWVuejEQMA4GA1UEKhMHR2VyaGFyZDEWMBQGA1UEAxMNR2VyaGFyZCBNdWVuejEwMC4GCSqG SIb3DQEJARYhbXVlbnpAaW5mb3JtYXRpay51bmktdHVlYmluZ2VuLmRlMSIwIAYJKoZIhvcN AQkBFhNtdWVuekBuZXQuaW4udHVtLmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAxC8p+6KRpyQyKvT9LAxUB2m8azrci+c5oQUYac2A4WsjoqiCqi2k/wgCrCIHrN0USQeH LmcbtSWT5O+1kMai28KGUdZG5xmJ7PLuLejKlYIu2TkR8tI1Q4gyu1Gs45yn9Rf+EGWmqa/s ebjMV3tc/zrpEN2b1ls8U9rM2/h0NcUUU+g170e8DlXNOL7+bsQD+tLH5G3nlV9mZntMQ68t PaaLG4MtupHuS99YGoo0yB4rzuTxiWRKTJgqjboQL0eS9+6dxsrT01g7sOc2QtXbO45PBnsG Ra5CAMpGLrqGT1ISZIpqYrGuMH9Rv7HTR3rLygL81WMDtNCa6W5/PPMlSwIDAQABo1MwUTBB BgNVHREEOjA4gSFtdWVuekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGWBE211ZW56QG5l dC5pbi50dW0uZGUwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQBOkMsohjpIH4Mr 33zNnhc5PkzAi0RZ6UAOB28nTtfjVZ25UVLWqmLgYEszbloTd07y5PcUZhSuPuwGzEwn4XdX i3VWl6qk5VcPpyP7+b5XEY5CU1A8cqeaXS88qWyshu1dXm2ToqueRPv+E2b3GJHAciNt2Qfc T4SNWymkvUyPSjCCA08wggK4oAMCAQICECrF6t03ZdVGRRmy6Tkgp08wDQYJKoZIhvcNAQEF BQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5 MDIxOTEwMjk0NVoXDTEwMDIxOTEwMjk0NVowgZAxDjAMBgNVBAQTBU11ZW56MRAwDgYDVQQq EwdHZXJoYXJkMRYwFAYDVQQDEw1HZXJoYXJkIE11ZW56MTAwLgYJKoZIhvcNAQkBFiFtdWVu ekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGUxIjAgBgkqhkiG9w0BCQEWE211ZW56QG5l dC5pbi50dW0uZGUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDELyn7opGnJDIq 9P0sDFQHabxrOtyL5zmhBRhpzYDhayOiqIKqLaT/CAKsIges3RRJB4cuZxu1JZPk77WQxqLb woZR1kbnGYns8u4t6MqVgi7ZORHy0jVDiDK7UazjnKf1F/4QZaapr+x5uMxXe1z/OukQ3ZvW WzxT2szb+HQ1xRRT6DXvR7wOVc04vv5uxAP60sfkbeeVX2Zme0xDry09posbgy26ke5L31ga ijTIHivO5PGJZEpMmCqNuhAvR5L37p3GytPTWDuw5zZC1ds7jk8GewZFrkIAykYuuoZPUhJk impisa4wf1G/sdNHesvKAvzVYwO00Jrpbn888yVLAgMBAAGjUzBRMEEGA1UdEQQ6MDiBIW11 ZW56QGluZm9ybWF0aWsudW5pLXR1ZWJpbmdlbi5kZYETbXVlbnpAbmV0LmluLnR1bS5kZTAM BgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAE6QyyiGOkgfgyvffM2eFzk+TMCLRFnp QA4HbydO1+NVnblRUtaqYuBgSzNuWhN3TvLk9xRmFK4+7AbMTCfhd1eLdVaXqqTlVw+nI/v5 vlcRjkJTUDxyp5pdLzypbKyG7V1ebZOiq55E+/4TZvcYkcByI23ZB9xPhI1bKaS9TI9KMYID ZDCCA2ACAQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECECrF6t03ZdVGRRmy6Tkgp08wCQYFKw4DAhoFAKCCAcMwGAYJKoZIhvcNAQkDMQsGCSqG SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDkwODA2MjAzMTQyWjAjBgkqhkiG9w0BCQQxFgQU qQAR1bhSlbXUY6ezCNfQK+2Qn1cwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggq hkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUG CSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1 aW5nIENBAhAqxerdN2XVRkUZsuk5IKdPMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAqxerdN2XVRkUZsuk5IKdP MA0GCSqGSIb3DQEBAQUABIIBAJfWxrlP8nKxEMRWNfLoa7CG47uy3oXG/FNkZUbqVcE6dUp6 KAsKdEAoKBrJQl9lLqjrNgYgwmncYc+Q7V6gyN+QZEwsCHe0keje1Yd5Zn4iQh8ydU06m4pt moqYwJjHFqiaI5gJH1XzNrMY0pEWkvW+LD4jD36uvWogwA6FLtebYkl91UkgvkEF/dXA7ggE v2IdI7Idfw3jjFtlHUeHyB+7aNWDfBuWrIKrX0IzlvVKeNb66k3Jle7Im/3bXiJpkhilfjpU R5v4QBOo1kV5avjj1K/WeGTWPWxiozwRjbG0qKA2XkhjlZ58m+Wf3PJfcbyWZdRpeqiUOHpJ GMARooEAAAAAAAA= --------------ms080502010908040909020004-- From clonvick@cisco.com Thu Aug 6 13:45:47 2009 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 24F5B3A6E23 for ; Thu, 6 Aug 2009 13:45:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.539 X-Spam-Level: X-Spam-Status: No, score=-6.539 tagged_above=-999 required=5 tests=[AWL=0.060, 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 fh-KPFycUj2G for ; Thu, 6 Aug 2009 13:45:46 -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 40CF63A6A2A for ; Thu, 6 Aug 2009 13:45:46 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAF/eekqrR7PD/2dsb2JhbAC5RYgqkBwFhBg X-IronPort-AV: E=Sophos;i="4.43,336,1246838400"; d="scan'208";a="362069250" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 06 Aug 2009 20:45:37 +0000 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n76Kjbqa013898; Thu, 6 Aug 2009 13:45:37 -0700 Received: from sjc-cde-011.cisco.com (sjc-cde-011.cisco.com [171.69.16.68]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id n76Kjbv8019803; Thu, 6 Aug 2009 20:45:37 GMT Date: Thu, 6 Aug 2009 13:45:37 -0700 (PDT) From: Chris Lonvick To: Gerhard Muenz In-Reply-To: <4A7B3DAE.906@net.in.tum.de> Message-ID: References: <4A7B3DAE.906@net.in.tum.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1158; t=1249591537; x=1250455537; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=clonvick@cisco.com; z=From:=20Chris=20Lonvick=20 |Subject:=20Re=3A=20[Syslog]=20Matters=20arising=20was=3A=2 0Re=3A=20syslog=20WG=20meeting=20minutes(proposed) |Sender:=20; bh=O/51pmdw3PO0NjMtHh8l9GrYz/HvPP8+b8CLsdFugD4=; b=JartghKQ2Dp/44mo82u0uiDach0QPl/Xfaz9qygdWEn1dVtpJbttrcpHp6 VrtlHS8oV+mKmZYKPtJxOkOnbDxsLqLrQbmiVxarhTAYh2rs+eKLI/lEReso 4A4EtAFC5F; Authentication-Results: sj-dkim-3; header.From=clonvick@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: syslog@ietf.org Subject: Re: [Syslog] Matters arising was: Re: syslog WG meeting minutes(proposed) 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, 06 Aug 2009 20:45:47 -0000 Hi Gerhard, syslog has already gone through that. http://tools.ietf.org/html/rfc5424#section-8.6 The issue at hand is how to position XYZ/dtls with respect to the same set of circumstances. syslog, ipfix and isms will all need to address that and likely will need to be consistent. As David is saying, syslog/dtls will be an optional transport and will probably carry the same verbiage as was written in 8.6 of RFC 5424. Regards, Chris On Thu, 6 Aug 2009, Gerhard Muenz wrote: > > Hi, > > It seems that syslog is struggling with issues IPFIX has already gone > through. It might be worth looking at RFC5101 and the wording in Section > 10.3 about IPFIX-over-UDP: > http://tools.ietf.org/html/rfc5101#section-10.3.1 > > Regards, > Gerhard > >> >> Hi, >> >> To clarify a point ... >> syslog/tls is not simply RECOMMENDED; it is MANDATORY TO IMPLEMENT. >> >> syslog/dtls will be an optional transport; we do not need to RECOMMEND >> it. >> Implementers can decide for themselves whether to implement it. >> I agree that the IESG may not approve it with congestion control >> considerations. >> >> dbh >> > From clonvick@cisco.com Thu Aug 6 14:00:10 2009 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 850393A677C for ; Thu, 6 Aug 2009 14:00:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.549 X-Spam-Level: X-Spam-Status: No, score=-6.549 tagged_above=-999 required=5 tests=[AWL=0.050, 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 JDhZ-lYum7op for ; Thu, 6 Aug 2009 14:00:09 -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 9617228C147 for ; Thu, 6 Aug 2009 13:59:26 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAGvhekqrR7PD/2dsb2JhbAC5MIgqkB0FhBg X-IronPort-AV: E=Sophos;i="4.43,336,1246838400"; d="scan'208";a="193326729" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 06 Aug 2009 20:59:29 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n76KxTJ7006065 for ; Thu, 6 Aug 2009 13:59:29 -0700 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 n76KxTBP028740 for ; Thu, 6 Aug 2009 20:59:29 GMT Date: Thu, 6 Aug 2009 13:59:29 -0700 (PDT) From: Chris Lonvick To: syslog@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1886; t=1249592369; x=1250456369; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=clonvick@cisco.com; z=From:=20Chris=20Lonvick=20 |Subject:=20revised=20draft=20WG=20meeting=20minutes |Sender:=20; bh=BoD9KspBeIbQbO7t/G8FzWZC5klfsSzrHHTVjMaFj3o=; b=C8O4JjLuwTZiUc9MyX4uixVyPp5y9DRExZm+1i9QNVDxCh9ImpUzNYtf7k C2EHc+vwje1n98oPoQaluA96BzP3PUtRimSt3e46JNCzSZz3I7NpAhyyOa7d LNeZ3nQ5C0; Authentication-Results: sj-dkim-3; header.From=clonvick@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Subject: [Syslog] revised draft WG meeting minutes 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, 06 Aug 2009 21:00:10 -0000 Hi Folks, Thanks to Gerhard and Linda for corrections and notes. Please take a look at these minutes. === Meeting was started, blue sheets passed around, no one in jabber room other than the people in the room. Chairs went through the slides. Q about syslog/BEEP on slide 10: We're not proposing to standardize this; it's already RFC 3195. Since the uptake on implementation (of this RFC, and of BEEP overall) is low, then the WG should consider moving the RFC to HISTORIC. Jurgen S. gave a review of his thoughts on the proposed new charter items: Slide 8, MIB, OK DHCP, has some operational value don't need an architectural reference to be done in the IETF Slide 9 might be interesting to have a guideline but not sure who would commit the time to do that DTLS, should be done and aligned with RFC 5425 (syslog/tls) syslog/tcp, should be very straightforward and easy to do syslog/BEEP, declare HISTORIC Dan R. - Since syslog WG is proposing to do syslog/DTLS is there enough commonality so that ISMS/DTLS and IPFIX/DTLS can re-use? - Consensus was that this was likely. David also noted that the others are also doing SCTP. Pasi E. - syslog/DTLS should be easy since it will draw directly from syslog/TLS - IPFIX is also interested in Dead Peer Detection (DTLS Heartbeet), we should likely support this as well. - There were problems with a previous interoperability test of IPFIX/DTLS but that was because OpenSSL didn't fully support dtls. The current version does. Wes H. - there is not that much commonality between the schemes because of a lot of useage details. Chris and David have asked Joe Saloway to act as WG editor for the DTLS work. We will need commitment from WG members to review and comment on this work. Meeting adjurned at 10am. === Regards, Chris From Pasi.Eronen@nokia.com Fri Aug 7 02:27:36 2009 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 C281A3A6957 for ; Fri, 7 Aug 2009 02:27:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.979 X-Spam-Level: X-Spam-Status: No, score=-5.979 tagged_above=-999 required=5 tests=[AWL=0.620, 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 gx74oGuZXAlP for ; Fri, 7 Aug 2009 02:27:36 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 863103A6AF4 for ; Fri, 7 Aug 2009 02:27:35 -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 n779RLcr013608; Fri, 7 Aug 2009 12:27:26 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 7 Aug 2009 12:27:29 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Fri, 7 Aug 2009 12:27:29 +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; Fri, 7 Aug 2009 11:27:29 +0200 From: To: Date: Fri, 7 Aug 2009 11:27:28 +0200 Thread-Topic: [Syslog] Missing dead peer detection in DTLS Thread-Index: AcoTWsAkXIgIs4w1SvO/Dig4S3/5FwD5VXDw Message-ID: <808FD6E27AD4884E94820BC333B2DB773A72364277@NOK-EUMSG-01.mgdnok.nokia.com> References: <4A6EB9BB.9040002@net.in.tum.de> <000401ca111a$3bb01da0$0601a8c0@allison> <000201ca1352$42b53ba0$0601a8c0@allison> In-Reply-To: <000201ca1352$42b53ba0$0601a8c0@allison> 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: 07 Aug 2009 09:27:29.0571 (UTC) FILETIME=[48D4F730:01CA1741] X-Nokia-AV: Clean Cc: syslog@ietf.org Subject: Re: [Syslog] Missing dead peer detection in 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, 07 Aug 2009 09:27:36 -0000 [trimming Cc list to just syslog] Tom Petch wrote: > > This would mean, that > > * SYSLOG/TLS/TCP/IP > > * SYSLOG/DTLS/SCTP/IP > > * SYSLOG/DTLS/DCCP/IP > > are in principle acceptable, whereas > > * SYSLOG/DTLS/UDP/IP > > is not. > > You would (from the congestion control perspective) have the same > > classification when taking out the DTLS or TLS layer, right? >=20 > > I am unclear about your second sentence, but the first one, yes, I > would expect the first three to be acceptable to the IESG (which is > rather important if you want an I-D to become an RFC) and the last > one not to be. TLS (by using TCP), SCTP, DCCP have acceptable > congestion control, DTLS and UDP do not. Well, syslog-over-UDP was acceptable to IESG, and was published as=20 RFC 5426 couple of months ago. Syslog-over-UDP is not the mandatory-to-implement or recommended transport for in RFC 5424, due to both congestion control and security reasons. Syslog-over-DTLS-over-UDP would have the same challenges in congestion control, so probably it wouldn't be the mandatory-to-implement or recommended transport either. But that doesn't prevent it from being published as RFC. Best regards, Pasi From Pasi.Eronen@nokia.com Fri Aug 7 02:35:32 2009 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 CCB7028C0FA for ; Fri, 7 Aug 2009 02:35:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.01 X-Spam-Level: X-Spam-Status: No, score=-6.01 tagged_above=-999 required=5 tests=[AWL=0.589, 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 WGsKcLWRldyz for ; Fri, 7 Aug 2009 02:35:32 -0700 (PDT) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 466CF28C0DD for ; Fri, 7 Aug 2009 02:35:31 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx06.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n779ZDw6000520; Fri, 7 Aug 2009 12:35:14 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 7 Aug 2009 12:35:19 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Fri, 7 Aug 2009 12:35:18 +0300 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.106]) by nok-am1mhub-04.mgdnok.nokia.com ([65.54.30.8]) with mapi; Fri, 7 Aug 2009 11:35:18 +0200 From: To: , Date: Fri, 7 Aug 2009 11:35:17 +0200 Thread-Topic: Matters arising was: Re: [Syslog] syslog WG meeting minutes (proposed) Thread-Index: AcoV6n3AW24KNqB4TXWOgJYMlf1S2wBV08zA Message-ID: <808FD6E27AD4884E94820BC333B2DB773A7236429D@NOK-EUMSG-01.mgdnok.nokia.com> References: <001101ca1421$2f6365c0$0601a8c0@allison> <001301ca15e1$ff494fe0$0601a8c0@allison> In-Reply-To: <001301ca15e1$ff494fe0$0601a8c0@allison> 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: 07 Aug 2009 09:35:18.0640 (UTC) FILETIME=[606B3700:01CA1742] X-Nokia-AV: Clean Cc: syslog@ietf.org Subject: Re: [Syslog] Matters arising was: Re: syslog WG meeting minutes (proposed) 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, 07 Aug 2009 09:35:32 -0000 Tom Petch wrote: > > Tom, can a document just do XYZ/dtls, or does it also _really_ need > > definition for the substrate? >=20 > I can write such a document, but will the IESG accept it? I don't > know; I was surprised at Magnus's DISCUSS two years ago on > syslog-protocol that led us to RECOMMEND a TLS transport, as opposed > to UDP, on the grounds that it offered congestion control and I > doubt that concerns about congestion have decreased since then. >=20 > So I am anticipating that syslog over DTLS with no mention of > underlying transport cannot be RECOMMENDED; perhaps a question for > our AD to ponder, and bounce off his transport area opposite > numbers. >=20 > As to other points, my list, of what xxx-over-DTLS must consider is > - authentication > - connection set up > - connection termination > - choice of ciphersuite > - choice of (D)TLS extensions > - delineation of datagrams > - invoking DTLS > - fragmentation > and nowadays I must add > - congestion control. About half of these seem to depend on the underlying transport protocol (UDP/DCCP/SCTP/etc.) somehow, so I don't think a generic XYZ-over-DTLS-over-anything document is really possible. (But naturally e.g. both UDP and SCTP could be covered in the same document, so this doesn't have to lead to explosion in the number of internet-drafts...:-) Best regards, Pasi From cfinss@dial.pipex.com Fri Aug 7 07:16:05 2009 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 BC0493A6976 for ; Fri, 7 Aug 2009 07:16:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.284 X-Spam-Level: X-Spam-Status: No, score=-2.284 tagged_above=-999 required=5 tests=[AWL=0.315, BAYES_00=-2.599] 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 41vt-UMtH8f2 for ; Fri, 7 Aug 2009 07:16:05 -0700 (PDT) Received: from mk-outboundfilter-6.mail.uk.tiscali.com (mk-outboundfilter-6.mail.uk.tiscali.com [212.74.114.14]) by core3.amsl.com (Postfix) with ESMTP id AA62E3A6951 for ; Fri, 7 Aug 2009 07:16:04 -0700 (PDT) X-Trace: 129543363/mk-outboundfilter-6.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.100.40/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.100.40 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: ApwEAP/Te0o+vGQo/2dsb2JhbACDMI05vyQJhA0F X-IronPort-AV: E=Sophos;i="4.43,341,1246834800"; d="scan'208";a="129543363" X-IP-Direction: IN Received: from 1cust40.tnt1.lnd9.gbr.da.uu.net (HELO allison) ([62.188.100.40]) by smtp.pipex.tiscali.co.uk with SMTP; 07 Aug 2009 15:16:04 +0100 Message-ID: <001c01ca1761$1dc1ff00$0601a8c0@allison> From: "tom.petch" To: , "Chris Lonvick" , References: <4A6EB9BB.9040002@net.in.tum.de><000401ca111a$3bb01da0$0601a8c0@allison> <000201ca1352$42b53ba0$0601a8c0@allison> <808FD6E27AD4884E94820BC333B2DB773A72364277@NOK-EUMSG-01.mgdnok.nokia.com> Date: Fri, 7 Aug 2009 14:40:29 +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 Cc: syslog@ietf.org Subject: [Syslog] Choice of substrate wasRe: Missing dead peer detection in 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: Fri, 07 Aug 2009 14:16:05 -0000 ----- Original Message ----- From: To: Cc: Sent: Friday, August 07, 2009 11:27 AM Well, syslog-over-UDP was acceptable to IESG, and was published as RFC 5426 couple of months ago. Syslog-over-UDP is not the mandatory-to-implement or recommended transport for in RFC 5424, due to both congestion control and security reasons. Syslog-over-DTLS-over-UDP would have the same challenges in congestion control, so probably it wouldn't be the mandatory-to-implement or recommended transport either. But that doesn't prevent it from being published as RFC. Pasi Thanks for that. One trigger for this discussion was Chris's question, as to whether we could write a syslog-over-DTLS I-D, or whether it would be syslog-over-DTLS-over-UDP or whether it would be syslog-over-DTLS-over-UDPandSCTP .... Obviously an I-D covering more than one substrate could RECOMMEND the one with flow control but, for myself, I would prefer just to cover a single substrate, namely UDP (seeing that as the one most likely to be implemented). So I see a difference from the syslog-over-UDP case in that there is a close alternative to syslog-over-DTLS-over-UDP which does provide flow control ie syslog-over-DTLS-over-SCTP (or DCCP), an alternative that is much closer than in the choice of UDP versus TLS, so we might be encouraged to include a substrate that did offer flow control. Worst case scenario would be to produce a UDP only I-D and then get told late in the day that we have to retrofit SCTP and/or DCCP in order to address the concerns of the then Transport Area reviewers. I appreciate that it is impossible to predict the views of such reviewers in a year or two's time but the reassurance I was looking for was that you thought that such an action was unlikely. Looking forward, I think that Chris's preference would be to have syslog over DTLS with no reference to substrate. Mmmmmmm, I think that that would leave too many issues uncovered, but I think that the question of substrate(s) is the discussion we now need to have, with Joe's views, as potential editor, being of particular interest to me. Tom Petch Best regards, Pasi From clonvick@cisco.com Mon Aug 31 10:56:58 2009 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 91C5928C23C for ; Mon, 31 Aug 2009 10:56:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.556 X-Spam-Level: X-Spam-Status: No, score=-6.556 tagged_above=-999 required=5 tests=[AWL=0.043, 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 Ne+w43cX3aMd for ; Mon, 31 Aug 2009 10:56:57 -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 CFCA128C36A for ; Mon, 31 Aug 2009 10:56:46 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAI+rm0qrR7PE/2dsb2JhbADBfYhBAY58BYQa X-IronPort-AV: E=Sophos;i="4.44,306,1249257600"; d="scan'208";a="379053715" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 31 Aug 2009 17:56:58 +0000 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n7VHuwJx025768 for ; Mon, 31 Aug 2009 10:56:58 -0700 Received: from sjc-cde-011.cisco.com (sjc-cde-011.cisco.com [171.69.16.68]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id n7VHuvRa023576 for ; Mon, 31 Aug 2009 17:56:57 GMT Date: Mon, 31 Aug 2009 10:56:57 -0700 (PDT) From: Chris Lonvick To: syslog@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4365; t=1251741418; x=1252605418; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=clonvick@cisco.com; z=From:=20Chris=20Lonvick=20 |Subject:=20Protocol=20Action=3A=20'Alarms=20in=20SYSLOG'=2 0to=20Proposed=20Standard=20(fwd) |Sender:=20; bh=LSOgeY5XyDJITCan9K7HGkFza0lyVWJVT/K99Gv7IVw=; b=n08yQJljoIVXv1BcJB06g2ibuK9a1j3CKnIvRSQstfoBXGs7H7OH9v/wOg wdoqyng9AHshjfSB1scBVi/trPqenyZ0LQtcm87CZW0fBAx6fl/xfCCJ9LV8 4ljDz13UkD; Authentication-Results: sj-dkim-4; header.From=clonvick@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Subject: [Syslog] Protocol Action: 'Alarms in SYSLOG' to Proposed Standard (fwd) 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, 31 Aug 2009 17:56:58 -0000 Hi Folks, Many thanks to the people who helped put this together and get it through the process. Regards, Chris ---------- Forwarded message ---------- Date: Mon, 31 Aug 2009 10:24:31 -0700 (PDT) From: The IESG To: IETF-Announce Cc: Internet Architecture Board , RFC Editor Subject: Protocol Action: 'Alarms in SYSLOG' to Proposed Standard The IESG has approved the following document: - 'Alarms in SYSLOG ' as a Proposed Standard This document is the product of the Operations and Management Area Working Group. The IESG contact persons are Dan Romascanu and Ron Bonica. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-opsawg-syslog-alarm-02.txt Technical Summary This document describes how to send alarm information in syslog. It includes the mapping of ITU perceived severities onto syslog message fields and a number of alarm-specific SD-PARAM definitions from X.733 and the IETF Alarm MIB. Working Group Summary The document was revised based on WG feedback & the result meets the issues that were raised. Document Quality SYSLOG is widely implemented and deployed, and the ITU severities are used by a number of protocols and alarm models including the IETF Alarm MIB. Personnel Scott Bradner is the Document Shepherd for this document. Dan Romascanu is the Responsible Area Director. RFC Editor Note Please insert the following edits in the published version: 1. In section 1, Old:Alarm related terminology is defined in [RFC3877]. New:Alarm related terminology is defined in [RFC3877]. SD-ID, SD-PARM and other syslog related terms are defined in [RFC5424] 2. In section 3 Old: the SD-PARARMS are mandatory. New: the SD-PARAMS are mandatory. 3. In section 3.6 Old: [RFC1738] and its updates. In the case of an SNMP resource, the New: [RFC3986] and its updates. In the case of an SNMP resource, the 4. In section 4 Old: In this example, extended from [Syslog], the VERSION is 1 and the New: In this example, extended from [RFC5424], the VERSION is 1 and the OLD: 'APP-NAME is "su"' NEW: 'APP-NAME is "evntslog"' OLD: 'exampleSDID@0' NEW: 'exampleSDID@32473' OLD: 'resourceURI =' NEW: 'resourceURI=' 5. In section 6 Old: IANA is requested to register the SD-IDs New: IANA is requested to register the syslog Structured Data ID Values 6. In section 8.1 Old: [RFC1738] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform Resource Locators (URL)", RFC 1738, December 1994. New: [RFC3986] Berners-Lee, T., Fielding, R., and Masinter, L., "Uniform Resource Identifier (URI): Generic Syntax", RFC RFC3986, January 2005. 7. In Section 3.1: OLD: If the "alarm" SD-ID is supported, the "resource" SD-PARAM MUST be supported. NEW: If the "alarm" SD-ID is included, the "resource" SD-PARAM MUST be included. 8. In Section 3.2: OLD: If the "alarm" SD-ID is supported, the "probableCause" SD-PARAM MUST be supported. NEW: If the "alarm" SD-ID is included, the "probableCause" SD-PARAM MUST be included. 9. In Section 3.3: OLD: If the "alarm" SD-ID is supported, the "perceivedSeverity" SD-PARAM MUST be supported. NEW: If the "alarm" SD-ID is included, the "perceivedSeverity" SD-PARAM MUST be included. 10. In Section 3.4: OLD: If the "alarm" SD-ID is supported, the "eventType" SD-PARAM SHOULD be supported. NEW: If the "alarm" SD-ID is included, the "eventType" SD-PARAM SHOULD be included. 11. In Section 3.5: OLD: If the "alarm" SD-ID is supported, the "trendIndication" SD-PARAM SHOULD be supported. NEW: If the "alarm" SD-ID is included, the "trendIndication" SD-PARAM SHOULD be included. 12. In Section 3.6: OLD: If the "alarm" SD-ID is supported, the "resourceURI" SD-PARAM SHOULD be supported. NEW: If the "alarm" SD-ID is included, the "resourceURI" SD-PARAM SHOULD be included. _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce From clonvick@cisco.com Mon Aug 31 11:07:41 2009 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 A1AC03A68D1 for ; Mon, 31 Aug 2009 11:07:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.562 X-Spam-Level: X-Spam-Status: No, score=-6.562 tagged_above=-999 required=5 tests=[AWL=0.038, 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 gv1TqeWlyvUG for ; Mon, 31 Aug 2009 11:07:40 -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 9252128C138 for ; Mon, 31 Aug 2009 11:07:40 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAOetm0qrR7PE/2dsb2JhbADBbIhBAY5+BYQa X-IronPort-AV: E=Sophos;i="4.44,306,1249257600"; d="scan'208";a="379062404" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 31 Aug 2009 18:07:52 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n7VI7qGn019580 for ; Mon, 31 Aug 2009 11:07:52 -0700 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 n7VI7q0N002912 for ; Mon, 31 Aug 2009 18:07:52 GMT Date: Mon, 31 Aug 2009 11:07:51 -0700 (PDT) From: Chris Lonvick To: syslog@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1865; t=1251742072; x=1252606072; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=clonvick@cisco.com; z=From:=20Chris=20Lonvick=20 |Subject:=20Protocol=20Action=3A=20'Definitions=20of=20Mana ged=20Objects=20for=20Mapping=20SYSLOG=0A=20Messages=20to=20 Simple=20Network=20Management=20Protocol=20(SNMP)=20Notifica tions'=20to=0A=20Proposed=20Standard=20(fwd) |Sender:=20; bh=z3tll2LfH44++TmJM1/hiTIJXNom1oqmLUxGrGTVQFU=; b=E9IPyJD1dCUtddMavQc/OXM/tNV4jie3jdOgijOCkW4668jIP5IJo64PGJ rcyC1nfyfy8rBirbrJFdScZC/i1d8dFDLxcpsYpc68ybdES30s2ekG1BgqOa z0G95a0Q+A; Authentication-Results: sj-dkim-4; header.From=clonvick@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Subject: [Syslog] Protocol Action: 'Definitions of Managed Objects for Mapping SYSLOG Messages to Simple Network Management Protocol (SNMP) Notifications' to Proposed Standard (fwd) 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, 31 Aug 2009 18:07:41 -0000 Hi, Yet another one. Again thanks to those who helped push this along. Regards, Chris ---------- Forwarded message ---------- Date: Mon, 31 Aug 2009 08:39:35 -0700 (PDT) From: The IESG To: IETF-Announce Cc: Internet Architecture Board , RFC Editor Subject: Protocol Action: 'Definitions of Managed Objects for Mapping SYSLOG Messages to Simple Network Management Protocol (SNMP) Notifications' to Proposed Standard The IESG has approved the following document: - 'Definitions of Managed Objects for Mapping SYSLOG Messages to Simple Network Management Protocol (SNMP) Notifications ' as a Proposed Standard This document is the product of the Operations and Management Area Working Group. The IESG contact persons are Dan Romascanu and Ron Bonica. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-opsawg-syslog-msg-mib-06.txt Technical Summary This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines a mapping of SYSLOG messages to Simple Network Management Protocol (SNMP) notifications. Working Group Summary There was consensus in the working group to publish these documents. Document Quality SNMP and SYSLOG are widely used and deployed. The document was reviewed in the Working Group and by MIB DOctors. Personnel Scott Bradner is the Document Shepherd. Dan Romascanu is the Responsible Area Director. _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce From clonvick@cisco.com Mon Aug 31 11:13:47 2009 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 46F6028C435 for ; Mon, 31 Aug 2009 11:13:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.566 X-Spam-Level: X-Spam-Status: No, score=-6.566 tagged_above=-999 required=5 tests=[AWL=0.033, 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 t9IiRWGmh0JO for ; Mon, 31 Aug 2009 11:13:45 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id E51FC28C1CC for ; Mon, 31 Aug 2009 11:13:45 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAJGvm0qrR7PD/2dsb2JhbADBeohBAY8BBYQa X-IronPort-AV: E=Sophos;i="4.44,306,1249257600"; d="scan'208";a="186664395" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 31 Aug 2009 18:13:57 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n7VIDvkJ012587 for ; Mon, 31 Aug 2009 11:13:57 -0700 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 n7VIDv9w009209 for ; Mon, 31 Aug 2009 18:13:57 GMT Date: Mon, 31 Aug 2009 11:13:57 -0700 (PDT) From: Chris Lonvick To: syslog@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=393; t=1251742437; x=1252606437; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=clonvick@cisco.com; z=From:=20Chris=20Lonvick=20 |Subject:=20Update=20on=20syslog-sign |Sender:=20; bh=byYFLnxoIFnpUCLBUIoLoLgOcN8olIerRp4eoYugBEI=; b=lYgUtGJBez8lNcLfzKoU3OFsF+csGCMfYmKWVl+W9tsk8s7qmFl2GFjhvA j1MzLoqpLKiZv66jiBGNlBN86I05AHE4LL2CXadNSJ2sHH92RPgjeVixqiQe a5ZfEO3/y7; Authentication-Results: sj-dkim-3; header.From=clonvick@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Subject: [Syslog] Update on syslog-sign 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, 31 Aug 2009 18:13:47 -0000 Hi Folks, As long as I'm working the keyboard, I figured that I'd push out an update on syslog-sign. Alex has addressed Pasi's request for an explanation about multiple signers and the result looks good. Alex is going to post the new document to the repository and Pasi will ask the Secretariat to open it for IETF Last Call and schedule it for IESG review. Regards, Chris From alex@cisco.com Mon Aug 31 13:53:30 2009 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 65F1828C246 for ; Mon, 31 Aug 2009 13:53:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 NY2g6ps2BhYn for ; Mon, 31 Aug 2009 13:53:29 -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 7B5FE28C51D for ; Mon, 31 Aug 2009 13:53:29 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAIPVm0qrR7O6/2dsb2JhbADCBohBAY8VBYQa X-IronPort-AV: E=Sophos;i="4.44,307,1249257600"; d="scan'208";a="200437089" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 31 Aug 2009 20:53:41 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n7VKrffh012635 for ; Mon, 31 Aug 2009 13:53:41 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n7VKrVhr023362 for ; Mon, 31 Aug 2009 20:53:38 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); Mon, 31 Aug 2009 13:53:34 -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: Mon, 31 Aug 2009 13:53:33 -0700 Message-ID: <85B2F271FDF6B949B3672BA5A7BB62FB0855F47B@xmb-sjc-236.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] Update on syslog-sign Thread-Index: AcoqZtEgEwie88jsTl+0n7frs/DtzgAFdjhQ References: From: "Alexander Clemm (alex)" To: "Chris Lonvick (clonvick)" , X-OriginalArrivalTime: 31 Aug 2009 20:53:34.0667 (UTC) FILETIME=[1B0E21B0:01CA2A7D] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=957; t=1251752021; x=1252616021; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=alex@cisco.com; z=From:=20=22Alexander=20Clemm=20(alex)=22=20 |Subject:=20RE=3A=20[Syslog]=20Update=20on=20syslog-sign |Sender:=20; bh=p3Q/hRO2+2a/UcL48NYAJyNrHA1I4o2QyH2bCl4SmNM=; b=z96QraVh9VnoTdqkLSIDFunPOHGo2cOy9LVjtL1xDeENcvZcz9U4WusZnY q5flwSL8gRqNHpIkYMahRvebeHjTofe6GR7sUAQiC4fih05aDM7N0qSGTyyo +igetzfTQk; Authentication-Results: sj-dkim-2; header.From=alex@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Subject: Re: [Syslog] Update on syslog-sign 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, 31 Aug 2009 20:53:30 -0000 Hi, I have just posted the new revision. Special thanks to Chris, David, and Pasi for their comments, and to Martin for the generation of updated examples. Regards --- Alex -----Original Message----- From: syslog-bounces@ietf.org [mailto:syslog-bounces@ietf.org] On Behalf Of Chris Lonvick (clonvick) Sent: Monday, August 31, 2009 11:14 AM To: syslog@ietf.org Subject: [Syslog] Update on syslog-sign Hi Folks, As long as I'm working the keyboard, I figured that I'd push out an update=20 on syslog-sign. Alex has addressed Pasi's request for an explanation about multiple=20 signers and the result looks good. Alex is going to post the new document=20 to the repository and Pasi will ask the Secretariat to open it for IETF=20 Last Call and schedule it for IESG review. Regards, Chris _______________________________________________ Syslog mailing list Syslog@ietf.org https://www.ietf.org/mailman/listinfo/syslog From root@core3.amsl.com Mon Aug 31 14:00:02 2009 Return-Path: X-Original-To: syslog@ietf.org Delivered-To: syslog@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 0402E3A6B2E; Mon, 31 Aug 2009 14: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: <20090831210002.0402E3A6B2E@core3.amsl.com> Date: Mon, 31 Aug 2009 14:00:02 -0700 (PDT) Cc: syslog@ietf.org Subject: [Syslog] I-D Action:draft-ietf-syslog-sign-27.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: Mon, 31 Aug 2009 21: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 : Signed syslog Messages Author(s) : J. Kelsey, et al. Filename : draft-ietf-syslog-sign-27.txt Pages : 45 Date : 2009-08-31 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 [RFC5424], "The syslog Protocol". A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-syslog-sign-27.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-sign-27.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-08-31134524.I-D@ietf.org> --NextPart--