An IP flow information export system includes a data model, which represents the flow information, and a transport protocol. An "exporter," which is typically an IP router or IP traffic measurement device, will employ the IP flow information export system to report information about "IP flows," these being series of related IP packets that have been either forwarded or dropped. The reported flow information will include both (1) those attributes derived from the IP packet headers such as source and destination address, protocol, and port number and (2) those attributes often known only to the exporter such as ingress and egress ports, IP (sub)net mask, autonomous system numbers and perhaps sub-IP-layer information.
This group will select a protocol by which IP flow information can be transferred in a timely fashion from an "exporter" to a collection station or stations and define an architecture which employs it. The protocol must run over an IETF approved congestion-aware transport protocol such as TCP or SCTP.
Specific Goals
o Define the notion of a "standard IP flow." The flow definition will be a practical one, similar to those currently in use by existing non-standard flow information export protocols which have attempted to achieve similar goals but have not documented their flow defintion.
o Devise data encodings that support analysis of IPv4 and IPv6 unicast and multicast flows traversing a network element at packet header level and other levels of aggregation as requested by the network operator according to the capabilities of the given router implementation.
o Consider the notion of IP flow information export based upon packet sampling.
o Identify and address any security privacy concerns affecting flow data. Determine technology for securing the flow information export data, e.g. TLS.
o Specify the transport mapping for carrying IP flow information, one which is amenable to router and instrumentation implementors, and to deployment.
o Ensure that the flow export system is reliable in that it will minimize the likelihood of flow data being lost due to resource constraints in the exporter or receiver and to accurately report such loss if it occurs.
| Done | Submit Revised Internet-Draft on IP Flow Export Requirements | |
| Feb 02 | Submit IPFX-REQUIREMENTS to IESG for publication as an Informational RFC | |
| Done | Submit Internet-Draft on IP Flow Export Architecture | |
| Done | Submit Internet-Draft on IP Flow Export Data Model | |
| May 02 | Submit IPFX-DATAMODEL to IESG for publication as an Informational RFC | |
| May 02 | Submit IPFX-ARCHITECTURE to IESG for publication, Proposed Standard RFC (also need an Applicability Statement RFC) |
Current Meeting Report
Minutes of the IP Flow Information eXport (IPFIX) WG
IETF 53, Minneapolis, Monday March 18, 2002
78 people in attendance
Reported by Greg Ruth (scribe), Dave Plonka & Nevil Brownlee (co-chairs)
The meeting agenda is available here:
http://ipfix.doit.wisc.edu/IETF53/IETF53_IPFIX_agenda.sdd
http://ipfix.doit.wisc.edu/IETF53/IETF53_IPFIX_agenda.ppt
Nevil gave a brief overview of the IPFIX goals, commenting particularly that the working group is not trying to invent anything from scratch and that the IPFIX system must utilize a congestion-aware transport protocol.
Regarding the milestones, we have completed our first drafts of architecture, requirements and data model on schedule.
Mark Fullmer of OARnet, and author of flow-tools, did a short presentation entitled Abilene NetFlow Deployment, which the co-chairs introduced as an example of a large-scale flow-based measurement system. The presentation is available at:
http://ipfix.doit.wisc.edu/IETF53/abilene-netflow.ppt
The measurement system currently collects about 350 million flows per day, and processes them using multiple kinds of analysis.
Mark noted some security issues including that current NetFlow authentication is based solely on source IP. While spoofed flows can be detected by sequence numbers, this is not often done in practice.
Mark's tools can be found here:
http://www.splintered.net/sw/flow-tools/
The next item on the agenda was to review the WG documents.
1. IPFIX Applicability - Tanja Zseby, FhG FOKUS
http://ipfix.doit.wisc.edu/IETF53/IPFIX-applicability.ppt
The chairs mentioned that while this document is not yet listed as a WG milestone, it will be required for making IPFIX a standard.
Tanja noted these document objectives:
a) show how target applications can use IPFIX;
b) describe relations and potential interfaces to other frameworks/working groups (RTFM, IPPM, AAA, etc.)
c) the document is expected to address at least these applications:
Accounting, traffic profiling, TE, Intrusion detection, QoS Monitoring, Deployment of Sampling in IPFIX
The document is available here and will be published as an Internet Draft soon:
http://ipfix.doit.wisc.edu/app/ipfix-applicability-v1.txt
2. IPFIX Requirements - Juergen Quittek, NEC
http://ipfix.doit.wisc.edu/IETF53/IPFIX-reqs-IETF53.ppt
Juergen mentioned the following updates:
a) added section 2 on terminology - IP traffic flows, observation point, metering process, flow record, exporting process, collecting process
b) replaced "measuring device" by either "metering process", "export process" or "IPFIX device" as appropriate
c) removed "network surveillance" section
d) added "overload behavior" section
There are some changes that need to be done for the next (and probably final) draft: consistency checks, add "observation domain", remove "IPFIX device", rephrase Security Considerations
Next version to appear May 1 - expect WG last call at that time
3. IPFIX Information Model (formerly Data Model) - K.C. Norseth
http://ipfix.doit.wisc.edu/IETF53/ipfix_data_ietf53.ppt
KC's overview consisted of the following points:
a) This document was created by a design team: equipment vendors, applications vendors and users
b) flow types and flow definitions
c) selection criteria for a flow
d) packet encoding format
e) information elements
Outstanding issues include:
a) need to clarify more elements
b) counters (absolute vs. Delta - may have both)
c) source & destination address types
Next steps are:
a) complete/refine the flow definition
b) add missing information elements
c) detailed definition of elements (type, size, detailed description)
Discussion:
Should we have just one document instead of a info/data model and architecture (??)
Consesus was that it was reasonable to have one seperate document listing the information elements, which may need to be updated more often than the architecture document.
Should some topics be moved out of the data model (back) into the architecture document?
As the data model document matures, we may revisit whether the defintion of the flow belongs in this document or in the architecture document.
4. IPFIX Architecture - KC Norseth
http://ipfix.doit.wisc.edu/IETF53/ipfix_arch_ietf53.ppt
The architecture document was also developed by the design team.
KC presented an overview of the elements of an architecture including: collector, IPFIX device, etc.
The IPFIX Protocol as implemented in the exporting device will encode the control information into self-describing structures, encode the flows measured, and packetize the flow records. It will use the underlying transport layer to send the export packets to the collector.
The IPFIX Protocol in the collecting device will receive and store the control information, decode and store flow records using the control information.
The architecture document currently refers to separate control and data streams. The control stream being a reliable path to exchange control information, monitor connectivity and other failures, and the data stream to send the IPFIX export payload itself.
At this point, a number of attendees took issue with the use of the word "control" because it can be confusing. In response it was noted that, in this context, "control [information]" refers to the portion of IPFIX which communicates the structure of the exported data.
Consensus was that both the words "control" and "stream" are inappropriate. "Data description" was suggested as an alternative.
[Note that the architecture document currently contains a section on "Selection Criteria" for the IPFIX application-level protocol. This section will ultimately be replaced by one describing the IPFIX protocol, as the result of the selection process (see below).]
KC mentioned that the co-chairs said that all the references to UDP as transport must be removed from the architecture document.
This triggered a discussion about transport protocols.
The result of that was that it is IETF consensus (RFC 2914), not just an IESG policy, that standard protocols must use congestion-aware transport.
The proposed DCP transport protocol may be satisfactory (since it accommodates congestion handling). The transport area director noted that good implementations of TCP and SCTP should be perfectly satisfactory for our purposes at this time.
It was asked what "reliability" means for the IPFIX application-level protocol. In response, it was noted that IPFIX's reliability requirement isn't necessarily satisfied by simply using a reliable transport protocol. Reliability is a multifaceted issue. Different degrees of reliability for different kinds of records.
It was suggested that IPFIX consider the Reliable Server Pooling WG effort and its documents:
http://www.ietf.org/html.charters/rserpool-charter.html
Regarding capability negotiation, consensus amongst attendees (by a hum) was that neither exporter configuration nor capabilities negotiation between collectors and exporters should be addressed by IPFIX. The chairs will follow-up with a call on the mailing list on this topic.
Also, the chairs said that explicit references to template-based application-level protocols need to be removed from the architecture document, since the IPFIX requirements do not exclude other candidate self-describing data encoding methods.
The chairs turned the discussion to WG process issues, specifically they proposed an evaluation and selection process for the IPFIX application-level protocol. This is outlined in the last two slides of the agenda here:
http://ipfix.doit.wisc.edu/IETF53/IETF53_IPFIX_agenda.sdd
http://ipfix.doit.wisc.edu/IETF53/IETF53_IPFIX_agenda.ppt
The proposal is that we will have an "evaluation team" consisting of an odd number of people having experience in disciplines including router hardware, probes, application software, and end use of flow-based measurements. The chairs will select the members from among the interested respondents.
The evaluation team will consider candidate protocols which (a) have a working implementation, (b) are documented by an Internet Draft or RFC, and (c) have a IPFIX participant advocating the selection of that protocol and willing to produce a brief document, such as an I-D, explaining how the protocol meets the selection criteria.
The evaluation team will interact with the advocates by responding to the advocacy documents with lists of issues/deficiencies and may ask additional questions of the advocates. They will also produce a report according within a WG-defined timeframe proposing their selection and identifying suggested improvements as necessary.
The evaluation report will be discussed and approved by mailing list consensus.
Subsequent discussion did not offer any improvements to the proposed process.
In reponse to a question about whether multiple IPFIX application protocols could be selected, the chairs said that the goal is to settle on a single protocol and that protocols unencumbered by intellectual property issues will be preferred.
Lastly, WG milestones were reviewed. The editors of each document agreed to produce their next revision by May 1.
The chairs plan to solicit for candidate protocol advocates and appoint an evaluation team by May 1, and call for advocacy reports by June 1.
The evaluation team will present a status report at the next IETF WG meeting in July.
Slides
Agenda
Abilene NetFlow Deployment
IPFIX Applicability
IPFIX Requirements
IPFIX Data
IPFIX Architecture