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

From: fenghongyan <[email-masked]>
Date: Sun, 02 Aug 2009 10:08:13 +0800

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 -----
发件人: [email-masked]
日期: 2009年 7月 29日, 星期三,  上午3:02
主题: Syslog Digest, Vol 47, Issue 9
收件人: [email-masked]

> 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
>  	[email-masked]
>  
>  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
>  	[email-masked]
>  
>  You can reach the person managing the list at
>  	[email-masked]
>  
>  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 <[email-masked]>
>  Subject: [Syslog] Missing dead peer detection in DTLS
>  To: [email-masked], "[email-masked]" <[email-masked]>
>  Cc: Michael Tuexen <[email-masked]>,	Robin Seggelmann
>  	<[email-masked]>,	Daniel Mentz <[email-masked]>
>  Message-ID: <[email-masked]>
>  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: [email-masked]    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
>  [email-masked]
>  https://www.ietf.org/mailman/listinfo/syslog
>  
>  
>  End of Syslog Digest, Vol 47, Issue 9
>  *************************************
>

---

From: Gerhard Muenz <[email-masked]>
Date: Sun, 02 Aug 2009 22:03:39 +0200

Hi Linda,

> 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 consideration?

Not sure. We have not tried the corresponding OpenSSL patch yet.  Maybe
the application (e.g. syslog) has to trigger the Heartbeat.

Regards,
Gerhard

-- 
Dipl.-Ing. Gerhard Münz
Chair for Network Architectures and Services (I8)
Technische Universität München - Department of Informatics
Boltzmannstr. 3, 85748 Garching bei München, Germany
Phone:  +49 89 289-18008       Fax: +49 89 289-18033
E-mail: [email-masked]    WWW: http://www.net.in.tum.de/~muenz

---

From: fenghongyan <[email-masked]>
Date: Tue, 04 Aug 2009 23:44:36 +0800

Hi Gerhard,

----- 原始邮件 -----
发件人: Gerhard Muenz <[email-masked]>
日期: 2009年 8月 3日, 星期一,  上午4:03
主题: Re: Missing dead peer detection in DTLS (Gerhard Muenz)
收件人: fenghongyan <[email-masked]>
抄送: [email-masked]

>  > "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 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.
>  
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?
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?

Linda

---

From: Gerhard Muenz <[email-masked]>
Date: Tue, 04 Aug 2009 18:23:02 +0200

Hi,

> 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.

> 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

---

From: fenghongyan <[email-masked]>
Date: Wed, 05 Aug 2009 17:16:51 +0800

Hi,
  
>  In the case of DTLS/UDP, the Collector needs to maintain the DTLS state

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.

>  This is another situation where DTLS Heartbeat extension is useful.

I share this opinion. "timeout" can also work for it.

>  > I think if the ipfix collector need support multiple exporter, 
> ipfix need also support session demultiplexing,
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