Minutes IETF103: maprg
minutes-103-maprg-00

MAPRG Meeting at IETF 103
Nov 6, 2018
Notetaker: Chris Wood

# Intro (Mirja Kühlewind)

Mirja reminded group and speakers that there is an option to write a post on
the IETF blog about measurement work presented in maprg to address a broader
audience. Let Mirja (or Greg Wood directly) know if you are interested in
writing a post. Aaron noted that you can get a free t-shirt for that.

Mirja also asked to having maprg as a venue for collecting data.

Brian Trammell (on remote queue): We should consider doing this. Work in MAMI
project on building referencable databases on intermedia measurement results
that I could talk about in Prague, or hackathon in Prague. There was a dagstuhl
workshop on repeatability in measurements where we also talked about
harmonizing the APIs for these kind of platforms. So I could summarize for
Prague and we can talk more form there.

Mirja also reported that Dave Plonka with organize an hackathon table in Prague
for maprg.

Tom Jones: Support this idea. I would be there. Comcast has offered before to
provide a platform for VMs for measurement. It has to be organized before but
this would be a good use.

# Heads-up talk: Privacy and Security Issues in IPv6 Deployment (Tobias Fiebig)

No mic questions.

# A Tale of Two Checksums (Tom Jones)

No mic questions.

# QUIC Performance over a satellite public Internet access (Nicolas Kuhn)

Ian Swett: Not surprised about results. Hard to do end-to-end split TCP. On
satellite congestion in the 1000s. Our numbers show that a median congestion
window for typical connection is 20-40 for most users — results seem to be two
orders of magnitude larger. There might be some things we could do at the
server but by nature this is one of the cases where end-to-end is actually
worst because this network is so different from a typical network and
connections are usually relate short.

Nicolas: We already did measurement with just a large initial window. It's not
possible to usually do that but we will try to find some small tricks that can
help us.

Ian: Probably you would want an initial window to be 1000. That would help you
a lot but take a lot of people super grumpy. We always pace at QUIC and Google.

Wes Hardaker: Did measurements on UDP vs. TCP about 15+ years ago, especially
on satellite.  Results are not valid anymore but we saw a lot of loss. Did you
look into lossy networks in this study?

Nicolas: In geosatellite fixed access networks loss ratio is lower than in
LTE/Wifi, basically we have no loss. For mobile users we see burst of losses
but loss pattern is very different.

Wes: What I found was that TCP falls over at 33% loss. UDP does eventually win
if you keep retrying.

Aaron Falk: Thanks for this work. See that satellite is still as problematic as
it was 25 years ago. If you look on high initial windows it would be good to
also look on effect that this traffic may have on low latency traffic as you
might be unresponsible to congestion events. So don't only document the
performance increase but also look at how bad you are making it for everybody
else who is sharing the network on the other side.

Nicolas: But we can pace it over long RTT. We don't send bursts. We have end
users with SLA contracts that prioritize low latency traffic with QoS
management; that will not be affected. The question is how your congestion
control will be affected by the QoS management you have underneath.

Aaron: You weren't sure about TCP optimization in your satellite link? Would be
go to understand this better.

Nicolas: Industry is doing this. Sure but it's black box measurements.

Bob Briscoe: This will also become a problem as links get faster. BDP is about
bandwidth as well as delay.

Nicolas presented some more slides on a new tool.

# Evaluating the Performance of CoAP, MQTT, and HTTP in Vehicular Scenarios
(Jaime Jimenez)

Thomas Schmidt: Which quality level in MQTT (2), but what about CaAP?

Jaime: Use confirmable messages. ACKs are not confirmable.

Thomas: MQTT and CoAP are similar with reliability layers. Will send
pointer to referenced paper.

Florin Baboescu: How much bandwidth does the 4G/LTE base station have - 5MHz,
20 MHz? Is it a single base station? Whole track is one same base station with
high signal strength for speed test as vehicle is moving? Max. number of
hardware transmission for error connection? Because the latency numbers seems
very ideal. As vehicle is moving latency will change.

Jaimes: Ural environment and only one base station. Latency did change but not
that much.

Florin: Usually 4-5 retransmission would expected which would increase latency.
Are you doing different connection or semi-persistence connections? With
persistence connection you have granted access to scheduler.

Jaimes: rasberry pie 3 and no specific modifications on scheduler or below IP
layer.

