Minutes IETF99: mptcp
minutes-99-mptcp-00

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]