Network Working Group D. Crocker Internet Draft Brandenburg draft-crocker-mast-proposal-00.txt InternetWorking Expires: <2-04> August 28, 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 multi-homed hosts and for mobile hosts. Both have multiple IP addresses but cannot use more than one, for any single transport association (context). Multiple Address Service for Transport (MAST) defines a mechanism that transparently supports association of multiple IP addresses with any transport association. It requires no change to the IP infrastructure, and no change to IP modules or transport modules in the end-systems. Instead, it defines a wedge layer between IP and transport that operates only in the end systems and affects only participating hosts. CONTENTS 1. INTRODUCTION 2. IETF BACKGROUND 2.1. HIP 2.2. DCCP 2.3. SCTP 3. REQUIREMENTS 4. FRAMEWORK 4.1. Architectural Model 4.2. Alternative Approaches 4.3. Operation Through Nats 5. MAST FUNCTIONALITY 5.1. Association Attributes 5.2. The INIT Operation 5.3. The SET Operation 5.4. The PROBE Operation 5.5. The SHUT Operation 5.6. The ERR Operation 6. TRANSFER SERVICE 7. ADDRESS SELECTION 8. IMPLEMENTATION 8.1. Typical Transport Interfacing 8.2. Mast Through Nat 8.3. Mast In Nat 9. SECURITY CONSIDERATIONS 10. APPENDIX 10.1. Acknowledgements 10.2. References 10.3. AuthorsĘ Addresses 10.4. Full Copyright Statement 1. 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 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 multi-homed 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. Multiple Address Service for Transport (MAST) defines a mechanism to support association of multiple IP addresses during the life of any transport instantiation. It requires no change to existing transport protocols and no changes to IP. Instead, it defines a wedge layer between IP and transport. It operates only in the end systems and affects only participating hosts. MAST may be invoked at any time, for existing or future transport associations. Hence 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 multi-homed 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: This document is an extended proposal, rather than a fully detailed specification. It defines MAST functionality, nearly to the level of specification. However it leaves some details unresolved, in the belief that they are essential to implementation of the protocol, but not to the initial analysis of its proposal. The proposal also incorporates some critical details by reference and general adaptation, rather than stating then in the detail that is needed for a complete specification. Again, this permits initial analysis but is not sufficient for adoption and implementation. 2. IETF BACKGROUND Support for mobility and multi-homing have been notable challenges within the Internet architecture. Classic connection-based transport services do not mobility directly, nor can they take advantage of multiple access paths accessible through alternate IP addresses. When a host gains a new IP address, transport services can exercise it only with new connections. IETF focus on mobility has split between using DHCP for initial system attachment to the network, versus using infrastructure-based IP forwarding services. In contrast, the current proposal provides support that requires no new infrastructure and no changes to existing protocols. 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]. 2.1. HIP 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 a similar approach, but uses a simpler protocol, with a somewhat narrower functional focus. HIP has a substantial focus on creating and using special security mechanisms. MAST has more somewhat more modest requirements and relies on the kind of protection provided in SCTP. Unlike HIP, MAST does not define a new, global name space. Rather, it employs random, transient identifiers that are known only to the host-pair that use them in MAST. They protect against redirection attacks and support recovery after loss of IP addresses. Existing mechanisms are used for rendezvous and system identification. The HIP Section 3 discussion, Usage Scenarios, provides an excellent description of the environments for which this proposal is intended. However Section 3.2, Location Privacy, is not pursued in MAST. It would be an interesting enhancement over the core requirement, but is inessential to that core. It is likely that this proxy masking capability can be layered on top of the current specification, as a MAST control exchange "relaying" mechanism. Section 3 of [MOBHOM], without section 3.2, is included here, by reference. The section comprises the following sub- sections: 3. Usage scenarios 3.1 End-host mobility 3.2 Location privacy ą 3.3 End-host multi-homing 3.4 Site multi-homing 3.5 Combined mobility and multi-homing 3.6 Network renumbering 3.7 Combined all 2.2. DCCP DCCP is a proposal for an unreliable datagram delivery service. It specifies a connection mechanism that seems particularly robust for protecting MAST against redirection attacks. 2.3. SCTP SCTP is a reliable transport protocol for multiplexed data streams. It includes modern mechanisms for safe initiation of a connection, as well as the necessary tools for reliability and congestion control. It also has a mechanism for communication access to multiple IP addresses between the participation host pair. MAST does not need the general transport mechanisms that are in SCTP, for user data and its reliable transport. Further MAST traffic is expected to comprise few, occasional packets. Hence, the concern for MAST's being congestion- friendly is quite limited. NOTE: For simplicity, this MAST proposal uses a subset of SCTP as references (examples) for its core features. This supplies guidance for basic packet formats, components of functionality, appropriate security techniques, and support for IPv4 and IPv6 addressing. 3. 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. When multiple addresses are stable and pre-existing, the host is called "multi-homed". When the set of usable IP addresses varies over the life of the association, the host is called "mobile". NOTE: When a stable network changes its connectivity to the rest of the Internet -- such as when it changes up-stream providers -- the change can be viewed as a kind of mobility. This is significant, to the extent that MAST can facilitate network migrations to different providers. 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 multi- address mechanism. c) The service must be resilient against classic, basic security threats, especially spoofing, where a third-party attempts to take over the association. d) The service must operate across administrative and operational boundaries and across address translation boundaries (NAT). 4. FRAMEWORK 4.1. Architectural Model The current architecture for transport use of IP addresses makes a direct linkage to a specific IP address pair: Connection (IP.a, Port.l, IP.y, Port.r) +-----------------+ | Port.l | Port.r +-----+ +-----+ | TCP | | TCP | +-----+ +-----+ | IP.a | IP.y +-----+ +-----+ | IP | | IP | +-----+ +-----+ | | | | IP.a IP.f IP.q IP.y This example shows each host being multi-homed. Each must choose a single IP address and bind the connection to it. MAST permits each host to use one, then the other, or both of its available addresses, varying the binding and the use over the life of the connection. Connection (IP.a, Port.l, IP.y, Port.r) +-------------------------+ | Port.l | Port.r +------+ +------+ | TCP | | TCP | +------+ +------+ IP.a | | IP.y |+----+ control +----+| < MAST >-----------< MAST > |+----+ +----+| IP.a,| |IP.q, IP.f | | IP.y +------+ +------+ | IP | | IP | +------+ +------+ | | | | IP.a IP.f IP.q IP.y MAST is a control protocol for the exchange of notification and authorization information, to use additional IP addresses in a given host-pair context. The primary MAST exchange transmits: * A list of current IP addresses supported by the sender Support exchanges: * Establish a host-pair context * Establish relevant authentication between the pair 4.2. Alternative Approaches It is possible to support multi-homing and mobility through a number of different mechanisms. 4.2.1. Application-Level Applications often provide themselves with enhanced infrastructure support services, to compensate for the lower protocol layers that lack the requisite features. A typical example is with reliable data transfer, when using an unreliable datagram service. The obvious difficulty with this approach is that it burdens each new application with re-creating these underlying services. Although there might be some benefit in permitting applications to discover details about multiple-address capabilities, and possibly even to specify some controls over their use, the prevalence of multi-homing and mobility dictate their support in lower layers. 4.2.2. Transport-Level Recent transport protocols, such as SCTP and the proposal for DCCP, provide for the use of multiple IP addresses in a session. This has the benefit of placing the necessary functionality only in end-systems. It well might be the best, long-term architectural choice. However the fact that the functionality is applicable to all transport services suggests that there should be some consideration of the benefit in having IP multi-homing and mobility functionality reside in a single architectural module, separate from any specific transport service. In any case, these new transport protocol efforts cannot affect the considerable installed base of services using older transport protocols, such as TCP and UDP. MAST is designed to work with unmodified versions these protocols and it achieves this functionality without imposing any start-of-association delays. 4.2.3. Session-Level In effect, implementing support in a layer that is above transport, but below the application, is a way of institutionalizing application-level support. The merit of placing multi-homing and mobility support at the session layer is that it can use multiple transport services. The problem with this approach is that a full session layer typically requires replicates substantial portions of the transport service, in order to ensure reliability and in- order data sequencing. This makes the session-level approach notably complicated. 4.2.4. IP-Level Classic approaches to mobility support involve the addition of mechanisms to the IP layer, such as with encapsulating forwarding services. Conceptually, the biggest problem with this approach is that it attempts to take topology-related information -- the IP address -- and use it non-topologically. Operationally, the biggest problems with this approach are that forwarding services are inefficient, multi-layer encapsulation adds complexity, and the service requires infrastructure change. Changing the infrastructure also makes the adoption process much slower and more fragile. 4.2.5. Host Identity Protocol (HIP) HIP takes an approach that has notable similarities to MAST. It creates a "wedge" layer in between IP and Transport. The HIP approach: * Creates a new, globally unique name space * Uses strong, cryptographically based protocol details, overloading some HIP functionality with security functionality * Is tied significantly to [IPSEC] * Creates a new DNS RR entry * Requires a Rendezvous server for mobility support * Requires that NATs be aware of HIP Many of the HIP features are appealing, such as the cleanliness of the architectural model depicted in Section 4 of [HIPARCH]. Were the Internet stack being created now, HIP well might be an excellent approach. However retrofitting this approach into the existing, deployed Internet entails serious barriers to adoption. MAST is explicitly designed to impose the minimum change feasible. It seeks to achieve the basic function of supporting multiple addresses between host transport associations. Problems such as rendezvous, flooding and spoofing are significant, but they go beyond the basic requirement of multi-address support. Hence they are deferred for separate solution. MAST takes a more modest approach, with a simpler specification, and permitting easier implementation and adoption. Consequently, MAST differs from the list of HIP requirements in that it: * Uses a name space that is transient and local to the host-pair * Uses existing, SCTP security mechanisms * Has no special requirements on DNS * Defers the question of rendezvous * Is transparent to NATs In general, addition of a DNS SRV record can be useful for achieving efficient rendezvous, with or without mobility. It permits participants to know whether a service is supported by its partner, without requiring a probe packet. However this enhancement to DNS data structures is not required. The same assessment applies to pursuit of a separate rendezvous service. Security functions that are essential to proper operation of MAST are adapted from those used in SCTP, for the same purpose. 4.3. Operation Through NATs A Network Address Translation (NAT) device maps between one set of addresses, and another. In typical cases, addresses from the interior of a network are mapped to different ports on a single, public address on the outside of the network. Obviously this mapping task must be performed with knowledge of transport protocol details and must adjust transport headers, as well as IP-level addresses. Stateless NATs need no modification to support MAST, in that the NAT will simply do its usual task of replacing IP addresses and adjusting dependent transport headers accordingly. However, there is the basic question of whether a sending MAST participant correctly knows its own addresses. In this, MAST suffers the same difficulty as other application protocols that embed IP addresses. ISSUE: How does this limit real-world utility of the protocol? Interestingly, MAST can be implemented as a NAT that is internal to an end-system. That is, one can model the implementation of MAST as a NAT activity between the IP layer and the transport layer inside the host. It takes one set of addressing attributes on one side and maps them to another set on the other side. ISSUE: Is this perspective useful? Does it suggest additional benefits or problems? 5. MAST FUNCTIONALITY This section discusses MAST operations between participating hosts. Since this is a proposal, rather than a detailed specification, discussion is about basic functionality, with examples drawn from SCTP to illustrate how the function can be performed in a way that is appropriate for MAST. NOTE: As guidance about the association relationship between two participating MAST hosts, SCTP Section 4, "SCTP Association State Diagram" provides a useful framework. See [SCTPMOB] for discussion of mobility enhancements that are applicable to MAST. 5.1. Association Attributes An MAST association is between a pair of hosts. It comprises a domain name double, an Association Nonce double, and a transaction sequence number (TSN) double. * It has a globally unique, macro-label comprising a domain name for each host, and an internal, association label comprising an Association Nonce double, with one from each host. * The Association Nonce is an 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]. * The TSN 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. 5.2. 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. NOTE: SCTP Section 3.3.2, "Initiation (INIT)" defines a mechanism that provides this capability. The "init" operation includes: * Sender Association Nonce * TSN * Sender and Receiver domain names * List of sender IPv4 and IPv6 addresses 5.3. 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. NOTE: 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. 5.4. 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 5.5. 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. NOTE: SCTP Section 3.3.8 "Shutdown Association (SHUTDOWN)" defines a mechanism that provides this capability. The "shut" operation includes: * Association Nonce * TSN * Sender and Receiver domain names 5.6. The ERR Element ERR elements are sent, in MAST, when there is an error. NOTE: SCTP Section 3.3.10, "Operation Error (ERROR)" defines a mechanism that provides this capability. The "err" operation includes: * Association Nonce * TSN 6. 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. NOTE: As appropriate, algorithms and services can be adapted from SCTP, to provide reliable, secure exchange of address information by MAST. 7. ADDRESS 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 in NAT Multi-homing 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 11.2.4.2, 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. 10. APPENDIX 10.1. Acknowledgements Funding for the RFC Editor function is currently provided by the Internet Society. The original ideas for MAST were developed a number of years ago. Christian Huitema independently developed the same technical constructs, at the same time. When a wedge layer was first suggested, the most serious concern was for securing the exchange of additional address information. The mechanisms in SCTP nicely resolve this manner, without requiring a massive security infrastructure. As noted earlier in this document, recent work on HIP continues the core construct of an IP/transport wedge for mapping addresses. 10.2. References 10.2.1. Normative [DCCP] Kohler, E., M. Handley, S. Floyd, J. Padhye, "Datagram Congestion Control Protocol (DCCP)", draft-ietf-dccp-spec- 04.txt, 30 June 2003 [HIPARC] Moskowitz, R., "Host Identity Protocol Architecture", < http://www.ietf.org/internet-drafts/draft- moskowitz-hip-arch-03.txt > [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> [RAND] Eastlake, D., S. Crocker, J. Schiller. , "Randomness Recommendations for Security", RFC 1750, December 1994. [SCTP] L. Ong, and J. Yoakum "An Introduction to the Stream Control Transmission Protocol (SCTP)", , May 2002 [SCTPMOB] R. Stewart, et al, "Stream Control Transmission Protocol (SCTP) Dynamic Address Reconfiguration", draft-ietf-tsvwg- addip-sctp-07.txt, February 26, 2003 10.2.2. Non-Normative [HIP] Mostkowitz, R., "Host Identity Protocol", [IPSEC] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998 [NAT] Egevang, K., and P. Francis, "The IP Network Address Translator (NAT)", RFC1631, May 1994 [PRIV] Rekhter, Y., B. Moskowitz, D. Karrenberg, G. J. de Groot, and E. Lear, "Address Allocation for Private Internets", RFC 1918, February 1996. [TLS] Dierks, T., C. Allen , "The TLS Protocol Version 1.0", RFC 2246, January 1999. 10.3. AuthorsĘ Addresses Dave Crocker Brandenburg InternetWorking 675 Spruce Drive Sunnyvale, CA 94086 USA tel: +1.408.246.8253 dcrocker@brandenburg.com 10.4. 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.