Subject: [multipathtcp] standards track now

From: "Eggert, Lars" <[email-masked]>
Date: Thu, 1 Aug 2013 07:43:14 +0000

Hi,

as I just said during TSVAREA, I think we should recharter the WG to allow work on a PS spec now.

The issues that remain to be worked on a clearly tractable and can be resolved during the normal process of pushing an ID towards RFC publication.

Lars

---

From: Scott Brim <[email-masked]>
Date: Thu, 1 Aug 2013 09:57:56 +0200

On 08/01/13 09:43, Eggert, Lars allegedly wrote:
> The issues that remain to be worked on a clearly tractable and can
> be resolved during the normal process of pushing an ID towards RFC
> publication.
> 
> Lars

I'm going to be the person who says "let's not be hasty".

(1) A fundamental point in MPTCP is balancing traffic on subflows and
overall coordinated congestion management.  Ramin Khalili's
presentation showed that what we have so far seems pretty
experimental, and we're essentially still at the research stage.

(2) NATs are real, so ADD_ADDR is going to get used, but it's a
security hole.  That's "clearly tractable" but what we have now is not
ready for even limited deployment.  Maybe ADD_ADDR should be taken out
of the standards track docs and added later.

Scott

---

From: "Eggert, Lars" <[email-masked]>
Date: Thu, 1 Aug 2013 08:04:36 +0000

Hi,

> experimental, and we're essentially still at the research stage.

right. But we can start the work on 6824bis now, and not yet start 6356bis until this has been investigated more.

We will probably want a normative reference from 6824bis to 6536bis, so we can't actually publish 6824bis before finishing 6356bis. But we can start the work on 6824bis.

> of the standards track docs and added later.

Sure, that's a discussion we can have. But we can have it during the work on draft-ietf-rfc6824bis, right?

Lars

PS: Phil pointed out to me that the WG is already chartered for PS work, so no recharter needed.

---

From: Roberto Peon <[email-masked]>
Date: Thu, 1 Aug 2013 10:07:01 +0200

ADD_ADDR and similar man-in-the-middle policy generation allows for cheap
successful semi-passive attacks whereby traffic is moved through a
centralized proxy which analyzes the content or metadata for that content.

