INTERNET-DRAFT Expires: February 2003 INTERNET-DRAFT Internet Draft Paul Calato Document: draft-calato-ipfix-lfap-eval-00.txt Riverstone Networks Expires: January 2003 August 2002 Evaluation Of Protocol LFAP Against IPFIX Requirements Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of [RFC 2026]. 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 Distribution of this document is unlimited. Copyright Notice Copyright (C) The Internet Society (2001). All Rights Reserved. Abstract This document provides an evaluation of the applicability of the LFAP protocol as an IPFIX protocol. It compares the properties and capabilities of the LFAP protocol to the IPFIX requirements version 05 [IPFIX- REQ]. Calato Informational [Page 1] INTERNET-DRAFT IPFIX LFAP Protocol Evaluation August 2002 Table of Contents 1. INTRODUCTION ......................................................4 2. ARCHITECTURAL CONSIDERATIONS ......................................5 2.1 LFAP ARCHITECTURE HIGHLIGHTS ...................................6 2.1.1. Flow Records ...............................................6 2.1.2. Information Model ..........................................6 2.1.3. Data Model .................................................6 2.1.4. Scalability ................................................6 2.1.5. Security ...................................................7 2.1.6. Statistics .................................................7 2.1.7. Protocol Maturity ..........................................7 2.2 LFAP PROTOCOL OVERVIEW .........................................8 2.2.1. LFAP Flow Ids ..............................................9 2.2.2. Periodic reporting versus singular reporting ...............9 2.2.3. Protocol Example ..........................................10 2.3 GENERAL APPLICABILITY .........................................11 2.3.1. Requirements Section 2.1 IP Traffic Flow ..................11 2.3.2. Requirements Section 2.2 Observation Point ................11 2.3.3. Requirements Section 2.3 Metering .........................11 2.3.4. Requirements Section 2.5 Exporting Process ................11 2.3.5. Requirements Section 2.4 Flow Record ......................13 2.3.6. Requirements Section 2.6 Collecting Process ...............13 2.4 ARCHITECTURAL DIFFERENCES .....................................14 3. ITEM LEVEL COMPLIANCE EVALUATION .................................14 3.1 EXTENDING LFAP ................................................14 3.1.1. Vendor Specific ...........................................15 3.1.2. Information Element Extension .............................15 3.1.3. AR/ARA Message Extension ..................................15 3.1.4. MIB Extensions ............................................15 3.2 REQUIREMENTS SECTION 4 DISTINGUISHING FLOWS ...................15 3.3 REQUIREMENTS SECTION 5 METERING ............................16 3.3.1. Requirements Section 5.1 Reliability ......................16 3.3.2. Requirements Section 5.2 Sampling .........................16 3.3.3. Requirements Section 5.3 Overload .........................16 3.3.4. Requirements Section 5.4 Timestamps .......................17 3.3.5. Requirements Section 5.5 Time Synchronization .............17 3.3.6. Requirements Section 5.6 Flow Expiration ..................17 3.3.7. Requirements Section 5.7 Multicast ........................17 3.3.8. Requirements Section 5.8 Ignore Port Copy .................18 3.3.9. Requirements Section 6.1 Information Model ................18 3.3.10. Templated Data ...........................................21 3.3.11. Requirements Section 6.2 Data Model ......................21 3.3.12. Requirements Section 6.3.1 Congestion Awareness ..........22 3.3.13. Requirements Section 6.3.2 Reliability ...................22 3.3.14. Requirements Section 6.3.3 Security ......................22 Calato Informational [Page 2] INTERNET-DRAFT IPFIX LFAP Protocol Evaluation August 2002 3.3.15. Requirements Section 6.4 Regular Reporting ...............22 3.3.16. Requirements Section 6.5 Notification on Specific Events .23 3.3.17. Requirements Section 6.6 Anonymization ...................23 3.3.18. Requirements Section 7.1 Configuration of the Metering ...23 5. Overload behavior .............................................23 3.3.19. Requirements Section 7.2 Configuration of the Exporting ..23 3.3.20. Requirements Section 8.1 Openness ........................24 3.3.21. Requirements Section 8.2 Scalability Concerning the Number of Exporting Processes ...........................................24 3.3.22. Requirements Section 8.3 Several Collecting Processes ....24 4. SECURITY CONSIDERATIONS ..........................................24 4.1 REQUIREMENTS SECTION 6.3.3 SECURITY ...........................24 4.2 REQUIREMENTS SECTION 10.1 DISCLOSURE OF FLOW INFORMATION DATA .25 4.3 REQUIREMENTS SECTION 10.2 FORGERY OF FLOW RECORDS ..........25 4.4 REQUIREMENTS SECTION 10.3 DENIAL OF ERVICE (D S OS) ATTACKS .....26 5. REFERENCES .......................................................27 6. AUTHOR'S ADDRESS .................................................27 7. FULL COPYRIGHT STATEMENT .........................................27 Calato Informational [Page 3] INTERNET-DRAFT IPFIX LFAP Protocol Evaluation August 2002 1. Introduction This document provides an evaluation of the applicability of the LFAP protocol as an IPFIX protocol. First, the general LFAP architecture is introduced and its application to the communication between an IPFIX exporting process and an IPFIX collecting process is discussed in Section 2. Section 3 discusses in detail, to which degree requirements stated in [IPFIX-REQ] are met. This document uses the terminology defined in [IPFIX-REQ]. LFAP [1][2] was originally submitted to the IETF as RFC 2124 [3] in 1997. Since then it has under gone a number of revisions. Revisions were submitted as Internet Drafts. The latest revision can be found at http://www.ietf.org/internet-drafts/draft-riverstone-lfap-01.txt http://www.ietf.org/internet-drafts/draft-riverstone-lfap-data- 01.txt LFAP is completely unencumbered and is available for use by the internet community. Calato Informational [Page 4] INTERNET-DRAFT IPFIX LFAP Protocol Evaluation August 2002 2. Architectural Considerations This section introduces the architecture of the LFAP protocol and suggests a way of applying it to the communication between an IPFIX exporting process and an IPFIX collecting process. LFAP was developed specifically for IP flow accounting. As such it is well suited to support the communication between the Exporting Process and an IPFIX Collecting process. The basic architecture is depicted below: +---------------------------+ | | | | | Application | | | +--//-----------------------+\ // \\ // \\ // \\ +--/--+ +--\--+ | | | | | C1 | | C2 | +--|\-+ +-/+-\+ /| \\ // | \ / | \\ // | \ // | \\ // | \ / | \ / | \ / | \\ // | \ / | \\ // | \ +--/--+ +--+--+ +--\--+ +--/--+ +--+--+ +--\--+ | | | | | | | | | | | | | ID1 | | ID2 | | ID3 | | ID4 | | ID5 | | ID6 | +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ One Collecting process services multiple IPFIX Devices. Each IPFIX Device may have one or more backup Collectors. In case of failure, ID1 _ ID3 would also point to C2 and ID4 _ ID6 would point to C1. An application then retrieves the flow data from the Collecting devices. The LFAP protocol is used between the IPFIX Devices and Collecting process to exchange flow accounting data. See section 2.3.4 of this document for a detailed view of an IPFIX device in both LFAP and IPFIX terms. Calato Informational [Page 5] INTERNET-DRAFT IPFIX LFAP Protocol Evaluation August 2002 2.1 LFAP Architecture Highlights This section provides an overview of the LFAP Architecture's highlights. 2.1.1. Flow Records LFAP splits flow records along the line of characteristic properties (e.g. source IP) as described in the requirements document section 2.4 Flow Record and measured properties (e.g. bytes) also described in section 2.4. This split allows lower memory requirements for the IPFIX Device. Since the characteristics properties are sent independent of measured characteristics, there is no need to store the characteristic properties until update time. This split also allows lower bandwidth consumption since only measured properties need to be reported with each update. See Section 2.2 of this document for a detailed example. If no split is desired information could be combined. 2.1.2. Information Model LFAP defines a very strong Information Model. Information Elements exchanged have a well defined meaning. LFAP itself defines very little in the way of new data elements. The majority of data is defined in such a way as to use the semantics and value range from the protocol being reported. For example, the Class of Service field is defined in terms of RFC 791 (see section 2.8 of the LFAP data specification [2]). 2.1.3. Data Model LFAP defines data precisely and uses a TLV format to encode transfer of information. Dense encoding is supported via a multi- record structure, which allows type and length to be provided once for all flows reported in the message. Semantic information still resides close by the data to minimize potential interpretation errors. The TLV format also allows extension, as unknown data elements can be easily skipped using the length field. Using a TLV format also makes debugging messages straightforward. 2.1.4. Scalability Since LFAP was designed for IP flow accounting, there is little in the way of non-IP-flow data being passed. Messages with Flow data are dense and compact. LFAP was also designed to minimize memory and CPU consumption on the device. Messages are simplified so that transfer of state information requirements is minimal. For example, on failover from one server to another, IP flows can continue send a flow's periodic updates to the new Collector with absolutely no extra work on the part of the IPFIX device. Also since flow data Calato Informational [Page 6] INTERNET-DRAFT IPFIX LFAP Protocol Evaluation August 2002 merely needs to be encoded and sent, CPU usage is minimal. 2.1.5. Security The LFAP specification has a complete section on security. It also paves the way for field level security, which may reduce the CPU cycles needed to implement security features. LFAP provides multiple levels of security and it allows security to be handled externally (e.g. by the transport layer), via LFAP protocol itself or a combination. If LFAP itself is used, protection against any combination of these attacks are covered in the specification: 1) Message altering 2) Message replay 3) Message Insertion 4) Message reading (snooping) 5) Impersonation of a CCE or FAS 2.1.6. Statistics LFAP defines a complete management plane for monitoring a running flow information exchange system. These statistics allow detection of problems and even provide a gauge on the extent of damage. For example, if there is loss of connectivity to the Collector for an extended period, a counter will indicate the number of bytes dropped (i.e. not counted) so the damage from loss of connectivity can be assessed. The protocol defines a base set of metric and operational state so that testing for interoperability is simplified. 2.1.7. Protocol Maturity LFAP was originally submitted to the IETF as RFC 2124 in 1997. Since then it has under gone a number of improvements. The basic model and design have been proven with time. LFAP also has working open source implementations /SDKkits freely available on http://www.nmops.org. The code base has been shipping in commercial products for several years. An LFAP API source kit is available from www.nmops.org. The kit can be used for building both client and server applications. The LFAP API was also ported to NT for use as a probe. LFAP servers are also freely available from www.nmops.org. XACCT Technologies distributes a commercial version of that LFAP server. lfapd written by Steven Premeau, used for Flowscan, is another open source server. InMon Corporation developed an LFAP server for use with its products. Clients and Calato Informational [Page 7] INTERNET-DRAFT IPFIX LFAP Protocol Evaluation August 2002 Servers have been built on Solaris, Linux and NT. Lastly, over time LFAP has built up several debugging tools. The first is a client simulator for testing servers. The second is a server simulator for testing clients. Tests are written using ASCII files with test validation built in. A complete set of message dumping facilities are embedded in the LFAP API. Lastly, a load driver for performance testing is also available. The LFAP protocol is mature protocol specifically designed for the demands of IP accounting. 2.2 LFAP Protocol Overview The LFAP message structure is relatively simple. The following diagram represents which messages each side of the LFAP protocol sends. ,----------------------------. ,-----------------------------. | Collector | | IPFIX Device | | | | | `|---+--------|---|-----|----' `---|---|------------|---+----' | ^ ^ | | ^ | ^ | ^ | ^ ^ | ^ ^ | | | | | | | | | | | | | | | | | | | | | | | | VR | | | | | | | | | | | | | | | `---------------' | | | | | | | | | | | | | | VRA | | | | | | | | | | | | | `--------------------' | | | | | | | | | | | | CR | | | | | | | | | | | `------------------------' | | | | | | | | | | | | | | | | | | | | CAN/CRN/DR | | | | | | | | | `---------------------------------' | | | | | | | | | | | | | | | | FER | | | | | | | `-----------------------------------------' | | | | | | | | | | | | FAR/FUN | | | | | `-------------------------------------------------' | | | | | | | | AR/ARA | | | `----------------------------------------------------------' | | | | KA | `------------------------------------------------------------------' LFAP consists of an initial handshake followed by flow export. The Calato Informational [Page 8] INTERNET-DRAFT IPFIX LFAP Protocol Evaluation August 2002 handshake consists of the VR, VRA, CR, CAN/CRN/DR, AR, ARA and FER messages. Flow export consists of the FAR and FUN messages. The FAR indicates the start of a flow and contains all the requested data elements. The FUN provides periodic updates concerning bytes, packets and time. A state field in the FUN indicates the flow's termination. During the handshake the IPFIX device initiates a TCP connection to a Collector. Session establishment then happens in three phases following TCP connection establishment. In the first phase the LFAP version is exchanged and verified via the VR and VRA messages. In the second phase, the Collector allows or denies the connection via the CRN/CAN/DR messages. The third phase allows setup information to be exchanged via the AR and ARA messages, before flow export begins. For example, the list of Information Elements to be reported may be sent in this phase. Finally, the Collecting device sends the FER and flow export may begin. For more details see the state machine on session establishment in section 6.4 of the LFAP specification [1]. The KA message allows the IPFIX device to quickly detect the loss of a Collector. 2.2.1. LFAP Flow Ids An LFAP Flow ID uniquely identifies a flow. It is used to correlate characteristic properties and all periodic updates. 2.2.2. Periodic reporting versus singular reporting With singular reporting, all characteristic properties and measured properties are reported at the same time. Each report is independent of other flow reports. LFAP Flow IDs in this case are not necessary. With periodic reporting, a flow is reported on more than once. Flow IDs are used to correlate multiple reports to the same flow. Periodic reporting is be more difficult because information can be dispersed plus possible Collector failures. LFAP has done a good job solving this problem with its Flow ID, message structure and failover design. If IPFIX WG determines that singular reporting must be supported the LFAP specification would need to be slightly modified to allow measured characteristics in the FAR message. LFAP is well positioned to handle the more complex case of periodic reporting in addition to the simpler singular reporting. Calato Informational [Page 9] INTERNET-DRAFT IPFIX LFAP Protocol Evaluation August 2002 2.2.3. Protocol Example Assume F1 is a flow with a very narrow flow key, which is to be updated once per minute. Assume F2 is a flow with a very coarse flow key and is to be updated once every 15 minutes. For the sake of example, assume F1 uses cumulative bytes value and F2 uses delta byte values. For simplicity time calculations will not be shown, but are similar to processing for cumulative and delta byte calculations. The message structure and processing would be as follows. Time Message Processing ---- -------------- ---------------------------------------- T1 FAR The first packet for F1 is seen at T1. A FAR message is sent with the requested characteristic properties at T1. T2 FAR The first packet for F2 is seen at T2. A FAR message is sent with the requested characteristic properties at T2 T3 F1 FUN T3 is time to update F1. Current statistics S1 are retrieved. Since the statistics are cumulative the Collector uses S1 _ 0 (zero) to calculate the statistics for this interval. T4 F1 FUN T3 is time to update F1 again. Current statistics S2 are retrieved. Since the statistics are cumulative the Collector uses S2 _ S1 to calculate the statistics for this interval. Several more updates for happen before F2 is updated T17 F2 FUN T17 is time to update F2. Current delta statistics DS1 are retrieved. Since the statistics are in delta form the Collector uses DS1 statistics for this interval. Calato Informational [Page 10] INTERNET-DRAFT IPFIX LFAP Protocol Evaluation August 2002 2.3 General Applicability 2.3.1. Requirements Section 2.1 IP Traffic Flow LFAP is compatible with the flow definition described. 2.3.2. Requirements Section 2.2 Observation Point 2.3.3. Requirements Section 2.3 Metering 2.3.4. Requirements Section 2.5 Exporting Process These 3 items map to the Connection Control Entity (CCE) in the LFAP specifications. A detailed view of a CCE and how it maps to IPFIX is provided below. Calato Informational [Page 11] INTERNET-DRAFT IPFIX LFAP Protocol Evaluation August 2002 +--------------------------------------------------------------------+ | ^ | | | Send Message to Collector | | +----------+ Remove +-------+------------+ +-------+ | | | Msg Queue|<--------| LFAP Processing API|<-----+Timers | | | +----------+ | | +-------+ | | ^ +--+------------+----+ | | | |Lookup |Flow Update | | | | | Exporting Process +---------------------------------|------------|---------------------+ | | v | | | | +--------------------------+-| | | | |Flow ID -> Flow table key | | | | | +--------------------------- | | | | ^ | | | | | | | | | Add | | | | +----+------+---+ | | | | LFAP Flow API |Get stats | | | | +-------------+ | | | +---------------+ | | | | ^ | | | | | Flow Start | | | | | Flow End | | | | +-----+---------+ | | | | | Flow Mgt | | | | | +-----> Flow Key | | | | | | | Forward* |------>Packet | | | | | +---------------+ | | | | | | Create - forward/filter| | | | | | Delete | | Metering Process +--|-----------|------------------------|------|---------------------+ | | +-----v--------------+ | | | | | | Flow Table Stats|<--------+ | | | | | |<---------------+ | | | +--------------------+ | | | ^ | | | | | | | | Lookup | | | +-----+------+ | | | | Forward ---+--------> Packet | | | | Filter-----+-----+ | | +-----+ Not Found | | | |Packet +------------+ ----- | | ^ --- | | | - | | Packet---+ Observation Point +--------------------------------------------------------------------+ Figure 1 - CCE ==> IPFIX Arcitecture Calato Informational [Page 12] INTERNET-DRAFT IPFIX LFAP Protocol Evaluation August 2002 This diagram assumes the device performs some function besides Metering. In a pure passive probe environment some of the device functions would be deleted. A packet arrives at the Observation point and a lookup is done in the flow table. If an entry is found the packet will either be forwarded or dropped. If no entry is found it is sent to the Flow Management system. Flow Management in the diagram includes both device functions (e.g. router functions) and IPFIX Metering functions. In Flow Management the flow key is determined and the flow table is programmed (device functions). IPFIX Metering is notified a flow has been created. Current implementations of LFAP use the device's flow key as the IP flow key. However, for IPFIX purposes this is where the flow would be distinguished based on current IPFIX configuration along with IPFIX Flow Filtering. A message with the characteristic properties is created and sent (usually just added to a queue to be sent in batches). Also the LFAP Flow ID to device flow key is maintained. This is the only piece of state needed for reporting periodic updates. System timers notify LFAP Processing of flow update intervals. Flow timeouts are based on inactivity (not shown in diagram) and Flow management is notified of the event which triggers an LFAP delete notification. The LFAP Processing sends the messages in the queue in addition to sending periodic updates. The Flow ID is used to lookup the matching device flow table key and retrieve statistics. 2.3.5. Requirements Section 2.4 Flow Record In LFAP a flow record maps to 2 messages. The FAR message contains all the characteristic properties such as Source IP, Destination IP, etc_. The FUN message maps to the measured properties such as bytes and packets. This split allows lower memory requirements for the IPFIX Device. Since the characteristics properties are sent independent of measured characteristics, there is no need to store the characteristic properties until update time. This also allows LFAP to report regular updates for a flow without repeating the flow characteristics. Thereby minimizing what is transferred over the network at the expense of keeping minimal state in the CCE for microflow or flow aggregates being reported. 2.3.6. Requirements Section 2.6 Collecting Process The Collecting process maps directly to the Flow Accounting Calato Informational [Page 13] INTERNET-DRAFT IPFIX LFAP Protocol Evaluation August 2002 Server (FAS) in the LFAP specification. 2.4 Architectural Differences LFAP was designed specifically for IP flow information export and defines the data and transfer protocol whereas IPFIX so far has focused on the architectural constructs of IP flow collection requirements/semantics and processing. Specific differences between LFAP and IPFIX requirements are described under the compliance section. 3. Item Level Compliance Evaluation This section evaluates the compliance of the LFAP protocol with the IPFIX requirements item by item. Requirements are addressed by their section numbers and item numbers in [IPFIX-REQ]. For each requirement it is explained to what degree the LFAP protocol meets the requirement and how this is achieved. The degree of compliancy is explicitly stated using five grades: -T Total compliance: The requirement is met completely by the protocol specification without any extensions required. -E Extension required for total compliance: The protocol is prepared to be extended and it is possible to extend it in a way that it meets the requirement. This grade is only applicable to protocols that are explicitly open to externally defined extensions, such as SNMP is extended by MIB modules or DIAMETER is extended by application modules. It is not applicable to protocols, where the protocol specification itself needs to be extended in order to comply with the requirement. -P Partial compliance: The requirement is met partially by the protocol specification. -U Upcoming compliance: The requirement is not met or met partially by the protocol specification, but there is a concrete plan for an upcoming version of the protocol. -F Failed compliance: The requirement is not met by the protocol specification. 3.1 Extending LFAP LFAP can be extended in 4 ways. In general extensions can be made without breaking existing Collectors. Each method is described below. Calato Informational [Page 14] INTERNET-DRAFT IPFIX LFAP Protocol Evaluation August 2002 3.1.1. Vendor Specific The Vendor Specific Information Element allows individual vendors to send extra information in any message without modifying the LFAP specification or breaking existing Collectors. The specification states that any information supplied in the Vendor Specific IE MUST be able to be safely ignored. See section 2.45 in the LFAP data specification [2] for a detailed description of the IE. 3.1.2. Information Element Extension The LFAP data specification can be modified with new Information Elements. The LFAP message structure and data semantics will remain the same. The LFAP specification indicates that unknown IE's are to be ignored so compatibility with existing Collectors is maintained. Adding a new element merely involves allocating the next Information Element number and adding the necessary text to the specification. 3.1.3. AR/ARA Message Extension These message are intended to contain control information which needs to be exchanged between the IPFIX Device and the Collecting process. The basic choice here is whether the information is better suited to the MIB or an outside configuration mechanism. Once the decision is made to use the AR/ARA messages, a new command value is allocated along with allocating any supporting Information Elements. Unknown commands are ignored by both the IPFIX device and the Collecting Device. If the command is not optional, the LFAP version number would need to be incremented resulting in an incompatibility for existing Collector and IPFIX Devices. 3.1.4. MIB Extensions New objects may be added for configuration or monitoring. 3.2 Requirements Section 4 Distinguishing Flows Requirements Section 4.1 Interfaces Requirements Section 4.2 IP Header Requirements Section 4.3 Transport Header Fields Requirements Section 4.4 MPLS Requirements Section 4.5 DiffServ Code Calato Informational [Page 15] INTERNET-DRAFT IPFIX LFAP Protocol Evaluation August 2002 Requirements Section 4.6 Header Compression and Encryption Compliance = T Any combination of attributes and/or functions may be used to distinguish flows. The resulting flow may then be exported using LFAP. 3.3 Requirements Section 5 Metering 3.3.1. Requirements Section 5.1 Reliability Compliance = T LFAP has the following statistics defined. Dropped messages A count of the number of FAR or FUN messages the CCE could not be transmitted to the FAS while not in Send State. Dropped messages while connected A count of the number of FAR or FUN messages the CCE could not be transmitted to the FAS while in Send State. Number of bytes not accounted for due to dropped messages A count of the number of bytes accounted for in FUN messages being dropped that CCE could not transmit to the FAS while in Send State. Number of packets not accounted for due to dropped messages A count of the number of packets accounted for on the wire that CCE could not transmit to the FAS while in Send State. 3.3.2. Requirements Section 5.2 Sampling Compliance = F LFAP does not have any support for sampling. However, it is certainly possible to extend it to contain the necessary support. For example, LFAP already has the notion of multiple types of flows. In this case extending LFAP to allow a FAR with a flow type of _sampled_ may be sufficient. 3.3.3. Requirements Section 5.3 Overload Compliance = T Calato Informational [Page 16] INTERNET-DRAFT IPFIX LFAP Protocol Evaluation August 2002 LFAP indicates that flows may be dropped and keeps statistics on this behavior. However, this should be stated more explicitly in the specification. Since the overload behavior is to stop reporting, there is no need to distinguish the flows from before and after the event. There is also no need to terminate all existing flows when this event occurs. The MUSTs in the requirements, I believe, do not apply to all overload behaviors. 3.3.4. Requirements Section 5.4 Timestamps Compliance = T* * - The LFAP specification indicates the start time is when the flow was created. This generally coincides with the first packet, but the specification does not mandate it. Furthermore, the end time is when the statistics were gathered. This generally coincides with the flow being timed out or the last packet. But again the specification does not mandate it. 3.3.5. Requirements Section 5.5 Time Synchronization Compliance = T LFAP provides a way to obtain time information from the IPFIX device. See sections 3.3 and 3.4 in the LFAP data specification [2] for the AR and ARA messages concerning the RETURN_TIME command. 3.3.6. Requirements Section 5.6 Flow Expiration Compliance = P LFAP provides a way to close a flow via a state field. The state field can be extended to indicate why the flow was close (e.g. timeout, FIN/RST TCP bits). However, LFAP does not clearly define the flow timeout procedure. This can be rectified in a subsequent revision. See section 2.16 of the LFAP data specification [2] concerning Flow State. 3.3.7. Requirements Section 5.7 Multicast Compliance = T LFAP can of course report the individual multicast flows. It can also report multiple output interfaces. See section 2.24 and section 3.1 of the LFAP data specification [2] for a Calato Informational [Page 17] INTERNET-DRAFT IPFIX LFAP Protocol Evaluation August 2002 description of multiple egress interfaces. 3.3.8. Requirements Section 5.8 Ignore Port Copy Compliance = F LFAP does not support reporting flows resulting from a port copy. Thus there is no way to distinguish them from normal flows. 3.3.9. Requirements Section 6.1 Information Model 1. IP version number Compliance = T* * - The address IE contains an address family field which will indicate IP V4 or IP V6. If address family is not sufficient then IP version number will need a new IE element. 2. source IP address Compliance = T LFAP also supports reporting the address mask. 3. destination IP address Compliance = T LFAP also supports reporting the address mask. 4. IP protocol type (TCP,UDP,ICMP,...) Compliance = T 5. source TCP/UDP port number Compliance = T 6. destination TCP/UDP port number Compliance = T 7. input interface (ifIndex) Compliance = T Calato Informational [Page 18] INTERNET-DRAFT IPFIX LFAP Protocol Evaluation August 2002 8. output interface (ifIndex) ) Compliance = T 9. packet counter Compliance = T 10. byte counter Compliance = T* * - The LFAP counter definition could be better expressed in the specification. 11. in case of IPv4: Type of Service Compliance = T 12. in case of IPv6: Flow Label Compliance = T 13. if BGP is supported at the observation point: BGP AS number Compliance = T 14. if MPLS is supported at the observation point: MPLS label Compliance = T 15. if DiffServ is supported at the observation point: DSCP Compliance = T 16. timestamp of the first packet of the flow Compliance = T* * - The LFAP specification indicates the start time is when the flow was created. This generally coincides with the first packet, but the specification does not mandate it. 17. timestamp of the last packet of the flow Compliance = T* Calato Informational [Page 19] INTERNET-DRAFT IPFIX LFAP Protocol Evaluation August 2002 The end time is when the statistics were gathered. This generally coincides with the flow being timed out or the last packet. But the specification does not mandate it. 18. if sampling is used: sampling configuration Compliance = F If the choice was to configure this via the protocol, LFAP could be extended by allowing the sampling configuration to be provided in the AR/ARA message pair or the in LFAP MIB. 19. unique identifier of the observation point Compliance = T* * - The identifier is an IP address. If the observation point is not IP addressable, a different mechanism would be needed. The issue here is how to obtain a unique ID that can also be traced back to a specific IPFIX observation point. 20. unique identifier of the exporting process Compliance = F This would require just the definition of one additional information element. 21. multicast replication factor Compliance = F This would require just the definition of one additional information element. 22. Time To Live Compliance = F This would require just the definition of one additional information element. 23. IP header flags Compliance = F Calato Informational [Page 20] INTERNET-DRAFT IPFIX LFAP Protocol Evaluation August 2002 This would require just the definition of one additional information element. 24. TCP header flags Compliance = T 25. dropped packet counter at the observation point Compliance = F This would require just the definition of one additional information element. 26. fragmented packet counter Compliance = F This would require just the definition of one additional information element. 3.3.10. Templated Data If templated data passing is needed, LFAP defines a multi- record IE where the record format is given once in the message and then just values are listed for each flow reported. This provides a good amount of data reduction. If further reduction is mandated via a session wide template, additional work would need to be done in LFAP. However, this extra level of reduction, in my view, is only an incremental reduction. The amount of data reduction from a coarser grained flow definition would dwarf any reduction from sending type information per session instead of per message. Thus if bandwidth is an issue, a coarser flow definition is the likely solution. 3.3.11. Requirements Section 6.2 Data Model Compliance = T & F Since LFAP uses a TLV format, unknown IE's are simply skipped over. Thus new attributes can be added without affecting existing Collectors. LFAP also allows, via the protocol, the configuration of the set of data elements to be exported. In some cases LFAP depends on messages coming in order. For example, if cumulative byte counts are used (as opposed to Calato Informational [Page 21] INTERNET-DRAFT IPFIX LFAP Protocol Evaluation August 2002 delta byte counts which is also available), out of sequence update messages would cause a problem. At the moment TCP is used to solve this problem. If an unreliable transport is needed, LFAP would need to be extended with a message sequence number to ensure ordering at the application layer. There already exists a message ID but it is only a 16 bit value which may not be large enough. The other option is to remove the alternative features that have ordering issues. 3.3.12. Requirements Section 6.3.1 Congestion Awareness Compliance = T LFAP uses TCP. If an unreliable congestion aware protocol is used instead, LFAP would need a larger message ID field (32 bits instead of 16) to solve any ordering issues. 3.3.13. Requirements Section 6.3.2 Reliability Compliance = T LFAP uses TCP which is a reliable transport. LFAP also defines statistics for tracking reliability parameters. Application level reliability is not supported. However, there is enough information in the LFAP messages to provide such support. For example, the FLOW_ID, TIMESTAMP, MESSAGE_ID 3-tuple uniquely identifies all messages. Thus duplicates may be weeded out. However, sending duplicate data records has design and implementation issues associated with it. The design issue is developing a procedure where duplicate records are always eliminated. It seems there exist failure combinations that poke holes in any design. Whether or not those holes are acceptable is an issue for the market place. Furthermore, high volume situations cause practical implementation problems in searching for duplicate records. 3.3.14. Requirements Section 6.3.3 Security See section 4 Security in this document. 3.3.15. Requirements Section 6.4 Regular Reporting Compliance = T LFAP's message structure is ideally suited for regular reporting. Update information may be sent without repeating characteristics. Update intervals can also vary for different Calato Informational [Page 22] INTERNET-DRAFT IPFIX LFAP Protocol Evaluation August 2002 flows. 3.3.16. Requirements Section 6.5 Notification on Specific Events Compliance = P & F The 2 events mentioned are handled by the FAR/FUN messages. The MIB also defined several events. If other events are needed, the AR/ARA messages could be extended or additional MIB events can be provided. 3.3.17. Requirements Section 6.6 Anonymization Compliance = F If all data is anonymzed an AR/ARA exchange or MIB changes could provide the indication. If it is per message, there is room in the message header to provide the indication. If field level is needed, there is room in the IE type for this indication. However, further review needs to be done as there may be other ways to accomplish this at the field level. 3.3.18. Requirements Section 7.1 Configuration of the Metering 1. Specification of the observation point 2. Specifications of flows to be metered 3. Flow timeouts 4. Sampling method and parameters, if feature is supported 5. Overload behavior Compliance = F LFAP does not define these configuration parameters. LFAP can be extended to provide configuration information via the MIB or AR/ARA exchange. How far we go in the configuration area is another matter. 3.3.19. Requirements Section 7.2 Configuration of the Exporting 1. reporting data format Compliance = T 2. the collecting process(es) to which flows are reported Compliance = T The LFAP MIB allows this to be configured. Calato Informational [Page 23] INTERNET-DRAFT IPFIX LFAP Protocol Evaluation August 2002 3. notifications to be sent to the collecting process(es) Compliance = P The LFAP MIB defines traps which may be sent. 4. flow anonymization Compliance = F This configuration be can handled via the LFAP MIB or the AR/ARA exchange. 3.3.20. Requirements Section 8.1 Openness Compliance = T* The LFAP Information Model and Data Model were designed for easy extension and flexibility. Configuration extension is possible through MIB and AR/ARA message exchange. 3.3.21. Requirements Section 8.2 Scalability Concerning the Number of Exporting Processes Compliance = T* LFAP places no limits on the number of Exporting Processes. LFAP distinguishes Exporting Processes by address. * - If distinguishing by address is deemed insufficient, an additional Information Element will need to be defined. 3.3.22. Requirements Section 8.3 Several Collecting Processes Compliance = F LFAP would need to define this procedure and add the necessary elements to the MIB module for configuration. 4. Security Considerations Security considerations for the IPFIX protocol are covered by the comparison against the specific Security requirements in the IPFIX requirements document [IPFIX-REQ] where they are specifically addressed by sections 6.3.3 and 10. 4.1 Requirements Section 6.3.3 Security Compliance = T Calato Informational [Page 24] INTERNET-DRAFT IPFIX LFAP Protocol Evaluation August 2002 LFAP specifies security mechanisms to achieve the elements listed below. The security mechanisms can be external to the protocol (e.g. provided by the transport layer) or via the LFAP protocol itself. A combination may be also be used. LFAP provides mechanisms in the protocol to allow for lightweight simple mechanisms when needed. It also paves the way for field level security, which may reduce the CPU cycles needed to implement security features. Confidentiality If LFAP is used a bit in the message header indicates the message is encrypted. The encryption mechanisms are well defined. Integrity If LFAP is used a bit in the message header indicates the message is authenticated. The authentication procedure covers Integrity. If only Integrity is desired, simply defining one additional bit is all that is necessary. Authenticity If LFAP is used a bit in the message header indicates the message is authenticated. Authentication procedures are well defined. Push Compliance = T Pull Compliance = F LFAP does not support pull mode. Additional work would need to support this mode. 4.2 Requirements Section 10.1 Disclosure of Flow Information Data Compliance = T LFAP defines encryption procedures. 4.3 Requirements Section 10.2 Forgery of Flow Records Compliance = T LFAP defines Authentication and Integrity procedures. Calato Informational [Page 25] INTERNET-DRAFT IPFIX LFAP Protocol Evaluation August 2002 4.4 Requirements Section 10.3 Denial of Service (DoS) Attacks Compliance = T The LFAP specification describes procedures to mitigate DoS attacks on the IPFIX device and the Collecting device. For example, see the following paragraph in section 5.2 _Version Request Acknowledge (VRA) Message_ of the LFAP specification [1]. _The CCE MUST NOT request a version higher than the one returned in the VRA otherwise the FAS MUST disconnect the TCP session and the counter Session Establishment Errors will be incremented._ This is intended to keep the FAS (Collecting Process) from being bombarded with VR requests as a DoS Attack against the FAS. Calato Informational [Page 26] INTERNET-DRAFT IPFIX LFAP Protocol Evaluation August 2002 5. References [1] "Light-weight Flow Accounting Protocol Specification Version 5.0" draft-riverstone-lfap-01.txt, June 2002 [2] "LFAP Data Definition Specification", draft-riverstone-lfap-data-01.txt. June 2002 [3] _Cabletron's Light-weight Flow Admission Protocol Specification version 1.0_. Informational RFC 2124 March 1997 [IPFIX-REQ] J. Quittek et al., "Requirements for IP Flow Information Export", draft-ietf-ipfix-reqs-05.txt, work in progress, August 2002. 6. Author's Address Paul Calato Riverstone Networks 5200 Great America Pkwy. Santa Clara, CA 95054 7. Full Copyright Statement Copyright (C) The Internet Society (2001). 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 languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDIN 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. Calato Informational [Page 27]