idnits 2.17.1 draft-bclaise-ipfix-reliability-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 472. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 444. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 451. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 457. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The Collecting Process MUST either process all the Data Records contained into an IPFIX Messages, or MUST not process any of the Data Records contained in an IPFIX Messages. By processing, the authors mean the aggregating or filtering functions. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 2006) is 6616 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-15) exists of draft-ietf-ipfix-info-09 == Outdated reference: A later version (-26) exists of draft-ietf-ipfix-protocol-17 -- Unexpected draft version: The latest known version of draft-ietf-ipfix-arch is -02, but you're referring to -08. -- Possible downref: Normative reference to a draft: ref. 'IPFIX-ARCH' ** Obsolete normative reference: RFC 2960 (Obsoleted by RFC 4960) ** Downref: Normative reference to an Informational RFC: RFC 3237 -- Possible downref: Non-RFC (?) normative reference: ref. 'RSERPOOL-ARCH' == Outdated reference: A later version (-10) exists of draft-ietf-rserpool-policies-02 ** Downref: Normative reference to an Experimental draft: draft-ietf-rserpool-policies (ref. 'RSERPOOL-POLICIES') == Outdated reference: A later version (-12) exists of draft-ietf-ipfix-as-05 -- Obsolete informational reference (is this intentional?): RFC 2246 (ref. 'TLS') (Obsoleted by RFC 4346) Summary: 7 errors (**), 0 flaws (~~), 7 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 B. Claise 2 P. Aitken 3 Internet Draft R. Stewart 4 draft-bclaise-ipfix-reliability-01.txt P. Lei 5 Expires: September 07 2006 Cisco Systems 6 March 2006 8 IPFIX Reliability Extensions 10 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress". 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html 31 This Internet-Draft will expire on September 07, 2006. 33 Copyright Notice 35 Copyright (C) The Internet Society (2006). 37 Abstract 39 This memo defines an extension to the IP Flow Information eXport 40 (IPFIX) protocol in order to accommodate the specific requirements of 41 billing. 43 Conventions used in this document 44 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 45 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 46 document are to be interpreted as described in RFC 2119. 48 Table of Contents 50 1. Open Issues..................................................2 51 2. Introduction.................................................2 52 2.1 IPFIX Documents Overview...................................3 53 3. Terminology..................................................3 54 4. Reliability..................................................4 55 4.1 Requirements...............................................4 56 4.2 Choice of the IPFIX Transport Protocol.....................4 57 4.3 Backup and Failover........................................5 58 4.4 Reliable Server Pooling Support............................5 59 4.5 Application Level Acknowledgments..........................6 60 5. Uniqueness...................................................6 61 5.1 Requirements...............................................6 62 5.2 Data Records De-duplication and Completeness...............7 63 6. Security.....................................................7 64 6.1 Requirements...............................................7 65 6.2 IPsec or TLS...............................................8 66 7. Security Considerations......................................8 67 8. The Collecting Process' side.................................8 68 9. References...................................................8 69 9.1 Normative References.......................................8 70 9.2 Informative References.....................................9 72 1. Open Issues 74 This section covers the open issues, still to be resolved/updated in 75 this draft. 77 1. Investigate whether the application level acknowledgments are 78 required. 79 2. The round-robin RserPool policy is the only that makes for IPFIX. 80 Should we have a new policy that goes send back to the primary 81 when he is back online? 83 2. Introduction 85 The IP Flow Information eXport (IPFIX) protocol serves for 86 transmitting information related to measured IP traffic over the 87 Internet. The protocol specification in [IPFIX-PROTO] defines how 88 Information Elements are transmitted. For Information Elements, it 89 specifies the encoding of a set of basic data types. 91 The list of Information Elements that can be transmitted by the 92 protocol, such as Flow attributes (source IP address, number of 93 packets, etc.) and information about the Metering and Exporting 94 Processes (packet Observation Point, sampling rate, Flow timeout 95 interval, etc.), is specified in [IPFIX-INFO]. 97 The IPFIX Working Group went through the process of specifying the 98 requirements for the export of measured IP flow information out of 99 routers, traffic measurement probes, and middleboxes [RFC3917]. While 100 the generic requirements for all application types were specified, 101 the appendix explains the derivation of the requirements from the 102 applications: it expresses the level of requirements (may, should, 103 must), per application, for every single requirement. The following 104 applications were looked at: QoS monitoring, attack/intrusion 105 detection, traffic engineering, traffic profiling, and usage based 106 billing. However, as expressed in the IPFIX Applicability Statement 107 draft [IPFIX-AS], it must be noted that the reliability requirements 108 defined in [RFC3917] are not sufficient to guarantee the level of 109 reliability that is needed for many usage-based accounting systems. 110 Particular reliability requirements for accounting systems are 111 discussed in [RFC2975]. 113 This document specifies how the IPFIX requirements and improvements 114 to be suitable for billing applications that require a higher level 115 of reliable. 117 2.1 IPFIX Documents Overview 119 The IPFIX protocol provides network administrators with access to IP 120 flow information. The architecture for the export of measured IP 121 flow information out of an IPFIX exporting process to a collecting 122 process is defined in [IPFIX-ARCH], per the requirements defined in 123 [RFC3917]. The IPFIX protocol document [IPFIX-PROTO] specifies how 124 IPFIX data record and templates are carried via a congestion-aware 125 transport protocol from IPFIX exporting processes to IPFIX collecting 126 process. IPFIX has a formal description of IPFIX information 127 elements, their name, type and additional semantic information, as 128 specified in [IPFIX-INFO]. Finally [IPFIX-AS] describes what type of 129 applications can use the IPFIX protocol and how they can use the 130 information provided. It furthermore shows how the IPFIX framework 131 relates to other architectures and frameworks. This document 132 specifies how IPFIX can be made suitable for billing applications 133 that require a higher level of reliable. 135 3. Terminology 137 The IPFIX-specific terminology used in this document is defined in 138 section 3 of [IPFIX-PROTO]. As in [IPFIX-PROTO], these IPFIX- 139 specific terms have the first letter of a word capitalized when used 140 in this document. As a minimum, the terms defined in the terminology 141 summary table (figure A) are used throughout this document. 143 +------------------+---------------------------------------------+ 144 | | Contents | 145 | +--------------------+------------------------+ 146 | Set | Template | Record | 147 +------------------+--------------------+------------------------+ 148 | Data Set | / | Data Record(s) | 149 +------------------+--------------------+------------------------+ 150 | Template Set | Template Record(s) | / | 151 +------------------+--------------------+------------------------+ 152 | Options Template | Options Template | / | 153 | Set | Record(s) | | 154 +------------------+--------------------+------------------------+ 155 Figure A: Terminology Summary Table 157 4. Reliability 159 4.1 Requirements 161 Billing applications require reliability to ensure that exported Data 162 Records are received by a collector. 164 A dedicated mechanism or dedicated mechanisms at the protocol level 165 should allow an extra level of reliability for the Data Records. 167 4.2 Choice of the IPFIX Transport Protocol 169 The IPFIX Protocol Specification [IPFIX-PROTO] has been designed to 170 be transport protocol independent. The IPFIX reliability extension 171 required the use of SCTP [RFC2960] using the PR-SCTP [RFC3758] 172 extension. Refer to [IPFIX-PROTO] for the detailed specification of 173 SCTP in IPFIX. The UDP and TCP transport protocols, which may be 174 used in IPFIX under certain conditions [IPFIX-PROTO], MUST NOT be 175 used for the IPFIX reliability extension. 177 [IPFIX-PROTO] specifies that the IPFIX Template Set and Options 178 Template Set MUST be sent over the reliable stream zero. The IPFIX 179 reliability extensions impose that the Data Records MUST also be sent 180 over a reliable stream. The reliable stream on which the Data 181 Records are sent MAY be the stream zero. The reliable stream on 182 which the Data Records are sent MAY be another reliable stream than 183 stream zero. 185 4.3 Backup and Failover 187 The Collecting Process failover MUST be supported by the Exporting 188 Process, for which a second SCTP association MUST be opened in 189 advance. All Templates and Option Templates MUST be sent ahead of 190 time to the second SCTP association. The SCTP association parameters 191 SHOULD be tuned in order to allow a minimum detection time in case of 192 connection failure. 194 SCTP provides the ability of a sender to retrieve the unacknowledged 195 data when an association fails. Each SCTP API uses various 196 definitions to ask the SCTP interface for this retrieval. An example 197 of this can be found in the SOCKET's API (draft-ietf-tsvg-sctpsocket- 198 11.txt) it is called a "SCTP_SEND_FAILED" notification. To receive it 199 the sender subscribes to the "SCTP_send_failure_event" using the 200 socket option SCTP_EVENTS. Each Exporting process should use such a 201 mechanism to receive these send failed notifications. 203 After subscribing to the SCTP's API for failure data notifications, 204 an SCTP sender, at the failing of an association to a collector, will 205 be able to retrieve all of the pending data that has been queued to 206 the collector but NOT acknowledged. Each notification comes with the 207 data, and an indication as to if the data was SENT and not 208 acknowledged or if the data was never sent (due to congestion or 209 receiver window limitations). The Exporting process MUST retransmit 210 this information to its backup collector. Information that was never 211 sent can be safely sent to the backup collector just like other new 212 data. Data that as been sent to the previous association but not 213 acknowledged should be processed with care by the backup collector 214 since it is possible that the data was read and processed already by 215 the failed collector. 217 4.4 Reliable Server Pooling Support 219 The RFC 3237 "Requirements for Reliable Server Pooling" [RFC3237] 220 that clearly express the requirements for Reliable Server Pooling 221 (RserPool), could easily be applied to IPFIX when an extra set of 222 reliability is required. If the Exporting Process and Collecting 223 Process require a more capable fault tolerance and higher 224 availability, the (RSerPool) architecture [RSERPOOL-ARCH] SHOULD be 225 used. RSerPool uses the features of SCTP. 227 The RSerPool architecture provides a framework for building fault 228 tolerant and highly available client/server applications between Pool 229 Users (clients/users) and Pool Elements (servers/services). Pools are 230 identified by a Pool Handle (name). In the context of RSerPool for 231 IPFIX, the Exporting Processes are Pool Users and the Collecting 232 Processes are the Pool Elements, which provide the collection 233 services to the Exporting Processes. 235 The Collecting Processes must be configured into the desired pool(s) 236 and registered under the desired Pool Handle. Collecting Processes 237 may be part of multiple pools and thus provide collection services to 238 pools. The number of Collecting Processes may be increased 239 dynamically by simply having additional Collecting Processes register 240 into the pool. Similarly, the number may be decreased by having some 241 Collecting Processes de-register from the pool. The Collecting 242 Process should also provide a state context value to RSerPool to 243 allow any Collecting Process that may take over for a failed 244 Collecting Process to quickly lookup this state context to resume 245 collecting services. 247 The Exporting Processes use services of the desired pool by sending 248 the export information to the desired Pool Handle. If this is the 249 first message sent to the pool, RSerPool will select an available 250 Collecting Process to be used for this Exporting Process according to 251 the pool's selection policy [RSERPOOL-POLICIES]. The association 252 between the Exporting Process and selected Collecting Process will be 253 maintained unless the Exporting Process restarts, or a failover has 254 occurred for the Collecting Process. That is, additional sends to 255 the same Pool Handle will result in messages being sent to the same 256 Collecting Process. 258 When a Collecting Process fails, RSerPool will automatically select a 259 new Collecting Process from the pool and will associate the new 260 process to the Exporting Process. The data retrieval procedures 261 described in 4.3.1 above will be performed on behalf of the Exporting 262 and new Collecting Processes. 264 4.5 Application Level Acknowledgments 266 EDITOR'S NOTE: evaluate and potentially write some text 268 5. Uniqueness 270 5.1 Requirements 272 Billing applications require a de-duplication mechanism in order to 273 eliminate redundant duplication of Data Records. They also require a 274 mechanism to uniquely identify Data Records on different Collectors. 276 A typical example is an export transport connection failure to the 277 primary Collector, which triggers export to the backup Collector. 278 In order to process all the billing Data Records, the primary 279 Collector must identify whether duplicated Data Records have been 280 received during the transport connection failure, must transfer all 281 the Data Records from the backup Collector, and must eliminate the 282 duplicate ones. 284 5.2 Data Records De-duplication and Completeness 286 The Collecting Process MUST create an unique packet ID out of the 287 IPFIX Message Export Time, Sequence Number, Source ID, and Exporter. 289 The Collector MUST associate every Data Record with this unique 290 packet ID before one of the two following tasks is executed: 291 - Data Records de-duplication. 292 - Data Records accumulation for other Collector(s) in case of 293 collector failover or partial export to different Collectors. 295 The Collector, which is considered as the primary Collector, SHOULD 296 check the Data Records de-duplication and Data Records accumulation 297 with other Collectors before executing any record aggregation or 298 filtering. 300 Once the de-duplication and accumulation tasks are executed, the 301 unique packet ID associated with the Data Records MAY be discarded. 303 Note that the unique packet ID could also be useful for Data Records 304 accumulation in case of duplicate export to two Collectors on the top 305 of UDP, which doesn't guarantee the reliable delivery of IPFIX 306 Messages. 308 EDITOR'S NOTE: 309 - this should be a little bit expanded to explain how the primary 310 collector gets the data records from the secondary collector, 311 discard them if already available, and store them if not 312 available. 313 - Should also explain what is a primary collector? Do we need a 314 communication between the 2 collectors? We don't want a situation 315 where primary collector is down, and the backup doesn't retrieve 316 the information from the "primary". To solve this, can we have a 317 kind of HSRP priority, set by the router, which is the only one to 318 know where one collector is down (or at least, when the connection 319 between the router and the collector is down, which is what we 320 care about) 322 6. Security 324 6.1 Requirements 325 Billing applications require security to prevent tampering by 326 ensuring the validity of the received Data Records, while preventing 327 unauthorized access to those Data Records to ensure privacy. 329 Proper security mechanisms are needed in order to avoid tampering and 330 eavesdropping. 332 6.2 IPsec or TLS 334 The IPFIX protocol MUST run on the top of IPsec or TLS [TLS], as 335 specified in [IPFIX-PROTO]. 337 7. Security Considerations 339 This draft is an extension the IPFIX protocol specifications. As 340 such, it does not address new security considerations that were not 341 covered in [IPFIX-PROTO]. 343 8. The Collecting Process' side 345 After the detection of the SCTP association failure, the primary 346 Collecting Process SHOULD query all the Data Records from the 347 secondary Collecting Process on regular basis, in order to de- 348 duplicate the Data Records and to complete the billing records. 350 The Collecting Process MUST either process all the Data Records 351 contained into an IPFIX Messages, or MUST not process any of the Data 352 Records contained in an IPFIX Messages. By processing, the authors 353 mean the aggregating or filtering functions. 355 9. References 357 9.1 Normative References 359 [IPFIX-INFO] Quittek, J., Bryant S., Claise, B., Meyer, J. 360 "Information Model for IP Flow Information Export" draft-ietf-ipfix- 361 info-09, July 2005 363 [IPFIX-PROTO] Claise, B., "Information Model for IP Flow Information 364 Export" draft-ietf-ipfix-protocol-17, July 2005 366 [IPFIX-ARCH] Sadasivan, G., Brownlee, N., Claise, B., Quittek, J., 367 "Architecture Model for IP Flow Information Export" draft-ietf-ipfix- 368 arch-08.txt", May 2005 370 [RFC2960] Stewart, R. (ed.) "Stream Control Transmission Protocol", 371 RFC 2960, October 2000 373 [RFC3237] Xie, Q., Stewart, R., Shore, M., Ong, L., Loughney, J., 374 Stillman, M., " Requirements for Reliable Server Pooling ", RFC 375 3237, January 2002 377 [RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., Conrad, P. 378 "Stream Control Transmission Protocol (SCTP) Partial Reliability 379 Extension", RFC 3758, May 2004 381 [RSERPOOL-ARCH] Tuexen, M., Xie, Q., Stewart, F., Shore, M., 382 Loughney, J., Silverton, A., " Architecture for Reliable Server 383 Pooling "draft-ietf-rserpool-arch-10.txt", July 2005 385 [RSERPOOL-POLICIES] Tuexen, M., Dreibholz, T., "Reliable Server 386 Pooling Policies" draft-ietf-rserpool-policies-02.txt, February 2006 388 9.2 Informative References 390 [RFC3917] Quittek, J., Zseby, T., Claise, B., Zander, S., 391 "Requirements for IP Flow Information Export" RFC 3917, October 2004 393 [IPFIX-AS] Zseby, T., Boschi, E., Brownlee, N., Claise, B., "IPFIX 394 Applicability", draft-ietf-ipfix-as-05.txt, May 2005 396 [RFC2975] Aboba, B., Arkko, J., Harrington, D. "Introduction to 397 Accounting Management", RFC 2975, October 2000 399 [TLS] Dierks, T. and C. Allen, "The TLS Protocol Version 400 1.0", RFC 2246, January 1999. 402 Authors' Addresses 404 Benoit Claise 405 Cisco Systems 406 De Kleetlaan 6a b1 407 1831 Diegem 408 Belgium 409 Phone: +32 2 704 5622 410 E-mail: bclaise@cisco.com 412 Paul Aitken 413 Cisco Systems 414 3rd Floor, 96 Commercial Quay, Commercial Street 415 EH6 6LX Edinburgh 416 Scotland 417 Phone: +44 (0)131 561-3616 418 E-mail: paitken@cisco.com 419 Randall R. Stewart 420 Cisco Systems 421 4875 Forest Drive 422 Suite 200 423 Columbia, SC 29206 424 United States 425 E-mail: rrs@cisco.com 427 Peter Lei 428 Cisco Systems 429 8735 W Higgins Rd, Suite 300 430 Chicago, IL 60631 431 United States 432 Phone: +1 773 695 8201 433 E-mail: peterlei@cisco.com 435 Intellectual Property Statement 437 The IETF takes no position regarding the validity or scope of any 438 Intellectual Property Rights or other rights that might be claimed 439 to pertain to the implementation or use of the technology described 440 in this document or the extent to which any license under such 441 rights might or might not be available; nor does it represent that 442 it has made any independent effort to identify any such rights. 443 Information on the procedures with respect to rights in RFC 444 documents can be found in BCP 78 and BCP 79. 446 Copies of IPR disclosures made to the IETF Secretariat and any 447 assurances of licenses to be made available, or the result of an 448 attempt made to obtain a general license or permission for the use 449 of such proprietary rights by implementers or users of this 450 specification can be obtained from the IETF on-line IPR repository 451 at http://www.ietf.org/ipr. 453 The IETF invites any interested party to bring to its attention any 454 copyrights, patents or patent applications, or other proprietary 455 rights that may cover technology that may be required to implement 456 this standard. Please address the information to the IETF at ietf- 457 ipr@ietf.org. 459 The IETF has been notified of intellectual property rights claimed 460 in regard to some or all of the specification contained in this 461 document. For more information consult the online list of claimed 462 rights. 464 Disclaimer of Validity 466 This document and the information contained herein are provided on 467 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 468 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 469 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 470 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 471 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 472 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 474 Copyright Statement 476 Copyright (C) The Internet Society (2006). This document is subject 477 to the rights, licenses and restrictions contained in BCP 78, and 478 except as set forth therein, the authors retain all their rights. 480 Acknowledgment 482 Funding for the RFC Editor function is currently provided by the 483 Internet Society.