One document matched: draft-shore-friendly-midcom-01.txt
Differences from draft-shore-friendly-midcom-00.txt
Internet Draft Melinda Shore
draft-shore-friendly-midcom-01.txt Cisco Systems
June 2002
Expires December 2002
Towards a Network-friendlier Midcom
<draft-shore-friendly-midcom-01.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
While IP was designed around the notion that the network would be
invisible to the applications that run on them, an increasingly
complex service environment along with the compartmentalization of
"policy" into administrative domains has led to a proliferation of
types of middleboxes for policy enforcement, and those middleboxes
are interfering with applications. Applications now need to influ-
ence the behavior of middleboxes, but violating network layering
principles by establishing explicit communication channels from
applications to network-layer middleboxes introduces a new set of
problems related to topology and discovery as well as consequent
problems that ripple out from those. This paper is an introductory
Page 1
Internet Draft Network-friendlier midcom June 2002
examination of whether or not there is a better way.
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
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. Met-
calfe's Law, which says that the utility of a network equals the
square of the number of users, may remain true in the broadest
sense of the phrase "utility of a network," but may not be true
locally. That is to say that the network may be more valuable to
me if I have access to your stuff, but it may be less valuable to
me if you have access to my stuff.
As a consequence an industry has evolved around providing boxes
that implement the separation of administrative domains. These
boxes typically are firewalls or network address translators, but
there may be others as well. A significant problem with firewalls
and NATs is that the mechanisms that they use to implement this
separation and to identify network traffic to which policy must be
applied are extremely crude. Addresses and port numbers are very
poor representations of policy, indeed. And because of the inade-
quacy of these representations, complex applications which manipu-
late or add their own data streams on dynamically allocated
address/port/protocol tuples fail when traversing domain boundaries
enforced by middleboxes.
Middlebox vendors have attempted to mitigate the negative effects
of their devices by adding "stateful inspection" capabilities and
through the introduction of application- layer gateways. By forc-
ing the middleboxes to understand application protocols the middle-
boxes become participants in the application, violating the end-to-
end principle. Predictably but unfortunately, stateful inspection
brings with it a large number of drawbacks, including not being
able to function if the application data are encrypted and failed
payload integrity checks if stateful NAT rewrites are used, which
actively interferes with securing applications. There are also
problems with scalability and with software maintenance, as middle-
boxes need to cope with an increasing number of application proto-
cols. ALGs suffer similar limitations, as they force connections
Page 2
Internet Draft Network-friendlier midcom June 2002
to terminate on intermediate devices, interfering with trust rela-
tionships and increasing network complexity as ALGs are added for
each application as needed.
The IETF's midcom working group [Midcom] has been chartered to
develop an architecture and requirements for moving application
logic out of middleboxes and allowing applications direct influence
over middlebox behavior by establishing a communications channel
between an agent acting on behalf of the application and the mid-
dlebox itself. The architecture that is being developed will work
well in smaller networks, but may have difficulties scaling and
with manageability. In this paper we discuss an alternative archi-
tecture that may be more idiomatic to IP networking, and therefore
more network-friendly.
2. The Midcom Model
The essential components of the midcom architectural framework are
a middlebox, a midcom agent (representing the application), and a
policy function, as shown in Figure 1.
+---------+
| agent |
+---------+
|
+---------+ +------+
|middlebox|------------|policy|
+---------+ +------+
Figure 1
The agent establishes an explicit connection with a middlebox.
That is to say, communication between the agent and the middlebox
is terminated at one end on the agent and at the other end on the
middlebox. In the case where there are multiple middleboxes that
need to be influenced the agent will need to establish communica-
tion with each one. Note that with respect to the agent the mid-
Page 3
Internet Draft Network-friendlier midcom June 2002
dleboxes may be organized serially (Figure 2)
+---------+
| agent |-+-+-+
+---------+ | | |
| | | |
+---------+ | | |
|middlebox|-+ | |
+---------+ | |
| | |
+---------+ | |
|middlebox|---+ |
+---------+ |
| |
+---------+ |
|middlebox|-----+
+---------+
Figure 2
or as a "fan" (Figure 3)
+---------+
+---------| agent |---------+
| +---------+ |
| | |
+---------+ +---------+ +---------+
|middlebox| |middlebox| |middlebox|
+---------+ +---------+ +---------+
Figure 3
Either configuration presents challenges to the application and
each configuration has problems of its own. These problems may not
be tractable. In both cases the agent will need to discover the
existence of the middleboxes and their location within the network.
Right now the midcom assumption is that the middlebox will be manu-
ally configured into the agent, but to date the question of rela-
tive location remains unaddressed.
By "relative location" we mean the location of each middlebox in
relation to the agent and in relation to each other. For example,
in the case where middleboxes are arranged serially, it may be nec-
essary for the agent to know where they are and how they're
ordered. If a NAT is inserted before a firewall, the agent will
Page 4
Internet Draft Network-friendlier midcom June 2002
need to know to use the translated-to address when installing a
ruleset on the firewall. If there are multiple NATs, the agent
will need to know which NAT is last in order to know what address
to present to the destination endpoint.
The fan configuration introduces a different, difficult problem --
routing. The midcom agent must be able to identify which middlebox
a particular stream of application data will traverse, which sug-
gests knowledge of network topology and routing tables. It becomes
even more complicated when a third party is used for call control
and as a midcom agent, as with VoIP. In that case it may very well
be that the middlebox(es) traversed to get from one call control
server/midcom agent to another in order to complete a call are not
the same as the middleboxes traversed by the end-to-end media
streams (Figure 4).
+--------------+ signaling +--------------+
| |<--------------->| |
| call control | | call control |
| | +---------+ | |
| +------+ |---|middlebox|---| +------+ |
| |midcom| | +---------+ | |midcom| |
| | agent| | | | agent| |
| +------+ | | +------+ |
+--------------+ +--------------+
| |
| |
| |
| |
| audio |
+----------+<------------------->+----------+
| VoIP | +---------+ | VoIP |
| terminal |-----|middlebox|-----| terminal |
+----------+ +---------+ +----------+
Figure 4
The agents may therefore need to know about the location of middle-
boxes outside of the paths traversed by its own data, and it may
need to understand the network topology well enough to determine
when it needs to make a request of one.
Other problems crop up, as well, such as NAT middleboxes with more
than one interface and with overlapping address spaces, and that a
Page 5
Internet Draft Network-friendlier midcom June 2002
midcom agent cannot know whether or not a given flow will need ser-
vices from a particular middlebox without having access to network
topology. Furthermore, because firewall rules are usually speci-
fied in terms of "in" and "out" on particular interface, there's
support for the notion of having midcom agents know about internal
middlebox configuration. All of this is leading towards having
midcom agents participate in network-layer routing, something which
has clear negative implications for network performance, manage-
ment, and stability.
While problems stemming from relative topology have not yet been
addressed, there have been proposals in midcom to make network-
layer topology explicit to the midcom agent to varying degrees
[Molitor, Aoun, Penfield]. [Brim] suggestion that leaving topol-
ogy-related decisions in the hands of the middlebox with notifica-
tion back to the agent is far more idiomatic to IP, but the prob-
lems of relative topology and middlebox discovery remain.
3. An Alternative
Architecturally it would seem to be preferable to allow the network
to handle network-layer issues. The question then becomes whether
or not that is feasible. There is a precedent for this sort of
approach, and that precedent is RSVP [RFC2205]. Our intention at
this time is not to propose RSVP as a midcom protocol but to exam-
ine the approach that it takes for applicability to middlebox
traversal problems. We also note that a working group has recently
been chartered to investigate future work on signaling in the
internet [nsis], and this may be a particularly apt time to examine
whether or not this approach generalizes well to middlebox communi-
cation.
Please note that while we do not consider the policy interface in
this draft, we do consider it a critical component of a complete
middlebox communication environment.
3.1. RSVP
[RFC2208] describes RSVP as "a unicast and multicast signalling
protocol, designed to install and maintain reservation state infor-
mation at each router along the path of a stream of data." "Reser-
vation state" in this case refers to QoS parameters. Midcom con-
cerns itself with manipulation of different resources (firewall
pinholes and NAT table mappings), but these might broadly be con-
sidered "reservation state information."
Page 6
Internet Draft Network-friendlier midcom June 2002
Why RSVP is of particular interest is that it relies on existing
routing mechanisms for finding a path through the network, and nei-
ther endpoint involved in the reservation needs to know where RSVP-
capable routers are located. The basic reservation model is build
around a flowspec, which describes the treatment that the data are
to receive, and a filter spec, which describes the data to which
the flowspec applies. This model works as well for packet filter-
ing middlebox functions as it does for QoS.
A key characteristic of RSVP is that requests are sent downstream
by the sender towards the receiver, collecting path/routing infor-
mation, and the receiver then returns the request back upstream to
the sender. This is where the actual reservation requests are made
of the network. What this gives us is access to middleboxes along
a path without having to address them directly, as well as access
to ordering information. We no longer need to export network
topology information to the application in order to have midcom be
able to find middleboxes and make topology-appropriate requests.
While there is legitimate concern about the state that this mecha-
nism would install and manipulate in middleboxes, it should be
noted that the middleboxes under direct consideration, NATs and
firewalls, already retain the vast bulk of this state in normal
operations. Indeed, one could argue that by removing stateful
inspection from firewalls and NATs we are reducing the amount of
state retention in these devices.
Another scaling issue is maintenance traffic. RSVP's messaging
model uses periodic idempotent messages to refresh reservation
state and to accomodate routing changes, potentially creating a
good deal of traffic of its own. Figuring on roughly 104 bytes per
message (including IP headers but not including INTEGRITY or POLICY
objects), we calculate the following table, where the number in
each cell represents the bytes/sec. of RSVP traffic based on update
interval (shown in the left-most column, in seconds) and the number
of data flows (shown in the first row).
20 100 500 1000 5000 10000
30: 8320 41600 208000 416000 2080000 4160000
60: 4160 20800 104000 208000 1040000 2080000
120: 2080 10400 52000 104000 520000 1040000
300: 832 4160 20800 41600 208000 416000
600: 416 2080 10400 20800 104000 208000
900: 277 1386 6933 13866 69333 138666
Page 7
Internet Draft Network-friendlier midcom June 2002
So, we can see that if there were 10000 data flows whose middlebox
state were being managed by Path/Resv message pairs every 30 sec-
onds, it would generate more than 4 megabytes/sec in traffic. If
the refresh interval is lengthened to 15 minutes, it would generate
about 140,000 bytes/second of RSVP traffic. Note that this discus-
sion assumes that the refresh reduction overhead mechanisms
described in [RFC2961] are not used. Note as well that the longer
the refresh interval is the longer it takes to respond to routing
changes, etc.
3.2. Messages
Downstream (from the sender towards the receiver) messages carry a
description of the requested action, such as "open a pinhole,"
"install a NAT mapping," etc., a description of the data flows
against which the action should be applied ({address, port, proto-
col} tuples, for example), and sufficient information for the mid-
dlebox to use as input into a policy-based decision whether or not
to honor a request. This might include the identity of the
requesting entity, the application for which the service is being
requested, etc.
Upstream (from the receiver towards the sender) messages create and
maintain state in middleboxes, and accumulate confirmed informa-
tion, such as NAT table mappings, that need to be returned to the
sender.
As with RSVP, when each middlebox receives a Path message it must
record the previous hop middlebox in order to ensure that the Resv
messages are returned along the same data path, avoiding problems
created by asymmetric routing.
The advantages of using the RSVP mechanism of collecting path
information in a downstream direction before installing and con-
firming reservation state in an upstream direction are clear. It
provides with an ability to make topology- appropriate reservation
requests and to be able to return topological summary information,
such as outermost NAT with respect to the receiver, to the sender.
4. Example Scenarios
For the sake of convenience, in the following examples we refer to
forward messages from the originating host as "Path" and returning
messages towards the originating host as "Resv". These were chosen
because they're well-understood, and should not be construed as
assuming or arguing for the use of RSVP as the underlying protocol.
Page 8
Internet Draft Network-friendlier midcom June 2002
4.1. Open a firewall pinhole
+----------+ (1) +--------------+ (2) +----------+
| |------>| |------>| |
| Host A | | Middlebox | | Host B |
| |<------| |<------| |
+----------+ (4) +--------------+ (3) +----------+
Figure 5
In this case Host A is requesting the middlebox to permit all traf-
fic originating at Host B and destined for Host A. Host A sends a
Path message (1) towards host B, anticipating that midcom-aware
middleboxes transited by the Path message will act on the message.
The middlebox intializes path state and forwards the message (2) on
towards Host B. Host B then uses the Path message to build a Resv
message, which is returned towards Host A (3). The middlebox
receives the Path message, makes a determination whether or not to
open the pinhole, and forwards the results (success or failure)
back to Host A (4).
4.2. Transit both firewall and NAT
This scenario is where we begin to derive some benefit from relying
on network routing and forwarding functions to handle topology for
us. Firewalls and NATs may appear in any order in the data path.
In Figure 6, packets from Host A to Host B transit a firewall
Page 9
Internet Draft Network-friendlier midcom June 2002
before transiting a NAT.
+--------+
| Host A |
+--------+
| ^
(1) | | (6)
v |
+--------+
|Firewall|
+--------+
| ^
(2) | | (5)
v |
+--------+
| NAT |
+--------+
| ^
(3) | | (4)
v |
+--------+
| Host B |
+--------+
Figure 6
Host A wishes to request a firewall pinhole and a NAT table map-
ping, but it cannot know in which order which type of middlebox
appears in the network. It therefore constructs a Path message
consisting of a firewall pinhole request AND a NAT table mapping
request and sends it into the network towards host B (1). The Path
message arrives at the firewall, which install initial path state,
and forwards it towards Host B (2). When the Path message arrives
at the NAT, the NAT similarly initializes path state but it also
rewrites the Path message with its own address so that Resv mes-
sages are routed correctly. State associated with that mapping is
retained at the NAT. The rewritten Path message is forwarded to
Host B (3), which builds a Resv message and sends it back towards
Host A using the translated address that was written into the
packet by the NAT. Host A extracts the translated-to address from
the message and uses it as needed for embedding in signaling pay-
loads for session-oriented protocols, etc.
Page 10
Internet Draft Network-friendlier midcom June 2002
4.3. Transit NAT then firewall
In Figure 7, packets from Host A to Host B transit a NAT before
transiting a firewall.
+--------+
| Host A |
+--------+
| ^
(1) | | (6)
v |
+--------+
| NAT |
+--------+
| ^
(2) | | (5)
v |
+--------+
|Firewall|
+--------+
| ^
(3) | | (4)
v |
+--------+
| Host B |
+--------+
Figure 7
As with the previous scenario, Host A wishes to request both a
firewall pinhole and a NAT table mapping but it doesn't know
whether or not those devices lie in the data path or in what order
they appear. It constructs a Path message consisting of both a
pinhole request and a NAT table mapping request and sends it
towards Host B (1). The Path message arrives at the NAT, which
rewrites its own address into the Path message and forwards it on
(2). When the firewall receives the Path message it now has the
NATted address to use as a component of the pinhole rule. The Path
message is forwarded on to Host B (3), which turns it around and
sends the Resv message back towards Host A, with the NATted address
in the Resv message and the pinhole for the translated address
installed on the firewall.
Page 11
Internet Draft Network-friendlier midcom June 2002
4.4. More than one NAT
Figure 8 shows two NAT devices between Host A and Host B.
+--------+
| Host A |
+--------+
| ^
(1) | | (6)
v |
+--------+
| NAT A |
+--------+
| ^
(2) | | (5)
v |
+--------+
| NAT B |
+--------+
| ^
(3) | | (4)
v |
+--------+
| Host B |
+--------+
Figure 8
Without midcom, or with the model currently being envisioned by
midcom, the application has no way of knowing how many NATs are
present or which address will appear in the source address field in
the IP header when the packet is delivered to Host B. Furthermore,
NAT A and NAT B have no way of knowing about eachother and cannot
be relied upon to do the right thing. With our model, however,
Host A will be able to learn the correct address without having any
explicit awareness of network topology.
Host A sends a Path message towards Host B (1). When it traverses
NAT A, NAT A installs initial Path state, including a new NAT table
mapping, writes the mapping into the Path message, and forwards it
on (2). The message arrives at NAT B, which does the same thing
(either adding a new mapping into the message along with a sequence
number or overwriting the existing mapping). This is forwarded
towards Host B (3), which turns it around as a Resv message. The
Resv message includes the NAT mapping information. When the Path
message returns to Host A, the correct NAT table entry will either
Page 12
Internet Draft Network-friendlier midcom June 2002
be the one with the highest sequence number, if all mappings are
retained, or the only one in the message, if mappings are overwrit-
ten.
5. Security Considerations
Many of the security issues relevant to midcom still apply, such as
the need for "agent" authentication for firewalls and for mutual
authentication for NATs. However, when the agent is authenticated
to middleboxes, symmetric, private key authentication along with
manual key provisioning is no longer a reasonable option. A rea-
sonable authentication infrastructure should be in place in order
to provide a foundation for secure operation. This may be a pub-
lic- key infrastructure or it may be a trusted third-party private
key mechanism, such as Kerberos.
It cannot assumed that the infrastructure exists to authenticate
and authorize network elements with which there is no pre-existing
relationship. That infrastructure does not exist today and it is
impossible to predict when it may become available. This is a
serious concern for some deployments, and should not be regarded
casually.
Note, too, that since multiple middleboxes may be altering the mid-
com messages in transit end-to-end integrity protection is no
longer viable. MACs may have to be recalculated at each middlebox.
This implies a transitivity of trust that may or may not be consis-
tent with local security policy.
Another consideration has less to do with the security of this pro-
tocol than it does with its interaction with security elements in
the network, namely firewalls. If a firewall allows this protocol
through without processing it, it may be the case that a false pos-
itive will result. That is to say, the sender may believe, based
on the contents of the Resv message (or a Resv Confirm message)
-
that a pinhole has been opened when a firewall along the path was
unable to process the message but just forwarded it along. This
concern may be mitigated by the question of whether or not a fire-
wall that just passes along unidentified midcom/RSVP traffic will
be likely to just pass along other unidentified traffic.
One very attractive advantage to the approach being proposed here
is that network topology need no longer be exposed to applications.
At most, the application will discover the public address of the
outermost NAT in its path.
Page 13
Internet Draft Network-friendlier midcom June 2002
6. References
[Aoun] Aoun, C. and Sen, S. "Required Information in Midcom Agents,"
work in progress, August 2001.
[Brim] Brim, S. and Simu, A. "Midcom Agents and Topology," work in
progress, August 2001.
[Midcom] "Middlebox Communication (midcom) Charter,"
http://www.ietf.org/html.charters/midcom-charter.html.
[Molitor] Molitor, A. "Topology Considerations for IP Telephony MIDCOM
Agents," work in progress, August 2001.
[Nsis] "Next Steps in Signaling (nsis) Charter,"
http://www.ietf.org/html.charters/nsis-charter.html.
[Penfield] Penfield, Bob. "MIDCOM Topology Using Realms," work in
progress, August 2001.
[RFC2026] Bradner, S. "The Internet Standards Process -- Revision 3,"
RFC 2026, October 1996.
[RFC2205] Braden, R. et al. "Resource ReSerVation Protocol (RSVP): Ver-
sion 1 Functional Specification", RFC 2205 September 1997.
[RFC2208] Mankin, A. et al. "Resource ReSerVation Protocol (RSVP) Ver-
sion Applicability Statement," RFC 2208, September 1997.
[RFC2961] Berger, L. et al. "RSVP Refresh Overhead Reduction Exten-
sions," RFC 2961, April 2001.
[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.
[Srisuresh] Srisuresh, P. et al. "Middlebox Communication Architecture
and framework," work in progress, July 2001.
7. Copyright
The following copyright notice is copied from RFC 2026 [RFC2026]
Section 10.4, and describes the applicable copyright for this docu-
ment.
Page 14
Internet Draft Network-friendlier midcom June 2002
Copyright (C) The Internet Society October 1, 2001. 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.
8. 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.
Page 15
Internet Draft Network-friendlier midcom June 2002
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
Page 16
| PAFTECH AB 2003-2026 | 2026-04-23 08:40:47 |