Re: [Syslog] Missing dead peer detection in DTLS (Gerhard Muenz)

fenghongyan <hongyanfeng@huaweisymantec.com> Sun, 02 August 2009 02:08 UTC

Return-Path: <hongyanfeng@huaweisymantec.com>
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 <syslog@core3.amsl.com>; 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 <syslog@core3.amsl.com>; 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 <syslog@ietf.org>; 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 <hongyanfeng@huaweisymantec.com>
To: Gerhard Muenz <muenz@net.in.tum.de>
Message-id: <fc16b80131ef.4a75658d@huaweisymantec.com>
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: <mailman.152.1248807621.17772.syslog@ietf.org>
References: <mailman.152.1248807621.17772.syslog@ietf.org>
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 <syslog.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/syslog>, <mailto:syslog-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/syslog>
List-Post: <mailto:syslog@ietf.org>
List-Help: <mailto:syslog-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/syslog>, <mailto:syslog-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 02 Aug 2009 02:08:15 -0000

Hi, Gerhard

Thanks for your comments, I read the proposals, I can see it's a good idea 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 
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 strategy. 
I prefer a "heart-beat" solution than a "time-out" solution for this issue.

The only thing left here for syslog-dlts is if we need specific using "heart-beat" in a syslog-dtls proposal?
It's a problem of dtls/udp, which can be fixed in the implementation of dtls and as a part of dtls protocol.
There's anything need syslog-dtls to do to support it? what's your consideration?




Thanks
Linda

----- Original Mail -----
发件人: syslog-request@ietf.org
日期: 2009年 7月 29日, 星期三,  上午3:02
主题: Syslog Digest, Vol 47, Issue 9
收件人: syslog@ietf.org


> If you have received this digest without all the individual message
>  attachments you will need to update your digest options in your list
>  subscription.  To do so, go to 
>  
>  https://www.ietf.org/mailman/listinfo/syslog
>  
>  Click the 'Unsubscribe or edit options' button, log in, and set "Get
>  MIME or Plain Text Digests?" to MIME.  You can set this option
>  globally for all the list digests you receive at this point.
>  
>  
>  
>  Send Syslog mailing list submissions to
>  	syslog@ietf.org
>  
>  To subscribe or unsubscribe via the World Wide Web, visit
>  	https://www.ietf.org/mailman/listinfo/syslog
>  or, via email, send a message with subject or body 'help' to
>  	syslog-request@ietf.org
>  
>  You can reach the person managing the list at
>  	syslog-owner@ietf.org
>  
>  When replying, please edit your Subject line so it is more specific
>  than "Re: Contents of Syslog digest..."
>  
>  
>  Today's Topics:
>  
>     1. Missing dead peer detection in DTLS (Gerhard Muenz)
>  
>  
>  ----------------------------------------------------------------------
>  
>  Message: 1
>  Date: Tue, 28 Jul 2009 10:41:31 +0200
>  From: Gerhard Muenz <muenz@net.in.tum.de>
>  Subject: [Syslog] Missing dead peer detection in DTLS
>  To: syslog@ietf.org, "ipfix@ietf.org" <ipfix@ietf.org>
>  Cc: Michael Tuexen <tuexen@fh-muenster.de>,	Robin Seggelmann
>  	<seggelmann@fh-muenster.de>,	Daniel Mentz <mentz@in.tum.de>
>  Message-ID: <4A6EB9BB.9040002@net.in.tum.de>
>  Content-Type: text/plain; charset="iso-8859-1"
>  
>  
>  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 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 
> 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 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 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 not
>  needed if we have DTLS Heartbeat Extension.
>  
>  Regards,
>  Gerhard
>  
>  -- 
>  Dipl.-Ing. Gerhard M?nz
>  Chair for Network Architectures and Services (I8)
>  Department of Informatics
>  Technische Universit?t M?nchen
>  Boltzmannstr. 3, 85748 Garching bei M?nchen, 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
>  
>  
>  -------------- next part --------------
>  A non-text attachment was scrubbed...
>  Name: smime.p7s
>  Type: application/x-pkcs7-signature
>  Size: 3467 bytes
>  Desc: S/MIME Cryptographic Signature
>  Url : <
>  
>  ------------------------------
>  
>  _______________________________________________
>  Syslog mailing list
>  Syslog@ietf.org
>  https://www.ietf.org/mailman/listinfo/syslog
>  
>  
>  End of Syslog Digest, Vol 47, Issue 9
>  *************************************
>