Subject: [multipathtcp] Multipath TCP Security

From: "Ford, Alan" <[email-masked]>
Date: Thu, 11 Nov 2010 08:05:14 -0000

Hi all,

Thank you for your time today in the SAAG session
(http://www.ietf.org/proceedings/79/slides/saag-1.ppt). For further
information about our Multipath TCP developments, the key documents are:

* The MPTCP threat analysis:
http://tools.ietf.org/html/draft-ietf-mptcp-threat-03

* The MPTCP protocol, which includes the documentation of the -02
security proposal as I presented today:
http://tools.ietf.org/html/draft-ietf-mptcp-multiaddressed-02

To reiterate, MPTCP combined multiple TCP connections ("subflows") on
the network into a single MPTCP connection, which is indistinguishable
from standard TCP for the application. MPTCP uses TCP options to convey
signaling information (maximum length of 40 bytes, although many are
already used for other options such as Timestamp or SACK). This
signaling information is used primarily for the exchange of identifying
information at the start of a new subflow to indicate to which MPTCP
connection it belongs, and for indicating what sequence numbers at the
MPTCP connection-level ("Data Sequence Number") map to what sequence
numbers on the subflow.

We recognise the inherent insecurity in a clear-text key exchange at the
start of the connection, but believe that this is closer to our "no
worse than TCP" goal than the previous (-01) proposal of single tokens
always exchanged in the clear. There are additional protections in the
protocol (Data Sequence Number Window; subflow liveness tests) in order
to reduce the chances of a successful attack.

Thanks to those who provided feedback in today's session: One
possibility may be to document a Diffie-Hellman exchange as an extension
via a flag in the SYN exchange that they encodes the exchange in the
first two packets of the payload; another may be to drip-feed a DH
exchange via options during the initial connection (possibly after a
timer in order to see if the connection is long-lived enough to justify
the use of MPTCP).

However, we are also concerned about MPTCP being too heavyweight to
implement, and we would very much welcome any input and suggestions you
may have for a sufficiently lightweight solution to our problem.

Many thanks,
Alan