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).