Multipath TCP (MPTCP) Meeting : IETF98, Thursday March 30, 2017, 15:20-18:40 Location : Zurich C Chairs : Philip Eardley Yoshifumi Nishida AD : Mirja Kühlewind URL : http://tools.ietf.org/wg/mptcp/ Note Taker: Rolf Winter, Christoph Paasch ------------------------------------------------------------------- 1: WG Updates - Chairs Christoph: Linux implementation progressing. Some outstanding features left like MPTCP RST. ------------------------------------------------------------------- 2: 6842bis update - Alan Ford Alan: question to the group: anything else to add? Olivier: there will be something in my presentation. ------------------------------------------------------------------- 3: Securing MultiPath TCP - Olivier Bonaventure Juliusz Chroboczek: Why not deal with this in TLS? Olivier: TLS is designed for TCP and has no notion of subflows. It cannot retransmit data that was acked in TCP level. You'll need to extend TLS if you do it. Alan: Are there changes to the wire to support this? How do you retransmit? Olivier: Don't ack in MPTCP level when it receives invalid data Mirja: seems like reinventing the wheel Olivier: This is different to fast open. You cannot simply use fast open for this. Costin: If the attacker have messed up the first path, users cannot use other subflows because shared keys cannot be exchanged. Phil: summary: worthwhile to write up and given that is should go into this bis document, it should be soon (way before Prague) Mirja: Data on MP_JOIN could be intercepted/dropped by middlebox, need to think about this. Olivier: it is just an optimization. if that happens you can try again without the data on the MP_JOIN ------------------------------------------------------------------- 4: Secure multipath key exchange over Multipath TCP - Costin Raiciu Alan: What do you need to change the protocol for this? Data seq mapping for SYN? Costin: Basically, but we will also want to revisit security mechanism. Why we need to way for one RTT to send data, etc. Middlebox issue that drop syn with data will be minor issue for MPTCP Olivier: Right. If middlebox drop MP_JOIN with data, MPTCP can retransmit without data. MP_JOIN with data is just optimization. Phil: Goal is to finish the bis by Prague if possible (really late with this!) Implementations needed. Either wait for those to catch up or remove things not implemented. Phil: Any other things for 6824bis? Yoshi: Is it Ok to just go with SHA-256? Mirja: Ask the SecDir for an early review. ------------------------------------------------------------------- 5: Channel bonding of low-rate links using MPTCP for Airborne Flight Research - Joseph Ishac Juliusz: you could use source routing or SADR here and then do without the proxies if end points are MPTCP capable. Joseph: proxy works explict. Matt: mptcp works well in our scenaio. if other technology works better, I would like to know. Joseph: The goal would be both ends will be mptcp and remove proxies, but stil need some static operations. Juliusz: Just clarify. source rouing can be combined with mptcp. ------------------------------------------------------------------- 6: Performance Gain with SYN Duplication in MPTCP - Kien Nguyen Minoz: Have you consider using this for censorship? Kein: Could be a case. But, Our motivaion was high throughput and low latency. Mirja: If you send data in MP_JOIN, can it do the same thing? Alan: Have you done security analysis on this? I still have some concerns. Kein: I hope we will have update soon on that part. Yes, it's an important point. ------------------------------------------------------------------- 7: Proxy Discussion Phil: Only talk about the two-proxy case at this meeting Christoph: We might want to consider IP version Dave: Policy control means e.g. use one link only for overflow or leave some traffic out of the link bonding Stuart Cheshire: low latency and failover are the most important thing, not more bandwidth today apps are adaptive, so bandwidth is not so important anymore because apps can adapt Margaret Cullen: there are still places where this is important Nicolai: rural areas with low bandwidth are places where this makes sense Olivier, Alan, Wim: 0-RTT is key Lars: once QUIC is deployed, all of this is useless Phil: Sketch of Proposals (3 approaches) We should try to pick one approach. Wim Hendrickx: #3 is not always viable because proxy not always on default path? Phil: Routing makes sure that the proxy becomes on the path (e.g., source-routing, tunnel,...) Wim: This complicates the design of the network. Adoption becomes difficult. #2 - round-trip-time is an issue #1 - 0-RTT Med: Socks4 does not support IPv6, so it's a no-go. SOCKSv5 adds delay. Christoph: #2 is possible with some minor changes with SOCKS Med: If other protocols want to use #1, we don't prevent them to do this. They can just do so. Dave Ellen: #1 - would be a useful assumption or requirement so that all traffic is routed (not only MPTCP). Dave: Plain-mode deprecates SOCKS. But just anecdotal for a quick look. Margaret: Are either of both 1/2 does one of them involves terminating the TCP connection? Wim: When there is end-to-end MPTCP the proxy does not do anything. If either does not support, then the proxy will transform it to MPTCP. Mirja: When neither of the end-poiints support MPTCP, there are 2 proxies terminating the TCP/MPTCP connections. Wim: #1 and #2 very similar? Christoph: They will end up very similar. Question would be it'll be more generic or MPTCP specific. Med: It's because we have the use-case about MPTCP Mirja: I would like to know what to do for them. For #2, it won't require any work. Changing SOCKS won't be a scope of the WG. Mirja: #1, it goes into the payload. Originally in TCP-option. Wim: Yes. Margaret: This is another form of proxying/tunneling. All of solutions have some issues, such as MTU. Med: For MTU there are no issues for plain-mode, because only the SYN of the initial subflow is "NAT'd". Wim: SOCKS actually does this sort of stuff. Margaret: Do we need signalling for endnode status, etc? Wim: Maybe useful. But, the solution should work without it. Rolf: #1 puts Layer-3 info in Layer-4. I don't like that I would hate it if an MPTCP-implementation would have to implement it. Mirja: It's in the payload, so not Layer-4. Wim: This should not be mandatory for an MPTCP-implementation. We want to standardize it because there are different vendors on each side. Rolf: fast open uses payload in SYN, but it's layer 4. Med: wrt to layer violation, we already use IP for TCP-checksum Mirja: Does not think that it's a layer violation. Olivier: #3 deployed and implemented #1. Operators perfer #3. To Christoph: let's start with MPTCP and extend later. Dave: When deciding between 1 and 2, take the one with the least moving parts Mirja: Does option 3 needs any protocol changes? Olivier: #3 was documented in the transparent-mode draft of last year. Need to distinguish between MPTCP-connections from the endpoint vs gateway. Phil: How to you ensure that remote is on-path Olivier: Any network solution, like source-routing. Med: Always place the initial subflow on primary path. To differentiate: PREFER_PROXY-option or a bit in MP_CAPABLE. We want to avoid mixing native MPTCP from the proxy one. Alan: I remain to be convinced for the need of this option. But if there is a need, it can be specified spearately. Phil: Let's not go into PREFER_PROXY discussion. We should reach a conclusion of 1 vs 2 vs 3. Med: Why do we need to decide between these? Mirja: Why does #3 has to be a MPTCP-option? Med: It does not have to be in MPTCP. It can be in the payload. Alan: In payload is dangerous for #3. Phil: For each of these three, do people think that the IETF should develop a solution? Rolf: Does #2 require standardization work? Wim: #2 and #1 will end up being the same. Juliusz: I'm against all 3 of them. We should not work on a middlebox solution. Med: The external IP of the proxy can be the one of the original client. It's upon the proxy to decide. Juliusz: I am worried about any kind of middlebox that does more than encapsulation. Wim: I am also against middleboxes, but this solution allows adoption of MPTCP. Joseph: It's not clear how multile subflows will be introduced here. Mirja: #1 there is no layer-violation. But #3 there rather is one. I would like to have the opinion of TCP-experts on this. Phil: Hum, should we do something or not? ???: Why are we voting 2 or 3. We should just vote for 1. What does it mean we hum for 2? It's not relevant here. Phil: Don't worry about that. Here is IETF. Hums during the meeting: Should the MPTCP WG do any MPTCP proxy work, or do none – about 2:1 or 3:1 in favour of doing work Should the MPTCP WG do proxy work based on option #1 in slide 12? Strongly more yes than no Should the MPTCP WG do proxy work based on option #2 in slide 12? more no than yes Should the MPTCP WG do proxy work based on option #3 in slide 12? Weak & roughly equal (Ref: https://www.ietf.org/proceedings/98/slides/slides-98-mptcp-sessa-chairs-01.pdf)