Internet Draft Tanja Zseby Document: <draft-ietf-ipfix-as-08.txt> Fraunhofer FOKUS Expires: November 2006 Elisa Boschi Hitachi Nevil Brownlee CAIDA Benoit Claise Cisco Systems June 2006 IPFIX Applicability draft-ietf-ipfix-as-08.txt Status of this Memo 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 becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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. Copyright Notice Copyright (C) The Internet Society (2006). Zseby, Boschi, Brownlee, Claise [Page 1]
IPFIX Applicability June 2006 Abstract This document describes the applicability of the IP Flow Information Export (IPFIX) protocol for a variety of applications. It shows how applications can use IPFIX, describes the relevant information elements (IEs) and shows opportunities and limitations of the protocol. The document furthermore describes relations of the IPFIX framework to other architectures and frameworks. Zseby, Boschi, Brownlee, Claise [Page 2]
IPFIX Applicability June 2006 Table of Contents 1. Introduction.............................................4 2. Applications of IPFIX....................................4 2.1 Accounting...............................................4 2.1.1 Example.................................................5 2.2 Traffic Profiling........................................7 2.3 Traffic Engineering......................................7 2.4 Network Security.........................................8 2.5 QoS Monitoring..........................................10 2.5.1 Correlating Events from Multiple Observation Points....11 2.5.2 Examples...............................................11 2.6 Inter-Domain Exchange of IPFIX data.....................13 2.7 Export of Derived Metrics...............................13 2.8 Summary.................................................14 3. Relation of IPFIX to Other Frameworks and Protocols.....14 3.1 IPFIX and PSAMP.........................................14 3.2 IPFIX and RMON..........................................15 3.3 IPFIX and IPPM..........................................16 3.4 IPFIX and AAA...........................................16 3.4.1 Connecting via an AAA Client...........................17 3.4.2 Connecting via an Application Specific Module (ASM)....18 3.5 IPFIX and RTFM..........................................19 3.5.1 Architecture...........................................19 3.5.2 Flow Definition........................................19 3.5.3 Configuration and Management...........................20 3.5.4 Data Collection........................................20 3.5.5 Data Model Details.....................................20 3.5.6 Transport Protocol.....................................20 3.5.7 Summary................................................21 4. Limitations.............................................21 4.1 Using IPFIX for other Applications than in RFC3917......21 4.2 Using a Different Transport Protocol than SCTP..........22 4.3 Push vs. Pull Mode......................................22 4.4 Template ID number......................................23 4.5 Exporting Bidirectional Flow Information................23 4.6 IPFIX and IPv6..........................................23 5. Security Considerations.................................24 6. Normative References....................................24 7. Informative References..................................25 8. Acknowledgements........................................27 9. Authors' Addresses......................................27 10. Full Copyright Statement................................28 11. Intellectual Property Statement.........................28 12. Copyright Statement.....................................29 13. Disclaimer..............................................29 Zseby, Boschi, Brownlee, Claise [Page 3]
IPFIX Applicability June 2006 1. Introduction The IPFIX protocol defines how IP Flow information can be exported from routers, measurement probes or other devices. It is intended to provide this information as input to various applications. IPFIX is a general data transport protocol, easily extensible to suit the needs of different applications. This document describes how typical applications that can use the IPFIX protocol. It shows opportunities and limitations of the protocol. Furthermore, the relationship of IPFIX to other frameworks and architectures is described. 2. Applications of IPFIX IPFIX data enables several critical applications. The IPFIX target applications and the requirements that originate from those applications are described in [RFC3917]. Those requirements were used as basis for the design of the IPFIX protocol. This section describes how these target applications can use the IPFIX protocol. Considerations for using IPFIX for other applications than described in [RFC3917] can be found in section 4.1. 2.1 Accounting Usage based accounting is one of the major applications for which the IPFIX protocol has been developed. IPFIX records provide fine-grained measurement results for highly flexible and detailed resource usage accounting. In order to realize usage-based accounting with IPFIX the flow definition has to be chosen in accordance to the tariff model. Flows can be distinguished by various IEs (e.g. packet header fields) from [IPFIX-INFO]. Due to the flexible IPFIX flow definition, arbitrary flow-based accounting models can be realized without extensions to the IPFIX protocol. A tariff can, for instance, be based on individual end-to-end flows, in which case accounting can be realized with a flow definition determined by the quintuple consisting of source address (sourceIPv4Address), destination address (destinationIPv4Address), protocol (protocolIdentifier) and port numbers (e.g., udpSourcePort, udpDestinationPort). Another example is a class-dependent tariff (e.g. in a DiffServ network). In this case flows could be distinguished just by the DiffServ codepoint (DSCP) (ipDiffServCodePoint) and IP addresses (sourceIPv4Address, destinationIPv4Address). The essential elements needed for accounting are the number of transferred Zseby, Boschi, Brownlee, Claise [Page 4]
IPFIX Applicability June 2006 packets and bytes per flow, which can be represented by the per- flow counter IEs (e.g., packetTotalCount, octetTotalCount). For accounting purposes, it would be advantageous to have the ability to use IPFIX flow records as accounting input in an AAA infrastructure. AAA servers then could provide the mapping between user and flow information. Note that the reliability requirements defined in [RFC3917] are not sufficient to guarantee the level of reliability that is needed for many usage-based accounting systems. Particular reliability requirements for accounting systems are discussed in [RFC2975]. 2.1.1 Example Please note: [RFC3330] demands the use of the address block 192.0.2.0/24 for example addresses. In the example below we use two example networks. In order to be conformant to [RFC3330] we divide the given address block into two networks by subnetting with a 25 bit netmask (192.0.2.0/25) as follows: Network A: 192.0.2.0 ... 192.0.2.127 Network B: 192.0.2.128 ... 192.0.2.255 Let's suppose someone has a Service Level Agreement (SLA) in a DiffServ network requiring accounting based on traffic volume. Flows are distinguished by source and destination address. The information to export in this case is: - IPv4 source IP address: sourceIPv4Address in [IPFIX-INFO], with a length of 4 octets - IPv4 destination IP address: destinationIPv4Address in [IPFIX-INFO], with a length of 4 octets - DSCP: ipDiffServCodePoint in [IPFIX-INFO], with a length of 1 octet - Number of octets of the Flow: octetDeltaCount in [IPFIX- INFO], with a length of 4 octets The template set will look as follows: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 2 | Length = 24 octets | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Template ID 256 | Field Count = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| sourceIPv4Address = 8 | Field Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| destinationIPv4Address = 12 | Field Length = 4 | Zseby, Boschi, Brownlee, Claise [Page 5]
IPFIX Applicability June 2006 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| ipDiffServCodePoint = 195 | Field Length = 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| octetDeltaCount = 1 | Field Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The information to be exported might be as listed in the following example table: Src. IP addr. | Dst. IP addr. | DSCP | Octets Number --------------+---------------+--------+-------------- 192.0.2.12 | 192.0.2.144 | 46 | 120868 192.0.2.24 | 192.0.2.156 | 46 | 310364 192.0.2.36 | 192.0.2.168 | 46 | 241239 In the example we use Diffserv CodePoint 46, recommended for the Expedited Forwarding Per Hop Behavior (EF PHB) in [RFC2598]. The Flow Records will then look as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 256 | Length = 43 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 192.0.2.12 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 192.0.2.144 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 46 | 120868 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | 192.0.2.24 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | 192.0.2.156 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | 46 | 310364 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | 192.0.2.36 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | 192.0.2.168 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | 46 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 241239 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Zseby, Boschi, Brownlee, Claise [Page 6]
IPFIX Applicability June 2006 2.2 Traffic Profiling Measurement results reported in IPFIX records can be used for traffic profiling. IPFIX records captured over a long period of time can be used to track and anticipate network growth and usage. Such Information is valuable for trend analysis and network planning. The parameters of interest are determined by the profiling objectives. Example parameters for traffic profiling are flow duration, flow volume, burstiness, the distribution of used services and protocols, the amount of packets of a specific type, etc. [RFC3917]. The distribution of services and protocols in use can be analyzed by configuring appropriate flows keys for flow discrimination. Protocols can be distinguished by the protocolIdentifier IE. Portnumbers (e.g., udpDestinationPort) often provide information about services in use. Those flow keys are defined in [IPFIX-INFO]. If portnumbers are not sufficient for service discrimination, further parts of the packet may be needed. Header fields can be expressed by IEs from [IPFIX-INFO] Packet payload can be reported by using the IE ipPayloadPacketSection in [PSAMP-INFO]. The flow duration can be calculated from the flow time stamp IEs defined in [IPFIX-INFO] (e.g., flowEndMicroseconds - flowStartMicroseconds). The number of packets and number of bytes of a flow are represented in the per-flow counter IEs (e.g., packetTotalCount, octetTotalCount). The burstiness of a flow can be calculated from the flow volume measured at different time intervals. 2.3 Traffic Engineering Traffic engineering aims at the optimization of network resource utilization and traffic performance [RFC2702]. Typical parameters are link utilization, load between specific network, nodes, number, size and entry/exit points of active flows and routing information [RFC3917]. Size of flows in packets and bytes can be reported by IEs packetTotalCount, octetTotalCount. Link utilization can be reported by using a coarse grained flow definition (e.g. based on identifier IEs such as egressInterface or ingressInterface) and per-flow counter IEs (e.g. packetTotalCount, octetTotalCount) defined in [IPFIX-INFO]. Zseby, Boschi, Brownlee, Claise [Page 7]
IPFIX Applicability June 2006 The load between specific network nodes can be reported in the same way if one interface of a network node receives only traffic from exactly one neighbor node (as usually the case). If the ingress interface is not sufficient for an unambiguous identification of the neighbor node, sub-IP header fields IEs (like sourceMacAddress) can be added as flow keys. The IE observedFlowTotalCount provides the number of all flows exported for the observation domain since the last initialization of the metering process [IPFIX-INFO]. If this IE is exported at subsequent points in time, one can derive the number of active flows in a specific time interval from the difference of the reported counters. The configured flow termination criteria have to be taken into account to interpret that numbers correctly. Entry and exit points can be derived from flow records if metering processes are installed at all edges of the network and results are mapped in accordance to flow keys. For this and other analysis methods that require the mapping of records from different observation points, the same flow keys should be used at all observation points. The path that packets take through a network can be investigated by using hash-based sampling techniques as described in [DuGr00] and [PSAMP-TECH]. For this IEs from [PSAMP-INFO] are needed. Neither [IPFIX-INFO] nor [PSAMP-INFO] defines IEs suitable for exporting routing information. 2.4 Network Security Attack and intrusion detection are among the IPFIX target applications described in [RFC3917]. Due to the enormous amount of different network attack types, only general requirements could be addressed in [RFC3917]. IPFIX can export flow information for arbitrary flow definitions as defined in [IPFIX-PROTO]. Packet information can be exported with IPFIX by using the additional information elements described in [PSAMP-INFO]. With this theoretically all information about traffic in the network at IP layer and above is accessible. This data can be used either directly to detect anomalies or can provide the basis for further post processing to generate more complex attack detection metrics. Depending on the attack type different metrics are useful. A sudden increase of traffic load can be a hint that an attack has been launched. The overall traffic at an observation point can Zseby, Boschi, Brownlee, Claise [Page 8]
IPFIX Applicability June 2006 be monitored using per-flow counter IEs like packetTotalCount, octetTotalCount as described in 2.3. The number of active flows can be monitored by regular reporting of the observedFlowTotalCount. A sudden increase of flows from different sources to one destination may be caused by an attack on a specific host or network node using spoofed addresses. Many flows to the same machine but on different ports or many flows to the same port and different machines may be an indicator for vertical or horizontal port scanning activities. An unusual ratio of TCP-SYN to TCP-FIN packets can refer to SYN-flooding. Worms may leave signatures in traffic patterns. The amount of metrics useful for attack detection is as diverse as attack patterns themselves. Attackers adapt rapidly to circumvent detection methods and try to hide attack patterns using slow or stealth attacks. Furthermore, unusual traffic patterns are not always caused by malicious activities. A sudden traffic increase may be caused by legitimate users who seek access to a recently published content. Strange traffic patterns may also be caused by mis-configuration. The difficult task is the separation of good from bad packets to prepare and launch counteraction. This may require a deeper look into packet content by using further header field IEs from [IPFIX-INFO] and/or packet payload from IE ipPayloadPacketSection in [PSAMP-INFO]. Multi-step analysis techniques may be useful, e.g., to launch an in-depth analysis (e.g. based on packet information) in case the flow information shows suspicious patterns. In order to supervise traffic to a specific host or network node one has to apply filtering methods as those described in [PSAMP-TECH]. Mapping the two directions of a communication is often useful for checking correct protocol behavior (see section 4.5). A correlation of IPFIX data from multiple observation points (see section 2.5.1) allows assessing the propagation of an attack and can help to locate its source. The integration of previous measurement results helps to review traffic changes over time for detection of traffic anomalies and provides the basis for forensic analysis. A standardized storage format for IPIFX data would support the offline analysis of data from different operators. Nevertheless, capturing full packet traces at all observation points in the network is not viable due to resource limitations Zseby, Boschi, Brownlee, Claise [Page 9]
IPFIX Applicability June 2006 and privacy concerns. Therefore metrics should be chosen wisely to allow a solid detection with minimal resource consumption. Resources can be saved for instance by using coarser grained flow definitions, reporting pre-processed metrics (e.g. with additional information elements) or deployment of sampling methods. Detecting security incidents in real-time often requires the pre-processing of data already at the measurement device. Immediate data export in case of a potential incident is desired. IPIFX supports such source-triggered exporting of information due to the push model approach. Nevertheless, further exporting criteria have to be implemented to export IPFIX records upon incident detection events and not only upon flow end or fixed time intervals. Security incidents can become a threat to IPFIX processes themselves (see also security considerations in [IPFIX-PROTO]). If an attack generates a large amount of flows (e.g. by sending packets with spoofed addresses or simulating flow termination) exporting and collecting process may get overloaded by the immense amount of records that are exported. A flexible deployment of packet or flow sampling methods can prevent the exhaustion of resources. Intrusion detection would profit from the combination of IPFIX functions with AAA functions (see section 3.4). Such an interoperation enables further means for attacker detection, advanced defense strategies and secure inter-domain cooperation. 2.5 QoS Monitoring QoS monitoring is one target application of the IPFIX protocol [RFC3917]. QoS monitoring is the passive observation of the transmission quality for single flows or traffic aggregates in the network. One example of its use is the validation of QoS guarantees in service level agreements (SLAs). Typical QoS parameters are loss [RFC2680], one-way [RFC2679] and round-trip delay [RFC2681] and delay variation [RFC3393]. The calculation of those QoS metrics requires per-packet processing. Reporting packet information with IPFIX is possible by simply considering a single packet as flow. [IPFIX-PROTO] also allows the reporting of multiple identical information elements in one flow record. Using this feature for reporting information about multiple packets in one record would require additional agreement on semantics regarding the order of information elements (e.g. which timestamp belongs to which packet payload in a sequence of information elements). [PSAMP-INFO] defines useful additional Zseby, Boschi, Brownlee, Claise [Page 10]
IPFIX Applicability June 2006 information elements for exporting per packet information with IPFIX. 2.5.1 Correlating Events from Multiple Observation Points Some QoS metrics require the correlation of data from multiple observation points. For this the clocks of the involved metering processes must be synchronized. Furthermore, it is necessary to recognize that the same packet was observed at different observation point. This can be done by capturing parts of the packet content (packet header and/or parts of the payload) that do not change on the way to the destination. Based on the packet content it can be recognized when the same packet arrived at another observation point. To reduce the amount of measurement data a unique packet ID can be calculated from the packet content e.g. by using a CRC or hash function instead of transferring and comparing the unprocessed content. Considerations on collision probability and efficiency of using such packet IDs are described in [GrDM98, DuGr00, ZsZC01]. IPFIX allows the reporting of several IP and transport header fields (see section 5.3 and 5.4 in [IPFIX-INFO]). Using only those fields for packet recognition or ID generation can be sufficient in scenarios where those header fields vary a lot among subsequent packets, where a certain amount of packet ID collisions is tolerable or where packet IDs need to be unique only for a small time interval. For including packet payload information the information element ipPayloadPacketSection defined in [PSAMP-INFO] can be used. The information element ipHeaderPacketSection can also be used. But header fields that can change on the way from source to destination have to be excluded from the packet ID generation, because they may differ at different observation points. For reporting packet IDs generated by a CRC or hash function the information element digestHashValue defined in [PSAMP-INFO] can be used. 2.5.2 Examples The following examples show which information elements need to be reported by IPFIX to generate specific QoS metrics. As an alternative the metrics can be generated directly at the exporter and IPIFX can be used to export the metrics (see section 2.7) Zseby, Boschi, Brownlee, Claise [Page 11]
IPFIX Applicability June 2006 2.5.2.1 RTT measurements with packet pair matching (single-point) The passive measurement of round-trip-times (RTT) can be performed by using packet pair matching techniques as described in [Brow00]. For the measurements, request/response packet pairs from protocols such as DNS, ICMP, SNMP or TCP (SYN/SYN_ACK, DATA/ACK) are utilized to passively observe the RTT [Brow00]. This technique requires the correlation of data from both directions. Required information elements per packet (DNS example): - Packet arrival time: observationTimeMicroseconds [PSAMP-INFO] - DNS header: ipPayloadPacketSection [PSAMP-INFO] Required functions: - Recognition of request/response packet pairs Remarks: - Requires information elements from [PSAMP-INFO] - observationTimeMicroseconds can be substituted by flowStartMicroseconds [IPFIX-INFO], because a single packet can be represented as a flow. - If time values with a higher granularity are needed observationTimeNanoseconds can be used. 2.5.2.2 One-way Delay Measurements (multi-point) Passive one-way-delay measurements require the collection of data at two observation points. The recognition of packets at the second observation point can be based on parts of the packet content directly. A more efficient way is to use a packet ID (generated from packet content). Required information elements per packet (with packet ID): - Packet arrival time: observationTimeMicroseconds [PSAMP-INFO] - Packet ID: digestHashValue [PSAMP-INFO] Required functions: - packet ID generation - delay calculation (from arrival times at the two observation points) Remarks: - Requires information elements from [PSAMP-INFO] - observationTimeMicroseconds can be substituted by flowStartMicroseconds [IPFIX-INFO], because a single packet can be represented as a flow. Zseby, Boschi, Brownlee, Claise [Page 12]
IPFIX Applicability June 2006 - If time values with a higher granularity are needed observationTimeNanoseconds can be used. - The amount of content used for ID generation influences the number of collisions (different packets that map to the same ID) that can occur. Investigations on this and other considerations on packet ID generation can be found in [GrDM98], [DuGr00], and [ZsZC01]. 2.6 Inter-Domain Exchange of IPFIX data IPFIX data can be used to share information with neighbor providers. A few recommendations should to be considered if IPFIX records travel over the public Internet compared to its usage within a single domain. First of all, security threats are higher if data travels over the public Internet. Protection against disclosure or manipulation of data is even more important than for intra-domain usage. Therefore IPsec or Transport Layer Security (TLS) should be used as described in [IPFIX-PROTO]. Furthermore data transfer should be congestion-aware in order to allow untroubled co-existence with other data flows. That means transport over SCTP or TCP is required. Some ISPs are still reluctant to share information due to concerns that competing ISPs might exploit network information from neighbor providers to strengthen their own position in the market. Nevertheless, technical needs have already triggered the exchange of data in the past (e.g. exchange of routing information by BGP). The need to provide inter-domain guarantees is one big incentive to increase inter-domain cooperation. The necessity to defend networks against current and future threats (denial of service attacks, worm distributions, etc.) will hopefully increase the willingness to exchange measurement data between providers. 2.7 Export of Derived Metrics The IPFIX protocol is used to transport flow and packet information to provide the input for the calculation of a variety metrics (e.g. for QoS validation or attack detection). IPFIX can also be used to transfer these metrics directly, e.g. if the metric calculation is co-located with measurement and exporting process. It doesn't matter which measurement and post-processing functions are applied to generate a specific metric. IPFIX can Zseby, Boschi, Brownlee, Claise [Page 13]
IPFIX Applicability June 2006 be used to transport the results from passive and active measurements and from post-processing operations. For the reporting of derived metrics additional information elements need to be defined. 2.8 Summary The following table shows an overview of the information elements required for the target applications described in [RFC3917] (M-mandatory, R-recommended, O-optional). | Application |[IPFIX-INFO]| [PSAMP-INFO] | additional IEs | +-------------+------------+--------------+-----------------+ | Accounting | M | - | - | +-------------+------------+--------------+-----------------+ | Traffic | M | O | - | | Profiling | | | | +-------------+------------+--------------+-----------------+ | Traffic | M | - | O | | Engineering | | | (routing info) | +-------------+------------+--------------+-----------------+ | Attack | M | R | R | | Detection | | |(derived metrics)| +-------------+------------+--------------+-----------------+ | QoS | M | M | O | | Monitoring | |(most metrics)|(derived metrics)| +-------------+------------+--------------+-----------------+ For accounting the IEs in [IPFIX-INFO] are sufficient. For traffic profiling additionally IEs from [PSAMP-INFO] can be useful to gain more insight into the traffic. For traffic engineering flow information from [IPFIX-INFO] is sufficient but it would profit from routing information, which could be exported by IPFIX. Attack detection usually profits from further insight into the traffic. This can be achieved with IEs from [PSAMP-INFO]. Furthermore the reporting of derived metrics in additional IEs would be useful. Most QoS metrics require the use of IEs from [PSAMP-INFO]. IEs from [PSAMP-INFO]are also useful for the mapping of results from different observation points as described in section 2.5.1. 3. Relation of IPFIX to Other Frameworks and Protocols 3.1 IPFIX and PSAMP PSAMP defines packet selection methods, their configuration at routers and probes and the reporting of packet information. Zseby, Boschi, Brownlee, Claise [Page 14]
IPFIX Applicability June 2006 PSAMP uses IPIFX as basis for exporting packet information [PSAMP-PROTO]. [PSAMP-INFO] describes further information elements for exporting packet information and reporting configuration information. The main difference between IPFIX and PSAMP is that IPFIX addresses the export of flow records whereas PSAMP addresses the export of packet records. Furthermore, PSAMP explicitly addresses remote configuration. It defines a MIB for the configuration of packet selection processes. Remote configuration is not (yet) addressed in IPFIX, but one could consider extending the PSAMP MIB to also allow configuration of IPFIX processes. 3.2 IPFIX and RMON RMON [RFC3577] is a widely used monitoring system that gathers traffic data from RMON Agents in network devices. One major difference between RMON and IPFIX is that RMON uses SNMP for data export whereas IPIFX defines an own push-oriented protocol. RMON defines MIBs that contain the information to be exported. In IPFIX the data to be exported is defined as information elements. The most relevant MIBs for a comparison with IPFIX are the Application Performance Measurement MIB (APM-MIB) [RFC3729] and the Transport Performance Metrics MIB (TPM-MIB) [RFC4150]. The APM-MIB has a complex system for tracking user application performance, with reporting about transactions and SLA threshold notification-trigger configuration, and persistence across DHCP lease expirations. It requires full RMON2-MIB protocolDirTable implementation. The APM-MIB reports the performance of transactions. A transaction is a service oriented term and describes the data exchange from the transaction start (when a user requests a service) until its completion. The performance parameters include response times, throughput, streaming responsiveness and availability of services. The RMON transaction concept differs from the IPFIX flow concept. A flow is a very generic term and allows to group IP packets in accordance to common properties. In contrast to this, the term transaction is service-oriented and contains all data exchange required for service completion. In order to report such data with IPFIX one would probably need a specific combination of multiple flows and the ability to map those to the transaction. Due to the service-orientated focus of APM, also the required metrics differ. For instance, the RMON APM requires a metric for the responsiveness of services. Such metrics are not addressed in IPFIX. Zseby, Boschi, Brownlee, Claise [Page 15]
IPFIX Applicability June 2006 Furthermore, the APM-MIB allows the configuration of the transaction type to be monitored, i.e., it addresses the configuration of the metering process, which is currently not addressd in IPFIX. The APM MIB could be considered as an extension of the IPFIX metering process where the application performance of a combination of multiple flows is measured. If appropriate IEs would be defined in the IPFIX information model and the IPFIX device would support the APM MIB data collection, the solutions could be complimentary. That means one could use IPFIX to export APM MIB transaction information. The TPM-MIB breaks out the APM-MIB transactions into sub- application level transaction. For instance a web request is broken down into DNS, TCP and HTTP sub-transactions. Again sub- application level transaction could be measured using IPFIX with an appropriate flow definition and by combining the reporting of both directions of the data transfer (for reporting bi- directional flow information see also section 4.5). The TPM-MIB requires APM-MIB and RMON2-MIB. 3.3 IPFIX and IPPM The IPFIX protocol can be used to carry IPPM network performance metrics or information that can be used to calculate those metrics (see sections 2.5 and 2.7). 3.4 IPFIX and AAA AAA defines a protocol and architecture for authentication, authorization and accounting for service usage [RFC2903]. The DIAMETER protocol [RFC3588] is used for AAA communication, which is needed for network access services (Mobile IP, NASREQ, and ROAMOPS). The AAA architecture [RFC2903] provides a framework for extending AAA support to other services. DIAMETER defines the exchange of messages between AAA entities, e.g. between AAA clients at access devices and AAA servers, and among AAA servers. DIAMETER is used for the transfer of accounting records. In order to form accounting records for usage-based accounting measurement data from the network is required. IPFIX defines a protocol to export such data from routers, measurement probes and other devices. Therefore it looks promising to connect those two architectures. As shown in section 2.1 accounting can be realized without an AAA infrastructure. Accounting applications can directly incorporate an IPFIX collecting process to receive IPFIX records with information about the transmitted volume. Nevertheless, if an AAA infrastructure is in place, the cooperation between IPFIX Zseby, Boschi, Brownlee, Claise [Page 16]
IPFIX Applicability June 2006 and AAA provides many valuable synergistic benefits. IPFIX records can provide the input for AAA accounting functions and provide the basis for the generation of DIAMETER accounting records. Further potential features include the mapping of a user ID to flow information (by using authentication information) or facilitating the secure authorized exchange of DIAMETER accounting records with neighbor domains. The last feature is especially useful in roaming scenarios where the user connects to a foreign network and the home provider generates the invoice. Coupling an IPFIX collecting process with AAA functions has also high potential for intrusion and attack detection. AAA controls network access and maintains data about users and nodes. AAA functions can help to identify the source of malicious traffic. They are able to deny access to suspicious users or nodes. Therefore coupling those functions with an IPFIX collecting process can provide an efficient defense against network attacks. Sharing IPFIX records (either directly or encapsulated in DIAMETER) with neighbor providers allows an efficient inter- domain attack detection. The AAA infrastructure can also be used to configure measurement functions in the network as proposed in [RFC3334]. Two possibilities exist to connect IPFIX and AAA: - Connecting via an AAA Client - Connecting via an Application Specific Module (ASM) Both are explained in the following sections. The approaches only require few additional functions. They do not require any changes to IPFIX or DIAMETER. 3.4.1 Connecting via an AAA Client One possibility of connecting IPFIX and AAA is to run an AAA client on the IPFIX collector. This client can generate DIAMETER accounting messages and send them to an AAA server. The mapping of the flow information to a user ID can be done in the AAA server by using data from the authentication process. DIAMETER accounting messages can be sent to the accounting application or to other AAA servers (e.g. in roaming scenarios). +---------+ DIAMETER +---------+ | AAA-S |------------->| AAA-S | +---------+ +---------+ ^ | DIAMETER Zseby, Boschi, Brownlee, Claise [Page 17]
IPFIX Applicability June 2006 | | +--+--------+--+ | | AAA-C | | + +--------+ | | | | Collector | +--------------+ ^ | IPFIX | +------------+ | Exporter | +------------+ Figure 2: IPFIX collector connects to AAA server via AAA client 3.4.2 Connecting via an Application Specific Module (ASM) Another possibility is to directly connect the IPFIX collector with the AAA server via an application specific module (ASM). Application specific modules have been proposed by the IRTF AAA architecture research group (AAARCH) in [RFC2903]. They act as an interface between AAA server and service equipment. In this case the IPFIX collector is part of the ASM. The ASM acts as an interface between the IPFIX protocol and the input interface of the AAA server. The ASM translates the received IPFIX data into an appropriate format for the AAA server. The AAA server then can add information about the user ID and generate a DIAMETER accounting record. This accounting record can be sent to an accounting application or to other AAA servers. +---------+ DIAMETER +---------+ | AAA-S |------------->| AAA-S | +---------+ +---------+ ^ | +------------------+ | ASM | | +------------+ | | | Collector | | +------------------+ ^ | IPFIX | +------------+ | Exporter | +------------+ Zseby, Boschi, Brownlee, Claise [Page 18]
IPFIX Applicability June 2006 Figure 3: IPFIX connects to AAA server via ASM 3.5 IPFIX and RTFM The Real-time Traffic Flow Measurement (RTFM) working group defined an architecture for flow measurement [RFC2722]. This section compares the Real-time Traffic Flow Measurement (RTFM) framework with the IPFIX framework. 3.5.1 Architecture The RTFM architecture is very similar to the IPFIX architecture. It defines meter, meter reader and a manager as building blocks of the measurement architecture. The manager configures the meter and the meter reader collects data from the meter. In RTFM the building blocks communicate via SNMP. The IPFIX architecture [IPFIX-ARCH] defines metering, exporting and collecting processes. IPFIX speaks about processes instead of devices to clarify that multiple of those processes may be collocated on the same machine. Both definitions do not contradict each other. One could see the metering process as part of the meter and the collecting process as part of the meter reader. One difference is that IPFIX currently does not define a managing process, because remote configuration was at least initially out of scope for the working group. 3.5.2 Flow Definition RTFM and IPFIX both consider flows as a group of packets which share a common set of properties. A flow is completely specified by that set of values, together with a termination criterion (like inactivity timeout). A difference is that RTFM defines flows as bidirectional. An RTFM meter matches packets from B to A and A to B as separate parts of a single flow, and maintains two sets of packet and byte counters, one for each direction. IPFIX does not explicitly state whether flows are uni- or bidirectional. Nevertheless information elements for describing flow properties were defined only for one direction in [IPFIX- INFO]. Nevertheless, there are several solutions for reporting bi-directional flow information (see section 4.5). Zseby, Boschi, Brownlee, Claise [Page 19]
IPFIX Applicability June 2006 3.5.3 Configuration and Management In RTFM, remote configuration is the only way to configure a meter. This is done by using SNMP and a specific Meter MIB [RFC 2720]. The IPFIX group currently does not address IPFIX remote configuration. IPFIX metering processes export the layout of data within their templates, from time to time. IPFIX collecting processes use that template information to determine how they should interpret the IPFIX flow data they receive. 3.5.4 Data Collection One major difference between IPFIX and RTFM is the data collection model. RTFM retrieves data in pull mode whereas IPFIX uses a push mode model to send data to collecting processes. An RTFM meter reader pulls data from a meter by using SNMP. SNMP security on the meter determines whether a reader is allowed to pull data from it. An IPFIX exporting process is configured to export records to a specified list of IPFIX collecting processes. The condition when to send IPFIX records (e.g. flow termination) has to be configured in the exporting or metering process. 3.5.5 Data Model Details RTFM defines all its attributes in the RTFM Meter MIB [RFC 2720]. IPFIX information elements are defined in [IPFIX-INFO]. RTFM uses continuously-incrementing 64-bit counters for the storage of the number of packets of a flow. The counters are never reset and just wrap back to zero if the maximum value is exceeded. Flows can be read at any time. The difference between counter readings gives the counts for activity in the interval between readings. IPFIX allows absolute (totalCounter) and relative counters (deltaCounter) [IPFIX-INFO]. The totalCounter is never reset and just wraps to zero if values are too large, exactly as the counters used in RTFM. The deltaCounter is reset to zero when the associated flow record is exported. 3.5.6 Transport Protocol RTFM has a standards-track Meter MIB [RFC2720], which is used both to configure a meter and to store metering results. The Zseby, Boschi, Brownlee, Claise [Page 20]
IPFIX Applicability June 2006 MIB provides a way to read lists of attributes with a single Object Identifier (called a 'package'), which reduces the SNMP overhead for flow data collection. SNMP, of course, normally uses UDP as its transport protocol. Since RTFM requires a reliable flow data transport system, an RTFM meter reader must time out and resend unanswered SNMP requests. Apart from being clumsy, this can limit the maximum data transfer rate from meter to meter reader. IPFIX is designed to work over a variety of different transport protocols. SCTP [RFC2960] and SCTP-PR [RFC3758] are mandatory. UDP and TCP are optional. In addition, the IPFIX protocol encodes data much more efficiently than SNMP does, hence IPFIX has lower data transport overheads than RTFM. 3.5.7 Summary IPFIX exports flow information in push model by using SCTP, TCP or UDP. It currently does not address remote configuration. RTFM data collection is using the pull model and runs over SNMP. RTFM addresses remote configuration which also runs over SNMP. Both frameworks allow a very flexible flow definition, although RTFM is based on a bi-directional flow definition. 4. Limitations The goal of this section is to show the limitations of IPFIX and to give advice where not to use IPFIX or in which cases additional considerations are required. 4.1 Using IPFIX for other Applications than in RFC3917 IPFIX provides a generic export mechanism. Due to its template based structure, it is a quite flexible protocol. Network operators and users may want to use it also for other applications than those described in [RFC3917]. Apart from sending raw flow information it can be used to send aggregated or post-processed data. For this new templates and information elements can be defined if needed. Due to its push mode operation IPFIX is also suited to send network initiated events like alarms and other notifications. It can be used for exchanging information among network nodes to autonomously improve network operation. Nevertheless, the IPFIX design is based on the requirements that originate only from the target applications stated in [RFC Zseby, Boschi, Brownlee, Claise [Page 21]
IPFIX Applicability June 2006 3917]. Using IPFIX for other purposes requires a careful checking of IPFIX capabilities against application requirements. Only with this, can one decide whether IPFIX is a suitable protocol to meet the needs of a specific application. 4.2 Using a Different Transport Protocol than SCTP SCTP is the preferred protocol for IPFIX, i.e. a conforming implementation must work over SCTP. Although IPFIX can also work over TCP or UDP, both protocols have drawbacks [IPFIX-PROTO]. Users should make sure they have good reasons befor using protocols other than SCTP in a specific environment. 4.3 Push vs. Pull Mode IPFIX works in push mode. That means IPFIX records are automatically exported without waiting for a request. The responsibility for initiating a data export lies with the exporting process. Criteria for exporting data need to be configured at the exporting process. Therefore push mode has more benefits if the trigger for data export is related to events at the exporting process (e.g. flow termination, memory shortage due to large amount of flows, etc.). If the protocol used pull mode, the exporting process would need to wait for a request to send the data. With push mode it can send data immediately e.g. before memory shortage would require a discarding of data. With push mode one can prevent the overloading of resources at the exporting process by simply exporting the information as soon as certain thresholds are about to exceed. Therefore exporting criteria are often related to traffic characteristics (e.g. flow timeout) or resource limitations (e.g. size of flow cache). But traffic characteristics are usually quite dynamic and often impossible to predict. If those are used to trigger flow export, the exporting rate and the resource consumption for flow export becomes variable and unpredictable. Pull mode has advantages if the trigger for data export is related to events at the collecting process (e.g. a specific application requests immediate input). In a pull mode, a request could simply be forwarded to the exporting process. In a push mode, the exporting configuration must be changed to trigger the export of the requested data. Furthermore, with pull mode one can prevent the overloading of Zseby, Boschi, Brownlee, Claise [Page 22]
IPFIX Applicability June 2006 the collecting process by the arrival of more records than it can process. Whether this is a relevant drawback depends on the flexibility of the IPFIX configuration and how IPFIX configuration rules are implemented. 4.4 Template ID number The IPFIX specification limits the different template ID numbers that can be assigned to the newly generated template records in an observation domain. In particular, template IDs up to 255 are reserved for Template or option sets (or other sets to be created) and template IDs from 256 to 65535 are assigned to data sets. In the case of many exports requiring many different templates, the set of Template IDs could be exhausted. 4.5 Exporting Bidirectional Flow Information Although IPFIX does not explicitly state that flows are unidirectional, information elements that describe flow characteristics are defined only for one direction in [IPFIX- INFO]. [IPFIX-PROTO] allows the reporting of multiple identical information elements in one flow record. With this information elements for forward and reverse direction can be reported in one flow record. But this is not sufficient. Using this feature for reporting bidirectional flow information would require an agreement on the semantic of information elements (e.g. first counter is counter for the forward direction, second counter for reverse direction). Another option is to use two adjacent flow records to report both directions of a bidirectional flow separately. This approach requires additional means for mapping those records and is quite inefficient due to the redundant reporting of flow keys. 4.6 IPFIX and IPv6 There are two issues to consider: - Generation and reporting of IPFIX records about IPv6 traffic - Exporting IPFIX records over IPv6 Zseby, Boschi, Brownlee, Claise [Page 23]
IPFIX Applicability June 2006 The generation and reporting of IPFIX records about IPv6 traffic is possible as appropriate information elements exist in [IPFIX- INFO]. Exporting IPFIX records over IPv6 is not explicitly addressed in [IPFIX-PROTO]. Since IPFIX runs over SCTP, SCTP-PR, UDP or TCP, it is trivial to run IPFIX over IPv6 networks, provided that the transport protocol being used to carry IPFIX is running on the IPv6 network. 5. Security Considerations This document describes the usage of IPFIX in various scenarios. Security requirements for IPFIX target applications and security considerations for IPFIX are addressed in [RFC3917] and [IPFIX- PROTO]. Those requirements have to be met for the usage of IPFIX. To our current knowledge, the usage scenarios proposed in section 2 do not induce further security hazards. Section 3 of this document describes how IPFIX can be used in combination with other frameworks. New security hazards can arise when two individually secure frameworks are combined. For the combination of AAA with IPFIX an application specific module (ASM) or an IPFIX collector can function as transit point for the messages. It has to be ensured that at this point the applied security mechanisms (e.g. encryption of messages) are maintained. 6. IANA Considerations This document has no actions for IANA. 7. Normative References [IPFIX-INFO] J. Quittek, S. Bryant, J. Meyer, "Information Model for IP Flow Information Export", Internet Draft <draft-ietf-ipfix-info-07>, work in progress, May 2005 [IPFIX-PROTO] B. Claise (Editor), "IPFIX Protocol Specification", Internet Draft <draft-ietf-ipfix-protocol-21.txt>, work in progress, April 2006 [PSAMP-INFO] T. Dietz, F. Dressler, G. Carle, B. Claise, "Information Model for Packet Sampling Exports", Internet Draft <draft-ietf-psamp-info-04.txt>, work in progress, March 2006 Zseby, Boschi, Brownlee, Claise [Page 24]
IPFIX Applicability June 2006 [RFC3917] J. Quittek, T. Zseby, B. Claise, S. Zander, "Requirements for IP Flow Information Export", RFC 3917, October 2004 8. Informative References [Brow00] Nevil Brownlee, "Packet Matching for NeTraMet Distributions", http://www2.auckland.ac.nz/net//Internet/rtfm/meeti ngs/47-adelaide/pp-dist/ [DuGr00] Nick Duffield, Matthias Grossglauser, "Trajectory Sampling for Direct Traffic Observation", Proceedings of ACM SIGCOMM 2000, Stockholm, Sweden, August 28 - September 1, 2000 [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 [IPFIX-ARCH] G. Sadasivan, N. Brownlee, B. Claise, J. Quittek, "Architecture for IP Flow Information Export", Internet Draft <draft-ietf-ipfix-architecture- 08.txt>, work in progress, March 2005 [PSAMP-PROTO] Benoit Claise (Ed.), Packet Sampling (PSAMP) Protocol Specifications, Internet Draft <draft- ietf-psamp-protocol-04.txt>, work in progress, March 2006 [PSAMP-TECH] T. Zseby, M. Molina, N. Duffield, S. Niccolini, F. Raspall, "Sampling and Filtering Techniques for IP Packet Selection" Internet Draft <draft-ietf-psamp- sample-tech-07.txt>, work in progress, July 2005 [RFC2598] V. Jacobson, K. Nichols, K. Poduri, "An Expedited Forwarding PHB", RFC 2598, June 1999 [RFC2679] G. Almes, S. Kalidindi, M. Zekauskas, "A One-way Delay Metric for IPPM", RFC 2679, September 1999 [RFC2680] G. Almes, S. Kalidindi, M. Zekauskas, "A One-way Packet Loss Metric for IPPM",RFC 2680, September 1999 Zseby, Boschi, Brownlee, Claise [Page 25]
IPFIX Applicability June 2006 [RFC2681] G. Almes, S. Kalidindi, M. Zekauskas, "A Round-trip Delay Metric for IPPM", RFC 2681, September 1999 [RFC2702] D. Awduche, J. Malcolm, J. Agogbua, M. O'Dell, J. McManus, "Requirements for Traffic Engineering Over MPLS", RFC 2702, September 1999 [RFC2722] Brownlee, N., Mills, C., G. Ruth, "Traffic Flow Measurement: Architecture", RFC 2722, October 1999 [RFC2903] C. de Laat, G. Gross, L. Gommans, J. Vollbrecht, D. Spence, "Generic AAA Architecture", RFC 2903, August 2000 [RFC2960] R. Stewart (ed.) "Stream Control Transmission Protocol", RFC 2960, October 2000 [RFC2975] B. Aboba, J. Arkko, D. Harrington, "Introduction to Accounting Management", RFC 2975, October 2000 [RFC3330] IANA, "Special-Use IPv4 Addresses", RFC 3330 September 2002 [RFC3334] T. Zseby, S. Zander, G. Carle, "Policy-Based Accounting", RFC 3334, October 2002 [RFC3393] C. Demichelis, P. Cimento, "IP Packet Delay Variation Metric for IPPM", RFC 3393, November 2002 [RFC3577] S. Waldbusser, R. Cole, C. Kalbfleisch, D.Romascanu, "Introduction to the Remote Monitoring (RMON) Family of MIB Module", RFC 3577, August 2003 [RFC3588] P. Calhoun, J. Loughney, E. Guttman, G. Zorn, J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003 [RFC3729] S. Waldbusser, "Application Performance Measurement MIB", RFC 3729, March 2004 [RFC3758] R. Stewart, M. Ramalho, Q. Xie, M. Tuexen, P. Conrad, "Stream Control Transmission Protocol (SCTP) Partial Reliability Extension", RFC 3758, May 2004 [RFC2720] N. Brownlee, Traffic Flow Measurement: Meter MIB, RFC2720 October 1999 Zseby, Boschi, Brownlee, Claise [Page 26]
IPFIX Applicability June 2006 [RFC4150] R. Dietz, R. Cole, "Transport Performance Metrics MIB", RFC 4150, August 2005 [ZsZC01] T. Zseby, S. Zander, G. Carle, "Evaluation 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 9. Acknowledgements We would like to thank the following persons for their contribution, discussion on the mailing list and valuable comments: Sebastian Zander Robert Loewe Reinaldo Penno Lutz Mark Andy Biermann Part of the work has been developed in the research project 6QM co-funded with support from the European Commission. 10.Authors' Addresses Tanja Zseby Fraunhofer Institute for Open Communication Systems (FOKUS) Kaiserin-Augusta-Allee 31 10589 Berlin, Germany Phone: +49 30 3463 7153 Email: zseby@fokus.fhg.de Elisa Boschi Hitachi Europe SAS Immeuble Le Theleme 1503 Route des Dolines 06560 Valbonne, France Phone: +33 4 89874180 Email: elisa.boschi@hitachi-eu.com Nevil Brownlee CAIDA (UCSD/SDSC) 9500 Gilman Drive La Jolla, CA 92093-0505 Zseby, Boschi, Brownlee, Claise [Page 27]
IPFIX Applicability June 2006 Phone : +1 858 534 8338 Email : nevil@caida.org Benoit Claise Cisco Systems De Kleetlaan 6a b1 1831 Diegem Belgium Phone: +32 2 704 5622 Email: bclaise@cisco.com 11.Full Copyright Statement "Copyright (C) The Internet Society (2006). 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. 12. 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. Zseby, Boschi, Brownlee, Claise [Page 28]
IPFIX Applicability June 2006 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. 13. Copyright Statement Copyright (C) The Internet Society (2006). 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. 14. Disclaimer 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. Zseby, Boschi, Brownlee, Claise [Page 29]
