Network Working Group D. Crocker Internet Draft Brandenburg draft-crocker-mast-proposal-01.doc InternetWorking Expires: <2-04> September 16, 2003 MULTIPLE ADDRESS SERVICE FOR TRANSPORT (MAST): AN EXTENDED PROPOSAL STATUS OF THIS MEMO This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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. COPYRIGHT NOTICE Copyright (C) The Internet Society (2003). All Rights Reserved. ABSTRACT Classic Internet transport protocols use a single source IP address and a single destination IP address, as part of the identification for an individual data flow. TCP includes these in its definition of a connection and its calculation of the header checksum. Hence the transport service is tied to a particular IP address pair. This is problematic for multihomed hosts and for mobile hosts. They cannot use more than one, for any single transport association (context). Multiple Address Service for Transport (MAST) defines a mechanism that supports association of multiple IP addresses with any transport association. It requires no change to the Internet infrastructure, no change to IP modules or transport modules in the end-systems, and no new administrative effort. Instead, it defines a layer between classic IP and transport that operates only in the end systems and affects only participating hosts. Additional functionality is obtained by use of a DNS and "presence" rendezvous service. CONTENTS 1. INTRODUCTION 1.1. TERMINOLOGY 1.2. DISCUSSION VENUE 1.3. DOCUMENT HISTORY 2. REQUIREMENTS 3. PROTOCOL 3.1. TRANSACTION MODEL 3.2. ASSOCIATION ATTRIBUTES 3.3. THE INIT OPERATION 3.4. THE SET OPERATION 3.5. THE PROBE OPERATION 3.6. THE SHUT OPERATION 3.7. THE ERR OPERATION 4. TRANSFER SERVICE 5. SOURCE VALIDATION 6. RENDEZVOUS 6.1. DNS 6.2. PRESENCE 7. PATH SELECTION 8. IMPLEMENTATION 8.1. TYPICAL TRANSPORT INTERFACING 8.2. MAST THROUGH NAT 8.3. MAST AGENT 9. SECURITY CONSIDERATIONS APPENDIX A. ACKNOWLEDGEMENTS B. REFERENCES C. AUTHOR'S ADRESS D. FULL COPYRIGHT STATEMENT INTRODUCTION Classic Internet transport protocols use a single source IP address and a single destination IP address, as part of the identification for an individual transport data flow. For example, TCP includes these in its definition of a connection and its calculation of the header checksum. Hence a classic transport association is tied to a particular IP address pair. This is problematic for multihomed hosts and for mobile hosts. Both have access to multiple IP addresses, but they are prevented from using more than one within an existing transport exchange. For a host to use a different IP address pair, participants must initiate a new exchange. In the case of TCP, this means a new connection. In recent years, there have been efforts to overcome many of these limitations, through different approaches at different places in the Internet architecture. Some modify the IP infrastructure, with embedded redirection services. Some define transport enhancements to support a set of addresses directly, and some define a layer between classic IP and classic transport. Each of the existing proposals has notable limitations in functionality, implementation, deployment or use. A discussion of the architectural choices and summary of existing multiaddressing projects is in [CHOICE]. Multiple Address Service for Transport (MAST) supports association of multiple IP addresses during the life of any transport instantiation, by defining a layer between IP and transport. It operates only in the end systems and affects only participating hosts. MAST does not require modification to the Internet infrastructure and does not require modification to any host's IP or transport modules, although improved functionality can be obtained with some changes. Further, MAST works with existing IPv4 and IPv6 transport services and it is useful to any two hosts that try to use it with each other. It does not define any new naming or addressing structure. It has no additional packet header overhead and minimal additional packet-processing overhead. It employs existing administrative structures. Hence MAST has a low barrier to adoption and use, while permitting more advanced functions with more extensive adoption and modification. MAST may be invoked at any time, before or during a transport association. A host may initiate and conduct a classic, single IP- pair TCP connection. It may then separately query for remote host support of MAST and initiate a MAST exchange to be used by that connectivity. Either participant is then free to add or remove addresses. Of course, use of MAST may instead be performed before a transport context is established, so that future contexts immediately have access to multiple IP addresses. For a multihomed host, it will be reasonable to associate multiple IP addresses with a transport context at the time the first context between that host-pair is initiated. For a mobile host, addresses may be added and removed as the host moves across the Internet fabric, acquiring and losing use of different IP addresses. Over the life of a mobile transport context, different addresses might be active at different times. Support is provided for continuation of service across complete connectivity interruptions to mobile hosts, when a host's set of available IP addresses becomes empty and the host later re- acquires a usable IP address. NOTE: The MAST proposal exploits the considerable HIP work done to uncover usability issues and edge conditions. MAST suggests the same core functionality as HIP and LIN6, and a similar approach, but uses a simpler protocol, with a somewhat narrower functional focus. 1.1. Terminology This proposal considers a method that will enable an endpoint (host) to use multiple addresses during single application associations (sessions). "Agent" refers to a forwarding service that represents an endpoint for multiaddressing. For mobility, the agent resides on the "home" network and relays datagrams to the endpoints actual location on the Internet. The endpoints are modified to support this forwarding technique. For multihoming, an agent hides the presence of multiple addresses from the endpoint located on the local network. "Mobility" refers to the availability of different addresses over time. This may even include discontinuities, with no available addresses, at times. It also may include overlapping availability of addresses. Interestingly, this looks the same as multihoming. "Multihoming" refers to the availability of multiple addresses simultaneously. It is typically used to refer to multiple network attachments for a host, but works equally well for multiple upstream network attachments by the local network, when the different upstream addresses are visible to the host. Interestingly, multihomed environments often must support dynamic changes, such as when adding a new upstream provider. Therefore, multihoming can include mobility features and mobility can include multihoming features. "Path discovery" provides a sender with the means for learning about the addresses from which they can send. "Path selection" is required when more than one address is available to the sender. Although the sender is limited to specifying an address, rather than a path, it appears that thinking of it as path selection aid consideration of solutions. In effect, it formulates the selection task as being similar to the job of routers. Route formulation is mature technology, so that this aspect of multiaddress processing will be tractable, if not straightforward. "Rendezvous" permits a host that is initiating an association to find the target of the association, such as a client finding a server. "Finding" means obtaining a valid address for the target. A public process is required for rendezvous. The primary Internet mechanism for rendezvous has been the Domain Name Service (DNS). The DNS used long, variable-length strings (names) and is tailored for large-scale rendezvous with names and addresses (mappings) that change infrequently. 1.2. Discussion Venue Discussion and commentary are encouraged about the topics presented in this document. The preferred forum is the <mailto:email@example.com> mailing list, for which archives and subscription information are available at <http://ietf.org/html.charters/multi6-charter.html>. 1.3. Document History -00 Initial proposal. Basic concepts. Heavy reliance on SCTP and DCCP for style of solutions and implied detail. -01 Substantial reorganization. Added more detail to MAST, including rendezvous and agent, adjunct services Extended discussions about alternative proposals and architectural issues, moved to -analysis- draft. Removed explicit SCTP/DCCP usage. Removed NAT references from architecture discussions. 2. REQUIREMENTS MAST has four requirements: a) The goal for this service is to support the use of multiple IP addresses by either participant in a transport association. b) The service should require no changes to the IP network infrastructure, to the IP layer in end-systems, or to the transport layer in the end-systems. All knowledge of the service, and all activity about it, must reside only in the end-systems using it. In order to avoid start-of-association operation, the service must support operation of classic transport associations, with post-hoc introduction of the multiaddress mechanism. c) The service must be resilient against classic, basic security threats, especially spoofing (association hijacking). d) The service must operate across administrative and operational boundaries and across address translation boundaries (NAT). 3. PROTOCOL This section discusses MAST operations between participating hosts. 3.1. Transaction model MAST uses a simple request/response. Each request receives a response. The response forms the basis of MAST transaction reliability. A request is retransmitted when a response is not received. Retransmission rules use the usual exponential backoff. <STATE As guidance about the association DIAGRAM> relationship between two participating MAST hosts, SCTP Section 4, "SCTP Association State Diagram" provides a useful, starting framework. See [SCTPMOB] for discussion of mobility enhancements that are applicable to MAST. 3.2. Association Attributes An MAST association is between a pair of hosts, defined by endpoint identifiers, an association label and a transaction sequence identifier. It comprises a domain name double, an Association Nonce double, and a transaction sequence number (TSN) double: Endpoint Globally unique, macro-labels identifiers: comprising a domain name for each host Endpoint Association nonce, with cryptographic association protection against hijacking. It is an label: internal identifier for the MAST association; it comprises a random value, such as defined in Section 6.4.2, "Connection Nonce Feature" and used in Section 6.4.3, "Identification Option", in [DCCP]. Also see [RAND]. Sequence A Transaction Sequence Number (TSN) label: indicates data flow during the association and is used for detecting duplicates, detecting missing data, and correlating responses NOTE: More complex association behaviors are possible, such as permitting specification of address subsets for different transport context. This level of sophistication is beyond the scope of the current effort, but will be interesting to explore after a basic capability is achieved. 3.3. The INIT Operation At the beginning of a MAST session, each host sends an "init" element, to create a host-pair association and define the initial set of valid addresses that may be used. The association is fully established after each host has received an acknowledgement to the "init" operation that it sent. The "init" operation includes: * Sender and Receiver domain names * Association Nonce * TSN * List of sender IPv4 and IPv6 addresses 3.4. The SET Operation When a host wants to specify a new list of its own IP addresses, supported in this MAST association with the other host, it sends a "SET" operation to the other host. This function is isomorphic with the INIT operation, except that it uses the existing "Association Nonce" and continues the existing TSN sequence. The domain names must be the same as were used in the "init" operation for this association. A SET operation may occur after a complete interruption of service, such as when a mobile host has not had connectivity for a time, and then reacquires access to the network. In this case, the set of sender addresses is likely to have no members in common with the set that was valid before the interruption. NOTE: A complete list of valid addresses is included, rather than specifying only incremental changes. The list of valid addresses is small and does not require the synchronization complexity of an incremental function. 3.5. The PROBE Operation Status of the association is queried with the "probe" operation. It serves three functions: * Permit a sender to discover the IP address and port number, being presented to a receiver, if subject to NAT transformations; the receiving MAST participant responds with the sender's IP address and port number it received in the IP datagram for the PROBE operation. * Confirm the continued utility of the destination address used for the PROBE operation. * Provide an association keep-a-live. The "probe" operation includes: * Association Nonce * TSN * Sender and Receiver IP addresses The IP addresses in the "probe" operation are the same as are specified by the sender in the containing IP datagram. The "probe response" operation includes: * Association Nonce * TSN * Received MAST Probe-level Sender and Receiver IP addresses * Received IP-level Sender and Receiver IP addresses 3.6. The SHUT Operation The SHUT operation terminates use of MAST between a host-pair; it uses a 3-way graceful close, with no half-open state. The "shut" operation includes: * Association Nonce * TSN * Sender and Receiver domain names 3.7. The ERR Operation ERR elements are sent, in MAST, when there is an error. The "err" operation includes: * Association Nonce * TSN * Error information 4. TRANSFER SERVICE The MAST control exchange has modest transfer (transport) requirements, except that it must itself be able to operate by using multiple IP addresses for each host. Transactions are small and are expected to be infrequent. However they must be reliably delivered, and they must be secure, with respect to redirection and replay attacks by third parties. A simple use of UDP will suffice, with MAST responses providing the needed transfer acknowledgement. The full specification will provide for retransmission controls. Security is built into the MAST protocol, rather than its transfer service. 5. SOURCE VALIDATION The minimal level of implicit source validation that exists within existing transport services' use of IP is eliminated with multiaddressing. This invites hijacking attacks. At the start of an association, MAST establishes association nonce that is used for later exchanges. This nonce is created while only one address is in force. The method of establishing the nonce will follow the lines of PBK, SCTP or DCCP, as dictated by the limited security requirements to prevent hijacking. 6. RENDEZVOUS How does one endpoint find another? The current answer is DNS. However multiaddressing introduces some challenges. Classic DNS use permits finding a set of addresses associated with a domain name. For finding a static, multihomed target, this is probably sufficient. The fact that the initiator is mobile can be communicated to the target by the initiator. However when the target is mobile, an additional support mechanism is needed. This section defines an adjunct service to finding mobile targets. 6.1. DNS Rendezvous with mobile targets is supported through a two-stage process. A domain name is used as the stable, public EID. An SRV record is defined to reference a dynamic "presence" service through which an endpoint can register its current set of IP addresses. 6.2. Presence The requirement to discover current IP addresses for an endpoint, and to be notified when they change, suits existing presence service models rather nicely. MAST is defined to use the presence service available through [XMPP]. The definition of this mechanism will be for standard XMPP, with some addressing conventions to specify the target system's domain name at a particular presence server. Development of the detailed specification may lead to choosing a different service. However, dynamic rendezvous is an adjunct function for MAST. Hence it is not essential to develop this capability for initial use of the service. 7. PATH SELECTION Having gained access to the list of IP addresses by which a destination host may be reached, a sender must select one, for the next set of data. As with any dynamic resource selection opportunity, the choice of schemes is extensive and can be quite sophisticated. However until there is experience with the basic dynamics of this service, conservative usage models are encouraged. As with SCTP, the conservative approach is to choose a primary address and use others as alternatives only to ensure robustness to the association. Periodic use of the PROBE operation to each addresses that the other side purports to have available will provide basic path availability and performance data. 8. IMPLEMENTATION The MAST protocol only provides for controlled and protected exchange of address lists. The utility of these lists hinges on their integration into host networking stack services. 8.1. Typical Transport Interfacing This discussion considers addition of MAST to an existing Internet protocol stack. It is possible to integrate MAST more tightly and efficiently, but this is not an immediate concern for early adoption of the service. MAST must be added to a host implementation of Internet Protocol and associated transport services, in a way that is transparent to the IP module and the transport modules. It is injected between IP and transport. Interfacing to IP transparently is straightforward. For classic transport services that use IP addresses, it is necessary to present a single, consistent address during the life of the association. When MAST is invoked after the start of a transport association, the transport service will already have a particular address that it associates with the other participant. In this case, it is easiest to map the packets being handed up to the transport layer, from additional addresses into the original one. Another approach is to make all destination addresses appear to the transport service as coming from an internally allocated address, such as one allocated in [PRIV]. A networking software stack would use public IP addresses for rendezvous functions, but transport would re-use addresses from this private, internal address space. 8.2. MAST through NAT Network Address Translation [NAT] devices map one address space into another, typically between an intranet set of host addresses to a smaller set of Internet addresses. In effect, they use port numbers as a means of mapping internal hosts to the smaller set of external addresses. This causes problems for any transport that performs end-system calculations that using IP addresses. The end system does the calculations on one set of addresses, but the NAT device changes an address, so that the calculation by the receiving party will not be correct. Hence, NAT devices also need to know about transport-level use of IP addresses and must adjust the values for those calculations carried in transport (or above) headers. MAST exacerbates this situation, since the mapping between IP address and transport calculations is more complicated. Whereas there used to be only one IP address to worry about, now there can be more. Note the section 4.3 specification of the "probe" operation, to discover NAT transformation on the sender's address. 8.3. MAST Agent Multihoming is often a feature of a network, rather than a host. Hosts often do not know that there are multiple Internet connections, especially when the local network uses internal (private) addressing that is different from the network's public address. In these cases, it might be possible for MAST to be implemented as a feature of the local network's NAT function, rather than in the end-system. Since the NAT is already doing address translation, adding MAST only requires that the NAT query the other end of the communication, to obtain permission to add MAST exchanges and multiple addresses. 9. SECURITY CONSIDERATIONS Basic Internet transport protocol activity does not apply any security-related mechanisms, other than relying on having a source addresses be usable as a destination address, to reach the originator of the previous, source data. So, transport-level security is based on address confirmation by virtue of reachability. This reliance on underlying routing behavior has well-known weaknesses. MAST does not to exacerbate or remedy them. However, MAST affects the core of Internet transport associations, by permitting new addresses to be associated with traffic for other addresses. Hence, MAST invites spoofing, redirection, and other manners of evil. The protection against these attacks is to conduct MAST control exchanges over a session that is protected, so that modification to the set of addresses permitted between a host-pair take place over a channel that cannot be spoofed, redirected, or the like. Protection is based on association-time self-authentication. Using the same basis as applies to typical transport session validation, MAST participants exchange protection keys prior modification of the list of acceptable addresses. These keys are then used in later transactions. Section 126.96.36.199, Blind Masquerade, of [SCTP] is incorporated by reference. When stronger protection is needed, [IPsec] or [TLS] should be used for the MAST control channel, or application-level security should be used for the user data flows. APPENDIX A. Acknowledgements Funding for the RFC Editor function is currently provided by the Internet Society. This work derives from discussions in the IETF, in the mid-1990s. A particular technical concern was protecting the address- changing negotiation. The current proposal leverages recent work done on HIP [HIPARC, HIP, MOBHOM], although it makes significantly different technical choices. MAST incorporates a number of the capabilities provided by [SCTP] and [DCCP]. The core ideas for MAST were developed by the author a number of years ago. Christian Huitema independently developed the same technical constructs, at the same time. When upper-layer mapping was first suggested, the most serious concern was for securing the exchange of additional address information, to prevent connection hijacking. Purpose-Built Keys and the mechanisms in SCTP and DCCP nicely resolve this manner, without requiring a massive security infrastructure. As noted earlier in this document, recent work on HIP and LIN6 continue the core construct of an IP/transport wedge for mapping addresses. Commenters on this text include: Marcelo Bagnulo, Iljitsch van Beijnum, Vint Cerf, Spencer Dawkins, Robert Honore, James Kempf , Eugene Kim, Eliot Lear, Pekka Nikander, Erik Nordmark, Tim Shepard, Randall R. Stewart, and Fumio Teraoka, Joe Hildebrand. B. References B.1. Normative [HIPARC] Moskowitz, R., "Host Identity Protocol Architecture", < http://www.ietf.org/internet- drafts/draft-moskowitz-hip-arch-03.txt > [PBK] Bradner, S., Mankin, AS., Schiller, J., "A Framework for Purpose-Built Keys (PBK)", draft- bradner-pbk-frame-06.txt, June 2003 [RAND] Eastlake, D., S. Crocker, J. Schiller. , "Randomness Recommendations for Security", RFC 1750, December 1994. [XMPP] Saint-Andre, P., Miller, J., "XMPP Core", draft- ietf-xmpp-core-18, September 7, 2003 B.2. Non-Normative [CHOICE] Crocker, D., "Choices for Support of Multiaddressing", draft-crocker-mast-analysis- 00.txt, September 16, 2003 [DCCP] Kohler, E., M. Handley, S. Floyd, J. Padhye, "Datagram Congestion Control Protocol (DCCP)", draft-ietf-dccp-spec-04.txt, 30 June 2003 [EID] Chiappa, J.N., "Endpoints and Endpoint Names: A Proposed Enhancement to the Internet Architecture", <http://users.exis.net/~jnc/tech/endpoints.txt>, 1999 [ETCP] Zhang, B., Zhang, B., Wu, I., "Extended Transmission Control Protocol (ETCP) Project-- Extension to TCP for Mobile IP Support", <http://www.cs.ucla.edu/~bzhang/etcp/report.html > [HIP] Moskowitz, R., "Host Identity Protocol Architecture", < http://www.ietf.org/internet- drafts/draft-moskowitz-hip-arch-03.txt > Moskowitz, R., "Host Identity Protocol", <ietf- id: draft-moskowitz-hip-07> Nikander, P., "End-Host Mobility and Multi- Homing with Host Identity Protocol", < http://www.ietf.org/internet-drafts/draft- nikander-hip-mm-00.txt> [IPSEC] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998 [LIN6] Teraoka, F., Ishiyama, M., Kunishi, M., "LIN6: A Solution to Mobility and Multi-Homing in IPv6", draft-teraoka-ipng-lin6-02.txt, 24 June 2003 [MOBHOM] Nikander, P., "End-Host Mobility and Multi- Homing with Host Identity Protocol", < http://www.ietf.org/internet-drafts/draft- nikander-hip-mm-00.txt> [NAT] Egevang, K., and P. Francis, "The IP Network Address Translator (NAT)", RFC1631, May 1994 [NSRG] Lear, E., Droms, R., "What's In A Name: Thoughts from the NSRG", draft-irtf-nsrg-report-09.txt, March 2003 [MIP] Perkins, C., "IP Mobility Support", RFC 2002, October 1996 Johnson, D., Perkins, C., Arkko, J., "Mobility Support in IPv6", draft-ietf-mobileip-ipv6- 24.txt, June 30, 2003 Bagnulo, M., Garcia-Martinez, A., Soto, I., "Application of the MIPv6 protocol to the multi- homing problem", draft-bagnulo-multi6-mnm-00, February 25, 2003 [PRIV] Rekhter, Y., B. Moskowitz, D. Karrenberg, G. J. de Groot, and E. Lear, "Address Allocation for Private Internets", RFC 1918, February 1996. [SCTP] L. Ong, and J. Yoakum "An Introduction to the Stream Control Transmission Protocol (SCTP)", <http://ietf.org/rfc/rfc3286.txt?number=3286>, May 2002 Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., Paxson, V., Stream Control Transmission Protocol", RFC 2960, October 2000 [SCTPMOB R. Stewart, et al, "Stream Control Transmission ] Protocol (SCTP) Dynamic Address Reconfiguration", draft-ietf-tsvwg-addip-sctp- 07.txt, February 26, 2003 [TCPMH] Matsumoto, A. Kozuka, M., Fujikawa, K., Okabe, Y., "TCP Multi-Home Options", draft-arifumi-tcp- mh-00.txt, 10 Sep 2003 [TLS] Dierks, T., C. Allen , "The TLS Protocol Version 1.0", RFC 2246, January 1999. C. Author's Adress Dave Crocker Brandenburg InternetWorking 675 Spruce Drive Sunnyvale, CA 94086 USA tel: +1.408.246.8253 firstname.lastname@example.org D. Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.