Network Working Group P. Sarolahti Internet-Draft HIIT/ICSI Intended status: Experimental November 20, 2009 Expires: May 24, 2010 Multipath Interface in the Socket API draft-sarolahti-mptcp-af-multipath-00.txt Abstract This document specifies a new address family to be used for sockets that are bound to more than one IP address, as motivated by the Multipath TCP work in the IETF. The goal is to use the same set of function calls as traditionally, but by new address family make it possible for them to express multiple addresses to connect or bind to. The document gives a high-level definition of the behavior of the traditional function calls, but a detailed specification of the API syntax is not in the scope of this document. 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), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on May 24, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. Sarolahti Expires May 24, 2010 [Page 1] Internet-Draft AF-Multipath November 2009 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 BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. The Multipath Address Family . . . . . . . . . . . . . . . . . 4 4. Behaviour with Different Networking Functions . . . . . . . . . 6 4.1. Bind . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4.2. Connect . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4.3. Name resolution . . . . . . . . . . . . . . . . . . . . . . 7 4.4. Get Local Address / Get Remote Address . . . . . . . . . . 7 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 6.1. Normative References . . . . . . . . . . . . . . . . . . . 8 6.2. Informative References . . . . . . . . . . . . . . . . . . 8 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9 Sarolahti Expires May 24, 2010 [Page 2] Internet-Draft AF-Multipath November 2009 1. Introduction This document proposes a new way to use the socket API to better support protocols that use multiple IP addresses at either end of a connection. The primary motivation for this specification is the ongoing work on Multipath TCP (e.g., [I-D.ford-mptcp-architecture], [I-D.ford-mptcp-multiaddressed]), but the same API can be used with any other protocol that runs multiple addresses on a single socket. One of the design goals in this specification is to enable support for multiple addresses in a socket without changing the set of networking function calls available in the system. This design also aims to maintain unchanged semantics with the previously familiar operations to the extent it is possible. Using Multipath TCP with a traditional socket API with IPv4 address family (also known as AF_INET) or IPv6 (AF_INET6) address family can be problematic, as discussed in the API considerations document [I-D.scharf-mptcp-api]. The socket API was designed with an assumption that a socket is using just one address, with this address being explicitly visible to the applications. When the API is used with a protocol that uses multiple addresses for communication, defining the semantics of existing function calls that directly refer to one IP address becomes problematic, potentially making the existing applications behave defectively when using the legacy socket API with Multipath TCP. While the motivation of Multipath TCP to operate on unmodified legacy APIs is well understandable, eventually a more expressive API is needed to better manage connections using multiple addresses at either end. This document specifies a new multipath-compatible address family to be used with the familiar socket operations, called AF_MULTIPATH. This address family is composed as a sequence of one or multiple elements that are each structured in the same way as one of the existing address families supported by the system, such as AF_INET or AF_INET6. At the same time, this lets the application indicate if it supports the use of multiple addresses for the socket, for example using multipath TCP. One advantage of the Multipath Address Family is that it supports using different address families, such as IPv4 or IPv6, in the same address set, thereby enabling dual-stack functionality between both IPv4 and IPv6 interfaces (although we note that IPv4 addresses can be expressed as a AF_INET6 structure). The AF_MULTIPATH address family could be used also with other protocols capable of multihoming, for example SCTP [RFC4960]. It may possibly be applicable also to shim-layer approaches to multihoming such as SHIM6 [RFC5533] or HIP [RFC5206], although these are based on a different philosophy of splitting locators (IP addresses) from the host identity. Different API extensions for multihomed protocols Sarolahti Expires May 24, 2010 [Page 3] Internet-Draft AF-Multipath November 2009 have been specified (or are being worked on), for example one using a set of socket options [I-D.ietf-shim6-multihome-shim-api], and another extending the set of socket operations in the socket API [I-D.ietf-tsvwg-sctpsocket]. This document deliberately avoids both approaches, choosing a method that does not require adding several new socket options or socket operations. The goal has been to develop a mechanism that fits with the existing operations in the socket API. 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 [RFC2119]. 3. The Multipath Address Family Multipath address family (AF_MULTIPATH) is composed of a sequence of addresses, each expressed using one of the existing address family formats supported in the system. A desirable behavior would be that in a system that supports the multipath address family, opening a socket using one of the traditional single-address families should be taken as an indication that multiple addresses should not be used for that socket. However, to allow migration period for legacy applications that are not converted to use the new address family, but would benefit from multipath communication, an additional option switch may be needed to control the behavior on traditional single- address families. The address family is structured according to the generic sockaddress structure as follows. The fields are given in network byte order. o Length (8 bits) o Address family (=AF_MULTIPATH) (8 bits) o Connection identifier (32 bits) (TODO: discuss if this is needed, or is the socket descriptor sufficient) o Number of addresses (8 bits) o Address 1 o Address 2 Sarolahti Expires May 24, 2010 [Page 4] Internet-Draft AF-Multipath November 2009 o .... o Address N Each of the address records above takes the generic sockaddress format, i.e.: o Length (8 bits) o Address family (8 bits) o Address (...i.e., the rest of sockaddr structure as defined by the address family...) When the API is used with Multipath TCP, the Connection identifier can be equal to the sender token used by Multipath TCP [I-D.ford-mptcp-multiaddressed]. Connection identifier is only used locally, and it is not intended that this identifier is communicated over the network. Connection identifier MUST be unique among all active connections in the host, and connection identifier MUST NOT be changed during the lifetime of the Multipath TCP connection. The same connection identifier SHOULD NOT be reused immediately after a socket is closed. Similar semantics are applied also to other multipath protocols, if AF_MULTIPATH is used with them. While the connection identifier is stable throughout the connection lifetime, in a dynamic multipath connection the other fields can change over time: new addresses may be added and earlier addresses can be removed. In today's system with Posix API the address family is commonly either AF_INET or AF_INET6, but the design is not limited to these address families. Depending on the address family, the address would typically in a Posix system be structured as sockaddr_in or sockaddr_in6 structure, with the length set appropriately. Different address families can be combined in a single AF_MULTIPATH record. There is a tradition that the IPv4/IPv6 address family is also used to indicate the protocol family in the socket call, originally intended to separate UNIX internal protocols from Internet protocols or ISO protocols. It is unclear (to the author) why the evolution has lead to use two separate values to indicate IPv4 and IPv6 protocols in the protocol family parameter of the socket call. It would seem appropriate that as dual-stack IPv4/IPv6 implementations are commonplace, a single protocol family would be used for opening a socket for any Internet protocol. Sarolahti Expires May 24, 2010 [Page 5] Internet-Draft AF-Multipath November 2009 4. Behaviour with Different Networking Functions This section defines the intended behavior of commonly used network operations when used with AF_MULTIPATH address family. The section gives a high-level definition of the operations to be applied as appropriate in different application environments. 4.1. Bind An AF_MULTIPATH socket can bind to several addresses using a single call. It is possible to use wildcard ("Any") address in some of entries of the address set. Multiple "Any" addresses could allow binding several ports to the same socket, although this does not seem a sensible action to take. AF_MULTIPATH can also contain just one address entry, in which case the behavior is similar to traditional single-homed bind. On return, the function call should indicate how many addresses were successfully bound, using error codes to indicate that binding failed to all addresses. "Get Local Address" operation (getsockname in Posix) can be used to investigate which addresses were successfully bound. When binding a new socket with no prior AF_MULTIPATH entry, connection identifier MUST be set to 0. This call can also be used by an application to indicate that new local addresses should be added to the connection. In this case connection identifier refers to an existing connection. If connection identifier is non-zero and such connection does not exist in the system, the call returns with failure. 4.2. Connect An AF_MULTIPATH socket can give multiple addresses to connect to, assuming the addresses belong to the same host. The protocol may need to activate these connections one at a time, if the protocol logic does not permit connecting to multiple addresses simultaneously. On return, the function call should indicate how many of the addresses were successfully connected, or an error code. It is expected that commonly this call is used together with name resolution, as described below. "Get Remote Address" (getpeername) operation can be used to investigate which addresses were successfully connected to. When connecting a new, earlier unconnected socket, connection identifier MUST be set to 0. Application can also indicate by this call, that the protocol stack should try to add new remote addresses to the connection. In this case connection identifier refers to an existing connection. If connection identifier is non-zero and such connection does not exist in the system, the call returns with Sarolahti Expires May 24, 2010 [Page 6] Internet-Draft AF-Multipath November 2009 failure. A consideration: one failure mode is that new address is reachable, but points to a different host. MPTCP MUST be able to detect this before any data gets exchanged. This might be something for the main MPTCP specification to think about, because this seems like a generic MPTCP security issue on connection hijacking. 4.3. Name resolution In a typical usage of a name resolver, multiple addresses may be returned from a name server, and a client cycles through the given addresses until connection is successfully established. Sometimes a client may need to try separately IPv6 addresses and IPv4 addresses, when it is not certain whether IPv6 is supported on the path. When name resolver is called with AF_MULTIPATH enabled, the name server returns the available address records as separate entries in a single AF_MULTIPATH structure. This would mean that the call returns a single AF_MULTIPATH host entry that may contain multiple addresses as specified in the AF_MULTIPATH format. An application may directly place the returned AF_MULTIPATH structure as a parameter of a connect call, indicating that a multipath protocol should try these addresses as subflows of the multipath connection. It is recommended that when resolver receives an AF_MULTIPATH-enabled call, it invokes name server queries for both IPv6 and IPv4 addresses, if both are supported in the system, and records of both types are returned to the application, if available. 4.4. Get Local Address / Get Remote Address These calls operate similarly than originally: they return a sockaddress structure at local or remote end. AF_MULTIPATH address family is returned if it has been used earlier with the same socket. The set of local or remote addresses SHOULD be up-to-date with the currently active set in the protocol implementation. Along with the current addresses, an application learns also about the connection identifier with this call. The connection identifier returned with "Get Remote Address" MUST be the same as the identifier returned with "Get Local Address", since it only has local meaning, and therefore the other end of the connection typically gets entirely different connection identifier for the connection. 5. Security Considerations No additional security threats known because of the multipath address family. Sarolahti Expires May 24, 2010 [Page 7] Internet-Draft AF-Multipath November 2009 6. References 6.1. Normative References [I-D.ford-mptcp-architecture] Ford, A., Raiciu, C., Barre, S., Iyengar, J., and B. Ford, "Architectural Guidelines for Multipath TCP Development", draft-ford-mptcp-architecture-00 (work in progress), October 2009. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 6.2. Informative References [I-D.ford-mptcp-multiaddressed] Ford, A., Raiciu, C., and M. Handley, "TCP Extensions for Multipath Operation with Multiple Addresses", draft-ford-mptcp-multiaddressed-02 (work in progress), October 2009. [I-D.ietf-shim6-multihome-shim-api] Komu, M., Bagnulo, M., Slavov, K., and S. Sugimoto, "Socket Application Program Interface (API) for Multihoming Shim", draft-ietf-shim6-multihome-shim-api-10 (work in progress), October 2009. [I-D.ietf-tsvwg-sctpsocket] Stewart, R., Poon, K., Tuexen, M., Yasevich, V., and P. Lei, "Sockets API Extensions for Stream Control Transmission Protocol (SCTP)", draft-ietf-tsvwg-sctpsocket-19 (work in progress), February 2009. [I-D.scharf-mptcp-api] Scharf, M. and A. Ford, "MPTCP Application Interface Considerations", draft-scharf-mptcp-api-00 (work in progress), October 2009. [RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, September 2007. [RFC5206] Nikander, P., Henderson, T., Vogt, C., and J. Arkko, "End- Host Mobility and Multihoming with the Host Identity Protocol", RFC 5206, April 2008. [RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming Shim Protocol for IPv6", RFC 5533, June 2009. Sarolahti Expires May 24, 2010 [Page 8] Internet-Draft AF-Multipath November 2009 Author's Address Pasi Sarolahti HIIT/ICSI 1947 Center Street (Suite 600) Berkeley, CA 94704 USA Phone: +1 (510) 409 - 9972 Email: pasi.sarolahti@iki.fi URI: http://www.iki.fi/pasi.sarolahti/ Sarolahti Expires May 24, 2010 [Page 9]