idnits 2.17.1 draft-trammell-ipfix-sctp-change-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 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 376. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 387. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 394. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 400. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- 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 (August 1, 2007) is 6110 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) == Missing Reference: 'RFC 2960' is mentioned on line 266, but not defined ** Obsolete undefined reference: RFC 2960 (Obsoleted by RFC 4960) == Missing Reference: 'RFC 3309' is mentioned on line 266, but not defined ** Obsolete undefined reference: RFC 3309 (Obsoleted by RFC 4960) == Missing Reference: 'RFC 3758' is mentioned on line 267, but not defined == Missing Reference: 'UDP' is mentioned on line 258, but not defined == Missing Reference: 'TCP' is mentioned on line 259, but not defined == Outdated reference: A later version (-26) exists of draft-ietf-ipfix-protocol-24 == Outdated reference: A later version (-08) exists of draft-ietf-ipfix-implementation-guidelines-06 ** Downref: Normative reference to an Informational draft: draft-ietf-ipfix-implementation-guidelines (ref. 'I-D.ietf-ipfix-implementation-guidelines') ** Obsolete normative reference: RFC 2960 (Obsoleted by RFC 4960) ** Obsolete normative reference: RFC 3309 (Obsoleted by RFC 4960) Summary: 6 errors (**), 0 flaws (~~), 8 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPFIX Working Group B. Trammell 3 Internet-Draft CERT/NetSA 4 Updates: XXXX (if approved) E. Boschi 5 Intended status: Standards Track Hitachi Europe 6 Expires: February 2, 2008 August 1, 2007 8 IP Flow Information Export (IPFIX) SCTP Stream Restriction Change 9 draft-trammell-ipfix-sctp-change-01.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on February 2, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 40 Abstract 42 The IPFIX protocol mandates the use of PR-SCTP as transport protocol. 43 The document specifies the transmission of Templates over SCTP stream 44 zero with reliable delivery and the transmission of Data Records over 45 separate streams. This constraint is unnecessary. This document 46 relaxes all restrictions on the use of SCTP streams within IPFIX, 47 allowing IPFIX implementations to use SCTP streams as most 48 appropriate for their respective applications. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 3. Usage of Streams in PR-SCTP for IPFIX export . . . . . . . . . 4 55 4. Changes to IPFIX Protocol Specification . . . . . . . . . . . 5 56 4.1. Stream Restriction Changes . . . . . . . . . . . . . . . . 5 57 4.2. SCTP Reliability . . . . . . . . . . . . . . . . . . . . . 6 58 4.3. SCTP References . . . . . . . . . . . . . . . . . . . . . 6 59 4.4. IPFIX Implementation Guidelines changes . . . . . . . . . 7 60 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 61 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 62 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 63 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 64 8.1. Normative References . . . . . . . . . . . . . . . . . . . 8 65 8.2. Informative References . . . . . . . . . . . . . . . . . . 8 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 67 Intellectual Property and Copyright Statements . . . . . . . . . . 10 69 1. Introduction 71 The specification of the IPFIX Protocol [I-D.ietf-ipfix-protocol] 72 mandates the use of PR-SCTP as transport protocol for IPFIX. SCTP as 73 specified in RFC 2960 [RFC2960] and RFC 3309 [RFC3309] using the PR- 74 SCTP extension defined in RFC 3758 [RFC3758] MUST be implemented by 75 all compliant implementations. 77 Section 10.2.4.3 of the IPFIX Protocol specification 78 [I-D.ietf-ipfix-protocol] requires that 80 "An Exporting Process MUST request at least two outbound streams per 81 association. The first stream (referred to as stream zero in the 82 rest of this document), is used to send the Template Set and the 83 Options Template Set. Data Sets MUST NOT be sent on stream zero." 85 This is an unnecessary constraint, derived in part from a 86 misunderstanding during the IPFIX Protocol development process of the 87 nature of SCTP streams and the per-message nature of the SCTP partial 88 reliability extension. This document updates the specification of 89 the use of SCTP and PR-SCTP as transport protocol for IPFIX, allowing 90 Data Sets, Template Sets and Option Template Sets to be sent over any 91 SCTP stream. No limit is given on the number of Streams an Exporting 92 Process must request (e.g., one outbound stream sending all templates 93 and data is perfectly acceptable). 95 The motivation behind this change is to allow different IPFIX 96 implementations to make the most appropriate use of SCTP streams, 97 which are used to isolate different logical groups of messages in 98 order to avoid the head-of-line blocking issue that can reduce total 99 throughput in fully-reliable single-stream transport protocols such 100 as TCP. For example, one IPFIX implementation could isolate 101 information from each separate Observation Domain into its own 102 stream, a second could export inbound and outbound flow data in 103 separate streams, and a third, simpler implementation could use a 104 single stream for all templates and data. None of these arrangements 105 are possible with the IPFIX Protocol as presently specified. 107 This change does require one minor note on the handling of Template 108 Withdrawals. In the protocol as presently specified, since all 109 Template Sets (including Template Sets within Template Withdrawal 110 Messages) SHOULD appear on stream zero, there exists no case in which 111 a reused Template ID may be received and processed before the 112 Template Withdrawal Message making the ID available for reuse. With 113 the removal of this restriction, we recommend that guidelines on the 114 use of Template Withdrawals on any stream be added to the IPFIX 115 Implementation Guidelines. 117 In addition, there are a two other very minor issues with the IPFIX 118 Protocol Specification's handling of SCTP. First, it refers to 119 "unreliable" delivery over PR-SCTP, a service which PR-SCTP does not 120 provide, and fails to reference RFC 3309, which corrects a problem 121 with SCTP's checksum mechanism. As this document corrects issues 122 with the interaction between IPFIX and SCTP, these issues are also 123 corrected in sections 4.2 and 4.3. 125 2. Terminology 127 Terms used in this document that are defined in the Terminology 128 section of the IPFIX Protocol [I-D.ietf-ipfix-protocol] document are 129 to be interpreted as defined there. 131 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 132 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 133 document are to be interpreted as described in RFC 2119 [RFC2119]. 135 3. Usage of Streams in PR-SCTP for IPFIX export 137 This section updates and supersedes any language in the IPFIX 138 Protocol Specification regarding stream selection. The new stream 139 selection rules are specified here in their entirety. In case of any 140 conflict with the IPFIX Protocol Specification, the following three 141 paragraphs are normative. Specific changes to the IPFIX Protocol 142 Specification and IPFIX Implementation Guidelines appear in the 143 following section. 145 An Exporting Process may request any number of SCTP streams during 146 SCTP association establishment. 148 An Exporting Process may send Template Sets and Options Template Sets 149 on any SCTP stream. Template Sets and Options Template Sets MUST be 150 sent reliably, and MUST be sent in order within a stream. An 151 Exporting Process may send Data Sets on any SCTP Stream, with full or 152 partial reliability, with ordered or unordered delivery. 154 A Collecting Process MUST accept Template Sets, Options Template 155 Sets, Template Witdrawal Sets, and Data Sets on any SCTP stream. 157 Additionally, an Exporting Process sending Template Withdrawal 158 Messages SHOULD ensure to the extent possible that the Template 159 Withdrawal Messages and subsequent Template Sets reusing the 160 withdrawn Template IDs are received and processed at the Collecting 161 Process in proper order. The Exporting Process can achieve this by 162 one of two possible methods: 1. by sending a Template Withdrawal 163 Message reliably, in order, and on the same stream as the subsequent 164 Template Set reusing its ID; or 2. by waiting an appropriate amount 165 of time (on the scale of one minute) after sending a Template 166 Withdrawal Message before attempting to reuse the withdrawn Template 167 ID. 169 4. Changes to IPFIX Protocol Specification 171 The following are the changes that would be made to the IPFIX 172 Protocol Specification to modify it to use the unrestrictive stream 173 selection rules in the previous section, and to clarify other issues 174 regarding the interaction of IPFIX with SCTP. 176 4.1. Stream Restriction Changes 178 Paragraph 5 of Section 8 "Template Management" of the IPFIX Protocol 179 Specification [I-D.ietf-ipfix-protocol] is replaced as follows: 181 Template Sets and Options Template Sets may be sent on any SCTP 182 stream. Template Sets and Option Template Sets MUST be sent reliably 183 and in order. As such, the Collecting Process MUST store the 184 Template Record information for the duration of the association so 185 that it can interpret the corresponding Data Records that are 186 received in subsequent Data Sets. 188 Paragraph 14 of Section 8 "Template Management" of the IPFIX Protocol 189 Specification [I-D.ietf-ipfix-protocol] is replaced as follows: 191 The Template Withdraw Message may be sent on any SCTP stream. The 192 Template Withdraw Message MUST be sent reliably and in order. 194 Paragraph 2 of Section 9 "The Collecting Process's Side" of the IPFIX 195 Protocol Specification [I-D.ietf-ipfix-protocol] is replaced as 196 follows: 198 The Collecting Process SHOULD listen for a new association request 199 from the Exporting Process. The Exporting Process will request a 200 number of streams to use for export. An Exporting Process MAY ask 201 for and support more than one SCTP stream. 203 Section 10.2.4.3 "Stream" of the IPFIX Protocol Specification 204 [I-D.ietf-ipfix-protocol] is replaced in full as follows. Note that 205 these changes also modify text on the reliability of IPFIX Message 206 transmission within streams, as noted in the following section: 208 An Exporting Process may request any number of outbound SCTP streams 209 per association. Each of these streams may be used for the 210 transmission of IPFIX Messages containing Data Sets, Template Sets, 211 and/or Options Template Sets. 213 Depending on the requirements of the application, the Exporting 214 Process may send Data Sets with full or partial reliability, using 215 ordered or out-of-order delivery, over any SCTP stream established 216 during SCTP Association setup. 218 When IPFIX Messages containing Data Sets are exported partially 219 reliably, they SHOULD be marked for retransmission as long as there 220 is room in the SCTP send queues. However, if the queue overflows 221 during times of congestion or other retransmission events, the oldest 222 IPFIX Message that has been transmitted and marked as partially 223 reliable should be freed and marked to be skipped per the PR-SCTP 224 [RFC3758] specification. The freed buffer space should then be re- 225 used for the new Data Sets being exported. 227 4.2. SCTP Reliability 229 PR-SCTP [RFC3758] provides partially reliable transport with a 230 variety of levels of partial reliability as defined by a variety of 231 partial reliability policies, as noted in the IPFIX Implementation 232 Guidelines [I-D.ietf-ipfix-implementation-guidelines]. However, 233 there is no such thing as "unreliable" SCTP transport. One such 234 reference in section 10.2.4.3 was replaced in the previous section. 235 In addition paragraph 1 of section 10.2.2 "Reliability" of the IPFIX 236 Protocol Specification [I-D.ietf-ipfix-protocol] is replaced as 237 follows: 239 The SCTP transport protocol is by default reliable, but has the 240 capability to deliver messages with partial reliability [RFC3758]. 242 4.3. SCTP References 244 Note also that references to the SCTP documents in the IPFIX Protocol 245 Specification are incomplete. References to SCTP as specified in RFC 246 2960 [RFC2960] should also reference RFC 3309 [RFC3309], which 247 updates SCTP to use CRC32 for checksums as opposed to the originally 248 specified Adler-32. This is an oversight, and is not intended to 249 imply that SCTP with Adler-32 checksums should be used as a transport 250 protocol for IPFIX. 252 Consequently, paragraph 2 of section 10.1 "Transport Compliance and 253 Transport Usage" of the IPFIX Protocol Specification 254 [I-D.ietf-ipfix-protocol] is replaced as follows: 256 SCTP as specified in [RFC 2960] and [RFC 3309] using the PR-SCTP 257 extension defined in [RFC 3758] MUST be implemented by all compliant 258 implementations. UDP [UDP] MAY also be implemented by compliant 259 implementations. TCP [TCP] MAY also be implemented by compliant 260 implementations. 262 Paragraph 1 of section 10.2 "SCTP" of the IPFIX Protocol 263 Specification [I-D.ietf-ipfix-protocol] is replaced as follows: 265 This section describes how IPFIX can be transported over SCTP as 266 specified in [RFC 2960] and [RFC 3309] using the PR-SCTP extension 267 defined in [RFC 3758]. 269 4.4. IPFIX Implementation Guidelines changes 271 The following text is added to Section 6.1 "SCTP" of the IPFIX 272 Implementation Guidelines [I-D.ietf-ipfix-implementation-guidelines]. 273 (Note that as the text of the Implementation Guidelines is still 274 subject to change, the absolute position of the text is not specified 275 here): 277 Since Template Sets and Template Withdrawal Messages may be sent on 278 any SCTP stream, a Template Withdrawal Message may withdraw a 279 template sent on a different stream, and a Template Set may reuse a 280 Template ID withdrawn by a Template Withdrawal Message sent on a 281 different stream. Therefore, an Exporting Process sending Template 282 Withdrawal Messages SHOULD ensure to the extent possible that the 283 Template Withdrawal Messages and subsequent Template Sets reusing the 284 withdrawn Template IDs are received and processed at the Collecting 285 Process in proper order. The Exporting Process can achieve this by 286 one of two possible methods: 1. by sending a Template Withdrawal 287 Message reliably, in order, and on the same stream as the subsequent 288 Template Set reusing its ID; or 2. by waiting an appropriate amount 289 of time (on the scale of one minute) after sending a Template 290 Withdrawal Message before attempting to reuse the withdrawn Template 291 ID. 293 5. Security Considerations 295 The same security considerations as for the IPFIX Protocol 296 [I-D.ietf-ipfix-protocol] apply. 298 6. IANA Considerations 300 This document has no actions for IANA. 302 7. Acknowledgements 304 Thanks to Randall Stewart, Michael Tuexen, and Peter Lei for 305 technical assistance with PR-SCTP. Thanks to Benoit Claise and Paul 306 Aitken for refining the new stream restriction rules in this draft. 308 8. References 310 8.1. Normative References 312 [I-D.ietf-ipfix-protocol] 313 Claise, B., "Specification of the IPFIX Protocol for the 314 Exchange", draft-ietf-ipfix-protocol-24 (work in 315 progress), November 2006. 317 [I-D.ietf-ipfix-implementation-guidelines] 318 Boschi, E., "IPFIX Implementation Guidelines", 319 draft-ietf-ipfix-implementation-guidelines-06 (work in 320 progress), June 2007. 322 [RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., 323 Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., 324 Zhang, L., and V. Paxson, "Stream Control Transmission 325 Protocol", RFC 2960, October 2000. 327 [RFC3309] Stone, J., Stewart, R., and D. Otis, "Stream Control 328 Transmission Protocol (SCTP) Checksum Change", RFC 3309, 329 September 2002. 331 [RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. 332 Conrad, "Stream Control Transmission Protocol (SCTP) 333 Partial Reliability Extension", RFC 3758, May 2004. 335 8.2. Informative References 337 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 338 Requirement Levels", BCP 14, RFC 2119, March 1997. 340 Authors' Addresses 342 Brian H. Trammell 343 CERT Network Situational Awareness 344 Software Engineering Institute 345 4500 Fifth Avenue 346 Pittsburgh, Pennsylvania 15213 347 United States 349 Phone: +1 412 268 9748 350 Email: bht@cert.org 352 Elisa Boschi 353 Hitachi Europe SAS 354 Immeuble Le Theleme 355 1503 Route les Dolines 356 06560 Valbonne 357 France 359 Phone: +33 4 89874100 360 Email: elisa.boschi@hitachi-eu.com 362 Full Copyright Statement 364 Copyright (C) The IETF Trust (2007). 366 This document is subject to the rights, licenses and restrictions 367 contained in BCP 78, and except as set forth therein, the authors 368 retain all their rights. 370 This document and the information contained herein are provided on an 371 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 372 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 373 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 374 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 375 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 376 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 378 Intellectual Property 380 The IETF takes no position regarding the validity or scope of any 381 Intellectual Property Rights or other rights that might be claimed to 382 pertain to the implementation or use of the technology described in 383 this document or the extent to which any license under such rights 384 might or might not be available; nor does it represent that it has 385 made any independent effort to identify any such rights. Information 386 on the procedures with respect to rights in RFC documents can be 387 found in BCP 78 and BCP 79. 389 Copies of IPR disclosures made to the IETF Secretariat and any 390 assurances of licenses to be made available, or the result of an 391 attempt made to obtain a general license or permission for the use of 392 such proprietary rights by implementers or users of this 393 specification can be obtained from the IETF on-line IPR repository at 394 http://www.ietf.org/ipr. 396 The IETF invites any interested party to bring to its attention any 397 copyrights, patents or patent applications, or other proprietary 398 rights that may cover technology that may be required to implement 399 this standard. Please address the information to the IETF at 400 ietf-ipr@ietf.org. 402 Acknowledgment 404 Funding for the RFC Editor function is provided by the IETF 405 Administrative Support Activity (IASA).