IPFIX working group EDITORS: K.C. Norseth Internet Draft Enterasys Networks draft-ietf-ipfix-Architecture-00.txt Ganesh Sadasivan Expires: August 2002 Cisco Systems, Inc February 2002 IPFIX Architecture Architecture for IP Flow Information Export draft-ietf-ipfix-architecture-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. 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. Abstract This document defines architecture for scalable monitoring, measuring and exporting IP flow information to collectors. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [ ]. 1. Introduction 2 2. Scope 3 3. Terminology 3 4. IPFIX reference Model 4 4.1. Exporter 6 4.2. IPFIX protocol 6 4.3. Observation Domain 7 4.4. Collector 8 4.5. Capabilities Management 8 4.6. Applications 9 IPFIX Working Group Expires August 2002 [Page 1]
INTERNET-DRAFT draft-ietf-ipfix-architecture-00.txt Feb. 22, 2002 5. IPFIX Protocol 9 5.1. Selection Criteria for IPFIX Protocol 9 5.1.1. Common for Exporting and Collecting Device 9 5.1.2. IPFIX Protocol on Exporting Device 9 5.1.3. IPFIX Protocol on Collecting Device 9 5.2. Export Models 9 5.2.1. A Simple Export Model 9 5.2.2. Export Model with Reliable Control Connection 9 5.3. Collector Crash Detection and Recovery 10 5.3.1. Simple Export Model 10 5.3.2. Export Model with Reliable Control Connection 10 5.4. Collector Crash Detection and Recovery 11 5.4.1. Simple Export Model 11 5.4.2. Export Model with Reliable Control Connection 11 5.5. Collector Redundancy 12 5.5.1. Simple Export Model 12 5.5.2. Export Model with Reliable Control Connection 12 5.6. Security 12 5.7. Capability Negotiation 12 5.7.1. Phase I - Capabilities and Capabilities Management 13 5.7.2. Phase II - Data Management and Data Transmission 14 5.7.3. Renegotiation of Capabilities 17 5.7.4. Caching of Negotiated Parameters 17 6. Security Consideration 17 6.1. Data security. 17 6.1.1. No security 18 6.1.2. Authentication only 18 6.1.3. Encryption 18 6.2. IPFIX end point authentication 18 6.3. Denial of service (DoS) attack prevention 19 6.3.1. Network under attack 19 6.3.2. Generic DoS attack on the IPFIX system 19 6.3.3. IPFIX Specific DoS attack 19 7. IANA Consideration 19 8. References 20 9. Acknowledgements 21 10. Author's Addresses 22 11. Full Copyright Statement 23 12. Issues 23 12.1. MIBS 24 12.2. Relationship to RTFM 24 1. Introduction Many applications e.g., Intrusion detection, traffic engineering, require the monitoring, measuring of IP traffic flows. It is hence important to have a standard way of exporting information related to IP flows. This document defines architecture for IP traffic flow monitoring, measuring and exporting. It provides a high-level description of the key components and their functions. 2. Scope IPFIX Working Group Expires August 2002 [Page 2]
INTERNET-DRAFT draft-ietf-ipfix-architecture-00.txt Feb. 22, 2002 This document defines architecture for IPFIX[3]. The main objective of this document is to: * Describe the key architectural components of IPFIX. * Define the architectural requirements, e.g., Recovery, Security, etc for the IPFIX framework. * Define the criteria to select the IPFIX Protocol. * Specify the control/data message formats and handshaking details to pass the IP flow information. 3. Terminology Flow: A flow is defined as a set of 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 of packet header fields (e.g. destination IP address) 2 One or more properties of the packet itself (e.g. packet length) 3 One or more of fields derived from packet treatment (e.g. AS number) Each of the fields from 1.,2. and 3. are referred to as keys. A packet is defined to belong to a flow if it completely satisfies all the defined properties of the flow. For a more detailed explanation of flows, refer to [IPFIX-DATA]. Flow Type: A function F that would take input as a set of keys and the output would be one or more flows depending on the combination of values for the set of keys. Observation Point: The observation point may be one or a set of interfaces (physical or logical) of the exporter. For a more detailed explanation of Observation Point, refer to [IPFIX-DATA]. Meter Process: A set of actions like timestamping, sampling, filtering, performed on packets received at an observation point to map them to flows. For a more detailed explanation of Meter Process, refer to [IPFIX- DATA]. Observation Domain: The set of observation points that is the largest aggregatable set of flow information at the exporter is termed as an observation domain. The observation domain presents itself a unique ID to the collector for identifying the export packets generated by it. Example: The observation domain could be a router line card, composed of several interfaces with each interface being an IPFIX Working Group Expires August 2002 [Page 3]
INTERNET-DRAFT draft-ietf-ipfix-architecture-00.txt Feb. 22, 2002 observation point. Template: Templates is a set of {type, length} ordered pairs, used to completely identify the structure and semantics of a particular information that needs to be communicated from the exporter to the collector. Each template is uniquely identified by a Template ID. 4. 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. +-------------------+ +----------------+ +----------------+ |[Obsv Point(s)] | |[*Application 1]| ..|[*Application n]| |[Meter Process(es)]| +--------+-------+ +-------+--------+ +----------+--------+ ^ ^ ^ ! ! ! +~~~~~~~~~~+~~~~~~~~+ ! ! v v +------------------+ +------------------+ |IPFIX Device(1) | | Collector(1) | |[Export Process] |<--------------->| | | | | | +------------------+ +------------------+ .... .... +-------------------+ +------------------+ |IPFIX Device(i) | | Collector(j) | |[Obsv Point(s)] |<-------------->| [*Application(s)]| |[Meter Process(es)]| +---->| | |[Export Process] | | +------------------+ +-------------------+ . .... . .... +-------------------+ | +------------------+ |IPFIX Device(m) | | | Collector(n) | |[Obsv Point(s)] |<---------+---->| [*Application(s)]| |[Meter Process(es)]| | | |[Export Process] | +------------------+ +-------------------+ The various functional components are indicated within []. The functional components within [*] are not part of the IPFIX framework. The interfaces shown by "<-->" are defined by the IPFIX framework and those shown by "<~~>" are not. An IPFIX device is a unit that hosts at the minimum, flow information export process but usually, the corresponding Observation points, metering processes, and exporter processes are co-located at this device. A group of Observation Points and their IPFIX Working Group Expires August 2002 [Page 4]
INTERNET-DRAFT draft-ietf-ipfix-architecture-00.txt Feb. 22, 2002 corresponding meter processes form an Observation Domain. One or more Observation Domains can interface with the same export process. The figure below shows a typical IPFIX device. +---------------------------------------------------+ | IPFIX Device | | +---------------------------------------+ +-----+ | | | Capabilities Manager | |MGMT | | Import | | | |Prcs |<------- | |---------------------------------------+ +-----+ | the | +---------------------------------------+ +-----+ | collector | | Observation Domain 1 | | e | | | | +--------------------------+ | | | | | | | * Optional Meter Process +~~+---------> x | | | | | Flow Level ({Fi}, {Si}) | | | | | | | | +--------------------------+ | | | p | | | | ^ ^ | | | | | | | ! ! | | | o | | | | +---......--+------------+ | | | | | | | | | | r | | | | +----+----+ Packet Level +----+----+ | | | | | | |Meter | ({Fi}, {Si}) |Meter | | | | | | | |Process 1| |Process N| | | t | | | | +---------+ +---------+ | | | | | | ^ ^ | | | | | | | | | | | | | | +-----+------+ +-----+------+| | | | | | |Obsv Point 1| ... |Obsv Point M|| | | | | | +------------+ +------------+| | | | | +---------------------------------------+ | | |export | .... | ------> | +---------------------------------------+ | | |towards | | Observation Domain K | | p | |the | | | | | |collector | | +--------------------------+ (*) | | r | | | | | * Optional Meter Process +~~+---------> | | | | | Flow Level ({Fi}, {Si}) | | | | o | | | | +--------------------------+ | | | | | | | ^ ^ | | | c | | | | +---......--+------------+ | | | | | | | | | | | | | | +----+----+ Packet Level +----+----+ | | e | | | | |Meter | ({Fi}, {Si}) |Meter | | | | | | | |Process 1| |Process N| | | s | | | | +---------+ +---------+ | | | | | | ^ ^ | | s | | | | | | | | | | | | +-----+------+ +-----+------+| | | | | | |Obsv Point 1| ... |Obsv Point M|| | | | | | +------------+ +------------+| | | | | +---------------------------------------+ +-----+ | +---------------------------------------------------+ IPFIX Working Group Expires August 2002 [Page 5]
INTERNET-DRAFT draft-ietf-ipfix-architecture-00.txt Feb. 22, 2002 In this figure, the functional blocks are shown in rectangular boxes. The interface shown by "~~" is applicable only if the optional Meter process at the flow level is present. Otherwise, the meter process(es) at the packet level interfaces directly with the exporting function. Note that in case of multiple observation domains, a unique ID per observation domain must be transmitted as parameters to the exporting function. For details on ({Fi}, {Si}) which makeup a meter process, refer to [IPFIX-DATA]. 4.1.Exporter The exporter is a subsystem that interacts with one or more observation points. The functions of an exporter may include: * Performing Flow ID management (capabilities negotiation) that includes the creation of tags to refer a flow between Exporter and the Collector for configuration and statistical purpose. * Assembling collected information into the right format to be carried by the IPFIX protocol * Configuring observation points with flow monitoring rules * Measuring, aggregating and exporting IP Flow information to the respective collectors. * May perform appropriate middle-box functions to translate the flow information. The information collected can be either pushed periodically to the collector or pulled by the collector on demand. The Exporter Process is the functional block that interacts with observation domain(s) on one side and collector(s) on the other side. The typical functions of an exporter may include: * Accept and separate flow records/control information from different observation domains into separate export packet streams. * Run the part of the IPFIX protocol, which deals with packetization, and transport of flow records/control information with the collector. 4.2. IPFIX protocol The information that needs to be exported from the exporting device can be classified into the following categories: IPFIX Working Group Expires August 2002 [Page 6]
INTERNET-DRAFT draft-ietf-ipfix-architecture-00.txt Feb. 22, 2002 1 Control Information - This includes the flow type definition, selection criteria for packets within the flow etc. 2 Flow record - This includes data records corresponding to the various observed flows at each of the observation point. IPFIX protocol at the exporting device does the following: 1 Encode the control information into self-describing structures. 2 Encode the flows measured at the exporting device into flow records. 3 Packetize the flow records and/or control information into export packets. 4 Use the underlying transport layer to send the export packets to the collector. IPFIX protocol at the collecting device is responsible for 1 Receive and store the control information. 2 Decode and store the flow records using the control information. The information that needs to be exported from the IPFIX device can be classified into the following categories: * Control Information - This includes the flow type definition, selection criteria for packets within the flow etc. * Flow records. At the IPFIX device, the protocol functionality may be split between Observation domain and exporter process. IPFIX protocol at the IPFIX device does the following: 1 Encode the control information into self-describing templates. 2 Encode the flows measured at the exporting device into flow records. 3 Packetize the flow records and/or control information into export packets. 4 Use the underlying transport layer to send the export packets to the collector. IPFIX protocol at the collector is responsible for 1 Receive and store the control information. 2 Decode and store the flow records using the control information. 4.3. Observation Domain The Observation Domain is the functional block which may be capable of managing the flows generated from all the valid {Observation Point, Meter Process} combination defined within itself. The typical functions of an Observation Domain may IPFIX Working Group Expires August 2002 [Page 7]
INTERNET-DRAFT draft-ietf-ipfix-architecture-00.txt Feb. 22, 2002 include: * Run the part of the IPFIX protocol which deals with encoding flow data and control information into flow records and templates respectively. * Decide which flow records/control information to export using rules based on time, thresholds, configuration events etc. * Aggregate flow records generated by one or more meter processes. * Add non-flow specific information (in some cases fields like AS numbers) * May perform appropriate middle-box functions to translate the flow information. The functionality of Meter Process is explained at length in [IPFIX-DATA]. 4.4. Collector Collector is a subsystem that interacts with one or more Exporters. The functions of the collector may include: * Performing Flow ID management (capabilities negotiation) that includes the creation of tags to refer a flow between Exporter and the Collector for configuration and statistical purpose. * Requesting an exporter sub-system to collect IP flows. * Communicating with different applications. * Maintaining a repository of IP flow statistics * Aggregating application level requests and form a template that will suitable for exporter. The application(s) and the collector may be tightly coupled in one system. They may also be logically or physically a separate subsystem from the application(s). In which case, the communication between them is beyond the scope of IPFIX. Collector is a subsystem that interacts with one or more IPFIX devices. The functions of the collector MAY include: * Identify and accept export packets from different {Export Process, Observation Domain} pairs. * Run IPFIX protocol. * Store the control information and flow records received from IPFIX device. * Pass capabilities information to the IPFIX device. Notify the IPFIX device of problems it is having 4.5. Capabilities Management Basic capabilities contain information about the collector. It MAY include: IPFIX Working Group Expires August 2002 [Page 8]
INTERNET-DRAFT draft-ietf-ipfix-architecture-00.txt Feb. 22, 2002 * The collector availability - is it up? * Maximum caching capability of the collector. 4.6.Applications IPFIX applications may be things such as Billing and Intrusion Detection sub-systems. etc.[3]. An application requests the Collector to gather the relevant IP Flow information. 5. IPFIX Protocol 5.1. Selection Criteria for IPFIX Protocol 5.1.1. Common for Exporting and Collecting Device 1 Transparency over transport protocol. Ability to operate on top of UDP or a reliable transport like TCP/SCTP. 2 Transparency over any underlying security protocols. 5.1.2. IPFIX Protocol on Exporting Device 1 Ability to detect loss of connectivity with the collector and trigger a switch over to an alternate collector. 2 Optionally export flow records to multiple collecting devices. 3 Optionally perform load balancing of flow record export among a set of collectors based on pre-defined set of rules. 4 Monitor control information/flow record export, detect overload and switch to the overload behavior. 5.1.3.IPFIX Protocol on Collecting Device Monitor the reception of export packets from IPFIX device. 5.2. Export Models 5.2.1. A Simple Export Model If the network in which the exporter and collector are located guarantees the security and reliability requirements, the transport of the export flow packets MAY do over a lightweight transport like UDP, for speed and simplicity. 5.2.2. Export Model with Reliable Control Connection IPFIX Working Group Expires August 2002 [Page 9]
INTERNET-DRAFT draft-ietf-ipfix-architecture-00.txt Feb. 22, 2002 If the network in which the exporter and collector are located does not guarantee reliability, at least the control information SHOULD be exported over a reliable transport. There could be network security concerns between exporter and collector. To avoid re- inventing the wheel, and to reduce the complexity of flow export protocol, one or a combination of the following methods MAY be adopted as a solution to achieve security: * IP Authentication Header MAY be used when the threat environment requires stronger integrity protections, but does not require confidentiality. * IP Encapsulating Security Payload (ESP) MAY be used to provide confidentiality and integrity. * If the transport protocol used is TCP, optionally TCP MD5 signature option MAY be used to protect against spoofed TCP segments. The flow records MAY be exported over an unreliable or reliable transport protocol. As explained above the transport connection (in the case of a connection oriented protocol) is pre-setup between the exporter and the collector. Once connected, the collector side receives the control information and uses this information to interpret the flow records. The exporter SHOULD set the keepalive (in the case of TCP) or the HEARTBEAT interval in the case of SCTP to a sufficiently low value so that it can quickly detect a collector crash. 5.3. Collector Crash Detection and Recovery The information that needs to be exported from the IPFIX device can be classified into the following categories: * Control Information - This includes the flow type definition, selection criteria for packets within the flow. This is also called as control stream. * Flow record - This includes data records corresponding to the various observed flows at each of the observation point. This is also called as data stream. 5.3.1. Simple Export Model If the network in which the exporter and collector are located guarantees the security and reliability requirements, the transport of the export flow packets MAY do over a lightweight transport like UDP, for speed and simplicity. A single transport stream for control and data would suffice here. 5.3.2. Export Model with Reliable Control Connection IPFIX Working Group Expires August 2002 [Page 10]
INTERNET-DRAFT draft-ietf-ipfix-architecture-00.txt Feb. 22, 2002 If the network in which the exporter and collector are located does not guarantee reliability, at least the control information SHOULD be exported over a reliable transport. There could be network security concerns between exporter and collector. To avoid re- inventing the wheel, and to reduce the complexity of flow export protocol, one or a combination of the following methods MAY be adopted as a solution to achieve security: * IP Authentication Header MAY be used when the threat environment requires stronger integrity protections, but does not require confidentiality. * IP Encapsulating Security Payload (ESP) MAY be used to provide confidentiality and integrity. * If the transport protocol used is TCP, optionally TCP MD5 signature option MAY be used to protect against spoofed TCP segments. The data stream MAY be exported over a reliable or unreliable transport protocol. As explained above the transport connection (in the case of a connection oriented protocol) is pre-setup between the exporter and the collector. Once connected, the collector side receives the control information and uses this information to interpret the flow records. The exporter SHOULD set the keepalive (in the case of TCP) or the HEARTBEAT interval in the case of SCTP to a sufficiently low value so that it can quickly detect a collector crash. 5.4.Collector Crash Detection and Recovery 5.4.1. Simple Export Model In this model, a collector crash can be detected if there is a Keepalive mechanism available at the IPFIX protocol layer. On detecting a Keepalive timeout, the exporter SHOULD stop sending the flow export data to the collector but continue to send Keepalive requests till a Keepalive response is received. If there is an alternate collector which can has connectivity with the exporter, the exporter SHOULD start exporting to this device. 5.4.2. Export Model with Reliable Control Connection The collector crash is detected at the exporter by the break in control connection (depending on the transport protocol the connection timeout mechanisms differ). On detecting a Keepalive timeout, the exporter SHOULD stop sending the flow export data to IPFIX Working Group Expires August 2002 [Page 11]
INTERNET-DRAFT draft-ietf-ipfix-architecture-00.txt Feb. 22, 2002 the collector and try reconnecting the transport connection. This is valid for a single collector scenario. If there are multiple collectors for the same exporter, the exporter opens control connections to each of the collectors. However, data is sent only to one of the collectors, which is chosen as the primary. There could be one or more collectors configured as secondary and a priority assigned to them. The primary collector crash is detected at the exporter by the break in control connection (depending on the transport protocol the connection timeout mechanisms differ). On detecting loss of connectivity, the exporter opens data stream with the secondary collector of the next highest priority. This collector now becomes the primary. The maximum export data loss would be the amount of data exported in the time between when the loss of connectivity to the collector happened, and the time at which this was detected by the exporter. 5.5. Collector Redundancy 5.5.1. Simple Export Model In case there are multiple collectors, the exporter MAY multicast the flow records to the set of collectors that joined the export multicast group, instead of sending several unicast streams towards the different collectors. Multicast would lower the bandwidth requirements on the export link in case that the collectors are on the same media, and could lower the internal bus utilization on the exporter. Using multicast session with more than one collector joining the flow export multicast group, redundancy of collectors can be easily achieved. 5.5.2. Export Model with Reliable Control Connection The control information is exported through a reliable transport and so cannot be multicast. The data stream MAY be multicast if it is over an unreliable transport like UDP. However, the collector SHOULD join the multicast group only after the control stream is established and it has received the control information from the exporter. Using multicast session with more than one collector joining the flow export multicast group, redundancy of collectors can be easily achieved. 5.6. Security Refer Security Consideration section for details 5.7. Capability Negotiation The capability negotiation is composed of two phases. In the first IPFIX Working Group Expires August 2002 [Page 12]
INTERNET-DRAFT draft-ietf-ipfix-architecture-00.txt Feb. 22, 2002 Phase, basic capabilities regarding the exporting interface support are negotiated between IPFIX end-points. If this phase fails, the negotiation process will terminate and status information will be provided to upper layers. In the second phase, more capabilities that are specific are negotiated, for instance, extended information model support, redundancy support, templates, and supported messages. One could use, for instance, a capability negotiation process similar to LCP [RFC 1661]. For each capability proposed by one of the peers in each of the phases, the answer can be a reject, ack or nak. More specifically, the system sending a Configure-Request is telling the peer system that it is willing to receive data sent with the enclosed options enabled. If the peer does not recognize (or administratively prohibits) one or more options in the Configure- Request message, it must return just these options in a Configure- Reject message and the original sender must then remove the options from a subsequent Configure-Request message. If some of these options were recognized but unacceptable with the supplied parameters, the peer would then respond with a Configure- Nak containing only the offending options and a suggested modified value for the parameters (called a hint). The receiver of the Configure-Nak then should decide if the hinted value is acceptable and, if so, send a new Configure-Request reflecting the requested changes plus the original values for the unchanged options. The sender of the Configure-Request may not send back any message other than Configure-Request in response to Configure-Nak, so the only recourses available if the hint is unreasonable are to drop the option from subsequent Configure-Request messages, use Protocol- Reject to disable the protocol, or disconnect the link entirely. Finally, if all options are acceptable, the peer then responds with Configure-Ack with the same options list as given in the Configure- Request to indicate that all of the enclosed options were acceptable and that are now enabled. 5.7.1. Phase I - Capabilities and Capabilities Management In the first phase, basic capabilities regarding the exporting interface support are negotiated between IPFIX end-points. If this phase fails, the negotiation process will terminate and status information will be provided to users. The Phase I negotiation MAY be carried over UDP, as it is a widely supported transport protocol. 5.7.1.1. Security support IPFIX Working Group Expires August 2002 [Page 13]
INTERNET-DRAFT draft-ietf-ipfix-architecture-00.txt Feb. 22, 2002 The security support capability is used to negotiate which methods (e.g. IPSec, TLS, MD5, etc) can be used to provide confidentiality, integrity and protection against spoofed attacks. 5.7.1.2. IPFIX protocol It is possible that several protocols (e.g. LFAP, CRANE, NetFlow, and Diameter) meet the IPFIX requirements. In this case, this capability is used to negotiate which protocol the end points will use. 5.7.1.3. Version of Protocol This capability is used to negotiate which version of the protocol exporter and collector will use to communicate. Agreeing on a specific version indicates that the end-points support all the semantics and dynamic procedures specified by a version of the protocol. The protocol syntax (information model, data model, coding schemes, etc) should be negotiated in Phase II. 5.7.1.4. Transport layer support This capability is used to negotiate the transport layer protocol used between the exporter and collector. As the reliability is a key requirement of an IPFIX system, the transport protocol should be connection oriented, congestion aware, reliable, and providing in-sequence data delivery (e.g. TCP, SCTP). Under some circumstances e.g., when the network path between exporter and collectors ensures abundant bandwidth and 'no' packet loss due to congestion, a lightweight transport protocol such as UDP may be employed. In this case, the upper layer must provide capabilities to ensure reliability, e.g. message integrity check, loss detection, acknowledgment, etc. 5.7.2. Phase II - Data Management and Data Transmission In this phase, the IPFIX protocol initiates its own connection setup that involves further capability negotiation. 5.7.2.1. Data collection triggers and policies *Update interval [TBD] *Sampling [TBD] IPFIX Working Group Expires August 2002 [Page 14]
INTERNET-DRAFT draft-ietf-ipfix-architecture-00.txt Feb. 22, 2002 *Aggregation rules[TBD] * Caching The exporter caches a certain amount of data before sending it to the collector. If the collector fails, the exporter will need to hold more data than normal while it waits for the collector to come back or switch to different one. In order to provide for these two modes of operation, the exporter could be configured with two levels of caching. One level when the system is operating normally and a second when a failure occurs. If the exporter detects that a server is unavailable; it should use the higher cache level that allows it to hold more data than it does in normal operation. 5.7.2.2. Reliability This capability is used to negotiate parameters related to fail-over support, load balancing, keepalives, etc. For instance, exporter and collector SHOULD set the keepalive (in the case of TCP) or the HEARTBEAT interval in the case of SCTP to a sufficiently low value so that it can quickly detect a collector crash. On detecting a Keepalive timeout, the exporter SHOULD stop sending the flow export data to the collector and bring down the transport connection. If the exporter detects that a collector is unavailable and fail- over was negotiated, it should try to switch to the stand-by collector in order to resume service. If the exporter does not keep a live connection to the stand-by collector, it MAY go through the capabilities negotiation process described in this section before it could export data. IN the case of UDP, an exporter MAY send a Collector Health request query. The collector MUST reply to this request. The exporter MUST be able to accept a response from the collector. If the exporter does not see the health query response from the collector, it assumes the collector is unavailable and MAY switch to another collector that is available. In the case there are multiple collectors operating redundant mode, the exporter MAY multicast the flow records to the set of collectors that joined the export multicast group, instead of sending several unicast streams towards the different collectors. Multicast would lower the bandwidth requirements on the export link in case that the collectors are on the same media, and could lower the internal bus utilization on the exporter. In the case there are multiple collectors operating in load- balancing mode, a weight number associated with each server MAY be used to infer the amount of exported flows each server should receive. IPFIX Working Group Expires August 2002 [Page 15]
INTERNET-DRAFT draft-ietf-ipfix-architecture-00.txt Feb. 22, 2002 It should be noted that servers operating in a redundant or load- balancing mode could be running different version of the IPFIX protocol and use different capabilities. 5.7.2.3. Templates This capability is used to negotiate a common set of templates corresponding to an IPFIX session between the exporter and collector. A locally unique template identifier (template ID) MUST be assigned to each template, and carried along with IPFIX user messages to ensure correct decoding of IP flow information. Exporter and collector MUST use the same set of templates during a session. The templates can be renegotiated but MUST always be agreed on by all IPFIX end-points participated in the IPFIX session before they can be used. The exporter and collector MUST agree on a common set of templates before the collector can start sending data according to them. The template negotiation follows the LCP method described earlier. The collector may propose changes to the templates received from an exporter (e.g. enabling some keys and disabling others), or it can acknowledge the templates as is. In the case that a template or a key is not recognized by the collector (e.g. they might be added to the exporter after the collector configuration has completed), the collector MAY choose to disable each unknown key or unknown templates in order to avoid unnecessary traffic. A template is disabled when all the keys are disabled. 5.7.2.4. Extended flow type support Beside standardized minimum set of possible flow properties, the exporter should be able to classify and export flows based on extended information such as (but not limited to) URL, RTP Media type and SIP Method. This capability is used to negotiate what are those extended properties. 5.7.2.5. Messages Supported A particular protocol or version might have optional messages that are not mandatory. This capability is used to negotiate what are those optional messages types supported. 5.7.2.6. Overlapping flows This capability is used to negotiate the support of overlapping flow awareness, i.e., if exporter has the means of inferring if the same will be exported more than once and letting the collector of this fact. In the absence of explicit negotiation of this capability, the IPFIX Working Group Expires August 2002 [Page 16]
INTERNET-DRAFT draft-ietf-ipfix-architecture-00.txt Feb. 22, 2002 collector MUST consider that all flows reported can overlap. In the case the device reports overlapping between certain flows, the collector SHOULD take this into consideration, but MUST NOT assume that other flows will not overlap 5.7.2.7. MIDCOM related Capabilities [TBD] To Be Added 5.7.3. Renegotiation of Capabilities Only renegotiation of capabilities agreed on phase II can be performed without tearing down the connection. The initial negotiation can deal with a wealth of settings and assign ID's to various capability versions. The re-negotiation needs only to refer these IDs and require simple acknowledgement. 5.7.4. Caching of Negotiated Parameters Negotiation of parameters can be transmitted at any time by the exporter. It is also possible for the collector to request negotiation parameters. The exporter MUST be able to receive a request from the exporter. 6. Security Consideration IP flow information can be used for various purposes, such as usage accounting, traffic profiling, traffic engineering, and intrusion detection. For each application, the security requirement may differ significantly from one to another. To be able to satisfy the security needs of various IPFIX users, the architecture of IPFIX MUST provide different levels of security protection. 6.1. Data security. IPFIX data consists the control stream 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 exporter to the collector when it is reported. To provide security, the data SHOULD be protected from adversary. The protection of IPFIX data within the end system (IPFIX device and collector) is out of the scope. It is assumed that the end system operator will provide adequate security for the IPFIX data. IPFIX Working Group Expires August 2002 [Page 17]
INTERNET-DRAFT draft-ietf-ipfix-architecture-00.txt Feb. 22, 2002 The IPFIX architecture MUST allow different levels of protection to the IPFIX data on the wire. Whereever security functions are required it is recommended to leverage to lower layers using either IPsec or TLS, if they can successfully satisfy the security requirement of IPFIX data protection. To protect the data on the wire, three levels of granularity SHOULD be supported: 6.1.1. No security No security is 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 solution MUST support it. 6.1.2. Authentication only The authentication only protection provides the IPFIX users the assurance of data integrity and authenticity. The data exchanged between the IPFIX device and the collector is protected by 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 avoid use this option 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: * TCP with MD5 options. * IP Authentication Header 6.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 exporter and the collector are unsafe and the IPFIX data needs to be protected. It is recommended to use the underlying security layer functions for this purpose. Some means to achieve this level of security are: * Encapsulating Security Payload. * Transport Layer Security Protocol The data encryption option adds overhead to the IPFIX data transfer. It may limit the rate that an export can report its flow to the collector due to the heavy resource requirement of running encryption. IPFIX Working Group Expires August 2002 [Page 18]
INTERNET-DRAFT draft-ietf-ipfix-architecture-00.txt Feb. 22, 2002 6.2. IPFIX end point authentication It is important to make sure that the IPFIX device is talking to the "right" collector instead of a masqueraded collector. The same logic also holds true from the collector point of view that it want to make sure it is collecting the flow information from the "right" IPFIX device. The IPFIX architecture SHOULD allow the authentication capability so that either one-way or mutual authentication can be performed between the IPFIX device and collector. The IPFIX architecture SHOULD use the existing transport protection protocols such as TLS to fulfill the authentication requirement. 6.3. 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. 6.3.1. Network under attack The Network itself may be under attack, resulting in an overwhelming number of IPFIX messages. The IPFIX SHOULD try to capture as much information as possible. However, when large amount IPFIX messages are generated in a short period of time, the IPFIX may become overloaded. The IPFIX system MUST provide enough performance assurance so that the system can still function under heavy load. Possible solutions include flow control and message threshold information. 6.3.2. Generic DoS attack on the IPFIX system The IPFIX system may subject to generic DoS attacks, just as any system on any open networks. These types of attacks are not IPFIX specific. Preventing and responding to such types of attacks are out of the scope of IPFIX WG. 6.3.3. IPFIX Specific DoS attack There is a specific attack on the IPFIX portion of the Exporter or Collector. (To be added and discussed on the general list). 7. IANA Consideration Need Port number assigned from IANA [more to be written] IPFIX Working Group Expires August 2002 [Page 19]
INTERNET-DRAFT draft-ietf-ipfix-architecture-00.txt Feb. 22, 2002 8. References 3. J. Quittek ,et al.," Requirements for IP Flow Information Export ", (work in progress) ,Internet Draft, Internet Engineering Task Force, <draft-ietf-ipfix-reqs-00.txt>, November 2001 4. M. Wood ,et al.," Intrusion Detection Message Exchange Requirements",(work in progress), Internet Draft, Internet Engineering Task Force, draft-ietf-idwg-requirements-06,February 2002. 5. Daniel O. Awduche, et. al.," Overview and Principles of Internet Traffic Engineering", (work in progress), Internet Draft, Internet Engineering Task Force, draft-ietf-tewg- principles-02.txt, May 2002 [Brow00] Nevil Brownlee: Packet Matching for NeTraMet Distributions, http://www2.auckland.ac.nz/net//Internet/rtfm/meetings/47- adelaide/pp-dist/ [DeCi01] C. Demichelis, P. Cimento: IP Packet Delay Variation Metric for IPPM, <draft-ietf-ippm-ipdv-08.txt>, November 2001 [RFC2680] G. Almes, S. Kalidindi, M. Zekauskas: A One-way Packet Loss Metric for IPPM, September 1999 [ClPB93] K.C. Claffy, George C Polyzos, Hans-Werner Braun: Application of Sampling Methodologies to Network Traffic Characterization, Proceedings of ACM SIGCOMM'93, San Francisco, CA, USA, September 13 - 17, 1993 [GrDM98] Ian D. GRAHAM, Stephen F. DONNELLY, Stele MARTIN, Jed MARTENS, John G. CLEARY: Nonintrusive and Accurate Measurement of Unidirectional Delay and Delay Variation on the Internet, INET'98, Geneva, Switzerland, 21-24 July, 1998 [DuGr00] Nick Duffield, Matthias Grossglauser: "Trajectory Sampling for Direct Traffic Observation", Proceedings of ACM SIGCOMM 2000, Stockholm, Sweden, August 28 - September 1, 2000. [RFC2679] G. Almes, S. Kalidindi, M. Zekauskas: A One-way Delay Metric for IPPM, Request for Comments: 2679, September 1999 [ZsZC01] Tanja Zseby, Sebastian Zander, Georg Carle: Evaluation IPFIX Working Group Expires August 2002 [Page 20]
INTERNET-DRAFT draft-ietf-ipfix-architecture-00.txt Feb. 22, 2002 of Building Blocks for Passive One-way-delay Measurements, Proceedings of Passive and Active Measurement Workshop (PAM 2001), Amsterdam, The Netherlands, April 23-24, 2001 (PAM 2001) [MCFW] Srisuresh, S. et al. "Middlebox Communication Architecture and framework," work in progress. October 2001. [NAT-TERM] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999. [NAT-TRAD] Srisuresh, P. and K. Egevang, "Traditional IP Network address Translator (Traditional NAT)", RFC 3022, January 2001. [PPVPN-FR] Callon, R., Suzuki, M., et al. "A Framework for Provider Provisioned Virtual Private Networks ", work in progress, <draft- ietf-ppvpn-framework-03.txt>, January 2002. [VPN-L2] Rosen, E., "An Architecture for L2VPNs," Internet-draft <draft-ietf-ppvpn-l2vpn-00.txt>, July 2001. [RFC2475] Black, D., Blake, S., Carlson, M., Davies, E., Wang, Z. and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998. [1] Requirements for IP Flow Export, <draft-ietf-ipfx-req-00.txt> <http://www.ietf.org/html.charters/ipfix-charter.html> [2] K.Zhang, et al., "Common Reliable Accounting for Network Element (CRANE)", <draft-kzhang-crane-protocol-02.txt>, February 2002 [3] G. Sadasivan, et al., "Flow Export Architecture", <draft-cisco- ipfix-arch-00.txt>, January 2002 [4] Carlson, James, "PPP Design, Implementation and Debugging", Second Edition . 9. Acknowledgements We like to thank all the people contributing to the requirements discussion on the mailing list, and the design teams for many valuable comments. George Carle Tanja Zseby Paul Calato Dave Plonka Kevin Zhang KC Norseth Benoit Claise Ganesh Sadasivan IPFIX Working Group Expires August 2002 [Page 21]
INTERNET-DRAFT draft-ietf-ipfix-architecture-00.txt Feb. 22, 2002 Vamsi Valluri Ram Gopal Jc Martin Carter Bullard Juergen Quittek Reinaldo Penno Nevil Brownlee Simon Leinen 10. Author's Addresses Paul Calato Riverstone Networks, Inc. 5200 Great America Parkway Santa Clara, CA 95054 USA Phone: +1 (603) 557-6913 Email: calato@riverstonenet.com Benoit Claise Cisco Systems De Kleetlaan 6a b1 1831 Diegem Belgium Phone: +32 2 704 5622 Email: bclaise@cisco.com Ganesh Sadasivan Cisco Systems, Inc. 170 W. Tasman Dr. San Jose, CA 95134 USA Phone: +1 (408) 527-0251 Email: gsadasiv@cisco.com Ram Gopal Nokia 5 Wayside Road, Burlington, MA 01803 Phone:+1 781 993 3685 Email: ram.gopal@nokia.com Man Li Nokia 5 Wayside Road, Burlington, MA 01803 Phone: +1 781 993 3923 Email: man.m.li@nokia.com K.C. Norseth Enterasys Networks 2691 S. Decker Lake Lane Salt Lake City, Utah 84119 Phone: +1 801 887 9823 Email: knorseth@enterasys.com IPFIX Working Group Expires August 2002 [Page 22]
INTERNET-DRAFT draft-ietf-ipfix-architecture-00.txt Feb. 22, 2002 Reinaldo Penno Nortel Networks, Inc. 2305 Mission College Boulevard Building SC9-B1240 Santa Clara, CA 95134 Email: rpenno@nortelnetworks.com Juergen Quittek NEC Europe Ltd. Adenauerplatz 6 69115 Heidelberg Germany Phone: +49 6221 90511-15 EMail: quittek@ccrle.nec.de Cliff Wang SmartPipes Inc. 565 metro Place Dublin, OH 43017 Phone: +1 614 923 6241 Email: cwang@smartpipes.com Kevin Zhang XACCT Technologies, Inc. 2900 Lakeside Drive Santa Clara, CA 95054 Phone +1 301 992 4697 Email: kevin.zhang@xacct.com Tanja Zseby GMD FOKUS Kaiserin-Augusta-Allee 31 10589 Berlin, Germany Phone: +49 30 3463 7153 Email: zseby@fokus.gmd.de 11. Full Copyright Statement "Copyright (C) The Internet Society (date). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into. IPFIX Working Group Expires August 2002 [Page 23]
INTERNET-DRAFT draft-ietf-ipfix-architecture-00.txt Feb. 22, 2002 12. Issues 12.1. MIBS An SNMP MIB module should be made available to monitor the various components and to define, if any, standard configuration objects (Mike Mcfadden, Dave Harrington) 12.2.Relationship to RTFM To be filled ouT IPFIX Working Group Expires August 2002 [Page 24]
