Multipath TCP (MPTCP) Meeting : IETF95, Wednesday April 6, 2016, 14:00-16:00 Location : Buenos Aires, Buen Ayre B Chairs : Philip Eardley Yoshifumi Nishida AD : Mirja Kühlewind URL : http://tools.ietf.org/wg/mptcp/ Note Taker: Olivier Bonaventure, Will Ivancic -------------------------------------------------------------------------------------------- 1: Chair's slide Phil: - Status of the WG - experience about ready to go to IESG, Phil will do shepherd report - update of the protocol document to get on standards track - milestone on middleboxes, there is lots of work in industry on middleboxes, but we had no working group document on this topic - milestones need to be refreshed by the chairs - Implementation news - Nigel in Swinburne on FreeBSD, did not have time to do coding for thesis, will be back soon Christoph Paasch: Linux has implemented ADD_ADDR2 and feedback has been provided to Alan for the new draft Linux is preparing a new stable release 0.91 in the coming weeks Rao Shoaib: Solaris side is Working on implementation, performance testing is being developed. If someone wants a beta, please contact me -------------------------------------------------------------------------------------------- 2: Updates for draft-ietf-mptcp-experience - Christoph Paasch Christoph: added some information on papers with MPTCP on smartphones finalized the conclusion, no big issue identified industry implementations have been successful and got widespread deployment draft is in its final stage and hope we can progress to IESG Phil: will write a shepherd report so that the draft can be sent to IESG Alan Ford: Is there any discussion on heuristics that has impacts on the bis draft? Christoph: No heuristics is concluded yet. We don't know what is absolutely the best way on scheduling traffic, etc yet. Maybe other drafts that come later may describe something Rao: Does the draft talk about datacenter and deployments in case of storage, backups through WAN connections? Christoph: There are bunch of research papers on datacenter use case for its benefits, but we don't know industrial use cases so far. No report about commercial deployments in datacenter in the draft. -------------------------------------------------------------------------------------------- 3: Updates for RFC6824bis - Alan Ford Phil: - primary goal is to publish a standard track version - we will bump the version number, this gives an opportunity to redesign multipath TCP signalling - made MP_CAPABLE signalling reliable, few other changes have been included in the bis draft - SYN cookies draft has an IPR declaration associated with it Rao: Will we support version 0 and 1? and at some point we say we don't support version 0? Phil: version 0 is an experimental protocol. version 1 will be standard track. Alan: - new negotiation mechanism based on SYN cookies draft - added some clarifications to the draft. - diff from RFC6824 is actually small as the changes are handshake mechanisms and clarifications - what else we want to include more? Christian Huitema: I would like to see a discussion of the privacy effects and privacy protection of MPTCP. Someone can listen to initial exchange and have a copy of the keys, etc that can discover in exchanges belong to the same connection. It is definitely possible to find that a new sub flow belongs to the same mptcp connection used before. So, if you move on different networks, by using mptcp and by disclosing info, you can tell that you are the same party in the previous location. This is clearly trade-off, but it should be discussed in the security section. Alan: Endpoint needs to have some identification of the connection. Christian Huitema: Not suggesting to change the design, but need to document issues Alan: Yes, we can do that. Mirja Kühlewind In tcpinc WG, we decided to not encrypt the header, but could encrypt some of the options. Could be used to solve the issue. This could be brought to the tcpinc WG. Alan: OK. We can mention that in the draft -------------------------------------------------------------------------------------------- 4: Updating the MPTCP Handshake - Christoph Paasch Rao: One thing MPTCP talk about is application does not need to be changed. Right now, we don't have APIs that tell kernel what the app wants. Christoph: If people want to use TLS-base key, it means the app need to be mptcp-aware. That's why we also need legacy fallback for apps that don't support such APIs. Rao: I don't have problem for the scenario, but apps need APIs. Christoph: Yes, we need APIs. Denis Ovsiyenko: Why do you leave key exchange to the higher layer? Christoph: We want to handover key exchange to the higher layer. Because TLS or other technologies can ensure encryption of key negotiation, while mptcp exchanges keys in clear text. Alan: So, there is no connection between the token and the key? would token be discarded for legacy fallback? Christoph: Yes. Alan: I think it will work as it doesn't break any functionality in mptcp. We have fallback mechanism. I can't immediately see of any issue with this approach. Christoph: OK. I will try to write a draft to document this. Costin (jabber): There is a concern on whether we should go to a new version number. If you are unhappy with the version number change, you need to discuss this on the list Phil: We had several discussion on this. We are getting consensus on increasing version number. If someone is not happy with it, let's discuss on the ML. Joseph Ishac (jabber): A major change should be at least tested experimentally first. Has the new handshake been studied in any test? Alan: That's why we wrote in the draft. If you have concern, please raise comments on the list. Christoph: It would be good we have multiple implementation and do inter-operability tests. Phil: Is there practical experience with the new handshake? Christoph: Only the ADD_ADDR2 option of the bis draft has been implemented. The other new features have not been implemented. Phil: Do you know if someone has plans? Christoph: For long term vision, yes. Cannot be certain we can do this by Berlin or not. Olivier Bonaventure: Experimental option could be implemented, but no plans for handshake Alan: Just to be clear. This is not proposing adding TLS support in the bis draft. Just provide a framework to allow extensibility Christoph: Protocol modifications are not that major in this case. Phil: Let's continue discussion on the list. Not reasonable to ask for a hum without a draft. Huitema: Idea of exchanging the key out of band is encouraging because you could also deal with the token that way and solve the privacy issue. There is a method in TLS to export key material, derive secret from master secret. Christoph: This would imply that the document is not predictable, which is annoying for the load balancers. Rao: How much can you put in the protocol bis draft? We're interested in encapsulating UDP inside Multipath TCP. Will Ivancic: NASA interested in multipath UDP using MPTCP. Rolf: Hybrid access and some people are interested in running traffic over MPTCP tunnels Juliusz Chroboczek: If you use UDP, you need more flexibility. Pointer to MOSH work done by Matthieu Boutier Phil: We'll need a longer discussion about whether that this is a potential topic for future work. Variety of technologies and there are working systems, some of these people are using MPTCP including tunnelling of traffic. Brian Trammel: We did some work in encapsulating UDP. You have to be relatively careful. You could do it configurationaly and operationally. This is interesting, but easy to get wrong Phil: Target remains to have stable version for Berlin. Will check with the AD to see whether we want to do rechartering for the tunnelling discussion. -------------------------------------------------------------------------------------------- 5: Multi-channel combining for Airborne Flight Research - Will Ivancic and Matt Sargent Christoph: There was a recent fix on 0.90 for the ack problem mentioned in the presentation -------------------------------------------------------------------------------------------- 6: Multipath TCP Support for Singlehomed End-systems - Rolf Winter Juliusz: Home network WG is doing something similar to what you propose, but with IPv6 only Data is routed using source specific routing to the correct gateway. Look at home net architecture document Multiple addresses on a single interface and MPTCP works out of the box in this setup. Rolf: I will take a look. Is it ND specific or use DHCP with single offer? Juliusz: We are testing with RA -------------------------------------------------------------------------------------------- 7: An MPTCP Option for Network-Assisted MPTCP Deployments: Plain Transport Mode - Med Boucadair Rolf: It is a new tunnelling technology? Med: Not a tunneling. The option is only placed in the SYN. Alan: A plain mode option is on every packet? Med: Wait until the next slide Rolf: How can it not be on every packet, otherwise it does not work. Is there enough space to carry this option? Med: State is maintained by the CPE and the concentrator in order to glue it with packets Christoph: For every connection, how many connections do you create on between CPE and concentrator? Med: It depends on network attachment you have Christoph: If client creates 10 connections, there will be 1 MPTCP connection? Med: No. There will be 10 MPTCP connections Rao: I think people are confused by the concentrator and you can remove and just have two hosts. Assume MPTCP is sending UDP Rolf: There will be lots of connection state on the concentrator Med: It's a normal way for functioning proxy or CGN Mirja: If you put UDP on TCP, is it always right thing to do? Christoph: So, you can put it either in option or payload. what is the tradeoff between them? Why put it in options if you can use payload? Med: There is an order. Try option first and then payload Wim Henderickx: The objective to use option is if you do TLS, better to put in option to avoid problems with encryptions Christoph: What happens if we do TLS and there is no option space? Rolf: Is the reason for having an MPTCP connection per eligible flow is to put the option in SYN? Put it in SYN only and maintain the state to check 5 tuples to match it Med: Right Wim: Still need state because you need to map outside to inside for downstream traffic Rao: Strange to put in SYN How does the concentrator that the option is in the payload? Alan: Do you have an example of what the payload looks like? Is there any UDP or TCP header in the payload? Wim: We don't change anything in the payload Alan: So, no length information about the UDP segment Med: Aspect that we want to discuss. Alternate approach is to pre establish MPTCP connections, but it requires that you send a plain mode option with a null IP address before. Or, include UDP payload in the SYN and need specific operation to suggest disabling some TCP functions. It's up to each implementation to decide about disabling. Alan: The issue 2 in the slide 12. The answer is yes. You cannot just map it Rao: That's why I'm struggling to understand how to check boundary, how to keep order, etc Rolf: lots of new stuff and options, don't see the benefit of having an MPTCP tunnel where you don't have to do anything. You only loose a bit of MTU. Why not just having tunnel? Med: If you only have a tunnel, you have no indication that the flow belong to the same UDP flow, you need extract information at encapsulation level Rolf: Why does it need to know that? Wim: Why extra headers, you send a packet to two links and you need to reorder the packets. That's why we need extract information to achieve that. You need flow control on top of GRE if you want to do this with GRE Phil: Is this proposal for information or do you come with a request? We cannot adopt this because outside of charter for now If you want to be working group document, send an email with a rationale and we would need more discussion around it. Mirja: Send it to the TCP working group to get further eyes. Might need broader audience