Re: [TLS] Draft minutes for IETF-75 available

Gerhard Muenz <muenz@net.in.tum.de> Mon, 03 August 2009 21:03 UTC

Return-Path: <muenz@net.in.tum.de>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D03F53A6986 for <tls@core3.amsl.com>; Mon, 3 Aug 2009 14:03:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.087
X-Spam-Level:
X-Spam-Status: No, score=-2.087 tagged_above=-999 required=5 tests=[AWL=0.163, 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 nfbtr6v3JKQ2 for <tls@core3.amsl.com>; Mon, 3 Aug 2009 14:03:16 -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 C07C73A687F for <tls@ietf.org>; Mon, 3 Aug 2009 14:03:15 -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 7C3F847FB7; Mon, 3 Aug 2009 23:03:15 +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 1E916509D; Mon, 3 Aug 2009 23:03:15 +0200 (CEST)
Message-ID: <4A775099.5040003@net.in.tum.de>
Date: Mon, 03 Aug 2009 23:03:21 +0200
From: Gerhard Muenz <muenz@net.in.tum.de>
User-Agent: Thunderbird 2.0.0.22 (Windows/20090605)
MIME-Version: 1.0
To: "Joseph Salowey (jsalowey)" <jsalowey@cisco.com>
References: <mailman.77.1249326021.24683.tls@ietf.org> <4A77429B.9080506@net.in.tum.de> <AC1CFD94F59A264488DC2BEC3E890DE5087BCF21@xmb-sjc-225.amer.cisco.com>
In-Reply-To: <AC1CFD94F59A264488DC2BEC3E890DE5087BCF21@xmb-sjc-225.amer.cisco.com>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg="sha1"; boundary="------------ms010103030504050806070309"
X-Virus-Scanned: ClamAV using ClamSMTP
Cc: tls@ietf.org
Subject: Re: [TLS] Draft minutes for IETF-75 available
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 03 Aug 2009 21:03:16 -0000

Joseph,

Joseph Salowey (jsalowey) wrote:
> Thanks Gerhard,
> 
> Minutes updated.   
> 
> Some questions below:
> 
> <snip> 
>> Some thoughts about the proposal to solve Heartbeat at the 
>> IPFIX layer (from me as a contributor to IPFIX):
>> It is extremely unlikely that we will change the IPFIX 
>> protocol from unidirectional to bidirectional just because 
>> DTLS-over-UDP requires it.
>> In my opinion, if we had to choose, it would be more likely 
>> that we would update RFC5101 saying that DTLS is not required 
>> any more for IPFIX-over-UDP implementations, and that the 
>> usage of IPFIX-over-DTLS/UDP is not recommended because of 
>> the dead peer detection problem.
> 
> [Joe] Is IPFIX defined over UDP without DTLS?  If so, would
> IPFIX-over-UDP have a dead peer detection problem of its own?  

Thanks for you interest in this problem.

The answer is yes and no.

Yes, it is a problem because with UDP the Exporter will never know
exactly if the Collector is up and receiving IPFIX Messages. A
non-existing Collector can be detected via returned ICMP messages
(destination unreachable and the like). However, such messages are often
blocked by firewalls.

However, no, it is not such a big problem because UDP is unrealiable anyway.

The big difference between IPFIX-over-UDP and IPFIX-over-DTLS/UDP is
that you can always start or restart a UDP Collector without touching
the Exporter. If the Collector is listening on the correct UDP port, it
will receive the Templates after a while (Templates are retransmitted
periodically when UDP is used), and then, it will be able to start or
resume decoding IPFIX Messages.

With DTLS/UDP, the Exporter must initiate the DTLS renegotiation after
the Collector has restarted. This is because the Collector does not know
which Exporters actually exist (like a server which does not know its
clients in advance). So, the Exporter should somehow know when a
renegotiation is necessary. It seems that DTLS Heartbeat would nicely
solve this.

Regards,
Gerhard


>> IPFIX cannot reasonably deploy DTLS for UDP without the 
>> proposed Heartbeat extension. The available workarounds are 
>> not very nice.
>>
> 
> 
>> Regards,
>> Gerhard
>>