Ipfix working Group F.Miao M.Yuzhi Internet Draft Huawei Technologies D.Harrington Huawei Technologies (USA) Expires: Mar 01, 2007 August 29, 2006 TLS and DTLS Transport Mapping for IPFIX draft-yuzhi-ipfix-transport-tls-00.txt 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 March 29, 2007. Copyright Notice Copyright (C) The Internet Society (2006). All Rights Reserved. Miao & Yuzhi Expires March 29, 2007 [Page 1] Internet-Draft TLS Transport Mapping for IPFIX August 2006 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. Table of Contents 1. Introduction.................................................2 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. UDP................................................5 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. Normative References.........................................8 Author's Addresses..............................................8 Intellectual Property Statement.................................9 Disclaimer of Validity.........................................10 Copyright Statement............................................10 Acknowledgment.................................................10 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. Miao & Yuzhi Expires March 29, 2007 [Page 2] Internet-Draft TLS Transport Mapping for IPFIX August 2006 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 RFC2119 [1]. This document uses terminology specific to SCTP as defined in section "Terminology" of RFC 2960 [5]. This document uses terminology specific to IPFIX as defined in section "Terminology" of "IPFIX Protocol Specification" [8]. 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 PR-SCTP or TCP, TLS is used to provide secure connection. If IPFIX runs over UDP, DTLS is used. An IPFIX Exporter acts as the TLS/DTLS client and an IPFIX Collector acts as the TLS/DTLS server. Miao & Yuzhi Expires March 29, 2007 [Page 3] Internet-Draft TLS Transport Mapping for IPFIX August 2006 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 (PR-SCTP) port is used as the default port for IPFIX over TLS. 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/PR-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 or PR-SCTP streams per association. The TLS handshake layer assumes that handshake messages are delivered reliably and breaks if those messages are lost, while PR-SCPT is not reliable during the lifetime of an association. In PR-SCTP, "Forward Cumulative TSN (FORWARD TSN)" chunk is sent to the peer to indicate which streams are going to be unreliable. An implementation MUST NOT send FORWARD TSN with the stream number where 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. Miao & Yuzhi Expires March 29, 2007 [Page 4] Internet-Draft TLS Transport Mapping for IPFIX August 2006 2.2.3. 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. 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 or PR-SCTP, there MUST be at least two bi-directional SCTP or PR-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 streams 0 MUST be fully reliable. IPFIX Data Sets MUST NOT be sent on Bi-directional streams 0. If the transport protocol is PR-SCTP, Bi-directional streams 0 MUST NOT be included in FORWARD TSN chunk. 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 or PR-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). Miao & Yuzhi Expires March 29, 2007 [Page 5] Internet-Draft TLS Transport Mapping for IPFIX August 2006 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 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 Miao & Yuzhi Expires March 29, 2007 [Page 6] Internet-Draft TLS Transport Mapping for IPFIX August 2006 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. 3. Security Considerations 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 (PR-SCTP) port number, one TCP port number and one UPD number which will be the default port for IPFIX/TLS over SCTP (PR-SCTP), IPFIX/TLS over TCP and IPFIX/DTLS/UDP separately, as defined in this document. 5. Acknowledgments Miao & Yuzhi Expires March 29, 2007 [Page 7] Internet-Draft TLS Transport Mapping for IPFIX August 2006 6. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] T. Dierks and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006. [3] E. Rescorla and N. Modadugu, "Datagram Transport Layer Security", RFC 4347,April 2006. [4] A. Jungmaier, E. Rescorla and M. Tuexen, "Transport Layer Security over Stream Control Transmission Protocol", RFC 3436, December 2002. [5] R. Stewart, Q. Xie, K. Morneault, C. Sharp, H. Schwarzbauer, T. Taylor, I. Rytina, M. Kalla, L. Zhang, and V. Paxson, "Stream Control Transmission Protocol", RFC 2960, October 2000. [6] R. Stewart, M. Ramalho, Q. Xie, M. Tuexen and P. Conrad, "Stream Control Transmission Protocol (SCTP) Partial Reliability Extension", RFC 3758, May 2005. [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] B. Claise, "IPFIX Protocol Specification", drft-ietf-ipfix- protocol-22.txt, June 2006. [9] G. Sadasivan, N. Brownlee, B. Claise, and J. Quittek, "Architecture for IP Flow Information Export", draft-ietf- ipfix-architecture-11.txx, June 2006. Author's Addresses Fuyou Miao Huawei Technologies No. 3, Xinxi Rd Shangdi Information Industry Base Miao & Yuzhi Expires March 29, 2007 [Page 8] Internet-Draft TLS Transport Mapping for IPFIX August 2006 Haidian District, Beijing 100085 P. R. China Phone: +86 10 8288 2008 Email: miaofy@huawei.com URI: www.huawei.com Yuzhi Ma Huawei Technologies No. 3, Xinxi Rd Shangdi Information Industry Base Haidian District, 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 Intellectual Property Statement 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. Miao & Yuzhi Expires March 29, 2007 [Page 9] Internet-Draft TLS Transport Mapping for IPFIX August 2006 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 Disclaimer of Validity 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 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. Copyright Statement Copyright (C) The Internet Society (2006). 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Miao & Yuzhi Expires March 29, 2007 [Page 10]