========================================== Minutes of the IPFIX session at IETF 67 San Diego Thursday November 9 at 1300-1500 Taken by Rolf Wolter and Juergen Quittek ========================================== Chairs: Juergen Quittek Agenda: 0) Session summary 1) Agenda review WG Status 2) Documents from the old charter 3) Implementation Guidelines 4) IPFIX Testing 5) Reducing Redundancy 6) IPFIX MIB 7) Bidirectional Flow Export 8) New drafts 9) wrap up, milestone review ---------------- 0) Session summary All documents from the old charter have passed IETF last call and the IPFIX protocol already passed IESG evaluation. The IPFIX architecture still needs to resolve one DISCUSS issue from IESG evaluation. The information model and the applicability statement will enter IESG evaluation soon. For the five documents from the new charter, all have initial versions as planned except for the MIB module that is still and individual draft. Progress of these documents is slightly slower than planned. Only the redundancy draft is on schedule and will enter WGLC next week. The implementation guidelines and the IPFIX testing drafts are delayed, because they should also cover IPFIX protocol security for which the final solution was fixed just this week. For this and the draft on bidirectional flow reporting WGLC is no planned for January 2007. The MIB module needs further work. Particularly the writeability of objects needs further discussion. WGLC is expected after the Prague meeting. ---------------- 1) Agenda review WG Status (Juergen Quittek) All drafts from the old charter have passed WGLC. 2 have been evaluated by the IESG, the other two will be evaluated soon. Milestones of current charter - Aug 2006: Publish Internet Draft on IPFIX Testing Publish Internet Draft on IPFIX MIB - Nov 2006 Submit IPFIX Implementation Guidelines draft to IESG for publication as Informational RFC Submit IPFIX Testing draft to IESG for publication as Informational RFC Submit IPFIX Reducing Redundancy draft to IESG for publication as Informational RFC - Mar 2007 Submit IPFIX Biflows draft to IESG for publication as Informational RFC Submit IPFIX MIB draft to IESG for publication as Standards track RFC Agenda bashing: suggestion to do 5) before 4) was accepted. ---------------- 2) Documents from the old charter (Juergen Quittek) - draft-ietf-ipfix-architecture-12.txt This draft is in IETF evaluation. There is one remaining DISCUSS issue to be solved. It requests adding text to encourage the use of Encapsulating Security Payload with a null encryption algorithm. Juergen promised to solve the issue by the end of the week. - draft-ietf-ipfix-protocol-24.txt During IESG evaluation security issues were raised. Benoit (editor) explained the issues (secure/insecure ports, TLS how to match SCTP streams, certificate ID). All issues have been solved and the draft passed IESG evaluation at the day before the session. It will enter the RFC editor queue soon after the IETF meeting. - draft-ietf-ipfix-info-14.txt This draft passed IETF last call and will now enter IESG evaluation. there are a few modifications necessary that will be sent with the draft to the evalaution. - draft-ietf-ipfix-as-10.txt This draft passed IETF last call and will now enter IESG evaluation. A problem of this draft is that it refers to the PSAMP information model draft that will take some more time for completing it. ---------------- 3) Implementation Guidelines (Elisa Boschi) - draft-ietf-ipfix-implementation-guidelines-01.txt Submitted in Aug 2006, milestone: Nov 2006 (might be delayed) The document describes recommendations for implementers, basically from the ipfix interoperability workshops and mailing list discussions. Next interop event: Nov 29,30 in Berlin, Germany. Details: http://ants.fokus.fraunhofer.de/ipfix/interop06/ Objective: Security and SCTP testing Lots of enhancements to the document, new concept of transport sessions, new guidelines on timing. New outline of the document: template management, export process, collection process, transport-specific, middleware boxes guidelines. The guidelines are behind schedule, because security section is still empty. Other sections need only editorial changes. Security section can now be written since the security solution for the IPFIX protocol was fixed yesterday. Open issue #1: Enterprise specific IE-how to address. Do we want to address it in the document? Paul: Do we have a solution for the enterprise-specific IEs? Juergen: no Paul: Then let's leave this out of this document If we have a solution, it should be in the protocol draft. But for the current protocol draft it's too late. Open issue #2: Security guidelines: 3 ongoing implementations, delayed start Juergen: if we exclude security we can keep our deadlines; still we should add it Paul: Yes, leave the security in Brian: We have a solution, but this should rather be covered by a different document Open issue #3: The tunneled mentioned in the middlebox section is not in IPFIX-INFO, because there is a variety of different tunnel IDs out there that is hard to cover with a single IE. The section needs to be modified. Juergen: how long will we need for completing the guidelines? Elisa: Two more revisions. Target would be WG last call in February. ---------------- 4) IPFIX Testing (Paul Aitken) - draft-ietf-ipfix-testing-00.txt This was a private draft, adopted by the WG. Reason for the draft: ipfix is a binary transport protocol, not human readable. Idea: support the implementers with the testing: "do the homework and then go to interop tests or real world" To be added: SCTP and TLS testing Potential future adding: - more formal test specs - out-of-the-box ipfix test suite - library of defective packets Benoit: Please ad defective packet descriptions Benoit: The library of defective packets should be included. Benoit: Is it a guideline for testing or a compliany test? Paul: Rather guideline for testing Juergen: Charter says it's just a guideline, The IETF has no compliance tests. There are no plans to go in that direction. Andrew: You are not compliant if you fail one of the tests. Juergen: You are not necessarily compliant if you pass all tests Juergen: Time frame: End of Jan WG last call, to be completed in Feb ---------------- 5) Reducing Redundancy (Elisa Boschi) - draft-ietf-ipfix-reducing-redundancy-01.txt This draft was submitted in August 2006 matching the WG milestone. The document is reasonably complete, feedback is still welcome. Main changes from previous version: textual improvements, clarification, new definition of transport session. Some rewrites and reorganized sections (Problem statement, Collection process). New example added Open issue: commonPorpertiesID definition. Transport session introduced, similar to template ID., same for properties management. Juergen: Should it go WG last call? No objections. 2 reviewers in the next week, Juergen will get additional reviewers and start last call next week. ---------------- 6) IPFIX MIB (Thomas Dietz) - draft-dietz-ipfix-mib-01.txt Current overall structure: exporter, session, template sections Exporter section: includes reporting, templates, instances, methods (placeholder for psamp extensions) Issues: transport session, scope missing. Writable objects missing? Several changes proposed for the exporter, such as transport session table to be added. Refresh timers for option template (UDP Part). Instance: complicated structure will be removed as it is included in the transport section. Issue: observation domain, table could become huge. Proposal to assign an Entity MIB index to the observatuion Domain ID. Issues for exporter MIB - Transport Session is missing - Scope and Flow Key is missing - Observation Domain is not really defined - Writeability of the MIB Issues for Collector MIB - Do minor alignments with the Exporter parts - Align statistics with Exporter parts - Thoroughly review alignment with other drafts - Check Documentation of Objects Writeable objects lead to recent extensive discussion on the list. Some objects changed to RW. Dan (Area Director): When did this turn into a big issues? Thomas: Many people on the list want it to be RW. Q: How will an ipfix exporter be used, do we need remote config operations? Thomas: yes. Dan: If not SNMP, then how to change it? Thomas: CLI. Dan: Is CLI good enough? Benoit: Cisco NetFlow MIB has various details, almost nobody is using it. Dan: Security issues maybe (SNMPv3). Simon: We use NetFlow a lot, CLI is sufficient. It would be nice to do it programmatically, however config options in the MIB delays the whole process. Maybe later on RW objects can be added. Dan: Consensus required. Explain how to configure ipfix (operational mode). Emile: RW equals max access while in the compliance section this can be reduced. Juergen: table control objects needed. Emile: CLI would open the access to all configurations, limit access for various operators. Thomas: Depends on CLI design. Emile: SNMPv3 could help. Tanja: Want write parameters. The first ipfix charter excluded configuration, so it would be ok to postpone and keep on the future to do list. Juergen: Issue with MUST RW objects, as the MIB design would be different. Should have the option to have a read-only MIB. Collector should only be RO, while Exporter could be RW Benoit: Lots of complexity would be added with SNMP write, especially tables and templates. Dave H: Row control only required for adding rows, not necessary for changing row. Specific suggestions for table indexes provided. Juergen: Summary of the discussion. We will have the option for RO implementations. Reporting would optionally be RW. Templates will probably be RO. Methods: unclear, to be discussed on the list. ---------------- 7) Bidirectional Flow Export (Brian Trammell) - draft-ietf-ipfix-biflow-00.txt First edition of the document. Various bidirectional flow representations described. Proposal: assign reverse PEN (private enterprise number) to the draft (in the template record) Biggest open issue: how to assign direction of a flow (i.e. source, destination). Proposal: flow initiator (first packet, TCP active opener). Not applicable in all situations and platform architectures. Alternative: interface/address assigned via membership in address set or side of a given interface. If both don't work: assign randomly. The draft will select the three proposals where applicable. Scenarios for all three cases explained. Status: Version 0: august 2006. Version 1: November 2006. Juergen: If the draft proposes the chosen direction method, does it report the method? Brian: not yet. Elisa: We recommend for each scenario which method should be chosen. Andrew: Maybe add an IE to report the method. Brian: We discussed adding an IE, this is a potential solution. Andrew: Make it flexible, if during the metering you notice that the assumption was wrong, just modify the reporting of the direction. Emile: PEN is a strange proposal. Juergen: This is the option chosen by the WG. Andrew: Can enterprise numbers provide reverse direction? Brian: Not possible. Add recommendation statement to the draft. ---------------- 8) New drafts - Order of Information Elements (Hitoshi Irino) draft-irino-ipfix-ie-order-00.txt High performance collectors required due to high speed interfaces while the combination of IEs limits that. This draft addresses the problem and it targeted towards large networks and ASIC implementations. 3 step ordering proposed: 1. Data size 2. Group number 3. Order in each group Next step: new IE definitions to be added in next version. Andrew: Did you implement it? Irino: Started implementing collector and exporter Paul: Do you have performance figures? Hitoshi: Implementation not completed. Paul: Looks like a complexscheme. Might reduce performance. Dan: what document type are you targeting at? Irino: informational Benoit: Looks complicated. Suggest reducing the number of rules. Some of the rules are interesting, so it could be added to the implementation guideline. Elisa: I would like to understand better he advantage of this before adding it to the guidelines. Juergen: Let's discuss further on the mailing list. - IPFIX Mediator (Atsushi Kobayashi) draft-kobayashi-ipfix-mediator-01.txt Objective: make ipfix applicable for large-scaled multi-layer networks, e.g. MPLS where multiple mediators are required, resulting in cascading the mediators. Cascading collectors modify the addresses, the router option template would address this issue. Proposal: define new router option template. The router is indicated by exporter address, port, and observation domain. These details can be passed from mediator to mediator and be considered as the scope. Dan: Has this new entity be implemented? Atsushi: Partly implemented. Dan: Concern about the proposal. No standard documents are out and we are lacking operational experience, so it is to early for extensions. The problem is well acknowledged, it is simply too early for the WG (personal opinion). Juergen: This would be an extension. Practical experiences would be good to add, i.e. what is the benefit and at what size of a network is it required. - IPFIX Configuration Data Model (Benoit Claise) draft-muenz-ipfix-configuration-00.txt Benoit presented for Gerhard Muenz. This draft defines a datamodel to combine IPFIX and PSAMP configuration. Various configurable parameters exist in PSAMP and IPFIX. Benoit's feedback: The title of the draft is misleading as it covers PSAMP and IPFIX. Use of the same terminology from IPFIX and PSMAP would improve the readability. Open questions: use SNMP or XML for configuration? Dan: This is the first WG in the OPS area talking about using XML for configuration. Congratulations! - An IPFIX-Based File Format (Brian Trammell) draft-trammell-ipfix-file-02.txt Standard flow storage format is useful for interoperability while flat files are ideal for storage. Requirements: extensibility and self description. File format descriptions added, such as authentication etc. Future: refine proposed methods for meeting requirements, continue to gain implementation experience with ipfix files. Tanja: We asked many people how they store flow data, many are using NetFlow. Please send us input if you are using something else? Emile: Do you incorporate PSAMP? Brian: Yes. Emile: Isn't this dangerous because you may store packet content? Brian: The data are anonymized. Juergen: Sensibility of data is already covered, text can be extended. Paul: What did you implement? Brian: The basis is there, but not the compression and not most of the options. Paul: Do you include configuration information? Brian: No, but this would be useful. Paul: How would it benefit from the Irino draft? Brian: Haven't look at it.