Requirements for the End-Middle-End Research Group S. Guha and P. Francis Cornell U. November 28, 2006 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. We assume that these discussions will lead to a version 0 internet-draft requirements document, possibly with an expanded set of authors. Table of Contents 1. Introduction 2. Terminology 3. Requirements 3.1. Access Control 3.2. Authentication 3.3. Privacy 3.4. Middlebox Control 3.5. Steering, Anycast, and Mobility 3.6. Protocol Negotiation 3.7. Multi-Homing 3.8. Multicast 3.9. Performance 3.10. Deployability 4. References 4.1. Normative References 4.2. Informational References Authors' Addresses 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 assisting endpoints to communicate through that network. 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 which 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, access control and 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. Access Control REQ-2: 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.2. Authentication REQ-3: 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. Furthermore, while endpoint authentication does not, by itself, solve the DoS problem it compartmentalizes the DoS problem to the authentication phase that precedes the actual flow. By abstracting DoS from applications into a common authentication phase, the Internet can include application-agnostic infrastructure to protect against DoS. 3.3. Privacy REQ-4: 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. 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. Endpoints must not be required to reveal their network address to untrusted middleboxes and endpoints. Network addresses should be made available after authentication 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-5: 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-6: 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-7: 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-8: 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-9: 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. Performance REQ-10: 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. 3.10. Deployability REQ-11: 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. References 4.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 4.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