B. Claise Internet Draft P. Aitken draft-bclaise-ipfix-reliability-00.txt R. Stewart Expires: February 08 2006 Cisco Systems July 2005 IPFIX Protocol Specifications for Billing 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 February 08, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This memo defines an extension to the IP Flow Information eXport (IPFIX) protocol in order to accommodate the specific requirements of billing. Conventions used in this document Claise B. [Page 1]
IPFIX Protocol Specification for billing August 2005 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. Table of Contents 1. Open Issues.................................................2 2. Introduction................................................2 2.1 IPFIX Documents Overview...................................3 3. Terminology.................................................3 4. Reliability.................................................4 4.1 Requirements...............................................4 4.2 Choice of the IPFIX Transport Protocol.....................4 4.3 Backup and Failover........................................4 5. Uniqueness..................................................5 5.1 Requirements...............................................5 5.2 Data Records De-duplication and Completeness...............5 6. Security....................................................6 6.1 Requirements...............................................6 6.2 IPsec or TLS...............................................6 7. Security Considerations.....................................6 8. The Collecting ProcessÆ side................................6 9. References..................................................7 9.1 Normative References.......................................7 9.2 Informative References.....................................7 1. Open Issues This section covers the open issues, still to be resolved/updated in this draft. 1. Investigate the applicability of rserpool for the failover and load-balancing scenario. 2. Introduction The IP Flow Information eXport (IPFIX) protocol serves for transmitting information related to measured IP traffic over the Internet. The protocol specification in [IPFIX-PROTO] defines how Information Elements are transmitted. For Information Elements, it specifies the encoding of a set of basic data types. The list of Information Elements that can be transmitted by the protocol, such as Flow attributes (source IP address, number of packets, etc.) and information about the Metering and Exporting Processes (packet Observation Point, sampling rate, Flow timeout interval, etc.), is specified in [IPFIX-INFO]. Claise B. [Page 2]
IPFIX Protocol Specification for billing August 2005 The IPFIX Working Group went through the process of specifying the requirements for the export of measured IP flow information out of routers, traffic measurement probes, and middleboxes [RFC3917]. While the generic requirements for all application types were specified, the appendix explains the derivation of the requirements from the applications: it expresses the level of requirements (may, should, must), per application, for every single requirement. The following applications were looked at: QoS monitoring, attack/intrusion detection, traffic engineering, traffic profiling, and usage based billing. However, as expressed in the IPFIX Applicability Statement draft [IPFIX-AS], it must be noted that the reliability requirements defined in [RFC3917] are not sufficient to guarantee the level of reliability that is needed for many usage-based accounting systems. Particular reliability requirements for accounting systems are discussed in [RFC2975]. This document specifies how the IPFIX requirements and improvements to be suitable for billing applications that require a higher level of reliable. 2.1 IPFIX Documents Overview The IPFIX protocol provides network administrators with access to IP flow information. The architecture for the export of measured IP flow information out of an IPFIX exporting process to a collecting process is defined in [IPFIX-ARCH], per the requirements defined in [RFC3917]. The IPFIX protocol document [IPFIX-PROTO] specifies how IPFIX data record and templates are carried via a congestion-aware transport protocol from IPFIX exporting processes to IPFIX collecting process. IPFIX has a formal description of IPFIX information elements, their name, type and additional semantic information, as specified in [IPFIX-INFO]. Finally [IPFIX-AS] describes what type of applications can use the IPFIX protocol and how they can use the information provided. It furthermore shows how the IPFIX framework relates to other architectures and frameworks. This document specifies how IPFIX can be made suitable for billing applications that require a higher level of reliable. 3. Terminology The IPFIX-specific terminology used in this document is defined in section 3 of [IPFIX-PROTO]. As in [IPFIX-PROTO], these IPFIX- specific terms have the first letter of a word capitalized when used in this document. As a minimum, the terms defined in the terminology summary table (figure A) are used throughout this document. +------------------+---------------------------------------------+ | | Contents | Claise B. [Page 3]
IPFIX Protocol Specification for billing August 2005 | +--------------------+------------------------+ | Set | Template | Record | +------------------+--------------------+------------------------+ | Data Set | / | Data Record(s) | +------------------+--------------------+------------------------+ | Template Set | Template Record(s) | / | +------------------+--------------------+------------------------+ | Options Template | Options Template | / | | Set | Record(s) | | +------------------+--------------------+------------------------+ Figure A: Terminology Summary Table 4. Reliability 4.1 Requirements Billing applications require reliability to ensure that exported Data Records are received by a collector. A dedicated mechanism or dedicated mechanisms at the protocol level should allow an extra level of reliability for the Data Records. 4.2 Choice of the IPFIX Transport Protocol The IPFIX Protocol Specification [IPFIX-PROTO] has been designed to be transport protocol independent. The IPFIX reliability extension required the use of SCTP [RFC2960] using the PR-SCTP [RFC3758] extension. Refer to [IPFIX-PROTO] for the detailed specification of SCTP in IPFIX. [IPFIX-PROTO] specifies that the IPFIX Template Set and Options Template Set MUST be sent over the reliable stream zero. The IPFIX billing extension imposes that the Data Records MUST also be sent over a reliable stream. The reliable stream on which the Data Records are sent MAY be the stream zero. The reliable stream on which the Data Records are sent MAY be another reliable stream than stream zero. 4.3 Backup and Failover If Collecting Process failover is supported by the Exporting Process a second SCTP association MUST be opened in advance. All Templates and Option Templates MUST be sent ahead of time. The SCTP association parameters SHOULD be tuned in order to allow a minimum detection time in case of connection failure. Claise B. [Page 4]
IPFIX Protocol Specification for billing August 2005 SCTP provides the ability of a sender to retrieve the unacknowledged data when an association fails. Each SCTP API uses various definitions to ask the SCTP interface for this retrieval. An example of this can be found in the SOCKET's API (draft-ietf-tsvg- sctpsocket-11.txt) it is called a ææSCTP_SEND_FAILEDÆÆ notification. To receive it the sender subscribes to the ææsctp_send_failure_eventÆÆ using the socket option SCTP_EVENTS. Each Exporting process should use such a mechanism to receive these send failed notifications. After subscribing to the SCTP's API for failure data notifications, an SCTP sender, at the failing of an association to a collector, will be able to retrieve all of the pending data that has been queued to the collector but NOT acknowledged. Each notification comes with the data, and an indication as to if the data was SENT and not acknowledged or if the data was never sent (due to congestion or receiver window limitations). The Exporting process MUST retransmit this information to its backup collector. Information that was never sent can be safely sent to the backup collector just like other new data. Data that as been sent to the previous association but not acknowledged should be processed with care by the backup collector since it is possible that the data was read and processed already by the failed collector. 5. Uniqueness 5.1 Requirements Billing applications require a de-duplication mechanism in order to eliminate redundant duplication of Data Records. They also require a mechanism to uniquely identify Data Records on different Collectors. A typical example is an export transport connection failure to the primary Collector, which triggers export to the backup Collector. In order to process all the billing Data Records, the primary Collector must identify whether duplicated Data Records have been received during the transport connection failure, must transfer all the Data Records from the backup Collector, and must eliminate the duplicate ones. 5.2 Data Records De-duplication and Completeness The Collecting Process MUST create an unique packet ID out of the IPFIX Message Export Time, Sequence Number, Source ID, and Exporter. The Collector MUST associate every Data Record with this unique packet ID before one of the two following tasks is executed: Claise B. [Page 5]
IPFIX Protocol Specification for billing August 2005 - Data Records de-duplication. - Data Records accumulation for other Collector(s) in case of collector failover or partial export to different Collectors. The Collector SHOULD check the Data Records de-duplication and Data Records accumulation with other Collectors before executing any record aggregation or filtering. Once the de-duplication and accumulation tasks are executed, the unique packet ID associated with the Data Records MAY be discarded. Note that the unique packet ID could also be useful for Data Records accumulation in case of duplicate export to two Collectors on the top of UDP, which doesnÆt guarantee the reliable delivery of IPFIX Messages. 6. Security 6.1 Requirements Billing applications require security to prevent tampering by ensuring the validity of the received Data Records, while preventing unauthorised access to those Data Records to ensure privacy. Proper security mechanisms are needed in order to avoid tampering and eavesdropping. 6.2 IPsec or TLS The IPFIX protocol MUST run on the top of IPsec or TLS [TLS], as specified in [IPFIX-PROTO]. 7. Security Considerations This draft is an extension the IPFIX protocol specifications. As such, it does not address new security considerations that were not covered in [IPFIX-PROTO]. 8. The Collecting ProcessÆ side After the detection of the SCTP association failure, the primary Collecting Process SHOULD query all the Data Records from the secondary Collecting Process on regular basis, in order to de- duplicate the Data Records and to complete the billing records. The Collecting Process MUST either process all the Data Records contained into an IPFIX Messages, or MUST not process any of the Data Claise B. [Page 6]
IPFIX Protocol Specification for billing August 2005 Records contained in an IPFIX Messages. By processing, the authors mean the aggregating or filtering functions. 9. References 9.1 Normative References [IPFIX-INFO] Quittek, J., Bryant S., Claise, B., Meyer, J. "Information Model for IP Flow Information Export" draft-ietf-ipfix- info-09, July 2005 [IPFIX-PROTO] Claise, B., "Information Model for IP Flow Information Export" draft-ietf-ipfix-protocol-17, July 2005 [IPFIX-ARCH] Sadasivan, G., Brownlee, N., Claise, B., Quittek, J., "Architecture Model for IP Flow Information Export" draft-ietf-ipfix- arch-08.txt", May 2005 [RFC2960] Stewart, R. (ed.) "Stream Control Transmission Protocol", RFC 2960, October 2000 [RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., Conrad, P. "Stream Control Transmission Protocol (SCTP) Partial Reliability Extension", RFC 3758, May 2004 9.2 Informative References [RFC3917] Quittek, J., Zseby, T., Claise, B., Zander, S., "Requirements for IP Flow Information Export" RFC 3917, October 2004 [IPFIX-AS] Zseby, T., Boschi, E., Brownlee, N., Claise, B., "IPFIX Applicability", draft-ietf-ipfix-as-05.txt, May 2005 [RFC2975] Aboba, B., Arkko, J., Harrington, D. "Introduction to Accounting Management", RFC 2975, October 2000 [TLS] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999. Authors' Addresses Benoit Claise Cisco Systems De Kleetlaan 6a b1 1831 Diegem Belgium Phone: +32 2 704 5622 E-mail: bclaise@cisco.com Claise B. [Page 7]
IPFIX Protocol Specification for billing August 2005 Paul Aitken Cisco Systems 3rd Floor, 96 Commercial Quay, Commercial Street EH6 6LX Edinburgh Scotland Phone: +44 (0)131 561-3616 E-mail: paitken@cisco.com Randall R. Stewart 4875 Forest Drive Suite 200 Columbia, SC 29206 E-mail: rrs@cisco.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. 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. The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights. Claise B. [Page 8]
IPFIX Protocol Specification for billing August 2005 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 (2005). 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. Claise B. [Page 9]