idnits 2.17.00 (12 Aug 2021) /tmp/idnits14121/draft-schmoll-ipfix-testing-00.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 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 617. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 594. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 601. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 607. ** 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: The Scope Field Count MAY NOT be zero. Verify that the collector does not accept an Options Template with no scope fields. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: Note that the Scope Field Count MAY NOT be zero. Verify that the collector does not accept an Options Template with no scope fields. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: IPFIX Options Templates contain an overall Field Count and a Scope Field Count. The Field Count is the number of all fields in the Option Template Record, including the Scope Fields. The Scope Field Count MAY NOT be zero. -- 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 (February 13, 2006) is 5940 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: draft-ietf-ipfix-architecture has been published as RFC 5470 ** Downref: Normative reference to an Informational draft: draft-ietf-ipfix-architecture (ref. 'I-D.ietf-ipfix-architecture') == Outdated reference: draft-ietf-ipfix-info has been published as RFC 5102 == Outdated reference: draft-ietf-ipfix-protocol has been published as RFC 5101 Summary: 6 errors (**), 0 flaws (~~), 8 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IPFIX Working Group C. Schmoll 2 Internet-Draft Fraunhofer Institute Fokus 3 Expires: August 17, 2006 P. Aitken 4 Cisco Systems 5 February 13, 2006 7 IP Flow Information Exchange (IPFIX) Testing 8 draft-schmoll-ipfix-testing-00.txt 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on August 17, 2006. 35 Copyright Notice 37 Copyright (C) The Internet Society (2006). 39 Abstract 41 This document presents a list of tests which implementers of IP Flow 42 Information Export (IPFIX) compliant systems are encouraged to 43 perform on their IPFIX system. This document has been created to 44 help implementers test the functionality of their IPFIX exporter 45 and/or collector component. The goal of these tests is to ensure 46 that all important functions are covered by tests and thereby to gain 47 a level of confidence in the system which allows the implementer to 48 perform interoperabilty or plug tests with other IPFIX systems. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 53 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 4 54 1.2. Document Scope . . . . . . . . . . . . . . . . . . . . . . 4 55 1.3. Related Documents . . . . . . . . . . . . . . . . . . . . 4 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 57 3. Test Specifications . . . . . . . . . . . . . . . . . . . . . 7 58 3.1. Exporter/Collector Connectivity Tests . . . . . . . . . . 7 59 3.1.1. Connectivity Tests between Exporter and Collector . . 7 60 3.2. Data Template and Data Transmission Tests . . . . . . . . 7 61 3.2.1. Transmission of Simple Data Template and Data . . . . 7 62 3.2.2. Transmission of Data Template with variable-length 63 IEs and Data . . . . . . . . . . . . . . . . . . . . . 7 64 3.2.3. Flowsets with Padding . . . . . . . . . . . . . . . . 8 65 3.3. IE Tests . . . . . . . . . . . . . . . . . . . . . . . . . 8 66 3.3.1. Enterprise-specific IEs . . . . . . . . . . . . . . . 8 67 3.3.2. Reduced-size Encoding of IEs . . . . . . . . . . . . . 8 68 3.3.3. Multiple use of the same IE in one Template . . . . . 8 69 3.4. Options Templates . . . . . . . . . . . . . . . . . . . . 9 70 3.4.1. Using any IEs as Scope . . . . . . . . . . . . . . . . 9 71 3.4.2. Using multiple Scopes . . . . . . . . . . . . . . . . 9 72 3.4.3. Metering Process (MP) Statistics Option Template . . . 9 73 3.4.4. Metering Process (MP) Reliability Statistics 74 Option Template . . . . . . . . . . . . . . . . . . . 9 75 3.4.5. Exporting Process (EP) Reliability Statistics 76 Option Template . . . . . . . . . . . . . . . . . . . 10 77 3.4.6. Flow Keys Option Template . . . . . . . . . . . . . . 10 78 3.4.7. Template Withdrawal Message . . . . . . . . . . . . . 10 79 3.5. Stress/Load Tests . . . . . . . . . . . . . . . . . . . . 10 80 3.5.1. Large Number of Records for one Template . . . . . . . 11 81 3.5.2. High Rate of incoming Data Records . . . . . . . . . . 11 82 3.5.3. Large Templates with high Number of IEs . . . . . . . 11 83 3.5.4. Many new Templates within Data Template timeout 84 interval . . . . . . . . . . . . . . . . . . . . . . . 11 85 3.5.5. Multiple Exporters sending to one Collector . . . . . 11 86 3.5.6. Export from one Exporter to multiple Collectors . . . 11 87 3.6. Error Handling . . . . . . . . . . . . . . . . . . . . . . 12 88 3.6.1. Temporary Network Disconnect . . . . . . . . . . . . . 12 89 3.6.2. Exporter Termination and Restart during Data 90 Transmission . . . . . . . . . . . . . . . . . . . . . 12 91 3.6.3. Collector Termination and Restart during Data 92 Transmission . . . . . . . . . . . . . . . . . . . . . 12 93 3.6.4. Incorrect Template Records . . . . . . . . . . . . . . 13 94 3.6.5. Export of defective IPFIX Data record . . . . . . . . 13 95 3.6.6. Export of non-matching Template and Data . . . . . . . 13 96 3.6.7. Incorrect Set IDs . . . . . . . . . . . . . . . . . . 13 97 3.6.8. Flowsets with Invalid Padding . . . . . . . . . . . . 13 98 3.6.9. Re-using the same Template ID inside the Template 99 Expiry Time . . . . . . . . . . . . . . . . . . . . . 14 100 3.6.10. Re-using the same Template ID after the Template 101 Expiry Time . . . . . . . . . . . . . . . . . . . . . 14 102 3.6.11. Re-sending an existing template ID without 103 withdrawal . . . . . . . . . . . . . . . . . . . . . . 14 104 4. Security Considerations . . . . . . . . . . . . . . . . . . . 15 105 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 106 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 107 Intellectual Property and Copyright Statements . . . . . . . . . . 17 109 1. Introduction 111 The IPFIX protocol has been developed for the purpose of exporting IP 112 flow information from devices such as routers or measurement stations 113 to mediation, accounting, and network management systems. It is 114 intended for the purposes of Internet research, QoS and traffic 115 measurement, attack and intrusion detection reporting, accounting, 116 and billing. 118 The IPFIX architecture [I-D.ietf-ipfix-architecture] defines the 119 different components which are involved in this data export process. 120 For a testable IPFIX software toolkit one needs at least the IPFIX 121 exporter and the IPFIX collector component. The exporter component 122 communicates information regarding flows from a location close to the 123 point of measurement in the network to the collector via SCTP, TCP, 124 or UDP. The collector may then e.g., store this data into a database 125 or transfer it directly to an application for further processing. 127 An implementation of these IPFIX components in software, firmware, or 128 hardware needs to be tested thoroughly in order to check its 129 robustness and the conformity to the IPFIX drafts it is based on. 130 This document suggests tests which should be run in order to check 131 the system and to gain a high confidence in the conformity, 132 robustness, and correct behavior of such implementation. 134 1.1. Motivation 136 The main driving force for preparing this document is the observation 137 that protocols for data exchange often fail to work properly when 138 implementations from different companies or organizations are in use 139 together. In many cases this even holds true when tests had 140 previously been performed successfully using an exporting and 141 collecting process from a single implementer. The tests listed here 142 can form a valuable common basis for implementers involved in 143 interoperability testing when all of them use these tests to check 144 their own exporter and collector first. 146 1.2. Document Scope 148 This document lists tests intended to be performed between an 149 implementation of an IPFIX exporter and an IPFIX collector. For some 150 tests multiple instances of each of those components are involved. 151 The tests cover basic application connectivity, export of template 152 and data records, high load, and error condition situations. 154 1.3. Related Documents 156 This draft refers to the following draft documents: "Information 157 Model for IP Flow Information Export" [I-D.ietf-ipfix-info] and 158 "IPFIX Protocol Specification" [I-D.ietf-ipfix-protocol]. 160 2. Terminology 162 The terminology used in this document is fully aligned with the 163 terminology defined in [I-D.ietf-ipfix-architecture] and [I-D.ietf- 164 ipfix-protocol]. 166 In the remainder of this document IE means Information Element. 168 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 169 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 170 document are to be interpreted as described in [RFC2119]. 172 3. Test Specifications 174 The following tests SHOULD be performed using an IPFIX exporting 175 process on one host and an IPFIX collecting process on a different 176 host. The network configuration and software component setup SHOULD 177 be recorded. The test results SHOULD be recorded per test performed. 179 3.1. Exporter/Collector Connectivity Tests 181 This section lists the basic tests which must succeed as a 182 precondition for the more complex tests in later sections. 184 3.1.1. Connectivity Tests between Exporter and Collector 186 Setup one exporting and one collecting process. Configure the 187 exporting process to send to the collecting process. Configure a 188 minimal data set so that the exporter will initiate a connection. 189 Detect whether a connection was established (in case of SCTP and TCP) 190 and whether data was exchanged. The transmitted data might be 191 observed on-line with an appropriate tool such as Ethereal 192 (www.ethereal.com). 194 Perform the test for all the supported combinations of IPv4 and IPv6 195 and UDP, SCTP, and TCP as transmission protocol. 197 3.2. Data Template and Data Transmission Tests 199 This section lists the important tests for checking the correct 200 transmission of IPFIX templates and data sets. 202 3.2.1. Transmission of Simple Data Template and Data 204 Create and export an IPFIX data template and data record for a few 205 fixed-size IEs over the transports in Section 3.1. Verify the 206 correct reception and decoding of the template and data. Use various 207 IEs so that each data type (octet, unsigned16, unsigned32 ...) is 208 used in at least one test. 210 3.2.2. Transmission of Data Template with variable-length IEs and Data 212 Create and export data templates and data records for a mixture of 213 fixed-sized and variable-length IEs over the transports in 214 Section 3.1. The various templates should contain: 216 o a single variable-length IE 218 o a single variable length IE followed by a fixed length IE 219 o a fixed length IE followed by a variable length IE 221 o multiple variable-length IEs 223 Verify the correct reception and decoding of all templates and data. 225 3.2.3. Flowsets with Padding 227 Create and send data records which contain padding (i.e. which use 228 the PaddingOctets IE). Test with legal and illegal padding sizes 229 (i.e. padding to boundaries other than 4 or 8 octets). Make sure the 230 implementation captures the (illegal) case where the data records are 231 so short that the padding is equal to or longer than the length of 232 the record, so the padding might otherwise be interpreted as another 233 record (e.g. 1 bytes TOS plus 3 bytes of padding). Test fixed-size 234 padding (e.g. 12 bytes of data plus 2 bytes of padding) and variable- 235 length padding (e.g. export a string and a variable number of padding 236 bytes afterwards to align the next data element to a 4 byte 237 boundary). 239 3.3. IE Tests 241 This section lists the tests which cover the use of IEs and the 242 correct transfer of IPFIX Options Templates. 244 3.3.1. Enterprise-specific IEs 246 Export a template and data set which makes use of Enterprise-specific 247 IEs as defined in [I-D.ietf-ipfix-info] and check correct reception 248 and decoding. Verify correct reception of IEs which are unknown to 249 the collector. Ensure that such IEs are not silently discarded. 251 3.3.2. Reduced-size Encoding of IEs 253 Generate export and test reception of IEs which have been transmitted 254 using a reduced-size encoding as defined in section 6.2 of [I-D.ietf- 255 ipfix-protocol]. Make sure that the collector is aware of the real 256 size of each IE and not only the length used for its transmission. 258 3.3.3. Multiple use of the same IE in one Template 260 Create and export a data template containing multiple instances of 261 the same IE, either consecutively or with other IEs in between. 262 Verify that the collector is able to parse the message contents and 263 stores all values received for all the IEs which appeared multiple 264 times in the template definition. 266 3.4. Options Templates 268 This section lists the tests which cover the use of IEs and the 269 correct transfer of IPFIX Options Templates. 271 3.4.1. Using any IEs as Scope 273 Options Templates contain a scope field which gives the context of 274 the reported IEs in the corresponding Data Records. The scope is an 275 IE specified in [I-D.ietf-ipfix-info]. 277 Export Options Template Records containing various different IEs in 278 their scope fields, and export a data record using each template. 279 Verify the correct reception of the templates and data records at the 280 collector. Verify whether the collector accepts an unknown IE in the 281 scope field. Verify whether the collector accepts an Enterprise 282 specific IE in the scope field. 284 The Scope Field Count MAY NOT be zero. Verify that the collector 285 does not accept an Options Template with no scope fields. 287 3.4.2. Using multiple Scopes 289 Multiple scope fields MAY be present in the Options Template Record. 290 If the order of the scope fields is relevant, the order of the scope 291 fields MUST be used. 293 Export an Options Template Record containing multiple scope fields, 294 and a data record using that template. Verify the correct reception 295 of the template and data record at the collector. 297 Note that the Scope Field Count MAY NOT be zero. Verify that the 298 collector does not accept an Options Template with no scope fields. 300 3.4.3. Metering Process (MP) Statistics Option Template 302 Check that the IPFIX collector can handle the reception and decoding 303 of options template records in general and that it is able to receive 304 and decode MP statistic option data records as defined in section 4.1 305 of [I-D.ietf-ipfix-protocol]. Note that not all fields listed there 306 might be present in a received MP statistic option data record. Also 307 check that the optional additional Scope Field is supported by the 308 implementation. 310 3.4.4. Metering Process (MP) Reliability Statistics Option Template 312 Check that the IPFIX collector can handle the reception and decoding 313 of MP reliability option data records as defined in section 4.2 of 315 [I-D.ietf-ipfix-protocol]. Note that not all fields listed there 316 might be present in a received MP reliability option data record. 317 Also check that the optional additional Scope Field is supported by 318 the implementation. 320 3.4.5. Exporting Process (EP) Reliability Statistics Option Template 322 Check that the IPFIX collector can handle the reception and decoding 323 of EP reliability option data records as defined in section 4.3 of 324 [I-D.ietf-ipfix-protocol]. Note that not all fields listed there 325 might be present in a received EP reliability option data record. 327 3.4.6. Flow Keys Option Template 329 Check that the IPFIX collector can handle the reception and decoding 330 of flow key option template data records as defined in section 4.4 of 331 [I-D.ietf-ipfix-protocol]. Note that not all fields listed there 332 might be present in a received EP reliability option data record. 333 Make sure that the implementation also properly handles the case 334 where the transmitted templateId incorrectly refers to a non-existing 335 template. 337 3.4.7. Template Withdrawal Message 339 Send a template withdrawal message for (a) a template which had been 340 sent before, (b) for a template which has never been sent, and (c) 341 for a template which was previously sent and already withdrawn. 342 Check correct behavior of the collector when receiving data records 343 before and after the template withdrawal. IPFIX template management 344 is defined in chapter 8 of [I-D.ietf-ipfix-protocol]. 346 3.5. Stress/Load Tests 348 Stress tests are used to check correct behavior and robustness of an 349 IPFIX collector implementation when a number of data records arrive 350 very quickly. This is especially important when IPFIX over UDP is 351 used, since in that case a slow collector must not block the IPFIX 352 exporter(s) from sending, since UDP is not congestion aware. Such 353 stress tests may not be applicable to the devices being tested. The 354 tests may be dependant upon the hardware and transports technology in 355 use. Therefore the tests may need to be scaled up or down to meet 356 the needs of the particular implementation. However, the implementer 357 SHOULD verify that his implementation is stable under excessive 358 traffic conditions, for whatever definition of "excessive" applies at 359 their intended installation. 361 The implementer MUST verify the correct operation of his exporter 362 and/or collector when the collector is incapable of processing 363 records at the rate which they are received. 365 3.5.1. Large Number of Records for one Template 367 Export many records to the collecting process. Depending on what 368 that process does (save to file, store to database, analyze the data) 369 the collector may use up a lot of memory. Verify that if it runs out 370 of memory, it terminates the connection gracefully but remains 371 available to receive data exported on other connections. 373 3.5.2. High Rate of incoming Data Records 375 If possible, export to the collector with an increasing records per 376 second export rate. For TCP or SCTP export this should stall the 377 exporter once the collector becomes fully loaded. For UDP export, 378 the collector should drop records gracefully as it becomes 379 overloaded. 381 3.5.3. Large Templates with high Number of IEs 383 Create and export templates with the maximum possible number of IEs. 384 Create and export matching data records. Note that, for the 385 implementation, these data records might be smaller or larger than 386 the template records depending on the type of IEs inside and the 387 presence of variable-length IEs. 389 3.5.4. Many new Templates within Data Template timeout interval 391 Create and export a large number of data templates using different 392 template IDs, to stress test the collector's memory consumption. 393 Ensure that the collector gracefully discards data templates (i.e. 394 logs warnings) if it's running in a system with insufficient memory 395 resources. 397 3.5.5. Multiple Exporters sending to one Collector 399 Setup multiple exporting processes to export data templates and data 400 to the same collecting process at the same time. Observe correct 401 reception and decoding of all the information at the collector. 402 Check that no exporter stalls or disconnects completely. 404 3.5.6. Export from one Exporter to multiple Collectors 406 If possible, configure the exporter to export data records in 407 parallel to different IPFIX collectors. Use simple and complex 408 templates and/or a mixture of them and check for correct reception. 410 3.6. Error Handling 412 This section lists and describes a number of problems which might 413 occur in either the network or data transmission or related to wrong 414 information encoding, and which the IPFIX system must be capable of 415 handling in a graceful way. It is intended to test the robustness 416 and fault tolerance of the IPFIX system. 418 3.6.1. Temporary Network Disconnect 420 Due to network failures (either physical or logical, e.g. defective 421 routing) the connectivity between an IPFIX exporter and collector 422 might be disrupted. The IPFIX system MUST be able to handle such 423 events in a deterministic and graceful way if they should occur 424 during an IPFIX export. When connection oriented transmission 425 protocols (TCP/SCTP) are in use, such a failure may or may not be 426 signaled to the exporter and collector by the operating system 427 depending on the type of network adapter, driver software and 428 operating system in use. The effect might be the direct signaling of 429 an error when IP packet read/write system functions are invoked 430 (signaling connection reset by peer) or there might be an OS- 431 dependant connection timeout. An implementer should check the 432 behavior of his/her IPFIX system upon such interruptions of data 433 transmission. For TCP- and SCTP-based connections, short disconnects 434 and long disconnects should be tested. For UDP-based data export 435 there is no noticeable connection loss, but data received with non- 436 consecutive sequence numbers indicates data loss and should be 437 recognized and reported by the collector per section 3.1 of 438 [I-D.ietf-ipfix-protocol]. 440 3.6.2. Exporter Termination and Restart during Data Transmission 442 An IPFIX collecting process might be confronted with a faulty 443 exporter implementation which suddenly crashes, dropping any open 444 connections. The exporter may be restarted again soon after the 445 crash. Kill a running and exporting exporter process. Check that 446 the associated collector gracefully closes all connections associated 447 to that exporter. Start the exporting process again. The collector 448 must be able to correctly receive from the new exporter instance at 449 the same source host. 451 3.6.3. Collector Termination and Restart during Data Transmission 453 An IPFIX exporting process might be confronted with a faulty 454 collector implementation which suddenly crashes, dropping any open 455 connections. That collector may be restarted again soon after the 456 crash. Kill a running collector while collecting. Check that the 457 exporter gracefully closes all connections associated with that 458 collector. Restart the collector. Check that the exporter is able 459 to export correctly to the new collector instance. 461 3.6.4. Incorrect Template Records 463 IPFIX Options Templates contain an overall Field Count and a Scope 464 Field Count. The Field Count is the number of all fields in the 465 Option Template Record, including the Scope Fields. The Scope Field 466 Count MAY NOT be zero. 468 Verify the collector's operation when it receives an options template 469 where the Field Count is less than the Scope Field Count. 471 Verify the collector's operation when it receives an options template 472 where the Scope Field Count is zero. 474 3.6.5. Export of defective IPFIX Data record 476 Check that the collector successfully drops all those data records 477 which are not correct IPFIX messages. Potential errors include but 478 are not limited to: 480 o IPFIX message too short 482 o illegal use of reduced size encoding 484 o invalid length specification in case of variable length IEs 486 3.6.6. Export of non-matching Template and Data 488 Check that the collector successfully drops all those data records 489 which do not match with their corresponding template. Potential 490 errors include but are not limited to: 492 o too few IEs in data record 494 o too many IEs in data record 496 3.6.7. Incorrect Set IDs 498 Check that Template Sets, Options Template Sets, and Data Sets with 499 an incorrect Set ID are discarded by the IPFIX collector. As of 500 [I-D.ietf-ipfix-protocol] version 19 only the Set ID values 2 and 3 501 denote valid sets. 503 3.6.8. Flowsets with Invalid Padding 505 Check that the IPFIX collector gracefully handles flowsets which have 506 invalid padding, i.e. when the number of padding bytes is incorrect, 507 or when the padding is not composed of NUL character(s). The 508 collector MAY accept the data records only for the latter case. 510 3.6.9. Re-using the same Template ID inside the Template Expiry Time 512 Check how the collector handles the case where a template definition 513 is received via UDP export with a template ID which is still in use, 514 i.e. not yet timed out. If the template is the same as the previous 515 this is a valid behavior. Sending a different template with the same 516 ID within the template expiry time however is not allowed and should 517 be reported by the collector. 519 3.6.10. Re-using the same Template ID after the Template Expiry Time 521 Check that the collector successfully handles the case where a 522 template definition is received via UDP with a template ID that was 523 in use but has expired. 525 Also check and ensure that the collector drops data records which 526 refer to a template after its expiry (or withdrawal in the case of 527 SCTP). 529 3.6.11. Re-sending an existing template ID without withdrawal 531 [I-D.ietf-ipfix-protocol] states in section 8 that a template MUST 532 NOT be sent more than once during the lifetime of an SCTP 533 association. Create and export a template multiple times using SCTP 534 based data transmission. Ensure that the collector gracefully 535 discards any but the first template record. The collector should log 536 a warning about such error observed from an exporter, and MUST shut 537 down the SCTP association (if any). 539 4. Security Considerations 541 This memo raises no security issues. 543 5. References 545 [I-D.ietf-ipfix-architecture] 546 Sadasivan, G., "Architecture for IP Flow Information 547 Export", draft-ietf-ipfix-architecture-09 (work in 548 progress), August 2005. 550 [I-D.ietf-ipfix-info] 551 Quittek, J., "Information Model for IP Flow Information 552 Export", draft-ietf-ipfix-info-11 (work in progress), 553 September 2005. 555 [I-D.ietf-ipfix-protocol] 556 Claise, B., "IPFIX Protocol Specification", 557 draft-ietf-ipfix-protocol-19 (work in progress), 558 September 2005. 560 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 561 Requirement Levels", BCP 14, RFC 2119, March 1997. 563 Authors' Addresses 565 Carsten Schmoll 566 Fraunhofer Institute Fokus 567 Kaiserin-Augusta-Allee 31 568 Berlin D-10589 569 Germany 571 Phone: +49 30 3463 7136 572 Email: schmoll@fokus.fraunhofer.de 573 URI: http://www.fokus.fraunhofer.de 575 Paul Aitken 576 Cisco Systems 577 96 Commercial Quay 578 Edinburgh EH6 6LX 579 Scotland 581 Phone: +44 131 561 3616 582 Email: paitken@cisco.com 583 URI: http://www.cisco.com 585 Intellectual Property Statement 587 The IETF takes no position regarding the validity or scope of any 588 Intellectual Property Rights or other rights that might be claimed to 589 pertain to the implementation or use of the technology described in 590 this document or the extent to which any license under such rights 591 might or might not be available; nor does it represent that it has 592 made any independent effort to identify any such rights. Information 593 on the procedures with respect to rights in RFC documents can be 594 found in BCP 78 and BCP 79. 596 Copies of IPR disclosures made to the IETF Secretariat and any 597 assurances of licenses to be made available, or the result of an 598 attempt made to obtain a general license or permission for the use of 599 such proprietary rights by implementers or users of this 600 specification can be obtained from the IETF on-line IPR repository at 601 http://www.ietf.org/ipr. 603 The IETF invites any interested party to bring to its attention any 604 copyrights, patents or patent applications, or other proprietary 605 rights that may cover technology that may be required to implement 606 this standard. Please address the information to the IETF at 607 ietf-ipr@ietf.org. 609 Disclaimer of Validity 611 This document and the information contained herein are provided on an 612 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 613 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 614 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 615 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 616 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 617 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 619 Copyright Statement 621 Copyright (C) The Internet Society (2006). This document is subject 622 to the rights, licenses and restrictions contained in BCP 78, and 623 except as set forth therein, the authors retain all their rights. 625 Acknowledgment 627 Funding for the RFC Editor function is currently provided by the 628 Internet Society.