Meeting minutes Proposed Measurement and Analysis for Protocols Research Group (maprg) at IETF-96 (Berlin) Monday, July 18, Afternoon session III 18:00-20:00 Room: Potsdam I Meetecho recording at: http://recs.conf.meetecho.com/Playout/watch.jsp?recording=IETF96_MAPRG&chapter=chapter_1 Dave Plonka and Mirja Kühlewind: Intro & Overview Leslie Daigle: Network Operator Measurement Activity (NOMA) with John Jason Brzozowski: Basic ipv6/ipv4 Measurements Lars Eggert: While you talk to the operators, ask them if there's a way to make the data available (for other researchers) Leslie: interesting discussion, first point is to try to piece out some of the data for any kind of public consumption Phil Eardley: IIUC closed community, workshop between operators, measurement data amongst themselves, point is to learn joint lessons? Leslie: no, closed workshop is to get operators interested in doing this, and get used to the concept of sharing some version of their data to a neutral third party public that will publish it publicly. There will be a public view of the data. Phil: You're going to come up with a sort of BCP of how to do measurements. Maybe tools for other operators to use? John: I think we wrote some of that down. Did it for the last IETF, had an LMAP draft that we had to split into two separate drafts; talked about open sourcing some of the stuff that we did. From what we heard it would help, to jumpstart somebody else trying to get going Phil: In IPPM we talked about having a registry of tests. Good idea, but standardizing all these tests is a long-term activity. Having something as an intermediate step to start agreeing what common tests are would be good John: Yes. Commented on this in IPPM or LMAP, I think you should insist that reference implementations to be included Leslie: this is complementary to other excellent work out there Philipp Richter: Beyond Counting: New Perspectives on the Active IPv4 Address Space David Dolson: Visualization interesting. Collected from a CDN; why don't you try to account for some blocks that may never try to contact your CDN? Other people's servers would never initiate connections, I wonder if you account for that at all? Philipp: Of course we are limited to the CDN's perspective; what made us confident that we're covering a large portion of address space is, if we compare to ICMP, the fraction of IP addresses that are visible within ICMP but not visible in our logs is comparably small; of course would need other measurements to extend to server space Dave Plonka: Measurement and Analysis for Internet of Things David Dolson: You talk about privacy and all this, but on the other hand you found it interesting to have that source port that you could use to track. If the network is being flooded, and we want to see if there is a bug with something, your house is sending stuff - how do you figure out which device it is if there is no signature? Should IoT devices somehow tag traffic so that you can track down which one is buggy? Dave Plonka: Collect thoughts instead of saying what I think about this Christian Huitema: Working a lot on privacy of Internet. One of the things we're doing is using encryption, and as much metadata as we can of the packets. Isn't there tension there? If I strip my metadata you won't be able to tell? Dave: Deserves design attention. Christian: Can we do these statistics in a way that preserves privacy? Dave Plonka: Great question Lee Howard: Great question but out of scope. Five tuples are great metadata to use though. DNS servers are another fun place to mine for potential data. I see things going to ntp.net.com, hey that's a sign. Dave: Yes Matt Mathis: Seems the best signal are the ones that are accidental. Any signal that you design turns into a security problem. For instance the port numbers were unusual as an accident, which became a useful signal. That's a repeated pattern, that the best signals are accidental. Giovane C. M. Moura: Anycast vs. DDoS: Evaluating the November 2015 Root DNS Event Dave Plonka: first thing from the way maprg was formed, how is this instructive for the design of operation? Do you have a recommendation? You asked a couple of times rhetorically in your talk: are these enough locations? Giovane: what choices do you have - can withdraw routes, you can keep them - we show it's more complex, depends on the attack, hard to make good choices Matt Mathis: do you know if any of the withdrawn routers were delivered or were they also collatoral damage Giovane: good question. Some may have been collatoral damage, we didn't have access to this information ??: single vantage point, single site, but great study, really useful. Have you also looked at single vantage point and multiple sides, to see what the dynamics as as one site was changing, to see what another site was doing over time? I mean, not sites of a single instance but different instances, like different letters at the same time - you have a single vantage point, what does that vantage point look like as these changes are happening across multiple sites but they still have 13 different instances of root servers to look at Giovane: one measurement per root server letter, per time you have a measurement from each probe to all the 13 letters ... we didn't do the analysis of looking at the individual probes and how many of the letters they could reach at a time, but that's somthing that can easily be done Varun Singh: WebRTC Performance Analytics Dave Plonka: 2% are v6 only, where in the world is a browser that does v6 only? Varun: I think it's mostly Europe. Actually I haven't looked up why there's only v6 Lorenzo Colitti: dhcpv4 was timing out Eric Vyncke? from Cisco: Don't know any v6-only network in Europe, but I could be wrong. Do you have the data that shows all v6 enabled nodes are relying on TURN server? Varun: Yes, we have not shown the plot Eric Vyncke?: Is it high or low? Due to NAT? Varun: have not diagnosed the TURN v6 much. Some infrastructures really don't have v6, if you run a TURN server on Amazon, I think they don't give v6 addresses. Haven't looked at TURN/v6. Eric Vyncke?: RTT difference between v4/v6? Varun: We didn't look at it. Good question. Lorenzo Colitti: Do you have data about firewall traversal in IPv6, is it better or worse? Varun: yes, haven't had time to look at the data in detail. should look at v6 regarding throughput etc. Michael Tuexen: data channels, or only video/audio channels? Varun: we have some data, but it's separate, from BitTorrent-type of traffic, not from companies that use audio/video. Happy to share. Johannes Klick: Temporal and Efficient Analysis of Services Availability Dave Plonka: rate limiting in routers. v6, also happening in v4 ... is there a compelling reason why you pursued this technique, to not use up all tokens in routers? What's the value of doing this instead of just doing a full scan? Answer: The value is that we can get quite similar results by scanning less; as I have shown before, if you're issueing a lot of SYN packets, this can have impact on your results. One point is that we're getting abuse messages, also law complaints, intrusion detection systems and routers, especially for IPv6 ICMP, after some high rates there will be drop-offs, this can also have impact on results. Therefore we need to scan less from an ethical point and also from the point of data quality. Tommy Pauly: A View Through Happy Eyeballs: Client-Side IPv6 Metrics Lorenzo Colitti: could you use something to detect things like a man in the middle? SYN/SYN-ACK latency is going to be entirely a function of whatever man in the middle you're talking to. Something you could do, look at ack-clocking, deeper into TCP connection, is there something? Keep-alive connections for example, when you measure time between request/response of some static thing that you've already requested, I don't know Tommy Pauly: definitely we want to look further into the connections Lorenzo: would you find what you're looking for? Have you thought about this? Do you have something that you think will work? Tommy: Not yet, but love to have suggestions Lorenzo: This is a crying shame when networks have v4 transparent proxies, and experimental data saying v6 is faster on those network, racing to deploy v4 transparent proxies as well, seems silly, if we could counteract that ... Olivier Bonaventure: You take all connections initiated by the device, then you sample them at 1% whatever the destination, then send information back to Apple for analysis, is this correct? Tommy: yes, when our library initiates a connection we flip a coin and choose 1% of those as eligible for tracking Olivier: as a researcher I think this is a really nice data set, as a user I'm not sure that from a privacy viewpoint i'm happy to see this kind of information to be sent to servers for any destination that I reach Tommy: we don't have any information whatsoever about ip addresses, just v4/v6 breakdown Olivier: but you have information about the carrier Tommy: these are only from people who have opted into data collection Alexander Azimov: do you have some historical data? Would be very interesting to see if this gap in latency between v4 and v6 is changing Tommy: agree interesting, first data we have is from last friday, love to report back in a year and say how it's gone Runa Barik: DSCP and the Evil Bit Lorenzo: proposal for RG policy: future presentations, if they have v4 only data, they must include the "danger: v4" sticker in their slides Lars: should be more time for discussion Mirja: will figure out, sometimes there are no questions Harald Alvestrand: just checking, you sent icmp packets and tcp syn packets, no udp packets? Runa: yes Harald: suggest that for the next version, would be fun to see the difference Runa: yes, we got suggestion to test with STUN packet directly Matt: how many vantage points inside corporate networks? Were you measuring enterprise firewalls at all for instance? Runa: We measured e.g. at an airport, in a cafeteria, shopping mall.. Matt: So public ISPs Dave Plonka: close the meeting Mirja: if you have questions, or would need data, or have data, let us know!