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!