IRTF Open Meeting @ IETF-96 Berlin, Germany Wednesday, July 20, 2016 (CEST) 15:50-17:20 Wednesday Afternoon session II State of the IRTF Lars Eggert 10 min Applied Networking Research Prize (ANRP) Award Talks 2x 40 min *** Dario Rossi *** for characterizing anycast adoption and deployment in the IPv4 Internet: Danilo Cicalese, Jordan Augé, Diana Joumblatt, Timur Friedman and Dario Rossi. Characterizing IPv4 Anycast Adoption and Deployment. Proc. ACM CoNEXT, Heidelberg, Germany, December 2015. Giovane Moura - You use ICMP to probe - ICMP very often put in low priority queues - so how do you handle that? DR - shows slide indicating distribution of latency - most things we see are in a space that brings you to the size of a continent - Don't need to mention bufferbloat. The circles that are useful are really small. We use a threshold and discard the excess. This is sort of the same in a mirror fashion. You are asking about discs that are very large because they are queued or incur high latency. Packets that incur high latency are factored out in the solution to the problem. The solution takes discs that are short and even if you start thresholding even discs that are very large, then you don't care because in the greedy solution you are going to solve this by increasing size and most useful discs are going to be the smaller. You rely on the existence of this lucky guy that has a privileged path to the replica. Those guys are the ones that you want to select as a result of the optimisation problem. So the others are just the overhead that you incur because you need to do those measurements. The solution of the algorithm will throw them away. Zhen Cao - Using ICMP to measure latency could be impacted by bufferbloat issues. DR - The dataset from infocom paper, extended jsac paper that exports different protocols. The census was only done with ICMP because it is more lightweight, but we have other work where we use a variety of protocols for measurements DNS HTTP - one of the reasons why planetlab is interesting - different protocols will result in different latency measurements - this is not related to bufferbloat which is mostly found in the access network - if using ICMP you're going to get 3 times median latency with respect to the speed of light - TCP and UDP have slightly different figures - hotnet paper 'internet at speed of light' - the nearby hosts will help increase accuracy with regards to location of replica - couple this with the fact that you are not selecting at random but picking largest cities, you basically factor out problem of huge latency noise. You just use latency as a hint and then you move to other things. Giovane Moura - this is all for IPv4 - could you use reverse DNS against the IPv4 records you found and get AAAA records to permit you to analyse IPv6? DR - software is v6 ready - but no v6 census - we have tried the approach you suggest using reverse DNS and looking for AAAA records, there are not so many v6-capable alexa ranked services - it's not easy to do it automatically right now - scaling for census is different - right now there are presentations about is everybody reachable with ipv6? adds another layer of complexity - failure modes are more complicated - but this could be interesting in future *** Samuel Jero *** for a security analysis of the QUIC protocol: Robert Lychev, Samuel Jero, Alexandra Boldyreva and Cristina Nita-Rotaru. How Secure and Quick is QUIC? Provable Security and Performance Analyses. Proc. IEEE Symposium on Security and Privacy, pp. 214–231, San Jose, CA, USA, May 2015. Dave Plonka: I read your paper before this, your presentation helped me to understand the paper better. You didn't mention SNI in the paper - past IETF work to try to encrypt SNI - I'm wondering if you can send SNI encrypted under subsequent sessions because you have this 0-RTT encrypted context... SJ: That's true but logically part of that server config is ssl certs and verification - so you still need that prior to setting up encryption keys DP: I think i understand that. This afternoon in tcpinc i'm going to propose a way to omit SNI when we don't need it. Maybe you have a unique IPv6 address for each service. How could we improve from quic or use techniques from it to encrypt or obscure SNI? SJ: QUIC sends SNI in cleartext - abstracted out of the security analyses part of this work - not sure I have any suggestions. DP: is it out of scope because it's more of a privacy concern rather than a security concern? SJ: Yes, it was completely abstracted out of the security analysis we performed. Stuart Cheshire: I was going to ask if TLS includes TLS1.3 and then you talked about that. Of the vulnerabilities you found, which ones are flaws in quic specifically that TLS1.3 doesn't have, which are just inherent in 0-RTT protocols? it would be interesting to know if there are things that could be fixed in quic. Performing security analyses of TLS1.3 before final is exactly the right thing to do, before the RFC is published and not afterwards. SJ: Absolutely. Most of the described attacks are going to affect all types of 0-RTT protocols. By caching that information you're giving it to the attacker to do these kind of replays against. TLS1.3 could explore some other way to prevent IP spoofing - in a number of these attacks that source address token that QUIC uses provides leverage in many cases. Even in the stk replay attack, there is some protection against IP spoofing, but it's not complete. Lars Eggert: Are there any other questions about anything IRTF related? Lars Eggert: We're going to start the call for nominations of the 2017 cycle of ANRP soon. If you go to conferences and see papers as good as or better than those that have been presented today, please nominate them or encourage the authors to self-nominate. If you're an author, nominate your work. Meeting adjourned.