Multipath TCP (MPTCP) Meeting : IETF105, Monday July 22, 2019, 15:50 - 17:50 (Afternoon session II) Location : Place du Canada Chairs : Philip Eardley Yoshifumi Nishida AD : Mirja Kühlewind URL : http://tools.ietf.org/wg/mptcp/ Note Taker: Michael Scharf -------------------------------------------------------------------------- 1: Working Group Status - Chairs RFC6824bis has completed IESG review. Final confirmation required that all IESG comments are resolved. -------------------------------------------------------------------------- 2: MPTCP Robust session establishment - Markus Amend Anna Brunstrom: Which of the two versions is your main target? The simple one may be similar to what is going on in TAPS. Markus: Good point. There was a similar comment on happy eyeballs on the mailinglist already. Yet, it may make sense to have something inside MPTCP. Anna: TAPS also uses happy eyeballs. Phil: You want to develop both versions? Markus: This can be discussed on the mailinglist. If there are good reasons to remove the simple one, it could be removed. Yoshi: Can you provide a testing environment to someone who implements this? Markus: We have a prototype for the paper, but it is outdated and buggy. A new implementation should be developed from scratch based on the current draft version. Deutsche Telekom currently doesn't have the development resources. Help would be appreciated. ----------------------------------------------------------------------------- 3: MPTCP inactivity time option and Rate-limit option - Viet-Hoang Tran (remote) Chairs: These are two proposals. Are there any comments? Yoshi (from floor): About the rate control option. The client clamps the window size, right? If the server clamps the window, this can achieve more or less the same? Viet-Hoang: Yoshi: Or use 3 dup ACKs? Viet-Hoang: This would imply different semantics. Yoshi: Regarding inactivity timeout: What is the current default in Linux? Viet-Hoang: Keep the connection forever, unless there is memory pressure. -------------------------------------------------------------------------------- 4: Privacy threats and possible countermeasures for Multipath-TCP - Marcelo Bagnulo Chairs: Comments? Questions? Yoshi (from floor): Let's consider an attacker who monitors the traffic at multiple points and observes the DSS option. He could correlated MPTCP connections, right? Marcelo: Right, that is an additional attack. Yoshi: So, We have to encrypt DSS as well. Marcelo: Correct. Yoshi: It can be combersome to encrypt MPTCP options one by one. We might want to encrypt all options at once. Marcelo: Encrypt the options by session key. It could also work to use the session key. We have talked about creating a secure version of MPTCP in the past. We would have to agree on the security goals for that secure version of MPTCP. It would be a significant change of the protocol. This document is only about minor protocol updates. -------------------------------------------------------------------------------- 5: Potential future topics for WG Chairs: There will be a related discussion in the TSVAREA meeting on where to home multipath work in the IETF. - Default is to close the WG around IETF 106 and continue maintenance work in TCPM - Or working group can continue if there is interest Chairs: List of active individual drafts - Many are driven by a small group of peoples only Chairs: Next steps? Close the WG? Move on? Markus: Several questions to the AD. (1) What are minor extensions? (2) Lot's of multiplath development in the IETF, e.g., multipath QUIC, multipath QUIC. Combine them? (3) MPTCP is selected by 3GPP. Is it part of the liason? Mirja: Regarding (1): Decided by TCPM on a case-by-case basis. Regarding (2): We want people to exchange ideas. This will be discussed in TSVAREA. Regarding (3): Liason is aware of the use of MPTCP. Currently 3GPP does not request changes, i.e., we seem to be good. Florian: Regarding the 3GPP comment. Dependencies exist regarding two drafts: The first one is the TCP converter draft. Second is the main -bis draft. Mirja: The first one is in TCPM and close to be finished. The second one is the -bis document and done already. So we seem to be good regarding 3GPP. Keith Moore: Is there support in the room for working on a secure (encrypted) version of MPTCP? Chairs: Show of hands: How many would be willing to work on an encrypted version. (~1) Marcelo is interested. Mirja (as individual): If you want encryption, use QUIC. Chairs: Would work on be a bad idea? (a couple) and why? Nicolas P: I think it's too heavy. Would require encryption of options. Yoshi: TCPINC was oribinally intended to be used for MPTCP. But, it does not encrypt options. Do we want to create an updated version? Mirja: There is zero deployment of TCPINC. I would suggest to first get deployment experience. Markus: Will there be another meeting at IETF 106? Chairs: No decision has been made so far. Alan Ford (on Jabber): MPTCP + TLS was proposed some time ago. Yoshi: Someone wants to revive this? Alan Ford (on Jabber): If someone is interested, I would contribute. The proposal was to use TLS key extraction for the session security. It was only a 4 page draft in -00. If there was interest in encryption at transport level, I would suggest to use this as a starting point. Mirja: If there is interest, bring it to the TLS working group. Marcelo: TLS is used as it is. Mirja: TLS may not be happy about an interface to expose the keys. Chairs: Anybody interested in helping Alan? (Yoshi and presumably Olivier are interested) Marcelo: The authors of the draft may be interested. Eckert Bogenfeld: Maybe many people are on holidays? Is this just bad timing. My proposal is not to close the working group and to wait until IETF 106. Sri Gundavelli: +1 In the past, there was general interest in the active documents. Some of the active individual drafts are relevant. Mirja: I will not make a decision now. Continue on the mailing list. But, interest from multiple contributors not only authors is needed for moving forward any of these items.