Internet DRAFT - draft-bonaventure-mptcp-addr
draft-bonaventure-mptcp-addr
MPTCP Working Group O. Bonaventure
Internet-Draft UCLouvain
Updates: RFC6824 (if approved) July 06, 2015
Intended status: Informational
Expires: January 7, 2016
Multipath TCP Address Advertisement
draft-bonaventure-mptcp-addr-00
Abstract
Multipath TCP [RFC6824] defines the ADD_ADDR option to allow a host
to announce its addresses to the remote host. In this document we
analyze some of the issues with the address advertisement technique
defined [RFC6824] and propose some modifications to mitigate these
problems. We also show that the reverse DNS could be an excellent
alternative to advertise the stable addresses of a server.
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 7, 2016.
Copyright Notice
Copyright (c) 2015 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
Bonaventure Expires January 7, 2016 [Page 1]
Internet-Draft MPTCP ADDR July 2015
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Issues with ADD_ADDR . . . . . . . . . . . . . . . . . . . . 3
2.1. Usage of the Address Identifiers . . . . . . . . . . . . 4
2.2. Reliability of the ADD_ADDR Option . . . . . . . . . . . 5
3. Learning the Addresses bound to a host through the DNS . . . 5
4. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 7
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
6. Informative References . . . . . . . . . . . . . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction
Multipath TCP is an extension to TCP [RFC0793] that was specified in
[RFC6824]. Multipath TCP was designed with multi-addressed hosts in
mind [RFC6182]. A Multipath TCP connection is composed of subflows
that are established between any of the addresses of the
communicating hosts. [RFC6824] defines two options to manage the
host addresses :
o ADD_ADDR is used to announce one address bound to a host (possibly
combined with a port number)
o REMOVE_ADDR is used to indicate that an address previously
attached to a host is not anymore attached to this host
To cope with Network Address Translation (NAT), the ADD_ADDR and
REMOVE_ADDR options contain an address identifier encoded as an 8
bits integer.
When the initial subflow is created, it is assumed to be initiated
from the address of the client whose identifier is 0 towards the
address of the server whose identifier is also 0. Both the client
and the server can use ADD_ADDR to advertise the other addresses that
they use. When an additional subflow is created, the MP_JOIN option
placed in the SYN (resp. SYN+ACK) contains the identifier of the
address used to create (resp. accept) the subflow.
Experience with Multipath TCP shows that these two options allow to
support multi-homed or dual-stack servers [TMA2015] and mobile
devices [Cellnet12]. While the ADD_ADDR option has been supported in
the Linux implementation of Multipath TCP, other implementors have
chosen to not support it [I-D.eardley-mptcp-implementations-survey]
while still supporting the REMOVE_ADDR option.
Bonaventure Expires January 7, 2016 [Page 2]
Internet-Draft MPTCP ADDR July 2015
In this document, we first analyse in Section 2 several issues with
the current ADD_ADDR option as defined in [RFC6824] and
[I-D.ietf-mptcp-rfc6824bis]. Then in Section 3 we show how Multipath
TCP could leverage the existing DNS to obtain information about the
different addresses attached to a server.
2. Issues with ADD_ADDR
A first issue are the security risks if an attacker is able to send
spoofed TCP segments that include the ADD_ADDR option. Multipath TCP
[RFC6824] defines the ADD_ADDR option shown in Figure 1.
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| IPVer | Address ID |
+---------------+---------------+-------+-------+---------------+
| Address (IPv4 - 4 octets / IPv6 - 16 octets) |
+-------------------------------+-------------------------------+
| Port (2 octets, optional) |
+-------------------------------+
Figure 1: The ADD_ADDR option
From a security viewpoint, this option introduces a potential
security risk if an attacker is able to send a spoofed ADD_ADDR
option. [I-D.ietf-mptcp-rfc6824bis] proposes a new format for this
option by placing a truncated HMAC inside the option to authenticate
it. The format for this new option (ADD_ADDR2) is shown in Figure 2.
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| IPVer | Address ID |
+---------------+---------------+-------+-------+---------------+
| Address (IPv4 - 4 octets / IPv6 - 16 octets) |
+-------------------------------+-------------------------------+
| Port (2 octets, optional) | |
+-------------------------------+ |
| Truncated HMAC (8 octets) |
| +-------------------------------+
| |
+-------------------------------+
Figure 2: The ADD_ADDR2 option
Bonaventure Expires January 7, 2016 [Page 3]
Internet-Draft MPTCP ADDR July 2015
2.1. Usage of the Address Identifiers
A second issue with the ADD_ADDR option is the management of the
address identifiers. At first glance, a Multipath TCP implementation
could maintain a table of the IP addresses bound to the local host
and associate one identifier with each address. When a new IP
address is configured, it is added to the table and the index in the
table can be used as its identifier. If a local address stops to be
bound to the host, the Multipath TCP can extract its identifier from
the table and send the REMOVE_ADDR option over all existing Multipath
TCP connections. Unfortunately, such a naive implementation is not
possible with the current Multipath TCP implementation.
As defined in [RFC6824], the identifiers 0 are assigned to the
addresses that were used for the establishment of the initial
subflow. This is because the MP_CAPABLE option does not contain any
field to encode an address identifier in contrast with the MP_JOIN
option.
An annoying consequence of this design choice is that a Multipath TCP
implementation must at least remember the identifier of the address
that was used to create the initial subflow. It cannot simply rely
on the global address table described above because when an address
fails, it must be able to send a REMOVE_ADDR with for address
identifier 0 if this address was used to create the initial subflow.
This forces a Multipath TCP implementation to at least store the
address identifier of the initial subflow for each connection.
One suggestion to ease the maintenance of the addresses on a
Multipath TCP implementation would be to stop assuming that the
address identifier 0 corresponds to the address used to establish the
initial subflow. Instead, the implementation should maintain a table
of all the addresses that it uses with Multipath TCP and assign one
strictly positive identifier to each address. In this case, each
address assigned to the host has the same address identifier for all
the Multipath TCP connections. When a new address is learned, it is
automatically assigned the next available address identifier and can
be announced over all existing Multipath TCP connections depending on
the policy applied for the address announcements. When an address is
not bound anymore to this host, then the same REMOVE_ADDR option can
be sent over all Multipath TCP connections.
There is one missing element in the solution discussed above : how to
announce the real address identifier that corresponds to the initial
subflow. A simple solution to this problem is to use the ADD_ADDR
option without an address as shown in Figure 3.
Bonaventure Expires January 7, 2016 [Page 4]
Internet-Draft MPTCP ADDR July 2015
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| IPVer | Address ID |
+---------------+---------------+-------+-------+---------------+
Figure 3: The ADD_ADDR option indicating the address identifier of
the current subflow
This empty ADD_ADDR option indicates the address identifier of the
address on the subflow over which it has been transmitted. It MUST
only be used on the initial subflow since on the other subflows the
same information is carried reliably in the MP_JOIN option of the SYN
segments. The IPVer field of this ADD_ADDR option MUST match the IP
version used for the initial subflow.
2.2. Reliability of the ADD_ADDR Option
A third issue with the ADD_ADDR option is that since it is
transmitted as a TCP option, it is not delivered reliably
[Cellnet12]. If it announces an IPv4 address, the ADD_ADDR option
could be inserted inside a segment that carries data and would thus
be delivered reliably like the user data. However, if the ADD_ADDR
option contains an IPv6 address, it might be too large to fit inside
a segment that already contains a DSS option and possibly other
options such as the [RFC1323] timestamps. Given its length, the
ADD_ADDR2 option cannot be placed in the same segment as a DSS
option. In these two cases, the ADD_ADDR/ADD_ADDR2 option will be
often transmitted inside a duplicate ACK that is not delivered
reliably. [Cellnet12] proposes a method to improve the reliability
of the transmission of the ADD_ADDR option, but to our knowledge this
method has never been implemented. To cope with packet losses, some
implementations could decide to transmit several copies of the
ADD_ADDR option over the same connection.
3. Learning the Addresses bound to a host through the DNS
[RFC6824] defines the ADD_ADDR option as the basic technique to learn
the addresses bound to the remote host. Given the importance of
learning those addresses, one would expect this technique to be
supported by all Multipath TCP implementations. This is not the
case, since only the Linux implementation of Multipath TCP supports
the ADD_ADDR option [I-D.eardley-mptcp-implementations-survey] as
defined in [RFC6824]. The other implementations do not support this
option [I-D.eardley-mptcp-implementations-survey]. This design
choice was probably motivated by security concerns with this option
and also because these implementations assume that only the client
Bonaventure Expires January 7, 2016 [Page 5]
Internet-Draft MPTCP ADDR July 2015
creates the subflows and the server is single-homed. In this case,
the client (e.g. a smartphone), can create the subflows from any of
its own addresses towards the single address of the server.
However, with the deployment of IPv6, the number of dual-stack
clients and servers will grow and it will be important for a host
that creates a connection towards the IPv4 address of a server to
also learn the IPv6 address associated to this particular server. We
show in this section that the DNS could be used to distribute the
addressing information that is required by Multipath TCP.
There are three possibilities to use to DNS to distribute the list of
addresses associated to a given server. A first approach is to use
the existing forward DNS and consider that all the 'A' and 'AAAA'
records associated with a name correspond to the same server and can
be used to establish Multipath TCP subflows. Unfortunately, when
several records are associated to a DNS name, this is often for load
balancing reasons and those records point to the addresses of
different hosts. A second approach would be to define a new DNS
record that contains the list of the IP addresses associated to a
given host. However, this would require to deploy a new type of DNS
record. Proposals that were made in the past to define new RR types
were not endorsed by the IETF (e.g., one single RR for dual stack
hosts [I-D.li-dnsext-ipv4-ipv6] or a distinct RR for IPv4-Embedded
IPv6 Address [I-D.boucadair-behave-dns-a64]).
The third approach that we propose in this document is to use the
reverse DNS to encode the information about the alternate addresses
that are associated to a given host. The reverse DNS tree typically
only contains PTR records that associate names to reverse IPv4 or
IPv6 addresses. However, nothing prevents the use of the reverse DNS
to store A and AAAA records. This is the approach that we recommend.
It does not require any change to the DNS protocol and can leverage
dynamic updates to the DNS [RFC3007] and DNSSec to authenticate the
advertisement of addresses [RFC4034].
As an example, consider the server whose name is mptcp.example.org
and which is reachable via the following IP addresses taken from the
documentation prefixes [RFC3849] [RFC5737] :
o 192.0.2.10
o 198.51.100.23
o 2001:db8::1234
The forward DNS will contain the following records for this server
Bonaventure Expires January 7, 2016 [Page 6]
Internet-Draft MPTCP ADDR July 2015
mptcp.example.org. 7200 IN A 192.0.2.10
mptcp.example.org. 7200 IN A 198.51.100.23
mptcp.example.org. 7200 IN AAAA 2001:db8::1234
In addition, the following entries would be added in the reverse DNS.
10.2.0.192.in-addr.arpa. 7200 IN AAAA 2001:db8::1234
10.2.0.192.in-addr.arpa. 7200 IN A 198.51.100.23
23.100.51.198.in-addr.arpa. 7200 IN AAAA 2001:db8::1234
23.100.51.198.in-addr.arpa. 7200 IN A 192.0.2.10
4.3.2.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.
8.b.d.0.1.0.0.2.ip6.arpa. 7200 IN A 192.0.2.10
4.3.2.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.
8.b.d.0.1.0.0.2.ip6.arpa. 7200 IN A 198.51.100.23
These reverse records can, of course, be signed with DNSSec
[RFC4034].
4. Conclusion
In this document, we have discussed several issues with the
advertisement of addresses with the ADD_ADDR and ADD_ADDR2 options in
Multipath TCP. Then, we have shown that the reverse DNS can be used
by servers to advertise their alternate IP addresses. This does not
require any modification to the DNS protocol and could be used by
applications that do not want or cannot rely on the ADD_ADDR option.
5. Acknowledgements
This work was partially supported by the FP7-Trilogy2 project. This
document was improved thanks to the comments and suggestions received
from Fabien Duchene, Benjamin Hesmans and Mohammed Boucadair.
6. Informative References
[Cellnet12]
Paasch, C., Detal, G., Duchene, F., Raiciu, C., and O.
Bonaventure, "Exploring Mobile/WiFi Handover with
Multipath TCP", ACM SIGCOMM workshop on Cellular Networks
(Cellnet12) , 2012,
<http://inl.info.ucl.ac.be/publications/
exploring-mobilewifi-handover-multipath-tcp>.
Bonaventure Expires January 7, 2016 [Page 7]
Internet-Draft MPTCP ADDR July 2015
[I-D.boucadair-behave-dns-a64]
Boucadair, M. and E. Burgey, "A64: DNS Resource Record for
IPv4-Embedded IPv6 Address", draft-boucadair-behave-dns-
a64-02 (work in progress), September 2010.
[I-D.eardley-mptcp-implementations-survey]
Eardley, P., "Survey of MPTCP Implementations", draft-
eardley-mptcp-implementations-survey-02 (work in
progress), July 2013.
[I-D.ietf-mptcp-rfc6824bis]
Ford, A., Raiciu, C., Handley, M., and O. Bonaventure,
"TCP Extensions for Multipath Operation with Multiple
Addresses", draft-ietf-mptcp-rfc6824bis-04 (work in
progress), March 2015.
[I-D.li-dnsext-ipv4-ipv6]
Li, L., Li, Z., and X. Duan, "DNS Extensions to Support
IPv4 and IPv6", draft-li-dnsext-ipv4-ipv6-02 (work in
progress), October 2009.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC
793, September 1981.
[RFC1323] Jacobson, V., Braden, B., and D. Borman, "TCP Extensions
for High Performance", RFC 1323, May 1992.
[RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic
Update", RFC 3007, November 2000.
[RFC3849] Huston, G., Lord, A., and P. Smith, "IPv6 Address Prefix
Reserved for Documentation", RFC 3849, July 2004.
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Resource Records for the DNS Security Extensions",
RFC 4034, March 2005.
[RFC5737] Arkko, J., Cotton, M., and L. Vegoda, "IPv4 Address Blocks
Reserved for Documentation", RFC 5737, January 2010.
[RFC6182] Ford, A., Raiciu, C., Handley, M., Barre, S., and J.
Iyengar, "Architectural Guidelines for Multipath TCP
Development", RFC 6182, March 2011.
[RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure,
"TCP Extensions for Multipath Operation with Multiple
Addresses", RFC 6824, January 2013.
Bonaventure Expires January 7, 2016 [Page 8]
Internet-Draft MPTCP ADDR July 2015
[TMA2015] Hesmans, B., Hoang Tran-Viet, ., Sadre, R., and O.
Bonaventure, "A first look at real Multipath TCP traffic",
TMA 2015 , April 2015,
<http://inl.info.ucl.ac.be/publications/
first-look-real-multipath-tcp-traffic>.
Author's Address
Olivier Bonaventure
UCLouvain
Email: Olivier.Bonaventure@uclouvain.be
Bonaventure Expires January 7, 2016 [Page 9]
