Multipath TCP (MPTCP) Meeting : IETF78, Monday November 8, 2010, 15:10-16:10 Location : Beijing, Valley Ballroom A Chairs : Philip Eardley Yoshifumi Nishida AD : Lars Eggert URL : http://tools.ietf.org/wg/mptcp/ Note Taker: Andrew McGregor Costin Raicu ------------------------------------------------------------------------------------ 1: Introduction - Chairs Wenbo Zu: The linux implementation was done or ongoing? Costin: Ongoing Tim Shepard: What the interoperability matrix will look like? Costin: When I wrote the userland, it was written to a very early spec, Linux one is much more recent. No intention of supporting userland. ------------------------------------------------------------------------------------ 2: Updates for protocol and Open Issues - Alan Ford Tim Shepard: I don't see how the offload engine helps on transmit. Alan: You can often get to the checksum after offload has calculated it. Scott Brim: How do you specify the crypt function? Upgrade it? Alan: Aware of that issue, we will address it. Yoshifumi: Does it have to be in the payload? Alan: That gives it reliability Yoshifumi: If it's not in the payload, we can retransmit on another connection Alan: Yes, but it is linked to the subflow Costin: The perceived problems are that you have a 4 way handshake, and you do it in the payload, and going in options you can just reduce the handshake strength. If you make this asymmetric, you can remove some of the return data (particular A's token). Alan: If we have middleboxes that wish to correlate multiple flows, they may need the tokens to do that Lars: May want to ask security area for help here Tim: Along those lines, why are you doing any crypt with the keys in the clear at the beginning? That will have to be explained to the security people. Randall Stewart: This is very similar to the auth mechanism in SCTP, which needed a shared secret. Tim: subflow success is unknown... we can never know the number of fully-open subflows without signalling it. Costin: we're trying to force the attacker to be on-path for the main connection, attackers who are only on a flows should not be able to insert flows or data. Is this suitable? Tony Lee: Not convinced you should be solving the MITM attack at all. So option 1 with the nonces is just fine. Lars: SAAG is thursday afternoon, with a light agenda, could perhaps put this in. Yoshifumi: Is syncookie needed in the subflow setup? Alan: You know the token, that counts. Lars: experimental protocol, so maybe we don't want to spend time on lightweight protocol features. Maybe save that for later. Andrew McGregor: Anyone suggesting turning off checksums in data centers should first look up the BER on 10GbE. ------------------------------------------------------------------------------------ 3: Updates on architectures draft - Alan Ford: Adoption for WGLC Support - around 7 Not support - 0 4: Updates on API draft - Alan Ford: Costin: Need to be able to add subflows to use ECMP Stuart Cheshire: These look reminiscent of socket options, do you expect applications to change to support this? Alan: If they care about a great deal of detail, yes. But you could enable it by default. ???: Designating a path as a backup path would therefore be a system-wide option, and never an API option? Alan: Yes ???: It would be as well to be able to say that "This communication is cost-insensitive" Alan: It's a bit dangerous to do this... user control is perhaps better Costin: I've spoken to people who had as an idea that you can send redundantly over multiple paths. Say you have plenty of bandwidth, but not reliability. Tim: Somebody has to be in control, and system-wide basis may not be the right thing. Say, your backup app should not be allowed to use backup path. This is complicated, but probably should not be solved here. But then, where? Stuart: My advice would be to briefly list the controls that might be useful, and not go beyond that. It can be implemented system wide, by firewall config, or by API access, but all of this is implementation detail, not on-the-wire. Andrew: +1 Stuart Andrew: What do you do with a TCP_MULTIPATH_BIND that specifies addresses that no longer exist? Alan: good point Yuri: Good not to prevent an app keeping an address list. Dave Thaler: Is this too abstract or too concrete? Discussion has been abstract, which is great. However, I think this is repeating an old mistake, because socket options are not type-safe in C. So it's important to keep the concrete APIs reviewed elsewhere. In 3678, we did something with source address lists, and we had the same question, is it reasonable to expect the app to maintain such a list, and the discussion ended up giving a basic API (add, delete), and an advanced API (specific list). Dave: Not ready for WG adoption because needs abstraction, but easily can be done quickly. Needs to lose the things that Austin Group/posix would not standardize. ------------------------------------------------------------------------------------ Meeting : IETF78, Wednesday November 10, 2010, 15:10-16:10 Location : Beijing, Valley Ballroom C Chairs : Philip Eardley Yoshifumi Nishida AD : Lars Eggert URL : http://tools.ietf.org/wg/mptcp/ Note Taker: Andrew McGregor ------------------------------------------------------------------------------------ 1: Small updates - Chairs Adoption for API if we omit setsockopt: Support - around 10 Not Support - Zero Andrew McGregor will attempt to review the protocol document Christian Gotare volunteered for review of API document ------------------------------------------------------------------------------------ 2: Threat Analysis Update - Marcelo Bagnulo Tim Shepard: The default should be to exchange a key in the establishment of the first subflow. Most people would understand that in a security context. Option space precludes the use of a key derivation mechanism, and so the keys are supposed to be exchanged in the clear. Most people would not expect a clear text exchange. Illisch: Why not DH? Tim: Because there's no room for that in option space. Marcelo: That doesn't buy you much. You still get replay attacks and more, unless you use a PKI or something to give authentication. Steve Bauer: DH doesn't require PKI. Marcelo: You can MITM the DH, though, so on its own that does not buy you so much. Replay attacks etc are still possible. Tim: If you do DH, though, you can do a channel binding later. Marcelo: Yes, DH is in fact better. However, the past agreement is that DH and so forth are not worth the extra complexity. Costin: The goal is only to be no less secure than plan TCP, and we believe we've done that. Call for Adoption: Support - around 10 Not support - 0 ------------------------------------------------------------------------------------ 2: Middlebox Survey - Michio Honda Costin: We knew that middleboxes are likely to be a problem. So we should retransmit data on a subflow until it is acked, and not add new data to that subflow until we get an ack. Inefficient, but all we can do. ------------------------------------------------------------------------------------ 3: Congestion control in data centres - Costin Raicu Andrew McGregor: Don't even think about turning checksums off; the BER implies errors every couple of minutes on 10GbE. Murari: The data center is very homogeneous, if you did per packet splitting, that implies the congestion is uniformly distributed. Timeouts in the DC are quite small. Maybe we can do something simpler than multipath. Costin: You build them homogeneous, but they become heterogeneous over their lifetime. Murari: If you believe MPTCP can move the capacity off poor links, so can other techniques.