One document matched: draft-shore-midcom-protos-00.txt
Internet Draft Melinda Shore
draft-shore-midcom-protos-00.txt Cisco Systems
October 2003
Expires April 2004
Talking to Stuff In The Network: Middlebox Communication Models
<draft-shore-midcom-protos-00.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [1].
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 docu-
ments 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.
Abstract
It is increasingly common for applications to want to influence the
behavior of equipment in the network, in violation of various
tenets underpinning the the design of IP. A number of different
mechanisms and architectures have been proposed, and this very
drafty draft is a hoped to be a start at discussing some of the
issues related to protocols used for middlebox communication.
1. Introduction
IP was originally designed around the end-to-end principle
[Saltzer] which says, among other things, that application function
should not be embedded in the network. This design was executed at
Shore [Page 1]
Internet Draft Midcom Models October 2003
a time when the dominant values in the network were sharing and
maximizing communication reach.
As IP networking found a foothold in the commercial world, however,
there grew an increasing need to compartmentalize the network into
administrative domains where local policy could be applied. These
policies include things like access control, accounting, quality-
of-service, and so on. There was also increasing interest in per-
formance-enhancing intermediaries and proxies.
These middleboxes typically have done their work either by making
policy decisions based on packet contents (firewalls filtering on
the traditional 5-tuple or QoS-capable routers making decisions
based on DSCPs) or by transforming all traffic that traverses it
(NAT, for example).
Allowing the middlebox to make decisions in isolation from the end-
points participating in the data flows that traverse it has turned
out to have some serious problems. Among those is that the middle-
box often has no way to inspect the traffic to make decisions if
the traffic is encrypted (and unfortunately some network adminis-
trators are choosing to not encrypt traffic in order to allow mid-
dlebox/firewall inspection). Another is that the network should
not be allowed to manipulate traffic without authorization from the
participating endpoints (for example, it might be a problem if
every instance of "Gore" was changed to "Bush" without permission).
And another is that it's frequently difficult for middleboxes to
recognize relationships among parallel data streams, which has
proven to be a very serious problem in protocols and applications
which use dynamically-allocated data streams, such as VoIP and
streaming media.
Various, uncoordinated pieces of work on explicit communication
with network devices have progressed in parallel in the IETF, and
different approaches and architectures have been developed. Each
introduces unique problems and benefits and it may be time to step
back and examine what we have (or have not!) learned so far.
[RFC3234] discusses different types of middleboxes and their asso-
ciated issues, but not the protocols used in sending policy and
other requests to them. This memo is an attempt at categorizing
those protocols and architectures.
[Some obvious things are missing: mobile IP. Some things seem out-
of-scope - configuration protocols like DHCP and ipv6 neighbor dis-
covery, ??Teredo??, application intermediaries that function as
application peers, like SIP proxy servers]
Shore [Page 2]
Internet Draft Midcom Models October 2003
2. Terminology
Middlebox: Any intermediary device performing functions other than
the normal, standard functions of an IP router on the datagram
path between a source host and destination host. See
[RFC3234] for a more complete discussion.
Off-path Signaling: "Off-path signaling" is a generic term refer-
ring to the establishment of an explicit policy request/commu-
nication connection between an application or an application
agent and a network device. It is called "off-path" because
the application agent may lie outside the application data
path. Also sometimes referred to as "path-decoupled signal-
ing."
On-path signaling: A generic term for referring to requests sent
along the same network path as the data messages they are
intended to affect. Also sometimes referred to as "path-cou-
pled signaling."
Relative topology: The relationship of network devices to one
another. Examples incude ordering of devices along a path, or
devices that are "next to eachother" topologically in a multi-
homed network.
3. Endpoint/Proxy-initiated approaches to middlebox communication
In this section we look at architectures in which the signaling or
middlebox communication request is initiated by a network endpoint
or its proxy. When an application running across a network recog-
nizes that it requires special services from the network, such as
QoS for a particular data stream, a firewall pinhole, a security
policy modification, etc., it initiates a request. This function
may be proxied by another entity acting on behalf of the endpoint.
This is distinct from models in which a middlebox initiates commu-
nication with an endpoint or another device, which we discuss
later.
Also, note that we tend to use the phrases "signaling," "middlebox
requests," and "middlebox communication" interchangeably throughout
and probably should not.
Shore [Page 3]
Internet Draft Midcom Models October 2003
3.1. Client-server approach
This is probably the most basic model for sending requests to a
network device. It is the one assumed by midcom, an IETF working
group defining a protocol specifically to make requests of middle-
boxes, in this case firewalls and NATs (although the intention was
to devise something general enough to support a variety of middle-
box uses). The client-server approach is one mechanism used for
off-path signaling but it is not the only one.
In this case an endpoint, or an agent acting on behalf of the end-
point (for example, a VoIP call control server), initiates a con-
trol connection to a middlebox and sends requests, which are
granted or denied by the middlebox based on local administrative
policy. An agent may be in communication with multiple middleboxes
or a middlebox may be in communication with multiple agents, but
the basic communication model remains the same (Figure 1 shows the
middlebox control model -- no data streams are shown).
+-----------+
| |
| |
| Agent |
| |
| |
+-----------+
/ \
/ \
+-----------+ \+------------+ +------------+
| | | | | |
| | | | | |
| Host 1 | | Middlebox | | Host 2 |
| | | | | |
| | | | | |
+-----------+ +------------+ +------------+
Figure 1
This model raises a number of architectural issues, not the least
of which are location and routing. An agent has to know if there
are middleboxes along a given data path and if it has knowledge of
multiple middleboxes it has to be able to determine which are
Shore [Page 4]
Internet Draft Midcom Models October 2003
relevant and which are not. An even more difficult problem is that
it may be the case that if there is more than one middlebox along a
path, requests could potentially be sensitive to topological order-
ing within the network. This is particularly true when one of
those middleboxes is a NAT and packets' transport addresses are
being altered in transit.
A clear advantage of using a client-server model for middlebox
requests is that the security model is relatively simple, with the
ability to authenticate and authorize being artifacts of a
straightforward relationship between the agent and middlebox as
well as whatever policy mechanisms are available.
Other examples of this kind of protocol include SOCKS [RFC1928],
TURN [Rosenberg]
3.2. On-path signaling
On-path signaling sends middlebox requests along the same path (or
is hoped to be the same path) that will be traversed by the associ-
ated data stream. Probably the best-known protocol and architec-
ture used for on-path signaling is RSVP [RFC2205], and while RSVP
was originally used to carry IntServ requests it has been general-
ized somewhat to extend its use for establishing MPLS LSPs
[RFC3209]. There have been proposals to use RSVP for other middle-
box communication applications [Shore], and there are plans to sup-
port middlebox communications in the IETF's next on-path signaling
protocol [NSIS].
In on-path signaling, a request is sent between the two hosts orig-
inating and terminating a data stream. That is to say that the
source and destination addresses in the signaling request are the
same as those of the data stream (or proxies acting on behalf of
either or both endpoints). Requests are not addressed directly to
the middleboxes. Instead, something in the packet, for example a
router alert or a transport protocol port number, can be used to
indicate that the request is one that should be intercepted and
acted upon by the middlebox. Figure 2 shows the middlebox communi-
Shore [Page 5]
Internet Draft Midcom Models October 2003
cation model (again, no data streams are shown).
+------+ +-----------+ +-----------+ +------+
| |------->| |---->| |--->| |
|Host 1| |Middlebox 1| |Middlebox 2| |Host 2|
| |<-------| |<----| |<---| |
+------+ +-----------+ +-----------+ +------+
Figure 2
In RSVP, path state (routing) is established as the request flows
from Host 1 towards Host 2, while reservation state is confirmed
and installed in the reverse direction, as the request flows from
Host 2 towards Host 1. This need not necessarily be the case.
This model has some clear advantages around topological issues
(discovery, routing, relative topology), and it can be used for
topology discovery and determination. One example of this is the
Tunnel Endpoint Discovery protocol, which is used to discover IPSec
gateway locations in order to establish IPSec tunnels. An entry
gateway injects a message into the network towards the destination
address of a data flow. The message is intercepted by an IPSec
gateway and returned to the originating gateway which then initi-
ates an IKE session with the discovered gateway, bringing up an
IPSec tunnel.
but there are several associated disadvantages. One is that the
signaling model is path-oriented, which suggests the existence of a
path, or at least a source and destination. A protocol like this
is not useful for provisioning or configuration. For example, a
path-coupled signaling protocol is unsuitable for sending a message
to a middlebox asking for specific QoS treatment for all traffic.
While individual requests can be sent out to request service for
each data stream, clearly this generates more traffic and cannot
solve certain middlebox problems such as asking for a more-or-less
static firewall pinhole for accepting incoming requests (on well-
known ports, for example).
Another difficulty is that the security model can be somewhat
murky. While endpoint (request initiator) credentialing can be
done, message authentication can be a problem in an environment
where nodes along the path may be modifying the contents of the
request and you might not have an existing relationship with other
nodes along the path. Authorization is difficult in the absence of
Shore [Page 6]
Internet Draft Midcom Models October 2003
existing relationships, as well.
The most straightforward approach to securing middlebox requests in
this environment is to secure traffic between adjacent hops and
rely on transitivity. Security may not actually be transitive in
all situations, and it is sometimes unclear what a "hop" is, par-
ticularly when the protocol is being used to support a variety of
uses and any given node may not be relied upon to be participating
in a particular use.
4. Middlebox-initiated approaches to middlebox communication
In some instances, middleboxes may choose to consult with a sending
endpoint or with another device for further information on how to
process a packet. In these cases, the middlebox initiates a
request.
4.1. Callback protocols
In some cases, a middlebox may decide to contact a packet's sender
either to request additional information (say, credentials) or to
send it a notification. Obvious, early and crude examples of this
kind of use include ICMP messages like source quench and various
unreachables.
This has been suggested as one possible communication model for
transport intermediaries [Blumenthal] but is not in wide use. It
demonstrates many of the same advantages and disadvantages as call-
out protocols, but may have fewer firewall traversal problems
(which is not to say that there will be no problems). The OPES
documents (see below) require that an endpoint be notified and
allowed to authorize (or not) treatment of its request or response
to its request, but it remains unspecified.
4.2. Callout protocols
In a callout protocol, a middlebox initiates contact with someone
other than a packet's sender. One example of this is the proposed
architecture for a "transport triggers" service for transport layer
protocols (notably TCP) [Dawkins]. Another is the callout function
of the OPES architecture [Barbir]
4.2.1. TRIGTRAN
TRIGTRAN is path-oriented, in that it assumes the existence of two
participating endpoints which are sending data to one another.
Shore [Page 7]
Internet Draft Midcom Models October 2003
When a transport intermediary wishes to notify the endpoints of a
transport event or of connection path characteristics, it generates
a message which is sent to the receiver of the data triggering the
event, rather than the sender. Note that these requests are advi-
sory only, but nevertheless do constitute a form of middlebox com-
munication. There is a reasonable expectation that an endpoint
that has received a TRIGTRAN notification will modify its own
behavior, which in turn imposes some security requirements on the
protocol. Figure 3 shows the flow of the control traffic (here we
assume that Host A is the originator of the traffic and Host B is
the receiver).
+------+ +----------------------+ +------+
|Host A| |Transport Intermediary|--->|Host B|
+------+ +----------------------+ +------+
Figure 3
As with path-oriented signaling and callback protocols, callout
protocols have the advantage of not requiring device or topology
discovery. The endpoints are known. However, the most common
authorization model for firewalls (and indeed, the fundamental
premise behind NATs) is that connections initiated from inside a
firewall or NAT are allowed and that data sent from outside a fire-
wall or NAT is discarded either because it's a policy violation
(firewalls) or because the device doesn't know where to send it
(NATs). Consequently, because TRIGTRAN messages are path-oriented
but not in-band, and because TRIGTRAN and other callout messages
are not embedded in the data stream of interest they will have a
problem reaching an endpoint if there is a NAT or firewall along
the path.
Note that in TRIGTRAN and other protocols where a network-embedded
device sends information that suggests to an endpoint that it mod-
ify its behavior (another example is when an endpoint discovers or
receives its external address from a NAT via midcom or another pro-
tocol), the middlebox must identify itself and be authorized to
provide the service in question. The reasons are obvious (DoS
attacks, connection hijacking, etc.), but this creates a somewhat
different expectation from the usual one that an endpoint is the
one who must authenticate itself to the server or network device.
4.2.2. Open Pluggable Edge Services (OPES)
The IETF's OPES working group has developed an architecture to
allow invocation of network-embedded application services that are
Shore [Page 8]
Internet Draft Midcom Models October 2003
initiated by server-side devices. For example, requests from a
client may be redirected for load balancing, or a web page may be
automatically translated from one language to another. OPES sup-
ports the use of "callout servers." When a middlebox (in this case
an "OPES processor") receives traffic it would like to refer out
for processing, it encapsulates and forwards it (possibly after
performing some transformation itself). The transformed data are
returned to the OPES processor. There are essentially two middle-
boxes here, the OPES processor, which is a middlebox with respect
to the data originator, and the callout processor, which is a mid-
dlebox with respect to the OPES processor. See Figure 4, which
shows the control connections for the callout protocol.
+-----------------+
|Callout Processor|
+-----------------+
^
/
/
/
+------+ +--------------+ +------+
|Host A| |OPES Processor| |Host B|
+------+ +--------------+ +------+
Figure 4
It could be argued that this is actually an instance of off-path
signaling, much like midcom. This probably doesn't survive
scrutiny in the overall network context, however, because of the
relationships among the participants. In midcom, the device
requesting treatment of the sender's data has a very close trust
relationship with the sender (and in fact may be the sender). In
OPES the sender has no relationship with the callout processor and
is not even aware that it exists.
COPS [2748] is arguably another example of a callout protocol.
Conclusion
Based on the above discussion we can start to identify certain
properties that may be used to describe different aspects of mid-
dlebox communication. Among these are:
path-coupled/path-decoupled
endpoint-initiated/middlebox-initiated
Shore [Page 9]
Internet Draft Midcom Models October 2003
on-path/in-stream
We believe that there are other distinctions that can be teased
out, as well, and that as we go forward with new middlebox communi-
cation protocols it is easily worth some effort to come to a
broader understanding of the issues and environments.
References
[Barbir] Barbir, A. et al. "An Architecture for Open Pluggable Edge
Services (OPES)," work in progress. December 2002.
[Blumenthal] Blumenthal, U. et al. "Securely Enabling Intermediary-based
Transport Services," work in progress. June 2003.
[Dawkins] Dawkins, S., Williams, C. and A. Yegin, "Framework and
Requirements for TRIGTRAN," work in progress. March 2003.
[Fluhrer] Fluhrer, S. "Tunnel Endpoint Discovery," work in progress
(expired internet draft). November 2001.
[NSIS] "Next Steps in Signaling (nsis)," working group charter.
http://www.ietf.org/html.charters/nsis-charter.html.
[RFC1928] Leach, M. et al. "SOCK Protocol Version 5," March 1996.
[RFC2205] Braden, R. et al. "Resource ReSerVation Protocol (RSVP)," RFC
2205, September 1997.
[RFC2748] Durham, D. et al. "The COPS (Common Open Policy Service) Pro-
tocol." RFC 2748, January 2000.
[RFC2753] Yavatkar, R., Pendarakis, D., and R. Guerin. "A Framework for
Policy-based Admission Control," RFC 2753, January 2000.
[RFC3209] Awduche, D. et al. "RSVP-TE: Extensions to RSVP for LSP Tun-
nels, RFC 3209, December 2001.
[RFC3234] Carpenter, G. and S. Brim. "Middleboxes: Taxonomy and
Issues," RFC 3234, February 2002.
[RFC3303] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A., and A.
Rayhan. "Middlebox communication architecture and framework, RFC
3303, August 2002.
Shore [Page 10]
Internet Draft Midcom Models October 2003
[Rosenberg] Rosenberg, J., Mahy, R., and C. Huitema, "Traversal Using
Relay NAT (TURN)," work in progress, October 2003.
[Saltzer] Saltzer, J.H., Reed, D.P., Clark, D.D. "The End-to-End Argu-
ment in System Design," ACM Transactions in Computer Systems 2(4),
November 1984.
[Shore] Shore, M. "The TIST (Topology-Insensitive Service Traversal)
Protocol," work in progress (expired internet draft), May 2002.
5. Copyright
The following copyright notice is copied from RFC 2026 [RFC2026]
Section 10.4, and describes the applicable copyright for this docu-
ment.
Copyright (C) The Internet Society October 1, 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, pub-
lished and distributed, in whole or in part, without restriction of
any kind, provided that the above copyright notice and this para-
graph are included on all such copies and derivative works. How-
ever, 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 proce-
dures 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 assignees.
This document and the information contained herein is provided on
an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGI-
NEERING 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 WAR-
RANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Shore [Page 11]
Internet Draft Midcom Models October 2003
6. Intellectual Property
The following notice is copied from RFC 2026 [Bradner, 1996], Sec-
tion 10.4, and describes the position of the IETF concerning intel-
lectual property claims made against this document.
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to per-
tain to the implementation or use other technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on
the IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication 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 pro-
prietary rights by implementers or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Execu-
tive Director.
Author's Address
Melinda Shore
Cisco Systems
809 Hayts Road
Ithaca, NY 14850
USA
mshore@cisco.com
Shore [Page 12]
| PAFTECH AB 2003-2026 | 2026-04-23 08:48:45 |