ipfix Working Group F. Miao Internet-Draft M. Yuzhi Intended status: Standards Track Huawei Technologies Expires: July 27, 2007 D. Harrington Huawei Technologies (USA) January 23, 2007 TLS and DTLS Transport Mapping for IPFIX draft-yuzhi-ipfix-transport-tls-01 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of 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 July 27, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract This document describes the use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) to provide a secure communication for the transport of IPFIX protocol. Miao, et al. Expires July 27, 2007 [Page 1] Internet-Draft draft-yuzhi-ipfix-transport-tls-01.txt January 2007 Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [1]. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Terminology . . . . . . . . . . . . . . . . . 3 1.2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. IPFIX over TLS or DTLS . . . . . . . . . . . . . . . . . . . . 4 2.1. Port Assignment . . . . . . . . . . . . . . . . . . . . . 4 2.2. Initiation . . . . . . . . . . . . . . . . . . . . . . . . 4 2.2.1. SCTP . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.2.2. TCP . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.2.3. PR-SCTP . . . . . . . . . . . . . . . . . . . . . . . 4 2.2.4. UDP . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.3. Sending data . . . . . . . . . . . . . . . . . . . . . . . 5 2.4. Closure . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.5. TLS/DTLS to secure IPFIX . . . . . . . . . . . . . . . . . 6 2.5.1. IPFIX End-point Authentication . . . . . . . . . . . . 6 2.5.2. Data Security . . . . . . . . . . . . . . . . . . . . 6 3. Security Considerations . . . . . . . . . . . . . . . . . . . 7 3.1. Encryption . . . . . . . . . . . . . . . . . . . . . . . . 7 3.2. Authentication . . . . . . . . . . . . . . . . . . . . . . 7 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 6.1. Normative References . . . . . . . . . . . . . . . . . . . 7 6.2. Informative References . . . . . . . . . . . . . . . . . . 8 Appendix A. An Appendix . . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 Intellectual Property and Copyright Statements . . . . . . . . . . 10 Miao, et al. Expires July 27, 2007 [Page 2] Internet-Draft draft-yuzhi-ipfix-transport-tls-01.txt January 2007 1. Introduction This document describes the use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) to provide a secure communication for the transport of IPFIX protocol. 1.1. Requirements Terminology o An Exporter is a device which hosts one or more Exporting Processes. An Exporting Process sends Flow Records to one or more Collecting Process. o A Collector is a device which hosts one or more Collecting Processes. A Collecting Process receives Flow Records from one or more Exporting Processes. o A TLS client is an application that can initiate a TLS connection by sending a Client Hello to a peer. o A TLS server is an application that can receive a Client Hello from a peer and reply with a Server Hello. o A DTLS client is an application that can sent Client Hello to a peer. o A DTLS server is an application that can receive a Client Hello from a peer and reply with a Hello Verify Request. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [1]. This document uses terminology specific to SCTP as defined in section "Terminology" of RFC 2960 [2].. This document uses terminology specific to IPFIX as defined in section "Terminology" of "IPFIX Protocol Specification" . 1.2. Overview This document discusses how IPFIX can be secured using TLS or DTLS. IPFIX can be transported over SCTP, PR-SCTP, TCP and UDP, and can be secured using TLS or DTLS. If IPFIX runs over SCTP or TCP, TLS is used to provide secure connection. If IPFIX runs over UDP or PR- SCTP, DTLS is used. An IPFIX Exporter acts as the TLS/DTLS client and an IPFIX Collector acts as the TLS/DTLS server. Miao, et al. Expires July 27, 2007 [Page 3] Internet-Draft draft-yuzhi-ipfix-transport-tls-01.txt January 2007 2. IPFIX over TLS or DTLS 2.1. Port Assignment The IANA-assigned TCP port is used as the default port for IPFIX over TLS. The IANA-assigned SCTP port is used as the default port for IPFIX over TLS. The IANA-assigned PR-SCTP port is used as the default port for IPFIX over DTLS.The IANA- assigned UDP port is used as the default port for IPFIX over DTLS. 2.2. Initiation 2.2.1. SCTP When the transport protocol is SCTP, the Exporter should initiate an association with the Collector and then send the TLS Client Hello to begin the TLS handshake. Because TLS requires bi-directional connection for handshake, and IPFIX protocol need at least two uni- directional streams from Exporting Process to carry its data and templates records separately, so there MUST have at least two bi- directional SCTP streams per association. The TLS handshake layer assumes that handshake messages are delivered reliably and breaks if those messages are lost. An implementation MUST NOT use partial reliability extension for SCTP when a TLS handshake is pending. 2.2.2. TCP When the transport protocol is TCP, the Exporter should initiate a connection to the Collector and then send the TLS Client Hello to begin the TLS handshake. 2.2.3. PR-SCTP When the transport protocol is PR-SCTP, the Exporter should send the DTLS Client Hello to initiate the TLS handshake. All DTLS control message MUST be transported on PR-SCTP stream 0 with unlimited reliability and with the ordered deliver feature. 2.2.4. UDP When the transport protocol is UDP, the Exporter should send the DTLS Client Hello to initiate the TLS handshake. Once the Exporter has sent Client Hello, it expects to receive a Hello Verify Request from the Collector. If either the Client Hello or the Hello Verify Request is lost, the Exporter should retransmit Client Hello message. Miao, et al. Expires July 27, 2007 [Page 4] Internet-Draft draft-yuzhi-ipfix-transport-tls-01.txt January 2007 2.3. Sending data Once TLS or DTLS handshake has finished, an application data protocol, such as IPFIX, is layered on the TLS/DTLS record protocol. ALL IPFIX Flow Records MUST be sent as "application data" of TLS/ DTLS. When the transport protocol is SCTP, there MUST be at least two bi- directional SCTP streams per association. The first bi-directional stream (referred to as bi-directional stream 0 in the rest of this document), is used to send the IPFIX Template Set and Options Template Set. Bi-directional stream 0 MUST be fully reliable. IPFIX Data Sets MUST NOT be sent on Bi-directional streams 0. When the transport protocol is PR-SCTP, there SHOULD be at least one bi-directional PR-SCTP stream per association.The first bi- directional stream (referred to as bi-directional stream 0 in the rest of this document), is used to send the IPFIX Template Set and Options Template Set. Bi-directional stream 0 MUST be fully reliable. IPFIX Data Sets MAY be sent on Bi-directional stream 0, but SHOULD be sent on other streams for better performance. When the transport protocol is UDP, IPFIX Templates sent from Exporter to Collector MUST be resent at regular intervals in case previous copies were lost. 2.4. Closure A closure_notify alert MUST be sent over each TLS stream before closing the SCTP association. A closure_notify alert MUST be sent before closing the TCP connection. A Exporter MAY choose not to wait for the Collector's closure_notify alert and simply close the association or the connection, thus generating an incomplete close on the Collector side. Once the Collector gets closure_notify from the Exporter, it MUST reply with a closure_notify unless it becomes aware that the association or the connection has already been closed by the Exporter (e.g., the closure was indicated by TCP or SCTP). When a Collector no longer wants to receive IPFIX messages, it SHOULD close its end of the association or the connection. The Collector MUST attempt to initiate an exchange of closure_notify alerts with the Exporter before closing the association or the connection. When the Exporter has received the closure_notify alert from the Collector and still has pending data to send, the Exporter SHOULD send the Miao, et al. Expires July 27, 2007 [Page 5] Internet-Draft draft-yuzhi-ipfix-transport-tls-01.txt January 2007 pending data before sending the closure_notify alert. The Collector SHOULD continue to read IPFIX Messages until the Exporter has closed its end. 2.5. TLS/DTLS to secure IPFIX TLS/DTLS transport can provide different levels of security protection. 2.5.1. IPFIX End-point Authentication It is important to make sure that the IPFIX Exporter is talking to the "right" Collector and vice versa. TLS supports three authentication modes: authentication of both parties, server authentication with an unauthenticated client, and total anonymity. TLS or DTLS uses certificate [RFC3280] to authenticate the peers. When an Exporter authenticates a Collector it MUST validate the certificate. It SHOULD check the common name (CN) of the certificate against the host name of the collector if it has knowledge of a common name/host name mapping. If the common name does not match the host name, the Exporter SHOULD send an "access_denied" error alert using the TLS or DTLS alert protocol to terminate the handshake, and then it SHOULD close the communication between them. When a Collector authenticates an Exporter, the same procedure applies. It is up to the application (administrator) to decide whether one-way authentication, mutual authentication or total anonymity is appropriate for the application. 2.5.2. Data Security The IPFIX data may exist in both the IPFIX Exporter and the Collector. In addition, the data is also transferred on the wire from the IPFIX Exporter to the Collector when it is exported. To provide security, the data should be protected from common network attacks. The protection of IPFIX data within the IPFIX Device and Collector is out of scope for this document. TLS supports both stream cipher and block cipher. The key for encryption is derived from a secret established by the handshake protocol. An IPFIX implementation SHOULD permit administrators to select the cryptographic level they desire. Miao, et al. Expires July 27, 2007 [Page 6] Internet-Draft draft-yuzhi-ipfix-transport-tls-01.txt January 2007 3. Security Considerations Note: This section is not complete yet. 3.1. Encryption The data encryption option adds overhead to the IPFIX data transfer. It may limit the rate that an Exporter can report its Flow Records to the Collector due to the resource requirement for running encryption. If the IPFIX messages do not carry sensitive information, then the TLS/DTLS Record Protocol can be used to carry data without encryption. 3.2. Authentication TLS authentication and the establishment of secrets are based on certificates and asymmetric cryptography. This makes TLS/DTLS transport much more expensive. One-way authentication may be used when the Exporter's identity can be assured. Mutual authentication SHOULD be required when the identities of the IPFIX Device and the Collector can't be assured. 4. IANA Considerations IANA is requested to assign one SCTP port number, one PR-SCTP port number, one TCP port number and one UPD number which will be the default port for IPFIX/TLS over SCTP , IPFIX/TLS over TCP , IPFIX/ DTLS over PR-SCTP and IPFIX/DTLS over UDP separately, as defined in this document. 5. Acknowledgments 6. References 6.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. Paxson, "Stream Control Transmission Protocol", RFC 2960, October 2000. [3] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Miao, et al. Expires July 27, 2007 [Page 7] Internet-Draft draft-yuzhi-ipfix-transport-tls-01.txt January 2007 Protocol Version 1.1", RFC 4346, April 2006. [4] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security", RFC 4347, April 2006. [5] Jungmaier, A., Rescorla, E., and M. Tuexen, "Transport Layer Security over Stream Control Transmission Protocol", RFC 3436, December 2002. [6] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. Conrad, "Stream Control Transmission Protocol (SCTP) Partial Reliability Extension", RFC 3758, May 2004. [7] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002. [8] Claise, B., "Specification of the IPFIX Protocol for the Exchange", draft-ietf-ipfix-protocol-24 (work in progress), November 2006. [9] Sadasivan, G., "Architecture for IP Flow Information Export", draft-ietf-ipfix-architecture-12 (work in progress), September 2006. 6.2. Informative References [10] Tuexen, M., "Datagram Transport Layer Security for Stream Control Transmission Protocol", draft-tuexen-dtls-for-sctp-01 (work in progress), October 2006. Appendix A. An Appendix Authors' Addresses Miao Fuyou Huawei Technologies No. 3, Xinxi Rd Shangdi Information Industry Base Beijing 100085 P.R. China Phone: +86 10 8288 2008 Email: miaofy@huawei.com URI: www.huawei.com Miao, et al. Expires July 27, 2007 [Page 8] Internet-Draft draft-yuzhi-ipfix-transport-tls-01.txt January 2007 Ma Yuzhi Huawei Technologies No. 3, Xinxi Rd Shangdi Information Industry Base Beijing 100085 P.R. China Phone: +86 10 8288 2008 Email: myz@huawei.com URI: www.huawei.com David Harrington Huawei Technologies (USA) 1700 Alma Drive Plano, TX 75075 USA Phone: +1 603 436 8634 Email: dharrington@huawei.com URI: www.huawei.com Miao, et al. Expires July 27, 2007 [Page 9] Internet-Draft draft-yuzhi-ipfix-transport-tls-01.txt January 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Miao, et al. Expires July 27, 2007 [Page 10]