=============================================================== Network Management Research Group / 3rd NetFlow/IPFIX Workshop IETF #78, Maastricht, Netherlands FRIDAY, July 30, 2010, 09:00-1515, Room 0.8 Rome =============================================================== Agenda: http://www.ietf.org/proceedings/78/agenda/NMRG.txt Presentations: https://datatracker.ietf.org/meeting/78/materials.html Opening: - Meeting Chairs: Ramin Sadre Aiko Pras - Minutes taken by Idilio Drago and edited by Ramin Sadre - Wes Hardaker Sparta took care of Jabber and remote participants Discussions: * Using of time characteristic in Netflow data for improvement of protocol detection (Pavel Piskac, Masaryk University/INVEA-TECH) Q: About slide 8: Are those fields all you need? A: At this time, yes. We need also the 'package size'. Q: About slide 9: What time resolution do you need? A: Microsecond. Q: I am scared about this time resolution. Don't you think that the router will be busy only with measurement? A: We can use an external probe equipment to avoid that. Q: Have you performed similar study with IPFIX? A: Not yet. Q: But those fields are in IANA assignment. Is it a matter of implement it? A: Yes. Q: About your picture on slide 20: Did you look into those irregular peaks in your graph? I have the same in my research. A: Not yet. Q: How have you defined your threshold? A: By hand, using data observation. C: A lot of things have been done on using NetFlow data for security. It is time to move on to something new. * Flow signatures of popular applications (Nikolay Melnikov, Jacobs University Bremen) Q: Does an application signature differ by OS? A: We have tried 2 OS. In some cases, there are differences (like Chrome). But in general, there is no variation. C: But there are differences on the TCP/IP implementation of different OS's. Q: How are the signatures changing over time? More or less like in an anti-virus? Have you looked into that? A: Not yet. We are expecting that, e.g when you have new versions of a software, but we have not researched it yet. Q: What about privacy of your users? A: That is why we are using flow records (without personal identification, like IP addresses). Q: But even without IP addresses, if you can identify a user, it is still a problem in some countries. A: Our test-users were aware of the purpose of this research. * IPTV Traffic Monitoring System with IPFIX/PSAMP (Shingo Kashima, NTT) C: There has been a software demonstration during his presentation. Q: Have you done any analysis of the accuracy that you can achieve? A: See slide 12: Information from RTP, so it is not an estimation. Q: Is this tool available? A: Not for the public. Only internal in NTT. Q: Did you assume any specific loss distribution? A: We assume constant package loss. * NetFlow/IPFIX Various Thoughts (Paul Aitken and Benoit Claise, Cisco) Q: Do you have any collector to be deployed supporting IPFIX? A: For researching, yes. For commercial use, Cisco has partners developing collectors for that. Q: So, does Cisco have a collector? A: Yes, Cisco NetFlow Collector. It supports all IPFIX. Q: Is it available? A: Yes. You can find it. Q: What are the differences between what you have presented and real routers? A: New things are being developed. For example, new routers are to be announced supporting Flexible NetFlow. Q: Is Cisco supporting your work? A: Yes. But things take time to be available on the market. C: There are some nice tools outside Cisco for IPFIX development, like NTOP. You do not have to wait until a vendor prepares a product, for starting your research. * A Labeled Data Set For Flow-based Intrusion Detection (Anna Sperotto, University of Twente) Q: How do you cope with privacy? A: Anonymization. Q: How exactly? A: We use the method from Nfdump. Q: Have you created the flows from tcpdump? Do you have all data? A: We assume that we have everything, but we can see that some loss occurred based on the match with the server log files (99% of match). Q: What was the load of the monitored link? A: Only one machine was monitored. Therefore, there was not so much load. * Malware Detection From The Network Perspective Using NetFlow Data (Pavel Celeda, Masaryk University) C: Nice story! Do you know The Cuckoo's Egg (book)? Q: How have you discovered the botnet? A: Our students were developing (and using) tools for monitoring the network. They saw a lot of telnet connections. Then they started to reverse engineering the botnet, from infected devices. At the end, we were part of the botnet. Q: Is your plugin only for this botnet? Or, is it a general solution? A: We have been developing things for general purpose detection. This one is only for the Chuck Norris botnet, but we are planning to make it generic. Q: What are the flow timeouts in your system? A: 5 minutes for active timeout and 30 seconds for inactive timeout. Q: Do you have any paper describing this work? A: It has not been accepted yet. But we are trying to publish it. C: We have reported authorities about the control hosts of the botnet in Europe, but nobody has taken any action up to now. C: There are still a lot of ADSL modems around the world with admin/admin as login/password. * Characterization of accuracy problems in NetFlow data and approaches to handle them (Jochen Koegel, University of Stuttgart) C: About the "load dependency" question: maybe you have an answer on slide 9. C: Did you inspect only NetFlow traces? It would also be interesting to compare other probe equipments. In our experience, taps can introduce delays, for example. Q: Do you know which manufacturers were involved in your test? A: Not of all equipments. Q: Did you consider that the flow record could stay on cache sometime before being exported? A: Yes, I am looking at the starting time of the flow, not the time that the record was exported. C: Your data are not about the network, but about the network as seen by a measurement system. Maybe that is also something to be carried in IPFIX: information about the collector device, so that one could correct bias on the measurement system. * ripfix: Rapid Prototyping and Debugging of IPFIX Applications in Ruby (Brian Trammell, ETH Zurich) C: Which tools are the audience using to analyse flow data? * The Tranalyzer and Traviz tools (Stefan Burschka, Swisscom/CSIT) Q: Does this tool also export NetFlow to ordinary collectors? A: This tool is not a NetFlow exporter. Tranalyser can read from tcpdump and from Ethernet interfaces - it could export NetFlow data, but there is no plugin for that yet. Q: How do you compute the top talkers? A: We sort the data first. Q: Isn't that too slow? A: We have implemented everything in C, focusing on performance. Q: What is the license of this tool? A: GPL. Q: Does this tool use "pcap-nanosecond"? A: Not now. We are now more interested in the amount of data we can analyze. * The trace2netFlow tool (Lucjan Janowski, AGH Poland) Q: What programming language have you used? A: C. There are compiled versions available for MAC, Windows and Linux. Q: What protocols are available? Do you plan to implement other protocols? A: We are implementing things as we they become needed.