Date: Tuesday Nov 6, 16:10-18:10 (Afternoon session II)
Room: Chitlada 1
Mirja Kühlewind
10 min
Tobias Fiebig
5 mins
Tom Jones
10 mins
Nicolas Kuhn
15 min
Jaime Jimenez
20 min
Matthias Wählisch
20 min
Nick Sullivan
20 min
A Tale of Two Checksums (Gorry Fairhurst, Tom Jones, Raffaele Zullo (University of Aberdeen))
draft-ietf-tsvwg-udp-options proposes adding options to UDP in the same way that TCP provides options. UDP Options are carried in the space beyond the end of the UDP Datagram unto the IP Payload length. This extra space carries TLV-formatted transport options.
In TSVWG at IETF-101 we presented a single slide showing a UDP checksum bug in the FreeBSD UDP output code. We fixed that bug upstream and thought that was the end of checksum issues! Little did we know the trials we were to face in implementing and testing UDP Options. We started measuring whether Internet paths transparently support UDP Options datagrams and were met by a whole mess of issues, one was the innocuously little checksum bug that we fixed in FreeBSD. There are still opportunities to miscalculate the checksum, causing datagrams to fail to reach the remote endpoint.
So, we asked, “What would happen if the options space itself carried a value that magically improved ability to work across the Internet?” We found such a value in what we call the checksum compensation option (CCO). An endpoint that receives a UDP-Options datagram containing a CCO, can compute a valid UDP checksum using either the UDP Length, or the length deduced from the IP header information. The CCO not only dramatically improves the chance of successful transmission, and the same checksum also protects the integrity of the UDP options space.
Our presentation will take a fast trip through this story, using measurement data from paths to 400K IPv4 addresses (17K ASes) and 30K IPv6 addresses (200 ASes) to assess the range of pathologies that result, and whether the CCO improves the probability of successful use of UDP Options. The targets list included 200K authoritative DNS servers and 100K HTTP servers from the Top-1m Alexa and about 70K STUN servers from a full IPv4 range scan.
Refs:
draft-ietf-tsvwg-udp-options
draft-fairhurst-cco (to be submitted before IETF-103)
QUIC performance over a satellite public Internet access (Nicolas Kuhn)
Paper: https://arxiv.org/abs/1810.04970We analyze QUIC transport protocol behavior over a satellite communication system. Such systems usually split end-to-end protocols to improve end users’ quality of experience while fully encrypted QUIC might jeopardize this solution. Using a real satellite public access, we observe that heavy page load time is approximately twice longer with QUIC than with TLS over TCP. Although faster, QUIC connection establishment does not compensate an inappropriate congestion control.
Evaluating the Performance of CoAP, MQTT, and HTTP in Vehicular Scenarios (Roberto Morabito, Jaime Jimenez)
In this work, we conducted an extensive empirical analysis—through the set up of a testbed—with the attempt to shed the light on the suitability of different application layer protocols in vehicular scenarios. Specifically, by focusing only on the transmission of small-sized messages—i.e. with payload comparable to the one produced by the Vehicle's sensors—, we evaluated the performance in terms of throughput and latency of HTTP, CoAP, and MQTT, by also taking into account additional factors, including the impact of vehicle’s speed as well as scalability. Finally, we provided further insights on the potential benefits that an edge-based service provisioning can enable compared to a centralized cloud-based approach.
The Rise of Certificate Transparency and Its Implications on the Internet Ecosystem (Quirin Scheitle, Oliver Gasser, Theodor Nolte, Johanna Amann, Lexi Brent, Georg Carle, Ralph Holz, Thomas C. Schmidt, Matthias Wählisch)
Paper: https://arxiv.org/abs/1809.08325In this paper, we analyze the evolution of Certificate Transparency (CT) over time and explore the implications of exposing certificate DNS names from the perspective of security and privacy. We find that certificates in CT logs have seen exponential growth. Website support for CT has also constantly increased, with now 33% of established connections supporting CT. With the increasing deployment of CT, there are also concerns of information leakage due to all certificates being visible in CT logs. To understand this threat, we introduce a CT honeypot and show that data from CT logs is being used to identify targets for scanning campaigns only minutes after certificate issuance. We present and evaluate a methodology to learn and validate new subdomains from the vast number of domains extracted from CT logged certificates.
Is the Web Ready for OCSP Must Staple?
(Taejoong Chung and Jay Lok (Northeastern University), Balakrishnan Chandrasekaran (Max-Planck-Institut für Informatik), David Choffnes (Northeastern University), Dave Levin (University of Maryland), Bruce Maggs (Duke University and Akamai Technologies), Alan Mislove (Northeastern University), John Rula (Akamai Technologies), Nick Sullivan (Cloudflare), Christo Wilson (Northeastern University))
TLS, the de facto cryptographic protocol for securing communications in the Internet, relies on a hierarchy of certificates that bind names to public keys. Naturally, ensuring that the communicating parties are using only valid certificates is fundamental to benefit from the security of TLS. To this end, most certificates and clients support OCSP, a protocol for querying a certificate’s revocation status and confirm that it is still valid. Unfortunately, however, OCSP has been criticized for its slow performance, unreliability, soft-failures, and privacy issues. To address these issues, the OCSP Must-Staple certificate extension was introduced, which requires web servers to provide OCSP responses to clients during the TLS handshake, making revocation checks free for clients. Whether all of the players in the web’s PKI are ready to support OCSP Must-Staple, however, remains still an open question. In this paper, we take a broad look at the web’s PKI and determine if all components involved—namely, certificate authorities, web server administrators, and web browsers— are ready to support OCSP Must-Staple. We find that each component does not yet fully support OCSP Must-Staple: OCSP responders are still not fully reliable, and most major web browsers and web server implementations do not fully support OCSP Must-Staple. On the bright side, only a few players need to do something to make it possible for web admins to switch. Thus, we believe a much wider deployment of OCSP Must-Staple is an achievable goal.
In: Proc. of ACM Internet Measurement Conference (IMC), New York: ACM, 2018. accepted for publication