Minutes IETF98: mptcp
minutes-98-mptcp-02

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)