I am not sure that these mechanisms will survive review by the security
working group without significant change, and as a result, I'm not sure if
this is the time to be going for RFC if it includes these features (which,
are essentially fundamental to the protocol's advantages....)

-=R

On Thu, Aug 1, 2013 at 9:57 AM, Scott Brim <[email-masked]> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.13 (Darwin)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iEYEARECAAYFAlH6FQQACgkQF0TR2hENFARCdACfVOVd1qXv0bnB5LJEOTqNJ4BD
> BmkAn0Au+FfCvkURa1AlxFVfvbE0mNlK
> =POc0
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> multipathtcp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/multipathtcp
>

---

From: Olivier Bonaventure <[email-masked]>
Date: Thu, 01 Aug 2013 10:40:21 +0200

Scott,

> experimental, and we're essentially still at the research stage.

Experience with congestion control schemes shows that improvements are 
possible. For TCP, this started in 1988 and hasn't yet stopped. The IETF 
has basically opted for NewReno like congestion control scheme for 
single path TCP despite the fact that there have been other proposals. 
Several TCP stacks have used different congestion control schemes.

For Multipath TCP, history repeats. This is not surprising. OLIA 
improves LIA, like several unipath congestion control schemes improve 
NewReno...

> of the standards track docs and added later.

ADD_ADDR may cause a security issue, as identified by Marcelo's draft, 
but this issue can be easily fixed.

The discussion that needs to be done in the mptcp working group is 
whether we want to have the current ADD_ADDR capability os not. We have 
to look at the use cases for ADD_ADDR.

The current implementations tend to either open subflows only from the 
client side, or only open one subflow at a time. In these cases, there 
is no benefit for the client to send ADD_ADDR (REMOVE_ADDR still makes 
sense to indicate that an address does not work anymore). The main 
benefit that I see currently from ADD_ADDR is for multihomed servers 
(currently probably a small fraction of the servers) and dual-stack 
servers (hopefully a growing fraction of the servers). I see benefits 
with ADD_ADDR on dual-stack servers to allow the client to learn easily 
the other address of the server.

Thus the important question for me is whether we want the ability to 
exchange IP address information within Multipath TCP. I think that there 
are interesting use cases for that.

Olivier

-- 
INL, ICTEAM, UCLouvain, Belgium, http://inl.info.ucl.ac.be

---

From: Mark Handley <[email-masked]>
Date: Thu, 01 Aug 2013 02:10:07 -0700

> experimental, and we're essentially still at the research stage.

As Olivier has said, I don't think any of us claimed LIA was the
ultimate MPTCP congestion control.  It's likely to be safe though, and
that has been a good starting point, just the same was that TCP Tahoe
was a good starting point back in 1988.

> of the standards track docs and added later.

Part of the problem with the current ADD_ADDR mechanism is that we don't
negotiate its use.  ADD_ADDR is probably safe and may be useful in
environments such as a datacenter, where on-path hijack is not an issue.
 Sure, you can have the server connect back to the client in those
cases, but things get more complicated controlling which subflows are
set up if both ends are doing it.

Out in the public Internet, ADD_ADDR's authentication may be
unacceptably week because if its ability to turn a passive eavesdropper
into an active man-in-the-middle.  The only way around this seems to be
strong crypto - we spent a _lot_ of time looking for alternatives, but
in the presence of NATs, there's nothing else stable to bind the
authentication to.  And we didn't really want to mandate strong crypto
within MPTCP.  [well, I did, hence tcpcrypt, but there's not consensus
on that]

For this, the simplest useful solution comes from Christophe and Olivier
- allow the app to supply the secret.  This is especially useful when
the app uses TLS or ssh, and the trend is in that direction anyway.  
What's missing is MPTCP's ability to signal that this is the ADD_ADDR
mechanism the endpoints will use.  In my view, this is probably
something we should change.

- Mark

---

From: Costin Raiciu <[email-masked]>
Date: Thu, 1 Aug 2013 14:33:22 +0300

I strongly support  going to standards track. There is a lot of interest in MPTCP and real deployment seems likely in the near future.

As for the two issues brought up:
- The security issues are solvable (see discussion below) albeit without strong crypto we will have to restrict the use cases for MPTCP.
- The congestion control is safe and works - if we wait for the perfect controller we might wait forever.

Now the discussion about MPTCP security and redirection. 

I will start by saying that I like ADD_ADDR because it allows flexiblity:
- one can insert explicit middleboxes on path (there were two bofs at this ietf that would like to have this)
- one can use v4 and v6 in the same tcp connection (without add_addr this is not possible); 
- it allows mobility even when the other end is behind a NAT

On the security front, I think we are raising the bar for MPTCP a bit too high, given that today on-path boxes can also redirect TCP by:
-  tunneling data to another middlebox
- by using MPLS / Openflow/any other routing. 
In fact many networks mess with TCP connections, and can apply any of the attacks that are possible with MPTCP redirections, albeit only in the same administrative domain.  One positive aspect of MPTCP redirections is that they are explicit: at least the endpoints know the connection is being redirected (which is not the case today with all these transparent boxes and routing tricks!). 

Coming back to MPTCP attacks. there are two ways we can make MPTCP more secure.

1) MPTCP with plaintext keys. 

ADD_ADDR is not the only issue - it's just the most obvious one. The attacks draft shows that an off-path attacker can hijack the connection by using the ADD_ADDR (with a bit of effort). As mentioned, this attack is easy to counter by adding an HMAC or the token to the ADD_ADDR. 

An on-path attacker, however, can still use ADD_ADDR because it knows the keys. So to stop these guys we must drop ADD_ADDR altogether. 

