Network Working Group S. Guha Internet-Draft P. Francis Expires: August 19, 2007 Cornell U. February 15, 2007 Requirements for the End-Middle-End Research Group draft-guha-emerg-requirements-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of 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 August 19, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract This document proposes a set of requirements for the IRTF EME (End Middle End) research group. The intent is to serve as a starting point for discussions about EME requirements. Table of Contents 1. Introduction 2. Terminology 3. Requirements 3.1. Authentication 3.2. Authorization 3.3. Privacy and Confidentiality 3.4. Middlebox Control 3.5. Steering, Anycast, and Mobility 3.6. Protocol Negotiation 3.7. Multi-Homing 3.8. Multicast 3.9. Scalability, Performance and Robustness 3.10. Deployability 4. Acknowledgments 5. References 5.1. Normative References 5.2. Informational References Authors' Addresses Intellectual Property and Copyright Statements 1. Introduction The Internet originally offered a small set of critical services: (1) provide long-term stable user-friendly names and (non-user-friendly) addresses to identify specific applications running on specific machines (DNS names, IP addresses, and ports), and (2) provide the ability to transmit and receive a stream of bytes (TCP) or datagrams (UDP) to and from the identified applications. Note that by "the Internet", we mean the set of services that is commonly available to an application by the network protocols in the OS and the network (i.e. the sockets interface). Over the years, this minimal set of services has deteriorated. One reason for this is the fact that NAT breaks the end-to-end semantics of addressing. In addition, endpoints are no longer the sole stake- holder in Internet connections. Networks too have a stake in the communications through the network. Firewalls allow networks to assert their policy in an ad hoc way and prevent certain endpoints from communicating. This is of course a feature, not a bug, at least in the mind of the firewall operator. The address/port style of connection establishment does not provide adequate information for firewalls to make decisions, and as a result firewalls in many cases err on the side of caution and block legitimate connections. Beyond the connection establishment problems created by NATs and firewalls, networks often wish to insert middleboxes into the path, for instance web caches. Sometimes these middleboxes are desired by the endpoints, sometimes they are not. Either way, the fact that the Internet does not explicitly support discovery and use of middleboxes is a serious limitation. The broad goal of the EME research group is to research naming and connection establishment schemes that satisfy the security and privacy needs of endpoints and the middle. Beyond this, however, there are a number of features that may be supported by new naming and connection establishment protocols, including mobility, multi- homing, anycast, multicast, and DoS protection. As a result, it behooves us to consider these features as part of the EME set of requirements, so as to adequately explore the design space. It may very well turn out that a protocol that satisfies all the requirements set forth is overly complex, performs poorly, or requires too much change to the existing infrastructure. Ultimately a protocol design must balance goals of simplicity, performance, and deployment cost against these requirements, and we may therefore choose not to satisfy all requirements. 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]. Endpoint: An endpoint identifies an application process engaged in two-party or multi-party communication. An endpoint may have multiple connections (or flows) with multiple other endpoints. An endpoint may have local policy that governs which other endpoints may communicate with it. Flow: A flow refers to application data exchanged between two or more endpoints. A flow may be a reliable, in-order, stream of bytes, or datagrams delivered in a best-effort fashion. Middlebox: A middlebox refers to a network element which involves itself in communication between endpoints by performing functions apart from standard functions of an IP router ([RFC1009]). A middlebox may keep per-flow state or may be stateless. Like endpoints, middleboxes may also have local policy governing which endpoints may communicate over the particular network. Policy: A policy is a rule defined by a network administrator (or endpoint user) that controls how endpoints can communicate over that particular network (or communicate with that particular endpoint). 3. Requirements This section lists the EME research group requirements. The requirements include authentication, authorization, DoS protection, privacy, middlebox control, steering, anycast, mobility, protocol negotiation, multi-homing, multicast delivery, and performance. The current network protocols do not provide adequate semantics or mechanisms for a network ACL service. Among other things, IPv4 addresses are not globally unique, IPv6 addresses can be but are likely to be ephemeral in practice, neither of them are user- friendly, the port number does not adequately identify the application at network firewalls, and the DNS service does not understand enough about the querying user or impending application to know whether or how to answer a query. A name indicates what we seek, an address indicates where it is, and a route indicates how to get there [Shoch78]. IP deals with addresses, DNS provides mnemonics for IP addresses, and BGP distributes routes for IP addresses. The Internet lacks the notion of a name to describe endpoints. REQ-1: Application endpoints MUST be identified by globally-unique, long-term stable, user-friendly names. Globally-unique, long-term stable, user-friendly names allow endpoint users and network administrators to define policy with greater ease. 3.1. Authentication REQ-2: Middleboxes MUST be able to authenticate endpoints, and endpoints MUST be able to authenticate middleboxes that they are aware of. Endpoint and middlebox authentication is necessary for applying policy to Internet flows. Authentication must precede the exchange of application data to protect the application from communicating with unauthorized endpoints. In addition to aiding policy enforcement, endpoint authentication protects against impersonation and address spoofing attacks. 3.2. Authorization REQ-3: The Internet MUST allow endpoint administrators (users or otherwise) to control which other endpoints and middleboxes the endpoint can communicate with and how. The Internet MUST allow network administrators to control which endpoints can communicate over that network and how. A flow on the Internet must be subjected to the policy of the endpoints as well as the networks through which the flow is routed. Only flows that are authorized by all stakeholders should be allowed to succeed. There must be mechanisms that allow endpoints and middleboxes to inform each other when a flow violates policy and allow the negotiation of flows that satisfy policies. 3.3. Privacy and Confidentiality REQ-4: The Internet MUST allow anonymous communications (policy permitting). The Internet must allow endpoints to communicate anonymously or allow middleboxes to anonymize endpoint identity; other endpoints and middleboxes, however, may refuse to communicate with anonymous endpoints by policy. REQ-5: The Internet MUST allow endpoints and middleboxes to protect confidential information, and reveal it only to trusted parties when necessary. Confidential information may include endpoint names, network addresses, authentication tokens, encryption keys etc. Endpoints must not be required to reveal their network address to untrusted middleboxes and endpoints. Network addresses must be made available after authentication and authorization as the address can be used to direct a DoS attack to a bottleneck link. The Internet must allow endpoints and middleboxes to require flow encryption for flows observable by unauthorized elements. Depending on policy, trust-model and nature of the middlebox service, encryption may be hop-by-hop between endpoints and intermediate middleboxes, or be end-to-end. 3.4. Middlebox Control REQ-6: Endpoints MUST be able to discover middleboxes, request their services when desired, and be informed when the middle requires that their services be used (i.e. NAT or firewall). Note that it is not a requirement that the middle MUST inform endpoints of all middleboxes in the path, only that there be a way to do so should the middle desire it. Endpoints may not be aware of middlebox services they must take advantage of in order to establish a flow such as a NAT device deployed by network administrators to extend the network address space. In other cases, an endpoint may wish flows to be blocked far away from a bottleneck link to defend against a DoS attack. In yet other cases, policy at the endpoint or the middle may require application data to be scrubbed of viruses and spam. Endpoints must be able to discover and take advantage of such middlebox services when available. 3.5. Steering, Anycast, and Mobility REQ-7: Endpoints and middleboxes MUST be able to redirect flows to alternate endpoints, addresses or through alternate routes. In particular: a) Steering: An endpoint MUST be allowed to redirect an inbound flow to an alternate endpoint without requiring the application initiating the flow to intervene. b) Anycast: A middlebox MUST be allowed to direct an inbound flow to an alternate address for an endpoint without requiring either endpoint application to intervene. c) Mobility: The Internet MUST maintain and reroute flows between mobile endpoints when possible. Endpoints may delegate certain flows to other endpoints in order to shed load, or to offer alternate services. Alternately, multiple application instances identified by a common logical endpoint name may provide the same service such that an intermediate middlebox can direct flows to any instance. Finally, an endpoint may change its address over time and wish to migrate an in-progress flows to utilize the new route. In such cases, the endpoint or middlebox affected must be allowed to transparently redirect flows to alternate endpoints, addresses or through alternate routes. 3.6. Protocol Negotiation REQ-8: Endpoints MUST be able to negotiate the protocol stack for a flow subject to application requirements and relevant endpoint and middlebox policy. Endpoints may require or prefer datagram delivery (UDP, DCCP) or reliable stream delivery (TCP, SCTP), with or without encryption (TLS, IPSec), with or without compression etc. Not all endpoints may have support for all protocols. New protocols may be implemented that endpoints would like to negotiate. 3.7. Multi-Homing REQ-9: Multi-homed endpoints and middleboxes MUST be allowed to to specify the route(s) to use for a flow. The Internet MUST allow multiple routes to be used simultaneously. A multi-homed endpoint or middlebox may have policy governing which upstream provider to send and receive data over for a particular flow. Endpoints and middleboxes must not be unduly constrained to use the default route selected by intermediate networks. Endpoints and middleboxes must also be allowed to simultaneously utilize multiple routes when available for increased performance and reliability. 3.8. Multicast REQ-10: The Internet MUST support multicast flows. Endpoints should be able to send data to multiple endpoints. When available, the Internet should be able to take advantage of localized in-network support (IP multicast). When in-network multicast functionality is not present, the Internet must offer a fallback approach whereby endpoints and middleboxes can cooperate to facilitate multicast. 3.9. Scalability, Performance and Robustness REQ-11: The Internet MUST scale to global proportions. The Internet must support global communications. In particular, changes or modifications should not limit the scalability demonstrated by the current Internet architecture. REQ-12: The Internet MUST support fast flow establishment. The Internet must be optimized for short flows on high-latency networks. It must not necessitate latency intensive operations that waste multiple RTTs before flows can be established. In particular, it should often be possible for the first transmitted packet to contain an application payload. REQ-13: The Internet MUST be tolerant to path change. Endpoints must have enough state to re-establish flows should they be disrupted by a path change or a crashed middlebox. At the same time, the Internet shouldn't prevent the deployment of redundant hot- failover, fast-reroute kinds of solutions in the infrastructure, should one wish to deploy this way. 3.10. Deployability REQ-14: Changes to the Internet MUST be incrementally deployable. Overhauling the Internet overnight is not possible. Endpoints and middleboxes must be allowed to gradually migrate to any new architecture. There must be an incentive to migrate gradually to a new architecture. This requirement, however, only applies to architectures that are close to be deployed. Deployability may be ignored in the initial design phase. 4. Acknowledgments The authors would like to thank Mark Baugher, Scott W Brim, Remi Despres, and Stephen Farrell for insightful comments on earlier versions of this document. 5. References 5.1. Normative References [RFC1009] Braden, R. and J. Postel, "Requirements for Internet gateways", RFC 1009, June 1987. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 5.2. Informational References [Shoch78] Shoch, J., "Inter-Network Naming, Addressing, and Routing", IEEE Proc. COMPCON Fall 1978 pp. 72-79, Fall 1978. Authors' Addresses Saikat Guha Cornell University 331 Upson Hall Ithaca, NY 14853 US Phone: +1 607 255 1008 Email: saikat@cs.cornell.edu Paul Francis Cornell University 4108 Upson Hall Ithaca, NY 14853 US Phone: +1 607 255 9223 Email: francis@cs.cornell.edu Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).