MP-TCP Session 1, Tuesday 15:50 scribes Dave Allan, Ilpo Järvinen WG-status Implementation Updates - Chris Paasch - iOS and Linux Update "MPTCP in iOS11" slide Julius: who picks the mode, the user or developer? A: Developer. Julius: What does "only for developers" in one of the bullets mean? A: Can only use it on a developer phone (with paid developer Apple account). Debashish: Wifi assist. if two interfaces on the cellular connection. A: We do not support this. Debashish: we see some use cases where this is possible. Marcus: On iOS, do you plan on supporting proxies from the phone itself. A: Can't comment. - Fabien Duchene - implementation results Alan: this is using vanilla 6824bis A: yes - other updates no update - hackathon news Quentin Alan: The general point is that the MP-TCP reset option was to carry additional semantics. Timeout, again the reason codes had a general logic, if it could be useful for an admin to analyze a problem, or analyze a bug. We don't necessarily need reason codes for everything. It has stuff like lack of resources or ???, exactly the stuff we'd want to see for transient problems. A: we can continue the discussion on mail. reaction to the experimental option: Alan: should be a fairly straightforward. Julius: For the peanut gallery, what is the application of this? Alan: local experiments - Alan Ford - RFC 6824bis Phil: A question to revisit on Friday, if there are any further suggestions of extensions to the bis version before we declare victory. DO we have implementations of all the new bits? Alan & Chris P: Linux is fine, but IOS is not complete Alan: we have one implementation of everything. Discussion about hackathon MPTCP code availability, Chris P?: should all be available once pushed out Phil: Is this sufficient to go standards track. Mirja: Up to the WG, will be justified in the shepherd’s write up. Phil: Discuss timing a bit more on Friday. Need a security area review to make sure they are happy. Proxies - Olivier, MPTCP Converters Jabber: When the converter translates TCP to MP-TCP, who decides to do this, is it the client or the converter. A: do not understand the question. Alan Ford: How do we add another subflow to this? A: you have two MP-TCP connections. If the client adds a subflow, one will be added between the converter and the server. In many use cases you have a large numebr of connections. Alan: The presence of all this direct stuff tells you the server supports MP-TCP, in the previous example it wasn't there. Vladimir: About TFO, isn't it dangerous to pass the TFO cookie to the client vs. keep it in the converter? A: Depends on deployment. If you think of a converter with a single IP address serving a lot of clients there may be a problem. Pool of IP addresses, makes sense to send cookie back. Chris P. What happens if the converter changes its cookie, so there is a wrong cookie on the client side. A: you would not ack the message and have a restart, normal TFO procedure. Julius: More comments after socks 6. Extensibility, what do you do with unknown TLV. A: there is an error TLV in the draft. Julius: Actual procedures not described. You are only replying with a SYN-ACK when you get a SYN-ACK from the other side. A: we want to test the connection to the server is working correctly. The connections do not always succeed. Some small changes to be done in the stack interactions. Jabber: Only plain MP-TCP support is the client the middlebox. A: take that question to the list. Mirja: this is an app layer protocol. And can be used for other things besides MP-TCP, so this may not be the right group. A: speaking as an individual. Mirja: Individual, but can change that anytime. Med: If we want this specific to MP-TCP, it is a matter of scoping the document. If it is a proxy just get the port number. Mirja: This is the right direction but not the right WG. Sounds a bit like ICE (?). Oliver: This does match the charter item. Mirja: It does not need to be a WG document, could still be elsewhere? Phil: We need to discuss perhaps in a smaller venue. Alan Ford: This is very MP-TCP specific as far as app layer protocols go. It is in scope as an MP-TCP solution so IMO it is a good map with this WG. Mirja: Shop this around to other WGs. Julius: The use case comes from MP-TCP. Julius: This is a quite manageable document, written with an eye to implementability. There are no domain names, this is good. If this goes through other WGs, will it still have this property. Oliver: Do not know. Do not want the converter to have to do a DNS lookup. A side effect is that it becomes doable in kernels. Mirja: As an AD I'd recommend announcing this on the TSV AREA and TCP mailing lists. Phil: This is a nice to read document. I encourage everyone to read it. The contributors really listened to the feedback from previous efforts. - Vladimir -SOCKS protocol version 6 Julius: In the late 90s, early 2000s, it was great to use SOCKS5, but we discovered one RTT was added to no benefit, it took 20 years to get that back. Thank you. Need to stress how much Olivier and your drafts live in different spaces. I think this has reason to exist even if Olivier’s draft is also pursued. Generalizing often yields unmanagable protocols. I wonder if there is a way to talk to a proxy and know if a converter or SOCKS6. Vladimir: No sure how to answer that question. Should go like this. Hi, I want to speak version X, server, I speak version Y. If client speaks SOCKS5 then the server should speak SOCKS5. Olivier: We start with a fixed header with a version number. If the first transaction had assigned ranges of version numbers for converter and for SOCKs then this would be possible. Julius: The initial truncation of data, needs some discussion, A: will amend the draft. Ben Schwartz: Similar proposal in DPRIV, ability to demux on first few bytes is controversial as it constrains protocol design. Socks5 is incredibly widely deployed. Your proposal is an improvement. Agreeing on a new major version number is close to being as big as that for HTTP. Probably should not be done in MP-TCP A: plan is to do this in INTAREA. Point out that the major improvement is in reduction of RTTs. Two use cases, localhost, and remainder on a LAN with low latencies. SO the latency savings is useful, but only if SOCKs server is a large distance from you. The TLS should be mandatory, or some other encryption. 4G and 5G have high delay, so going to get large RTT. Ben: Again funky security properties. None of the SOCKS5 clients today do any encryption between client and proxy. Plain text passwords. Outside a private LAN, TLS should be mandatory. Olivier: It does not use TFO, thanks for providing the code. AS for the existence of HTTP proxies, there are other applications. Ben: HTTP connect is a superset of the functionality. Phil: Presenting this in INTAREA later in the week. A:Yes. MP-TCP Session 2, Friday 11:50 scribe Brian Trammell 3.3 Follow-up discussions from Tuesday's proxy discussions [15mins] Phil: SOCKS work will probably go forward in INTAREA. Converter discussion was quite promising, people like the approach, need more time to read it. Any further comments in follow-up? Otherwise I suggest the authors rev the draft addressing comments, will work out which working group that should go forward in. Discussion? 4. A security attack - Zhiyun Qian [15mins] See slide 8 in chair slides "MP-PRIO attack". MP-PRIO can be used by a MITM to divert all traffic on to its own path, degrading to normal TCP. Removing address identifier from the option fixes this. Upcoming paper at ICNP. Alan Ford: MP-PRIO is a backup bit, predates the PRIO bit in the MP-JOIN, which negates the point of this signal. Real question: is there a reason to change the priority of a subflow from another subflow? Olivier: Attack important in practice. Multiple connection, can be used to move all traffic to an untrusted network e.g. wifi. Don't know any implementer that uses address identifier on MP-PRIO, so remove it. Keeps protocol simple and usable. Phil: Anyone unhappy with proposed solution, please hum. [Silence]. Okay with it? [Tired hums]. Need more time? [Silence] 5. A proposal for MPTCP Robust session Establishment (MPTCP RobE) Markus Amend - "A proposal for MPTCP Robust session Establishment (MPTCP RobE)" [15mins] Alan Ford: last slide covers everything I was going to say. Biggest killer is no key in MP_CAPABLE. Semantics of the key simply aren't the same as what you're using. Can't assume that two keys on the wire are the same identity. Most concerned as to how you see this working without the key, what's your way around it? Markus: Key missing in first SYN, can't use as identifier. Last ACK has both keys available, then you can make the decision on the receiver side. Alan: Would not have been the same key B Markus: Host B answers with different keys B. Key B can be replaced... Alan: Security alarm bells. Can't point to just one thing. Very uncomfortable. Olivier: Good motivation, looking at Happy Eyeballs, though, this seems applicable. Work in TAPS for racing, is the same problem. Application layer library can do this, not application itself. Build a shim layer, then the app-layer solution is easier. Markus: Then we have some overhead Olivier: But you can learn the network, and remember it, you don't have to do this for every connection. Markus: Put it in the standard, not in the libraries, then it's general. Christoph: Important work. iOS uses the timer based approach. Independent of the transport layer protocol. Also, paths not equal. Markus: also delay. Brian: I like approach 1 but share Alan's concerns. No incremental deployment, means you need negotiation, makes it more complex. Would that be done before MP-QUIC is, for example? Approach 3, little bit more latency but less complexity. Don't race in MPTCP layer; racing in two places is messy, and you have to race v4v6 Anna: **missing** Separate robustness and latency 6. Proposal for a new Multipath TCP option Quentin De Coninck - "Every Millisecond Counts: Tuning Multipath TCP for Interactive Applications on Smartphones" [15mins] Uma: Low latency very important, 5G etc. What is the gain you achieve with you this approach over classical MPTCP? Quentin: Latency remains quite the same, but the cellular won't get established until you need to use it. Alan: Options in SYN before data, what are you signing with HMAC? No data until third ACK. What is DSN on slide 8? Are you sending data in the SYN? Quentin: Yes. Alan: Cool. Anna: Curious about impact on delay bet. detection to establish new subflow and cost of setting it up. Magnitude important to see whole picture on latency. Quentin: You see this with a low latency main net and a high latency second net. When the nets are comparable, Phil: Is this a change to base protocol? Changes security properties? Quentin: Yes Christoph: Important to reduce handshake time. But when cell is down bringing it back up again is very slow and in this case the handshake is lost in noise. Do you have MB detection? Quentin: No but we could. 7. Better documenting interactions between MPTCP and TFO - Christoph [10mins] Alan: I'd love to see this in bis, but I can't write the text Olivier: We will help. Michael Scharf: as TCPM chair, haven't been here for a while. In TCPM are thinking about moving TFO to PS. Does MPTCP have an opinion on this? Please give input to tcpm list. Yoshi via jabber: different TFO cookies sizes for TCP and MPTCP? Christoph: implementation dependent, currently cookie reduced to 4 bytes, can be dynamic. Olivier: In bis, requirements on shorter cookies are relaxed, since MPCAPABLE is only 4 bytes. Important for MPTCP is DS mapping for SYN data. Phil: Anyone against including this in the bis? [Nobody]. Too early to decide? [Nobody] In favour [some noise]. Christoph, you and Olivier please work up some text. Juliusz: Is it okay for MPTCP PS to refer to experimental TFO? Michael Scharf: TCPM can move TFO to PS if there were a problem Alan: TFO is informative in bis, so not a problem. 8. Using MPTCP on IPv6 only hosts in networks with NAT64 - Quentin [10mins] Mohamed Boucadair: There are means to discover NAT64, learn prefixes of all NAT64, you have multiple in path, generic problem. DHCP option is not an option, BEHAVE says don't do that, various issues. Juliusz: One POV that NAT64 is a hack that does not belong in the internet, I hope for a burst of common sense. Wonder about accommodating for NAT64 brokenness within MPTCP. Mohamed: **nat discussion** Olivier: *missing, network issues* NAT64 will exist. Please use a well-known prefix. Christoph: This is a really big problem when the device is on a v6 only net and we used to be a v4 only *net error* I think we could document this in the bis. 9. Plans for progressing MPTCP [10mins]