Last Modified: 2004-06-08
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 | |
| Done | Submit Internet-Draft on IP Flow Export Architecture | |
| Done | Submit Internet-Draft on IP Flow Export Data Model | |
| Done | Submit Internet-Draft on IPFIX Protocol Evaluation Report | |
| Done | Submit Internet-Draft on IP Flow Export Applicability Statement | |
| Done | Select IPFIX protocol, revise Architecture and Data Model drafts | |
| Done | Submit IPFX-REQUIREMENTS to IESG for publication as Informational RFC | |
| Done | Submit IPFIX Protocol Evaluation Report to IESG for publication as Informational RFC | |
| Sep 04 | Submit IPFX-ARCHITECTURE to IESG for publication as Proposed Standard RFC | |
| Sep 04 | Submit IPFX-INFO_MODEL to IESG for publication as Informational RFC | |
| Sep 04 | Submit IPFX-APPLICABILITY to IESG for publication as Informational RFC | |
| Sep 04 | Submit IPFX-PROTOCOL to IESG for publication as Proposed Standard RFC |
|
Minutes of the IP Flow Information eXport (IPFIX) WG
IETF 60, San Diego, Wednesday August 4, 2004 42 people in attendance Reported by Dave Plonka & Nevil Brownlee (co-chairs) based on notes from Colleen Shannon and George Michaelson. The text messaging log is available here: http://www.xmpp.org/ietf-logs/ipfix@ietf.xmpp.org/2004-08-04.html The meeting agenda and slides are available here: http://ipfix.doit.wisc.edu/IETF60/ [please see the agenda slides there for the sequence of topics: http://ipfix.doit.wisc.edu/IETF60/0-ietf60-ipfix-agenda.pdf ] ---- At the opening of the meeting the chairs reiterated that both the Evaluation Report and Requirements drafts and have been approved by the IESG and are in the RFC-Editor's queue. ---- David Moore presented work on "Building a Better NetFlow". [Note: the chairs included this talk so as to consider whether or not the IPFIX protocol, as currently defined, has sufficient features to accommodate potential modifications to flow export in practice.] This work proposes a new technique to simplify the configuration of flow export by using a fixed time interval (such as five minutes) for flow termination and to deliver a predictable (configured) number of flow records to the collector. It does this by automatically decreasing the number of packets sampled if necessary and pacing the export throughout the subsequent time slot. This is to avoid exporter failure due to resource exhaustion by bounding the resource requirement. It also simplifies configuration for operators by specifying only how many flows records are desired per time interval. [see slides for details: http://ipfix.doit.wisc.edu/IETF60/1-ietf60-ipfix-moore-better.pdf ] The technique itself was discussed, and its implications for IPFIX. In particular, the IPFIX protocol would need to allow the exporter to regularly inform the collector of the sample rate for each interval. This would be done with option templates and option records. ---- Arne Oslebo presented "IPFIX Implementation Notes" on behalf of its author, Luca Deri. [ see slides and the draft for details: http://ipfix.doit.wisc.edu/IETF60/2-ietf60-ipfix-deri-implementation.ppt http://www.ietf.org/internet-drafts/draft-deri-impl-00.txt ] During the discussion, it was mentioned that the concerns regarding Vendor-specific Extensions have been addressed in the most recent protocol draft version (-03). ---- Simon Leinen presented his draft about IPFIX over TCP. [ see slides and the draft for details: http://ipfix.doit.wisc.edu/IETF60/3-ietf60-ipfix-leinen-tcp.pdf http://www.ietf.org/internet-drafts/draft-leinen-ipfix-tcp-00.txt ] Discussion included: * Should the IPFIX exporter or collector initiate the TCP connection(s)? It was noted that an exporter-initiated TCP connection better matches the implementation over other transports (SCTP, UDP). Also, concern was raised that the router being the server-side might make it more vulnerable to attack. * Simon suggested using TLS with TCP, which causes us to consider what negotiation might be required. It was suggested to avoid handshake/negotiate by configuring TLS out-of-band on both the exporter and collector. This should be discussed on the mailing list. * Simon offered to produce new version(s) of the draft, the content to be ultimately be moved into the protocol draft when Simon finishes this work. ---- Nevil Brownlee gave an overview of the four IPFIX documents' purposes. ---- Benoit Claise brought us up to date on the protocol draft changes and open issues. [ see slides and the draft for details: http://ipfix.doit.wisc.edu/IETF60/4-ietf60-ipfix-claise-proto.pdf ] Discussion included: * Benoit proposed eliminating scope values/namespace, and reusing like-named information elements or fields. This will reduce IANA-managed namespaces and will better enable IPFIX users to correlate template values with the scope reported in records. * We discussed changing the term "FlowSet" to simply "Set" throughout IPFIX documents. For instance, Option Template FlowSet becomes Option Template Set, which is less confusing. * The drafts will specify that some FlowSet values in IPFIX are reserved or not used for historical reasons (i.e. in the basis protocol, NetFlowV9) and that IPFIX does not require those features to be implemented. Approximately the following wording was proposed: "For historical reasons, the FlowSet ID value of 0 and 1 MUST NOT be used." * It was suggested that IPFIX and PSAMP share a single namespace for information elements, rather than splitting them at a "magic number". * It was suggested that complete specifications (detailed descriptions) of information elements should be maintained by IANA. An expert panel should be identified to review IE additions for IANA. Such reviews should also consider security implications. * Discussion should follow in the mailing to define, in the protocol specification, just the minimum set of MUST-implement information elements for metering process statistics. This is necessary to satisfy the IPFIX requrements regarding packet/byte/flow reporting losses by sending this via options templates/records. Benoit said that he will produce a new version of the draft within one week. ---- Juergen Quittek reported the status of the IPFIX Information Model draft, which is still very much under construction. [ see slides and the draft for details: http://ipfix.doit.wisc.edu/IETF60/5-ietf60-ipfix-quittek-info-model.ppt ] Juregen mentioned that Jeff Meyer has not been available recently, but Stuart Bryant & Benoit Claise have helped. Discussion included: * What to do regarding bi-direction counters, for instance inPackets, outPackets, and just packets (where direction is unspecified)? This topic will be discussed on the mailing list. * What to do with reporting fields whose values vary within a single flow variable such as TTL, TCPFlags, multicast replication, etc. In response it was suggested to rigorously define the semantics in the IE description. This topic will be discussed on the mailing list. * Concern was again raised with field number simultaneous in both PSAMP and IPFIX. Until the IANA hand-off, it was proposed that PSAMP and IPFIX will coordinate their use of numbers. ---- Nevil Brownlee brought us up to date on the architecture draft changes and open issues. [ see slides and the draft for details: http://ipfix.doit.wisc.edu/IETF60/6-ietf60-ipfix-brownlee-arch-03.pdf ] * The terms "Flow Recording Process" and "Flow Aggregation" will be removed from all IPFIX documents for the sake of clarity and removing unnecessary complications. (Their functions may still play a part, but the hidden within another component.) * Nevil mentioned that the Security Considerations section is a bit too light on content. For example, it would benefit from more discussion of threats. * The term "field" versus "information element" was discussed, with some attendees in favor of either for different circumstances. This issue deserves follow-up on the mailing list. * Nevil discussed whether or not the architecture and protocol documents must share exactly the same entries in the terminology section, given that the documents have differing goals. Some preference was expressed for verbatim consistency, perhaps over brevity, since the current terminology was carefully arrived at. ---- Tanja Zseby reported that the applicability statement draft has just had a bit of restructuring and a little new content: not many changes. ---- The chairs asked for volunteers regarding security work. We need the sort of content that would be in a "threats" draft, but suggest putting it in the architecture draft. Also, we could use expertise regarding TLS, IPSEC, etc. ---- [ Note from chairs: We expect new versions of the protocol and architecture drafts shortly after this meeting. The chairs would like to do last call on one or more of those revised drafts before the next IETF meeting. ] ---- $Id: minutes.txt,v 1.6 2004/08/27 18:20:19 dplonka Exp $ |