[Search] [pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00 01 02                                                      
IP Flow Information Export WG                                   D. Mentz
Internet-Draft                                                  G. Muenz
Intended status: Informational                                  L. Braun
Expires: January 7, 2010                                     TU Muenchen
                                                            July 6, 2009


            Recommendations for Implementing IPFIX over DTLS
              <draft-mentz-ipfix-dtls-recommendations-00>

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on January 7, 2010.

Copyright Notice

   Copyright (c) 2009 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.

Abstract

   This document discusses problems and solutions regarding the
   implementation of the IPFIX protocol over SCTP and DTLS.



Mentz, et al.  draft-mentz-ipfix-dtls-recommendations-00.txt    [Page 1]


Internet-Draft     Recommendations for IPFIX over DTLS         July 2009


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3

   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3

   3.  Issues and Recommendations Regarding IPFIX over DTLS/UDP  . . . 3
     3.1.  Undetected Collector Crashes  . . . . . . . . . . . . . . . 3
     3.2.  Possible Solutions  . . . . . . . . . . . . . . . . . . . . 4

   4.  Issues and Recommendations Regarding IPFIX over DTLS/SCTP . . . 6
     4.1.  Renegotiation for DTLS and SCTP-AUTH  . . . . . . . . . . . 6
     4.2.  Possible Solutions  . . . . . . . . . . . . . . . . . . . . 7

   5.  Security Considerations . . . . . . . . . . . . . . . . . . . . 7

   Appendix A.  Acknowledgements . . . . . . . . . . . . . . . . . . . 7

   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 7
     6.1.  Normative References  . . . . . . . . . . . . . . . . . . . 7
     6.2.  Informative References  . . . . . . . . . . . . . . . . . . 7

   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 8




























Mentz, et al.  draft-mentz-ipfix-dtls-recommendations-00.txt    [Page 2]


Internet-Draft     Recommendations for IPFIX over DTLS         July 2009


1.  Introduction

   All implementations of the IPFIX protocol conforming to [RFC5101]
   must support DTLS [RFC4347] if SCTP or UDP is used as transport
   protocol.

   This document discusses specific issues that have arisen during the
   implementation of the IPFIX protocol over DTLS.  These issues may
   degrade the performance of an IPFIX Exporter as they require to
   periodically interrupt the data export.  As a solution, we proposes
   workarounds which solve these problems without requiring any changes
   to DTLS and the IPFIX protocol.

   This document is to be considered as a possible update of the IPFIX
   Implementation Guidelines [RFC5153].


2.  Terminology

   This document adopts the IPFIX terminology used in [RFC5101].  As in
   all IPFIX document, all IPFIX specific terms have the first letter of
   a word capitalized when used in this document.


3.  Issues and Recommendations Regarding IPFIX over DTLS/UDP

3.1.  Undetected Collector Crashes

   DTLS has been conceived for deployment on top of unreliable transport
   protocols, such as UDP.  Hence, it is able to cope with lost
   datagrams and datagrams that arrive out of order at the receiver.  In
   contrast to UDP, which does not maintain any connection state, DTLS
   has to maintain state across multiple datagrams at both endpoints.
   This state is established during the DTLS handshake.

   During the DTLS handshake, the two peers authenticate each other and
   agree upon several parameters which are necessary to communicate over
   DTLS.  Among these parameters are a cipher suite as well as a shared
   key that is usually established using a Diffie-Hellman key exchange.
   If one of the peers crashes unexpectedly, these parameters as well as
   the maintained DTLS state usually get lost.  As a consequence, the
   peer is not able to check the integrity of newly arrived datagrams or
   to decrypted the datagrams' payload.

   In the case of connection oriented transport protocols, such as TCP
   or SCTP, a connection endpoint will be informed about the crash of
   its correspondent by the transport protocol.  UDP, however, is
   connection less, which means that the crash of the receiver is not



Mentz, et al.  draft-mentz-ipfix-dtls-recommendations-00.txt    [Page 3]


Internet-Draft     Recommendations for IPFIX over DTLS         July 2009


   noticed by the sender.  There are situations in which the sender
   might receive ICMP messages that indicate that the receiver is
   experiencing problems, but there is no guarantee that those ICMP
   messages will be sent.  As DTLS itself does not provide any
   mechanisms for dead peer detection, the crash of one of the peers has
   to be detected and handled by protocols in the upper layers.

   As IPFIX is a unidirectional protocol, a conform implementation of an
   IPFIX Exporter only sends but does not receive any data.  Hence, the
   Exporter cannot tell from the absence of returning traffic that the
   Collector has crashed.  Instead, the Exporter keeps on sending data
   which must be discarded by the recovered Collector because the
   information needed to check the integrity and to decrypt the data is
   lost.

3.2.  Possible Solutions

   There are three options to circumvent this problem.

   1.  The first option is to let the Exporter periodically trigger
       renegotiations on the DTLS layer.  This means that both peers
       have to participate in a new handshake, implying the exchange of
       datagrams in both direction.  Hence, due to a timeout, the
       Exporter will notice that the Collector has crashed.

       Under normal conditions, such a renegotiation is used to renew
       the keying material in a long living connection.  Depending on
       whether a full or abbreviated handshake is carried out, such a
       renegotiation can be very costly in terms of computational
       overhead because it involves public key operations.  In addition,
       the DTLS specification [RFC4347] leaves open if application data
       can be sent during the handshake or not.  Typical
       implementations, such as OpenSSL [OpenSSL], require that sending
       data is interrupted until the handshake is finished.
       Consequently, the export of IPFIX Messages must be stalled for at
       least two round trip times, which could lead to IPFIX Messages
       queuing up in the buffer of the Exporting Process and potential
       loss of data.

       The most substantial argument against this solution is that the
       renegotiation was simply not conceived to serve as a dead peer
       detection mechanism.  To make sure that the Exporter learns
       quickly about a crashed Collector, renegotiations would have to
       be carried out in short intervals.

   2.  The authors of this draft endorse the second option which is to
       periodically establish new DTLS connections and replace the
       active DTLS connection by a new one.  Establishing a new DTLS



Mentz, et al.  draft-mentz-ipfix-dtls-recommendations-00.txt    [Page 4]


Internet-Draft     Recommendations for IPFIX over DTLS         July 2009


       connection involves a bidirectional handshake which requires both
       peers to be alive.  If the Collector crashes unexpectedly and
       recovers quickly, then the time during which he receives
       meaningless data is limited until a new DTLS connection is
       established.  Care should be taken that two successive
       connections overlap in a way such that no data is lost at the
       Exporting Process.  This can be achieved by swapping the
       connections only after all active templates have been sent out on
       the new DTLS connection.

       As regards the computational overhead, this solution suffers from
       the same limitations as the first one.  Every new DTLS connection
       might involve costly public key operations and a small overhead
       in terms of the transmitted data volume.  However, public key
       operations do not have to be carried out if the DTLS
       implementations support a feature called session resumption which
       allows the reuse of keying material from an earlier session.
       This feature could also be used to simplify the renegotiation
       proposed in the first solution.

       The main advantage over periodical renegotiations is that this
       solution does not suffer from the data stall that is due to the
       fact that OpenSSL does not allow sending application data during
       handshakes.  IPFIX records can be transmitted without
       interruption due to the overlap of the old and the new DTLS
       connection.

       From the point of view of IPFIX, every new DTLS connection
       represents a new Transport Session.  At the collector side,
       however, it should be straight forward to associate the different
       Transport Sessions to the same Exporter since the exporter IP
       address remains the same.  At the beginning of every new
       Transport Session, not only all active Templates have to be sent,
       but also certain Data Records defined by Option Templates.  In
       the case of UDP, however, this does not cause significant
       additional overhead because Templates and Data Records defined by
       Option Templates are periodically resent anyway.

   3.  A third alternative to detect a dead or recovered collector is to
       implement the DTLS Heartbeat Extension which has been very
       recently suggested in [I-D.seggelmann-tls-dtls-heartbeat].  This
       DTLS extension allows detecting a dead peer without interfering
       with the ongoing data transfer.  The computational and bandwidth
       overhead is negligible plus the data transmission does not stall.

       The problems with this solution are that the necessary DTLS
       extension has not yet been standardized and that there are
       literally no implementations available at the time of writing.



Mentz, et al.  draft-mentz-ipfix-dtls-recommendations-00.txt    [Page 5]


Internet-Draft     Recommendations for IPFIX over DTLS         July 2009


4.  Issues and Recommendations Regarding IPFIX over DTLS/SCTP

4.1.  Renegotiation for DTLS and SCTP-AUTH

   The DTLS binding for SCTP is more sophisticated than the DTLS/UDP
   binding.  This is due to the fact that SCTP provides a connection
   oriented service to upper layers.  It also carries additional data
   items with each user message.  Among those items are:
   o  stream ID
   o  payload protocol identifiers

   DTLS only protects the bare user data.  Without additional security
   mechanisms, a man-in-the-middle attacker could easily tamper with the
   stream ID or the payload protocol identifier.  He could also defeat
   SCTP's efforts to provide a reliable or partially reliable service by
   forging SACK and Forward-TSN chunks.

   The solution to this problem is SCTP-AUTH [RFC4895] which allows the
   SCTP implementation to insert an authentication chunk which
   authenticates certain types of subsequent chunks in the same packet
   using a Hashed Message Authentication Code (HMAC).  While SCTP-AUTH
   allows for the negotiation of the hash algorithm it does not provide
   means for secure key agreement.  Therefore a cross layer approach is
   used to extract keying material from the DTLS layer and use it on the
   SCTP layer.  This approach is described in
   [I-D.ietf-tsvwg-dtls-for-sctp] and is readily available in OpenSSL.

   Due to limitations of DTLS, no renegotiation (i.e., change of keying
   material) can be performed without impeding the ongoing data
   transfer.  The implementation has to make sure that there is no data
   in flight at the point in time that the keying material is swapped.
   This means that data transfer on all streams has to stop before a
   renegotiation can be initiated.  Moreover, there must not be any
   unacknowledged messages in the send buffers of the SCTP sockets.  In
   practice, the renegotiation has to wait until the SCTP sockets at
   both endpoints return SCTP_SENDER_DRY_EVENT
   [I-D.ietf-tsvwg-sctpsocket].  Only after the handshake has been
   completed, the data transfer can continue because DTLS does not
   guarantee the proper authentication and decryption of user messages
   that were secured with outdated keying material.

   In the case of IPFIX, this means that the Exporting Process has to
   interrupt the export of IPFIX Messages for a certain period of time.
   IPFIX Messages generated in the meantime have to be buffered or
   dropped until the renegotiation is over.






Mentz, et al.  draft-mentz-ipfix-dtls-recommendations-00.txt    [Page 6]


Internet-Draft     Recommendations for IPFIX over DTLS         July 2009


4.2.  Possible Solutions

   To solve this problem of data stall, the authors of this draft
   suggest to employ the same mechanism as in the UDP case, which is to
   periodically establish a new DTLS/SCTP association between Exporter
   and Collector in parallel to the existing one.  Only after the
   handshakes of SCTP and DTLS are completed and the IPFIX Templates are
   sent on the new association, the Exporter starts sending Data Records
   on the new Transport Session.

   Again, the establishment of a new SCTP association represents a new
   IPFIX Transport Session.  Some overhead is produced because Templates
   as well as certain Data Records defined by Option Template have to be
   resent, which would not be necessary if the old Transport Session was
   kept.  However, the amount of additional data that has to be sent is
   assumed to be rather small.


5.  Security Considerations

   The recommendations in this document do not introduce any additional
   security issues to those already mentioned in [RFC5101].


Appendix A.  Acknowledgements

   The authors thank Michael Tuexen and Robin Seggelmann for their
   contribution on the standardization and implementation of DTLS for
   SCTP as well as for their valuable advice regarding the
   implementation of IPFIX over DTLS.


6.  References

6.1.  Normative References

   [RFC5101]  Claise, B., "Specification of the IP Flow Information
              Export (IPFIX) Protocol for the Exchange of IP Traffic
              Flow Information", RFC 5101, January 2008.

6.2.  Informative References

   [RFC5153]  Boschi, E., Mark, L., Quittek, J., Stiemerling, M., and P.
              Aitken, "IP Flow Information Export (IPFIX) Implementation
              Guidelines", RFC 5153, April 2008.

   [RFC3758]  Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P.
              Conrad, "Stream Control Transmission Protocol (SCTP)



Mentz, et al.  draft-mentz-ipfix-dtls-recommendations-00.txt    [Page 7]


Internet-Draft     Recommendations for IPFIX over DTLS         July 2009


              Partial Reliability Extension", RFC 3758, May 2004.

   [RFC4960]  Stewart, R., "Stream Control Transmission Protocol",
              RFC 4960, September 2007.

   [RFC4347]  Rescorla, E. and N. Modadugu, "Datagram Transport Layer
              Security", RFC 4347, April 2006.

   [OpenSSL]  "OpenSSL Cryptography and SSL/TLS Toolkit",
              Homepage http://www.openssl.org/, 2009.

   [I-D.seggelmann-tls-dtls-heartbeat]
              Seggelmann, R., Tuexen, M., and M. Williams, "Datagram
              Transport Layer Security Heartbeat Extension",
              draft-seggelmann-tls-dtls-heartbeat-00 (work in progress),
              July 2009.

   [RFC4895]  Tuexen, M., Stewart, R., Lei, P., and E. Rescorla,
              "Authenticated Chunks for the Stream Control Transmission
              Protocol (SCTP)", RFC 4895, August 2007.

   [I-D.ietf-tsvwg-dtls-for-sctp]
              Tuexen, M., Seggelmann, R., and E. Rescorla, "Datagram
              Transport Layer Security for Stream Control Transmission
              Protocol", draft-seggelmann-tls-dtls-heartbeat-00 (work in
              progress), October 2008.

   [I-D.ietf-tsvwg-sctpsocket]
              Stewart, R., Poon, K., Tuexen, M., Yasevich, V., and P.
              Lei, "Sockets API Extensions for Stream Control
              Transmission Protocol (SCTP)",
              draft-ietf-tsvwg-sctpsocket-19 (work in progress),
              February 2009.


Authors' Addresses

   Daniel Mentz
   Technische Universitaet Muenchen
   Department of Informatics
   Chair for Network Architectures and Services (I8)
   Boltzmannstr. 3
   Garching  D-85748
   DE

   Email: mentz@in.tum.de





Mentz, et al.  draft-mentz-ipfix-dtls-recommendations-00.txt    [Page 8]


Internet-Draft     Recommendations for IPFIX over DTLS         July 2009


   Gerhard Muenz
   Technische Universitaet Muenchen
   Department of Informatics
   Chair for Network Architectures and Services (I8)
   Boltzmannstr. 3
   Garching  D-85748
   DE

   Phone: +49 89 289-18008
   Email: muenz@net.in.tum.de
   URI:   http://www.net.in.tum.de/~muenz


   Lothar Braun
   Technische Universitaet Muenchen
   Department of Informatics
   Chair for Network Architectures and Services (I8)
   Boltzmannstr. 3
   Garching  D-85748
   DE

   Phone: +49 89 289-18010
   Email: braun@net.in.tum.de
   URI:   http://www.net.in.tum.de/~braun



























Mentz, et al.  draft-mentz-ipfix-dtls-recommendations-00.txt    [Page 9]