Minutes for MAPRG at IETF-96
minutes-96-maprg-1

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!