forked from obonaventure/mptcp-bib
-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathprotocol.tex
62 lines (38 loc) · 6.67 KB
/
protocol.tex
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
The first phase of the work in the IETF MPTCP working group has been focussed on the production of several documents. The architectural guidelines are specified in \cite{rfc6182}. This document served as a reference for the work in the IETF working group. The main design decision was that Multipath TCP assumes that the communicating hosts have different addresses and that these addresses are used to identify the flows. The main requirements listed in this document were :
\begin{itemize}
\item \emph{Improve Throughput}: Multipath TCP MUST support the concurrent use of multiple paths. To meet the minimum performance incentives for deployment, a Multipath TCP connection over multiple paths SHOULD achieve no worse throughput than a single TCP connection over the best constituent path.
\item \emph{Improve Resilience}: Multipath TCP MUST support the use of multiple paths interchangeably for resilience purposes, by permitting segments to be sent and re-sent on any available path.
\end{itemize}
In addition, \cite{rfc6182} lists several compatibility goals that include compatibility with existing applications that use the socket API and compatibility with the network including the middleboxes that it could contain.
The security requirements were discussed in more details in a separate document \cite{rfc6181}. This document defines the flooding attacks and the hijacking attacks that were considered for the initial design of Multipath TCP.
The detailed specification for the Multipath TCP protocol extension may be found in \cite{rfc6824}. This specification is being updated to include in the revised specification the lessons learned from the utilisation of Multipath TCP in the global Internet \cite{draft-ietf-mptcp-experience}. Several of the design choices for the protocol and its implementation in the Linux kernel are discussed in \cite{Raiciu_Hard:2012}. The revised specification \cite{draft-ietf-mptcp-rfc6824bis} includes several improvements such as a modified \texttt{ADD\_ADDR} option that includes a HMAC and an option for the RST segments \cite{draft-bonaventure-mptcp-rst}.
A companion document discusses the security risks and possible attacks with Multipath TCP and how the identified attacks
could be mitigated~\cite{draft-ietf-mptcp-attacks}. The recent
modification of the \texttt{ADD\_ADDR} option is a result of this work.
The standard congestion congestion scheme chosen by the MPTCP working group for Multipath TCP is described in \cite{rfc6356}. This congestion control scheme was first proposed and evaluated in \cite{Wischik_Design:2011}.
One of the initial design choices of Multipath TCP was to be as compatible as possible with the existing applications that interact with TCP through the socket interface. Still, \cite{rfc6897} describes some basic extensions to the socket API to enable applications to notably disable Multipath TCP.
\subsection{Protocol extensions}
Several extensions to Multipath TCP have been proposed within the IETF MPTCP working group.
TCP Fast Open is one of the last TCP extensions that has been added to TCP. Barre et al. discuss
in \cite{draft-barre-mptcp-tfo} how to support TFO within Multipath TCP and report their experience in implementing TFO in the Multipath TCP implementation in the Linux kernel.
To cope with some forms of denial of service attacks, various TCP servers rely on syncookies. This approach enables them to respond to \texttt{SYN} segments without maintaining any state on the server. State is only created upon reception of a valid third \texttt{ACK} segment. With Multipath TCP, it is more difficult to enable servers to operate without maintaining state given the keys exchanged in the \texttt{MP\_CAPABLE} option. \cite{draft-paasch-mptcp-syncookies-00} analyses this problem and proposes a new \texttt{MP\_CAPABLE\_EXT} option to cope with this problem.
Single-path TCP uses the timestamp option defined in RFC1323 to estimate round-trip-times and more importantly to protect TCP against problems that could occur when a connection sends data
quickly and sequence numbers wrap. For this usage, RFC7323, requires all TCP segments to carry a timestamp option. With
Multipath TCP, the second utilisation of the timestamp option is
void since Multipath TCP uses 64 bits sequence numbers that protect against problems when the 32 bits sequence numbers wrap. Requiring a timestamp option in all segments is a waste of space
in the limited TCP header. \cite{draft-bonaventure-mptcp-timestamp} proposes a different
type of timestamp option for Multipath TCP.
The extensibility of TCP is limited by the difficulty of adding new options in the TCP header that cannot be longer than 64 bytes. \cite{draft-paasch-mptcp-control-stream} proposes a different approach that uses one flag in the DSS option to
indicate whether such an option maps regular data or control information.
Several researchers have analysed the security of Multipath TCP
and proposed different solutions to improve its security.
Diez et al. propose in \cite{Diez_Security:2011} to use hash chains to secure the establishment of subflows. Instead of exchanging keys to secure only the establishment of subflows, \cite{draft-paasch-mptcp-ssl} assumes that an application layer protocol like SSL, TLS or ssh will negotiate keys to authenticate and encrypt the data. In this case, a better
approach is to derive the keys used by Multipath TCP to authenticate the new subflows for the keys exchanged by the
application level protocol \cite{draft-paasch-mptcp-ssl}.
\cite{draft-bonaventure-mptcp-tls} goes one step further by
proposing MPTLS, a close integration of TLS and Multipath TCP.
In some environments, attacks are not a concern. In these environments, generating random keys for each Multipath TCP
connection can limit performance. \cite{draft-paasch-mptcp-lowoverhead} proposes a small modification to Multipath TCP that does not use random keys
to authenticate the establishment of subflows.
\subsection{Interactions with other protocols}
In several use cases, such as datacenters, the selection of the best paths for the subflows that compose a Multipath TCP connection is an important decision. The current IETF RFCs do not manadate any path selection mechanisms. Proposed techniques include random selection with ECMP \cite{Raiciu_Datacenter:2011}, modifying the hash function used by ECMP \cite{Detal_Revisiting:2013} is used, or using other fields like the TTL to influence the path as proposed in \cite{Kabbani_Flowbender:2014}. Another approach is to develop a signalling protocol that enables the hosts to query the network for the paths to be used to reach a specific destination. Krupakaran et al. propose in \cite{Krupakaran_Optimized:2015} a layer-2 protocol called Traceflow to exchange this kind of information.