Internet Engineering Task Force A.Singh Internet Draft University of Bremen Intended status: experimental M. Scharf Expires: January 2011 Alcatel-Lucent Bell Labs August 6, 2010 PayLoad Multi-connection Transport using Multiple Addresses draft-singh-mptcp-plmt-00.txt Abstract The single path transport provided by the Transmission Control Protocol (TCP) can be extended to a multipath transport session for multi-homed end hosts by coupling several TCP connections over multiple interfaces of the end hosts. Payload Multi-connection Transport (PLMT) is a multipath protocol variant that encodes all the control/signaling information in the payload of TCP connections and therefore requires no additional TCP options. PLMT allows for the simultaneous use of the multiple connections over potentially disjoint paths while being mostly backward compatible to single path transport of TCP. PLMT operates as an additional protocol layer between the network stack and the application layer. This document describes PLMT as an example for a multipath mechanism that could possibly be realized entirely in the user-space of an operating system. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on January 6, 2011. Singh, et al. Expires January 6, 2011 [Page 1] Internet-Draft PLMT August 2010 Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Singh, et al. Expires January 6, 2011 [Page 2] Internet-Draft PLMT August 2010 Table of Contents 1. Introduction...................................................5 2. Terminology....................................................6 3. Design Considerations..........................................7 3.1. Goals.....................................................7 3.2. Layered Representation....................................8 3.3. Operation Summary.........................................8 3.4. Compatibility............................................11 3.5. Advantages and Drawbacks of PLMT.........................11 4. PLMT Protocol.................................................16 4.1. Session Initiation.......................................16 4.2. Exchange of PLMT Signaling Over the PLMT Control Channel.16 4.2.1. Establishment of the Control Connection.............16 4.2.2. PLMT Capable Messages...............................17 4.2.3. Further Usage of the Control Connection.............19 4.2.4. Discussion of Control Connection Failure Cases......20 4.3. PLMT Data Connection Setup and Operation.................20 4.3.1. Guidelines for selection of a Signature.............21 4.3.2. Bundling of Initial Connection to the Control Connection in Parallel Setup...............................21 4.3.3. Bundling of Initial Connection to the Control Connection in Late Setup...................................23 4.4. Additional Subflow Connections Initiation and Operation..24 4.4.1. Address Advertisement...............................24 4.4.2. Subflow Connection Setup............................25 4.4.3. TLV Encoding of Data Segments.......................26 4.4.4. Data Acknowledgments................................26 4.5. Other Aspects............................................27 4.5.1. Congestion Control..................................27 4.5.2. Path Management and Scheduling......................28 4.5.3. Closing Connections and Sessions....................28 5. Interaction with Middleboxes..................................28 5.1. Middleboxes that Translate Address/Ports.................29 5.2. Middleboxes that Manipulate TCP Options..................29 5.3. Middleboxes that Parse Content...........................29 5.4. Middleboxes that Change content..........................30 6. Security Considerations.......................................30 6.1. Reappearance of Signature in Application Data...............30 6.2. Resilience against Malicious Attacks........................31 7. Open Issues...................................................31 8. IANA Considerations...........................................31 9. Conclusion....................................................32 10. References...................................................32 10.1. Normative References.......................................32 10.2. Informative References.....................................32 Singh, et al. Expires January 6, 2011 [Page 3] Internet-Draft PLMT August 2010 11. Acknowledgments..............................................33 Singh, et al. Expires January 6, 2011 [Page 4] Internet-Draft PLMT August 2010 1. Introduction The objective of a multipath transport mechanism is to allow the simultaneous use of multiple connections over multiple paths. A multipath transport mechanism is expected to be beneficial since it enhances the network resource utilization and since it provides resilience to node failures in the network [5]. One key mechanism that aims to provide multipath transport is Multipath TCP (MPTCP). MPTCP enables multipath transport by utilizing multiple addresses of the end host to establish multiple paths (subflows) for a TCP connection [6]. MPTCP extends the standard Transmission Control Protocol (TCP) [2] to add the multipath capability and uses several new TCP options to encode control/signaling information. Another multipath transport solution, MCTCP [9] uses the new TCP options only during connection setup to transport signaling information. Afterwards the additional signaling information is sent together with the application data in the payload using a type- length-value (TLV) framing format. This document presents the Payload Multi-connection Transport (PLMT) protocol design as a further alternative multipath transport mechanism. PLMT also uses a type-length-value (TLV) framing format to send application data and control/signaling information. However, in order to transmit control/signaling information; PLMT does not use new TCP options, unlike other multipath transport solutions. Instead, PLMT sets up a control connection to a well-known port for the signaling information exchange, and it uses payload encoding over standard TCP connections. The control connection can either be set up before starting the data transport, or afterwards. In either case, it is possible to implement the PLMT signaling without changing the network stack. Each of the multiple PLMT connections is a standard TCP connection that transports TLV encoded data segments and that are coupled together to the PLMT session. Therefore, PLMT is easily deployable and extensible. PLMT is also transparent to applications and offers reliable transport similar to a standard TCP connection. PLMT is also mostly backward compatible to single path standard TCP. By design, PLMT robustly operates in environments with middleboxes that prevent the use of new TCP options. But the use of out-of-band signaling also comes at some cost concerning complexity, fall-back options, and security. However, as outlined in this document, PLMT is designed to minimize these risks and is rather robust. This document presents PLMT and discusses both the advantages and drawbacks of its design. Singh, et al. Expires January 6, 2011 [Page 5] Internet-Draft PLMT August 2010 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [1]. This document uses the terminology defined in [5][6], though some of the terms are re-defined. Session: A connection over which an application can communicate between two hosts. For an application, there is a one-to-one mapping between a session and the socket. If a session includes only the initial connection, it is almost identical to a standard TCP connection. PLMT Control Port: A port allocated to accept the PLMT control connections. PLMT Layer: A protocol layer implementing the multi-connection capability of the PLMT. It can for instance be realized in the user space of an operating system. Initial Connection: A TCP connection established by an application request. If both ends are PLMT capable, the first subflow uses this connection. Additional Subflow Connection: A new TCP connection established for a subsequent subflow. Control Connection: A TCP connection that is established to the PLMT Control Port. The IP addresses are identical to the Initial Connection. PLMT Data Segment: The segmented application data with TLV header. Active Opener: Refers to the TCP client for a Session with PLMT Layer. Passive Opener: Refers to the TCP server for a Session with PLMT Layer. Legacy End-host: Refers to a host without PLMT Layer. Token: A 64-bit number that is unique on a host. Signature: A long bit pattern that is used to identify PLMT messages inside TCP connections. The length is 16 byte (128 bit). It MUST be Singh, et al. Expires January 6, 2011 [Page 6] Internet-Draft PLMT August 2010 selected in a way such that it is unlikely to occur in application protocols. Guidelines how to determine a Signature are explained in section 4.3.1. . Session Sequence Number: The sequence number of a byte inside a byte stream of a session, determined by the PLMT Layer. 3. Design Considerations This section gives a high-level overview of PLMT's design. 3.1. Goals Important design assumptions and goals of the PLMT design are: o No change of network stack: PLMT is designed to minimize the impact on the network stack implementation. The signaling can be completely implemented in the user-space of an operating system. o Backward compatible: The PLMT should be backward compatible to standard TCP. A single connection PLMT should be exactly similar to the standard TCP connection. As long as only one connection exists, it is not necessary to use TLV framing on that connection. o Co-existence with standard TCP connections: A PLMT capable end host must be able to differentiate between PLMT connections and regular TCP connections. This is crucial, since PLMT connections use TLV encoding. o Multihomed and multiaddressed end hosts: PLMT assumes that for the establishment of multiple connections at least one of the end hosts must be multihomed and multiaddressed. o Middlebox compatibility: PLMT should be compliant to the vast majority of middleboxes, such as NAPT middleboxes and firewalls. Therefore, PLMT should not rely on TCP extensions. PLMT should also allow a middlebox to identify that a host establishes PLMT connections, and prevent this. Singh, et al. Expires January 6, 2011 [Page 7] Internet-Draft PLMT August 2010 o Transparency: PLMT should be transparent to the legacy application i.e., it should provide the same API and services (of the standard TCP) to the application. 3.2. Layered Representation PLMT operates as an additional protocol layer (shim layer) between the application layer and the transport layer. It is designed to be transparent to both higher and lower layers and to be implemented in the user space. It can be used by legacy applications without any changes. Figure 1 illustrates this layering. +-------------------------------+ | Application | +-----------------------------+ +-------------------------------+ | Application | | PLMT | +-----------------------------+ +---------------+---------------+ | TCP | | TCP | TCP | +--------------+--------------+ +---------------+---------------+ | IP | | IP | IP | +--------------+--------------+ +---------------+---------------+ Figure 1 Comparison of Standard TCP and PLMT Protocol Stacks 3.3. Operation Summary This section gives an outlook to the overall high-level operation of PLMT. Figure 2 depicts a simple scenario to illustrate the basic PLMT operation. A detailed PLMT protocol specification and operation description is provided in section 4. o A legacy application, unaware of the presence of PLMT will initiate a standard TCP connection by opening a TCP socket for a Session. PLMT-aware applications MAY use a new application interface [8] to control the functioning of PLMT. o The PLMT Layer then manages the connection establishment of Initial Connection, Control Connection and additional Subflow Connections. o In order to enable PLMT, the Active Opener opens a PLMT control connection to a well-known port at the Passive Opener. The control connection is used to determine whether the remote end supports PLMT, and to exchange the necessary control information such as the Tokens. The Control Connection, as well Singh, et al. Expires January 6, 2011 [Page 8] Internet-Draft PLMT August 2010 as Subflow Connections, are established in the standard TCP way by the PLMT Layer. o A node may either set up a Control Connection before or in parallel to the setting up of the Initial Connection (refer Figure 2). Alternatively, it may first use the Initial Connection and decide later to open the Control Connection. The latter case is discussed in section 4.3.3. . The control connection must be set up using the same IP source and destination addresses like the Initial Connection, and use the PLMT control port. If the setup of the Control Connection fails, PLMT will not be enabled and fall back to standard TCP. o If the Passive Opener supports PLMT and TLV transport is successfully enabled, the Initial Connection will use a TLV framing for data transmission. Then, the Initial Connection is also termed first Subflow Connection. The setup of the TCP connections between two hosts A and B is illustrated in Figure 2. PLMT signals the use of TLV encoding by sending the Signature in the payload of the TCP byte stream. The Signature is a long bit pattern that is selected in such a way that it is unlikely to occur in a TCP connection not using PLMT. Furthermore, Tokens are used to verify that the Initial and Control Connection originate indeed at the same hosts. A detailed analysis of the security implications of PLMT and the resulting very small risk of false positives when detecting its connections are provided in section 6. . o If multiple interfaces are present, PLMT can establish multiple Subflow Connections to allow data transport over multiple paths. Once TLV encoded data transport is activated, a Session level data sequence number is used for in-order delivery of the Data Segments over multiple Subflow Connections. The PLMT Layer manages the multiple interfaces and connections and delivers the packets over the different connections. At the receiver, the PLMT Layer reassembles the byte stream and transparently delivery them to the application. o As the Subflow Connections are standard TCP connections, they are terminated as a regular TCP connection with the 4-way FIN handshake. The Session is terminated with the termination of the last subflow. Singh, et al. Expires January 6, 2011 [Page 9] Internet-Draft PLMT August 2010 End-host A End-host B --------------------------- --------------------------- Address A1 Address A2 Address B1 Address B2 ------------ ------------ ------------ ------------ | | | | | (Initial Connection setup) | | |---------------SYN----------------------->| | |<------------SYN/ACK----------------------| | |---------------ACK----------------------->| | | | | | | (Control Connection setup) | | |~~~~~~~~~~~~~~~SYN~~~~~~~~~~~~~~~~~~~~~~~>| | |<~~~~~~~~~~~~SYN/ACK~~~~~~~~~~~~~~~~~~~~~~| | |~~~~~~~~~~~~~~~ACK~~~~~~~~~~~~~~~~~~~~~~~>| | | | | | | (Token exchange over Control Connection | | | as detailed in Figure 3) | | |~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~>| | |<~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| | | | | | | Signature+Token | | |----------------------------------------->| | | Signature+Token | | |<-----------------------------------------| | | | | | | (TLV-encoded Data Segments | | | over the Initial Connection) | | |----------------------------------------->| | |<-----------------------------------------| | | | | | |(Address Exchange over the Control or Initial Connection)| | | | | | (Additional Subflow Connection setup (TCP)) | |==========================SYN===========================>| |<=======================SYN/ACK==========================| |==========================ACK===========================>| | | | | | (Signature and TLV-encoded Data Segments | | over the Subflow Connection) | |========================================================>| |<========================================================| | | | | | Figure 2 PLMT Connections Establishment in case that the Control Connection is set up in parallel to the Initial Connection Singh, et al. Expires January 6, 2011 [Page 10] Internet-Draft PLMT August 2010 3.4. Compatibility PLMT uses the Control Connection to detect whether a Passive Opener indeed supports its operation. If the setup of the Control Connection fails, it falls back to standard TCP transport, and does not use any additional PLMT signaling. PLMT is thus compatible with legacy TCP stacks and is able to detect them. The PLMT Layer is transparent to applications, i. e., it is compatible with legacy applications unaware of PLMT. The PLMT protocol does not require extensions of the TCP protocol and reuses the standard TCP mechanisms for the reliable, in-order operation of its connections. PLMT uses its own frame format based on the TLV encoding to send the application data and the control information. The use of TLV encoding is known from other TCP-based protocols such as TLS [3]. Therefore, PLMT should pass most middleboxes, in particular all middleboxes that would block TCP options. An exception is the case of middleboxes that parse the byte stream and block TLV content. In this case, PLMT transport may fail in certain cases, as discussed in section 5.3. and 5.4. . The signaling and message transport of PLMT can be implemented on a host without changing the network stack, i. e., as a library in the user space. With a combination of scheduling and rate shaping mechanisms, the PLMT Layer can also try to emulate congestion control coupling algorithms such as [4]. In this case, it may be possible to implement PLMT entirely in the user space of a host. 3.5. Advantages and Drawbacks of PLMT PLMT follows the principles outlined for a multipath transport solution based on TCP in [5]. PLMT uses the TCP payload to transport signaling messages and requires no new TCP options. Thus, PLMT brings along all advantages of the payload encoding mechanism (cf. [9]): o PLMT does not use any TCP option to setup its connections. Therefore, it might be possible to implement PLMT entirely in the user-space, which would significantly facilitate deployment of PLMT. o In addition, the signaling messages are not constrained with the limited size of the TCP options, and PLMT does not consume further option space in SYN segments. Singh, et al. Expires January 6, 2011 [Page 11] Internet-Draft PLMT August 2010 o PLMT does not modify TCP and is therefore compatible with many middleboxes, especially ones which do not allow unknown TCP options to get through, or ones that re-write the TCP options. o Middleboxes can very easily identify the setup of a PLMT Control Connection due to the use of a well-known port. If a middlebox on the path of the Initial Connection wants to prevent the use of multipath transport, it can simply block the connection setup to that port. Then, multipath transport will not be used for the corresponding connection. PLMT is developed as an example for a multipath transport protocol that does not use any new TCP option, or other TCP extensions, and that is still backward compatible. Still, due to the use of payload encoding and an out-of-band control channel for the exchange of control information, a number of issues arise. The following text discusses these problems (some of which may exist for other multipath transport solutions as well) and possible solutions. o PLMT opens a Control Connection per PLMT Session, i. e., an additional TCP connection. If a host opens Control Connections for every short TCP-based transfer, this would result in a large number of additional connection setups, which would consume bandwidth, processing resources, and port numbers. The worst case is that a PLMT Control Connection is set up for every Initial Connection, but additional subflows are never established. Then, the number of TCP connection doubles without any performance benefit. As a remedy, PLMT can also first use an Initial Connection without Control Connection, and try to establish the Control Connection after some time. Once PLMT capability is detected and additional signaling information has been exchanged, the Initial Connection as well as potential additional Subflow Connections can then be used to transport PLMT TLV-encoded data traffic. This mechanism avoids needless Control Connection setups for short transfers. o PLMT needs a well known, dedicated port for the Control Connections, similar to TLS [3]. If PLMT is enabled on a host, it may try to establish Control Connections to that port for all communication partners. Even if heuristics can be used to learn whether servers are supporting PLMT, or not, and thus Singh, et al. Expires January 6, 2011 [Page 12] Internet-Draft PLMT August 2010 reduce the connection setup attempts, numerous legacy hosts in the Internet will receive connection setups on that port. To legacy systems, this may look similar to a SYN flooding attack. As a counter measure, network administrators may configure firewalls to block the PLMT Control Port, which prevents the usage of the protocol once it is more widely deployed. o Middlebox that transparently change the length of content are a problem for multipath transport protocols. When using TLV- based transport, PLMT could detect such middleboxes by using a checksum, or by observing broken TLV headers, and try retransmissions. However, if the byte stream is transparently changed before switching to TLV encoding, difficulties can arise. For instance, the Signature may not be at the position where it is expected. In this case, PLMT cannot enter the TLV mode, but it can also not necessarily fall back, and it may either have to cancel that transfer by closing the PLMT Session, or, in the worst case, it may even deliver corrupted data to an application. o PLMT delays the setup of connections in various scenarios. If an Active Opener wants to use TLV encoding immediately on the Initial Connection, it must await the setup of the control connection. If there is no response (no SYN/ACK), the Active Opener may either retransmit the SYN, i. e., wait for a longer time, or give up. Then, multipath transport is not possible. In all cases, there is at least a small delay before the data transport over the Initial Connection can start. If the Active Opener decides to setup the Control Connection later, this delay is avoided. But then the Active Opener must stop data transmission after the setup of the Control Connection, in order to ensure a safe exchange of tokens, which interrupts the data transport. o The Passive Opener has a significant processing overhead due to PLMT. First and most obviously, there is the overhead of maintaining the Control Connections, which can be significant for a highly-loaded server with thousands of connections. o The second and trickier challenge is the distinction between legacy TCP connections and connection originating from hosts Singh, et al. Expires January 6, 2011 [Page 13] Internet-Draft PLMT August 2010 that use PLMT. PLMT Subflow Connections are characterized by the presence of the Signature in the byte stream. This means that the PLMT layer must accept all incoming connections, parse for the presence of a valid Signature, and then decide whether it is a legacy connection or a connection transporting PLMT content with TLV encoding. The parsing for Signatures is difficult if an incoming connection sends less data than the length of the Signature. If the first bytes match a valid Signature, or if no bytes are received at all, the PLMT layer must wait for the arrival of further data, or time out, e. g., if the corresponding application does not send enough bytes. If it times out, the only safe option is to close the connection. This means that the PLMT layer may reject not only PLMT connections that suffered from retransmissions within the first byte, but also valid TCP connection setup from legacy stacks if they happen to (partly) match a Signature. If the delayed setup of Control Connections is allowed, the parsing overhead is even larger. The PLMT layer must then parse all established TCP connections for all valid Signatures at the negotiated positions in the byte stream, which may also require temporary buffering of data, if only parts of a valid Signature are received, or if the rest of the first TLV message is missing. In all cases, the delivery of data to applications may be delayed. o On a Passive Opener, the PLMT layer has to accept incoming connections in order to parse the payload, before it can hand over the connection to the application. This can delay data delivery, and also may result in inconsistent views when the connection is indeed established. Further studies are needed to understand whether the delay of connection establishment as seen by applications, which does not occur in case of option- based multipath protocols, could break existing applications. o Due to the processing and buffer overhead required to identify connections by payload parsing, the Passive Opener is vulnerable to a Denial-of-Service (DoS) attack: An attacker can open a large number of Control Connections, which will consume resources on a server and slow down data delivery on other connections. Passive Openers can reduce the risk by only accepting Coupled Connections from source IP addresses that Singh, et al. Expires January 6, 2011 [Page 14] Internet-Draft PLMT August 2010 originate also an existing connection, but this does not offer a complete protection, in particular if an attacker is sitting behind a large NAPT middlebox. Another remedy is to limit the amount of allowed Control Connections, but then other users of PLMT suffer from the effects of Control Connection setup failures. o PLMT must exchange the Token information in the payload of the Initial Connection, in order to verify that an Initial Connection and a Coupled Connection indeed have the same endpoints. This requires the transport of a TLV-encoded message. As a consequence, unlike other multipath transport protocols [6] [9], PLMT cannot fall back to a backward compatible byte stream transport if a middlebox on the path should block the TLV transport. o If there is a single-homed Active Opener and a multi-homed Passive Opener, PLMT cannot indicate to the Active Opener that multipath transport may make sense, i. e., that it could establish a Control Connection, before that connection actually exists. Other multipath transport protocols [6] [9] have a signaling mechanism for this. PLMT can only detect this situation if it blindly opens Control Connections in all cases. o If a middlebox does not intercept the information on the Control Connections, or if it does not know the Signature by other means, it cannot determine if a given TCP connection transports PLMT data, or not. If a middlebox is not on the path of the Control Connection, it cannot prevent the usage of TLV encoding. For the latter case, a possible remedy would be that Additional Subflow Connections use another well-known port, which could then be blocked. o A Passive Opener can accept with a certain, small probability erroneously a connection from a legacy host as PLMT Subflow Connection, if an application happens to send a bit pattern that is identical to one of the valid Signature of that Passive Opener, plus the valid Tokens. This may either happen if the first bytes of a standard TCP connection match an active Signature, or if a corresponding bit pattern is present exactly at the same sequence position as negotiated on a control Singh, et al. Expires January 6, 2011 [Page 15] Internet-Draft PLMT August 2010 connection. In that case, TLV-encoded content will be injected into a legacy connection, which will be corrupted. Due to the length of the Signature, this error probability is very small. o An attacker can abuse PLMT to break legacy TCP connections to a PLMT-enabled Passive Opener, if it is sitting behind the same NAPT middlebox like another Active Opener, as already explained. In this case, the attacker can open multiple Control Connections, not only as a DoS attack, but also to attack other users. With a very small probability, the Signature and Tokens negotiated over the Control Connection will match another connection. If so, TLV content will be injected on that connection, and it will break, too. Again, the success probability of this attack is very small. In summary, PLMT is a multipath protocol that is designed as a payload-only solution. It is useful for controlled and trusted environments, for networks with middleboxes that affect the use of TCP options, and for use cases where it is impossible to change the network stack. 4. PLMT Protocol This section details the operations of PLMT protocol. 4.1. Session Initiation A session initiation begins with an application request for a new TCP connection, upon which the PLMT protocol performs the following actions. 4.2. Exchange of PLMT Signaling Over the PLMT Control Channel A node MAY setup a TCP Control Connection before or in parallel to the setting up of the Initial Connection (Parallel Setup), or it MAY set up the Control Connection at a later point in time (Late Setup). Both variants have advantages and drawbacks and affect the way how the Initial Connection is used. 4.2.1. Establishment of the Control Connection The Active Opener Must set up the TCP Control Connection using the same source and destination IP addresses, and it MUST be destined to the PLMT Control Port. If the TCP connection is successfully set up, this is a first indication that the Passive Opener indeed supports Singh, et al. Expires January 6, 2011 [Page 16] Internet-Draft PLMT August 2010 PLMT. In order to exclude the case that another service is accidentally running on that port, PLMT support is further verified by PLMT Capable Messages. A Passive Opener SHOULD verify whether there are already established TCP connections from the same Active Opener, in order to reduce the vulnerability to DoS attacks. 4.2.2. PLMT Capable Messages If the Control Connection is set up successfully, the two hosts can be expected to have an operational PLMT Shim Layer. The End-host MUST exchange the Tokens as shown in Figure 3 for further validation of the existence of PLMT Shim layer and the willingness of the Passive Opener to use PLMT. Note that at this stage of the signaling the Passive Opener cannot safely identify the Initial Connection that this Control Connection shall be associated with. End-host A End-host B --------------------------- --------------------------- Address A1 Address A2 Address B1 Address B2 ------------ ------------ ------------ ------------ | | | | | (Control Connection setup (TCP)) | | |~~~~~~~~~~~~~~~SYN~~~~~~~~~~~~~~~~~~~~~~~>| | |<~~~~~~~~~~~~SYN/ACK~~~~~~~~~~~~~~~~~~~~~~| | |~~~~~~~~~~~~~~~ACK~~~~~~~~~~~~~~~~~~~~~~~>| | | | | | | (PLMT Capable Signaling) | | |~~~~~~~~~~PLMT Token Indication~~~~~~~~~~>| | |<~~~~~~~~PLMT Token Confirmation~~~~~~~~~~| | | | | | Figure 3 PLMT Signaling Exchange over the Control Connection The frame format of the PLMT Token Indication message is shown in Figure 4. The Token is a unique number for a host and is used to identify a particular PLMT Session. To make it harder for an attacker to guess the Token by brute-force method, a 64-bit Token SHOULD be generated randomly [7]. Furthermore, the PLMT Token Indication message includes the Signature of the Active Opener, as well as the byte position in the Initial Connection where this Signature will be present on the Initial Connection. The byte position is provided in the Token Indication in order to reduce the parsing overhead of a Passive Opener, and the risk that an attacker can hijack a connection by negotiation of a large number of Signatures and Tokens with a Passive Opener. This implies that an Singh, et al. Expires January 6, 2011 [Page 17] Internet-Draft PLMT August 2010 Active Opener can only send data up to this position before it receives a PLMT Token Confirmation message. In case of a Parallel connection setup, this position is set to 0, as the Signature is set at the beginning of the connection. As a side note, the whole mechanism can fail if the bytestream length is affected by a middlebox. 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +---------------+--------------------------------+--------------+ |Kind=TOKENIND | Length=32 | reserved | +---------------+--------------------------------+--------------+ : Active Opener Signature (in total 16 byte) : +---------------------------------------------------------------+ : Active Opener Token (in total 8 bytes) : +---------------------------------------------------------------+ | Signature offset (4 byte) | +---------------------------------------------------------------+ Figure 4 PLMT Token Indication message (sent via the Control Connection) As a response to the reception of the PLMT Token Indication from the Active Opener, the Passive Opener SHOULD either send back an own Token in a PLMT Token Confirmation message shown in Figure 5, or it SHOULD immediately close the Control Connection instead. This message also echoes back the Active Opener's Token, in order to verify that the reply is indeed sent by a PLMT layer. 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +---------------+--------------------------------+--------------+ |Kind=TOKENCONF | Length=36 | reserved | +---------------+--------------------------------+--------------+ : Passive Opener Signature (in total 16 byte) : +---------------------------------------------------------------+ : Passive Opener Token (in total 8 byte) : +---------------------------------------------------------------+ : Echo of Active Opener Token (in total 8 bytes) : +---------------------------------------------------------------+ Figure 5 PLMT Token Confirmation message (sent via the Control Connection) Singh, et al. Expires January 6, 2011 [Page 18] Internet-Draft PLMT August 2010 Upon reception of that message, the Active Opener MUST first verify the validity of the message (in particular the echoed Token). If the message is valid, it MUST send the Signature provided from the Passive Opener at the indicated byte position in the Initial Connection, directly followed by a PLMT Token Message. Afterwards, TLV framing has to be used. The Passive Opener must similarly react: After having received the Signature and Token on an Initial Connection, the Passive Opener MUST send the Active Opener's Signature and a PLMT Token Message over the Initial Connection, too, and use TLV framing afterwards. Thus, after having sent the Signature, the Active Opener must parse all incoming bytes on the Initial Connection for the Signature of the Passive Opener, in order to detect the begin of TLV transfer in the reverse direction. In the simplest case, the Passive Opener has not sent any data in the meantime, i. e., the Signature is received immediately. However, other cases are possible, too. Note that this method is inefficient and also has a very small risk of false positives, as it requires byte-wise parsing of the byte stream. Yet, the fundamental problem is that the Passive Opener cannot provide a byte offset for the Signature over the Control Channel during the PLMT Capability Signaling phase, as the Initial Connection and the Control Connection cannot be associated at that time. As an optimization, the Passive Opener could provide a bytestream offset by a separate signaling message once it has received the Token on the Initial Connection, but PLMT cannot rely on this, as the Control Connection could fail or stall in the meantime and then the PLMT session would not be in consistent state. The PLMT signaling exchange is designed to reflect an atomic transaction. 4.2.3. Further Usage of the Control Connection The Control connection is only needed to exchange token information and to verify the association with the Initial Connection. After the PLMT capability exchange has been completed, the control connection is actually not needed any more, and it MAY be closed. All further control information, such as additional addresses etc., can also be exchanged over the Subflow Connections, by corresponding TLV messages. However, the Control Connection MAY also be kept established and used for further PLMT signaling. In particular, it could be useful to exchange address information over the Control Connection instead of the Subflow Connections. This would enable future NAPT helper for the PLMT protocol that could try to translate private to public addresses. A detailed discussion of this is outside the scope of this document. Singh, et al. Expires January 6, 2011 [Page 19] Internet-Draft PLMT August 2010 4.2.4. Discussion of Control Connection Failure Cases A failure to setup a Control Connection is an indication that the other end host does not have a PLMT Layer, or that middleboxes do not allow the establishment of a PLMT Control Connection. An Active Opener MUST await the successful PLMT capability exchange on the Control Connection before starting to send the Signature and TLV encoded content. An Active Opener MAY also give up after a certain waiting time. Then, it MUST close the Control Connection, and use backward compatible bytestream transport on the Initial Connection. The PLMT capability exchange requires a single exchange of messages on the Control Connection only. If the Connection fails afterwards, all control information can be exchanged over Subflow Connections. If the control connection fails and the Active Opener does not receive the Token Confirmation message, without that the Passive Opener detects this, there may be a synchronization mismatch and the Passive opener may inject a Signature and a Token to the Initial Connection even if this is not expected by the Active Opener. In order to avoid data corruption, the Active Opener could parse all incoming data for the Signature after failure of a Control Connections, but this may increase the processing overhead. If a Control Connection fails after the exchange of the tokens, PLMT could in principle continue to operate, since TLV encoded data can be transported over the established Subflow Connections, and since the Signatures and Tokens are already known. 4.3. PLMT Data Connection Setup and Operation PLMT provides two modes of operation, which differ by the time when the control connection is established: Parallel Setup and Late Setup. The Parallel Setup is significantly simpler for a Passive Opener, as Signatures are sent in the first bytes of a connection and therefore are simple to identify. But, unfortunately, the setup of a Control Connection for every data transfer with a short duration results in overhead and additional delay without any performance gains. This mode is therefore mainly useful if it is known in advance that a TCP connection will transport a large amount of data. In order to reduce the overhead for short connection, PLMT also allows that the Control Connection is established later than the Initial Connection. In this case, the PLMT Layer on a host MUST not initiate the TLV data encoding before the PLMT capability of the other host has been determined through the Control Connection, (cf. Figure 3). Singh, et al. Expires January 6, 2011 [Page 20] Internet-Draft PLMT August 2010 4.3.1. Guidelines for selection of a Signature To allow for a simple identification of where exactly the TLV encoding inside the byte stream starts, a 128-bit Signature is used, which is used as a delimiter between bytestream and TLV encoding (cf. Figure 6). The Signature is selected by the hosts that must parse it, and MUST be chosen such that collisions with existing application protocols are minimal. Note that it is up to the hosts to decide what Signature to use for different connections The most secure solution is to use a different Signature for every Control Connection, but then the parsing effort is the largest. For performance optimization, the PLMT Layer at a host MAY use the same Signature in more than one connection, but it MUST change the value on a regular basis. 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +---------------------------------------------------------------+ | Signature (16 byte) : +-----------------------------------------------+---------------+ : Signature : +-----------------------------------------------+---------------+ : Signature : +-----------------------------------------------+---------------+ : Signature | +---------------------------------------------------------------+ Figure 6 PLMT Signature (sent on Subflow Connections) 4.3.2. Bundling of Initial Connection to the Control Connection in Parallel Setup The Control Connection is used to determine the PLMT capability of the end hosts. The Initial Connection MUST not transport any data before the Control Connection is established and the PLMT Capability Exchange is completed. If the Control Connection setup or PLMT Capability Exchange fails, then the Initial Connection MUST not transmit data with TLV encoding but the legacy TCP bytestream. Before using TLV encoding, a host must first send the Signature on the Initial Connection as depicted in Figure 7. The first TLV- encoded messages after that delimiter must exchange the tokens to bundle the Initial Connection with the Control Connection, and to verify at both endpoints that the Initial Connection and the Control Connection indeed terminate at the same host. The tokens are exchanged by a Token Indication and a Token Confirmation message. After these messages, both sides are allowed to send other PLMT messages in TLV encoding over the Connection, or to establish Singh, et al. Expires January 6, 2011 [Page 21] Internet-Draft PLMT August 2010 further Subflow Connections. Both Active and Passive Opener must verify the Tokens. If the Tokens do not match the ones exchanged over the control connection, the PLMT session must be closed, as apparently an error has occurred. End-host A End-host B --------------------------- --------------------------- Address A1 Address A2 Address B1 Address B2 ------------ ------------ ------------ ------------ | | | | | (Initial Connection setup (TCP)) | | |---------------SYN----------------------->| | |<------------SYN/ACK----------------------| | |---------------ACK----------------------->| | | | | | | (PLMT Capability of the Other End-host has been | | determined over the Control Connection) | | | | | | (First TLV encoded message exchange | | | over the Initial Connection) | | |---B's Signature + Token B Verification-->| | | | | Token | | | | verif. | |<--A's Signature + Token A Verification---| | Token | | | | verif. | | | | | | | | | (TLV encoded data transport | | | over the Initial Connection) | | |---------------TLV----------------------->| | |<--------------TLV------------------------| | | | | | Figure 7 Bundling of Initial PLMT Subflow Connection and Control Connection for Parallel Setup 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +---------------+---------------------------------+-------------+ |Kind=TOKEN | Length=12 | reserved | +---------------+---------------------------------+-------------+ | Token (8 byte) | +---------------------------------------------------------------+ Figure 8 PLMT Token Verification Message (sent over the Initial Connection) Singh, et al. Expires January 6, 2011 [Page 22] Internet-Draft PLMT August 2010 4.3.3. Bundling of Initial Connection to the Control Connection in Late Setup In order to avoid the setup overhead of control Connections for short-lived transfers, the PLMT protocol MAY establish the Control Connection after data has already been exchanged on the Initial Connection. This document does not describe heuristics when to set up the Control connection. They may take into account factors such as number of bytes transferred, cached information about support of PLMT, or user preferences. A receiver MUST assume that all bytes received on an incoming TCP connection are sent by legacy end system, before a match with a valid Signature is possible. Until then, all data must be passed to the application in unmodified form. Thus, PLMT risks with a very small probability that corrupted data is delivered to an application. Once the Control Connection is established and the PLMT capability information of the end hosts has been exchanged, the Active Opener can send the Passive Opener's Signature and a PLMT Token Verification message over the Initial Connection, at the position in the byte stream that has been advertised over the control channel. The mechanism of token exchange in the payload of the Initial Connection is used to verify that the Initial Connection and Control Connection actually involve the same hosts. End-host A End-host B --------------------------- --------------------------- Address A1 Address A2 Address B1 Address B2 ------------ ------------ ------------ ------------ | | | | | (Initial Connection setup (TCP)) | | |---------------SYN----------------------->| | |<------------SYN/ACK----------------------| | |---------------ACK----------------------->| | | | | | | (Data Segments | | | sent over the Initial Connection) | | |----------------------------------------->| | |<-----------------------------------------| | | | | | | (Control Connection setup (TCP)) | | |~~~~~~~~~~~~~~~SYN~~~~~~~~~~~~~~~~~~~~~~~>| | |<~~~~~~~~~~~~SYN/ACK~~~~~~~~~~~~~~~~~~~~~~| | |~~~~~~~~~~~~~~~ACK~~~~~~~~~~~~~~~~~~~~~~~>| | Singh, et al. Expires January 6, 2011 [Page 23] Internet-Draft PLMT August 2010 | | | | | (TLV-Enabled PLMT Control Signaling | | | sent over the Control Connection) | | |~~~Sign. indic. (A's sign., A's token)~~~>| | |<~~Sign. confirm. (B's sign., B's token)~~| | | | | | | (Message exchange over the | | | Initial Connection) | | |---B's Signature + Token B verification-->| | | | Token | ........|..........................................| verif. | |<--A's Signature + Token A verification---| | Token | | | | verif. | (TLV encoded data transport | | | over the Initial Connection) | | |---------------TLV----------------------->| | |<--------------TLV------------------------| | | | | | Figure 9 Bundling of PLMT First Subflow Connection and Control Connection for Delayed Setup 4.4. Additional Subflow Connections Initiation and Operation 4.4.1. Address Advertisement The Initial Subflow Connection, as well as the Control Connection, is established by the Active Opener. Once TLV encoding is enabled on the Initial Subflow Connection, and it is thus verified that the two end- hosts are PLMT capable, any of the end-hosts MAY initiate further Subflow Connections. PLMT assumes that at least one of the two connection endpoints is multihomed, i. e., has at least two IP addresses. The end-hosts MAY exchange these addresses via the Control Connection or via any Subflow Connection, once TLV transport is enabled. The frame format of advertising and releasing addresses is given in Figure 10 and 11, respectively. 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +---------------+-------------------------------+-------+-------+ | Kind=ADD_ADDR | Length | IPVer | (res) | +---------------+-------------------------------+-------+-------+ | Address (IPv4 - 4 octets / IPv6 - 16 octets) | +---------------------------------------------------------------+ Figure 10 PLMT Add Address Singh, et al. Expires January 6, 2011 [Page 24] Internet-Draft PLMT August 2010 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +---------------+-------------------------------+-------+-------+ | Kind=DEL_ADDR | Length | IPVer | (res) | +---------------+-------------------------------+-------+-------+ | Address (IPv4 - 4 octets / IPv6 - 16 octets) | +---------------------------------------------------------------+ Figure 11 PLMT Remove Address 4.4.2. Subflow Connection Setup For each initiation of an additional Subflow Connection, a new TCP connection is initiated with a three-way handshake (SYN, SYN/ACK, ACK). The Signatures are used by both ends to distinguish Subflow Connections from normal TCP connection, and to detect the start of TLV encoding. If a Subflow Connection is established that shall carry TLV Data Segments, a sender MUST send the Signature first before starting to send TLV Data Segments. In all cases, the first Data Segment after the Signature MUST be a Token Indication (from Active Opener) or Token Confirmation message (from Passive Opener). This setup of an additional Subflow Connection is illustrated in Figure 12. End-host A End-host B --------------------------- --------------------------- Address A1 Address A2 Address B1 Address B2 ------------ ------------ ------------ ------------ | | | | | (TLV encoded Data Segments) | | |----------------------------------------->| | |<-----------------------------------------| | | | | | | (Over Subflow or Control Connection) | |<--------------ADD_ADDR-B2----------------| | | | | | | (Additional Subflow Connection Setup (TCP)) | |***************************SYN**************************>| |<************************SYN/ACK*************************| |***************************ACK**************************>| | | | | |***B's Signature + Token B verification*****************>| | | Token | ........|..........................................| verif. | |<**A's Signature + Token A verification******************| Token | | | | verif. | (TLV encoded data transport | | Singh, et al. Expires January 6, 2011 [Page 25] Internet-Draft PLMT August 2010 | over the additional Subflow Connection) | | |***************TLV**************************************>| | | | | |<**************TLV***************************************| Figure 12 Additional Subflow Connection setup 4.4.3. TLV Encoding of Data Segments TLV encoded Data Segments can be sent on each Subflow Connection. Each Data Segment carries a 64-bit Session Sequence Number. A PLMT- capable host must maintain a Session Sequence Number in addition to the TCP sequence numbers of TCP on a Subflow Connection. 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +----------------+-------------------------------+--------------+ | Kind = DATA | Length=20+n | reserved | +----------------+-------------------------------+--------------+ : Session Sequence Number (8 byte) : +---------------------------------------------------------------+ : Data Segment (n bytes total) | +---------------------------------------------------------------+ Figure 13 TLV encoded Data Segment message Session Sequence Numbers are used to reorder the data inside the PLMT session that arrives over multiple Subflow Connections. The Session Sequence Number is thus similar to the TCP sequence number and identifies each byte of data. Each Data Segment carries the Session Sequence Number, which refers to the byte number of the first byte in the Data segment. Even when a PLMT-capable host is not transmitting TLV data segments, the end host MUST store Session Sequence Numbers for all ongoing TCP connections, in order to be able to deal with late setups of a Control Connection. 4.4.4. Data Acknowledgments In addition to the regular Subflow Connection TCP acknowledgements, session-level Data Acknowledgements are used to cumulatively acknowledge the data received over the different Subflow Connections. A Data Acknowledgement that acknowledges the reception of a Data Segment message includes the next expected byte of Data Segments. In a normal operation, session-level Data Acknowledgements are actually not needed, but certain performance enhancing proxies Singh, et al. Expires January 6, 2011 [Page 26] Internet-Draft PLMT August 2010 or middlebox failures may result in situations in which the acknowledgments on a SubFlow Connection erroneously allows release of data in the sender, even if it is not yet received. The Data Acknowlegdements also include a session-level receive window to correctly perform flow control at session level, and to avoid deadlocks. Since the use of data acknowledgements is only a mechanism to increase robustness, the data acknowledgements SHOULD be sent at bigger intervals of time. It is left for further study how often they should be sent. Another open question is on which of the connections the messages should be sent. 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +---------------+--------------------------------+--------------+ |Kind=SESS_ACK | Length=12 | reserved | +---------------+--------------------------------+--------------+ : Next expected Session Sequence Number (8 byte in total) : +---------------------------------------------------------------+ : Session receive window (8 bytes in total) : +---------------------------------------------------------------+ Figure 14 Data Acknowledgement message 4.5. Other Aspects 4.5.1. Congestion Control One of the goals for having a multi-connection transport solution is to enhance the usage of network resources, commonly known as resource pooling principle. In order to achieve resource pooling, the congestion windows of the different Subflow Connections of the Session should be coupled together. The coupling should lead to transmission of more Data Segments over the less congested connections as compared to the more congested connections. Different congestion control algorithms may be implemented for multipath transport mechanisms to achieve the goals of resource pooling and fairness. One such algorithm is presented in [4]. The algorithm offers a potential solution in the current Internet by controlling the Subflow Connection congestion window increase as a function of the performance of other Subflow Connections of a session. Singh, et al. Expires January 6, 2011 [Page 27] Internet-Draft PLMT August 2010 PLMT could use this algorithm for congestion control as well. If PLMT is entirely implemented in the user space, an alternative algorithm could be used that runs a corresponding scheduler, which uses own estimates for the path characteristics. The design of alternative algorithms for congestion control coupling is beyond the scope of this document. 4.5.2. Path Management and Scheduling The establishment of multiple Subflow Connections to different addresses aims at a better utilization of the network resources. PLMT could use cross-layer information from the network layer for path management. The scheduling of TLV-encoded Data Segments over the different Subflow Connections is based on the local policy. PLMT can use different algorithms to control the splitting of the data stream from the application over the different Subflow Connections. PLMT uses the standard TCP mechanisms for reliable transport of data on its Subflow Connections. The retransmission strategy for lost Data Segments is a local policy. The session sequence number allows lost Data Segments to be sent over another Subflow Connection in addition to the retransmission over the same Subflow Connection. How often a Data Segment is sent over another Subflow Connection is again a design choice of the local policy. 4.5.3. Closing Connections and Sessions A Subflow Connection is a standard TCP connection. To close a Subflow Connection the TCP 4-way FIN handshake mechanism is used. When the Session needs to be closed, it means that all the PLMT Connections need to be closed, including the Control Connection. 5. Interaction with Middleboxes The Internet consists of many different types of middleboxes, some parse the contents of the stream of a TCP connection, rewrite the content of packet headers or rewrite even the payload. For a new multipath transport like PLMT to be successfully deployable, its operation should be understood and tested against such middleboxes. Examples for well-known middleboxes are Network Address and Port Translators (NAPT). PLMT is designed to be compatible with middleboxes that have problems with TCP options. But there are also some problems with other types of middleboxes. Singh, et al. Expires January 6, 2011 [Page 28] Internet-Draft PLMT August 2010 5.1. Middleboxes that Translate Address/Ports Middleboxes that perform Network Address and Port Translations (NAPT) may cause problems for the creation of multiple connections (this is a potential issue for all multipath transport protocols). Hosts behind the NAPT know their local addresses but might not be aware of the global addresses that the NAPT uses. Therefore, the hosts MUST NOT advertise their multiple local addresses to the other host. The host behind the NAPT MAY still be multipath capable and MAY open a PLMT connection to the other host if the other host is also PLMT capable. Over the established PLMT connection, the other host MAY advertise its multiple addresses. These addresses will be used by the host behind the NAPT to open further Subflow Connections. 5.2. Middleboxes that Manipulate TCP Options The multipath solutions that use TCP options field for their operation may suffer from middleboxes that may remove or modify the TCP options. Some middleboxes may even drop packets with unknown TCP options, and this may happen for the connection establishment packets as well. PLMT does not employ any new TCP option and hence it would not be affected by such a middlebox behavior. 5.3. Middleboxes that Parse Content Current middleboxes in the Internet are not aware of multipath transport. Therefore, middleboxes will identify the single Subflow Connection to be a standard TCP connection. The TLV encoding of the payload may confuse the middlebox and may lead the middlebox to stall the connection in case that the middlebox parses the content. If a middlebox blocks TLV encoding, PLMT can try to transmit data over another path. However, PLMT cannot fall back to a mode that does not use TLV transport, since it must send the Signature and tokens in TLV encoding over the Initial Subflow Connection. Middleboxes that want to prevent multipath transport can block connection setups to the well-known port. This prevents the use of multipath transport if a middlebox is both on the path of the Initial Subflow Connection and the Control Connection. A middlebox that is not on the path of the Control Connection cannot safely distinguish normal TCP connections and PLMT Subflow Connections with TLV transport. Singh, et al. Expires January 6, 2011 [Page 29] Internet-Draft PLMT August 2010 5.4. Middleboxes that Change content Middleboxes may also modify the payload and not only the packet headers. All the multipath solutions require a session-level data sequence number to re-order/combine the data stream received over the Subflow Connections. The PLMT design allows detecting such a middlebox behavior by identifying the connection which gets stalled due to undecodable TLV framing. In addition, checksums could be used. The Data Acknowledgements will identify the holes in the session sequence numbers so that a retransmission of the missing segments over other Subflow Connections will be initiated. This allows working around content-modifying middleboxes, unless they are present on all paths. If this type of middlebox is present on the Initial Connection, then the Signature matching may fail. This means that data transport over the Initial Connection may be corrupted, as, e. g., the Signature may be delivered to the application as part of the byte stream. 6. Security Considerations The Signature-based method to identify the setup of a new TLV- enabled data flow has two security issues: First, an application can accidentally generate a bit pattern that is equal to the Signature. Second, due to the use of out-of-band signaling, PLMT's method must be robust against malicious attacks that try to break or hijack PLMT sessions or normal connections. Unlike other multipath transport protocols, it is theoretically possible to attack a normal TCP connection to a PLMT-enabled server, even if it does not use multipath transport. 6.1. Reappearance of Signature in Application Data The Signature (and the tokens) is sent in two different contexts: o A connection which was started as a single legacy TCP connection is later switched to PLMT/TLV-enabled operation. In this case, the Active Opener provides the Session sequence number over the control connection of the last byte that is not TLV encoded. This way, the PLMT Layer of the Passive Opener knows how much user data has been transmitted through the legacy TCP connection and when to expect the Signature. Given the length of the Signature, as well as the following token exchange, it is extremely unlikely that a normal TCP connection is wrongly classified as a Subflow Connection. A similar problem occurs at the Active Opener. Singh, et al. Expires January 6, 2011 [Page 30] Internet-Draft PLMT August 2010 o The Signature can also be present in the first bytes of a new PLMT Subflow Connection, if it is an additional Subflow Connection, or if the Control Connection is established first. In these cases, the Subflow Connection is characterized by the Signature being present in the first bytes of a connection. In case that an application itself opens an additional TCP connection to the same corresponding end host, a problem could occur if the Signature pattern (and follow-up token messages) is contained in the first data packet of the connection. Because of both effects, there is a residual probability that PLMT accepts a connection erroneously, if an application accidentally sends a bit pattern that is identical to the Signature (plus the Tokens), of if an attacker manages to guess the pattern. This probability is very small as the Signature is a long, random bit pattern. This probabilistic approach of a token-based identification is general practice in challenge-response authentication methods, where there is also an extremely small residual probability that an unauthorized (malicious) node guesses the response correctly. 6.2. Resilience against Malicious Attacks One aspect of address-agile multi-path transport mechanisms are possible malicious attacks. PLMT suffers from a DoS vulnerability, but it has protection methods against other attacks. PLMT uses the same token mechanism like other multipath transport protocols, but with much longer tokens. An attacker must not only correctly guess the Tokens, but also the Signature. As a consequence, the probability of blind guess attacks on PLMT is extremely small. 7. Open Issues This PLMT protocol specification is a work-in-progress, and there are still remaining unsolved issues that need further considerations. 8. IANA Considerations This document will make a request to IANA to allocate a new TCP/UDP port value for the PLMT Control Connection. Singh, et al. Expires January 6, 2011 [Page 31] Internet-Draft PLMT August 2010 9. Conclusion PLMT is a user-space solution to enable reliable, in-order data transfer over multiple paths. This specification defines the PLMT protocol. PLMT is defined as a worked example for a payload-based multipath transport, as an alternative to TCP option based signaling mechanisms. Due to some security vulnerabilities, it is mainly suitable for controlled and trusted environments. 10. References 10.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] J. Postel, ''Transmission Control Protocol'', STD 7, RFC 793, September 1981. [3] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008. 10.2. Informative References [4] Raiciu, C., Handley, M. and D. Wischik, ''Coupled Multipath- Aware Congestion Control'', draft-ietf-mptcp-congestion-00 (work in progress), July 2010. [5] Ford, A., Raiciu, C., Barre, S. and J. Iyengar, ''Architectural Guidelines for Multipath TCP Development'', draft-ietf-mptcp- architecture-01 (work in progress), June 2010. [6] Ford, A., Raiciu, C. and M. Handley, ''TCP Extensions for Multipath Operation with Multiple Addresses'', draft-ietf- mptcp-multiaddressed-01 (work in progress), July 2010. [7] M. Bagnulo, ''Threat Analysis for Multi-addressed/Multi-path TCP'', draft-ietf-mptcp-threat-02 (work in progress), March 2010. [8] Scharf, M. and A. Ford, ''MPTCP Application Interface Considerations'', draft-scharf-mptcp-api-02 (work in progress), July 2010. [9] M. Scharf, ''Multi-Connection TCP (MCTCP) Transport'', draft- scharf-mptcp-mctcp-00 (work in progress), July 2010. Singh, et al. Expires January 6, 2011 [Page 32] Internet-Draft PLMT August 2010 11. Acknowledgments The authors are supported by the German-Lab project (http://www.german-lab.de/), a research project funded by the German Federal Ministry of Education and Research (BMBF). The views expressed here are those of the author(s) only. The BMBF is not liable for any use that may be made of the information in this document. The authors gratefully acknowledge significant input into this document from Koojana Kuladinithi, Asanga Udugama, Andreas Koensgen, Andres Toro (all from University of Bremen), Andreas Timm-Giel (Hamburg University of Technology), Thomas-Rolf Banniza and Peter Schefczik (all from Alcatel-Lucent Bell Labs). Authors' Addresses Amanpreet Singh University of Bremen Otto-Hahn-Allee 1 28359 Bremen Germany Email: aps@comnets.uni-bremen.de Michael Scharf Alcatel-Lucent Bell Labs Lorenzstrasse 10 70435 Stuttgart Germany EMail: michael.scharf@alcatel-lucent.com Singh, et al. Expires January 6, 2011 [Page 33]