Minutes IETF105: maprg
minutes-105-maprg-00

MAPRG at IETF 105

Note takers: Rich Salz / Brian Trammell

Overview & Status - Dave Plonka & Mirja Kühlewind

Understanding Evolution and Adoption of Top Level Domains and DNSSEC - Yo-Der
Song (remote)
--------------------------------------------------------------------
https://datatracker.ietf.org/meeting/105/materials/slides-105-maprg-understanding-evolution-and-adoption-of-top-level-domains-and-dnssec-01

George Michaelson: A study like this needs to explore the concept of generative
(hash) domain names for botnet C&C. New gTLDs are attractive targets for abuse
due to the ease of getting names. Many new TLDs have no intention of delegation
-- e.g. .ibm is not an open domain, and its growth is driven by its business
mission. You typify ccTLDs as if there is ICANN-prescribed normative behavior.
A ccTLD represents a government; it's only different in the quality that they
have tanks. Your paper was really interesting and thank you for presenting it!

Tim Wattenberg: Where'd you get the data, and what kind is it? Which kind of
analysis did you do with that data? Yo-Der Song: three datasets from NZ: In
presentation there is overview graph and second level domains created over time
for .kiwi and .nz Tim: And you got numbers from them but no zone files? Yo-Der
Song: Yes, just numbers. Tim: RIPE Atlas may be useful for future research

Ulrich Wisser (from The Swedish Internet Foundation): To George we are not a
government agency. For the record, we do not own tanks. ccTLDs are all over the
map. More domains signing DNSSEC than sending DNS records. Do these newly
signed domains support CDNSKEY? Yo-Der Song: From metadata, information not
available.

Ben Schwartz: 10% of records are invalid, can your clarify what you mean by
invalid? e.g your they fail with CERTFAIL? Yo-Der Song: It believe it is hash
fail with DSNKEY record but bot entirely sure.

Hiromu Shiozawa (JPNIC): On top ten TLD graph. I get a similar analysis for our
data. Which data do you use? Yo-Der Song: Top ten TLV was based on local campus
network at Uni Auckland.

Dave: You mention problem oof overlap e.g. between .kiwi and .nz. I'm curious,
how do you effectively determine "clones"/aliais within your dataset? Do you
have to do active measurement or can you get this from the registrations?
Yo-Der Song: Didn't look specifically at this but something to look at in the
future

TLS 1.3 Client Measurements - Tommy Pauly
---------------------------
https://datatracker.ietf.org/meeting/105/materials/slides-105-maprg-tls-13-client-measurements-0-00

George Michaelson: Is this our sample from Apple only from your clients, or
other measuring points? Tommy: Population of beta users or opt-in data
collection on normal devices across the world e.g. on mobile or wireless.
George Michaelson: Is there a skew in measuring because of the data set (e.g.,
no Android measurements or older phones). Might be a depending on update
circles because of negotiation. It come to the question is that only newer
devices you measure. Having a larger population v6 would have a higher outtake
because it's more present on newer releases. 80% of v6 in mobile. Tommy: Yes,
git points. Also only getting data on devices that have been upgraded to enable
1.3. So these are no older devices and no devices we don't own. It is early
adopters on the client side.

Ian Swett: Similar question about selection bias: was wondering if you have
attempted to do hold back experiment where half of the user did not have 1.3
enabled but recorded when 1.3 was available and see if other half actually got
better. Because that would remove server selection bias and we found that for
quic that's was kind of important. Tommy: Yes, early on before when were
turning it on by default we would do probing essentially detecting when LTS 1.3
was available even if we didn't use it. But because there is the performance
benefit we didn't want to hold people back. But yes, that's a very good point.

Jan Rüth: PDF seems to show that TLS 1.3 servers seems to be better connected
and more up to date. So what the real reason for the low PDF? Are they just
better connected or is it the protocol? Tommy: Yes, very good point. Lots of
bias. Also that we show that these are servers that are clearly adopting
"leading edge" (such as 1.3 and ipv6), they  are probably doing other
optimizations too. In isolated measurement we definitely do see the benefits.
RTT are a mayor fact. I don't think they dominate this but your are correct.

Roland van Rijswijk: Lead remark about they being leaders in adopting this. I
have a request: Can you look if these people have their domains signed and if
is was valid by looking at AD bit in the DNS response that our clients get to
determine DNSSEC deployment? Tommy: We don't have that but that would be great.
Noted

Brian Trammell: There are a few things that you can look into in the responses
that might identify server software, so you can correlate early adopter by what
software they use. Because on of the things we saw for example with ECN is that
nobody cares about actually turning it now it's just that defaults are better.
Would bee good for this community to know to what extent is the work we doing
driving defaults some of this deployment, and to what extent is this people
driving these decision? Tommy: good point, will need to figure out how to do
that in a privacy-preserving way.

