Multipath TCP (MPTCP) Meeting : IETF89, Monday March 3, 2014, 13:00-15:00 Location : London, Balmoral Chairs : Philip Eardley Yoshifumi Nishida (absent) AD : Martin Stiemerling URL : http://tools.ietf.org/wg/mptcp/ Note Taker: Mirja Kuehlewindn, Simone Ferlin-Oliveira --------------------------------------------------------------------------- 1: Chair Slide Phii: We've seen lots of deployments these days Olivier will coordinate the operational document. This will be important document as we will need this to publish core spec draft as a standard RFC. --------------------------------------------------------------------------- 2: MPTCP residual threats - by Chair Phil: We are thinking about running WGLC now. If there's any objection or suggestion for this, let us know. This will be companion documents for RF6824bis draft. --------------------------------------------------------------------------- 3: 6824bis updates - Alan Ford Phil: The document is basically stable and waiting for the operational experience document to be done. --------------------------------------------------------------------------- 4: MPTCP Proxy for Mobile Networks - Lingli Deng Sri Gundavelli How does this work with 3GPP release 12? If you've done WLAN EPS integration, from the UE you still see multiple paths? Lingli: In case of MPTCP, we can deliver IP level, more general solution. Sri: In case of NSWO connections, it will never hit your proxy. I'm not very sure how it works here, but we can discuss on the list. Keith Morgan: I'm worry about the proxy that is interpreting content that is intended for the endpoint. MPTCP already has been struggling with middleboxes which try to impersonate endpoint. Will this proxy interfere with mptcp capable endpoints? Lingli: We are considering operator driven use case only, but might be beneficial to also consider Internet-wide use case, e.g. proxy of ingress of data center. Keith: It might be an issue when you have an endpoint which is fighting for network who manage the resource. Not saying that a proxy is a bad idea and clearly, there is a valid use case, but there might be an architectural issue. You might need to find a way two things co-exist. Lingli: We have been doing trial and will soon deploy split TCP proxies (without MPTCP) over 2G/3G network at Gi interface, which bring over 20% performance gains. It might be appealing to following the same architecture framework by upgrading these split TCP proxy with MPTCP capabilities, if possible. Keith: Not surprised about this result but the impact on e2e mptcp is not clear. iesg might be looking at this Steve Kent: My interpretation with this is if we use mptcp with TLS, this will be fine. But, in case of tcpcrypt would not be. Is this correct? Lingli: I'm not familiar with tcpcrypt. Will get back to this office. Konda (from Cisco): What's about using home network with wifi? how does this traffic go to the proxy? Lingli: Explicit entry mechanism requirement. Service discovery for 3GPP to get MPTCP proxy and first subflow can tell others (Out-of-band signaling) Alan: This is trying to apply many different access method forced to go to one location, which might negate many benefits uncomfortable with this Phil: Are you working on experiments? Lingli: Yes, did implementation but not the anchoring capability, but issue with mobile terminal/anroid system and performance issues with transition when dropping down of mobile links Costin: There are proxies already today, don't think this proposal is broken, but need to define cases e.g. if endsystem is mptcp-capable. there are mechanism in the protocol to make proxies visible to the endsystem. I'm not sure it is very efficient way. But, this is unavoidable, so let's do it right Keith: This still can go wrong, it breaks e2e. Olivier: It can also be a proxy on the end-device, then it doesn't need to be an implicit proxy Keith: If it's implemented on the end-device, how is this different to implementing mptcp in the stack? 5: Wifi Mobility without Fast Handover - Costin Raiciu --------------------------------------------------------------------------- ?? (from cisco): Did you also try mobile enhancements related to 802.11v and 11w? Costin: No. We've just tested with Linux. Goal for this is mobility for uncontrolable areas like using different types of providers in city-wide area. Mirja: Connecting one AP might be better? Costin: normal TCP is always lower than UDP. --------------------------------------------------------------------------- 6: The Status of MPTCP Deployment and Evaluation in the NorNet Testbed - Thomas Dreibholz --------------------------------------------------------------------------- 7: Generic control stream for Multipath TCP - Christoph Paasch Alex Zimmermann: This also extends option space for SYNs possible? Christoph: No. Because we still need DSS option (16 byte) Alex: This has been discussed in tcpm but proposals only to solves problem after handshake Christoph: Is there a draft? Alex: There is a propsal from Microsoft Christoph: We'll check later Mark Handley: You should be careful about extensibility because people might use it. Once you have two sequence spaces, you might go in direction of TCP minion. You will have multiple logical flows over one tcp connection. Christoph: It might be interesting to do real multiplexing over mptcp. Mark: If you go the direction, you'll need to think about how far you want to go. Mirja: It sounds like a generic approach to extend option space. This may not be a right WG to propose this. --------------------------------------------------------------------------- 8. Secure MPTCP - Marcelo Bagnulo Steve Kent: I'm going to suggest you don't have to have that big MAC. But, I'm still worry we could still get out of space under some conditions. TLS just works on top. Only during the initial phase in TLS additional information needed, But joining later gets you an nice encrypted stream. Choice is not only between plain text and this proposal but between plain text, this and TLS. It's not a clear choice to me. You did good job to show increased vulnerability of mptcp, But, tcpcrypt option could easily just be chopped out by middlebox/attacker. Marcelo: What about all people who don't use TLS? They have to reduce security if using MPTCP. Steve: Your propose to mandate this with the use of MPTCP? Because that only solution to this? Marcelo: Yes. If this is deployed, you can specify you only accept MPTCPcrypt connection. That's the only way you can deal with this attack. It's matter of local policy and how widely this will be deployed. David Mazieres: I think We can have an hook in tcpcrypt to use other keys. My question is if we can use a bit in flag to get extract key from tcpcrypt. Marcelo: Yes. If you want to use tcpcrypt to secure mptcp, you can use a bit to indicate it. Alan: Can we re-use 64bit DSN? David: Most significant 32bit is implicit. But, checksum may fail --------------------------------------------------------------------------- 9: Multipath TCP security building on SSL - Christoph Paasch Steve: As long as mptcp is implemented inside kernel, there won't be significant security issues for exporting/importing keys. However, if it's implmeneted in appl level, that would be concern. Christoph: We might be able to do hmac calculation in app layer. Steve: That's really questionable from security perspective. You can't be sure what will be done when handing it in user space. ? (from Akamai): A concern for using key in appl is it might limit how mptcp can be used. If this will be used for roll-out strategies similar to IPv6, appl key might be problematic. Christoph: Yes, It would not work over proxy Keith: Using app layer key in transport needs further study. I'm suspicious Steve: I didn't mean to be too negative. You might want to look at VoIP security approach using dtls with rtsp, which is perfectly reasonable. Christoph: We will check this. Phil: Is there any thought on which one is promising or seeing all of them? Keith: We'll need analysis to make decision Costin: Once you have an encrypted payload the security problem with MPTCP becomes much smaller. I don't care about security in control info as long as payload is secure. The question is what are middlesboxes allowed to. I'm fine with them to re-route my packets as long as they can read them keith: Traffic analysis is often attacker's goal. Let's not discard the concern so lightly. Marcelo: tcpcrypt integration does not makes sense for WG to make any decision at this stage. It really depends on tcpcrypt. Tcpcrypt need to be standardized first and we need to figure out what to do as soon as tcpcrypt gets more stable David: As a co-author of tcpcrypt, we've received a lot of feedback. Hardest push back was middlebox that might strip TCP options on port 80, which will be applied to mptcp as well. Costin: For mptcp, it won't be as bad. if we have multiple subflows and one subflow is modifed, we can catch that and use other flows, or if there's no subflow, we fall back to tcp David: We do fallback, too. but if middlebox doesn't set reset it takes 6 secs which makes people freak out Costin: In MPTCP, if you don't have subflow, then the data has to be http. because we don't change at all. Jon Crowcroft: We are building block here and tcpcrypt is a nice option and multi-streaming stuff. Please come to TAPS BoF because this is a general function. I like multi-streaming in general which is also in minions. I like choosing better one than existing security mechanism. Keith: mptcp-aware middleboxes have to be regarded as a threat. It can't interfere the use of the protocol. We need to find a way that two mptcp (with and without proxy) could co-exist, although there is a conflict or a tussle. Sooner to solve is better. Jana Iyengar: Middleboxes is absolutely going to be there. So, there are two directions possible here: 1) bring them in the conversation and 2) detect them and route around it, therefore tcpcrypt MAC is useful. Detect things that we don't want to happen is an important thing