IRTF Open Meeting @ IETF-89 London, UK WEDNESDAY, March 5, 2014 0900-1130 Morning Session I ------------------------------------------------------------------------ State of the IRTF Lars Eggert 5+5 min Lars presents introductory presentation, agenda bashing, etc. State of the IRTF 7 RGs meeting and one proposed RG meeting On the CFRG chair issue Ran Atkinson: With respect to the summary of Trevor Perrin's argument, we should characterise these statements as claims, or allegations - there were other positive comments on Dragonfly for example. These claims aren't necessarily completely true. Lars: Yes - this slide is an attempt to summarise the two e-mails that were sent. Ran: Claims are not the same as facts. Lars: Correct. ------------------------------------------------------------------------ Applied Networking Prize (ANRP) Award Talks 30+10 min (x2) *** Kenny Paterson *** on finding and documenting new attacks against TLS and DTLS: N. J. Al Fardan and K. G. Paterson. Lucky Thirteen: Breaking the TLS and DTLS Record Protocols. Proc. IEEE Symposium on Security and Privacy, pp. 526-540, San Francisco, CA, USA, May 2013. Jon Crowcroft: How do we get better choices to build security? Paterson: If you use gcc -w all it doesn't tell you about dead code, so there's clearly more work to do. INRIA have been doing a lot of good work on language-based security using typing. Ran Atkinson: ARe you saying that pad length is related to pad values? Paterson: Yes. RA: So you have predictable plain text? KP: Yes. RA: And that's the problem? KP: No. Rich Salt: What's the encode part on the slide? KP: Concatenation of the fields mike ? - ex-chair of maawg - consider using maawg as a way to coordinate disclosure of this kind of thing Dave Oran: GCM is itself difficult, or embedding in TLS? KP: That's straightforward, there's an interface in TLS1.2 Dave: Hopefully there's only a small number of highly scrutinised implementations Crowcroft: Some possible further discussion topics - would be great to have generic advice on what to put in security considerations relating to timing attacks. Also, responsible disclosure processes would be good to develop - preventing researchers from getting sued would be good. Sharing disclosure experience would be good. Ran Atkinson: What about server-side software getting fixed? KP: As far as I know microsoft servers are patched, I believe OpenSSL is patched - honestly I don't know the exact numbers. It takes time for these patches to roll out - legacy is the curse of security. ?: I'm from Comcast - we have techfund to support academic research - check us out, 7 figure sums to hand out. ------------------------------------------------------------------------ *** Keith Winstein *** on designing a transport protocol for interactive applications that desire high throughput and low delay: Keith Winstein, Anirudh Sivaraman, and Hari Balakrishnan Stochastic Forecasts Achieve High Throughput and Low Delay over Cellular Networks. Proc. 10th USENIX Symposium on Networked Systems Design and Implementation (NSDI), Lombard, IL, USA, April 2013. Keith will talk about our work building Sprout, a transport protocol for interactive traffic over cellular networks, and Remy, a tool that generates congestion-control protocols automatically. Crowcroft: At an instant the choice might be send multiple packets due to power saving etc. KW: Yes Jana Iyengar: What happens when Sprout competes with a Cubic flow KW: It's catastrophic - it's not possible Dave Taht: Your work is great. Sprout's goals appear to be get under 100ms of delay - have you looked at getting down to 2ms of delay KW: No, that sounds hard. DT: It is. What are you wokring on now? KW: Let's talk offline, but see cellshell. Crowcroft: This is great work. You have multiple parameters, the problem I have is that operators may find it difficult to stomach the idea of something that isn't explanatory. How can we address lack of rationalisation of what's going on, or should we ignore telco bellheads? KW: You're right it is scary to deploy evolved code. Aircraft design code is used to design aerofoil and engine. It would be nice to understand this better. The theorists don't I think know how to solve these problems. Bob Briscoe: Cool stuff, thankyou for doing it. On the question of what the mission is - for realtime media - we did some experiments back in 2001, replicated since, we gave people money and asked them to spend it on different types of variation of media quality to see whether people would prefer smooth media or faster on average or more variable. Definite preference for low average if you could make it smoother - trying to find results to share. This may be why Skype etc are lower on throughput. Temporary throughput may not actually be appreciated by end user. KW: I think you're right. A real video coder would be more tentative about increasing rate for fear of having to reduce later. Increases should be slow, but slow decreases are folly. BB: As long as delay objective is paramount you'll achieve that. Did you have any smoothing? KW: No. Tim Sheppard: When you say 'net' you're really talking about your dumbbell topology which is a single link. We don't understand why Remy is better, would using this on something as big as the Internet be a good idea - do you have any intuition. KW: I don't advocate for the use of RemyCC on the Internet. You raise good questions. We as a community should develop a suite of benchmark network topologies that people care about. It is possible to reason about these algorithms, but I don't have a very good story yet. If you tell Remy that the link only has one hop and it actually has two hops we can answer those sorts of questions. But maybe going from one to thirty is worth it. These are the right things to talk about.