MAPRG Meeting at IETF 102 2018-07-19 9:30-12:00 Notetaker: Magnus Westerlund Intro & Overview Mirja Kühlewind 25 min https://datatracker.ietf.org/meeting/102/materials/slides-102-maprg-chairs-intro-01 Mirja opened the meeting and wellcomes everyone. IAB has reviewed the RG and how it works. Got Some feedback from the IAB and discussion about things to do/change in future (see slides). Aaron Falk commented regarding conflict resolution that for TAPS WG he sent out a question asking for people who liked to be in the WG and couldn't. Mirja responded that this may be hard as it depends on the RG agenda. Spencer Dawkins commented that people do know what research they are doing and therefore could provide input quite early. Mirja, however, commented that usually the agenda is not ready early enough. Colin Perkins commented that with the increase in presentation on measurement research with the ANRW and the MAPRG, it should be clear where things are presented so that they are not brought up multiple times. Chairs considering involvement in the Hackathon, but how is under discussion. Welcome to discuss this further. Brian Trammel commented on MAT working group in RIPE (as co-chair). Maintain loose information exchange if of interested for both groups but slightly different focus. Aaron Falk commented that if one writes a blog post, one gets a T-shirt. Heads-up talk: Dmap: Atomating Domain Name Ecosystem Measurements and Applications Giovane C. M. Moura 5 min https://datatracker.ietf.org/meeting/102/materials/slides-102-maprg-dmap-automating-domain-name-ecosystem-measurements-and-applications-giovane-c-m-moura-00 No questions. Heads-up talk: Monitoring DNS with open-source solutions Felipe Espinoza 5 min https://datatracker.ietf.org/meeting/102/materials/slides-102-maprg-monitoring-dns-with-open-source-solutions-felipe-espinoza-00 Jon Reed - Akamai: Where are you capturing information? -> The authority server of the chilean top domain. Had experience that capturing recursive and figuring out the actual user experience is hard. Sara Dickison: What format are you capturing the information pcap other? -> Not using CBOR. Packet Reordering in QUIC Ian Swett 10 min https://datatracker.ietf.org/meeting/102/materials/slides-102-maprg-udp-packet-reordering-ian-swett-00 Tommy Pauly: Client-side on packet re-order is this for both? -> Only in the client direction. Aaron: How is this distributed over flows, a small number of flows that causes lots of issues? Is it topology concentrated or more pervasive? -> Ian didn't have the answer. Erik Nygren: Do you have sense how much of how much is fragmented packets? -> They set DF on the flows, so there should be no. Colin Perkins: Do you know which packets gets reordered? -> A common case is that if one has queue pressure and then a small tail packet, then it can raise ahead. Colin: Do you seen reordering in connection establishment? -> Very little. Brian Trammel: I would blame WIFI for a lot of reordering. Gorry Fairhurst: It would be interesting to know how this looks for TCP. -> Ian agreed, that it would be. Is Bufferbloat a Privacy Issue? Brian Trammell 15 min https://datatracker.ietf.org/meeting/102/materials/slides-102-maprg-is-bufferbloat-a-privacy-issue-brian-trammell-00 Aaron Falk: Struggling with the initial premise. -> Brain: Okay then give me your IP address... one can tell if one are using the network or not. If one pings frequently enough one can determine bulk transfer versus more interactive. Stephane Bortzmeyer, AFNIC: Why do you need ICMP, there are other ways, like TCP syn + reset pattern. -> Yes, but already measuring with ICMP. Giovane Moura: Many networks treat pings differently, how does this affect the results? -> Brian: yes some of the networks that doesn't have any load indication may be a case of this. Will try using TCP. Wes Hardaker, ISI: Have used DNS to determine peoples wake and sleep cycles of the inhabitants. This gives you even more. Benjamin Damm, Itron: Appreciate the research, if you don't see this a problem, you just haven't had anyone trying to hurt you. Felipe Espinoza: Can also use this to monitor webserver to get cooperate information e.g. how many people visit which website when. Lorenzo, Google: A different advice, is to randomize the response time for ICMP. Probably in the bad advice column. Clusters in the Expanse: De-Aliasing IPv6 Hitlists Quirin Scheitle 15 min https://datatracker.ietf.org/meeting/102/materials/slides-102-maprg-clusters-in-the-expanse-de-aliasing-ipv6-hitlists-quirin-scheitle-00 Erik Nygren: How do you handle load balanced clusters? -> A prefix of IP addresses can go to any of the servers in the cluster. The original classifier would be considered as aliased, but verification is likely to not considered to be aliased. Lorenzo Colitti, Google: Set random TCP options to make the fingerprinting less efficient. -> Yes, there are a number of reasonable protections. Need to look at what we can do to prevent at protocol level from allowing this type of fingerprinting. Tobias Fiebig, TU Berlin: Did you compare clusters to IPv6-reverse-DNS-zones data set or other data set? -> We have been in touch before. Igor Lubashev, Akamai: A pretty large IP prefix could have multiple backend servers and distribute among them in a more random order. Would not be classified as alias. Could one consider to detect a set of endhost being the alias for the same address set? Tatauya Jinmei, Infoblox: What if one have really large prefix. Found one /29 which was the same machine. Tim Shepherd: was that a firewall? -> No, it was a NGIX. Measuring the usable maximum packet size across Internet paths Gorry Fairhurst 20 min https://datatracker.ietf.org/meeting/102/materials/slides-102-maprg-measuring-the-usable-maximum-packet-size-across-internet-paths-how-can-we-make-pmtud-work-gorry-fairhurst-00 Aaron Falk: Some of the problems are in the network, some are in the end-systems. Are you doing anything to fix this. -> Gorry thinks there are some things that may be simple to fix, but the real solution is to address this in the transport. Yoshifumi Nishida: Can we know where it happens and what variations? -> Gorry answered that yes they have data for which hops. Lorenzo: ICMP is unfixable which you show. Transport is the layer that can do something. Important to not blackhole, and do not introduce latency. Thus start small and do probe in parallel. The cost for failing is to high, thus the 1280 clamping in a lot of service for IPv6 -> Gorry: yes that is what DPLMTUD does. Jana Iyangar, Fastly: What Lorenzo said is important. Not relying on ICMP is the right way. Gorry doing SCTP and UDP is actually simpler as they normally allow probe packets, while TCP has issues sending non data probe. Working on QUIC to test the algorithm. Erik Nygren: Based on what you measured, do you get any use out of path signaling, like MSS clamping. -> Gorry: It would be good with a path signal, but MSS clamping is not the right signal, only a side-effect. Ron Bonica is working on an IPv6 stack signal. When the Dyke breaks: dissecting DNS Defenses during DDoS Giovane C. M. Moura 20 min https://datatracker.ietf.org/meeting/102/materials/slides-102-maprg-when-the-dyke-breaks-dissecting-dns-defenses-during-ddos-giovane-c-m-moura-01 Jon Reed: What if one authoritative server of several is hit. -> Results in paper for this. Treated recursive layer as one block. Robert Kisteleki, Ripe NCC: Put in measurements to be able to detect if the root servers are hit. Paul Hoffman: I like the measurements, but not the conclusions. Due to the answer is that one works, should have more focus on getting one authoritative instance working. Jinmei Tatuya: Did you get information for the caches. The methodology allows for determine what is coming from caches and what is not. If one change what is provided from the caches, then one can determine what has been stretched. Mark?, NL?: In the Netherlands we had an incident where the recursive was unable to reach the authoritative, due to a DDoS on the recursive uplink. A: Depends on the recursive, but hard to answer based on this material. Finding the source of DNS resolver users that were using old DNSSEC keys Wes Hardaker 20 min https://datatracker.ietf.org/meeting/102/materials/slides-102-maprg-dnssec-ksk-2010-trust-anchor-signal-analysis-wes-hardaker-00 Roy Arends, ICANN: Double signing is not the only problem. The issues is when you stop signing with the old key. Github contains a lot of cruft. Those 2000 results are only 300 unique files. Some of the repositories are very popular and have been forked a lot. Davi?: Many are likely aware of the announcement, but not the work that is being done. IOT devices appear to have a similar problem with updates and trust anchors. -> Wes: What is clear is that there needed to be a longer time period to prepare for the roll over. After the actual roll over there will be need to consider these issues more.