[IPFIX] DTLS Recommendations

Lothar Braun <braun@net.in.tum.de> Wed, 27 July 2011 13:21 UTC

Return-Path: <braun@net.in.tum.de>
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C53321F850B for <ipfix@ietfa.amsl.com>; Wed, 27 Jul 2011 06:21:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.249
X-Spam-Level:
X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TF0Sh7yc40Cl for <ipfix@ietfa.amsl.com>; Wed, 27 Jul 2011 06:21:26 -0700 (PDT)
Received: from mail-out1.informatik.tu-muenchen.de (mail-out1.informatik.tu-muenchen.de [131.159.0.8]) by ietfa.amsl.com (Postfix) with ESMTP id 781FB21F8678 for <ipfix@ietf.org>; Wed, 27 Jul 2011 06:21:25 -0700 (PDT)
Received: from honshu.net.in.tum.de (honshu.net.in.tum.de [131.159.20.100]) by mail.net.in.tum.de (Postfix) with ESMTPSA id AD2122083FE5 for <ipfix@ietf.org>; Wed, 27 Jul 2011 15:23:18 +0200 (CEST)
From: Lothar Braun <braun@net.in.tum.de>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Date: Wed, 27 Jul 2011 15:21:23 +0200
Message-Id: <476242D1-B10B-472E-A1CA-209C8F11F37B@net.in.tum.de>
To: IPFIX list <ipfix@ietf.org>
Mime-Version: 1.0 (Apple Message framework v1084)
X-Mailer: Apple Mail (2.1084)
Subject: [IPFIX] DTLS Recommendations
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IPFIX WG discussion list <ipfix.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Wed, 27 Jul 2011 13:21:27 -0000

Hi all,

with the WG meeting approaching and me only participating remotely, I would like to share some thoughts on the DTLS recommendations draft by mail. There has not been an update on draft-mentz-ipfix-dtls-recommendations-02 because we didn't get any additional feedback and we didn't feel that any changes were necessary.

Some input on where to move with the draft (this is basically the same what I presented at the meeting in Prague :-)):

The draft identifies issues with IPFIX over DTLS/UDP and DTLS/SCTP. Most of them can be addressed by updating the implementation guidelines. Some other things (might) require text in the protocol spec:

DTLS/SCTP

DTLS renegotiations (changing the keying material for long-lasting associations), require stall of IPFIX export before the negotiation can occur. As a consequence, buffers might fill up and messages might get lost within the exporter. This is highly implementation specific and can therefore be addressed in the implementation guidelines.

DTLS/UDP

Incorrect PATH MTU estimation:

Messages can get lost if path MTU is not configured correctly. Using DTLS heartbeats, one could use the heartbeats to estimate the correct path MTU. This is purely optional and does not require changes to IPFIX, as the heartbeat mechanism is part of the DTLS layer, and can be therefore part of the implementation guidelines.

Collector state loss

This is probably the most severe problem with IPFIX and DTLS, because there is a huge difference between IPFIX over UDP and IPFIX over UDP/DTLS. 

If DTLS is employed, both the Collector and the Exporter need to hold DTLS-specific state in order to communicate. This state is established at association setup and required for all the communication after the setup. If the Collector looses this state (either due to a crash, a reconfiguration, or a reboot), it will not be able to decode any further Messages from the Exporter. Even worse, the Exporter cannot detect that state loss because IPFIX is a purely unidirectional protocol and the Exporter does not get any feedback from the Collector.

This means that IPFIX will behave differently with UDP on the transport layer depending on whether DTLS is used or not:

If a state loss occurs on IPFIX over UDP (e.g. template information gets lost), IPFIX will automatically recover because the Exporter is required to re-send this state information (e..g the Templates) periodically. If a state loss occurs on IPFIX over DTLS/UDP, no recovery will take place within this transport association. I think this is a protocol issue, and should be somehow addressed by the protocol. I can see two options:

1.) the protocol specification highlights that this problem exists, and specifies that an Exporter should deal with this problem (e.g. according to the tips that are given in an updated version of the guidelines). The guidelines can then be updated to contain the solution/work-arounds from draft-mentz-ipfix-dtls-recommendations-02.

2.) The protocol specification requires the Exporter to implement one of the options we proposed in draft-mentz-ipfix-dtls-recommendations-02 (preferably require the use of DTLS heartbeats) to detect Collector state information loss.

Option 2 would most likely introduce a dependency on DTLS heartbeats, which could be a problem: The DTLS heartbeat document is currently not a RFC. yet. It is still a working group document of the TLS group (http://tools.ietf.org/html/draft-ietf-tls-dtls-heartbeat-02). It will be discussed on TLS WG meeting on thursday (http://www.ietf.org/proceedings/81/agenda/tls.txt), and it might be a blocker for an updated version of the protocol specs.

Pre-Shared Keys (DTLS and TLS with all transport binding):

This is not a problem, but a nice to have feature: RFC 5101 requires the use of X509 certificates for authentication between the Collector and the Exporter. Deploying and maintaining a X509 infrastructure is complex and might be an overkill for small deployments. RFC4279 defines ciphersuites which build on pre-shared keys for authentication.

If the group would like to allow pre-shared keys for authentication, a change to RFC 5101 in Section "11.3 Authentication" would be required.

Best regards,
  Lothar

--
Lothar Braun
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-18010       Fax: +49 89 289-18033
E-mail: braun@net.in.tum.de