===================================== Ip Folw Information Export WG (IPFIX) IETF #74, Stockholm Monday, 27 Jul 09 at 1520-1720 Taken by Ralf Wolter ===================================== Chairs: Nevil Brownlee Juergen Quittek 0) Session summary 1) Agenda review and WG Status 2) Update from last meeting 3) Drafts submitted to IESG 4) Current WG drafts 5) Other drafts 6) Any Other Business 0) Session Summary Three IPFIX documents (file format, single SCTP flow export, MIb module) are under IESG review. Two mediation drafts (problem statement, framework) will enter WGLC with next version. Work on PSAMP MIB will start when all IPFIX MIB issues are solved. Work on IPFIX configuration is on hold waiting for YANG to be completed by the NETMOD WG. At this session three proposals for new WG work items were discussed: structuring of IPFIX records, flow anonymization, flow selection. For all of them there was consensus to accept them. Approval on mailing list is still missing. 1) Agenda review and WG Status There were no requests to modify the agenda. The document on exporting type information was published today as RFC5610. The IPFIX MIB module is still under review in IETF last call. PSAMP: 4 of the 5 scheduled documents published as RFC: - A Framework for Packet Selection and Reporting, RFC 5474 - Sampling and Filtering Techniques for IP Packet Selection, RFC 5477 - Packet Sampling (PSAMP) Protocol Specifications, RFC 5476 - Information Model for Packet Sampling Exports, RFC 5475 The PSAMP MIB was moved to the IPFIX WG and the PSAMP WG will be closed. 2) Update from last meeting a) Exporting Type Information for IPFIX IEs (Elisa Boschi), draft-ietf-ipfix-exporting-type-05 approved as PS, to RFC Editor 10 Jun 09 b) Information Element Registry status: Nevil is working with IANA on getting the changes made as per the current errata 3) Drafts submitted to IESG a) IPFIX MIB (Thomas Dietz) draft-ietf-ipfix-mib-07.txt Currently in IETF LC. Changes: - MIB doctor review issues fixed, - Alignment with IPFIX configuration draft - Open topics: minor and editorial issues Summary: almost all issues solved Outlook to PSAMP MIB: will be based on IPFIX MIB, will be the first user of the IPFIX selector MIB Dan Romascanu (AD): Will there be an updated version before submitting to IESG? Thomas: Yes 4) Current WG drafts a) Configuration Data Model (Gerhard Muenz) draft-ietf-ipfix-configuration-model-03.txt Changes in version 3: - many editorial changes - UML class diagrams used, some feedback from UML experts would be appreciated - Clarification related to Observation domain - configuration of mutual authentication and authorization added. Call for review! - open issues: psamp parameters, TLS/DTLS parameters - next step: WGLC for final feedback, clarifications, and changes b) IPFIX Mediation: (Kobayashi Atsushi) draft-ietf-ipfix-mediators-problem-statement-04.txt Issues: - WGLC for v3 ended on June 5th - v4 published, editorial changes, some corner cases to be added - define boundaries between problem statement and framework - exclude examples from terminology - does IPFIX mediation cover Òtransport protocol mediationÓ? - 1 open issue: change transport protocol from UDP to SCTP - new mediation proposal: ÒIPFIX Mediation is the manipulation and conversion of a stream of records for subsequent export using IPFIXÓ - editorial changes - next step: editorial improvements and submit to IESG Juergen: When discussion the draft with Nevil, we thought about having another WGLC before submitting Atsushi: Agreement, there will be one additional WGLC. c) IPFIX Mediation: (Kobayashi Atsushi) draft-ietf-ipfix-mediators-framework-03.txt Issues: - v3 published - changes: feedback from WGLC applied - one open issue: in case of NetFlow to IPFIX translation/mediation, what function is needed? Benoit: Slide 8 Ð conversion from NetFlow to ipfix. A proxy function is required Atsushi: Even a proxy needs an intermediate process. 5) Other drafts a) Handling Structured Data (Benoit Claise) draft-claise-structured-data-in-ipfix-01.txt Issues: - second version of the draft - IPFIX has always focused on flat records, this draft extends RFC 5101 and 5102 to support hierarchical data. - basicList example: IPmc output interfaces, BGP AS path, list of port numbers - subTemplateList example: MPLS label and value could be exported in one flow record - subTemplateMultiList example: aggregated observation point David Harrington: What does Òless security focusÓ mean? Benoit: Initial version was security focused, additional examples from different areas added. - new in v1: usage guidelines, example of aggregated observation point, XML specs added - next step: correct mistake in one example; Brian proposed changes to subTemplateMultiList element Humming: a clear yes from the audience to include this as a candidate for the re-chartered WG. b) VoIP Monitoring and Exporting (Thomas Dietz) draft-huici-ipfix-sipfix-00.txt - motivation: distributed monitoring is needed in VoIP networks - use cases: QoS, SLAs, Traffic Engineering, Troubleshooting, Security, Billing, Law enforcement, etc. - proposal: standardized approach way to make probes, (mediators) and collectors talk to each other Adriel: in practice this doesnÕt work for QoS, SLA, None of the use cases are applicable. The chosen headers are not nearly enough. Theo: Where are you expecting the exporter to run / be implemented? Thomas: Not clear yet. There is a need to export the data, location of implementation to be chosen later. Q: Why use IPFIX for this? Thomas: Build on existing standards, SIP and RTP are flow-based protocols. Adriel: SIP is not a flow but an application layer protocol and cannot be treated as a flow. RTP can be used as a flow. Request and response in SIP can go through different paths. Thomas: Mediation could help. Adriel: This would require IPFIX implementation pervasively in the Internet. Juergen: This proposal was based on an operatorÕs request. This is not a question if the SIP community wants this. Q: here to go and what to do? OaM area or RAI area? Dan: This is the third time that we see a request like this, we would like to understand it and be able to solve where to go. Discussions about specific data cases are required to see where the proposal helps. Use cases should be the focus! Theo: Vijay will present use cases from RAI in the ops area. Margaret Wasserman: It should be done in RAI area because if they donÕt want it, no ine will implement it. Benoit: Why is the third option not relevant? Juergen: Because it should be reviewed in RAI area Benoit: ThatÕs fine, IPFIX should just be the export protocol, the RAI group should define the IEs. David: SIPCLF is doing some work in this area, Dave is providing input there. Use cases have not been discussed in details yet, more clarification required. Adriel: The IPFIX format is fine. Juergen: DISPATCH group has just started, might take some time but work will be done anyway. Maybe a SIPops WG required with 1 chair from RAI and one from OaM. Gurbani: DISPATCHhas reached a decision, currently Syslog and IPFIX under evaluations. Dan: From IPFIX perspective, how to deal with future requests? Should ipfix continue as a general WG to support other technologies (e.g. IPFIX doctorÕs group) or just close after finalizing the current work? Juergen: Any comments? David: Based on SNMP MIB experience, in the past people approached the opsarea to define MIBs for other technologies. It would make sense to have this WG to provide guidance. Brian: Supporting DavidÕs comments, have a guidance document in addition to RFC 5102. c) Implementing IPFIX over DTLS (Gerhard Muenz) draft-mentz-ipfix-dtls-recommendations-00 Issues: - has anyone implemented DTLS support? One attempt failed (Brian), only VERMONT (Gerhard) succeeded - background: RFC 5101 - support of DTLS mandatory for IPFIX-over-SCTP and IPFIX-over-UDP for security reasons - problems with IPFIX-over-DTLS/UDP explained: exporter cannot detect a crash of the collector as traffic is unidirectional, after reboot the collector cannot decrypt/verify incoming IPFIX messages due to lost DTLS state - proposed solutions stated, e.g. DTLS heartbeat extensions - conclusion: currently only ÒOpening a new IPFIX Transport Session solves both problemsÓ, alternatives required. If anyone works in this area, interop testing would be nice. Juergen: Should there be an updated version of the implementation guideline? Gerhard: More experience Chris Lonvick: Syslog WG is considering DTLS, information should be shared. Syslog is also a unidirectional protocol Elias: Implementation guidelines requires multiple implementations first! Gerhard: Yes, agreed Brian: DTLS guidelines for unidirectional transports Ð should be moved to transport area? Dave: Syslog and SNMP work are done in security area, not transport Dan: Agreeing with what everyone has said. Concern: we have one failed implementation reported. Brian: this was 2 years ago, things are much better now. Dave: For SNMP, Hardaker was the contact. d) IP Flow Anonymization Support (Elisa Boschi) draft-boschi-ipfix-anon-04 Issues: - this is v5 now, the topic has been presented a couple of times - motivation: support for anonymization is one of the requirements for IPFIX (RFC3917) - could be implemented in a mediator - status: document is pretty mature now, a few extensions added - already part of the charter, it fits with mediation work and there is a working implementation - proposed status: experimental Dan: Why experimental? Elisa: Tools are from the research field Dan: ÒexperimentalÓ requires description of the experiments Juergen: Very few commercial software exists. Dan: ThatÕs ok Juergen Schoenwaelder: Security consideration is not an easy task, donÕt underestimate the work Brian: Anonymization is not meant as a replacement for encryption. This draft is not about specific tools, but the output what can be done. Risk is outside of the scope. Elisa: An anonymized trace is not an anonymous trace, we donÕt claim that. Juergen: Lets get security experts involved early. Margaret: Global question Ð where did the requirements come from? Will there be commercial requirements? Elisa: Experience of the authors is limited to research, therefore currently experimental focus. This has started in 2001. There are anynomization tools available now. Juergen: Usually there are legal issues due to de-anonymization tools available. We want to find out what happens, the use case is real, the outcome not. Margaret: Get implementations and see if results fit the use case? Elisa: Validity of certain solutions cannot be tested. Humming: very clear support for this proposal. e) Flow Selection (Elisa Boschi) draft-peluso-flowselection-tech-02 Issues - Elisa presented on behalf of Tanja - motivation: resource control, limit resource consumption, e.g., only collect elephant flows. Example: PlanetLab Europe - comparison of packet vs flow selection as input for sampling - position of the Flow Selection Process: after classification, options: during flow recording, at exporter, at collector - is there interest in the WG? Humming: very clear support for this proposal Juergen: All three proposals will be sent to the mailing list for further discussion. 6) Any Other Business No issues.