idnits 2.17.1 draft-ietf-ipfix-mediation-protocol-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 and authors Copyright Line does not match the current year -- The document date (December 5, 2011) is 4497 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) ** Obsolete normative reference: RFC 4960 (Obsoleted by RFC 9260) ** Obsolete normative reference: RFC 5102 (Obsoleted by RFC 7012) == Outdated reference: A later version (-18) exists of draft-ietf-ipfix-flow-selection-tech-09 == Outdated reference: A later version (-04) exists of draft-trammell-ipfix-a9n-03 == Outdated reference: A later version (-06) exists of draft-ietf-ipfix-psamp-mib-04 == Outdated reference: A later version (-11) exists of draft-ietf-ipfix-configuration-model-10 == Outdated reference: A later version (-10) exists of draft-ietf-ipfix-protocol-rfc5101bis-00 -- Possible downref: Normative reference to a draft: ref. 'RFC5101bis' == Outdated reference: A later version (-03) exists of draft-ietf-ipfix-rfc5815bis-00 -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) Summary: 2 errors (**), 0 flaws (~~), 7 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPFIX Working Group B. Claise 3 Internet-Draft Cisco Systems, Inc. 4 Intended Status: Standards Track A. Kobayashi 5 Expires: June 5, 2012 NTT PF Lab. 6 B. Trammell 7 ETH Zurich 8 December 5, 2011 10 Specification of the Protocol for IPFIX Mediation 11 draft-ietf-ipfix-mediation-protocol-00 13 Abstract 15 This document specifies the IP Flow Information Export 16 (IPFIX) protocol specific to Mediation. 18 Status of this Memo 20 This Internet-Draft is submitted to IETF in full conformance 21 with the provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet 24 Engineering Task Force (IETF), its areas, and its working 25 groups. Note that other groups may also distribute working 26 documents as Internet-Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six 29 months and may be updated, replaced, or obsoleted by other 30 documents at any time. It is inappropriate to use Internet- 31 Drafts as reference material or to cite them other than as "work 32 in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html 40 This Internet-Draft will expire on April, 2011. 42 Copyright Notice 44 Copyright (c) 2011 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with 52 respect to this document. Code Components extracted from this 53 document must include Simplified BSD License text as described 54 in Section 4.e of the Trust Legal Provisions and are provided 55 without warranty as described in the Simplified BSD License. 57 Conventions used in this document 59 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", 60 "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 61 and "OPTIONAL" in this document are to be interpreted as 62 described in RFC 2119 [RFC2119]. 64 Table of Contents 66 1. Introduction............................................. 4 67 1.1. IPFIX Documents Overview............................ 5 68 1.2. IPFIX Mediator Documents Overview................... 5 69 1.3. Relationship with IPFIX and PSAMP................... 7 70 2. Terminology.............................................. 7 71 3. Specifications.......................................... 10 72 3.1. Encoding of IPFIX Message Header................... 11 73 3.2. Template Management................................ 13 74 3.2.1. Template Management Without Template Records 75 Change............................................... 13 76 3.2.2. Template Management With New Template Records. 16 77 3.3. Time Management.................................... 20 78 3.4. Observation Point Management....................... 21 79 3.4.1. Observation Domain Management................. 23 80 3.5. Specific Reporting Requirements.................... 24 81 3.5.1. The Flow Keys Options Template................ 24 82 3.5.2. IPFIX Protocol Options Template............... 25 83 3.5.3. IPFIX Mediator Options Template............... 25 84 3.6. The Collecting Process's Side...................... 26 85 3.7. Configuration Management........................... 26 86 4. New Information Elements................................ 26 87 5. Security Considerations................................. 27 88 6. IANA Considerations..................................... 27 89 6.1. originalExporterIPv4Address........................ 28 90 6.2. originalExporterIPv6Address........................ 28 91 6.3. originalObservationDomainId........................ 28 92 7. References.............................................. 29 93 7.1. Normative References............................... 29 94 7.2. Informative References............................. 30 96 8. Author's Addresses...................................... 31 97 Appendix A. Additions to XML Specification of IPFIX 98 Information Elements....................................... 32 100 TO DO: 101 - Change the reference from RFC5102 to RFC5102bis, or should we 102 list IANA? 103 - There are still changes in RFC5101bis that must be integrated 104 here. Example: Template withdrawal and template life time 105 - Definition change proposal for the Intermediate Process, 106 Intermediate Conversion Process, Intermediate Selection 107 Process, Intermediate Anonymization Process, and IPFIX 108 Mediator. See http://www.ietf.org/mail- 109 archive/web/ipfix/current/msg05969.html. However, the 110 definitions are copied over verbatim from RFC6183. Also note 111 that Intermediate Anonymization Process in this document is 112 not in line with the RFC6235. 113 - "the IPFIX Mediator MAY keep the export time received from 114 the incoming Transport Session", and " Therefore, as there is 115 not a single rule that fits all different situations, the 116 precise rules of applying the Flow Record timestamps in IPFIX 117 Mediators is out of the scope of this document." Do we need 118 something more specific? 119 - Agree upon "Practically, the Original Exporters will not 120 exporting these Information Elements. Therefore, the 121 Intermediate Process SHOULD report the Original Observation 122 Point(s) to the best of its knowledge. Note that the 123 Configuration Data Model for IPFIX and PSAMP [IPFIX-CONF] may 124 help." 125 - What Paul Aikten would like to see in section 3.5: 126 What about IE ordering? May an exporter re-order received 127 fields? eg, two devices sending the same information, 128 though with the fields in a different order. Or the 129 mediator is extracting the same information from two 130 sources. That seems to be a valid scenario. eg, this 131 reduces the number of templates received at the collector. 133 What about temporal re-ordering? How should a mediator deal 134 with out-of-order data coming from multiple devices? It 135 can't expect all received data to be in time order. 137 What should a mediator do with a field which it doesn't 138 know/understand? Inevitably, exporters will be updated 139 without mediators keeping in step. It's also very likely 140 that mediators will see Enterprise-specific IEs. May a 141 mediator re-export unknown IEs unchanged, or should it drop 142 them? Presumably a mediator may report received Enterprise- 143 specific IEs even from multiple different Enterprises. 145 What if an unknown field depends on the field ordering? eg, 146 it's a bitfield like flowKeyIndicator. Re-ordering, adding 147 or removing fields breaks the meaning of this field, so it 148 can't be passed on. It can only be used if the received 149 fields are reported unchanged. 151 1. Introduction 153 The IPFIX architectural components in [RFC5470] consist of 154 IPFIX Devices and IPFIX Collectors communicating using the 155 IPFIX protocol [RFC5101bis], which specifies how to export IP 156 Flow information. This protocol is designed to export 157 information about IP traffic Flows and related measurement 158 data, where a Flow is defined by a set of key attributes 159 (e.g. source and destination IP address, source and 160 destination port, etc.). 162 However, thanks to its Template mechanism, the IPFIX protocol 163 can export any type of information, as long as the relevant 164 Information Element is specified in the IPFIX Information 165 Model [RFC5102], registered with IANA, or specified as an 166 enterprise-specific Information Element. The specifications 167 in the IPFIX protocol [RFC5101bis] have not been defined in 168 the context of an IPFIX Mediator receiving, aggregating, 169 correlating, anonymizing, etc... Flow Records from the one or 170 multiple Exporters. Indeed, the IPFIX protocol must be 171 adapted for Intermediate Processes, as defined in the IPFIX 172 Mediation Reference Model as specified in Figure A of [IPFIX- 173 MED-FMWK], which is based on the IPFIX Mediation Problem 174 Statement [RFC5982]. 176 This document specifies the IP Flow Information Export 177 (IPFIX) protocol in the context of the implementation and 178 deployment of IPFIX Mediators. The use of the IPFIX 179 protocol within a Mediator -- a device which contains both 180 as a Collecting Process and an Exporting Process -- has an 181 impact on the technical details of the usage of the 182 protocol. An overview of the technical problem is covered 183 in section 6 of [RFC5982]: loss of original exporter 184 information, loss of base time information, transport 185 sessions management, loss of Options Template Information, 186 Template Id management, considerations for network 187 topology, IPFIX Mediation interpretation, and 188 considerations for aggregation. 190 The specifications in this document are based on the IPFIX 191 protocol specifications [RFC5101bis] but adapted according 192 to the IPFIX Mediation Framework [IPFIX-MED-FMWK]. 194 1.1. IPFIX Documents Overview 196 The IPFIX Protocol [RFC5101bis] provides network 197 administrators with access to IP Flow information. 199 The architecture for the export of measured IP Flow 200 information out of an IPFIX Exporting Process to a Collecting 201 Process is defined in the IPFIX Architecture [RFC5470], per 202 the requirements defined in the IPFIX Requirement doc, 203 [RFC3917]. 205 The IPFIX Architecture [RFC5470] specifies how IPFIX Data 206 Records and Templates are carried via a congestion-aware 207 transport protocol from IPFIX Exporting Processes to IPFIX 208 Collecting Processes. 210 IPFIX has a formal description of IPFIX Information Elements, 211 their name, type and additional semantic information, as 212 specified in the IPFIX Information Model [RFC5102]. 214 The IPFIX Applicability Statement [RFC5472] describes what 215 type of applications can use the IPFIX protocol and how they 216 can use the information provided. It furthermore shows how 217 the IPFIX framework relates to other architectures and 218 frameworks. 220 "IPFIX Mediation: Problem Statement" [RFC5982], describing the 221 IPFIX Mediation applicability examples, along with some problems 222 that network administrators have been facing, is the basis for 223 the "IPFIX Mediation: Framework" [IPFIX-MED-FMWK]. This 224 framework details the IPFIX Mediation reference model and the 225 components of an IPFIX Mediator. 227 1.2. IPFIX Mediator Documents Overview 229 The "IPFIX Mediation: Problem Statement" [RFC5982] provides an 230 overview of the applicability of Mediators, and defines 231 requirements for Mediators in general terms. This document is 232 of use largely to define the problems to be solved through the 233 deployment of IPFIX Mediators, and to provide scope to the role 234 of Mediators within an IPFIX collection infrastructure. 236 The "IPFIX Mediation: Framework" [IPFIX-MED-FMWK] provides more 237 architectural details of the arrangement of Intermediate 238 Processes within a Mediator. 240 The details of specific Intermediate Processes, when these have 241 additional export specifications (e.g., metadata about the 242 intermediate processing conveyed through IPFIX Options 243 Templates), are each treated in their own document (e.g., the 244 "IP Flow Anonymization Support" [RFC6235]). Documents 245 specifying the operations of specific Intermediate Processes 246 cover the operation of these Processes within the Mediator 247 framework, and comply with the specifications given in this 248 document; they may additionally specify the operation of the 249 process independently, outside the context of a Mediator, when 250 this is appropriate. As of today, these documents are: 252 1. "IP Flow Anonymization Support", [RFC6235], which describes 253 Anonymization techniques for IP flow data and the export of 254 Anonymized data using the IPFIX protocol. 256 2. "Flow Selection Techniques" [IPFIX-MED-FLOWSEL], which 257 describes the process of selecting a subset of flows from all 258 flows observed at an observation point, the flow selection 259 motivations, and some specific flow selection techniques. 261 3. "Exporting Aggregated Flow Data using the IP Flow Information 262 Export" [IPFIX-MED-AGGR] which describes Aggregated Flow export 263 within the framework of IPFIX Mediators and defines an 264 interoperable, implementation-independent method for Aggregated 265 Flow export. 267 This document specifies the IP Flow Information Export 268 (IPFIX) protocol specific to Mediation, i.e. the 269 specifications that all Intermediate Processes type must 270 comply to. Some extra specifications might be required per 271 Intermediate Process type (In which case, the Intermediate 272 Process specific document would cover those). 274 1.3. Relationship with IPFIX and PSAMP 276 The specification in this document applies to the IPFIX 277 protocol specifications [RFC5101bis]. All specifications 278 from [RFC5101bis] apply unless specified otherwise in this 279 document. 281 As the Packet Sampling (PSAMP) protocol specifications 282 [RFC5476] are based on the IPFIX protocol specifications, the 283 specifications in this document are also valid for the PSAMP 284 protocol. Therefore, the method specified by this document 285 also applies to PSAMP. 287 2. Terminology 289 The IPFIX-specific terms, such as Observation Domain, Flow, Flow 290 Key, Metering Process, Exporting Process, Exporter, IPFIX 291 Device, Collecting Process, Collector, Template, IPFIX Message, 292 Message Header, Template Record, Data Record, Options Template 293 Record, Set, Data Set, Information Element, and Transport 294 Session, used in this document are defined in [RFC5101bis]. 295 The PSAMP-specific terms used in this document, such as 296 Filtering and Sampling are defined in [RFC5476]. 298 The IPFIX Mediation terms related to the aggregation, such as 299 the Interval, Aggregated Flow, and Aggregated Function are 300 defined in [IPFIX-MED-AGGR]. 302 The IPFIX Mediation-specific terminology used in this document 303 is defined in "IPFIX Mediation: Problem Statement" [RFC5982], 304 and reused in "IPFIX Mediation: Framework" [IPFIX-MED-FMWK]. 305 However, since both of those documents are an informational 306 RFCs, the definitions have been reproduced here along with 307 additional definitions. 309 Similarly, since [RFC6235] is an experimental RFC, the 310 Anonymization Record, Anonymized Data Record, and Intermediate 311 Anonymization Process terms, specified in [RFC6235], are also 312 reproduced here. 314 In this document, as in [RFC5101bis], [RFC5476], [IPFIX-MED- 315 AGGR], and [RFC6235], the first letter of each IPFIX-specific 316 and PSAMP-specific term is capitalized along with the IPFIX 317 Mediation-specific term defined here. In this document, we call 318 a stream of records carrying flow- or packet-based information a 319 "record stream". The records may be encoded as IPFIX Data 320 Records of any other format. 322 Transport Session Information 324 The Transport Session is specified in [RFC5101bis]. In SCTP, 325 the Transport Session Information is the SCTP association. In 326 TCP and UDP, the Transport Session Information corresponds to 327 a 5-tuple {Exporter IP address, Collector IP address, Exporter 328 transport port, Collector transport port, transport protocol}. 330 Original Exporter 332 An Original Exporter is an IPFIX Device that hosts the 333 Observation Points where the metered IP packets are observed. 335 Original Observation Point 337 An Observation Point of the Original Exporter. In the case of 338 the Intermediate Aggregation Process on an IPFIX Mediator, the 339 Original Observation Point can be composed of, but not limited 340 to, a (set of) specific exporter(s), a (set of) specific 341 interface(s) on an Exporter, a (set of) line card(s) on an 342 Exporter, or any combinations of these. 344 IPFIX Mediation 346 IPFIX Mediation is the manipulation and conversion of a record 347 stream for subsequent export using the IPFIX protocol. 349 The following terms are used in this document to describe the 350 architectural entities used by IPFIX Mediation. 352 Intermediate Process 354 An Intermediate Process takes a record stream as its input 355 from Collecting Processes, Metering Processes, IPFIX File 356 Readers, other Intermediate Processes, or other record 357 sources; performs some transformations on this stream, based 358 upon the content of each record, states maintained across 359 multiple records, or other data sources; and passes the 360 transformed record stream as its output to Exporting 361 Processes, IPFIX File Writers, or other Intermediate 362 Processes, in order to perform IPFIX Mediation. Typically, an 363 Intermediate Process is hosted by an IPFIX Mediator. 364 Alternatively, an Intermediate Process may be hosted by an 365 Original Exporter. 367 IPFIX Mediator 369 An IPFIX Mediator is an IPFIX Device that provides IPFIX 370 Mediation by receiving a record stream from some data sources, 371 hosting one or more Intermediate Processes to transform that 372 stream, and exporting the transformed record stream into IPFIX 373 Messages via an Exporting Process. In the common case, an 374 IPFIX Mediator receives a record stream from a Collecting 375 Process, but it could also receive a record stream from data 376 sources not encoded using IPFIX, e.g., in the case of 377 conversion from the NetFlow V9 protocol [RFC3954] to IPFIX 378 protocol. 380 Specific Intermediate Processes are described below. However, 381 this is not an exhaustive list. 383 Intermediate Conversion Process 385 An Intermediate Conversion Process is an Intermediate 386 Process that transforms non-IPFIX into IPFIX, or manages the 387 relation among Templates and states of incoming/outgoing 388 Transport Sessions (or equivalent for non IPFIX protocols) 389 in the case of transport protocol conversion (e.g., from UDP 390 to SCTP). 392 Intermediate Aggregation Process 394 An Intermediate Aggregation Process is an Intermediate 395 Process that aggregates records based upon a set of Flow 396 Keys or functions applied to fields from the record (e.g., 397 binning and subnet aggregation). 399 Intermediate Correlation Process 401 An Intermediate Correlation Process is an Intermediate 402 Process that adds information to records, noting 403 correlations among them, or generates new records with 404 correlated data from multiple records (e.g., the production 405 of bidirectional flow records from unidirectional flow 406 records). 408 Intermediate Selection Process 410 An Intermediate Selection Process is an Intermediate Process 411 that selects records from a sequence based upon criteria- 412 evaluated record values and passes only those records that 413 match the criteria (e.g., Filtering only records from a 414 given network to a given Collector). 416 Intermediate Anonymization Process 418 An Intermediate Anonymization Process is an Intermediate 419 Process that transforms records in order to anonymize them, 420 to protect the identity of the entities described by the 421 records (e.g., by applying prefix-preserving 422 pseudonymization of IP addresses). 424 Template Mapping 426 A mapping from Template Records and/or Options Template 427 Records received by a Mediator to Template Records and/or 428 Options Template Records sent by that IPFIX Mediator. Each 429 entry in a Template Mapping is scoped by incoming or 430 outgoing Transport Session and Observation Domain, as with 431 Templates and Options Templates in the IPFIX Protocol. 433 Anonymization Record 435 A record, defined by the Anonymization Options Template in 436 Section 6.1, that defines the properties of the 437 Anonymization applied to a single Information Element within 438 a single Template or Options Template. 440 Anonymized Data Record 442 A Data Record within a Data Set containing at least one 443 Information Element with Anonymized values. The Information 444 Element(s) within the Template or Options Template 445 describing this Data Record SHOULD have a corresponding 446 Anonymization Record. 448 3. Specifications 450 This section describes the IPFIX specifications for Mediation: 451 more specifically, specifications for generic Intermediate 452 Processes. Possible specific Intermediate Processes are: 453 Intermediate Conversion Process, Intermediate Aggregation 454 Process, Intermediate Correlation Process, Intermediate 455 Selection Process, Intermediate Anonymization Process. 457 For a specific Intermediate Process, the specifications in the 458 following references MUST be followed, on top of the 459 specifications in this document: 461 - For the Intermediate Aggregation Process, the 462 specifications in [IPFIX-MED-AGGR] MUST be followed. 464 - For the Intermediate Selection Process, the specifications 465 in [IPFIX-MED-FLOWSEL] MUST be followed. 467 - For the Intermediate Anonymization Process, the 468 specifications in [RFC6235] should be considered as 469 guidelines as [RFC6235] is an experimental RFC. 471 Note that no specific document deals with the Intermediate 472 Conversion Process at the time of this publication. 474 These new specifications, which are more specific compared than 475 [RFC5101bis], are described with the key words described in 476 [RFC2119]. 478 3.1. Encoding of IPFIX Message Header 480 The format of the IPFIX Message Header is shown in Figure A. 481 Note that the format is similar to the IPFIX Message in 482 [RFC5101bis], but some field definitions (for the example, the 483 Export Time) have been updated in the context of the IPFIX 484 Mediator. 486 0 1 2 3 487 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 488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 489 | Version Number | Length | 490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 491 | Export Time | 492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 493 | Sequence Number | 494 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 495 | Observation Domain ID | 496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 498 Figure A: IPFIX Message Header format 500 Message Header Field Descriptions 502 Version 504 Version of Flow Record format exported in this message. 505 The value of this field is 0x000a for the current 506 version, incrementing by one the version used in the 507 NetFlow services export version 9 [RFC3954]. 509 Length 511 Total length of the IPFIX Message, measured in octets, 512 including Message Header and Set(s). 514 Export Time 516 Time at which the IPFIX Message Header leaves the 517 Mediator, expressed in seconds since the UNIX epoch of 518 1 January 1970 at 00:00 UTC, encoded as an unsigned 32- 519 bit integer. 521 Sequence Number 523 Incremental sequence counter modulo 2^32 of all IPFIX 524 Data Records sent on this PR-SCTP stream from the 525 current Observation Domain by the Exporting Process. 526 Check the specific meaning of this field in the sub- 527 sections of section 10 when UDP or TCP is selected as 528 the transport protocol. This value SHOULD be used by 529 the Collecting Process to identify whether any IPFIX 530 Data Records have been missed. Template and Options 531 Template Records do not increase the Sequence Number. 532 RFC'S EDITOR: section 10 referred to RFC5101. Now it 533 must be aligned with RFC5101bis 535 Observation Domain ID 537 A 32-bit identifier of the Observation Domain that is 538 locally unique to the Exporting Process. The Exporting 539 Process uses the Observation Domain ID to uniquely 540 identify to the Collecting Process the Observation 541 Domain that metered the Flows. It is RECOMMENDED that 542 this identifier is also unique per IPFIX 543 Device. Collecting Processes SHOULD use the Transport 544 Session and the Observation Domain ID field to separate 545 different export streams originating from the same 546 Exporting Process. The Observation Domain ID SHOULD be 547 0 when no specific Observation Domain ID is relevant for 548 the entire IPFIX Message. For example, when exporting 549 the Exporting Process Statistics, or in case of 550 hierarchy of Collector when aggregated Data Records are 551 exported. 552 Note: the Observation Domain Management is discussed in 553 section 3.4.1. 555 3.2. Template Management 557 3.2.1. Template Management Without Template Records Change 559 The first case is a situation where the IPFIX Mediator doesn't 560 modify the (Options) Template Record(s) content. A typical 561 example is an Intermediate Selection Process acting as 562 distributor, which collects Flow Records from one or more 563 Exporters, and based on the Information Elements content, 564 redirects the Flow Records to the appropriate Collector. This 565 example is a typical case of a single network operation center 566 managing multiple universities: an unique IPFIX Collector 567 collects all Flow Records for the common infrastructure, but 568 might be re-exporting specific university Flow Records to the 569 responsible system administrator. 571 As specified in [RFC5101bis], the Template IDs are unique per 572 Exporter, per Transport Session, and per Observation Domain. As 573 there is no guarantee that, for similar Template Records, the 574 Template IDs received on the incoming Transport Session and 575 exported to the outgoing Transport Session would be same, the 576 IPFIX Mediator MUST maintain a Template Mapping composed of 577 related received and exported (Options) Template Records: 579 - for each received (Options) Template Record: Template 580 Record Flow Keys and non Flow Keys, Template ID, 581 Observation Domain Id, and Transport Session Information 583 - for each exported (Options) Template Record: Template 584 Record Flow Keys and non Flow Keys, Template ID, Collector, 585 Observation Domain Id, and Transport Session Information 587 If an IPFIX Mediator receives an IPFIX Withdrawal Message for a 588 (Options) Template Record that is not used anymore in any other 589 Template Mappings, the IPFIX Mediator SHOULD export the 590 appropriate IPFIX Withdrawal Message(s) on the outgoing 591 Transport Session, and remove the corresponding entry in the 592 Template Mapping. 594 If a (Options) Template Record is not used anymore in an 595 outgoing Transport Session, it MUST be withdrawn with an IPFIX 596 Template Withdrawal Message on that specific outgoing Transport 597 Session, and its entry MUST be removed from the Template 598 Mapping. 600 If an incoming or outgoing Transport Session is gracefully 601 shutdown or reset, the (Options) Template Records corresponding 602 to that Transport Session MUST be removed from the Template 603 Mapping. 605 For example, Figure B displays an example of an Intermediate 606 Selection Process, re-distributing Data Records to Collectors on 607 the basis of customer networks, i.e. the Route Distinguisher 608 (RD). In this example, the Template Record received from the 609 Exporter#1 is reused towards Collector#1, Collector#2, and 610 Collector#3. 612 Templ. .---------. 613 ID 256 | | 614 .---->|Collector|<==>Customer 615 | |#1 | #A 616 | | | 617 RD=100:1 '---------' 618 .---------.Templ. .---------. | 619 | |Id | |----' .---------. 620 | |258 | | RD=100:2 | | 621 |IPFIX |------->|IPFIX |--------->|Collector|<==>Customer 622 |Exporter | |Mediator | Templ. |#2 | #B 623 |#1 | | | ID 257 | | 624 | | | |----. '---------' 625 '---------' '---------' | 626 RD=100:3 627 Templ.| .---------. 628 ID | | | 629 257 '---->|Collector|<==>Customer 630 |#3 | #C 631 | | 632 '---------' 634 Figure B: Intermediate Aggregation Process Example 636 The following table shows the Template Mapping for the system 637 shown in Figure B. 639 Template Entry A: 640 Incoming Transport Session Information (from Exporter#1): 641 Source IP: 642 Destination IP: 643 Protocol: SCTP 644 Source Port: 645 Destination Port: 4739 (IPFIX) 646 Observation Domain Id: 647 Template Id: 258 648 Flow Keys: 649 Non Flow Keys: 651 Template Entry B: 652 Outgoing Transport Session Information (to Collector#1): 653 Source IP: 654 Destination IP: 655 Protocol: SCTP 656 Source Port: 657 Destination Port: 4739 (IPFIX) 658 Observation Domain Id: 659 Template Id: 256 660 Flow Keys: 661 Non Flow Keys: 663 Template Entry C: 664 Outgoing Transport Session Information (to Collector#2): 665 Source IP: 666 Destination IP: 667 Protocol: SCTP 668 Source Port: 669 Destination Port: 4739 (IPFIX) 670 Observation Domain Id: 671 Template Id: 257 672 Flow Keys: 673 Non Flow Keys: 675 Template Entry D: 676 Outgoing Transport Session Information (to Collector#3): 677 Source IP: 678 Destination IP: 679 Protocol: SCTP 680 Source Port: 681 Destination Port: 4739 (IPFIX) 682 Observation Domain Id: 683 Template Id: 257 684 Flow Keys: 685 Non Flow Keys: 687 The Template Mapping corresponding to figure B can be displayed 688 as: 690 Template Entry A <----> Template Entry B 691 Template Entry A <----> Template Entry C 692 Template Entry A <----> Template Entry D 694 Alternatively, the Template Mapping may be optimized as: 696 +--> Template Entry B 697 | 698 Template Entry A <--+--> Template Entry C 699 | 700 +--> Template Entry D 702 Note that all examples use Transport Sessions based on the SCTP 703 protocol, as simplified use cases. However, the protocol would 704 be important in situations such as an Intermediate Conversion 705 Process doing transport protocol conversion. 707 3.2.2. Template Management With New Template Records 709 The second case is a situation where the IPFIX Mediator 710 generates new (Options) Template Records as a result of the 711 Intermediate Process. 713 In such a situation, the IPFIX Mediator doesn't need to maintain 714 a Template Mapping, as it generates its own series of (Options) 715 Template Records. However, the following special case might 716 still require a Template Mapping, i.e. a situation where the 717 IPFIX Mediator, typically containing an Intermediate Conversion 718 Process, Intermediate Aggregation Process [IPFIX-MED-AGGR], or 719 Intermediate Anonymization Process in case of black-marker 720 Anonymization [RFC6235], generates new (Options) Template 721 Records based on what it receives from the Exporter(s), and 722 based on the Intermediate Process function. In such a case, 723 it's interesting to keep the correlation between the received 724 (Options) Template Records and exported Derived (Options) 725 Template Records in the Template Mapping. 727 Therefore, the IPFIX Mediator MAY maintain a Template Mapping 728 composed of received (Options) Template Records and exported 729 derived Options) Template Records: 731 - for each received (Options) Template Record: Template 732 Record Flow Keys and non Flow Keys, Template ID, 733 Observation Domain, and Transport Session Information 735 - for each exported derived Options) Template Record: 736 Template Record Flow Keys and non Flow Keys, Template ID, 737 Collector, Observation Domain, and Transport Session 738 Information 740 If an IPFIX Mediator receives an IPFIX Withdrawal Message for a 741 (Options) Template Record that is not used anymore as the basis 742 of an inferred (Options) Template Record(s), the IPFIX Mediator 743 SHOULD export the appropriate IPFIX Withdrawal Message(s) for 744 the inferred (Options) Template Record on the outgoing Transport 745 Session, and remove the corresponding entry in the Template 746 Mapping. 748 The following two examples illustrate this. 750 First, consider an IPFIX Mediator hosting an Intermediate 751 Aggregation Process that generates time-series traffic octet 752 counts per source IP address (as in the example in section 8.1 753 of [IPFIX-MED-AGGR]). Here, the Intermediate Process accepts 754 Flow Records fitting any Template, discards all Information 755 Elements other than the sourceIPv[46]Address and 756 octetDeltaCount, aggregates these across all Original Exporters 757 in a given regular time interval, and exports Flow Records 758 according to a Template Record containing 759 flowStartTimeMilliseconds, flowEndTimeMilliseconds, 760 sourceIPv[46]Address, and octetDeltaCount. 762 In this case, no Template Mapping is necessary. New Templates 763 and Template Withdrawals in the Transport Sessions from the 764 Original Exporters are handled as they would be at any 765 Collecting Process. Records according to Templates which do not 766 contain at least a timestamp, sourceIPv[46]Address, and 767 octetDeltaCount IE are simply discarded by the Collector. 769 Next, consider a more generic case of this Intermediate 770 Aggregation Process, which creates time-series aggregates across 771 all Original Exporters, imposing a time interval but keeping a 772 subset of the incoming Flow Key received from the Original 773 Exporter. In this case, a Template Mapping is necessary, as 774 there is a relationship between incoming and outgoing Templates. 776 .--------. tid 256 777 |IPFIX | 778 |Exporter|----+ 779 |#1 | | 780 '--------' | 781 .--------. | .----------. .---------. 782 |IPFIX | '--------->| | | | 783 |Exporter|-------------->|IPFIX |------------->|IPFIX | 784 |#2 | tid 257 |Mediator |tid 256 |Collector| 785 '--------' +--------->| | 257 | | 786 .--------. | '----------' '---------' 787 |IPFIX | | 788 |Exporter|----' 789 |#3 | tid 257 790 '--------' 792 Figure C: Intermediate Aggregation Process Example 794 In Figure C, above, the Mediator accepts a Template Record 795 containing only the sourceIPv4Address as the Flow Key from 796 Exporters 1 and 2, and a Template Record containing only the 797 destinationIPv4Address as the Flow Key from exporter 3. It 798 exports time-series source aggregates as Template ID 256, and 799 time-series destination aggregates as Template ID 257. The 800 Template Entries in this case are as follows: 802 Template Entry A: 803 Incoming Transport Session Information (from Exporter#1): 804 Source IP: 805 Destination IP: 806 Protocol: SCTP 807 Source Port: 808 Destination Port: 4739 (IPFIX) 809 Observation Domain Id: 810 Template Id: 256 811 Flow Keys: sourceIPv4Address 812 Non Flow Keys: octetDeltaCount, [others] 814 Template Entry B: 815 Incoming Transport Session Information (from Exporter#2): 816 Source IP: 817 Destination IP: 818 Protocol: SCTP 819 Source Port: 820 Destination Port: 4739 (IPFIX) 821 Observation Domain Id: 822 Template Id: 257 823 Flow Keys: sourceIPv4Address 824 Non Flow Keys: octetDeltaCount, [others] 826 Template Entry C: 827 Incoming Transport Session Information (from Exporter#3): 828 Source IP: 829 Destination IP: 830 Protocol: SCTP 831 Source Port: 832 Destination Port: 4739 (IPFIX) 833 Observation Domain Id: 834 Template Id: 257 835 Flow Keys: destinationIPv4Address 836 Non Flow Keys: octetDeltaCount, [others] 838 Template Entry D: 839 Outgoing Transport Session Information (to IPFIX Collector): 840 Source IP: 841 Destination IP: 842 Protocol: SCTP 843 Source Port: 844 Destination Port: 4739 (IPFIX) 845 Observation Domain Id: 846 Template Id: 256 847 Flow Keys: sourceIPv4Address 848 Non Flow Keys: octetDeltaCount 850 Template Entry E: 851 Outgoing Transport Session Information (to IPFIX Collector): 852 Source IP: 853 Destination IP: 854 Protocol: SCTP 855 Source Port: 856 Destination Port: 4739 (IPFIX) 857 Observation Domain Id: 858 Template Id: 257 859 Flow Keys: destinationIPv4Address 860 Non Flow Keys: octetDeltaCount 862 The Template Mapping corresponding to figure C can be displayed 863 as: 865 Template Entry A <----> Template Entry D 866 Template Entry B <----> Template Entry D 867 Template Entry C <----> Template Entry E 869 Note that all examples use Transport Sessions based on the SCTP 870 protocol, as simplified use cases. However, the protocol would 871 be important in situations such as an Intermediate Conversion 872 Process doing transport protocol conversion. 874 3.3. Time Management 876 The IPFIX Message Header "Export Time" field is the time in 877 seconds since 0000 UTC Jan 1, 1970, at which the IPFIX Message 878 leaves the IPFIX Mediator. However, in the specific case of an 879 IPFIX Mediator containing an Intermediate Conversion Process, 880 the IPFIX Mediator MAY keep the export time received from the 881 incoming Transport Session. 883 It is RECOMMENDED that Mediators handle time using absolute 884 timestamps (e.g. flowStartSeconds, flowStartMilliseconds, 885 flowStartNanoseconds), which are specified relative to the UNIX 886 epoch (00:00 UTC 1 Jan 1970), where possible, rather than 887 relative timestamps (e.g. flowStartSysUpTime, 888 flowStartDeltaMicroseconds), which are specified relative to 889 protocol structures such as system initialization or message 890 export time. 892 The latter are difficult to manage for two reasons. First, 893 they require constant translation, as the system 894 initialization time of an intermediate system and the export 895 time of an intermediate message will change across mediation 896 operations. Further, relative timestamps introduce range 897 problems. For example, when using the 898 flowStartDeltaMicroseconds and flowEndDeltaMicroseconds 899 Information Elements [RFC5102], the Data Record must be 900 exported within a maximum of 71 minutes after its creation. 901 Otherwise, the 32-bit counter would not be sufficient to 902 contain the flow start time offset. Those time constraints 903 might be incompatible with some of the Intermediate Processes: 904 Intermediate Aggregation Process (temporal) and Intermediate 905 Correlation Process, for example. 907 When an Intermediate Aggregation Process aggregates information 908 from different Flow Records, the typical reporting times SHOULD 909 be the minimum of the start times and the maximum of the end 910 times. However, if the Flow Records do not overlap, i.e. if 911 there is a time gap between the times in the Flow Records, then 912 the report may be inaccurate. The IPFIX Mediator is only 913 reporting what it knows, on the basis of the information made 914 available to it - and there may not have been any data to 915 observe during the gap. Then again, if there is an overlap in 916 timestamps, there's the potential of double-accounting: 918 different Observation Points may have observed the same traffic 919 simultaneously. Therefore, as there is not a single rule that 920 fits all different situations, a complete specification of the 921 precise rules of applying Flow Record timestamps at IPFIX 922 Mediators is out of the scope of this document. 924 Note that [IPFIX-MED-AGGR] provides additional specifications 925 for handling of timestamps at an Intermediate Aggregation 926 Process. 928 3.4. Observation Point Management 930 Depending on the use case, the Collector in an Exporter- 931 Mediator-Collector structure model may need to receive the 932 Original Observation Point(s), otherwise it may wrongly conclude 933 that the IPFIX Device exporting the Flow Records to him, i.e. 934 the IPFIX Mediator, directly observed the packets that generated 935 the Flow Records. Two new Information Elements are introduced 936 to solve this use case: originalExporterIPv4Address and 937 originalExporterIPv6Address. Practically, the Original 938 Exporters will not exporting these Information Elements. 939 Therefore, the Intermediate Process SHOULD report the Original 940 Observation Point(s) to the best of its knowledge. Note that 941 the Configuration Data Model for IPFIX and PSAMP [IPFIX-CONF] 942 may help. 944 In the IPFIX Mediator, the Observation Point(s) may be 945 represented by: 946 - A single Original Exporter (represented by the 947 originalExporterIPv4Address or originalExporterIPv6Address 948 Information Elements) 949 - A list of Original Exporter (represented by the 950 originalExporterIPv4Address or originalExporterIPv6Address 951 Information Elements) 952 - Any combination or list of Information Elements 953 representing Observation Points. For example: 954 o A list of Original Exporter interface(s) 955 (represented by the originalExporterIPv4Address or 956 originalExporterIPv6Address, the ingressInterface 957 and/or egressInterface Information Elements, 958 respectively) 959 o A list of Original Exporter line card (represented 960 by the originalExporterIPv4Address or 961 originalExporterIPv6Address, the lineCardId Information 962 Elements, respectively) 964 Some Information Elements characterizing the Observation Point 965 may be added. For example, the flowDirection Information 966 Element specifies the direction of the observation, and, as 967 such, characterizes the Observation Point. 969 Any combination of the above examples is possible. For example, 970 in case of an Intermediate Aggregation Process, an Original 971 Observation Point can be composed of: 972 exporterIPv4Address 192.0.2.1 973 exporterIPv4Address 192.0.2.2, 974 interface ethernet 0, direction ingress 975 interface ethernet 1, direction ingress 976 interface serial 1, direction egress 977 interface serial 2, direction egress 978 exporterIPv4Address 192.0.2.3, 979 lineCardId 1, direction ingress 981 If the Original Observation Point is composed of a list, then 982 the IPFIX Structured Data [RFC6313] MUST be used to export it 983 from the IPFIX Mediator. 985 The most generic way to export the Original Observation Point is 986 to use a subTemplateMultiList, with the semantic "exactlyOneOf". 987 Taking the previous example, the following encoding can be used: 989 Template Record 257: exporterIPv4Address 990 Template Record 258: exporterIPv4Address, basicList of 991 ingressInterface, flowDirection 992 Template Record 259: exporterIPv4Address, lineCardId, 993 flowDirection 995 The Original Observation Point is modeled with the Data Records 996 corresponding to either Template Record 1, Template Record 2, or 997 Template Record 3 but not more than one of these ("exactlyOneOf" 998 semantic). This implies that the Flow was observed at exactly 999 one of the Observation Points reported. 1001 When an IPFIX Mediator receives Flow Records containing the 1002 Original Observation Point Information Element, i.e. 1003 originalExporterIPv6Address or originalExporterIPv4Address, the 1004 IPFIX Mediator SHOULD NOT modify its value(s) when composing new 1005 Flow Records in the general case. Known exceptions include 1006 anonymization per [RFC6235] section 7.2.4 and an Intermediate 1007 Correlation Process rewriting addresses across NAT. In other 1008 words, the Original Observation Point should not be replaced the 1009 IPFIX Mediator Observation Point. The daisy chain of (Exporter, 1010 Observation Point) representing the path the Flow Records took 1011 from the Exporter to the top Collector in the Exporter- 1012 Mediator(s)-Collector structure model is out of the scope of 1013 this specification. 1015 3.4.1. Observation Domain Management 1017 In any case, the Observation Domain ID of any IPFIX Message 1018 containing Flow Records relevant to no particular Observation 1019 Domain, or to multiple Observation Domains, MUST have an 1020 Observation Domain ID of 0, as in section 3.1 above, and section 1021 3.1 of [RFC5101bis]. 1023 IPFIX Mediators that do not change (Options) Template Records 1024 MUST maintain a Template Mapping, as detailed in section 3.2.1, 1025 to ensure that the combination of Observation Domain IDs and 1026 Template IDs do not collide on export. 1028 For IPFIX Mediators that export New (Options) Template Records 1029 unchanged, as in section 3.2.2, there are two options for 1030 Observation Domain ID management. The first and simplest of 1031 these is to completely decouple exported Observation Domain IDs 1032 from received Observation Domain IDs; the IPFIX Mediator, in 1033 this case, comprises its own set of Observation Domain(s) 1034 independent of the Observation Domain(s) of the Original 1035 Exporters. 1037 The second option is to provide or maintain a Template Mapping 1038 for received (Options) Template Records and exported inferred 1039 (Options) Template Records, along with the appropriate 1040 Observation Domain IDs per Transport Session, which ensures that 1041 the combination of Observation Domain IDs and Template IDs do 1042 not collide on export. 1044 In some cases where the IPFIX Message Header can't contain a 1045 consistent Observation Domain for the entire IPFIX Message, but 1046 the Flow Records exported from the IPFIX Mediator should anyway 1047 contain the Observation Domain of the Original Exporter, the 1048 (Options) Template Record must contain the 1049 originalObservationDomainId Information Element. When an IPFIX 1050 Mediator receives Flow Records containing the 1051 originalObservationDomainId Information Element, the IPFIX 1052 Mediator MUST NOT modify its value(s) when composing new Flow 1053 Records with the originalObservationDomainId Information 1054 Element. 1056 3.5. Specific Reporting Requirements 1058 Some specific Options Templates and Options Template Records are 1059 necessary to provide extra information about the Flow Records 1060 and about the Metering Process. 1062 The Options Template Records defined in these subsections, which 1063 impose some constraints on the Metering Process and Exporting 1064 Process implementations in Intermediate Processes, MAY be 1065 implemented. If implemented, the specific Option Templates 1066 SHOULD be implemented as specified in these subsections. 1068 The minimum set of Information Elements is always specified in 1069 these specific IPFIX Options Templates. Nevertheless, extra 1070 Information Elements may be used in these specific Options 1071 Templates. 1073 3.5.1. The Flow Keys Options Template 1075 Exactly like the IPFIX protocol [RFC5101bis], the Flow Keys 1076 Option Template specifies the structure of a Data Record for 1077 reporting the Flow Keys of reported Flows. A Flow Keys Data 1078 Record extends a particular Template Record that is referenced 1079 by its templateId identifier. The Template Record is extended 1080 by specifying which of the Information Elements contained in the 1081 corresponding Data Records describe Flow properties that serve 1082 as Flow Keys of the reported Flow. 1084 The Flow Keys Option Template SHOULD contain the following 1085 Information Elements that are defined in [RFC5102] 1087 templateId An identifier of a Template. This 1088 Information Element MUST be defined 1089 as a Scope Field. 1091 flowKeyIndicator Bitmap with the positions of the Flow 1092 Keys in the Data Records. 1093 When any Intermediate Process changes the Flow Keys, the Flow 1094 Keys Option Template MUST include the new set of Flow Keys. 1095 Typically, an Intermediate Aggregation Process keeps or reduces 1096 the number of Flow Keys. However, the number of Flow Keys may 1097 increase when the Original Exporter or/and Original Observation 1098 Point is/are added. 1100 3.5.2. IPFIX Protocol Options Template 1102 The "Metering Process Statistics Options Template", "The 1103 Metering Process Reliability Statistics Options Template", and 1104 "The Exporting Process Reliability Statistics Options Template", 1105 as specified in [RFC5101bis], SHOULD be implemented on the IPFIX 1106 Mediator. 1108 Refer to the document specifying a particular Intermediate 1109 Process type for specific values for these Options Template 1110 Records. For example, in case of an Intermediate Aggregation 1111 Process, [IPFIX-MED-AGGR] specifies which values to insert into 1112 the fields of "Metering Process Statistics Options Template", 1113 "The Metering Process Reliability Statistics Options Template", 1114 and "The Exporting Process Reliability Statistics Options 1115 Template" 1117 3.5.3. IPFIX Mediator Options Template 1119 There is no need for a specific Options Template for the IPFIX 1120 Mediator; instead, each Intermediate Process type requires some 1121 particular metadata. For example, a specification of IPFIX flow 1122 Anonymization including an Options Template for the export of 1123 metadata about Anonymized flows is described in [RFC6235]; when 1124 Anonymizing Flows Records, IPFIX Mediators SHOULD add the 1125 Options Template specified therein to annotate the exported 1126 data. 1128 Transport Session Management SCTP [RFC4960] using the PR-SCTP 1129 extension specified in [RFC3758] MUST be implemented by all 1130 compliant IPFIX Mediator implementations. UDP [RFC768] MAY also 1131 be implemented by compliant IPFIX Mediator implementations. TCP 1132 [RFC793] MAY also be implemented by IPFIX Mediator compliant 1133 implementations. 1135 PR-SCTP SHOULD be used in deployments where IPFIX Mediators and 1136 Collectors are communicating over links that are susceptible to 1137 congestion. PR-SCTP is capable of providing any required degree 1138 of reliability. 1140 TCP MAY be used in deployments where IPFIX Mediators and 1141 Collectors communicate over links that are susceptible to 1142 congestion, but PR-SCTP is preferred due to its ability to limit 1143 back pressure on Exporters and its message versus stream 1144 orientation. 1146 UDP MAY be used, although it is not a congestion-aware protocol. 1147 However, in this case, the IPFIX traffic between IPFIX Mediator 1148 and Collector MUST run in an environment where IPFIX traffic has 1149 been provisioned for, or is contained through some other means. 1151 3.6. The Collecting Process's Side 1153 An IPFIX Mediator produces IPFIX Messages understandable by a 1154 IPFIX-compliant Collector, with the additional specifications in 1155 IPFIX Structured Data [RFC6313]. 1157 Therefore the Collecting Process on the top Collector MUST 1158 support the IPFIX protocol [RFC5101bis] and the IPFIX Structured 1159 Data [RFC6313]. 1161 3.7. Configuration Management 1163 In some cases such as an Intermediate Aggregation Process 1164 aggregating Flow Records from multiple Original Exporters, a 1165 consistent configuration of the Metering Processes and Exporting 1166 Processes on these Original Exporters offers some advantages. 1167 For example, consistent active timeout, inactive timeout, and/or 1168 consistent export time allows the number of the Flow Records per 1169 period of time to be compared. For example, consistent Sampling 1170 algorithm and parameters might allow Flow Records accuracy to be 1171 compared. 1173 While this is tempting to include all configuration parameters 1174 in Flow Records for the IPFIX Mediator to draw its own 1175 conclusion, the consistency of the configuration should be 1176 verified out of band, with the MIB modules ([RFC5815bis] and 1177 [PSAMP-MIB]) or with the Configuration Data Model for IPFIX and 1178 PSAMP [IPFIX-CONF] 1180 4. New Information Elements 1182 Three new Information Elements are requested in this 1183 specifications: originalExporterIPv4Address, 1184 originalExporterIPv6Address, and originalObservationDomainId. 1185 See Section 6.1. , Section 6.2. , and Section 6.3. , 1186 respectively, for the formal definitions. 1188 5. Security Considerations 1190 The same security considerations as for the IPFIX Protocol 1191 [RFC5101bis] apply. 1193 As they act as both IPFIX Collecting Processes and Exporting 1194 Processes, the Security Considerations for IPFIX Protocol 1195 [RFC5101bis] also apply to Mediators. The Security 1196 Considerations for IPFIX Files [RFC5655] also apply to IPFIX 1197 Mediators that write IPFIX Files or use them for internal 1198 storage. However, there are a few specific considerations that 1199 IPFIX Mediator implementations must also take into account. 1201 By design, IPFIX Mediators are "men-in-the-middle": they 1202 intercede in the communication between an Original Exporter (or 1203 another upstream Mediator) and a downstream Collecting Process. 1204 This has two important implications for the level of 1205 confidentiality provided across an IPFIX Mediator, and the 1206 ability to protect data integrity and Original Exporter 1207 authenticity across a Mediator. These are addressed in more 1208 detail in the Security Considerations for Mediators in [IPFIX- 1209 MED-FMWK]. 1211 Note that, while Mediators can use the exporterCertificate and 1212 collectorCertificate Information Elements defined in [RFC5655] 1213 as described in section 9.3 of [IPFIX-MED-FMWK] to export 1214 information about X.509 identities in upstream TLS-protected 1215 Transport Sessions, this mechanism cannot be used to provide 1216 true end-to-end assertions about a chain of IPFIX Mediators: any 1217 Mediator in the chain can simply falsify the information about 1218 upstream Transport Sessions In situations where information 1219 about the chain of mediation is important, it must be determined 1220 out of band. 1222 6. IANA Considerations 1224 This document specifies three new IPFIX Information Elements: the 1225 applicationDescription, applicationTag and the applicationName. 1227 New Information Elements to be added to the IPFIX Information 1228 Element registry at [IANA-IPFIX] are listed below. 1230 XML specifications of these elements can be found in Appendix A. 1232 EDITOR'S NOTE: please change the TBD1, TBD2, and TBD3, with the 1233 IANA newly assigned numbers. Note that the XML specification in 1234 Appendix A must also be updated with the elementId values 1235 allocated. 1237 6.1. originalExporterIPv4Address 1239 Name: originalExporterIPv4Address 1240 Description: 1241 The IPv4 address used by the Exporting Process on the Original 1242 Exporter. This is used by an IPFIX Mediator Exporting Process 1243 to identify the Original Exporter. 1244 Abstract Data Type: ipv4Address 1245 Data Type Semantics: identifier 1246 ElementId: TBD1 1247 Status: current 1249 6.2. originalExporterIPv6Address 1251 Name: originalExporterIPv6Address 1252 Description: 1253 The IPv6 address used by the Exporting Process on the Original 1254 Exporter. This is used by the IPFIX Mediator Exporting Process 1255 to identify the Original Exporter. 1256 Abstract Data Type: ipv6Address 1257 Data Type Semantics: identifier 1258 ElementId: TBD2 1259 Status: current 1261 6.3. originalObservationDomainId 1263 Name: originalObservationDomainId 1264 Description: 1265 An identifier of the Observation Domain on the Original 1266 Exporter, where the metered IP packets are observed. This is 1267 used by the IPFIX Mediator Exporting Process to identify an 1268 Observation Domain as received from the Original Exporter. 1269 Abstract Data Type: unsigned32 1270 Data Type Semantics: identifier 1271 ElementId: TBD3 1272 Status: current 1273 7. References 1275 7.1. Normative References 1277 [RFC2119] S. Bradner, Key words for use in RFCs to Indicate 1278 Requirement Levels, BCP 14, RFC 2119, March 1997 1280 [RFC3758] Stewart, R., Ramalho, M, Xie, Q., Tuexen, M., and P. 1281 Conrad, "Stream Control Transmission Protocol (SCTP), 1282 Partial Reliability Extension", May 2004 1284 [RFC4960] Stewart, R., Ed., "Stream Control Transmission 1285 Protocol", RFC 4960, September 2007. 1287 [RFC5102] Quittek, J., Bryant, S., Claise, B., Aitken, P., and 1288 J. Meyer, "Information Model for IP Flow Information 1289 Export", RFC 5102, January 2008. 1291 [RFC5655] Trammell, B., Boschi, E., Mark, L., Zseby, T., and A. 1292 Wagner, "Specification of the IP Flow Information 1293 Export (IPFIX) File Format", RFC 5655, October 2009. 1295 [RFC6313] Claise, B., Dhandapani, G., Aitken, P., and S. Yates, 1296 "Export of Structured Data in IP Flow Information 1297 Export (IPFIX)", RFC6313, July 2011. 1299 [IPFIX-MED-FLOWSEL] D'antonio, S., Zseby, T., Henke, C. and L. 1300 Peluso, "Flow Selection Techniques", draft-ietf-ipfix- 1301 flow-selection-tech-09.txt, Internet-Draft work in 1302 progress, November 2011. 1304 [IPFIX-MED-AGGR] Trammell, B., Boschi, E., A. Wagner, and B. 1305 Claise, "Exporting Aggregated Flow Data using the IP 1306 Flow Information Export (IPFIX) Protocol", draft- 1307 trammell-ipfix-a9n-03.txt, Internet-Draft work in 1308 progress, June 2011. 1310 [PSAMP-MIB] Dietz, T., Claise, B., and J. Quittek "Definitions 1311 of Managed Objects for Packet Sampling", draft-ietf- 1312 ipfix-psamp-mib-04.txt, Internet-Draft work in 1313 progress, October 2011. 1315 [IPFIX-CONF] Muenz, G., Claise, B., and P. Aitken "Configuration 1316 Data Model for IPFIX and PSAMP", draft-ietf-ipfix- 1317 configuration-model-10, Internet-Draft work in 1318 progress, July 2011. 1320 [RFC5101bis] Claise, B., and B. Trammell, "Specification of the 1321 IP Flow Information eXport (IPFIX) Protocol for the 1322 Exchange of IP Traffic Flow Information", draft-ietf- 1323 ipfix-protocol-rfc5101bis-00, Work in Progress, 1324 November 2011. 1326 [RFC5815bis] Dietz, T., Kobayashi, A., Claise, B., and G. Muenz, 1327 "Definitions of Managed Objects for IP Flow Information 1328 Export", draft-ietf-ipfix-rfc5815bis-00.txt, Work in 1329 Progress, April 2010. 1331 7.2. Informative References 1333 [RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 1334 August 1980. 1336 [RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 1337 793, September 1981. 1339 [RFC3917] Quittek, J., Zseby, T., Claise, B., and S. Zander, 1340 "Requirements for IP Flow Information Export", RFC 1341 3917, October 2004 1343 [RFC3954] Claise, B. (Ed), "Cisco Systems NetFlow Services 1344 Export Version 9", RFC 3954, October 2004 1346 [RFC5470] Sadasivan, G., Brownlee, N., Claise, B., and J. 1347 Quittek, "Architecture Model for IP Flow Information 1348 Export", RFC5470, March 2009 1350 [RFC5472] Zseby, T., Boschi, E., Brownlee, N., and B. Claise, 1351 "IP Flow Information Export (IPFIX) Applicability", RFC 1352 5472, March 2009 1354 [RFC5476] Claise, B., Quittek, J., and A. Johnson, "Packet 1355 Sampling (PSAMP) Protocol Specifications", RFC 5476, 1356 March 2009. 1358 [RFC5982] Kobayashi, A. (Ed), Claise, B. (Ed), "P Flow 1359 Information Export (IPFIX) Mediation: Problem 1360 Statement", RFC 5982, August 2010. 1362 [IPFIX-MED-FMWK] Kobayashi, A., Claise, B., Muenz, G., and K. 1363 Ishibashi, "IPFIX Mediation: Framework", RFC 6183, 1364 April 2011. 1366 [RFC6235] Boschi, E., Trammell, B. "IP Flow Anonymization 1367 Support", RFC 6235, May 2011. 1369 [IANA-IPFIX] http://www.iana.org/assignments/ipfix/ipfix.xhtml 1371 Acknowledgments 1373 We would like to thank the IPFIX contributors and specifically 1374 Paul Aitken for his thorough review. 1376 8. Author's Addresses 1378 Benoit Claise 1379 Cisco Systems, Inc. 1380 De Kleetlaan 6a b1 1381 Diegem 1813 1382 Belgium 1384 Phone: +32 2 704 5622 1385 Email: bclaise@cisco.com 1387 Atsushi Kobayashi 1388 NTT Information Sharing Platform Laboratories 1389 3-9-11 Midori-cho 1390 Musashino-shi, Tokyo 180-8585 1391 Japan 1393 Phone: +81-422-59-3978 1394 Email: akoba@nttv6.net 1395 URI: http://www3.plala.or.jp/akoba/ 1397 Brian Trammell 1398 ETH Zurich 1399 Gloriastrasse 35 1400 8092 Zurich 1401 Switzerland 1403 Phone: +41 44 632 70 13 1404 EMail: trammell@tik.ee.ethz.ch 1406 Appendix A. Additions to XML Specification of IPFIX Information 1407 Elements 1409 This appendix contains additions to the machine-readable 1410 description of the IPFIX information model coded in XML in 1411 Appendix A and Appendix B in [RFC5102]. Note that this appendix 1412 is of informational nature, while the text in Section 6. 1413 (generated from this appendix) is normative. 1415 The following field definitions are appended to the IPFIX 1416 information model in Appendix A of [RFC5102]. 1418 1422 1423 1424 The IPv4 address used by the Exporting Process on the 1425 Original Exporter. This is used by an IPFIX Mediator 1426 Exporting Process to identify the Original Exporter. 1427 1428 1429 1431 1435 1436 1437 The IPv6 address used by the Exporting Process on the 1438 Original Exporter. This is used by the IPFIX Mediator 1439 Exporting Process to identify the Original Exporter. 1440 1441 1442 1444 1449 1450 1451 An identifier of the Observation Domain on the Original 1452 Exporter, where the metered IP packets are observed. 1453 This is used by the IPFIX Mediator Exporting Process to 1454 identify an Observation Domain as received from the 1455 Original Exporter. 1456 1457 1458