IP Flow Information Export WG G. Sadasivan (ipfix) Cisco Systems, Inc. Internet-Draft N. Brownlee Expires: July 5, 2005 CAIDA | The University of Auckland B. Claise Cisco Systems, Inc. J. Quittek NEC Europe Ltd. January 2005 Architecture for IP Flow Information Export draft-ietf-ipfix-architecture-06 Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she become aware will be disclosed, in accordance with RFC 3668. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on July 5, 2005. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This memo defines the IP Flow Information eXport (IPFIX) architecture Sadasivan, et al. Expires July 5, 2005 [Page 1] Internet-Draft IPFIX Architecture January 2005 for the selective monitoring of IP flows, and for the export of measured IP flow information from an IPFIX device to a collector, as per the requirements set out in the IPFIX requirements document. Table of Contents 1. Changes/Issues from the -05 Draft . . . . . . . . . . . . . 4 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1 Document Scope . . . . . . . . . . . . . . . . . . . . . . 4 2.2 IPFIX Documents Overview . . . . . . . . . . . . . . . . . 5 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Examples of Flows . . . . . . . . . . . . . . . . . . . . . 9 5. IPFIX Reference Model . . . . . . . . . . . . . . . . . . . 11 6. IPFIX Functional and Logical Blocks . . . . . . . . . . . . 12 6.1 Metering Process . . . . . . . . . . . . . . . . . . . . . 12 6.1.1 Flow Record Expiration . . . . . . . . . . . . . . . . 13 6.2 Observation Point . . . . . . . . . . . . . . . . . . . . 13 6.3 Selection Criteria for Packets . . . . . . . . . . . . . . 14 6.3.1 Sampling Functions, Si . . . . . . . . . . . . . . . . 14 6.3.2 Filter Functions, Fi . . . . . . . . . . . . . . . . . 15 6.4 Observation Domain . . . . . . . . . . . . . . . . . . . . 15 6.5 Exporting Process . . . . . . . . . . . . . . . . . . . . 15 6.6 Collecting Process . . . . . . . . . . . . . . . . . . . . 16 6.7 Summary . . . . . . . . . . . . . . . . . . . . . . . . . 16 7. Overview of the IPFIX Protocol . . . . . . . . . . . . . . . 18 7.1 Information Model Overview . . . . . . . . . . . . . . . . 18 7.2 Flow Records . . . . . . . . . . . . . . . . . . . . . . . 19 7.3 Control Information . . . . . . . . . . . . . . . . . . . 19 7.4 Reporting Responsibilities . . . . . . . . . . . . . . . . 20 8. IPFIX Protocol Details . . . . . . . . . . . . . . . . . . . 20 8.1 The IPFIX Basis Protocol . . . . . . . . . . . . . . . . . 20 8.2 IPFIX Protocol on the Collecting Process . . . . . . . . . 21 8.3 Support for Applications . . . . . . . . . . . . . . . . . 21 9. Export Models . . . . . . . . . . . . . . . . . . . . . . . 22 9.1 Export with Reliable Control Connection . . . . . . . . . 22 9.2 Collector Failure Detection and Recovery . . . . . . . . . 22 9.3 Collector Redundancy . . . . . . . . . . . . . . . . . . . 23 10. IPFIX Flow Collection in Special Situations . . . . . . . . 23 11. Security Considerations . . . . . . . . . . . . . . . . . . 24 11.1 Data Security . . . . . . . . . . . . . . . . . . . . . 24 11.1.1 Host-Based Security . . . . . . . . . . . . . . . . 25 11.1.2 Authentication-only . . . . . . . . . . . . . . . . 25 11.1.3 Encryption . . . . . . . . . . . . . . . . . . . . . 25 11.2 IPFIX End-point Authentication . . . . . . . . . . . . . 26 12. IPFIX Overload . . . . . . . . . . . . . . . . . . . . . . . 26 12.1 Denial of Service (DoS) Attack Prevention . . . . . . . 26 12.1.1 Network Under Attack . . . . . . . . . . . . . . . . 26 12.1.2 Generic DoS Attack on the IPFIX Device and Sadasivan, et al. Expires July 5, 2005 [Page 2] Internet-Draft IPFIX Architecture January 2005 Collector . . . . . . . . . . . . . . . . . . . . . 26 12.1.3 IPFIX Specific DoS Attack . . . . . . . . . . . . . 27 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . 27 13.1 Numbers used in the Protocol . . . . . . . . . . . . . . 27 13.2 Numbers used in the Information Model . . . . . . . . . 27 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 15.1 Normative References . . . . . . . . . . . . . . . . . . 28 15.2 Non-normative References . . . . . . . . . . . . . . . . 28 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 29 Intellectual Property and Copyright Statements . . . . . . . 30 Sadasivan, et al. Expires July 5, 2005 [Page 3] Internet-Draft IPFIX Architecture January 2005 1. Changes/Issues from the -05 Draft Flow Keys: Agreed that each field used in defining a flow is a Flow Key. A flow is therefore defined by a set of Flow Keys. Text changed to say 'set of Flow Keys' where neccessary. Special Traffic and Devices: These sections pointed out that IPFIX can be implemented in devices other than switches and routers, and that in such cases one needs a clear description of the information elements used in such devices. These two sections have been combined to produce a shorter description of 'IPFIX in Special Situations.' Editorial Changes: A few errors (from early sections of text) have been corrected so that they match the Protocol and Info Model drafts. Architecture issues: All the issues in draft-05 are now closed. 2. Introduction There are several applications e.g., usage-based accounting, traffic profiling, traffic engineering, attack/intrusion detection, QoS monitoring, that require flow-based IP traffic measurements. It is therefore important to have a standard way of exporting information related to IP flows. This document defines an architecture for IP traffic flow monitoring, measuring and exporting. It provides a high-level description of an IPFIX device's key components and their functions. 2.1 Document Scope This document defines the architecture for IPFIX. Its main objectives are to: o Describe the key IPFIX architectural components, consisting of (at least) IPFIX devices and collectors communicating using the IPFIX protocol. o Define the IPFIX architectural requirements, e.g., recovery, security, etc. Sadasivan, et al. Expires July 5, 2005 [Page 4] Internet-Draft IPFIX Architecture January 2005 o Describe the characteristics of the IPFIX protocol. Note that the IPFIX architecture does not provide for remote configuration of an IPFIX device. Instead, IPFIX devices are configured by other means. 2.2 IPFIX Documents Overview The IPFIX protocol provides network administrators with access to IP flow information. This document specifies the architecture for the export of measured IP flow information out of an IPFIX exporting process to a collecting process, per the requirements defined in IPFIX-REQS [1]. The IPFIX protocol document IPFIX-PROTO [3] specifies how IPFIX flow record data, options record data, and templates are carried via a congestion- aware transport protocol from IPFIX exporting process to IPFIX collecting process. IPFIX has a formal description of IPFIX information elements (fields), their name, type and additional semantic information, as specified in IPFIX-INFO [2]. Finally IPFIX-AS [4] describes what type of applications can use the IPFIX protocol and how they can use the information provided. It furthermore shows how the IPFIX framework relates to other architectures and frameworks. Note that the IPFIX system does not provide for remote configuration of an IPFIX device. Instead, IPFIX devices are configured by network operations staff. 3. Terminology The definitions of basic IPFIX terms such as IP Traffic Flow, Exporting Process, Collecting Process, Observation Point, etc. are semantically identical with those found in the IPFIX requirements document IPFIX-REQS [1]. Some of the terms have been expanded for more clarity when defining the protocol. Additional definitions required for the architecture have also been defined. For the same terms defined here and in IPFIX-PROTO [3] the definitions are equivalent in both documents. * Observation Point An Observation Point is a location in the network where IP packets can be observed. Examples include: a line to which a probe is attached, a shared medium, such as an Ethernet-based LAN, a single port of a router, or a set of interfaces (physical or logical) of a router. Sadasivan, et al. Expires July 5, 2005 [Page 5] Internet-Draft IPFIX Architecture January 2005 Note that one Observation Point may be a superset of several other Observation Points. For example one Observation Point can be an entire line card. That would be the superset of the individual Observation Points at the line card's interfaces. * Observation Domain An Observation Domain is the largest set of Observation Points for which Flow information can be aggregated by a Metering Process. Each Observation Domain presents itself using a unique ID to the Collecting Process to identify the IPFIX Messages it generates. For example, a router line card may be an observation domain if it is composed of several interfaces: each of which is an Observation Point. Every Observation Point is associated with an Observation Domain. * IP Traffic Flow or Flow There are several definitions of the term 'flow' being used by the Internet community. Within the context of IPFIX we use the following definition: A Flow is defined as a set of IP packets passing an Observation Point in the network during a certain time interval. All packets belonging to a particular Flow have a set of common properties. Each property is defined as the result of applying a function to the values of: 1. One or more packet header field (e.g. destination IP address), transport header field (e.g. destination port number), or application header field (e.g. RTP header fields [RFC1889]) 2. One or more characteristics of the packet itself (e.g. number of MPLS labels) 3. One or more fields derived from packet treatment (e.g. next hop IP address, output interface) A packet is said to belong to a Flow if it completely satisfies all the defined properties of the Flow. This definition covers the range from a Flow containing all packets observed at a network interface to a Flow consisting of just a single packet between two applications with a specific sequence number. Sadasivan, et al. Expires July 5, 2005 [Page 6] Internet-Draft IPFIX Architecture January 2005 * Flow Key Each of the fields which 1. Belong to the packet header (e.g. destination IP address) 2. Are a property of the packet itself (e.g. packet length) 3. Are derived from packet treatment (e.g. AS number) and which are used to define a Flow are termed Flow Keys. * Flow Record A Flow Record contains information about a specific Flow that was observed at an Observation Point. A Flow Record contains measured properties of the Flow (e.g. the total number of bytes for all the Flow's packets) and usually characteristic properties of the Flow (e.g. source IP address). * Metering Process A Metering Process generates Flow Records. Input to the process are packet headers observed at an Observation Point, and packet treatment at the Observation Point Point (for example the selected output interface). The Metering Process consists of a set of functions that includes packet header capturing, timestamping, sampling, classifying, and maintaining Flow Records. The maintenance of Flow Records may include creating new records, updating existing ones, computing Flow statistics, deriving further Flow properties, detecting Flow expiration, passing Flow Records to the Exporting Process, and deleting Flow Records. * Exporting Process An Exporting Process sends Flow Records to one or more Collecting Processes. The Flow Records are generated by one or more Metering Processes. * Exporter A device which hosts one or more Exporting Processes is termed an Exporter. Sadasivan, et al. Expires July 5, 2005 [Page 7] Internet-Draft IPFIX Architecture January 2005 * IPFIX Device An IPFIX Device hosts at least one Observation Point, a Metering Process and an Exporting Process. Typically, corresponding Observation Point(s), Metering Process(es) and Exporting Process(es) are co-located at such a device, for example at a router. * Collecting Process A Collecting Process receives Flow Records from one or more Exporting Processes. The Collecting Process might process or store received Flow Records, but such actions are out of scope for this document. * Collector A device which hosts one or more Collecting Processes is termed a Collector. * Template A Template is an ordered sequence of pairs, used to completely identify the structure and semantics of a particular set of information that needs to be communicated from an IPFIX Device to a Collector. Each Template is uniquely identifiable by means of a Template ID. * Control Information, Data Stream The information that needs to be exported from the IPFIX Device can be classified into the following categories: Control Information This includes the Flow definition, selection criteria for packets within the Flow sent by the Exporting Process, and any IPFIX protocol messages. The Control Information carries all the information needed for the end-points to understand the IPFIX protocol, and specifically for the receiver (Collector) to understand and interpret the data sent by the sender (Exporter). Data Stream This includes Flow Records carrying the field values for the various observed Flows at each of the Observation Points. Sadasivan, et al. Expires July 5, 2005 [Page 8] Internet-Draft IPFIX Architecture January 2005 IPFIX Message An IPFIX Message is a message originating at the Exporting Process that carries the IPFIX records of this Exporting Process and whose destination is a Collecting Process. An IPFIX Message is encapsulated within a transport layer. Information Element An Information Element is a protocol and encoding independent description of an attribute which may appear in an IPFIX Flow Record. The IPFIX information model [IPFIX-INFO] defines the base set of Information Elements for IPFIX. The type associated with an Information Element indicates constraints on what it may contain and also determine the valid encoding mechanisms for use in IPFIX. 4. Examples of Flows Some examples of Flows are listed below: Example 1: The Flow Keys define the different fields by which Flows are distinguished. The different combination of the field values creates unique Flows. If the set of Flow Keys is {source IP address, destination IP address, DSCP}, then all of these are different Flows. 1. {198.18.40.1, 198.18.23.5, 4} 2. {198.18.40.23, 198.18.23.67, 4} 3. {198.18.40.23, 198.18.23.67, 2} 4. {198.18.20.200, 198.18.23.67, 4} Example 2: A match function can be applied to all the packets that pass through an Observation Point, in order to aggregate some values. This could be done by defining the set of Flow Keys as {source IP address, destination IP address, DSCP} as in example 1 above, and applying a function which masks out the least significant 8 bits of the source IP address and destination IP address (i.e. the result is a /24 address). The four Flows from example 1 would now be aggregated into three Flows by merging the Flows 1 and 2 into a single Flow. 1. {198.18.40.0/24, 198.18.23.0/24, 4} 2. {198.18.40.0/24, 198.18.23.0/24, 2} 3. {198.18.20.0/24, 198.18.23.0/24, 4} Example 3: A filter defined by some field values can be applied on all packets that pass the Observation Point, in order to select only Sadasivan, et al. Expires July 5, 2005 [Page 9] Internet-Draft IPFIX Architecture January 2005 certain Flows. The filter is defined by choosing fixed values for specific fields from the packet. All the packets that go from a customer network 198.18.40.0/24 to another customer network 198.18.23.0/24 with DSCP value of 4 define a Flow. All other combinations don't define a Flow and are not taken into account. The three Flows from example 2 would now be reduced to one Flow by filtering away the second and the third Flow, leaving only {198.18.40.0/24, 198.18.23.0/24, 4}. The above examples can be thought of as a function F() taking as input {source IP address, destination IP address, DSCP}. The function selects only the packets which satisfy all three of the following conditions: 1. Mask out the least significant 8 bits of source IP address, match against 198.18.40.0. 2. Mask out the least significant 8 bits of destination IP address, match against 198.18.23.0. 3. Only accept DSCP value equal to 4. Depending on the values of {source IP address, destination IP address, DSCP} of the different observed packets, the Metering Process function F() would choose/filter/aggregate different sets of packets, which would create different Flows. For example, various combination of values of {source IP address, destination IP address, DSCP}, F(source IP address, destination IP address, DSCP) would result in the definition of one or more Flows. Sadasivan, et al. Expires July 5, 2005 [Page 10] Internet-Draft IPFIX Architecture January 2005 5. IPFIX Reference Model The figure below shows the reference model for IPFIX. This figure covers the various possible scenarios that can exist in an IPFIX system. +----------------+ +----------------+ |[*Application 1]| ..|[*Application n]| +--------+-------+ +-------+--------+ ^ ^ ~ ~ +~~~~~~~~~~+~~~~~~~~+ ^ ~ +------------------------+ +-------+------------------+ |IPFIX Device(1) | | Collector(1) | |[Exporting Process(es)] |<----------->| [Collecting Process(es)] | +------------------------+ +--------------------------+ .... .... +------------------------+ +---------------------------+ |IPFIX Device(i) | | Collector(j) | |[Obsv Point(s)] |<---------->| [Collecting Process(es)] | |[Metering Process(es)] | +---->| [*Application(s)] | |[Exporting Process(es)] | | +---------------------------+ +------------------------+ . .... . .... +------------------------+ | +--------------------------+ |IPFIX Device(m) | | | Collector(n) | |[Obsv Point(s)] |<-----+---->| [Collecting Process(es)] | |[Metering Process(es)] | | [*Application(s)] | |[Exporting Process(es)] | +--------------------------+ +------------------------+ The various functional components are indicated within brackets []. The functional components within [*] are not part of the IPFIX architecture. The interfaces shown by "<-->" are defined by the IPFIX architecture but those shown by "<~~>" are not. Figure 3 The figure below shows a typical IPFIX Device where the IPFIX components are shown in rectangular boxes. +--------------------------------------------------+ | IPFIX Device | | +-----+ | | +---......--+------------+---------> | | | | | | | | Sadasivan, et al. Expires July 5, 2005 [Page 11] Internet-Draft IPFIX Architecture January 2005 | +----+----+ +----+----+ | | | | |Metering | |Metering | | E | | | |Process 1| |Process N| | x | | | |(Packet | |(Packet | | p | | | | Level) | | Level) | | o | | | +---------+ +---------+ | r | | | ^ ^ | t | | |+-------+-----------------------+-------+ | i | | || | Observation Domain 1 | | | n | | || +-----+------+ +-----+------+| | g | | || |Obsv Point 1| ... |Obsv Point M|| | | | || +------------+ +------------+| | | | Packets|+-------^-------------------------^-----+ | | | Export --->---+--------+----------.....----------+ | | | Pkts to In | | +-------> | . . . . . | | |Collector | | | | | +---......--+------------+---------> | | | | | | | | | +----+----+ +----+----+ | P | | | |Metering | |Metering | | r | | | |Process 1| |Process N| | o | | | +---------+ +---------+ | c | | | ^ ^ | e | | |+-------+-----------------------+-------+ | s | | || | Observation Domain K | | | s | | || +-----+------+ +-----+------+| | | | || |Obsv Point 1| ... |Obsv Point M|| | | | || +------------+ +------------+| | | | Packets|+-------^-------------------------^-----+ +-----+ | --->---+--------+---------- ... ----------+ | In | | +--------------------------------------------------+ Figure 4 6. IPFIX Functional and Logical Blocks 6.1 Metering Process Every Observation Point in an IPFIX Device, participating in Flow measurements, must be associated with at least one Metering Process. Every packet coming into an Observation Point goes into each of the Metering Processes associated with the Observation Point. Broadly, each Metering Process observes the packets that pass an Observation Point, does timestamping and classifies the packets into Flow(s) based on the selection criteria. Sadasivan, et al. Expires July 5, 2005 [Page 12] Internet-Draft IPFIX Architecture January 2005 The Metering Process is a functional block which manages all the Flows generated from an Observation Domain. The typical functions of a Metering Process may include: o Maintain database(s) of all the Flows Records from an Observation Domain. This includes creating new Flow Records, updating existing ones, computing Flow Records statistics, deriving further Flow properties, adding non-flow-specific information based on the packet treatment (in some cases fields like AS numbers, router state, etc.) o Maintain statistics about the itself, such as Flows Records generated, packet observed, etc. 6.1.1 Flow Record Expiration A Flow Record is considered to have expired under the following conditions: 1. If the Metering Process can deduce the end of a Flow, that Flow Record should be exported when the end of the Flow is detected. For example, a Flow generated by TCP traffic where the FIN or RST bits indicate the end of the Flow Record. 2. If no packets belonging to the Flow have been observed for a certain period of time. This time period should be configurable at the Metering Process, with a minimum value of 0 seconds for immediate expiration. Note that a zero timeout would report a Flow as a sequence of single-packet Flows. 3. If the IPFIX Device experiences resource constraints, a Flow Record may be prematurely expired (e.g. lack of memory to store Flow Records) 4. For long-running Flows, the Metering Process should expire the Flow Record on a regular basis or based on some expiration policy. This periodicity or expiration policy should be configurable at the Metering Process. When a the Record of a long-running Flow is expired, that Flow Record may still be maintained by the Metering Process so that, for further observed packets of the same Flow Record, the Metering Process does not need to create a new Flow Record. 6.2 Observation Point A Flow Record can be better analyzed if the Observation Point from Sadasivan, et al. Expires July 5, 2005 [Page 13] Internet-Draft IPFIX Architecture January 2005 which it was measured is known. As such it is recommended that IPFIX Devices send this information to Collectors. In cases where there is a single Observation Point or where the Observation Point information is not relevant, the Metering Process may choose not to add the Observation Point to the Flow Records. 6.3 Selection Criteria for Packets A Metering Process may define rules so that only certain packets within an incoming stream of packets are chosen for measurement at an Observation Point. This may be done by one of the two methods defined below or a combination of them, in either order. A combination of each of these methods can be adopted to select the packets, i.e. one can define a set of methods {F1, S1, F2, S2, S3} executed in a specified sequence at an Observation Point to select particular Flows. The figure below shows the operations which may be applied as part of a typical Metering Process. packet header capturing | timestamping | v +----->+ | | | sampling Si (1:1 in case of no sampling) | | | filtering Fi (select all when no criteria) | | +------+ | v Flows Figure 5 6.3.1 Sampling Functions, Si A sampling function determines which packets within a stream of incoming packets is selected for measurement, i.e. packets that satisfy the sampling criteria for this Metering Process. Example: sample every 100th packet that was received at an Observation Point and collect the Flow Records selected by a particular filter function. Choosing all the packets is a special Sadasivan, et al. Expires July 5, 2005 [Page 14] Internet-Draft IPFIX Architecture January 2005 case where the sampling rate is 1:1. 6.3.2 Filter Functions, Fi A Filter Function selects only those incoming packets that satisfy a function on fields defined by the packet header fields, fields obtained while doing the packet processing, or properties of the packet itself. Example: Mask/Match of the fields that define a filter. A filter might be defined as {Protocol == TCP, Destination Port between 80 and 120}. Several such filters could be used in any sequence to select packets. Note that packets selected by a (sequence of) filter functions may be further classified by other filter functions, i.e. the selected packets may belong to several Flows, any or all of which are exported. 6.4 Observation Domain The Observation Domain is a logical block that presents a single identity for a group of Observation Points within an IPFIX Device. Each {Observation Point, Metering Process} pair belongs to a single Observation Domain. An IPFIX Device could have multiple Observation Domains, each of which has a subset of the total set of Observation Points in it. Each Observation Domain must carry a unique ID within the context of an IPFIX Device. Note that in case of multiple Observation Domains, a unique ID per Observation Domain must be transmitted as a parameter to the Exporting Function. That unique ID is referred to as the IPFIX Source ID. 6.5 Exporting Process The Exporting Process is the functional block that sends data to one or more IPFIX Collectors using the IPFIX protocol. On one side the Exporting Process interfaces with Metering Process to get Flow Records, while on the other side it talks to a Collecting Process on the Collector(s). There may be additional rules defined within an Observation Domain so that only certain Flows Records are exported. This may be done by either one or a combination of Si, Fi, as described in the section on "Selection Criteria for Packets". Example: Only the Flow Records which meet the following selection criteria are exported. Sadasivan, et al. Expires July 5, 2005 [Page 15] Internet-Draft IPFIX Architecture January 2005 1. All Flow Records whose destination IP address matches {198.18.33.5}. 2. Every other (i.e. sampling rate 1 in 2) Flow Record whose destination IP address matches {198.18.11.30}. 6.6 Collecting Process Collecting Processes use a Flow Record's Template ID to interpret that Flow Record's Information Elements. To allow this, an IPFIX Exporter must ensure that an IPFIX Collector knows the Template ID for each incoming Flow Record. To interpret incoming Flow Records, an IPFIX Collector may also need to know the function F() that was used by the Metering Process for each Flow. An IPFIX Collector may also use the selection criteria for packets to interpret the Flow Records further. The functions of the Collecting Process must include: o Identifying, accepting and decoding the IPFIX Messages from different pairs. o Storing the Control Information and Flow Records received from an IPFIX Device. At a high level, the Collecting Process: 1. Receives and stores the Control Information. 2. Decodes and stores the Flow Records using the Control Information. 6.7 Summary The figure below shows the functions performed in sequence by the various functional blocks in an IPFIX Device. Packet(s) coming into Observation Point(s) | | v v +----------------+-------------------------+ +-----+-------+ | Metering Process on an | | | | Observation Point | | | | packet header capturing | | | | | |...| Metering | Sadasivan, et al. Expires July 5, 2005 [Page 16] Internet-Draft IPFIX Architecture January 2005 | timestamping | | Process N | | | | | | | +----->+ | | | | | | | | | | | sampling Si (1:1 in case of no | | | | | | sampling) | | | | | classifying Fi (select all when | | | | | | no criteria) | | | | +------+ | | | | | | | | | | Timing out Flows | | | | | Handle resource overloads | | | +--------|---------------------------------+ +-----|-------+ | | Flow Records (identified by Observation Domain) Flow Records | | +---------+---------------------------------+ | +--------------------|----------------------------------------------+ | | Exporting Process | |+-------------------|-------------------------------------------+ | || v IPFIX Protocol | | ||+-----------------------------+ +----------------------------+| | |||Rules for | |Functions || | ||| Picking/sending Templates | |-Packetize selected Control || | ||| Picking/sending Flow Records|->| & data Information into || | ||| Encoding Template & data | | IPFIX export packets. || | ||| Selecting Flows to export(*)| |-Handle export errors || | ||+-----------------------------+ +----------------------------+| | |+----------------------------+----------------------------------+ | | | | | IPFIX exported packet | | | | | +------------+-----------------+ | | | Anonymize export packet(*) | | | +------------+-----------------+ | | | | | +------------+-----------------+ | | | Transport Protocol | | | +------------+-----------------+ | | | | +-----------------------------+-------------------------------------+ | v IPFIX export packet to Collector (*) indicates that the block is optional. Sadasivan, et al. Expires July 5, 2005 [Page 17] Internet-Draft IPFIX Architecture January 2005 Figure 6 7. Overview of the IPFIX Protocol An IPFIX Device consists of a set of co-operating processes that implement the functional blocks described in the previous section. Alternatively, an IPFIX Device can be viewed simply as a network entity which implements the IPFIX protocol. At the IPFIX Device, the protocol functionality resides in the Exporting Process. The IPFIX Exporting Process gets Flow Records from a Metering Process, and sends them to the Collector(s). At a high level, an IPFIX Device performs the following tasks: 1. Encode Control Information into Templates. 2. Encode packets observed at the Observation Points into Flow Records. 3. Packetize the selected Templates and Flow Records into IPFIX Messages. 4. Send IPFIX Messages to the Collector. The IPFIX protocol communicates information from an IPFIX Exporter to an IPFIX Collector. That information includes not only Flow Records, but also information about the Metering Process. Such information (referred to as Control Information) includes details of the data fields in Flow Records. It may also include statistics from the Metering Process, such as the number of packets lost (i.e. not metered). For details of the IPFIX protocol please refer to IPFIX-PROTO [3]. 7.1 Information Model Overview The IP Flow Information eXport (IPFIX) protocol serves for transmitting information related to measured IP traffic over the Internet. The protocol specification in IPFIX-PROTO [3] defines how Information Elements are transmitted. For Information Elements, it specifies the encoding of a set of basic data types. However, the list of fields that can be transmitted by the protocol, such as Flow attributes (source IP address, number of packets, etc.) and information about the Metering and Exporting Process (packet Observation Point, sampling rate, Flow timeout interval, etc.), is not specified in IPFIX-PROTO [3]. Instead, it is defined in the IPFIX Information Model document IPFIX-INFO [2]. Sadasivan, et al. Expires July 5, 2005 [Page 18] Internet-Draft IPFIX Architecture January 2005 The Information Model provides a complete description of the properties of every IPFIX Information Element. It does this by specifying each element's name, Field Type, data type, etc., and providing a description of each element. Element descriptions give the semantics of the element, i.e. say how it is derived from a Flow or other information available within an IPFIX Device. 7.2 Flow Records The following rules provide guidelines to be followed while encoding the Flow Records information: A Flow Record contains enough information so that the Collecting Process can identify the corresponding . The Exporting Process encodes a given Information Element (as specified in IPFIX-INFO [2]), based on the encoding standards prescribed by IPFIX-PROTO [3]. 7.3 Control Information The following rules provide guidelines to be followed while encoding the Control Information: o Per-Flow Control Information should be encoded such that the Collecting Process can capture the structure and semantics of the corresponding Flow data for each of the Flows Records exported by the IPFIX Device. o Configuration Control Information is conveyed to a Collector so that its Collecting Process can capture the structure and semantics of the corresponding configuration data. The configuration data which is also Control Information should carry additional information on the Observation Domain within which the configuration takes effect. For example, sampling using the same sampling algorithm, say 1 in 100 packets, is configured on two Observation Points O1 and O2. The configuration in this case may be encoded as {ID, configuration domain (O1,O2), sampling algorithm, interval (1 in 100)}, where ID uniquely identifies this configuration. The ID must be sent within the Flow Records in order to be able to match the right configuration control information The Control Information is used by the Collecting Process to: o Decode and interpret Flow Records. Sadasivan, et al. Expires July 5, 2005 [Page 19] Internet-Draft IPFIX Architecture January 2005 o Understand the state of the Exporting Process. Sending Control Information from the Exporting Process in a timely and reliable manner is critical to the proper functioning of the IPFIX Collecting Process. The following approaches may be taken for the export of Control Information. 1. Send all the Control Information pertaining to Flow Records prior to sending the Flow Records themselves. This includes any incremental changes to the definition of the Flow Records. 2. Notify on a near real time basis the state of the IPFIX Device to the Collecting Process. This includes all changes such as a configuration change that affects the Flow behavior, changes to Exporting Process resources that alter export rates, etc., which the Collector needs to be aware of. 3. Since it is vital that a Collecting Process maintains accurate knowledge of the Exporter's state, the export of the Control Information should be done such that that it reaches the Collector reliably. One way to achieve this would be to send the Control Information over a reliable transport. 7.4 Reporting Responsibilities From time to time an IPFIX Device may not be able to observe all the packets reaching one of its Observation Points. This could occur if a Metering Process finds itself temporarily short of resources, for example it might run out of packet buffers for IPFIX export, or it might detect errors in its underlying transport layer. In such situations, the IPFIX Device must report to its Collector(s) the number of packet losses that have occurred. 8. IPFIX Protocol Details When the IPFIX Working Group was chartered there were existing common practices in the area of Flow export, for example NetFlow, CRANE, LFAP, RTFM, etc. IPFIX's charter required the Working Group to consider those existing practices, and select the one that was the closest fit to the IPFIX requirements IPFIX-REQS [1]. Additions or modifications would then be made to the selected protocol to fit it exactly into the IPFIX architecture. 8.1 The IPFIX Basis Protocol The working group went through an extensive evaluation of the various Sadasivan, et al. Expires July 5, 2005 [Page 20] Internet-Draft IPFIX Architecture January 2005 existing protocols that were available, weighing the level of compliance with the requirements, and selected one of the candidates as the basis for the IPFIX protocol. For more details of the evaluation process please see IPFIX-EVAL [5]. In the basis protocol Flow Records are defined by Templates, where a Template is an ordered set of the Information Elements appearing in a Flow Record, together with their field sizes within those records. This approach provides the following advantages: o Using the Template mechanism, new fields can be added to IPFIX Flow Records without changing the structure of the export record format. o Templates that are sent to the Collecting Process carry structural information about the exported Flow Record fields. Therefore, if the Collector does not understand the semantics of new fields it can ignore them, but still interpret the Flow Record. o Because the template mechanism is flexible, it allows the export of only the required fields from the Flows to the Collecting Process. This helps to reduce the exported Flow data volume and possibly provide memory savings at the Exporting Process and Collecting Process. Sending only the required information can also reduce network load. 8.2 IPFIX Protocol on the Collecting Process The Collecting process is responsible for: 1. Receiving and decoding Flow Records from the IPFIX Devices. 2. Indicating Flow Record losses to the IPFIX Collecting Process. Complete details of the IPFIX protocol are given in IPFIX-PROTO [3]. 8.3 Support for Applications Applications that use the information collected by IPFIX may be Billing or Intrusion Detection sub-systems, etc. These applications may be an integral part of the Collecting Process or they may be co-located with the Collecting Process. The way by which these applications interface with IPFIX system to get the desired information is out of scope for this document. Sadasivan, et al. Expires July 5, 2005 [Page 21] Internet-Draft IPFIX Architecture January 2005 9. Export Models 9.1 Export with Reliable Control Connection As mentioned in the IPFIX-REQS [1] document, an IPFIX Device must be able to transport its Control Information and Data Stream over a congestion-aware transport protocol. If the network in which the IPFIX Device and Collecting Process are located does not guarantee reliability, at least the Control Information should be exported over a reliable transport. The Data Stream may be exported over a reliable or unreliable transport protocol. Possible transport protocols include: o SCTP: Supports reliable and unreliable transport. o TCP: Provides reliable transport only. o UDP: Provides unreliable transport only. Network operators would need to avoid congestion by keeping traffic within their own administrative domains. 9.2 Collector Failure Detection and Recovery The transport connection (in the case of a connection oriented protocol) is pre-configured between the IPFIX Device and the Collector. The IPFIX protocol does not provide any mechanism for configuring the Metering or Exporting Processes. Once connected, an IPFIX Collector receives Control Information and uses that information to interpret Flow Records. The IPFIX Device should set a keepalive (e.g. the keepalive timeout in the case of TCP, the HEARTBEAT interval in the case of SCTP) to a sufficiently low value so that it can quickly detect a Collector failure. Collector failure refers to the crash or restart of the Collecting Process, or of the Collector itself. A Collector failure is detected at the IPFIX Device by the break in the connection oriented transport protocol session: depending on the transport protocol - the connection timeout mechanisms differ. On detecting a keepalive timeout, the IPFIX Device should stop sending the Flow Record export data to the Collector and try to reestablish the transport connection. This is valid for a single Collector scenario. If Collecting Process failover is supported by the Exporting Process the backup session may be opened in advance. Sadasivan, et al. Expires July 5, 2005 [Page 22] Internet-Draft IPFIX Architecture January 2005 There could be one or more secondary Collectors with priority assigned to them. The primary Collector crash is detected at the IPFIX Device by the break in control connection (depending on the transport protocol - the connection timeout mechanisms differ). On detecting loss of connectivity, the IPFIX Device opens a Data Stream with the secondary Collector of the next highest priority. That Collector might become the primary, or the Exporting Process might try to reestablish the original session. 9.3 Collector Redundancy Configuring redundant Collectors is an alternative to configuring backup Collectors. In this model, all Collectors simultaneously receive the Control Information and Data Streams. Multiple {Control Information, Data Stream} pairs could be set up, each to a different Collector from the same IPFIX Device. Since the IPFIX protocol requires a congestion-aware transport, achieving redundancy using multicast is not an option. 10. IPFIX Flow Collection in Special Situations An IPFIX Device could be doing one or more of generating, receiving, altering special types of traffic which are listed below. Tunnel traffic: The IPFIX Device could be the head, midpoint or endpoint of a tunnel. In such cases the IPFIX Device could be handling GRE, IPinIP or UTI traffic. VPN traffic: The IPFIX Device could be a provider edge device which receives traffic from customer sites belonging to different Virtual Private Networks. Similarly, IPFIX could be implemented on devices which perform one or more of the following special services: o Explicitly drop packets. For example a device which provides firewall service drops packets based on some administrative policy. o Alter the values of fields used as IPFIX Flow Keys of interest. For example a device which provides NAT service can change source and/or destination IP address. In cases such as those listed above, there should be clear guidelines Sadasivan, et al. Expires July 5, 2005 [Page 23] Internet-Draft IPFIX Architecture January 2005 as to: o How and when to classify the packets as Flows in the IPFIX Device. o If multiple encapsulations are used to define Flows, how to convey the same fields (e.g. IP address) in different layers. o How to differentiate Flows based on different private domains. For example, overlapping IP addresses in Layer-3 VPNs. o What extra information needs be exported so that the Collector can make a clear interpretation of the received Flow Records. 11. Security Considerations Flow information can be used for various purposes, such as usage accounting, traffic profiling, traffic engineering, and intrusion detection. The security requirement may differ significantly for such applications. To be able to satisfy the security needs of various IPFIX users, an IPFIX system must provide different levels of security protection. 11.1 Data Security IPFIX data comprises Control Information and Data Stream generated by the IPFIX Device. The IPFIX data may exist in both the IPFIX Device and the Collector. In addition, the data is also transferred on the wire from the IPFIX Device to the Collector when it is exported. To provide security, the data should be protected from common network attacks. The protection of IPFIX data within the end system (IPFIX Device and Collector) is out of scope for this document. It is assumed that the end system operator will provide adequate security for the IPFIX data. The IPFIX architecture must allow different levels of protection to the IPFIX data on the wire. Wherever security functions are required it is recommended that users should leverage lower layers using either IPSEC or TLS, if these can successfully satisfy the security requirement of IPFIX data protection. To protect the data on the wire, three levels of granularity should be supported .. Sadasivan, et al. Expires July 5, 2005 [Page 24] Internet-Draft IPFIX Architecture January 2005 11.1.1 Host-Based Security Security may not be required when the transport between the IPFIX Device and the Collector is perceived as safe. This option allows the protocol to run most efficiently without extra overhead and an IPFIX system must support it. 11.1.2 Authentication-only Authentication-only protection provides IPFIX users with the assurance of data integrity and authenticity. The data exchanged between the IPFIX Device and the Collector is protected by an authentication signature. Any modification of the IPFIX data will be detected by the recipient, resulting in discarding of the received data. However, the authentication-only option doesn't offer data confidentiality. The IPFIX user should not use authentication-only when sensitive or confidential information is being exchanged. An IPFIX solution should support this option. The authentication-only option should provide replay attack protection. Some means to achieve this level of security are: o TCP with MD5 options. o IP Authentication Header 11.1.3 Encryption Data encryption provides the best protection for IPFIX data. The IPFIX data is encrypted at the sender and only the intended recipient can decrypt and have access to the data. This option must be used when the transport between the IPFIX Device and the Collector are unsafe and the IPFIX data needs to be protected. It is recommended that the underlying transport layer's security functions be used for this purpose. Some means to achieve this level of security are: o Encapsulating Security Payload. o Transport Layer Security Protocol The data encryption option adds overhead to the IPFIX data transfer. It may limit the rate that an Exporter can report its Flow Record to the Collector due to the resource requirement for running encryption. Sadasivan, et al. Expires July 5, 2005 [Page 25] Internet-Draft IPFIX Architecture January 2005 11.2 IPFIX End-point Authentication It is important to make sure that the IPFIX Device is talking to the "right" Collector rather than to a masquerading Collector. The same logic also holds true from the Collector point of view, i.e. it may want to make sure it is collecting the Flow Records from the "right" IPFIX Device. An IPFIX system should allow the end point authentication capability so that either one-way or mutual authentication can be performed between the IPFIX Device and Collector. The IPFIX architecture should use any existing transport protection protocols such as TLS or IPSEC to fulfill the authentication requirement. 12. IPFIX Overload An IPFIX Device could become overloaded under various conditions. This may be because of exhaustion of internal resources used for Flow generation and/or export. Such overloading may cause loss of data from the Exporting Process, either from lack of export bandwidth (possibly caused by an unusually high number of observed Flows) or from network congestion in the path from Exporter to Collector. IPFIX Collectors should be able to detect the loss of exported Flow Records, and should at least record the number of lost Flow Records. 12.1 Denial of Service (DoS) Attack Prevention Since one of the potential usages for IPFIX is for intrusion detection, it is important for the IPFIX architecture to support some kind of DoS resistance. 12.1.1 Network Under Attack The Network itself may be under attack, resulting in an overwhelming number of IPFIX Messages. An IPFIX system should try to capture as much information as possible. However, when a large number of IPFIX Messages are generated in a short period of time, the IPFIX system may become overloaded. 12.1.2 Generic DoS Attack on the IPFIX Device and Collector The IPFIX Device and Collector may be subject to generic DoS attacks, just as any system on any open network. These types of attacks are not IPFIX specific. Preventing and responding to such types of attacks are out of the scope of this document. Sadasivan, et al. Expires July 5, 2005 [Page 26] Internet-Draft IPFIX Architecture January 2005 12.1.3 IPFIX Specific DoS Attack There are some specific attacks on the IPFIX portion of the IPFIX Device or Collector. o The attacker could overwhelm the Collector with spoofed IPFIX export packets. One way to solve this problem is to periodically synchronize the sequence numbers of the Flow Records between the Exporting and Collecting Processes. o The attacker could provide false reports to the Collector by sending spoofed packets. The problems mentioned above can be solved to a large extent if the control packets are encrypted both ways. 13. IANA Considerations The IPFIX Architecture, as set out in this document, has two sets of assigned numbers. Considerations for assigning them are discussed in this section, using the example policies as set out in the "Guidelines for IANA Considerations" document IANA-RFC [6]. 13.1 Numbers used in the Protocol IPFIX Messages, as described in IPFIX-PROTO [3], use two fields with assigned values. These are the IPFIX Version Number, indicating which version of the IPFIX Protocol was used to export an IPFIX Message, and the IPFIX Template Number, indicating the type for each set of information within an IPFIX message. Changes in either IPFIX Version Number or IPFIX Template Number assignments require an IETF Consensus, i.e. they are to be made via RFCs approved by the IESG. 13.2 Numbers used in the Information Model Fields of the IPFIX protocol carry information about traffic measurement. They are modeled as elements of the IPFIX information model IPFIX-INFO [2]. Each Information Element describes a field which may appear in an IPFIX Message. Within an IPFIX message the field type is indicated by its Field Type. Changes in IPFIX Field Type will be administered by IANA, subject to Expert Review, i.e. review by one of a group of experts designated by an IETF Operations and Management Area Director. Those experts will initially be drawn from the Working Group Chairs and document editors of the IPFIX and PSAMP Working Groups. Sadasivan, et al. Expires July 5, 2005 [Page 27] Internet-Draft IPFIX Architecture January 2005 14. Acknowledgements The document editors wish to thank all the people contributing to the discussion of this document on the mailing list, and the design teams for many valuable comments. In particular, the following made significant contributions: Tanja Zseby Paul Calato Dave Plonka Jeffrey Meyer K.C.Norseth Vamsi Valluri Cliff Wang Ram Gopal Jc Martin Carter Bullard Reinaldo Penno Simon Leinen Kevin Zhang Paul Aitken Special thanks to Dave Plonka for the multiple thorough reviews. 15. References 15.1 Normative References [1] Quittek, J., Zseby, T., Claise, B. and S. Zander, "Requirements for IP Flow Information Export", RFC RFC 3917, October 2004. [2] Meyer, J., Quittek, J. and S. Bryant, "IPFIX: Information Model", (work in progress), Internet Draft, draft-ietf-ipfix-info-06.txt, October 2004. [3] Claise, B., Bryant, S., Sadasivan, G. and M. Fullmer, "IPFIX: Protocol", (work in progress), Internet Draft, draft-ietf-ipfix-protocol-07.txt, December 2004. [4] Zseby, T., Boschi, E., Penno, R., Brownlee, N. and B. Claise, "IPFIX: Protocol", (work in progress), Internet Draft, draft-ietf-ipfix-protocol-03.txt, October 2004. 15.2 Non-normative References [5] Leinen, S., "Evaluation of Candidate Protocols for IP Flow Information Export", RFC 3955, October 2004. Sadasivan, et al. Expires July 5, 2005 [Page 28] Internet-Draft IPFIX Architecture January 2005 [6] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", RFC 2434, October 1998. Authors' Addresses Ganesh Sadasivan Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 USA Phone: +1 408 527-0251 Email: gsadasiv@cisco.com Nevil Brownlee CAIDA | The University of Auckland Private Bag 92019 Auckland New Zealand Phone: +64 9 373 7599 x8941 Email: n.brownlee@auckland.ac.nz Benoit Claise Cisco Systems, Inc. De Kleetlaan 6a b1 1831 Diegem Belgium Phone: +32 2 704 5622 Email: bclaise@cisco.com Juergen Quittek NEC Europe Ltd. Adenauerplatz 6 69225 Heidelberg Germany Phone: +49 6221 90511-15 Email: quittek@ccrle.nec.de Sadasivan, et al. Expires July 5, 2005 [Page 29] Internet-Draft IPFIX Architecture January 2005 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Sadasivan, et al. Expires July 5, 2005 [Page 30] Internet-Draft IPFIX Architecture January 2005 Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Sadasivan, et al. Expires July 5, 2005 [Page 31]