TSVAREA IETF 81 Quebec City July, 2011 =============== TSV Area Status David Harrington & Wesley Eddy 15 minutes IETF P2P Toolset and TSV Role Wes Eddy, David Bryan, Rich Woundy 40 minutes Jim Gettys: Upstream bandwidth becomes the bottleneck on downstream performance in IPv6 (because the acks are larger) Michael Richardson: It would be interesting to know what the bandwidth at last mile and bandwidth out of ISP increase was, to know if 15% to 18% increase was a huge increase of traffic, or not much because the network didn't grow Rich: The year-to-year growth of traffic, particularly downstream, is around 50% Michael: So each year, the network grew by 50% Rich: Exactly, so that increase is pretty spectacular x: Is it legal to do content caching? Rich: If the data was legal, sure Bob B: The way LEDBAT works it sorts out the sharing in the queue in the upstream of your home router, but it wouldn't yield to others in the CMTS queue. Rich: If you look at a cable modem, it has its own queue, and the primary reason it fills up is too much upstream traffic vs provisioned bandwidth, but there are places upstream where congestion may cause further harm. Bob: I was using the CMTS as the slowest example of something shared in the network. Rich: If the customer is stepping on their own toes, and LEDBAT helps, they call me less. And if it helps overall, great, but that's a bonus. Stuart Cheshire: I'm seeing this as jumping on a trendy bandwagon, and lots of this stuff is not specific to p2p. For example, nat traversal is not really specific to p2p. LEDBAT is not p2p specific either. We have talked at Apple about using LEDBAT flow control for software updates, although I don't know if we did it. If there's a cloud of 1k machines out there with bits of the content, you've stepped outside client-server, and that is p2p. Chair: We moved storage and p2p into transport because they have significant transport impact, although we are still sorting out the transport bits from the rest. Bhumip Khasnabish: It would be interesting to know where the growth numbers come from Rich: These are pretty much budgetary estimates for equipment costs, and the growth estimates come from own data plus studies from 2009/10. Growth mostly comes over the holidays when people buy lots of new devices. Bhumip Khasnabish: What's a commodity server? Rich: A 1u or 2u server from any regular system supplier Alan Morton: Caching, path localisation, really great. What about layer 8? I just got a screener copy of Transformers... what about the risk? You have to pay to maybe get burned. Rich: Well, there's legal risk, but that's not an IETF matter. The costs matter... well p2p is a complete wildcard, and could really change things. TCP-minion: A network-compatible substrate for new transport services Janardhan Iyengar 25 minutes http://arxiv.org/pdf/1103.0463v1 http://dedis.cs.yale.edu/2009/tng/papers/pfldnet10.pdf (at slide describing priority queueing in sender socket buffer) Eric: How does this react to transparent proxies? Jana: It works. Eric: But the proxy terminates the TCP... Stuart: The proxy reduces the benefit. Eric: Interesting to compare people behind transparent proxy to people who can't hole-punch UDP Jana: Could deploy at the proxy also. TCP in presence of proxies is not end-to-end, entirely. (pointed offline) Matthew: The 2nd to last slide refers to the cycle of non-deployment, there's a whole bunch of cases where you want to deploy a transport without changing the kernel. Jana: Because it doesn't change the wire protocol, you can do minion at ONE end if that suits your application. tcpcrypt Mark Handley 40 minutes http://tools.ietf.org/html/draft-bittau-tcp-crypt-00 (mutual auth slide) Ekr: People using https have four mechanisms for doing this and don't use any of them. Mark: This is often about the browser UI, however, this isn't about the web only. Ekr: It seems a bit odd that this hasn't been deployed in existing forms. Chair: Let's move this along... Matthew: Can you comment on the lack of perfect forward secrecy? Mark: The forward secrecy is bounded by how often you regenerate the public key, the degree is up to how often you expire your keys. Tim: Same as ssh? Mark: Don't know (but affirmative noises from the back of the room) (slide showing handshake) Michael Richardson: The crypt hello in the syn is not generally necessary, and I suggest you get rid of it, because we know syns with unknown options tend to be dropped Mark: Michio has done some work on data (local end only, home gateways etc) Michael: Firewalls out there frequently do this, at the far end. So just don't say hello Mark: There will be options later though Michael: But if you don't go crypto, you don't do those, so you get backward compatibility David: I want to support the notion that MAC-ing the window is going to lose, because many PEPs fiddle with it. Also +1 to Michael's suggestion about taking the SYN option off. You get burned by sending an unknown option on a random path and the firewall drops Bob: Someone who is supporting this will have fixed their firewall (performance slides) Michael Richardson: Can you think why this shouldn't replace TCP MD5 for BGP? Mark: TCP MD5 is authentication within TCP, this is auth OVER TCP, which is a bit different. Richard Barnes: We already have TCP AO Mark: Yes, which is probably better for BGP (end) David McGrew: There's some interesting ideas, but I don't understand why there is a focus in inserting this into the TCP layer. I'm also concerned by some of the claimed benefits, because they depend on the properties of particular algorithms involved with full crypto agility. For example, there's a claim of forward security, but key generation is really expensive. Cert chains have proven to be the best way to authenticate two strangers on the internet... (lots of noise) David: If the TCP layer is the best place to have a graceful fallback, why not just use that to do discovery, and do the crypto somewhere else Mark: Well, it would have to be under the socket, but if it is over TCP you'll have to reinvent TCPs reliability mechanisms Matthew: How do you protect against a downgrade attack? Mark: So obviously, there are downgrade attacks Matthew: So, there's a way for someone outside a company to downgrade all the connections through the firewall? Mark: there's a protocol coming to prevent that Ekr: I have some reservations about the performance claims. You require 2RTT to start. TLS you are thinking takes 2RTT, but if you're confident you like the ciphers, you can just start. Google turned on https on gmail, and the performance impact was around 1%. If you go to a hosting provider, they charge for IP addresses and certificates, which are the same things that are expensive in tcpcrypt. These performance issues haven't been an issue for several years. Richard Barnes: Bump in the wire can also transparently decrypt, which could be a problem if apps assume they can do tcpcrypt Mark: We have a library that will make sure the channel exists, by falling back to TLS as required Richard Barnes: If you really want an authenticated channel, you stop saving. There's lots of ways of doing opportunistic security already, what Dave said is there's lots of interesting crypto optimisations Mark: They don't seem to be deployed Jeff Hodges: We like opportunistic encryption and would like to see it more deployed, so we'd like to support investigations here. points out that there are other issues with deployment (mashed up web apps), mentions adam langley's use of opportunistic crypto (different approach to saving an RTT) Yes, there's an issue around false sense of security, but nevertheless this stands to help McGrew: If we're concerned about passive eavesdropping, well, we'll just see more active attacks. firesheep++ does matthew's downgrade. Mark: Indeed. Please contact me if you think this is a good way to go Policies Migration in Virtualized Data Center Yingjie Gu 20 minutes http://tools.ietf.org/id/draft-gu-opsawg-policies-migration-00.txt http://tools.ietf.org/id/draft-gu-opsawg-policies-migration-solution-survey-00.txt http://tools.ietf.org/id/draft-wang-opsawg-policies-migration-gap-analysis-00.txt Bob: We're finding that there are lots of relevant issues to do with doing things in a timely manner within transport. It's not so much a protocol issue as an implementation issue Andrew: Is FORCES relevant here? Yingjie: Yes, we do think so David Black (not speaking for vmware): You have one suggestion on your time flow slide. The white section in the middle is the time critical part, because that has to be done while the VM is not running. So I think you want to look at doing the capability check before the critical section, so you can fail without shutting down. Take the top piece, decouple it, and use the go-notification to immediately start moving things, so you're not on the critical path Yingjie: Yes, I did have the pre-migration stage, it has been ommitted here for simplicity. There should a connection between the VM manager and the coordinator to say that only some state has been migrated and we can't start. David: I usually hand out fines for 'simple matters of programming'... you're talking about changing the VM manager into a 2-phase commit, that's going to take a lot of work Accurate ECN feedback in TCP Mirja Kuehlewind (no questions)