However, even removing ADD_ADDR  does not completely solve the hijacking issue. Anyone on path can snoop on the initial handshake and learn the key. With the key, this attacker can go off-path and start two subflows, one to the client and one to the server (it knows the crypto material), and proxy the data between the two. This attack does not use ADD_ADDR and is relatively easy to execute.  One way to stop this attack is to mandate that all subflows are opened in the same direction as the intial one; this allows client mobility, but does not allow server mobility (except make before break if we allow ADD_ADDR).

In summary: by removing ADD_ADDR and restricting the direction in which subflows can be opened MPTCP redirection is not possible anymore even for on path attackers. However, while doing this we lose flexiblity - server mobility is not possible anymore, v4+v6 mptcp connections are not possible anymore, etc. 

2) For traffic people care about, TLS is used with TCP today. The same will be true with MPTCP: sensitive traffic will run over TLS. In this context, since the data is encrypted, even if traffic is redirected it doesn't really matter - so I think we should allow ADD_ADDR without any extra authentication needed (i.e. leave it as it is today).   

Of course if we have a secret key between the endpoints we can restrict sending ADD_ADDR to the connection endpoints. However, the fact that on-path middleboxes can also use it is a bonus in my view, because it allows operators to route the traffic via middleboxes (which they already do!) but in an explicit way - at least the endpoints know about the redirection.

Cheers,
Costin

---

From: Edward Lopez <[email-masked]>
Date: Thu, 1 Aug 2013 12:21:13 +0000

I feel that we have not given due consideration to the role of middleboxes here.  Middleboxes providing proxy and DPI services will not function correctly if they do not have visibility of all sub-flows.

The idea of removing ADD_ADDR and restricting sub-flow direction will likely result in middleboxes forcing fallback to standard tcp, upon detection of an mptcp stream.  Consider the case of of IPS device, which might be required to be in place due to regulation (such as PCI-DSS).  Such a device, without recourse to redirect sub-flows, would have to view mptcp as an evasion attack.

I do recognize the problem here.  I see middleboxes potentially participating with mptcp in a relay and proxy mode.   By relay mode, this is where a given middlebox has visibility to all sub-flows.  It is likely that the ability to create this relay (a benevolent MitM per se) would require the ADD_ADDR function.  In a proxy mode, a middlebox may actually receive standard tcp or mptcp sessions, and proxy them into new mptcp sessions.  I sense that this form of middlebox as an mptcp proxy will be a more likely use case, which must be explored in depth.

Rdgs,
Ed Lopez

On Aug 1, 2013, at 7:33 AM, Costin Raiciu <[email-masked]<mailto:[email-masked]>> wrote:

Cheers,
Costin

_______________________________________________
multipathtcp mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/multipathtcp

***  Please note that this message and any attachments may contain confidential 
and proprietary material and information and are intended only for the use of 
the intended recipient(s). If you are not the intended recipient, you are hereby 
notified that any review, use, disclosure, dissemination, distribution or copying 
of this message and any attachments is strictly prohibited. If you have received 
this email in error, please immediately notify the sender and destroy this e-mail 
and any attachments and all copies, whether electronic or printed.
Please also note that any views, opinions, conclusions or commitments expressed 
in this message are those of the individual sender and do not necessarily reflect 
the views of Fortinet, Inc., its affiliates, and emails are not binding on 
Fortinet and only a writing manually signed by Fortinet's General Counsel can be 
a binding commitment of Fortinet to Fortinet's customers or partners. Thank you. ***

---

From: Yoshifumi Nishida <[email-masked]>
Date: Thu, 1 Aug 2013 12:15:50 -0700

Hi folks,

Since I couldn't attend the meeting, I might miss something, but anyway..
For (2), we have SCTP which already has similar feature for ADD_ADDR.
It's well designed and has been used for a while. And RFC5061 is PS.
I'm wondering how MPTCP is vulnerable compared to SCTP and how much
protection we'll need.

Thanks,
--
Yoshifumi

---

From: Roberto Peon <[email-masked]>
Date: Fri, 2 Aug 2013 08:13:37 +0200

Similar vulnerabilities exist for SCTP.
When SCTP was defined these attacks were far more theoretical than the
attacks we're seeing done today.

Analogies about jumping off of bridges because someone else did come to
mind... :)
-=R