idnits 2.17.1 draft-sommer-ipfix-mediator-ext-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 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 392. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 403. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 410. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 416. 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 : ---------------------------------------------------------------------------- -- 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 (July 14, 2008) is 5762 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 4234 (Obsoleted by RFC 5234) ** Obsolete normative reference: RFC 5101 (Obsoleted by RFC 7011) ** Obsolete normative reference: RFC 5102 (Obsoleted by RFC 7012) Summary: 4 errors (**), 0 flaws (~~), 1 warning (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Sommer 3 Internet-Draft F. Dressler 4 Intended status: Standards Track Univ. Erlangen 5 Expires: January 15, 2009 G. Muenz 6 Univ. Tuebingen 7 July 14, 2008 9 Mediator-Specific Extensions to IPFIX Protocol and Information Model 10 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on January 15, 2009. 37 Abstract 39 IPFIX supports the concept of a Mediator, a device that receives, 40 transforms, and exports data streams using IPFIX. One of the most 41 important requirements is the reduction of the volume of IPFIX 42 traffic by aggregating and discarding received information. This 43 document introduces a number of extensions to the IPFIX Information 44 Model that support the export of aggregated IPFIX data, introducing 45 abstract data types and Information Elements that optimize the 46 transport of descriptive information in terms of flow records' amount 47 and size. All extensions are directly applicable to the IPFIX 48 Mediator but can be used in many different applications as well. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Abstract data type orderedList . . . . . . . . . . . . . . . . 3 54 3. Abstract data type orderedPair . . . . . . . . . . . . . . . . 4 55 4. Abstract data type portRanges . . . . . . . . . . . . . . . . 5 56 5. Abstract data type ipv4Network . . . . . . . . . . . . . . . . 7 57 6. excludedPropertiesId Information Element . . . . . . . . . . . 7 58 7. Security considerations . . . . . . . . . . . . . . . . . . . 9 59 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 60 9. Normative References . . . . . . . . . . . . . . . . . . . . . 10 61 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 62 Intellectual Property and Copyright Statements . . . . . . . . . . 12 64 1. Introduction 66 The IPFIX Mediator is intended to provide techniques and features to 67 process IPFIX data in a Mediation Process. This process receives 68 data streams using IPFIX. It can apply transformations or 69 aggregation techniques and forward the resulting Flow information to 70 an Exporting Process and, thus, to another IPFIX collector. Flow 71 aggregation is one of the key operations in high-bandwidth networks. 72 The main idea is to reduce both the number and the size of IPFIX 73 messages. 75 This document introduces extensions to the IPFIX Information Model 76 that support the export of aggregated IPFIX data. These extensions 77 allow and optimize the transport of descriptive information on 78 aggregated IPFIX data. Thus, more information can be preserved in 79 the transmission while further reducing both the number and the size 80 of IPFIX messages. All the proposed extensions are directly 81 applicable to the IPFIX Mediator but can be used in many different 82 applications as well. 84 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 85 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 86 document are to be interpreted as described in [RFC2119]. 87 Illustrations of abstract data types are written in Augmented Backus- 88 Naur Form (ABNF), as specified in [RFC4234], extending the abstract 89 data types defined in [RFC5102]. Apart from the basic terms as 90 defined in [RFC5101], this document uses terminology first introduced 91 in [I-D.dressler-ipfix-aggregation]. 93 2. Abstract data type orderedList 95 IPFIX allows the transport of an ordered list of values by including 96 in a Template several Information Elements of the same type more than 97 once. This approach requires one Template for each possible length 98 of the list. In the context of flow mediation, however, the number 99 of entries in such lists typically changes with each exported 100 compound flow, leading to a dramatic increase of Templates and 101 associated housekeeping overhead. Therefore, a new abstract data 102 type, orderedList, is defined in this section. 104 The abstract data type orderedList defines an ordered list of 105 Information Elements, each being of the same type (referred to as 106 elementType) and the same, pre-defined length. An orderedList can 107 transport any finite number of Information Elements. The length of 108 an orderedList thus varies and is an integer multiple of the 109 contained Information Elements' length. If more than one contained 110 Information Element is transmitted in the form of an orderedList, 111 reduced size encoding of elementType MUST NOT be used. If only one 112 contained Information Element is transmitted, reduced size encoding 113 of elementType MAY be used. In ABNF-style notation, the syntax can 114 be summed up as follows: 116 orderedList = *( elementType ) 118 The number of Information Elements contained in an orderedList can be 119 determined by dividing the length of the orderedList by the length of 120 elementType. An Information Element basing on orderedList MAY also 121 be used as a variable-length Information Element by prefixing it with 122 a one-octet or three-octet length specifier as defined in [RFC5101]. 124 Table 1 shows some encoding examples if unsigned16 is used as the 125 elementType. 127 +----------------+--------+----------------+-----------------------+ 128 | Human-Readable | Octets | Hexadecimal | Remarks | 129 +----------------+--------+----------------+-----------------------+ 130 | 80 | 1 | 50 | Reduced size encoding | 131 | 80 | 2 | 0050 | | 132 | 80, 443 | 4 | 0050 01BB | | 133 | 80, 443, 8080 | 6 | 0050 01BB 1F90 | | 134 +----------------+--------+----------------+-----------------------+ 136 Table 1: orderedList Examples 138 3. Abstract data type orderedPair 140 The abstract data type orderedPair defines a 2-tuple of Information 141 Elements, each being of the same type (referred to as elementType) 142 and the same, pre-defined length. The length of an orderedPair is 143 thus defined as twice the length of its elementType. If more than 144 one contained Information Element is transmitted in the form of an 145 orderedPair, reduced size encoding of elementType MUST NOT be used. 146 If only one contained Information Element is transmitted, reduced 147 size encoding of orderedPair MAY be used if both contained 148 Information Elements are of the same value. The reduced size 149 representation of the orderedPair is in this case identical with the 150 (full or reduced size representation) of elementType. In ABNF-style 151 notation, the syntax can be summed up as follows: 153 orderedPair = elementType elementType 154 orderedPair =/ elementType 156 Table 2 shows some encoding examples if unsigned16 is used as the 157 elementType. 159 +----------------+--------+-------------+-----------------------+ 160 | Human-Readable | Octets | Hexadecimal | Remarks | 161 +----------------+--------+-------------+-----------------------+ 162 | 80, 80 | 1 | 50 | Reduced size encoding | 163 | 80, 80 | 2 | 0050 | Reduced size encoding | 164 | 80, 80 | 4 | 0050 0050 | | 165 | 80, 443 | 4 | 0050 01BB | | 166 +----------------+--------+-------------+-----------------------+ 168 Table 2: orderedPair Examples 170 4. Abstract data type portRanges 172 For some applications it might be useful to restrict the 173 applicability of an Aggregation Rule to Flows with source or 174 destination port being of a specific set of port numbers. In an 175 Aggregation Rule, such a set of port numbers can be specified as a 176 pattern. However, the current IPFIX Information Model does not 177 define any data type that allows transmitting a set of port numbers, 178 which is necessary in order to export the pattern as a Common 179 Property of the resulting Compound Flows. Therefore, the new 180 abstract data type portRanges for a list of port ranges is defined in 181 this section. 183 The abstract data type portRanges is an orderedList of orderedPair 184 Information Elements, each pair consisting of two unsigned16 185 Information Elements representing the port range's first and last 186 port number. 188 Data types basing on portRanges MAY thus be cast down to unsigned16 189 using reduced size encoding to represent a single Port and, hence, 190 the transportSourcePort and transportDestinationPort data types, 191 currently based on the unsigned16 abstract data type, can also be 192 parsed as portRanges-based data types. As specified for data types 193 basing on orderedList, an Information Element basing on portRanges 194 MAY also be used as a variable-length Information Elements by 195 prefixing it with a one-octet or three-octet length specifier as 196 defined in [RFC5101]. 198 Table 3 shows some encoding examples with portRanges. 200 +---------------+--------+-------------------------------+ 201 | Port Ranges | Octets | Hexadecimal Representation | 202 +---------------+--------+-------------------------------+ 203 | 80 | 2 | 0050 | 204 | 1:7 | 4 | 0001 0007 | 205 | 80, 443 | 8 | 0050 0050 01BB 01BB | 206 | 1:7, 256:1024 | 8 | 0001 0007 0100 0400 | 207 | 20, 80, 443 | 12 | 0014 0014 0050 0050 01BB 01BB | 208 | 1:7, 80, 443 | 12 | 0001 0007 0050 0050 01BB 01BB | 209 +---------------+--------+-------------------------------+ 211 Table 3: PortRanges Examples 213 5. Abstract data type ipv4Network 215 Currently, the transport of IP network information as specified by 216 IPFIX is done using two separate fields for the network address and 217 the corresponding mask. We propose a new abstract data type 218 ipv4Network that represents the common notation of IP networks: 219 address/mask. 221 The ipv4Network abstract data type extends the abstract data type 222 ipv4Address to allow a concatenated unsigned8 specifying the prefix 223 length. Alternatively, Information Elements based on the ipv4Network 224 abstract data type MAY be transmitted using reduced size encoding to 225 transmit only the network part of an IPv4 address. In ABNF-style 226 notation, the syntax can be summed up as follows: 228 ipv4Network = ipv4Address unsigned8 229 ipv4Network =/ *4( unsigned8 ) 231 Although using an ipv4Network field instead of two separate fields 232 for prefix and mask will not reduce the length of resulting Flow 233 Records, it eases the work of the aggregator: With ipv4Network, the 234 comparison of subnet addresses requires only one field lookup per 235 Flow Record instead of two. Furthermore, using the abstract data 236 type ipv4Network reduces the Template size by one field equaling four 237 octets. Applications such as IPFIX Aggregation benefit from 238 ipv4Network if network addresses are frequently exported. 240 6. excludedPropertiesId Information Element 242 The IPFIX Information Model [RFC5102] defines the commonPropertiesId 243 Information Element, which can be used to link to information which 244 several Flows have in common. 246 Similarly, the excludedPropertiesId shall be defined to link to a set 247 of Common Properties which a Flow does explicitly not exhibit. An 248 Element Id of 239 is proposed for this Information Element. 250 The excludedPropertiesId works like a Boolean "and not" operation on 251 the linked properties. This means that, if an excludedPropertiesId 252 refers to a set of Common Properties which in turn specifies excluded 253 properties, these transitively referenced properties are to be 254 treated as if directly referenced via a commonPropertiesId element 255 and, hence, as being present in the Flow in question. 257 Multiple excludedPropertiesId and commonPropertiesId specified for an 258 IPFIX Record must never contradict each other. If an IPFIX Collector 259 is able to detect that contradicting IEs were received, it SHOULD 260 proceed as if it received bad or nonsensical data. 262 The excludedPropertiesId can, for example, be used when a hierarchy 263 of Aggregation Rules with a "preceding rule" semantic, as introduced 264 in [I-D.dressler-ipfix-aggregation], is configured in an IPFIX 265 Aggregator. 267 Figure 1 illustrates the use of Common Property definitions and the 268 linking to these definitions with Information Elements of types 269 commonPropertiesId (CP) and excludedPropertiesId (EP). In this 270 example, two rules are defined in the aggregator: Rule 1 matches 271 Flows with a sourceIPv4Address of 192.0.2.1, Rule 2 matches Flows 272 with a destinationIPv4Address of 192.0.2.2. Furthermore, Rule 1 is 273 configured to precede Rule 2 in a hierarchy of rules, i.e. Flows 274 that matched Rule 1 will never match Rule 2. 276 In order to communicate this fact to a receiver, each Aggregation 277 Rule is transmitted as two sets of Common Properties. One set of 278 properties (shown on the right hand side of Figure 1) directly 279 transmits a rule's filtering criteria. The other set of properties 280 (shown on the left hand side) refers via a commonPropertiesId to all 281 properties that a Compound Flow exhibits, as well as via an 282 excludedPropertiesId to all that the Compound Flow does not exhibit. 284 The Flow depicted at the bottom of Figure 1 thus communicates a 285 source port of 80, a destination port of 65432, a destination IP of 286 192.0.2.2 and a source IP of "not 192.0.2.1". However, besides the 287 transmission of this Flow in one Data Record, previous transmissions 288 (and the successful reception) of four Option Templates, four Option 289 Data Records and one Template are required to communicate this 290 information. 292 Rule 1: 293 +########+------+ +######+---------------+ 294 # CP=101 # CP=1 |<-----------># CP=1 # SRC=192.0.2.1 | 295 +########+------+ +######+---------------+ 296 ^ 297 .--------------------' 298 Rule 2: v 299 +########+------+------+ +######+---------------+ 300 # CP=102 # EP=1 | CP=2 |<----># CP=2 # DST=192.0.2.2 | 301 +########+------+------+ +######+---------------+ 302 ^ 303 '-------------------. 304 Flow: v 305 +--------+-----------+--------+ 306 | SPT=80 | DPT=65432 | CP=102 | 307 +--------+-----------+--------+ 309 Figure 1: Using excludedPropertiesId to communicate a rule hierarchy 311 7. Security considerations 313 As all methods described in this document are merely variations on 314 methods already introduced in [RFC5101], the same rules regarding 315 exchange of Flow information apply. 317 8. IANA Considerations 319 Use of excludedPropertiesId, as well as use of a data type basing on 320 ipv4Network or on portRanges requires one new IPFIX Information 321 Element identifier each to be assigned. 323 9. Normative References 325 [I-D.dressler-ipfix-aggregation] 326 Dressler, F., "IPFIX Aggregation", 327 draft-dressler-ipfix-aggregation-05 (work in progress), 328 July 2008. 330 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 331 Requirement Levels", BCP 14, RFC 2119, March 1997. 333 [RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 334 Specifications: ABNF", RFC 4234, October 2005. 336 [RFC5101] Claise, B., "Specification of the IP Flow Information 337 Export (IPFIX) Protocol for the Exchange of IP Traffic 338 Flow Information", RFC 5101, January 2008. 340 [RFC5102] Quittek, J., Bryant, S., Claise, B., Aitken, P., and J. 341 Meyer, "Information Model for IP Flow Information Export", 342 RFC 5102, January 2008. 344 Authors' Addresses 346 Christoph Sommer 347 University of Erlangen-Nuremberg 348 Department of Computer Science 7 349 Martensstr. 3 350 Erlangen 91058 351 Germany 353 Phone: +49 9131 85-27993 354 Email: christoph.sommer@informatik.uni-erlangen.de 355 URI: http://www7.informatik.uni-erlangen.de/~sommer/ 357 Falko Dressler 358 University of Erlangen-Nuremberg 359 Department of Computer Science 7 360 Martensstr. 3 361 Erlangen 91058 362 Germany 364 Phone: +49 9131 85-27914 365 Email: dressler@informatik.uni-erlangen.de 366 URI: http://www7.informatik.uni-erlangen.de/ 367 Gerhard Muenz 368 University of Tuebingen 369 Computer Networks and Internet 370 Sand 13 371 Tuebingen 72076 372 Germany 374 Phone: +49 7071 29-70534 375 Email: muenz@informatik.uni-tuebingen.de 376 URI: http://net.informatik.uni-tuebingen.de/ 378 Full Copyright Statement 380 Copyright (C) The IETF Trust (2008). 382 This document is subject to the rights, licenses and restrictions 383 contained in BCP 78, and except as set forth therein, the authors 384 retain all their rights. 386 This document and the information contained herein are provided on an 387 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 388 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 389 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 390 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 391 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 392 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 394 Intellectual Property 396 The IETF takes no position regarding the validity or scope of any 397 Intellectual Property Rights or other rights that might be claimed to 398 pertain to the implementation or use of the technology described in 399 this document or the extent to which any license under such rights 400 might or might not be available; nor does it represent that it has 401 made any independent effort to identify any such rights. Information 402 on the procedures with respect to rights in RFC documents can be 403 found in BCP 78 and BCP 79. 405 Copies of IPR disclosures made to the IETF Secretariat and any 406 assurances of licenses to be made available, or the result of an 407 attempt made to obtain a general license or permission for the use of 408 such proprietary rights by implementers or users of this 409 specification can be obtained from the IETF on-line IPR repository at 410 http://www.ietf.org/ipr. 412 The IETF invites any interested party to bring to its attention any 413 copyrights, patents or patent applications, or other proprietary 414 rights that may cover technology that may be required to implement 415 this standard. Please address the information to the IETF at 416 ietf-ipr@ietf.org.