Internet DRAFT - draft-hampel-mptcp-proxies-anchors
draft-hampel-mptcp-proxies-anchors
Multipath TCP G. Hampel
Internet-Draft T. Klein
Intended status: Standards Track Alcatel-Lucent
Expires: August 11, 2012 February 8, 2012
MPTCP Proxies and Anchors
draft-hampel-mptcp-proxies-anchors-00
Abstract
MPTCP proxies and anchors are network-based functions, which support
MPTCP connections. The MPTCP proxy provides multipath support for
MPTCP-capable hosts on behalf of their MPTCP-unaware peers. This
facilitates incremental deployment of MPTCP. The MPTCP anchor
permits subflow establishment for MPTCP connections when direct
interaction between end hosts fails. This permits tolerance to local
IP protocol restrictions and it provides robustness in case of break-
before-make mobility events. MPTCP proxies and anchors are
especially suited for wireless access environments.
Status of this Memo
This Internet-Draft is submitted to IETF 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 August 11, 2012.
Copyright Notice
Copyright (c) 2012 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
Hampel & Klein Expires August 11, 2012 [Page 1]
Internet-Draft MPTCP Proxies and Anchors February 2012
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. MPTCP Network Functions . . . . . . . . . . . . . . . . . . . 4
2.1. MPTCP Proxy . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. MPTCP Anchor . . . . . . . . . . . . . . . . . . . . . . . 4
2.3. Implicit vs. Explicit Proxies . . . . . . . . . . . . . . 5
2.4. Implicit vs. Explicit Anchors . . . . . . . . . . . . . . 5
2.5. End-Host Authentication . . . . . . . . . . . . . . . . . 6
3. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 7
4. Operation with MPTCP Proxies . . . . . . . . . . . . . . . . . 8
4.1. Introduction of Implicit Proxy . . . . . . . . . . . . . . 8
4.2. Subflow Management with Implicit Proxy . . . . . . . . . . 11
4.3. Introduction of Explicit Proxy . . . . . . . . . . . . . . 12
4.4. Subflow Management with Explicit Proxy . . . . . . . . . . 15
5. Operation with MPTCP Anchors . . . . . . . . . . . . . . . . . 16
5.1. Introduction of Implicit Anchor . . . . . . . . . . . . . 16
5.2. Subflow Management with Implicit Anchor . . . . . . . . . 17
5.3. Introduction of Explicit Anchor . . . . . . . . . . . . . 19
5.4. Subflow Management with Explicit Anchor . . . . . . . . . 21
5.5. Protocol Translation with Anchor . . . . . . . . . . . . . 21
5.6. Connection Robustness with Anchor . . . . . . . . . . . . 22
6. Host Configuration . . . . . . . . . . . . . . . . . . . . . . 23
7. New Signaling . . . . . . . . . . . . . . . . . . . . . . . . 24
7.1. PROXY Flag . . . . . . . . . . . . . . . . . . . . . . . . 24
7.2. ANCHOR Flag . . . . . . . . . . . . . . . . . . . . . . . 24
7.3. JOIN Flag . . . . . . . . . . . . . . . . . . . . . . . . 25
7.4. Anchor-Reserved Address-Id Value . . . . . . . . . . . . . 26
7.5. SEEK_ADDR Option . . . . . . . . . . . . . . . . . . . . . 26
7.6. FWD_ADDR Option . . . . . . . . . . . . . . . . . . . . . 26
8. Security . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30
Hampel & Klein Expires August 11, 2012 [Page 2]
Internet-Draft MPTCP Proxies and Anchors February 2012
1. Introduction
Currently, a host can enjoy the advantages of MPTCP only if its peer
supports MPTCP as well [1]. This requirement creates an impediment
to incremental deployment since the incentive for a host to upgrade
to MPTCP is small as long as its potential peers have not upgraded
too.
The incremental deployment problem especially applies to wireless
environments, where traffic is dominated by interactions between
mobile clients and network-side servers. While MPTCP can be rolled
out rather quickly on mobile devices due to their short life cycle
and frequent kernel upgrades, changes on application servers are
usually harder to conduct. Further, the benefit of MPTCP may be more
obvious to mobile users than to application service providers.
The incremental deployment problem can be overcome through the
introduction of the MPTCP proxy, which resides in the network and
provides MPTCP support for MPTCP-capable hosts (e.g. mobile devices)
on behalf of their MPTCP-unaware peers (e.g. application services).
Since MPTCP proxies will most likely be run by network operators
rather than application service providers they can support a
multitude of application services, which makes incremental deployment
of MPTCP rather efficient. Further, network operators may see a
benefit in MPTCP deployment since it adds value to the network
services they provide and since they mostly support a billing
mechanism to reimburse themselves from MPTCP operation.
The MPTCP anchor is another MPTCP network function whose main purpose
is to support end-to-end multipath connections. It operates as a
subflow relay to facilitate subflow establishment between end points
that do not enjoy direct reachability. This may happen, for
instance, if the end points pertain to different IP protocols or if
the hosts have lost end-to-end connectivity after a break-before-make
mobility event.
The anchor function is most beneficial for peer-to-peer applications
such as voice/video communciations, which are run on MPTCP-enabled
mobile or multi-homed devices. Flexibility in IP protocol support is
important for this use case during the rollout of IPv6. The anchor
function further allows the network operator to provide
differentiated services for over-the-top applications.
This document discusses relevant features and signaling enhancements
needed for the support of MPTCP proxies and MPTCP anchors.
Hampel & Klein Expires August 11, 2012 [Page 3]
Internet-Draft MPTCP Proxies and Anchors February 2012
2. MPTCP Network Functions
All network-based functions that interact with MPTCP connections
through MPTCP signaling are referred to as "MPTCP network functions".
MPTCP network functions are assumed to reside on "MPTCP network
nodes". We consider two types of MPTCP network functions namely the
MPTCP proxy and the MPTCP anchor. Anchor- and proxy functions can be
collocated on one MPTCP network node.
2.1. MPTCP Proxy
The MPTCP proxy supports MPTCP on behalf of an MPTCP-unaware host.
It splits the connection between multipath-capable and multipath-
unaware host into a MPTCP section and a TCP section, respectively
(Figure 1). All subflows established by the multipath-capable host
terminate at the proxy.
Proxy operation is discussed in Section 4.
______ MPTCP TCP ______
| | | |
| |-----------\ ________ | |
| | \ | | | |
| Host |-------------+| Proxy |---------------| Host |
| | / |________| | |
| |-----------/ | |
|______| |______|
Split connection with MPTCP Proxy
Figure 1
2.2. MPTCP Anchor
The MPTCP anchor provides a network-based access point (i.e. IP
address), which a MPTCP host can use to create additional subflows to
the peer. The anchor relays all packets arriving from this host to
the peer and vice versa. This creates a split subflow consistent of
one section between host and anchor and the other between anchor and
peer (Figure 2). The anchor's operation involves address- and
eventually also port translation. Anchors can also insert or modify
MPTCP options of passing or relayed packets.
Anchor addresses can be introduced during connection establishment or
at any later point in time. Anchor functions can be invoked or
released during the entire lifetime of the connection.
An anchor function can interconnect end points using different IP
Hampel & Klein Expires August 11, 2012 [Page 4]
Internet-Draft MPTCP Proxies and Anchors February 2012
protocol versions with a subflow. In this case the anchor operates
as an IP protocol translator (Section 5.5). The anchor also serves
as a "meeting point" for the establishment of a new subflows when all
other subflows have failed and direct end-to-end subflow
establishment is not possible. This applies to scenarios where both
end hosts have simultaneously moved or when one host moves while the
other resides behind a firewall (Section 5.6).
Anchor operation is discussed in Section 5.
______ ______
| | SFL_0 ________ SFL_0 | |
| |------------\ | | /-------------| |
| | SFL_1 +| Anchor |+ SFL_1 | |
| Host |------------/ |________| \-------------| Host |
| | SFl_2 SFL_2 | |
| |---------------------------------------| |
|______| |______|
MPTCP connection with Anchor
Figure 2
2.3. Implicit vs. Explicit Proxies
An implicit proxy resides on the direct routing path between two
hosts engaging into a connection. This allows the hosts to establish
the connection directly with each other, while the proxy can derive
all information via packet inspection, insert and modify packets as
necessary and thereby create the MPTCP-TCP split connection. This
proxy is referred to as "implicit" since not explicit signaling is
necessary.
When the proxy does *not* reside on the direct routing path between
both hosts, explicit signaling is needed to introduce the proxy to
the connection. The same applies to a proxy that does not reside on
the path used for connection initiation. Such a proxy is referred to
as "explicit" proxy.
An implicit proxy typically resides on a central router in the access
network used by one of the hosts during connection establishment. An
explicit proxy can reside in any network.
2.4. Implicit vs. Explicit Anchors
The terms "implicit" and "explicit" can also be defined for anchors.
An implicit anchor resides on the routing path used by a subflow of a
Hampel & Klein Expires August 11, 2012 [Page 5]
Internet-Draft MPTCP Proxies and Anchors February 2012
MPTCP connection. This allows the anchor to derive all necessary
connection-related information via packet inspection during the
establishment of this subflow. Then, it can insert and modify
packets as necessary and thereby offer anchor services to the end
hosts.
When an implicit anchor resides on the initial subflow, it can offer
services to *both* end hosts. Otherwise, it can offer services only
to the subflow-initiating end host (see Section 5).
When the anchor does not reside on a direct routing path between both
connection end points, explicit signaling is needed to introduce the
anchor to the connection. Such an anchor is referred to as
"explicit" anchor.
Anchors can support connections between two hosts as well as between
a host and a MPTCP proxy. Usually, anchors are more beneficial in
the former of the two scenarios.
2.5. End-Host Authentication
MPTCP proxies and anchors should support an explicit or implicit
mechanism to authenticate one of the connection's end hosts. This
allows the proxy- or anchor operator to charge for operation of the
respective MPTCP network function. There are also security reasons
that require end-host authentication as outlined in Section 8.
Hampel & Klein Expires August 11, 2012 [Page 6]
Internet-Draft MPTCP Proxies and Anchors February 2012
3. Deployment Scenarios
The predominant use case for MPTCP proxies and MPTCP anchors is seen
in wireless access networks. This is motivated by the increasing
number of wireless devices that support multiple access technologies
as well as multi-homing.
In one deployment scenario, the MPTCP network function resides on a
central router of a wireless access network, e.g. a 3G/4G mobile
network. Especially 3G and 4G mobile network operators may see an
incentive for MPTCP proxy support since it allows them to dynamically
offload traffic from licensed to unlicensed spectrum. Further, 3G-
and 4G mobile networks already provide a centralized architecture,
security support and charging functions, which can be used for MPTCP
proxy or anchor operation.
There are also technical reasons to place MPTCP proxies inside
cellular networks which are related to the wide-area coverage these
networks typically provide. Therefore, the connection can be
established via the cellular interface and subsequently migrated to
other paths and networks. This substantially simplifies signaling
since an implicit proxy/anchor can be used. Further, the cellular
network can be used for reachability.
It is expected that anchor- and proxy functions are collocated.
For any deployment scenario, MPTCP-capable hosts need to be
configured appropriately so that they can take advantage of implicit
and explicit MPTCP network functions. Some aspects of host
configuration are discussed in Section 6.
Hampel & Klein Expires August 11, 2012 [Page 7]
Internet-Draft MPTCP Proxies and Anchors February 2012
4. Operation with MPTCP Proxies
Proxies must be introduced to the connection during connection
establishment and stay engaged during the entire lifetime of the
connection.
4.1. Introduction of Implicit Proxy
MPTCP TCP
______ ________ ______
| | | | | |
| Host | IP_A0 |Implicit| IP_B0 | Host |
| A |--|--------|--| Proxy |--|---------|--| B |
|______| SFL_0 |________| |______|
| |
_|_ _|_
|\ IP_A1 /| IP_PROX
| \ / |
| \----------------/ |
| SFL_1 |
| |
\----------------------/
SFL_2
MPTCP-TCP split connection with implicit MPTCP proxy
Figure 3
The MPTCP-capable host starts a MPTCP connection by sending a TCP SYN
packet with MP_CAPABLE option to its peer. The proxy inspects the
packet and caches the end point locators consistent of IP addresses
and port numbers as well as the key enclosed in the MP_CAPABLE
option. Based on these locators, the proxy identifies and intercepts
the peer's SYN-ACK response packet. The implicit proxy does not
change the locators contained on the packet.
In case the SYN-ACK response does not hold the MP_CAPABLE option, the
proxy initiates multipath support. It creates a key on behalf of the
peer, inserts a MP_CAPABLE option with this key into the SYN-ACK
packet, and then forwards the packet to the connection-initiating
host.
If the SYN-ACK response *does* contain an MP_CAPABLE option, the
proxy is not needed. In this case, the network node can provide
anchor functionality (see Section 5).
Hampel & Klein Expires August 11, 2012 [Page 8]
Internet-Draft MPTCP Proxies and Anchors February 2012
MPTCP MPTCP MPTCP TCP
HOST NETWORK NODE NETWORK NODE HOST
| | | |
| SYN + MP_CAPABLE | | |
| ----------------+--------------------+------------------->|
| | | |
| | add MP_CAPAPBLE_ | |
| | \| SYN-ACK |
|<-------------------+--------------------X--------------- |
| | | |
| | PROXY |
| | P |
| ACK + MP_CAPABLE | P |
| ----------------+--------------------+------------------->|
| | P |
| | P |
Connection initiation by MPTCP-capable host with implicit proxies on
initial path
Figure 4
If multiple implicit proxies reside on the initial path, the proxy
closest to the peer should become the MPTCP end point. Since this
proxy is the first to receive the peer's SYN-ACK packet, it
automatically assumes multipath support by inserting the MP_CAPABLE
option.
Hampel & Klein Expires August 11, 2012 [Page 9]
Internet-Draft MPTCP Proxies and Anchors February 2012
TCP MPTCP MPTCP MPTCP
HOST NETWORK NODE NETWORK NODE HOST
| | | |
| | _add MP_CAPABLE | |
| SYN |/ | |
| -----------------X--------------------+------------------->|
| | | |
| | | SYN-ACK+MP_CAPABLE|
|<-------------------+--------------------+---------------- |
| | | |
| PROXY | |
| P _add MP_CAPABLE | |
| ACK P/ | |
| -----------------X--------------------+------------------->|
| P | |
| P | |
Connection initiation by MPTCP-unaware host with implicit proxies on
initial path
Figure 5
The implicit proxy can also support scenarios, where the peer rather
than the connection-initiating host is MPTCP-capable. In this case,
the MPTCP proxy adds the MP_CAPABLE option with its own key to the
initial SYN packet. If the SYN-ACK response by the peer carries the
MP_CAPABLE header, the proxy assumes multipath support.
If multiple proxies reside on the initial path in this latter case,
the proxy closest to the session-initiating host should become the
MPTCP end point. Since this proxy is the first to receive the peer's
SYN packet, it automatically assumes multipath support by inserting
the MP_CAPABLE option into this SYN packet.
These signaling procedures work fine as long as at least one of the
end hosts supports MPTCP. A problem occurs, when multiple proxies
reside on the initial path but *neither* of the end hosts supports
MPTCP. In this case, one proxy may add MP_CAPABLE to the SYN packet
and the other to the SYN-ACK response packet. In this manner, both
proxies end up creating a TCP-MPTCP-TCP split connection with
multipath support between each other. Such a situation is likely to
occur when each of the hosts' access networks supports a proxy.
To avoid such a situation, the proxy inserting the MP_CAPABLE option
into the SYN packet has to reveal its true nature by adding a PROXY
flag to this option. When another proxy inspects the SYN packet and
finds the MP_CAPABLE option with PROXY flag set, it should not insert
Hampel & Klein Expires August 11, 2012 [Page 10]
Internet-Draft MPTCP Proxies and Anchors February 2012
MP_CAPABLE to the SYN-ACK response.
For implicit proxies, end-host authentication is implicitly provided
by the host's access authentication as long as the proxy resides in
the access network of one of the end hosts. This makes additional
signaling for end-host authentication unnecessary.
While this solution restricts operation of implicit proxies to access
providers and their affiliates (e.g. roaming partners), it covers the
most relevant deployment scenarios.
4.2. Subflow Management with Implicit Proxy
Since the proxy splits the connection into a MPTCP section and a TCP
section, it becomes the end point for all further subflows. These
subflows may be initiated by the MPTCP-capable host or by the proxy
itself.
When the proxy is implicit, it must inform the multipath-capable host
about its existence as well as its IP address. Otherwise, the
multipath-capable host may try to establish subflows with the
multipath-unaware peer. For this purpose, implicit proxies should
set the PROXY flag on those MP_CAPABLE options they insert into SYN
or SYN-ACK packets. This flag informs the multipath-capable host
that the remote end point is represented by a proxy.
After connection establishment, the proxy should advertise its
address via ADD_ADDR to the multipath-capable host. This step is
necessary since the host does not know the proxy's address.
Currently, the ADD_ADDR option also conveys the request for immediate
subflow establishment to the enclosed address. This request has the
purpose to enable subflow creation in reverse direction, i.e. when
the peer resides behind a firewall.
Obviously, immediate subflow creation is not desirable when a proxy
announces its IP address as an alterative end point. Therefore, the
ADD_ADDR option should be furnished with a JOIN flag, which allows
differentiating between the two purposes of ADD_ADDR. Hence subflow
creation is only requested when the JOIN flag is set.
Since MPTCP options are not delivered reliably, the ADD_ADDR option
may get lost. In this case, the host has no means to find out about
the proxy's IP address. For that reason, an additional SEEK_ADDR
option should be supported which allows the host to solicit address
advertisements by MPTCP network nodes and the peer.
SEEK ADDR should hold a field for the IP version requested. If this
Hampel & Klein Expires August 11, 2012 [Page 11]
Internet-Draft MPTCP Proxies and Anchors February 2012
field is set to zero, addresses pertaining to any IP version can be
advertised.
4.3. Introduction of Explicit Proxy
________
| |
|Explicit|
| Proxy |
MPTCP |________| TCP
|
_|_ IP_PROX
______ /|\ ______
| | / | \ | |
| Host | IP_A0 / | \ IP_B0 | Host |
| A |--|------------/ | \-----------|--| B |
|______| SFL_0 | |______|
| /|
_|_ IP_A1 / |
|\-------------------/ |
| SFL_1 |
| |
\-----------------------/
SFL_2
MPTCP-TCP split connection with explicit MPTCP proxy
Figure 6
If the proxy does not reside on the direct routing path of the
intended connection the connection initiator must provide the proxy
with explicit information on the peer's network locator, i.e. IP
address and port number. Since the explicit proxy may reside in a
different network, additional signaling for host authentication has
to be supported as well.
In case connection establishment reveals that both end hosts support
MPTCP (or if the peer is supported by an implicit proxy), the
explicit proxy function is not needed. In this case, the MPTCP
network node automatically assumes explicit anchor function since it
splits the initial subflow.
For connection establishment, the following signaling approaches are
considered:
o In-band MPTCP signaling: The peer's network locator (i.e. IP
address and port number) and the host's authentication information
are sent in-band on MPTCP options. Since the amount of
Hampel & Klein Expires August 11, 2012 [Page 12]
Internet-Draft MPTCP Proxies and Anchors February 2012
information is too large to fit into the TCP header of the initial
SYN packet additional packets need to be exchanged for signaling
purposes. A simple handhake can be realized where the MPTCP keys
are used as authenticators (Figure 7):
MPTCP EXPL MPTCP TCP
HOST A NETWORK NODE HOST B
| | |
| SYN + MP_CAP(KEY_A) | |
| -------------------------->| |
| | |
| SYN-ACK + MP_CAP(KEY_P) | |
|<-------------------------- | |
| | |
| ACK + FWD_ADDR(IP_B) | |
| -------------------------->| SYN + MP_CAP(KEY_A) |
| | ----------------------------->|
| | |
| | SYN-ACK |
| |<----------------------------- |
| | |
| PROXY |
| P |
| ACK + MP_CAP() P ACK |
|<--------------------------- P ----------------------------->|
| P |
| P |
Connection establishment with explicit proxy and in-band MPTCP
signaling
Figure 7
* The connection-initiating host (host A) sends the SYN packet
with MP_CAPABLE containing key_A as authenticator to the
explicit MPTCP network node which caches key_A and host A's
locator.
* The MPTCP network node answers with SYN_ACK enclosing
MP_CAPABLE with key_P as its own authenticator. It should
*not* set the PROXY flag, since it doesn't know at this point
if proxy function is required.
* Host A sends an ACK enclosing FWD_ADDR, which holds the peer's
(i.e. host B's) IP address. FWD_ADDR may also hold a port
number if it is different from the port number used to address
Hampel & Klein Expires August 11, 2012 [Page 13]
Internet-Draft MPTCP Proxies and Anchors February 2012
the MPTCP network node.
* The MPTCP network node sends SYN with MP_CAPABLE holding key A
to host B using its own IPaddress. It also sets the ANCHOR
flag in MP_CAPABLE as discussed in Section 5.
* If host B is not MPTCP-capable, it responds with a simple SYN-
ACK packet. Otherwise, it inserts MP_CAPABLE with key B into
the SYN-ACK packet. If MP_CAPABLE is absent, the MPTCP network
node assumes proxy function. Otherwise, it assumes anchor
function.
* The proxy function sends an ACK to host A and encloses the
MP_CAPABLE header with the PROXY flag set. This informs host A
that host B does not support MPTCP and that the MPTCP network
node has assumed proxy function. The MP_CAPABLE option does
not have to hold any key at this point since all keying
information has already been exchanged.
* The proxy function also sends a simple ACK to host B.
o Out-of-band MPTCP signaling: MPTCP introduces a separate signaling
connection to exchange the necessary signaling information prior
to establishment of the traffic connection. Since such an out-of-
band solution substantially extends the present scope of MPTCP it
is not further considered.
o Independent signaling: The host and the explict MPTCP network node
use an independent signaling protocol, in which the host
authenticates itself and provides the peer's locator. This
protocol can be supported on session or application layer such as
SIP [2], for instance. In this protocol, host and MPTCP network
node establish the 64-bit key, which is cached by the proxy
together with the peer's locator and inserted by the host into
MP_CAPABLE when initiating the MPTCP connection. This allows the
network node to find the peer's locator and to forward the SYN
packet to the peer using its own IP address. The network node
should set the ANCHOR flag when relaying the MP_CAPABLE packet to
the peer. In case the SYN-ACK return packet arriving from the
peer does *not* contain an MP_CAPABLE option, the network node
assume proxy function. In this case, the proxy inserts MP_CAPABLE
into the SYN-ACK packet, sets the PROXY flag and sends the packet
to the connection-initiating host using its own IP address and
port number as the packet's source. The host responds with an ACK
holding its own key as well as the key contained in the SYN-ACK
packet.
Security issues related to such explicit proxy solutions are
Hampel & Klein Expires August 11, 2012 [Page 14]
Internet-Draft MPTCP Proxies and Anchors February 2012
discussed in Section 8.
It makes little sense to consider explicit-proxy scenarios where the
connection-initiating host is not MPTCP-capable.
4.4. Subflow Management with Explicit Proxy
Subflow establishment with an explicit proxy follows along the same
lines as for an implicit proxy. The explicit proxy, however, does
not have to send an ADD_ADDR option since the host already knows the
proxy's address.
Hampel & Klein Expires August 11, 2012 [Page 15]
Internet-Draft MPTCP Proxies and Anchors February 2012
5. Operation with MPTCP Anchors
The anchor function splits subflows into two subflow sections, where
each section interconnects an end host with one of the anchor's IP
addresses (Figure 8). The anchor relays all packets arriving on one
subflow section to the other by rewriting the IP addresses of the
packet headers. The anchor may also translate port numbers. Anchors
can also insert or modify MPTCP options of passing packets.
To keep end-to-end semantics in tact, the end nodes must have full
awareness of the anchor's presence and its operation, i.e. if
subflows are split and if an IP address belongs to an anchor or to
the peer. Further, each host must know about the address-id its peer
uses on the remote section of a split subflow. This ensures proper
subflow tear-down in case the peer announces address removal via
REMOVE_ADDR option.
Anchors can be introduced during connection establishment or at any
later point in time. Anchor services can be invoked or released
during the entire lifetime of the connection.
5.1. Introduction of Implicit Anchor
______ ________ ______
| | | | | |
| Host | IP_A0 |Implicit| IP_B0 | Host |
| A |--|--------|--| Anchor |--|---------|--| B |
|______| SFL_0 |________| SFL_0 / |______|
| | / |
_|_ _|_ / _|_
|\ IP_A1 / \ IP_ANCH / | IP_B1
| \ / \ / |
| \----------------/ \-------/ |
| Split SFL_1 Split SFL_1 |
| |
\----------------------------------------------/
SFL_2
MPTCP connection with implicit MPTCP anchor
Figure 8
When an implicit anchor resides on the initial path, it caches the
locators (i.e. IP addresses and port numbers) of the initial subflow
as well as the keys exchanged during connection establishment. This
allows the anchor to derive the corresponding tokens and cache them
together with the end hosts' locators of this subflow.
Hampel & Klein Expires August 11, 2012 [Page 16]
Internet-Draft MPTCP Proxies and Anchors February 2012
Then, the anchor advertises its IP address to the end hosts by
sending an ADD_ADDR option to one or to both end hosts. The ADD_ADDR
option can be inserted into a packet that is passing on the initial
subflow. The anchor may also insert a port number into the ADD_ADDR
option.
The anchor has to mark the ADD_ADDR option in a manner that allows
the host receiving the option to distinguish it from an ADD_ADDR
option sent by the peer. For this purpose, the anchor should set the
address-id in the ADD_ADDR option to an anchor-reserved value (e.g.
255). This does not lead to any conflict in case multiple anchors
advertise their addresses with the same address-id value, since
anchor addresses are considered invariants that need not be removed.
Obviously, neither end hosts nor proxies should use this anchor-
reserved address-id value.
When an implicit anchor resides on the path used by a later subflow,
it caches the subflows locators as well as the token used during
subflow establishment. Obviously, anchor support can only be
provided for the host that initiated this subflow (host A) but not
for its peer (host B) since the anchor only knows host B's token.
Therefore, the anchor advertises its IP address (and port number)
only to host A.
The host receiving an ADD_ADDR options from an anchor caches the
anchor's address and port number contained in this option. When the
ADD_ADDR option does not carry a port number, the remote port number
of the subflow, where the option arrived, is cached instead.
Since the delivery of ADD_ADDR is not reliable, an end host may
proactively seek anchor addresses via the SEEK_ADDR option introduced
above. Both anchor and peer should respond with an ADD_ADDR option.
The host can differentiate the originators of these replies by the
enclosed address-id value.
5.2. Subflow Management with Implicit Anchor
When a host wishes to establish a subflow via anchor, it initiates a
subflow to the address and port number cached for the anchor. Based
on the destination port number of the SYN packet and the token
contained in MP_JOIN, the anchor identifies the peer's locator and
forwards the packet to the peer using one of its own addresses and
port numbers as the packet's source. The peer's SYN-ACK return
packet and all following packets are relayed by the anchor in the
same manner. Since the anchor does not change the address-ids
contained in the MP_JOIN options of the initial handshake, each host
learns the peer's address-id used for this split-subflow.
Hampel & Klein Expires August 11, 2012 [Page 17]
Internet-Draft MPTCP Proxies and Anchors February 2012
While the host initiating the subflow (host A) is aware of the
anchor's presence, its peer (host B) may not know that this subflow
is split because the anchor has not introduced itself to the peer or
because the corresponding ADD_ADDR option got lost. In such a case,
host B may falsely assume that the anchor's IP address belongs to
host A and map it to the address-id contained in MP_JOIN. This may
lead to a conflict, in case host A has announced (or will announce)
this address-id for another address. Further, host B may be tempted
to use the anchor's IP address for further subflows without knowing
that this may invoke triangular routing.
To avoid such misunderstanding, the MP_JOIN option on the SYN packet
has to be marked with an ANCHOR flag. This flag tells host B, that
the source address on the packet header belongs to an anchor and that
it is not associated with the address-id carried in the MP_JOIN
option. The ANCHOR flag should be set by the anchor when relaying
the SYN packet.
While host B may implicitly learn the anchor's IP address in this
manner, it is not advised to use this anchor for new subflows unless
the anchor has explicitly advertised its IP address. Host B can
solicit such IP address advertisement via SEEK_ADDR sent on the split
subflow.
Each host should cache the peer's address-id together with the state
information it holds for the corresponding split subflow. In case
the host receives an REMOVE_ADDR option, it can identify and tear
down all split-subflows pertaining to the address-id held in this
option.
The establishment of split subflows via anchor may introduce address-
ids without the corresponding IP addresses. This is a similar
situation as when direct end-to-end subflows pass network address
translators, and it does not pose any principle problem.
The anchor caches the host's locators and address-ids of the split
subflow together with all information it holds for this connection.
The anchor further keeps subflow-related state information for a
short time frame after the subflow has been closed. The tokens and
address ids are held for a short time after the last subflow known by
this anchor has been closed. The tear-down delay permits the anchor
to support break-before-make mobility scenarios discussed below.
Hampel & Klein Expires August 11, 2012 [Page 18]
Internet-Draft MPTCP Proxies and Anchors February 2012
5.3. Introduction of Explicit Anchor
________
| |
|Explicit|
| Anchor |
|________|
|
_|_ IP_ANCH
______ /|\ ______
| | / | \ | |
| Host | IP_A0 / | \ IP_B0 | Host |
| A |--|------------/ | \-----------|--| B |
|______| Split SFL_0 | Split SFL_0 |______|
| / Split SFL_1 |
_|_ IP_A1 / (using same path) _|_ IP_B1
|\-------------------/ |
| Split SFL_1 |
| |
\----------------------------------------------/
SFL_2
MPTCP-TCP split connection with explicit MPTCP anchor
Figure 9
If the anchor does not reside on a direct routing path it has to be
introduced via explicit signaling by one of the hosts. The signaling
has to include authentication information and the peer's locator.
Since these are the same conditions as for explicit proxies the same
solution scenarios can be applied as discussed in Section 4.3. For
the reasons mentioned above, only scenarios with in-band MPTCP
signaling and independent signaling are considered.
o In-band MPTCP signaling: The first four steps of the connection
establishment are identical to those discussed for the explicit
proxy (see Figure 7 and Figure 10):
Hampel & Klein Expires August 11, 2012 [Page 19]
Internet-Draft MPTCP Proxies and Anchors February 2012
MPTCP EXPL MPTCP MPTCP
HOST A NETWORK NODE HOST B
| | |
| SYN + MP_CAP(KEY_A) | |
| -------------------------->| |
| | |
| SYN-ACK + MP_CAP(KEY_P) | |
|<-------------------------- | |
| | |
| ACK + FWD_ADDR(IP_B) | |
| -------------------------->| SYN + MP_CAP(KEY_A) |
| | ----------------------------->|
| | |
| | SYN-ACK + MP_CAP(KEY_B) |
| |<----------------------------- |
| | |
| ANCHOR |
| A |
| ACK + MP_CAP(KEY_B) A ACK + MP_CAP(KEY_A, KEY_B) |
|<--------------------------- A ----------------------------->|
| A |
| A |
Connection establishment with explicit anchor and in-band MPTCP
signaling
Figure 10
* Steps 1-4 of connection establishment with explicit proxy.
* In case host B is MPTCP-capable, it inserts MP_CAPABLE with key
B into the SYN-ACK response packet. Upon reception of this
packet, the MPTCP network node assumes anchor function instead
of proxy function.
* The anchor function sends an ACK to host A and encloses the
MP_CAPABLE header with key_B and it sets the ANCHOR flag. This
informs host A that host B does support MPTCP and that the
MPTCP network node has assumed anchor function. At this point,
host A overwrites key_P with key_B.
* The anchor function also sends an ACK to host B, where it
inserts MP_CAPABLE with key_A and key_B and sets the ANCHOR
flag. This tells host B that an anchor resides on the initial
path.
Hampel & Klein Expires August 11, 2012 [Page 20]
Internet-Draft MPTCP Proxies and Anchors February 2012
o Independent signaling: The explicit MPTCP network node relays the
host's SYN packet holding the MP_CAPABLE option to the peer. If
the SYN-ACK return packet holds the MP_CAPABLE option, the MPTCP
network node assumes anchor function and the initial subflow
becomes a split subflow. When relaying the SYN-ACK packet to the
connection-initiating host, the anchor should set the ANCHOR flag.
The host responds with an ACK holding MP_CAPABLE with both keys.
In case host B is not multipath-aware it may be supported by an
implicit proxy residing on the path between host B and the explicit
anchor. This proxy may reside in host B's access network for
instance. The implicit proxy sets the PROXY flag in the MP_CAPABLE
option of the SYN-ACK return packet as described in section 4.1.
Since the explicit anchor sets the ANCHOR flag at the same time, host
A can infer that the PROXY flag was set by an implicit proxy.
A host can also introduce an explicit anchor after connection
establishment. This has only limited benefit since the peer won't be
able to proactively use this anchor. Further, it is rather
complicated to embed such an anchor introduction into the MP_JOIN
handshake. For that reason, only methods involving independent
signaling protocols are considered here. Such a protocol has to
provide authentication information, the remote end point locator and
the remote tokens used on this connection.
5.4. Subflow Management with Explicit Anchor
After introduction of the explicit anchor, establishment of further
split subflows follows the same procedure as discussed for implicit
anchors in Section 5.2.
5.5. Protocol Translation with Anchor
The anchor can be used for IP protocol translation on a split subflow
in case host A wishes to support IPv6 on a new interface while host B
only supports IPv4. Protocol translation further becomes necessary
when one host moves from an IPv4 network to an IPv6 network while the
peer's network only supports IPv4 (and vice versa).
In such scenarios, host A sends SEEK_ADDR on all subflows with the
IPVer field set to IPv6. In response, anchors will send their
respective IPv6 addresses. Then, host A initiates a new subflow to
one anchors' IPv6 address. Since the anchor has cached at least one
of host B's IPv4 addresses, it can create an IPv6/IPv4 split-subflow
using an IPv6 and an IPv4 address.
Hampel & Klein Expires August 11, 2012 [Page 21]
Internet-Draft MPTCP Proxies and Anchors February 2012
5.6. Connection Robustness with Anchor
The anchor can provide enhanced connection robustness in scenarios
where the only remaining subflow breaks and direct end-to-end subflow
establishment is not possible. This may happen, for instance, when
both hosts simultaneously move to a new address. Direct subflow
establishment is not possible in this case since neither host knows
the peer's new IP address.
In another scenario, a host moves to a new IP address while the peer
resides behind a firewall. The host cannot reach the peer since the
firewall blocks packets arriving from a new address. The peer cannot
reach the host either since it does not know the host's new IP
address.
In these scenarios, each host will try to establish a direct subflow
first. If this fails each host tries subflow establishment via an
anchor. Since the anchor recognizes the connection based on token
and port number contained in each host's SYN-packet, it can cache the
host's new address contained on the packet and use it as the
destination for SYN-packets sent by the peer. In this manner, a new
subflow can be established via the anchor.
For this purpose, the anchor should keep connection-related state
information for some time after the subflow it is residing on has
been torn down.
The procedure further requires that the anchor holds both end hosts'
tokens. This applies to anchors that reside on the initial path
during connection establishment.
Hampel & Klein Expires August 11, 2012 [Page 22]
Internet-Draft MPTCP Proxies and Anchors February 2012
6. Host Configuration
MPTCP-capable hosts should be appropriately configured to take
advantage of MPTCP network functions. In a deployment scenario,
where proxies and anchors are integrated with a central router of a
3G/4G cellular network, the host should initiate connections that
deserve MPTCP support via the cellular interface if possible. After
connection establishment, additional paths can be established and
utilized for traffic exchange.
In case explicit MPTCP network functions are provided, the host must
be configured to support the proprietary protocol that introduces
these nodes to the MPTCP connection. It must further be configured
with the IP addresses for explicit proxies.
The details on host configuration and the criteria on path selection
are beyond the scope of this document.
Hampel & Klein Expires August 11, 2012 [Page 23]
Internet-Draft MPTCP Proxies and Anchors February 2012
7. New Signaling
The following subsections discuss signaling changes necessary to
support MPTCP network functions.
7.1. PROXY Flag
The PROXY flag needs to be added to the MP_CAPABLE option. The PROXY
flag is set by MPTCP network nodes to announce that they assume proxy
function.
The PROXY flag serves two purposes. It avoids that implicit proxies
residing on the initial path between MPTCP-unaware hosts sustain a
MPTCP connection with each other. It also informs a MPTCP-capable
host that a proxy provides MPTCP on behalf of an MPTCP-unaware peer.
This avoids unnecessary attempts by this host to establish subflows
directly with the MPTCP-unaware peer.
The PROXY flag can be added into the header of the MP_CAPAPBLE option
(shown as "P" in Figure 11).
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 | Length |Subtype|Version|C|P|A|(resvd)|S|
+---------------+---------------+-------+-------+-+-+-+-------+-+
| ... ... |
MP_CAPABLE header with PROXY (P) and ANCHOR (A) flags
Figure 11
7.2. ANCHOR Flag
The ANCHOR flag needs to be added to the MP_CAPABLE option and to the
MP_JOIN option. The flag informs the receiving host (or proxy) that
an anchor has relayed this packet. This avoids misunderstandings
about the source IP address of the packet and the address-id it
carries.
The ANCHOR flag can be added to the headers of MP_CAPAPBLE and
MP_JOIN (shown as "A" in Figure 11 and Figure 12).
Hampel & Klein Expires August 11, 2012 [Page 24]
Internet-Draft MPTCP Proxies and Anchors February 2012
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 | Length = 12 |Subtype| |A|B| Address ID |
+---------------+---------------+-------+---+-+-+---------------+
| ... ... |
MP_JOIN header for SYN and SYN-ACK with ANCHOR flag
Figure 12
7.3. JOIN Flag
The ADD_ADDR option is currently overloaded with two requests: 1)
Cache this address and 2) initiate a subflow to this address right
away. While this bundling of requests makes sense for end-to-end
interactions, it becomes problematic for proxies and anchors, which
only want to inform the peers about their respective addresses.
The issue can be resolved by adding a JOIN flag to the ADD_ADDR
option. This, however, creates some issues since the option has no
room left for additional information. The option is further rather
long, especially if IPv6 addresses and port numbers have to be
carried.
The following approaches can be considered:
o The IPVer field is reduced from 4 to 3 bits as proposed by Olivier
Bonaventure. This still leaves room for 5 future IP versions
apart from IPv4 and IPv6. (Note that IP version = 0 is used by
SEEK_ADDR to refer to "all IP versions"). The released bit is
available for the JOIN flag.
o The ADDRESS ID field is reduced by 1 bit to allocate room for JOIN
as proposed by Costin Raiciu. This reduces the number of
simultaneously supported addresses from 256 to 128 (or 255 and 127
if the anchor-reserved address-id is included as well).
o The ADD_ADDR option only provides addresses and address-ids while
a new option conveys the request to create a subflow with respect
to a specific address id. A similar proposal was also made by
Yoshifumi Nishida.
o An octet is added to the ADD_ADDR option.
Hampel & Klein Expires August 11, 2012 [Page 25]
Internet-Draft MPTCP Proxies and Anchors February 2012
7.4. Anchor-Reserved Address-Id Value
The anchor-reserved address-id value is used when anchors advertise
their IP address via ADD_ADDR. It informs the receiving host that
the address belongs to an anchor and not to the peer.
The anchor reserved address-id value could be set for 255, for
instance.
7.5. SEEK_ADDR Option
The SEEK_ADDR option is sent by a host to solicit its peer as well as
proxies and anchors to advertise their addresses. This option is
necessary for operation with proxies and anchors, which rely on
reliable address advertising.
The SEEK_ADDR option holds the IP version field. If the value of
this field is set to zero, addresses to all IP versions are sought.
SEEK_ADDR also permits peers and MPTCP network nodes to reduce
address advertising. It is not necessary, for instance, to
preemptively advertise IPv6 addresses on connections that only use
IPv4 and vice versa.
The SEEK_ADDR option only holds the IP version field which leads to
length of 3 octets (Figure 13).
1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+---------------+---------------+-------+-------+
| Kind | Length |Subtype| IPVer |
+---------------+---------------+-------+-------+
SEEK_ADDR option
Figure 13
7.6. FWD_ADDR Option
The FWD_ADDR option is used by a host to forward its peer's IP
address and port number to an explicit MPTCP network node.
The fields of the FWD_ADDR are identical to that of the ADD_ADDR
option. Since both options have different semantic meanings they
should also carry different subtypes.
Hampel & Klein Expires August 11, 2012 [Page 26]
Internet-Draft MPTCP Proxies and Anchors February 2012
8. Security
Mobility and multi-homing protocols are vulnerable to session
redirection attacks such as session hijacking and distributed DoS
(DDoS)[3]. For MPTCP, these matters have been discussed in [4]. The
introduction of implicit proxies and anchors does not add new
principal vulnerabilities.
One potential weakness is seen in connections via explicit proxy (or
anchor), since the proxy can be used by the adversary to disguise its
true location. In a DDoS attack, the adversary establishes multiple
connections with the victim host and then floods the victim with a
high volume of traffic on each connection. The severity of such an
attack does not change when these connections are conducted via
explicit proxy. Since the proxy uses its own IP address to forward
the attacker's packets to the victim, the attacker's IP address
remains hidden to the victim. This makes it impossible for the
victim to identify an adversary prior to accepting a connection and
to trace back the traffic flood to the attacker's location.
One could argue that this situation could be improved by specifying a
strong authentication method to be exercised between host and proxy.
This, however, is not necessarily the case since a strong
authentication protocol by itself does not enforce the use of strong
authenticators.
Note that this situation is different for mobility protocols like
Mobile IPv6. In Mobile IPv6, the home agent uses the mobile host's
unique home address as the source for traffic originated by the
mobile host. The home address is therefore an authenticator of the
traffic originator.
To support the same level of security, the explicit proxy could use a
unique IP address for each host. While such an approach is feasible
in IPv6 it may have limited applicability in IPv4 due to IP address
exhaustion.
Hampel & Klein Expires August 11, 2012 [Page 27]
Internet-Draft MPTCP Proxies and Anchors February 2012
9. Acknowledgements
The authors wish to acknowledge suggestions and contributions on
proxies and anchors by Olivier Bonaventure, Philip Eardley, Alan
Ford, Mark Handley, Yoshifumi Nishida and Costin Raiciu.
Hampel & Klein Expires August 11, 2012 [Page 28]
Internet-Draft MPTCP Proxies and Anchors February 2012
10. References
[1] Ford, A., Raiciu, C., Greenhalgh, A., and M. Handley,
"Architectural Guidelines for Multipath TCP Development",
RFC 6182, March 2011.
[2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
Session Initiation Protocol", RFC 6182, June 2002.
[3] Nikander, P., Arkko, J., Auro, T., Montenegro, G., and E.
Nordmark, "Mobile IP Version 6 Route Optimization Security
Design Background", RFC 4225, December 2005.
[4] Bangulo, M., "Threat Analysis for TCP Extensions for Multipath
Operation with Multiple Addresses", RFC 6181, March 2011.
Hampel & Klein Expires August 11, 2012 [Page 29]
Internet-Draft MPTCP Proxies and Anchors February 2012
Authors' Addresses
Georg Hampel
Alcatel-Lucent
600 Mountain Ave
Murray Hill, NJ 07974
US
Phone: +1 908 582 2377
Fax: +1 908 582 8222
Email: georg.hampel@alcatel-lucent.com
Thierry Klein
Alcatel-Lucent
600 Mountain Ave
Murray Hill, NJ 07974
US
Phone: +1 908 582 3585
Fax: +1 908 582 8222
Email: thierry.klein@alcatel-lucent.com
Hampel & Klein Expires August 11, 2012 [Page 30]