idnits 2.17.1 draft-ietf-ipfix-biflow-05.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 987. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 998. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1005. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1011. 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 : ---------------------------------------------------------------------------- ** There are 11 instances of too long lines in the document, the longest one being 6 characters in excess of 72. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? 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 (June 21, 2007) is 6147 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 (-26) exists of draft-ietf-ipfix-protocol-24 == Outdated reference: A later version (-12) exists of draft-ietf-ipfix-as-11 == Outdated reference: A later version (-08) exists of draft-ietf-ipfix-implementation-guidelines-05 Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 8 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 Intended status: Standards Track E. Boschi 5 Expires: December 23, 2007 Hitachi Europe 6 June 21, 2007 8 Bidirectional Flow Export using IPFIX 9 draft-ietf-ipfix-biflow-05.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 December 23, 2007. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 40 Abstract 42 This document describes an efficient method for exporting 43 bidirectional flow (Biflow) information using the IP Flow Information 44 Export (IPFIX) protocol, representing each Biflow using a single Flow 45 Record. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 1.1. IPFIX Documents Overview . . . . . . . . . . . . . . . . . 3 51 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 52 3. Rationale and History . . . . . . . . . . . . . . . . . . . . 5 53 4. Biflow Semantics . . . . . . . . . . . . . . . . . . . . . . . 6 54 5. Direction Assignment . . . . . . . . . . . . . . . . . . . . . 8 55 5.1. Direction by Initiator . . . . . . . . . . . . . . . . . . 9 56 5.2. Direction by Perimeter . . . . . . . . . . . . . . . . . . 10 57 5.3. Arbitrary Direction . . . . . . . . . . . . . . . . . . . 10 58 6. Record Representation . . . . . . . . . . . . . . . . . . . . 11 59 6.1. Reverse Information Element Private Enterprise Number . . 11 60 6.2. Enterprise-Specific Reverse Information Elements . . . . . 13 61 6.3. biflowDirection Information Element . . . . . . . . . . . 13 62 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 63 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 64 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 65 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 66 10.1. Normative References . . . . . . . . . . . . . . . . . . . 15 67 10.2. Informative References . . . . . . . . . . . . . . . . . . 16 68 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 16 69 Appendix B. XML Specification of biflowDirection Information 70 Element . . . . . . . . . . . . . . . . . . . . . . . 20 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 72 Intellectual Property and Copyright Statements . . . . . . . . . . 23 74 1. Introduction 76 Many flow analysis tasks benefit from association of the upstream and 77 downstream flows of a bidirectional communication, e.g., separating 78 answered and unanswered TCP requests, calculating round trip times, 79 etc. Metering processes that are not part of an asymmetric routing 80 infrastructure, especially those deployed at a single point through 81 which bidirectional traffic flows, are well positioned to observe 82 bidirectional flows (Biflows). In such topologies, the total 83 resource requirements for Biflow assembly are often lower if the 84 Biflows are assembled at the measurement interface as opposed to the 85 collector. The IPFIX Protocol requires only information model 86 extensions to be complete as a solution for exporting Biflow data. 88 To that end, we propose a Biflow export method using a single Flow 89 Record per Biflow in this document. We explore the semantics of 90 bidirectional flow data in section 4, "Biflow Semantics"; examine the 91 various possibilities for determining the direction of Biflows in the 92 section 5, "Direction Assignment"; then define the Biflow export 93 method in section 6, "Record Representation". 95 This export method requires additional Information Elements to 96 represent data values for the reverse direction of each Biflow, and a 97 single additional Information Element to represent direction 98 assignment information, as described in sections 6.1 through 6.3. 99 The selection of this method was motivated by an exploration of other 100 possible methods of Biflow export using IPFIX; however, these methods 101 have important drawbacks, as discussed in section 3, "Rationale and 102 History". 104 1.1. IPFIX Documents Overview 106 "Specification of the IPFIX Protocol for the Exchange of IP Traffic 107 Flow Information" [I-D.ietf-ipfix-protocol] (informally, the IPFIX 108 Protocol document) and its associated documents define the IPFIX 109 Protocol, which provides network engineers and administrators with 110 access to IP traffic flow information. 112 "Architecture for IP Flow Information Export" 113 [I-D.ietf-ipfix-architecture] (the IPFIX Architecture document) 114 defines the architecture for the export of measured IP flow 115 information out of an IPFIX Exporting Process to an IPFIX Collecting 116 Process, and the basic terminology used to describe the elements of 117 this architecture, per the requirements defined in "Requirements for 118 IP Flow Information Export" [RFC3917]. The IPFIX Protocol document 119 then covers the details of the method for transporting IPFIX data 120 records and templates via a congestion-aware transport protocol from 121 an IPFIX Exporting Process to an IPFIX Collecting Process. 123 "Information Model for IP Flow Information Export" 124 [I-D.ietf-ipfix-info] (informally, the IPFIX Information Model 125 document) describes the Information Elements used by IPFIX, including 126 details on Information Element naming, numbering, and data type 127 encoding. Finally, "IPFIX Applicability" [I-D.ietf-ipfix-as] 128 describes the various applications of the IPFIX protocol and their 129 use of information exported via IPFIX, and relates the IPFIX 130 architecture to other measurement architectures and frameworks. 132 This document references the Protocol and Architecture documents for 133 terminology, uses the IPFIX Protocol to define an bidirectional flow 134 export method, and proposes additions to the information model 135 defined in the IPFIX Information Model document. 137 2. Terminology 139 Capitalized terms used in this document that are defined in the 140 Terminology section of the IPFIX Protocol document 141 [I-D.ietf-ipfix-protocol] are to be interpreted as defined there. 142 The following additional terms are defined in terms of the protocol 143 document terminology. 145 Directional Key Field: A Directional Key Field is a single field in 146 a Flow Key as defined in the IPFIX Protocol document 147 [I-D.ietf-ipfix-protocol] that is specifically associated with a 148 single endpoint of the Flow. sourceIPv4Address and 149 destinationTransportPort are example common directional key 150 fields. 152 Non-directional Key Field: A Non-directional Key Field is a single 153 field within a Flow Key as defined in the IPFIX Protocol document 154 [I-D.ietf-ipfix-protocol] that is not specifically associated with 155 either endpoint of the Flow. protocolIdentifier is an example 156 common non-directional key field. 158 Uniflow (Unidirectional Flow): A Uniflow is a Flow as defined in 159 the IPFIX Protocol document [I-D.ietf-ipfix-protocol], restricted 160 such that the Flow is composed only of packets sent from a single 161 endpoint to another single endpoint. 163 Biflow (Bidirectional Flow): A Biflow is a Flow as defined in the 164 IPFIX Protocol document [I-D.ietf-ipfix-protocol], composed of 165 packets sent in both directions between two endpoints. A Biflow 166 is composed from two Uniflows such that: 168 1. the value of each Non-directional Key Field of each Uniflow is 169 identical to its counterpart in the other, and 171 2. the value of each Directional Key Field of each Uniflow is 172 identical to its reverse direction counterpart in the other 174 A Biflow contains two Non-Key Fields for each value it represents 175 associated with a single direction or endpoint: one for the 176 forward direction and one for the reverse direction, as defined 177 below. 179 Biflow Source: The source of a Biflow is the endpoint identified by 180 the source Directional Key Fields in the Biflow. 182 Biflow Destination: The destination of a Biflow is the endpoint 183 identified by the destination Directional Key Fields in the 184 Biflow. 186 Forward direction (of a Biflow): The direction of a Biflow composed 187 of packets sent by the Biflow Source. Values associated with the 188 forward direction of a Biflow are represented using normal 189 Information Elements. In other words, a Uniflow may be defined as 190 a Biflow having only a forward direction. 192 Reverse direction (of a Biflow): The direction of a Biflow composed 193 of packets sent by the Biflow Destination. Values associated with 194 the reverse direction of a Biflow are represented using reverse 195 Information Elements, as defined below. 197 Reverse Information Element: An Information Element defined as 198 corresponding to a normal Information Element, but associated with 199 the reverse direction of a Biflow. 201 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 202 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 203 document are to be interpreted as described in RFC 2119 [RFC2119]. 205 3. Rationale and History 207 In selecting the Single Record Biflow export method described in this 208 document as the recommendation for bidirectional flow export using 209 IPFIX, we considered several other possible methods. 211 The first and most obvious would be simply to export Biflows as two 212 uniflows adjacent in the record stream; a Collecting Process could 213 then reassemble them with minimal state requirements. However, this 214 has the drawbacks that it is merely an informal arrangement the 215 Collecting Process cannot rely upon, and that it is not bandwidth- 216 efficient, duplicating the export of Flow Key data in each Uniflow 217 record. 219 We then considered the method outlined in Reducing Redundancy in 220 IPFIX and PSAMP Reports [I-D.ietf-ipfix-reducing-redundancy] for 221 reducing this bandwidth inefficiency. This would also formally link 222 the two Uniflows into a single construct, by exporting the Flow Key 223 as Common Properties then exporting each direction's information as 224 Specific Properties. However, it would do so at the expense of 225 additional overhead to transmit the commonPropertiesId, and 226 additional state management requirements at both the Collecting and 227 Exporting Process. 229 A proposal was made on the IPFIX mailing list to use the Multiple 230 Information Element feature of the protocol to export forward and 231 reverse counters using identical Information Element in the same Flow 232 Record. In this approach, the first instance of a counter would 233 represent the forward direction, and the second instance of the same 234 counter would represent the reverse. This had the disadvantage of 235 conflicting with the presently defined semantics for these counters, 236 and, as such, was abandoned. 238 4. Biflow Semantics 240 As stated in the Terminology section above, a Biflow is simply a Flow 241 representing packets flowing in both directions between two endpoints 242 on a network. There are compelling reasons to treat Biflows as 243 single entities (as opposed to merely ad-hoc combinations of 244 Uniflows) within IPFIX. First, as most application-layer network 245 protocols are inherently bidirectional, a Biflow-based data model 246 more accurately represents the behavior of the network, and enables 247 easier application of flow data to answering interesting questions 248 about network behavior. Second, exporting Biflow data can result in 249 improved export efficiency by eliminating the duplication of Flow Key 250 data in an IPFIX message stream, and improve collection efficiency by 251 removing the burden of Biflow matching from the Collecting Process 252 where possible. 254 Biflows are somewhat more semantically complicated than Uniflows. 255 First, when handling Uniflows, the semantics of "source" and 256 "destination" Information Elements are clearly defined by the 257 semantics of the underlying packet header data: the source 258 Information Elements represent the source header fields, and the 259 destination Information Elements represent the destination header 260 fields. When representing Biflows with single IPFIX Data Records, 261 the definitions of source and destination must be chosen more 262 carefully. 264 As in the Terminology section above, we define the Source of a Biflow 265 to be that identified by the source Directional Key Field(s), and the 266 Destination of the Biflow to be that identified by the destination 267 Directional Key Field(s). Note that, for IANA-registered Information 268 Elements or those defined by the IPFIX Information Model 269 [I-D.ietf-ipfix-info], Directional Key Fields associated with the 270 Biflow Source are represented by Information Elements whose names 271 begin with "source", and Directional Key Fields associated with the 272 Biflow Destination are represented by Information Elements whose 273 names begin with "destination"; it is recommended that vendor- 274 specific information elements follow these conventions, as well. 276 Methods for assignment of Source and Destination by the Metering and 277 Exporting Processes are described in the following section. 279 As the Source and Destination of a Biflow are defined in terms of its 280 Directional Keys, Biflow values are also split info "forward" and 281 "reverse" directions. As in the Terminology section above, the 282 Forward direction of a Biflow is composed of packets sent by the 283 Biflow Source, and the Reverse direction of a Biflow is composed of 284 packets sent by the Destination. In other words, the two directions 285 of a Biflow may be roughly thought of as the two Uniflows that were 286 matched to compose the Biflow. A Biflow record, then, contains each 287 Flow Key record once, and both forward and reverse direction 288 information elements for each non-key field. See Figure 1 for an 289 illustration of the composition of Biflows from Uniflows. 291 Uniflow Uniflow 292 +-------+-------+-----------------+ +-------+-------+-----------------+ 293 | src A | dst B | counters/values | | src B | dst A | counters/values | 294 +-------+-------+-----------------+ +-------+-------+-----------------+ 295 | | | | 296 V V V V 297 +-------+-------+---------------------+---------------------+ 298 | src A | dst B | fwd counters/values | rev counters/values | 299 +-------+-------+---------------------+---------------------+ 300 Biflow 302 Figure 1: Bidirectional Flow Conceptual Diagram 304 The Reverse direction values are represented by Reverse Information 305 Elements. The representation of these Reverse Information Elements 306 within Templates is detailed in section 5. A Flow Record may be 307 considered to be a Biflow Record by the Collecting Process if it 308 contains at least one Reverse Information Element AND at least one 309 Directional Key Field. Flow Records containing Reverse Information 310 Elements but no Directional Key Fields are illegal, MUST NOT be sent 311 by the Exporting Process, and SHOULD be dropped by the Collecting 312 Process. The Collecting Process SHOULD log the receipt of illegal 313 Biflow Flow Records. 315 When exporting Uniflows, Exporting Processes SHOULD use a Template 316 containing no Reverse Information Elements. Note that a Template 317 whose only Reverse Information Elements are counters MAY be used to 318 export Uniflows, as counters with values of 0 are semantically 319 equivalent to no reverse direction. However, this approach is not 320 possible for reverse Information Elements whose zero values have a 321 distinct meaning (e.g., tcpControlBits). 323 Note that a Biflow traversing a middlebox [RFC3234] may show 324 different Flow properties on each side of the middlebox due to 325 changes to the packet header or payload performed by the middlebox 326 itself. Therefore it MUST be clear at a Collecting Process whether 327 packets were observed and metered before or after modification. The 328 Observation Process SHOULD be located on one side of a middlebox and 329 the Exporting Process SHOULD communicate to the Collecting Process 330 both the incoming value of the Flow property changed within the 331 middlebox and the changed value on the "other side". The IPFIX 332 Information Model [I-D.ietf-ipfix-info] provides Information Elements 333 with prefix "post" for this purpose. The location of the Observation 334 Point(s) with respect to the middlebox can be communicated using 335 Options with Observation Point as Scope and elements such as 336 lineCardID or samplerID. 338 For further information on the effect of middleboxes within the IPFIX 339 architecture, refer to section 7 of the IPFIX Implementation 340 Guidelines [I-D.ietf-ipfix-implementation-guidelines]. 342 By the definition of Observation Domain in section 2 of the IPFIX 343 Protocol document [I-D.ietf-ipfix-protocol], Biflows may be composed 344 only of packets observed within the same Observation Domain. This 345 implies that Metering Processes that build Biflows out of Uniflows 346 must ensure that the two Uniflows were observed within the same 347 Observation Domain. 349 5. Direction Assignment 351 Due to the variety of flow measurement applications and restrictions 352 on Metering Process deployment, one single method of assigning the 353 directions of a Biflow will not apply in all cases. This section 354 describes three methods of direction assignment, and recommend them 355 based upon Metering Process position and measurement application 356 requirements. In each of the figures in this section, the "MP" box 357 represents the Metering Process. 359 As the method selection is dependent on Metering Process position, it 360 is sufficient to configure the direction assignment method at the 361 Collecting and/or the Exporting Process out-of-band. For example, a 362 Collecting Process might be configured that a specific Exporting 363 Process identified by exporterIPv4Address is assigning direction by 364 initiator; or both an Collecting Process and an Exporting Process 365 could be simultaneously configured with a specific direction 366 assignment perimeter. However, for Exporting Processes that use 367 multiple direction selection methods, or for Collecting Processes 368 accepting data from Exporting Processes using a variety of methods, a 369 biflowDirection Information Element is provided for optional 370 representation of direction assignment information. 372 5.1. Direction by Initiator 374 If the measurement application requires the determination of the 375 initiator and responder of a given communication, the Metering 376 Process SHOULD define the Biflow Source to be the initiator of the 377 Biflow, where possible. This can be roughly approximated by a 378 Metering Process observing packets in both directions simply assuming 379 the first packet seen in a given Biflow is the packet initiating the 380 Biflow. A Metering Process may improve upon this method by using 381 knowledge of the transport or application protocols (e.g., TCP flags, 382 DNS question/answer counts) to better approximate the flow-initiating 383 packet. 385 Note that direction assignment by initiator is most easily done by a 386 single Metering Process positioned on a local link layer, as in 387 Figure 2, or a single Metering Process observing bidirectional packet 388 flows at a symmetric perimeter routing point, as in Figure 3. 390 Note also that many Metering Processes have an "active" timeout, such 391 that any Flow with a duration longer than the active timeout is 392 expired and any further packets belonging to that Flow are accounted 393 for as part of a new Flow. This mechanism may cause issues with the 394 assumption that a first packet seen is from the flow initiator, if 395 the "first" packet is a middle packet in a long-duration Flow. 397 +-------+ +-------+ 398 | node | | node | 399 +---+---+ +---+---+ 400 | | +---------+ 401 <===+=====+=====+======>+ +<===> Internet 402 | | router | 403 +---+---+ +---------+ 404 | MP | 405 +---+---+ 407 Figure 2: Local Link Metering Process Position 409 +-------+ +-------+ 410 | node | | node | 411 +---+---+ +---+---+ 412 | | +---------+ 413 <===+===========+======>+ +<===> Internet 414 | router | 415 | +----+--+ 416 +----+ MP | 417 +-------+ 419 Figure 3: Symmetric Routing Point Metering Process Position 421 5.2. Direction by Perimeter 423 If the measurement application is deployed at a network perimeter, as 424 illustrated in Figure 4, such that there is a stable set of addresses 425 that can be defined as "inside" that perimeter, and there is no 426 measurement application requirement to determine the initiator and 427 responder of a given communication, then the Metering Process SHOULD 428 assign the Biflow Source to be the endpoint outside the perimeter. 430 No facility is provided for exporting the address set defining the 431 interior of a perimeter; this set may be deduced by the Collecting 432 Process observing the set of Biflow source or destination addresses, 433 or configured out-of-band. 435 +---------+ +---------+ 436 ====>+ access +====> ====>+ access +====> 437 Internet | router | Local Net | router | Internet 438 (link A) <====+ A +<==== <====+ B +<==== (link B) 439 +----+----+ +---------+ 440 | 441 +---+---+ 442 | MP | 443 +-------+ 445 Figure 4: Perimeter Metering Process Position 447 5.3. Arbitrary Direction 449 If the measurement application is deployed in a network core, such 450 that there is no stable set of addresses defining a perimeter (e.g., 451 due to BGP updates), as in Figure 5, and no requirement or ability to 452 determine the initiator or responder of a given communication, then 453 the Metering Process MAY assign the Biflow Source and Biflow 454 Destination endpoints arbitrarily. 456 In this case, the Metering Process SHOULD be consistent in its choice 457 of direction. Once assigned, direction SHOULD be maintained for the 458 lifetime of the Biflow, even in the case of active timeout of a long- 459 lived Biflow. 461 | 462 V 463 +----+----+ +---------+ 464 <===+ core | | core +===> 465 | router +<========>+ router | 466 ===>+ | | +<=== 467 +----+----+ +----+----+ 468 | | 469 +---+---+ V 470 | MP | 471 +-------+ 473 Figure 5: Transit/Core Metering Process Position 475 6. Record Representation 477 As noted above, Biflows are exported using a single Flow Record, each 478 of which contains the Flow Key fields once, and both forward and 479 reverse direction information elements for each non-key field. The 480 IPFIX Information Model is extended to provide a "reverse" 481 Information Element counterpart to each presently defined "forward" 482 Information Element, as required by any Information Element that may 483 be a non-key field in a Biflow. 485 6.1. Reverse Information Element Private Enterprise Number 487 Reverse Information Elements are specified as a separate "dimension" 488 in the Information Element space, by having IANA assign a single 489 Private Enterprise Number (PEN) to this document, and to define that 490 PEN to signify "IPFIX Reverse Information Element" (the Reverse PEN). 491 This reverse PEN would serve as a "reverse direction flag" in the 492 template; each Information Element number within this PEN space would 493 be assigned to the reverse counterpart of the corresponding IANA- 494 assigned public Information Element number. In other words, to 495 generate a reverse information element in a template corresponding to 496 a given forward information element, simply set the enterprise bit 497 and define the Information Element within the Reverse PEN space, as 498 in Figure 6 below. 500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 501 |0| flowStartSeconds 150 | Field Length = 4 | 502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 504 forward | 505 | 506 reverse V 508 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 509 |1| (rev) flowStartSeconds 150 | Field Length = 4 | 510 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 511 | reverse PEN TBD1 | 512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 514 Figure 6: Example Mapping between Forward and Reverse IEs 516 As the Reverse Information Element dimension is treated explicitly as 517 such, new Information Elements can be added freely to the IANA- 518 managed space without concern for whether a reverse element should 519 also be added. Aside from the initial allocation of an enterprise 520 number for this purpose, there is no additional maintenance overhead 521 for supporting Reverse Information Elements in the IPFIX Information 522 Model. 524 Note that certain Information Elements in the IPFIX Information Model 525 [I-D.ietf-ipfix-info] are not reversible; that is, they are 526 semantically meaningless as reverse Information Elements. An 527 Exporting Process MUST NOT export a Template containing the reverse 528 counterpart of a non-reversible Information Element. A Collecting 529 Process receiving the reverse counterpart of a non-reversible 530 Information Element MAY discard that Information Element from the 531 Flow Record. Non-reversible Information Elements represent 532 properties of the Biflow record as a whole, or are intended for 533 internal the use of the IPFIX Protocol itself. Therefore, by 534 definition, they cannot be associated with a single direction or 535 endpoint of the Flow. 537 The following specific Information Elements are not reversible: 539 1. Identifiers defined in section 5.1 of the Information Model which 540 cannot be associated with a single direction of Uniflow 541 collection: flowId (5.1.7), templateId (5.1.8), 542 observationDomainId (5.1.9), and commonPropertiesId (5.1.11). 544 2. Process configuration elements defined in section 5.2 of the 545 Information Model. 547 3. Process statistics elements defined in section 5.3 of the 548 Information Model. 550 4. paddingOctets (5.12.1). 552 5. biflowDirection (defined in section 6.3 of this document). 554 Any future addition to the Information Element Registry by IANA which 555 meets the criteria defined above SHOULD also be considered to be non- 556 reversible by the Collecting Process. 558 Note that Information Elements commonly used as Flow Keys (e.g. 559 header fields defined in sections 5.4 and 5.5 of the Information 560 Model) are reversible, as they may be used as value fields in certain 561 contexts, as when associating ICMP error messages with the flows that 562 caused them. 564 6.2. Enterprise-Specific Reverse Information Elements 566 Note that the Reverse PEN defined above is only available for 567 allocating reverse counterparts of IANA-registered IPFIX Information 568 Elements. No facility is provided for allocating reverse 569 counterparts of enterprise-specific Information Elements. 571 The allocation of enterprise-specific Information Elements for IPFIX 572 is left to the discretion of the enterprise allocating them. Note 573 that, as enterprise-specific Information Elements are designed for 574 the internal use of private enterprises, the lack of any guidance or 575 standard on Information Element allocation policies poses no 576 interoperability issues. However, if a private enterprise's own 577 Information Element registry anticipates the allocation of reversible 578 Information Elements, and the use of this specification for the 579 export of Biflow data, that registry MAY reserve one of the fifteen 580 available bits in the Information Element ID to signify the reverse 581 direction. For example, if the most significant bit were selected, 582 this would reserve Information Element IDs 0x4000 to 0x7FFF for the 583 reverse direction of Information Element IDs 0x0000 to 0x3FFF. 585 6.3. biflowDirection Information Element 587 Description: A description of the direction assignment method used 588 to assign source and destination to this Biflow. This Information 589 Element MAY be present in a Flow Data Record, or applied to all 590 flows exported from an Exporting Process or Observation Domain 591 using IPFIX Options. If this Information Element is not present 592 in a Flow Record or associated with a Biflow via scope, it is 593 assumed that the configuration of the direction assignment method 594 is done out-of-band. Note that when using IPFIX Options to apply 595 this Information Element to all flows within an Observation Domain 596 or from an Exporting Process, the Option SHOULD be sent reliably. 597 If reliable transport is not available (i.e., when using UDP), 598 this Information Element SHOULD appear in each Flow Record. This 599 field may take the following values: 601 +-------+------------------+----------------------------------------+ 602 | Value | Name | Description | 603 +-------+------------------+----------------------------------------+ 604 | 0x00 | arbitrary | Direction was assigned arbitrarily. | 605 | 0x01 | initiator | The Biflow Source is the flow | 606 | | | initiator, as determined by the | 607 | | | Metering Process' best effort to | 608 | | | detect the initiator. | 609 | 0x02 | reverseInitiator | The Biflow Destination is the flow | 610 | | | initiator, as determined by the | 611 | | | Metering Process' best effort to | 612 | | | detect the initiator. This value is | 613 | | | provided for the convenience of | 614 | | | Exporting Processes to revise an | 615 | | | initiator estimate without re-encoding | 616 | | | the Biflow Record. | 617 | 0x03 | perimeter | The Biflow Source is the endpoint | 618 | | | outside of a defined perimeter. The | 619 | | | perimeter's definition is implicit in | 620 | | | the set of Biflow Source and Biflow | 621 | | | Destination addresses exported in the | 622 | | | Biflow Records. | 623 +-------+------------------+----------------------------------------+ 625 Abstract Data Type: octet 627 Data Type Semantics: identifier 629 ElementId: TBD2 631 Status: current 633 7. IANA Considerations 635 This document specifies the creation of a new dimension in the 636 information element space defined by the IPFIX Information Model 637 [I-D.ietf-ipfix-info]. This new dimension is defined by the 638 allocation of a new Private Enterprise Number (PEN). The Internet 639 Assigned Numbers Authority (IANA) has assigned private enterprise 640 number TBD1 to this document as the "IPFIX Reverse Information 641 Element Private Enterprise", with this document's authors as point of 642 contact. 644 [NOTE for IANA: The text TBD1 should be replaced with the assigned 645 private enterprise number where it appears in this document.] 647 This document specifies the creation of a new IPFIX Information 648 Element, biflowDirection, as defined in section 6.3. IANA has 649 assigned Information Element number TBD2 in the IPFIX Information 650 Element registry for the biflowDirection information element. The 651 values defined for this information element are static, and as such 652 do not need to be maintained by IANA in a subregistry. 654 [NOTE for IANA: The text TBD2 should be replaced with the assigned 655 biflowDirection Information Element number where it appears in this 656 document.] 658 8. Security Considerations 660 The same security considerations as for the IPFIX Protocol 661 [I-D.ietf-ipfix-protocol] apply. 663 9. Acknowledgments 665 We would like to thank Lutz Mark, Juergen Quittek, Andrew Johnson, 666 Paul Aitken, Benoit Claise, and Carsten Schmoll for their 667 contributions and comments. Special thanks to Michelle Cotton for 668 her assistance in navigating the IANA process for enterprise number 669 assignment, and for the IANA pre-review of the document. 671 10. References 673 10.1. Normative References 675 [I-D.ietf-ipfix-protocol] 676 Claise, B., "Specification of the IPFIX Protocol for the 677 Exchange", draft-ietf-ipfix-protocol-24 (work in 678 progress), November 2006. 680 [I-D.ietf-ipfix-info] 681 Quittek, J., "Information Model for IP Flow Information 682 Export", draft-ietf-ipfix-info-15 (work in progress), 683 February 2007. 685 10.2. Informative References 687 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 688 Requirement Levels", BCP 14, RFC 2119, March 1997. 690 [RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and 691 Issues", RFC 3234, February 2002. 693 [RFC3917] Quittek, J., Zseby, T., Claise, B., and S. Zander, 694 "Requirements for IP Flow Information Export (IPFIX)", 695 RFC 3917, October 2004. 697 [I-D.ietf-ipfix-architecture] 698 Sadasivan, G., "Architecture for IP Flow Information 699 Export", draft-ietf-ipfix-architecture-12 (work in 700 progress), September 2006. 702 [I-D.ietf-ipfix-as] 703 Zseby, T., "IPFIX Applicability", draft-ietf-ipfix-as-11 704 (work in progress), February 2007. 706 [I-D.ietf-ipfix-implementation-guidelines] 707 Boschi, E., "IPFIX Implementation Guidelines", 708 draft-ietf-ipfix-implementation-guidelines-05 (work in 709 progress), June 2007. 711 [I-D.ietf-ipfix-reducing-redundancy] 712 Boschi, E., "Reducing Redundancy in IP Flow Information 713 Export (IPFIX) and Packet Sampling (PSAMP) Reports", 714 draft-ietf-ipfix-reducing-redundancy-04 (work in 715 progress), May 2007. 717 Appendix A. Examples 719 The following example describes a Biflow record as specified in 720 section 6, above. The "IPFIX Reverse Information Element" PEN is 721 assigned for the purpose of differentiating forward from reverse 722 information elements. 724 The information exported in this case is: 726 o The start time of the flow: flowStartSeconds in the IPFIX 727 Information Model [I-D.ietf-ipfix-info], with a length of 4 octets 729 o The reverse start time of the flow: flowStartSeconds in the IPFIX 730 Information Model [I-D.ietf-ipfix-info], with a length of 4 731 octets, and the enterprise bit set to 1. The following PEN is the 732 Reverse PEN. 734 o The IPv4 source IP address: sourceIPv4Address in the IPFIX 735 Information Model [I-D.ietf-ipfix-info], with a length of 4 octets 737 o The IPv4 destination IP address:destinationIPv4Address in the 738 IPFIX Information Model [I-D.ietf-ipfix-info], with a length of 4 739 octets 741 o The source port: sourceTransportPort in the IPFIX Information 742 Model [I-D.ietf-ipfix-info], with a length of 2 octets 744 o The destination port: destinationTransportPort in the IPFIX 745 Information Model [I-D.ietf-ipfix-info], with a length of 2 octets 747 o The protocol identifier: protocolIdentifier in the IPFIX 748 Information Model [I-D.ietf-ipfix-info], with a length of 1 octet 750 o The number of octets of the Flow: octetTotalCount in the IPFIX 751 Information Model [I-D.ietf-ipfix-info], with a length of 4 octets 753 o The reverse number of octets of the Flow: octetTotalCount in the 754 IPFIX Information Model [I-D.ietf-ipfix-info], with a length of 4 755 octets, and the enterprise bit set to 1. The following PEN is the 756 Reverse PEN. 758 o The number of packets of the Flow: packetTotalCount in the IPFIX 759 Information Model [I-D.ietf-ipfix-info], with a length of 4 octets 761 o The reverse number of packets of the Flow: packetTotalCount in the 762 IPFIX Information Model [I-D.ietf-ipfix-info], with a length of 4 763 octets, and the enterprise bit set to 1. The following PEN is the 764 Reverse PEN. 766 and the resulting template would look like the diagram below: 768 1 2 3 769 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 770 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 771 | Set ID = 2 | Length = 64 | 772 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 773 | Template ID >= 256 | Field Count = 11 | 774 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 775 |0| flowStartSeconds 150 | Field Length = 4 | 776 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 777 |1| flowStartSeconds 150 | Field Length = 4 | 778 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 779 | reverse PEN TBD1 | 780 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 781 |0| sourceIPv4Address 8 | Field Length = 4 | 782 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 783 |0| destinationIPv4Address 12 | Field Length = 4 | 784 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 785 |0| sourceTransportPort 7 | Field Length = 2 | 786 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 787 |0| destinationTransportPort 11 | Field Length = 2 | 788 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 789 |0| protocolIdentifier 4 | Field Length = 1 | 790 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 791 |0| octetTotalCount 85 | Field Length = 4 | 792 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 793 |1| octetTotalCount 85 | Field Length = 4 | 794 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 795 | reverse PEN TBD1 | 796 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 797 |0| packetTotalCount 86 | Field Length = 4 | 798 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 799 |1| packetTotalCount 86 | Field Length = 4 | 800 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 801 | reverse PEN TBD1 | 802 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 804 Figure 7: Single Record Biflow Template Set 806 The following example data record represents a typical HTTP 807 transaction. Its format is defined by the example template, above. 809 1 2 3 810 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 811 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 812 | Set ID >= 256 | Length = 41 | 813 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 814 | 2006-02-01 17:00:00 | 815 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 816 | 2006-02-01 17:00:01 | 817 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 818 | 192.0.2.2 | 819 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 820 | 192.0.2.3 | 821 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 822 | 32770 | 80 | 823 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 824 | 6 | 18000 . . . 825 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 826 . . . | 128000 . . . 827 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 828 . . . | 65 . . . 829 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 830 . . . | 110 . . . 831 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 832 . . . | 833 +-+-+-+-+-+-+-+-+ 835 Figure 8: Single Record Biflow Data Set 837 The following example demonstrates the use of the biflowDirection 838 Information Element, as specified in section 6.2, using the IPFIX 839 Options mechanism to specify that perimeter direction selection is in 840 effect for a given Observation Domain. 842 The information exported in this case is: 844 o The Observation Domain: observationDomainId in the IPFIX 845 Information Model [I-D.ietf-ipfix-info], with a length of 4 octets 847 o The direction assignment method: biflowDirection as defined in 848 section 6.2, above, with a length of 1 octet. 850 and the resulting template would look like the diagram below: 852 1 2 3 853 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 854 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 855 | Set ID = 3 | Length = 18 | 856 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 857 | Template ID >= 256 | Field Count = 2 | 858 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 859 | Scope Count = 1 |0| observationDomainId 149 | 860 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 861 | Field Length = 4 |0| biflowDirection TBD2 | 862 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 863 | Field Length = 1 | 864 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 866 Figure 9: Biflow Direction Options Template Set 868 The following example data record would specify that perimeter 869 direction selection is in effect for the Observation Domain with ID 870 33. Its format is defined by the example template, above. Note that 871 this example data set would be sent reliably, as specified in the 872 description of the biflowDirection Information Element. 874 1 2 3 875 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 876 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 877 | Set ID >= 256 | Length = 9 | 878 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 879 | 33 | 880 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 881 | 3 | 882 +-+-+-+-+-+-+-+-+ 884 Figure 10: Biflow Direction Options Data Set 886 Appendix B. XML Specification of biflowDirection Information Element 888 This appendix contains a machine-readable description of the 889 biflowDirection information element defined in this document, coded 890 in XML. Note that this appendix is of informational nature, while 891 the text in section 6.3 is normative. 893 The format in which this specification is given is described by the 894 XML Schema in Appendix B of the IPFIX Information Model 895 [I-D.ietf-ipfix-info]. 897 898 903 906 907 908 A description of the direction assignment method used to assign 909 source and destination to this Biflow. This Information Element MAY 910 be present in a Flow Data Record, or applied to all flows exported 911 from an Exporting Process or Observation Domain using IPFIX Options. 912 If this Information Element is not present in a Flow Record or 913 associated with a Biflow via scope, it is assumed that the 914 configuration of the direction assignment method is done 915 out-of-band. Note that when using IPFIX Options to apply this 916 Information Element to all flows within an Observation Domain or 917 from an Exporting Process, the Option SHOULD be sent reliably. If 918 reliable transport is not available (i.e., when using UDP), this 919 Information Element SHOULD appear in each Flow Record. This field 920 may take the following values: 921 922 923 +-------+------------------+----------------------------------------+ 924 | Value | Name | Description | 925 +-------+------------------+----------------------------------------+ 926 | 0x00 | arbitrary | Direction was assigned arbitrarily. | 927 | 0x01 | initiator | The Biflow Source is the flow | 928 | | | initiator, as determined by the | 929 | | | Metering Process' best effort to | 930 | | | detect the initiator. | 931 | 0x02 | reverseInitiator | The Biflow Destination is the flow | 932 | | | initiator, as determined by the | 933 | | | Metering Process' best effort to | 934 | | | detect the initiator. This value is | 935 | | | provided for the convenience of | 936 | | | Exporting Processes to revise an | 937 | | | initiator estimate without re-encoding | 938 | | | the Biflow Record. | 939 | 0x03 | perimeter | The Biflow Source is the endpoint | 940 | | | outside of a defined perimeter. The | 941 | | | perimeter's definition is implicit in | 942 | | | the set of Biflow Source and Biflow | 943 | | | Destination addresses exported in the | 944 | | | Biflow Records. | 945 +-------+------------------+----------------------------------------+ 946 947 948 949 951 Authors' Addresses 953 Brian H. Trammell 954 CERT Network Situational Awareness 955 Software Engineering Institute 956 4500 Fifth Avenue 957 Pittsburgh, PA 15213 958 US 960 Phone: +1 412 268 9748 961 Email: bht@cert.org 963 Elisa Boschi 964 Hitachi Europe SAS 965 Immeuble Le Theleme 966 1503 Route les Dolines 967 06560 Valbonne 968 France 970 Phone: +33 4 89874100 971 Email: elisa.boschi@hitachi-eu.com 973 Full Copyright Statement 975 Copyright (C) The IETF Trust (2007). 977 This document is subject to the rights, licenses and restrictions 978 contained in BCP 78, and except as set forth therein, the authors 979 retain all their rights. 981 This document and the information contained herein are provided on an 982 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 983 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 984 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 985 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 986 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 987 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 989 Intellectual Property 991 The IETF takes no position regarding the validity or scope of any 992 Intellectual Property Rights or other rights that might be claimed to 993 pertain to the implementation or use of the technology described in 994 this document or the extent to which any license under such rights 995 might or might not be available; nor does it represent that it has 996 made any independent effort to identify any such rights. Information 997 on the procedures with respect to rights in RFC documents can be 998 found in BCP 78 and BCP 79. 1000 Copies of IPR disclosures made to the IETF Secretariat and any 1001 assurances of licenses to be made available, or the result of an 1002 attempt made to obtain a general license or permission for the use of 1003 such proprietary rights by implementers or users of this 1004 specification can be obtained from the IETF on-line IPR repository at 1005 http://www.ietf.org/ipr. 1007 The IETF invites any interested party to bring to its attention any 1008 copyrights, patents or patent applications, or other proprietary 1009 rights that may cover technology that may be required to implement 1010 this standard. Please address the information to the IETF at 1011 ietf-ipr@ietf.org. 1013 Acknowledgment 1015 Funding for the RFC Editor function is provided by the IETF 1016 Administrative Support Activity (IASA).