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