Makku ?: Work load: repeat small exchanges continuously (11 kbit). Persistent
TCP connection or new one for each message? Results indicate that you might
open new connection for each message, as performance is roughly twice - 2 RTTs
for TCP but only one RTT for Coap.

Jaimes: That you also explain why results for HTTP are not that great.

Mirja: How often did you repeat the measurement?

Jaime: ~5 times? Need to check paper.

Mirja: Provide short update next time.

Jaimes: Will have QUIC and more moving vehicles.

## The Rise of Certificate Transparency and Its Implications on the
Internet Ecosystem (Matthias Wählisch)

Mirja: Thoughts on how to improve the system?

Matthias: Apply some ML algorithms to phishing domains. Honeypots are
a fruitful direction.

Mirja: Are you still operating the honeypot?

Matthias: Not anymore.

Aaron: Are you able to get an entire copy of the CT logs? Does that seem like a
good idea...?

Matthias: Yes. I gave you some arguments why this is not a good idea. But all
servers provide the data publicly. That’s the idea of CT that an external
person can monitor the logs and find the name they need.

Aaron: But usually you would look up a name that you already have, instead of
getting a entire copy and go though it and see what useful thing you can do
with it.

Matthias: You need to scan the whole log to find certificates that are
incorrectly issued.

Aaron: Did you come upon with any recommendation for how the system might
change to become better?

Matthias: No. Privacy concerns are not new issues. We just provide the
measurement to show that this is not a theoretical concern. But did not discuss
ways to improve this. And personally I'm not a big fan to this anyway because I
think it's the wrong idea to solve this problem.

?: You need to scan to see if someone is submitting fake subdomains of your own
domain.

Matthias: That intrinsic to the system. Based on our data people can judge on
their own if this is a good idea or not.

Tommy Pauly: Thanks for sharing how many fishing domains you see under apple as
well. I'm pretty sure I'm see a half of those in text messages. Improvement
here would be lovely.

Wes: Interesting study. Have you thought about next steps to go? In particular
measuring the effectiveness of CT? Is CT helping only the big people or small
shops too? Are you able to measure whether or not users are being protected?
That type of measurement seems easy to do.

Matthias: Haven’t thought about that so far.

Dan Druta: Another solution: Owners could do the scan rather than exposing
everything.

Matthias: You are running in circles because you argue that there is a
authentication between the name owner and the log server and only the owner
should every get a name. If such mistakes never happens you would not need CT
at all. You can also have a mistake when issuing as well as between the owner
and CT logs. Not sure this helps. Same Issue.

Ulrich ?: Have you checked whether honeypots were attacks or just access?

Matthias: Low interaction honeypot; no handshake. There seems to be some
evidence of an attack, because first access and then open connection is not
illegitimate access. But there was no connection.

## Is the Web Ready for OCSP Must Staple? (Nock Sullivan)

Marsten ?: Did availability study include potential for caching?

Nick: Did two things. Feature in OCSP to do cache busting. Measured cached and
not cached. Details are in the paper.

Marsten: Can you comment on effect of the outage spike?

Nick: Cache busting version of OCSP. CDNs in front to cache would mask a lot of
this issue. That's another reason to be optimistic as these failures happens
less because of caching that is typically used.

Marsten: Still not great that they are not available.

Nick: If you scale up your web servers may also have not a cached copy. Depends
on the architecture.

?: Have you looked into environments outside the browser space? Device
certificates in particular. Most device certification completely ignore
revocation today. Would be on server side because these devices might not be
able to reach OCSP. Looked into other distribution mechanisms. Do you thin
additional distribution mechanism would help these situation where OCSP does
not work today? E.g. one proposal was to use DNS. Not as alternative for OCSP
but an additional mechanism to catch this information.

Nick: This work is mainly focused on web server. In IoT when you have
centralized servers these results do still apply. HTTP is not entirely
reliable. I tend to think that if OCSP Must Staple because tempting to deploy
it because more likely that response will invest in having more reliability as
it is not that hard. It would make sense to put it in DNS or some other
mechanism, just to have another place to obtain it depending on lifetime. Have
not thought much about revocation at client but it comes with has the same
problem depending on if they can find title somewhere. Is OCSP Must staple
ready for client certificates? I don't think so.

?: Agree.

Further discussion offline. Thanks!