INTERNET DRAFT Melinda Shore
Cisco Systems
May 2001
Application Considerations for Midcom Middleboxes
<draft-shore-midcom-apps-00.txt>
Status Of This Memo
This document is an Internet-Draft and is in full con-
formance with all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet
Engineering Task Force (IETF), its areas, and its work-
ing 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 obso-
leted by other documents at any time. It is inappro-
priate 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.
Copyright Notice
Copyright (C) The Internet Society (2001). All Rights
Reserved.
Abstract
As an architecture is evolving around an interface
between middleboxes in the transport plane [Srisuresh]
and the applications which must traverse them, we need
to document the implications for applications. This
documentation is intended both to provide guidance for
application designers and to help network architects
come to a better understanding of sources of complexity
in our networks.
1. Introduction
The IP protocol suite was originally designed around
the notion that intelligence would be placed in the
endpoints and the applications running on those end-
points, and that the actions of the network itself
Page 1
Internet Draft Midcom Application Interactions April 2001
would be largely limited to routing and forwarding of
packets. However, over time and for a variety of rea-
sons (security, resource management, accounting, pol-
icy, etc) a number of different types of network inter-
mediaries have evolved, putting application involvement
into the network either explicitly (proxies, stateful
inspection firewalls) or implicitly through failure
(middleboxes which prevent some applications from func-
tioning correctly, such as NATs). [Carpenter] provides
an excellent overview of this evolution.
One response to the problem of middleboxes in the net-
work quietly interfering with applications has been to
make the middleboxes explicitly visible to them [mid-
com]. Applications controlling middleboxes in the
transport layer, such as firewalls and NATs, violates
the end-to-end principle as well as the separation of
network layers and therefore introduces yet more com-
plexity into an already increasingly complex network.
Understanding why this is the case and anticipating
some of the issues emanating from layer violation can
help network designers build their networks to minimize
complexity and help application and application proto-
col designers be more sensitive to the consequences of
middlebox interactions. This document is not intended
to present either protocol requirements or an architec-
tural framework.
2. Terminology
ASP Application Service Provider
ISP Internet Service Provider
3. ASPs and ISPs
Business arrangements built around network services are
coming to be layered in much the same manner that net-
work protocols themselves are layered. It is increas-
ingly the case that value-added services are being sold
and managed independently of network connectivity
itself so that, for example, one might contract for
voice or content distribution services with a company
which then contracts for bandwidth with yet another
company or companies. It is also not uncommon in orga-
nizations which deliver both connectivity and services
to have them delivered by distinct lines of business
with separate administrative and financial structures,
effectively operating as separate companies. These
arrangements may or may not be independent of "last
mile" connectivity.
In situations in which packet services and connectivity
are being managed by organizations other than those
Page 2
Internet Draft Midcom Application Interactions April 2001
which manage application services, it is possible that
middleboxes being operated in the network layer are
administratively inaccessible to application service
providers. This may be particularly problematic when
there is an assumption that the application has access
to the middlebox's authentication and authorization
infrastructures (or vice versa).
4. Third-party Session Mediation
The notion of applying external control to firewalls
and NATs originally came up within the IETF in the con-
text of IP telephony applications. In both enterprise
and service provider deployments of these applications
(PBX systems would be one example of the former, toll
bypass of the latter) it is typically the case that
some sort of call control server is used to mediate
call signaling. This mediation can consist of call
admission control, resource reservation, call routing,
billing and settlement, etc. Examples of call control
servers include SIP proxy servers and H.323 gatekeep-
ers.
Because this sort of administrative arrangement is
independent of network topology, there are clearly sev-
eral implications for interaction with network-layer
middleboxes. One obvious consideration is the manage-
ment of credentials for authentication and authoriza-
tion. A call control server may be able to establish a
trust relationship with a network-layer middlebox, but
it may well be (indeed, may usually be) that it will be
asking to open pinholes for direct communication
between calling and called parties rather than for com-
munication in which it is a party itself.
Another consideration is determining the location of
services. Service providers may not wish to expose the
topology of their network to external individuals or
businesses, and this would include preferring not to
reveal the location of firewalls and security gateways
(see below).
5. Receiving Incoming Sessions
Traditionally firewalls are configured to be more per-
missive of traffic exiting the protected network than
of traffic entering the protected network. In fact, in
many configurations a firewall will allow any connec-
tion initiated by a protected host but will by default
filter connections initiated from outside the network.
NAT also presents difficulties for hosts wishing to
receive incoming calls. It is overwhelmingly the
case that NATted endpoints do not have routable-to
Page 3
Internet Draft Midcom Application Interactions April 2001
addresses, and determining the address at which they
make a public appearance is frequently difficult, if
not impossible. While some NATs will forward all
incoming traffic (or all incoming traffic for a given
protocol) to a configured endpoint, this cannot allow
multiple NATted endpoints behind the same NAT to
receive incoming connections in the general case.
There may be several approaches to solving this prob-
lem. One would be for an application which expects to
receive incoming calls to 1) request a pinhole in a
firewall, and 2) request a NAT table mapping and a
directory update in anticipation of being contacted.
This approach can work, but it makes some assumptions
about directory services which may not be true (see
below) and is highly wasteful of resources on the mid-
dlebox.
An approach that scales better would be to have a proxy
server or call control server (or even a directory
server) available at a routable-to address, which would
mean that there would have to be a mechanism for
resolving from the address belonging to the called
party or server to the address of the proxy server or
call control server. This, in turn, implies the exis-
tence of an appropriate directory service. Some direc-
tory services, such as DNS, may assume a relatively
static underlying database and may not be able to func-
tion well in the presence of highly dynamic
name/address mappings, such an externally controlled
NAT may provide. Particular concerns would be speed of
update to the database itself, the security of that
database, and the speed of propagation of database
changes.
6. Separation of Signaling and Data Paths
In commercial packet multimedia architectures is is
commonly the case that call signaling is mediated by
call control servers (H.323 gatekeepers, SIP proxy
servers) but that media flow directly between end-
points. This results in a trapezoidal architecture:
signaling
CM ------------------------ CM
/ \
/ \
/ media \
EP ------------------------------- EP
(where "CM" is a call manager and "EP" is a call end-
Page 4
Internet Draft Midcom Application Interactions April 2001
point). There may be firewalls between call managers:
CM ---------- FW ---------- CM
/ \
/ \
/ \
EP ------------------------------- EP
or between endpoints:
CM ------------------------ CM
/ \
/ \
/ \
EP -------------- FW ------------- EP
or between both:
CM ---------- FW ---------- CM
/ \
/ \
/ \
EP -------------- FW ------------- EP
(note that there may also be firewalls between end-
points and call managers).
There are several concerns here. The first is that a
call control server that is in communication with a
firewall or NAT in order to permit transit of its own
signaling messages may not be aware that there is a
firewall or NAT in the media path. A particularly dif-
ficult problem, however, is that of route determina-
tion: that call control server may have to select from
among multiple middleboxes, and for it to know which
middlebox needs to be contacted it must have knowledge
of transport and/or application network topology and
routing policy. Alternatively it could contact all
known middleboxes and request a pinhole or NAT mapping,
but that is clearly wasteful of resources and can
introduce unnecessary gaps in the network perimeter.
7. Location and Discovery
Application failures caused by inability to traverse a
middlebox are most often diagnosed by a deficiency of
diagnostic information - they fail quietly, with error
indications usually being limited to timeouts or trans-
port protocol handshake failures. Firewalls are almost
always configured to drop packets without returning
ICMP unreachable messages, and ICMP unreachable code 13
(prohibited access) messages are rarely, if ever, used.
There is currently no mechanism available for applica-
tions to discover reliably that a packet filtering
Page 5
Internet Draft Midcom Application Interactions April 2001
middlebox is dropping their packets.
It must be noted that even if there were a general
mechanism for discovering middleboxes, network adminis-
trators tend to prefer not to expose network topology
to outsiders (or sometimes even insiders). And it must
be further noted that relying on knowledge of network
topology introduces new failure modes into applica-
tions.
Application designers should be aware that discovery
can expose them to attackers fraudulently representing
themselves as middleboxes and diverting traffic and
that a discovered middlebox should authenticate itself
to the middle box controller or agent.
Eliot Lear has published an internet draft [Lear]
describing the requirements for middlebox discovery.
8. Performance
Among the advantages of externalizing application logic
from a transport-layer middlebox is that it removes a
processing load as well as removing the packet/stream
reassembly latency imposed by stateful inspection.
There can be one area of performance impact, however,
and that is connection establishment. In addition to
introducing at least one additional round trip between
the middlebox and the application controlling it, there
may be other operations required, such as discovery (if
it hasn't already occured), authentication and policy
consultation for authorization, etc. The effect will
likely be negligible for most applications but may be
of concern for voice applications, etc.
9. Security Considerations
One of the foremost considerations must be whether or
not a given agent is authorized to execute given opera-
tions on a particular middlebox. The components of
that authorization decision include a policy infras-
tructure, an authentication infrastructure, and mecha-
nisms to provide identity authentication and source
authentication. Source authentication is needed in
order to prevent the spoofing of authorized control
agents. Any middlebox control facility will need
access to an authentication infrastructure, if one
exists, or will need to pre-share keys, a solution with
clear scaling limitations.
Middlebox control is predicated on the notion that an
application can find a middlebox to control. This
implies exposing elements of network topology to an
application, and many network administrators would
Page 6
Internet Draft Midcom Application Interactions April 2001
prefer not to do that. A middlebox discovery process
could potentially be subverted for the purposes of
locating, say, a firewall in order to attack it. Of
particular concern would be exposing network topology
to applications outside the network perimeter.
Application designers should also be aware that it
could be possible for an attacker to 1) subvert a dis-
covery process to represent him/herself as a middlebox,
or 2) spoof registration and control responses as com-
ing from an existing middlebox in order to divert traf-
fic. The authentication infrastructure must provide
for mutual authentication, which may mean the acquisi-
tion and installation of certificates from a certifi-
cate authority. Self-signed certificates are probably
undesirable in this case.
References
[Carpenter] Carpenter, Brian and Scott Brim, "Middleboxes:
taxonomy and issues," April 2001. Work in
progress.
[Lear] Lear, Eliot, "Requirements for Discovering Mid-
dleboxes," April 2001. Work in progress.
[midcom] "Middlebox Communication (midcom)" working group
charter, http://www.ietf.org/html.charters/mid-
com-charter.html.
[Srisuresh] Srisuresh, P. et al., "Middlebox Communication
Architecture and framework," May 2001. Work in
progress.
10. Author's Address
Melinda Shore
Cisco Systems
809 Hayts Road
Ithaca, NY 14850
USA
Email: mshore@cisco.com
Phone: +1 607 272 7512
11. Intellectual Property Statement
The IETF takes no position regarding the validity or
scope of any intellectual property 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; neither does it represent that
it has made any effort to identify any such rights.
Information on the IETF's procedures with respect to
Page 7
Internet Draft Midcom Application Interactions April 2001
rights in standards-track and standards-related docu-
mentation can be found in BCP-11. Copies of claims of
rights made available for publication and any assur-
ances of licenses to be made available, or the result
of an attempt made to obtain a general license or per-
mission for the use of such proprietary rights by
implementors 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 applica-
tions, or other proprietary rights which may cover
technology that may be required to practice this stan-
dard. Please address the information to the IETF Exec-
utive Director.
12. Full Copyright Statement
Copyright (C) The Internet Society (2000). 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 implementa-
tion may be prepared, copied, published and dis-
tributed, in whole or in part, without restriction of
any kind, provided that the above copyright notice and
this paragraph are included on all such copies and
derivative works. However, 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 procedures 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 Soci-
ety or its successors or assigns. This document and
the information contained herein is provided on an "AS
IS" basis and THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING 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 WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
13. Expiration Date
This memo is filed as <draft-shore-midcom-apps-00.txt>
and expires November, 2001.
Page 8