One document matched: draft-calato-ipfix-lfap-eval-00.txt
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
<draft-calato-ipfix-lfap-eval-00.txt>
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]
| PAFTECH AB 2003-2026 | 2026-04-23 14:38:33 |