Multipath TCP (MPTCP) Meeting : IETF97, Monday Nov 14, 2016, 13:30 - 15:30 Location : Park Ballroom 2 Chairs : Philip Eardley Yoshifumi Nishida AD : Mirja Kühlewind URL : http://tools.ietf.org/wg/mptcp/ Note Taker: Rolf Winter -------------------------------------------------------------------------- 1: WG Updates - Chairs MPTCP experience in RFC editor queue No particular implementation updates reported during the meeting Hackathon update: (from Fabien) 25 students in Louvain-La-Neuve and 5 people in Seoul Integration API with iPerf3 Binding the API towards a couple of languages Tuning a few applications for MPTCP LD_PRELOAD library Documentation Won the hackathon ... congrats! See Olivier's bog post for more information: http://blog.multipath-tcp.org/blog/html/2016/11/13/multipath_tcp_projects_during_the_ietf97_hackathon.html -------------------------------------------------------------------------- 2: 6842bis update - Alan Ford Two changes since IETF96: Add a flag into MP_CAPABLE "Do not use this address" and reliability of ADD_ADDR option Yoshi: This is for load-balancers? We have another solutions for load-balancers from Christoph. Alan: Not only for load-balancers. This is an optimization which is useful if you are behind a load balancer, but can be applied to other situations as well. Yoshi: Is this a mandatory feature for all implementations? Alan: All implementations have to support the echoing only. Yoshi: If ADDR_ADDR has been sent in ACK, the receiver might need to send ACK for ACK. Isn't it tricky to implement? Alan: I don't think so. Let's wait for implementation reports. -------------------------------------------------------------------------- 3: Efficient Design for Securing MPTCP against Eavesdropping during the initial handshake - Dong-yong Kim Alan: Why is the MP_JOIN insecure with MPTLS (DoS Attack)? (page 18 on the slide) Dong-Yong: Because valid token can be taken. Yoshi: This does not have to be MPTCP, why do you restrict it to MPTCP? Dong-Yong: I just did. Yoshi: The key length is restricted to fit into option space. Is it secure enough? Dong-Yong: With current key sizes this is safe. In 10 years, I do not know. -------------------------------------------------------------------------- 4: MPTCP Address Advertisement - Fabien Duchene Fabien: The 2 proposed bits have been added to the bis document as already mentioned. Echo flag has been implemented No_JOIN is still under development (probably done by the next IETF) Backup bit in the ADD_ADDR for make before or after break... more feedback needed Alan: You could do this by playing with window sizes and ACKs. Fabien: Yes, but that is hacky. Explicit is better. Mirja: Single bit or priority value? Fabien: Priority would be useful? Mirja: Is this a real use case? 0/1 is more realistic. Brian: Seconds Miria. In reality really difficult unless you have something like CBR traffic, but TCP is not used for that kind of traffic. Christoph: Sometimes this in not a 0/1 decision. Our implementation can be read about in the IETF journal (https://www.ietfjournal.org/multipath-tcp-deployments/). Sometimes a little more control is nice. Mirja: You can still do this with a 0/1 signal. Christoph: This is related also to latency etc. Mirja: But, this is more than just priorities Christoph: I agree Fabien: This is why we need more feedback on the list. ????: Priorities should consider other use cases (servers pooling DSL lines etc.). Overflow use cases and bandwidth pooling use cases etc. 3 bits proposed for defining communities (addresses with shared properties - user configurable). Dual-stack case main motivation Alan: Seems unnecessary. Users do not know this. Limited applicability. Fabien: This is to avoid using the same path. Alan: Then just do not announce it. Fabien: Makes sense. If this is a bad idea, then Ok. We can just scrap it. -------------------------------------------------------------------------- 5: MPTCP load balancing - Fabien Duchene Fabien: A guide to help people choose a load balancing solution Next steps: more work on security and industry input Yoshi: Previously Costin and Christoph proposed load balancing. Is this a merger? Fabien: No, this is just a comparison. -------------------------------------------------------------------------- 6: A proposal for improving MPTCP initialization - Kien Nguyen Kien: Proposal: Duplication during initial handshake (parallel SYNs) Alan: Scurity is weakened by this. Kien: Yes, we need to work on this. Yoshi: We usually have only one default route even if a node has multiple interfaces, e.g. wifi and ethernet. Klen: We presume a node has some routing mechanisms to utilize multiple interfaces efficiently. -------------------------------------------------------------------------- 7: Rechartering Discussion Possible work items: * API Show of hands: a bunch of people support this, but nobody really against it * Proxy Before going down this path, clarifications are needed. Alan: This is already in the charter Phil: Let us add this, since people want this and deploy this. Let us do this through the IETF and not have people just deploy their own stuff. Mirja: This is not MPTCP specific. This should therefore not be here since this is tunneling. Yoshi: We can document operational experience and guidelines. Is this in scope? Mirja: Yes, but not sure there is a big difference between one-ended and two-ended Olivier: The two-ended solution is not tunnel. Mirja: Ok, but tunneling is not in scope for MPTCP Wim: This proposed bits (excluding UDP) is proxying, not tunneling Brian: Advertisement for the BANANA BoF on Thursday. Alan: Agrees to put this on the charter as an analysis thing as according to the charter. Phil: It is important to understand what the impact is on the protocol bits. Is e.g. the bis in its current form appropriate. Also exclude the UDP case. That should be left to BANANA. Wim: Removing it might complicate things. But it might be a good compromise at this point. Dave: Process-wise, what does it take to define a technical solution to define the UDP bit if we do not think about this now. Mirja: We will think about this when we are there. Alan: The analysis will potentially lead to extensions but we do not need to think about this now. Wim: BANANA is a non-WG forming BoF. A lot depends on whether BANANA will become a WG or not. * Potential other items. NFS or CC or other topics if any. Nobody spoke up