Minutes IETF105: mptcp
minutes-105-mptcp-00

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?
       (Note: someone was interested. but, cannot identify the name..)

   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.

   ???:
       +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.