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.