Minutes IETF102: maprg
minutes-102-maprg-00

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.