Jana: Very similar point: Have you tried fingerprinting SSL libraries at the
server to corrective if there are libraries that have bad defaults turned on
and then performance actually sucks and that's why people have actually turned
it off? That's another correlation would I would be interested in but I don't
know how easy/feasible it is for you to fingerprint SSL libraries? Or if you
would even do it? Tommy: There would be the concern about ossifying on the
fingerprints of a given implementation; we've seen firewalls expecting certain
pattern of our own TLS implementation from our clients, so it's a tricky area.
Jana: Did not see any breakages mentioned. Tommy: Yes we won't share breakage
numbers but it's very low and pretty much the same as 1.2; nothing specific to
1.3. Jana: That's fantastic. Thanks!

Measuring QUIC Dynamics over a High Delay Path - Gorry Fairhurst
----------------------------------------------
https://datatracker.ietf.org/meeting/105/materials/slides-105-maprg-measuring-quic-dynamics-over-a-high-delay-path-01

Christian Huitema: You are mentioning QUIC, but you're testing one of 19
implementations. We'll get 19 different results. Gorry: When they are done, we
expect less diversity. Doubtful they will vary all that much with these simple
tests. Christian: Disagree. There is different when usin v4/v6, or how to check
window sizes, etc. Gorry: Let's get together to talk about the results and see
why we get them.

Jana:  Super impressed how close QUIC is to PEP TCP and far it in to plain TCP,
which also makes me skeptical. You're using Quicly, which is the right
implementation because I'm partially responsible for the performance of this
implementation, but I'm trying to understand what the TCP PEP is doing. Is it a
full terminator? Gorry: It's Split TCP you can see at traces. Jana: Part of
what you see is the different between Reno and Cubic because quickly currently
implements Reno. For the file sizes you have I expect Cubic ramp up much faster
because this is a high BDP link, so I expected a different there. Gorry: There
might be also some timer issues that could be fixed. This is not a complete
piece of work, it's a start. Jana: Super happy to continue working with this
and fix quickly implementation for any bugs.. Marten Seemann and I have a
simulation environment for testing. It would be good validate this stuff with
the simulator to see if you can replicate the same effects there.

Ian: Thanks for not using chromium quic, since there are many paper and
benchmarks based on that and that could overfit one implementation. Any maybe
have a bug in there that turn out to be a performance enhancer. That's always
my far. Thanks for picking an implementation that is the closes to the most
current version of the recovery and congestion control spec, so it validates
that spec largely works pretty well. There are some approaches that could
improve performance of quic here, any maybe TCP as well. BBR is one of them.
There might be other things that could mitigate this.

Aaron Falk: Do you know heater AQM is in use in those networks?
Gorry: They were not in use in those experiments.
Aaron: I'd be interested in seen how that's compared. I would also be
interested in comparison of fairness in terrestrial network. How QUIc behaves
compared to TCP. Gorry: Would probably put this in a simulator because there
are also some wireless effect here.

Colin Perkins: Would like to echo Christian's point. Lot of people have read
papers about certain quic implementation and widely extrapolate those results.
This group or qui group might consider to put out a statement about how to
benchmark quic and how to report realists and how to describe what you are
evaluation. It#s harming reception of quic when people to experiment with very
early version of quic compared to well-developed versions of TCP and right very
general conclusions. Gorry: That what I wanted to present here. We use quic and
we will keep up to date and that the only way to benchmark it now. Please don't
use gQUIC benchmark as your baseline. It's a different things. We really need
to track latest version of quic wg. Colin: Need to make sure publication are
more specific about what the test.

Trials and tribulations of migrating to IETF QUIC - Ian Swett
-------------------------------------------------
https://datatracker.ietf.org/meeting/105/materials/slides-105-maprg-trials-and-tribulations-of-migrating-to-ietf-quic-00

