Re: [IPFIX] [Syslog] Missing dead peer detection in DTLS
Michael Tuexen <tuexen@fh-muenster.de> Thu, 30 July 2009 15:24 UTC
Return-Path: <tuexen@fh-muenster.de>
X-Original-To: ipfix@core3.amsl.com
Delivered-To: ipfix@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 <tuexen@fh-muenster.de>
To: "tom.petch" <cfinss@dial.pipex.com>
In-Reply-To: <000401ca111a$3bb01da0$0601a8c0@allison>
X-Priority: 3
References: <4A6EB9BB.9040002@net.in.tum.de> <000401ca111a$3bb01da0$0601a8c0@allison>
Message-Id: <EB76C973-49C7-494C-8281-52559BC61F40@fh-muenster.de>
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: Thu, 30 Jul 2009 14:25:00 -0700
Cc: Robin Seggelmann <seggelmann@fh-muenster.de>, ipfix@ietf.org, Daniel Mentz <mentz@in.tum.de>, syslog@ietf.org, tls@ietf.org
Subject: Re: [IPFIX] [Syslog] Missing dead peer detection in DTLS
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IPFIX WG discussion list <ipfix.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ipfix>, <mailto:ipfix-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipfix>
List-Post: <mailto:ipfix@ietf.org>
List-Help: <mailto:ipfix-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipfix>, <mailto:ipfix-request@ietf.org?subject=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 > 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? > > 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? > > 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 > > ----- Original Message ----- > From: "Gerhard Muenz" <muenz@net.in.tum.de> > To: <syslog@ietf.org>; <ipfix@ietf.org> > Cc: "Michael Tuexen" <tuexen@fh-muenster.de>; "Robin Seggelmann" > <seggelmann@fh-muenster.de>; "Daniel Mentz" <mentz@in.tum.de> > 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 > 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 > > > >
- [IPFIX] Missing dead peer detection in DTLS Gerhard Muenz
- Re: [IPFIX] [Syslog] Missing dead peer detection … tom.petch
- Re: [IPFIX] [Syslog] Missing dead peer detection … Michael Tuexen
- Re: [IPFIX] [Syslog] Missing dead peer detection … tom.petch
- Re: [IPFIX] [Syslog] Missing dead peer detection … Michael Tuexen
- Re: [IPFIX] [TLS] [Syslog] Missing dead peer dete… Erick O
- Re: [IPFIX] [TLS] [Syslog] Missing dead peer dete… Michael Tuexen
- Re: [IPFIX] [TLS] [Syslog] Missing dead peer dete… Erick O
- Re: [IPFIX] [TLS] [Syslog] Missing dead peer dete… Erick O