idnits 2.17.1 draft-dressler-ipfix-aggregation-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 19. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 647. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 658. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 665. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 671. 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 5765 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 5101 (Obsoleted by RFC 7011) ** Obsolete normative reference: RFC 5102 (Obsoleted by RFC 7012) Summary: 3 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 F. Dressler 3 Internet-Draft C. Sommer 4 Intended status: Standards Track Univ. Erlangen 5 Expires: January 15, 2009 G. Muenz 6 Univ. Tuebingen 7 A. Kobayashi 8 NTT PF Lab. 9 July 14, 2008 11 IPFIX Flow Aggregation 12 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on January 15, 2009. 39 Copyright Notice 41 Copyright (C) The IETF Trust (2008). 43 Abstract 45 IPFIX Flow Aggregation describes a methodology for reducing the 46 amount of measurement data exchanged between monitoring devices 47 (IPFIX Exporters) and analyzers (IPFIX Collectors). Aggregation 48 techniques represent a necessary enhancement in order to cope with 49 increasing amounts of monitoring data that accrue with the ever- 50 growing network capacities. Using Flow Selection Criteria and 51 Compound Flow creation techniques, measurement information of 52 multiple Flows that are sharing some common criteria is merged to be 53 exported in one Compound Flow. Subsets of Flows eligible for 54 aggregation, as well as the desired degree of similarity, can be 55 customized using a set of Aggregation Rules. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3. Aggregation . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 4. Selection . . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 5. Compound Flow Creation . . . . . . . . . . . . . . . . . . . . 5 64 6. Aggregation Rules . . . . . . . . . . . . . . . . . . . . . . 7 65 6.1. Single Aggregation Rule . . . . . . . . . . . . . . . . . 7 66 6.2. Multiple Aggregation Rules . . . . . . . . . . . . . . . . 8 67 6.3. Deriving Templates from Aggregation Rules . . . . . . . . 8 68 7. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 69 8. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 12 70 9. Security Considerations . . . . . . . . . . . . . . . . . . . 13 71 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 72 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 73 11.1. Normative References . . . . . . . . . . . . . . . . . . . 13 74 11.2. Informative References . . . . . . . . . . . . . . . . . . 13 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 76 Intellectual Property and Copyright Statements . . . . . . . . . . 15 78 1. Introduction 80 Flow measurement in high-speed large-scale networks easily produces 81 an amount of data that can no longer be handled by a single IPFIX 82 Collector. Also, many applications processing Flow measurement data 83 do not require detailed Flow-level information, but require only 84 generic Flow information, with the scope of this information being 85 very application-specific. Examples for applications benefiting of 86 IPFIX Flow aggregation are charging and intrusion detection. In the 87 former application, detailed information about individual Flows is 88 not required. Similarly, intrusion detection applications may be 89 satisfied with Flow information for specific subnets. Flow 90 aggregation is also a viable solution for the anonymization of Flow 91 information. 93 This document presents a flexible Flow aggregation scheme that helps 94 reduce the number and the size of exported Flow Records, as well as 95 helps adapt the transmitted measurement information to the 96 requirements of deployed applications. Measurement data reduction is 97 achieved by discarding unneeded measurement information and merging 98 multiple individual Flows into a smaller number of Compound Flows, 99 which are then exported to the analyzer. 101 Flow aggregation will usually take place in an IPFIX concentrator. 102 Monitoring networks can thus be deployed in a logical tree topology, 103 using multiple levels of intermediate concentrators, rather than in a 104 logical star topology. 106 The following sections illustrate the design and implementation of 107 Flow aggregation. The key words "MUST", "MUST NOT", "REQUIRED", 108 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 109 and "OPTIONAL" in this document are to be interpreted as described in 110 [RFC2119]. 112 2. Terminology 114 Apart from the basic terms described in [RFC3917], [RFC5101], and 115 [I-D.ietf-ipfix-architecture], the following terms are used within 116 this document: 118 Compound Flow: 119 A Compound Flow is the result of an aggregation of one or more 120 individual input Flows that matched an Aggregation Rule. It 121 might, for example, contain the total count of all packets 122 addressed to a common subnet that were observed within a given 123 time interval. 125 Aggregation Rule: 126 An Aggregation Rule defines the properties of a Compound Flow and 127 the contents of the corresponding Flow Records. Optionally, a set 128 of selection criteria MAY be specified in order to restrict the 129 applicability of the Aggregation Rule to those Flows that show 130 certain patterns. 132 Preceding Rule: 133 The Preceding Rule represents a mechanism to inform the collector 134 about the position of the matching Aggregation Rule in the entire 135 chain or tree of Aggregation Rules. This parameter MAY be used to 136 dynamically transmit parts of the rule chain or tree. 138 3. Aggregation 140 An IPFIX concentrator, as introduced in [RFC3917], MAY be employed to 141 save processing resources of distributed monitoring devices by 142 providing aggregation techniques. Aggregated Flow data is exported 143 in form of Compound Flows. Furthermore, concentrators enable 144 cascaded, multi-level aggregation of Flow information. 146 In order to efficiently customize both the contents and the size of 147 exported Compound Flows, a two-step approach is proposed. 149 1. Incoming Flows are selected by comparing contained information 150 with configured Selection Criteria, enabling the aggregator to 151 discard unwanted Flows. 153 2. The selected Flows are aggregated by discarding fields or parts 154 of fields, enabling the aggregator to create Compound Flows by 155 merging Flows according to a reduced Flow Key. 157 These two independent steps are introduced in the next two sections. 158 A mediation device can use either one or both. 160 4. Selection 162 Depending on the configuration of the mediator, the receiver of Flows 163 may be only interested in a subset of all Flows that matches certain 164 patterns. Thus, patterns act as criteria that enable the selection 165 of Flows eligible for aggregation and subsequent export to the 166 analyzer. For example, the pattern "80" can configured for the 167 sourceTransportPort field in order to export only Compound Flows sent 168 by an HTTP server. 170 Selecting Flows means that all of the source Flows that make up a 171 certain Compound Flow will share a specific set of field values (e.g. 172 destination address 192.0.2.1 and destination port 80). This common 173 set of field values MUST be transmitted to receivers along with 174 Compound Flows' specific field values, so as not to lose information. 176 In order to conserve traffic volume it SHOULD, however, not be 177 directly included in all exported Compound Flow Records, but rather 178 communicated by more bandwidth-conserving means which still guarantee 179 a stable association from specific properties to Common Properties of 180 a Flow. 182 One such means is the transmission as a set of Common Properties. 183 This concept is introduced in [RFC5102] and illustrated in Figure 1. 184 In order to unambiguously communicate to receivers which Common 185 Properties of a Flow stem from aggregation, when multiple Common 186 Properties are transmitted in one Flow, an aggregator SHOULD make 187 sure that the first commonPropertiesID transmitted in Flows directly 188 corresponds to the set of selection criteria used. 190 Selection Criterion 1: 191 +######+---------------+ 192 # CP=1 # SRC=192.0.2.1 | 193 +######+---------------+ 195 Selection Criterion 2: 196 +######+---------------+ 197 # CP=2 # DST=192.0.2.2 | 198 +######+---------------+ 199 ^ 200 '-------------------. 201 Flow: v 202 +--------+-----------+------+ 203 | SPT=80 | DPT=65432 | CP=2 | 204 +--------+-----------+------+ 206 Figure 1: Using Common Properties to transmit Selection Criteria 208 5. Compound Flow Creation 210 The second aggregation step is the creation of Compound Flows. 211 Selected Flows can be aggregated by discarding fields or parts of 212 fields, enabling the aggregator to create Compound Flows by merging 213 Flows according to a reduced Flow Key. The following field modifiers 214 can be applied: 216 discard: 217 The field is not included in Compound Flow Records, i.e. Compound 218 Flows are not distinguishable with respect to this field. 219 Incoming Flows with different values for this field can be merged 220 and thus contribute to the same Compound Flow. 222 keep: 223 The field is included unmodified in Compound Flow Records, i.e. 224 Compound Flows are distinguishable with respect to this field. 225 Incoming Flows with different values for this field are not 226 merged, but contribute to different Compound Flows instead. 228 mask to n bits: 229 The field is included in Compound Flow Records, but the number of 230 significant bits is reduced (applicable to IP addresses only). 231 Incoming Flows with IP addresses belonging to the same subnet are 232 merged, so Compound Flows are distinguishable with respect to 233 resulting subnet addresses only. In accordance with [RFC5102], 234 the resulting subnet address MAY be encoded with an IP prefix 235 field and an IP mask field. For performance reasons it SHOULD, 236 however, be encoded with a single field of the abstract data type 237 ipv4Network introduced in [I-D.sommer-ipfix-mediator-ext]. 239 aggregate: 240 The field is included in Compound Flow Records, but field values 241 derived from multiple incoming Flows' values. 243 The value of fields with a field modifier of "aggregate" is computed 244 from the corresponding values of the original Flows by taking the 245 most appropriate of the following actions (listed in ascending order 246 of priority): 248 1. As also specified in [RFC5102] the value of variable fields, 249 which may change from packet to packet within a single Flow, is 250 determined by the first packet observed for the corresponding 251 Compound Flow. As a consequence, if no other action is more 252 appropriate, the default behavior requires using the value of the 253 incoming Flow Record with the earliest start timestamp. 255 2. For some Information Elements, [RFC5102] explicitly specifies a 256 different semantic, which is to then take precedence over the 257 aforementioned default behavior. 259 3. For some Information Elements, Table 1 specifies an aggregation 260 function that has to be used in order to obtain a correct, 261 aggregated value. If such an aggregation function is listed, it 262 takes precedence over all other available functions. For 263 example, the start timestamp of the Compound Flow is always set 264 to the minimum of the original start timestamps, while packet and 265 octet counts of aggregated Flows are always summed up. 267 +-----------------------+----------------------+ 268 | Information Element | Aggregation Function | 269 +-----------------------+----------------------+ 270 | minimumPacketLength | min | 271 | minimumTtl | min | 272 | flowStartSeconds | min | 273 | flowStartMilliSeconds | min | 274 | maximumPacketLength | max | 275 | maximumTtl | max | 276 | flowEndSeconds | max | 277 | flowEndMilliSeconds | max | 278 | octetDeltaCount | sum | 279 | packetDeltaCount | sum | 280 +-----------------------+----------------------+ 282 Table 1: Treatment of Fields Carrying Metering Information 284 6. Aggregation Rules 286 For the configuration of selection and compound flow creation, a 287 rule-based approach is proposed, where each aggregator is supplied a 288 list of user-defined Aggregation Rules. 290 6.1. Single Aggregation Rule 292 An Aggregation Rule (see Section 7 for an example) consists of 293 multiple instructions, one for each data field that is to be 294 considered. Each of the Aggregation Rules' instructions comprises 295 the following elements: 297 o The data field the instruction refers to (e.g. 298 destinationIPv4Address). Only Flows that contain the field 299 mentioned will be eligible for aggregation according to this 300 Aggregation Rule. 302 o An optional Selection Criterion (Section 4), e.g. 192.0.2.0/24, 303 for this field that further restricts eligibility of incoming 304 Flows to those that match the given value(s). Only Flows that 305 match all patterns of the Aggregation Rule will be aggregated. 307 o An optional field modifier enabling Compound Flow creation 308 (Section 5) , e.g. mask to 28 bits, that either configures how 309 much information in this field should be retained unmodified by 310 the aggregator or that the field's values should be aggregated 311 instead. 313 Fields that do not appear in any of an Aggregation Rule's 314 instructions are not part of its associated Compound Flow Records. 315 Incoming Flows that are not covered by any Aggregation Rule are 316 discarded. 318 6.2. Multiple Aggregation Rules 320 By default, incoming Flow Records are checked against all of the 321 configured Aggregation Rules. If an Aggregation Rule matches, i.e. 322 if the Flow Record comprises all required fields and matches all 323 given patterns, the field modifiers are applied and corresponding 324 Compound Flow Records generated or updated. Therefore, incoming Flow 325 Records that match multiple Aggregation Rules contribute to multiple 326 Compound Flows. 328 In some cases, it is preferred that an incoming Flow Record that 329 matched a certain Aggregation Rule is not checked against further 330 Aggregation Rules in order to avoid that this Flow contributes to 331 multiple Compound Flows. Therefore, it is possible to indicate a 332 Preceding Rule for each Aggregation Rule. If a Preceding Rule is set 333 for an Aggregation Rule, an aggregator first tries to aggregate an 334 incoming Flow according to the Preceding Rule. Only if the Preceding 335 Rule is not applicable, e.g. because the incoming Flow does not match 336 the given pattern, the current Aggregation Rule is applied. Using 337 the Preceding Rule relationship, Aggregation Rules can thus be 338 organized in rule chains and rule trees where only the first matching 339 Aggregation Rule is applied in every chain or branch. Consequently, 340 each incoming Flow Record is aggregated at most once per chain or 341 tree. Rules that do not define a Preceding Rule constitute the 342 beginning of a rule chain or the root of a rule tree and are used to 343 check all incoming Flow Records. 345 If a Preceding Rule is set for an Aggregation Rule, a suitable 346 mechanism SHOULD be employed by an aggregator to communicate to 347 receivers of a Compound Flow not only its common inclusion criteria, 348 i.e. having matched the Aggregation Rule's selection patterns, but 349 also its common exclusion criteria, i.e. not having matched any 350 Preceding Rule's selection patterns. IPFIX extensions that enable 351 efficient transport of such information are introduced in 352 [I-D.sommer-ipfix-mediator-ext]. 354 6.3. Deriving Templates from Aggregation Rules 356 With the definition of an Aggregation Rule as being comprised of one 357 instruction per Compound Flow field, each Aggregation Rule 358 unambiguously defines the structure of these Compound Flows. As 359 illustrated in Table 2, all selection patterns of an Aggregation Rule 360 become Common Properties of associated Compound Flows. With the 361 exception of fields that are discarded, all fields of an Aggregation 362 Rule transmit specific properties of Compound Flows and will thus 363 need to be included in each exported Flow Record. Of those fields, 364 all fields, except those that were aggregated, form the Flow Key of 365 Compound Flows, as defined in [I-D.ietf-ipfix-architecture]. 367 +-----------+-------------+---------------+---------------+---------+ 368 | Selection | Aggregation | Common | Specific | Flow | 369 | | | Property | Property | Key | 370 +-----------+-------------+---------------+---------------+---------+ 371 | any | discard | | | | 372 | any | keep | | x | x | 373 | any | mask | | x | x | 374 | any | aggregate | | x | | 375 | pattern | discard | x | | | 376 | pattern | keep | x | x | x | 377 | pattern | mask | x | x | x | 378 | pattern | aggregate | x | x | | 379 +-----------+-------------+---------------+---------------+---------+ 381 Table 2: Mapping Rules to Templates 383 It should be noted that certain combinations of selection and 384 aggregation instructions can cause undesirable side effects and 385 SHOULD NOT be used. These combinations are: 387 atomic pattern, do not discard: 388 Selecting Flows to only allow a specific field value (as opposed 389 to a range of values) and retaining this field as a discriminating 390 property will lead to the transmission of the selection pattern as 391 both a Common Property of all Compound Flows and a discriminating 392 property. If only an atomic pattern is used, the field can be 393 discarded with no loss of information. 395 any field value, discard: 396 If neither a pattern nor a field modifier should apply to a field, 397 it is sufficient for an Aggregation Rule to not include an 398 instruction for this field. Specifying for a field neither a 399 pattern nor a modifier will mandate presence of the field for an 400 incoming Flow to be eligible for aggregation, but not accomplish 401 any real selection or aggregation. 403 pattern, aggregate: 404 Selecting Flows to only allow certain field values in non- 405 discriminating properties, such as packet counters, then modifying 406 these properties, can lead to semantic conflicts when interpreting 407 the received Compound Flows. 409 7. Example 411 An Aggregation Rule shown in Table 3 will set up a stream of Compound 412 Flows, creation of which is performed as follows. 414 Selection: 415 Only Flows containing at least fields for the source address, 416 destination address, destination port, and the packet count will 417 be considered for aggregation. In addition, the destination 418 address must be in the subnet 192.0.2.0/28 and the destination 419 port must be equal to 80. 421 Compound Flow creation: 422 Destination addresses are merged according to subnets in 423 192.0.2.0/30 and all packet counters of one Compound Flow are 424 added up. 426 Export: 427 The resulting Compound Flow Records comprise the source address, 428 the destination subnet address, and the packet counter as their 429 specific properties, as well as a destination subnet of 430 192.0.2.0/28 and a destination port of 80 as their Common 431 Property. 433 +--------------------------+--------------+----------------+ 434 | IPFIX Field | Selection | Aggregation | 435 +--------------------------+--------------+----------------+ 436 | sourceIPv4Address | | keep | 437 | destinationIPv4Address | 192.0.2.0/28 | mask to 30 bit | 438 | destinationTransportPort | 80 | discard | 439 | packetDeltaCount | | aggregate | 440 +--------------------------+--------------+----------------+ 442 Table 3: Example Aggregation Rule 444 Adding the Aggregation Rule shown in Table 4 and configuring it with 445 a Preceding Rule, the Aggregation Rule of Table 3, will set up a 446 second stream of Compound Flows, creation of which is performed as 447 follows. 449 Selection: 450 As introduced in Section 6.2, Flows that were already aggregated 451 according to the Preceding Rule will be skipped. In addition, 452 only Flows containing at least fields for the source address, 453 destination address, destination port, and the packet count will 454 be considered for aggregation. Furthermore, the destination port 455 of incoming Flows must be equal to 80. 457 Compound Flow creation: 458 Source and destination addresses are merged according to subnets 459 in 192.0.2.0/30 and all packet counters of one Compound Flow are 460 added up. 462 Export: 463 The resulting Compound Flow Records comprise the source subnet 464 address, the destination subnet address, and the packet counter as 465 their specific properties, as well as a destination port of 80 as 466 their Common Property. Furthermore, a Common Property of all 467 Compound Flow Records is that they did not match the Preceding 468 Rule, i.e. the combination of their destination subnet and 469 destination port was not 192.0.2.0/28 and 80. 471 +--------------------------+-----------+----------------+ 472 | IPFIX Field | Selection | Aggregation | 473 +--------------------------+-----------+----------------+ 474 | sourceIPv4Address | | mask to 30 bit | 475 | destinationIPv4Address | | mask to 30 bit | 476 | destinationTransportPort | 80 | discard | 477 | packetDeltaCount | | aggregate | 478 +--------------------------+-----------+----------------+ 480 Table 4: Second Aggregation Rule (Chained) 482 The following example Table 5 illustrates the application of the 483 described chain of Aggregation Rules to selected Flows. 485 +-------------+-----------+--------------+----------------+---------+ 486 | Source IP | Source | Destination | Destination | Packets | 487 | | Port | IP | Port | | 488 +-------------+-----------+--------------+----------------+---------+ 489 | 192.0.2.1 | 64235 | 192.0.2.101 | 80 | 10 | 490 | 192.0.2.2 | 64236 | 192.0.2.102 | 110 | 10 | 491 | 192.0.2.3 | 64237 | 192.0.2.103 | 80 | 10 | 492 | 192.0.2.101 | 64238 | 192.0.2.1 | 80 | 10 | 493 | 192.0.2.102 | 64239 | 192.0.2.2 | 80 | 10 | 494 +-------------+-----------+--------------+----------------+---------+ 496 Table 5: Incoming Flows 498 Two sets of Compound Flows, as depicted in Table 6 and Table 7, will 499 be exported in our example according to the Aggregation Rules shown 500 in Table 3 and Table 4, respectively. 502 +-------------+----------------+------------------+---------+ 503 | Source IP | Destination IP | Destination Port | Packets | 504 +-------------+----------------+------------------+---------+ 505 | 192.0.2.101 | 192.0.2.0 | 80 | 10 | 506 | 192.0.2.102 | 192.0.2.0 | 80 | 10 | 507 +-------------+----------------+------------------+---------+ 509 Table 6: Compound Flows according to the first Aggregation Rule 511 +-----------+----------------+------------------+---------+ 512 | Source IP | Destination IP | Destination Port | Packets | 513 +-----------+----------------+------------------+---------+ 514 | 192.0.2.0 | 192.0.2.100 | 80 | 20 | 515 +-----------+----------------+------------------+---------+ 517 Table 7: Compound Flows according to the second Aggregation Rule 519 8. Open Issues 521 While the aggregation methodology introduced in Section 3 solves most 522 problems that could arise when doing Flow aggregation, some issues 523 are left unresolved. These issues require special attention or need 524 to be addressed at higher layers and are presented in this section. 526 One problem arises when received Option Data Records are forwarded by 527 an aggregator. Option Data Records that refer to an Observation 528 Domain, e.g. Data Records based on the Metering Process 529 (Reliability) Statistics Option Template, only include an 530 observationDomainId. However, [RFC5102] only mandates that the 531 observationDomainId be locally unique to an Exporting Process, so in 532 order to unambiguously refer to an Observation Domain, an additional 533 identifier of the Exporting Process would need to be transmitted. 534 While the selection of an Observation Domain ID that is unique to the 535 aggregation domain would alleviate this issue, a more generic 536 solution seems to be preferable. 538 Another problem arises when different sources transmit Flows 539 containing merely pseudonyms instead of IP addresses, and these Flows 540 are to be aggregated e.g. by an IPFIX concentrator. If an aggregator 541 is not explicitly informed of the anonymous nature of received Flows, 542 it assumes that identical IP address values refer to identical hosts, 543 which might not be the case if Flow sources employ different 544 algorithms to generate pseudonyms. 546 9. Security Considerations 548 As all methods described in this document are merely variations on 549 methods already introduced in [RFC5101], the same security 550 considerations regarding exchange of Flow information apply. 552 10. IANA Considerations 554 This document has no actions for IANA. 556 11. References 558 11.1. Normative References 560 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 561 Requirement Levels", BCP 14, RFC 2119, March 1997. 563 [RFC5101] Claise, B., "Specification of the IP Flow Information 564 Export (IPFIX) Protocol for the Exchange of IP Traffic 565 Flow Information", RFC 5101, January 2008. 567 [RFC5102] Quittek, J., Bryant, S., Claise, B., Aitken, P., and J. 568 Meyer, "Information Model for IP Flow Information Export", 569 RFC 5102, January 2008. 571 11.2. Informative References 573 [I-D.ietf-ipfix-architecture] 574 Sadasivan, G., Brownlee, N., Claise, B., and J. Quittek, 575 "Architecture for IP Flow Information Export", 576 draft-ietf-ipfix-architecture-12 (work in progress), 577 September 2006. 579 [I-D.sommer-ipfix-mediator-ext] 580 Sommer, C., Dressler, F., and G. Muenz, "Mediator-Specific 581 Extensions to IPFIX Protocol and Information Model", 582 draft-sommer-ipfix-mediator-ext-01 (work in progress), 583 July 2008. 585 [RFC3917] Quittek, J., Zseby, T., Claise, B., and S. Zander, 586 "Requirements for IP Flow Information Export", RFC 3917, 587 October 2004. 589 Authors' Addresses 591 Falko Dressler 592 University of Erlangen-Nuremberg 593 Department of Computer Science 7 594 Martensstr. 3 595 Erlangen 91058 596 Germany 598 Phone: +49 9131 85-27914 599 Email: dressler@informatik.uni-erlangen.de 600 URI: http://www7.informatik.uni-erlangen.de/ 602 Christoph Sommer 603 University of Erlangen-Nuremberg 604 Department of Computer Science 7 605 Martensstr. 3 606 Erlangen 91058 607 Germany 609 Phone: +49 9131 85-27993 610 Email: christoph.sommer@informatik.uni-erlangen.de 611 URI: http://www7.informatik.uni-erlangen.de/~sommer/ 613 Gerhard Muenz 614 University of Tuebingen 615 Computer Networks and Internet 616 Sand 13 617 Tuebingen 72076 618 Germany 620 Phone: +49 7071 29-70534 621 Email: muenz@informatik.uni-tuebingen.de 622 URI: http://net.informatik.uni-tuebingen.de/ 624 Atsushi Kobayashi 625 NTT Information Sharing Platform Laboratories 626 3-9-11 Midori-cho 627 Musashino-shi, Tokyo 180-8585 628 Japan 630 Phone: +81-422-59-3978 631 Email: akoba@nttv6.net 633 Full Copyright Statement 635 Copyright (C) The IETF Trust (2008). 637 This document is subject to the rights, licenses and restrictions 638 contained in BCP 78, and except as set forth therein, the authors 639 retain all their rights. 641 This document and the information contained herein are provided on an 642 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 643 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 644 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 645 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 646 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 647 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 649 Intellectual Property 651 The IETF takes no position regarding the validity or scope of any 652 Intellectual Property Rights or other rights that might be claimed to 653 pertain to the implementation or use of the technology described in 654 this document or the extent to which any license under such rights 655 might or might not be available; nor does it represent that it has 656 made any independent effort to identify any such rights. Information 657 on the procedures with respect to rights in RFC documents can be 658 found in BCP 78 and BCP 79. 660 Copies of IPR disclosures made to the IETF Secretariat and any 661 assurances of licenses to be made available, or the result of an 662 attempt made to obtain a general license or permission for the use of 663 such proprietary rights by implementers or users of this 664 specification can be obtained from the IETF on-line IPR repository at 665 http://www.ietf.org/ipr. 667 The IETF invites any interested party to bring to its attention any 668 copyrights, patents or patent applications, or other proprietary 669 rights that may cover technology that may be required to implement 670 this standard. Please address the information to the IETF at 671 ietf-ipr@ietf.org. 673 Acknowledgment 675 Funding for the RFC Editor function is provided by the IETF 676 Administrative Support Activity (IASA).