Jana: Thanks for bringing this. Was watching what happens when the gQUIC format
changes and as expected, it has already been ossified. This is exactly what we
were worried about and it seems like some of them are actually updating, which
is promising. But you mention the breakage a couple of RTTs in which suggest a
certain behaviour in middle boxes: they allow a few packets to go though and
then die. We've seen this before and given we see this again, I wonder ifs this
is the sort of thing you want to protect against, because if we assume that
either all packet go through or always all packets are block that is not
compatible with how middleboxes are build because they might pass it on to
different node that actually does detecting of what type of packet it is; by
the time this comes back you already forwarded a few packets. Not sure exactly
what's causing this to happen but we've seen that. May be worthwhile to
document some of this detections for others to use, because  it would be super
useful also for non chroming client to build these detections.  And second I
wonder is this is some we can specifically detect as behavior and use for
failover in chrome? Ian: We thought about specifically detecting it but it
turns out that so far we have only observed one vendor actually do this. So we
can email the vendor and ask to fix it. We#ve done that. Otherwise we ossify
the protocol on this weird this and the have this workaround feature and are
stuck with it forever and everybody else would need to add it too. I'd be okay
if chrome had to add it because we are early adopters and pushing it, but if
every other client on earth would have to add a bunch of extra heuristics that
would be kind of sad. Mirja: Insights about why this behavior or the vendor's
intention? Ian: Enterprise policy to drop quic. Way they drop unknown protocols
is to allow few packets in each direction. If after 2-3 packets they haven't
figured out what protocol they start dropping. QUIC go classed in v46 as unknot
protocol and got into this weird bin. The other thing I would like to comment:
This isn't good for any transport weather SCTP over DTLS. If you led th
handshake through and then black-hole it, it's gone be a really bad time for
the user experience. So to support UDP innovation the Internet, I would like
people to try to avoid doing this, not just for QUIC. That is not just for us
that is for anything. Jana: What I've seen on console of middle box is that is
say "packet received; can't classify; cannot classify" and then drops it. It's
possible that is trying to do classification on different thread and then
thread times out or give up and then it decided to black-hole. Agree this is a
huge issue. Unfortunately people how can change this aren't necessarily in this
room-

Tommy Pauly: Is blackholing only on a per-connection basis or and not the whole
device, so  per-IP? Ian: Typically it is the whole IP. Basically every QUIC
connection on that host starts getting black-hold. Because it's a middle box
where all quic connections go though. It's sort of host based. Tommy: Because
there is also be background data because of course always something might drop
off after a few packets. Would it be possible to look at all parallel
connection and if this other connection is further along it was just a network
impairment. That would not work in this case? Ian: We don't really trace that.
Can't say if that is true.

Brian Trammell: As co-editor of manageability draft, we will file you a couple
of issue to take this presentation into the draft. You said dropping all
packets for the connection is better than some from user visibility. That's
kind of obvious and we should actually write this down and yell it from the
tree tops of the IETF. You said for one of these you get the first 3 packets
and then you drop. Do you see other thing where you see intermediate drops
after you have stun up some actual data. Can you characterize the drop pattern
you see? Ian: We see some other post-handshake dropouts. Anecdotally seems to
be NAT related, instead of having a usage based timeout, it's fixed timeout of
e.g. after 60s I timeout this UDP instead of after 60s of idle and then you
have to ping to reopen it. Brian: See this also on non quic traffic. Ian: Not
super common but does happen.

Packet Loss Signaling for Encrypted Protocols -Alexandre Ferrieux
---------------------------------------------
https://datatracker.ietf.org/meeting/105/materials/slides-105-maprg-packet-loss-signaling-for-encrypted-protocols-01

Ian: Interesting data. For spin bit there is a fair amount of analysis what
happens if one of the two endpoints ties to "subvert" the signal. It seem like
it would be very easy to convince a middle box to give it any signal you
wanted.  Do you have thoughts on how to reject implementation that are either
buggy or not complying to the scheme. Alexandre: It's unilateral, only server
sets bits and that's what we are most interested in. Ian: Right now using these
bits would make header protection to fail and drop packet at received. Igor
Lubashev: No worse than TCP's plaintext.

The RPKI Wayback Machine - Roland Van Rijswijk
------------------------
https://datatracker.ietf.org/meeting/105/materials/slides-105-maprg-the-rpki-wayback-machine-01

Robert Kisteleki: Not sure if it's worthwhile, but an option to disable
manifest check might get the earlier data. Roland: Yes, and we'll make the
validated-only data available. Brian: Former RPKI skeptic.  Thanks. Volume,
coverage, and visualization of data is useful to see trends. There is a risk to
turning data validation on. Risk for your dataset is 1/accuracy, right? Roland:
yes Brian: And it's prefixes or announcements? Roland: Announcements have
prefixes in them

Recyling Large-Scale Internet Measurements to Study the Internet's Control Plan
- Jan Rüth
-------------------------------------------------------------------------------
https://datatracker.ietf.org/meeting/105/materials/slides-105-maprg-recycling-large-scale-internet-measurements-to-study-the-internets-control-plane-00

Hackathon Report - Dave Plonka
----------------
-> did not present, see the slides
https://datatracker.ietf.org/meeting/105/materials/slides-105-maprg-maprg-hackathon-report-01