| | | |
| Identify UDP port numbers | |
| on Ea (Eport1, Eport1+1) | |
| for pri-to-ext RTP & RTCP | |
| sessions (RTP1, RTCP1) | |
| | | |
| |++Create NAT Session | |
| | descriptors for | |
| | RTP1, RTCP1; Set the| |
| | parent session to | |
| | point to SIP flow++>| |
| |<+RTP1, RTCP1 session | |
| | descriptors created+| |
| | | |
| |++Permit RTP1 & RTCP1 | |
| | sessions External to| |
| | middlebox, namely | |
| | Ma to Ea:Eport1, | |
| | Ma to Ea:Eport1+1 | |
| | sessions ++++++++++>| |
| |<+Ma to Ea:Eport1, | |
| | Ma to Ea:Eport1+1 | |
| | sessions OKed ++++++| |
| | | |
| | |..redirected..|
| |--------INVITE--------|------------->|
| | | |
| |<-----180Ringing---------------------|
| | | |
|<--180Ringing----| | |
| |<-------200 OK-----------------------|
| | | |
| Identify UDP port numbers | |
| on Pa (Pport2, Pport2+1) | |
| for ext-to-pri RTP & RTCP | |
| sessions (RTP2, RTCP2) | |
| | | |
| |++Create consecutive | |
| | port BINDs on Ma | |
| | for (Pa, Pport2), | |
| | (Pa, Pport2+1) ++++>| |
| |<+Port BINDs created | |
| | on Ma as (Mport2, | |
| | Mport2+1) ++++++++++| |
| | | |
| |++Create NAT Session | |
| | descriptors for | |
| | RTP2, RTCP2; Set the| |
| | parent session to | |
| | point to SIP flow++>| |
| |<+RTP2, RTCP2 session | |
| | descriptors created+| |
| | | |
| Modify the SDP | |
| parameters in "200 OK" | |
| with NAPT PORT-BIND | |
| for RTP2 port on Ma. | |
| | | |
| |++Permit RTP2 & RTCP2 | |
| | sessions External | |
| | middlebox, namely | |
| | Ea to Ma:Mport2, | |
| | Ea to Ma:Mport2+1 | |
| | sessions ++++++++++>| |
| |<+Ea to Ma:Mport2, | |
| | Ea to Ma:Mport2 | |
| | sessions OKed ++++++| |
| | | |
|<---200 OK ------| | |
| | | |
|-------ACK------>| | |
| | |..redirected..|
| |-----------ACK--------|------------->|
| | | |
| | | |
|<===================RTP/RTCP============|=============>|
| | | |
|-------BYE------>| | |
| | | |
| |----------------------|-----BYE----->|
| | | |
| |<----------200 OK--------------------|
| | | |
| |+++Terminate the SIP | |
| | Session bundle +++>| |
| |<++SIP Session bundle | |
| | terminated ++++++++| |
| | | |
| |++Cancel permits to | |
| | sessions External | |
| | middlebox, namely | |
| | Ma to Ea:Eport1, | |
| | Ma to Ea:Eport1+1 | |
| | Ea to Ma:Mport2, | |
| | Ea to Ma:Mport2+1 | |
| | sessions ++++++++++>| |
| |<+Removed permits to | |
| | sessions listed ++++| |
| | | |
|<---200 OK-------| | |
| | | |
Legend: ++++ MIDCOM control traffic
---- SIP control traffic
==== RTP/RTCP media traffic
8.0. Operational considerations
8.1. Multiple MIDCOM sessions between agents and middlebox
A middlebox cannot be assumed to be a simple device implementing just
one middlebox function and no more than a couple of interfaces.
Middleboxes often combine multiple intermediate functions into the
same device and have the ability to provision individual interfaces
of the same device with different sets of functions and varied
provisioning for the same function across the interfaces.
As such, a MIDCOM agent ought to be able to have a single MIDCOM
session with a middlebox and use the MIDCOM interface on the
middlebox to interface with different services on the same middlebox.
8.2. Asynchronous notification to MIDCOM agents
Asynchronous notification by the middlebox to a MIDCOM agent can be
useful for events such as Session creation, Session termination,
MIDCOM protocol failure, middlebox function failure or any other
significant event. Independently, ICMP error codes can also be
useful to notify transport layer failures to the agents.
In addition, periodic notification of various forms of data, such as
statistics update, would also be a useful function that would be
beneficial to certain types of agents.
8.3. Timers on middlebox considered useful
When supporting the MIDCOM protocol, the middlebox is required to
allocate dynamic resources, as specified in policy rule(s), upon
request from agents. Explicit release of dynamically allocated
resources happens when the application session is ended or when a
MIDCOM agent requests the middlebox to release the resource.
However, the middlebox should be able to recover the dynamically
allocated resources, even as the agent that was responsible for the
allocation is not alive. Associating a lifetime for these dynamic
resources and using a timer to track the lifetime can be a good way
to accomplish this.
8.4. Middleboxes supporting multiple services
A middlebox could be implementing a variety of services (e.g. NAT and
firewall) in the same box. Some of these services might have inter-
dependency on shared resources and sequence of operation. Others may
be independent of each other. Generally speaking, the sequence in
which these function operations may be performed on datagrams is not
within the scope of this document.
In the case of a middlebox implementing NAT and firewall services, it
is safe to state that the NAT operation on an interface will precede
a firewall on the egress and will follow a firewall on the ingress.
Further, firewall access control lists, used by a firewall, are
assumed to be based on session parameters, as seen on the interface
supporting firewall service.
8.5. Signaling and Data traffic
The class of applications the MIDCOM architecture addresses focus
around applications that have a combination of, one or more,
signaling and data traffic sessions. The signaling may be done out-
of-band, using a dedicated stand-alone session or may be done in-
band, within a data session. Alternately, signaling may also be done
as a combination of both stand-alone and in-band sessions.
SIP is an example of an application based on distinct signaling and
data sessions. A SIP signaling session is used for call setup
between a caller and a callee. A MIDCOM agent may be required to
examine/modify SIP payload content to administer the middlebox so as
to let the media streams (RTP/RTCP based) through. A MIDCOM agent is
not required to intervene in the data traffic.
Signaling and context specific Header information is sent in-band,
within the same data stream for applications such as HTTP embedded
applications, sun-RPC (embedding a variety of NFS apps), Oracle
transactions (embedding oracle SQL+, MS ODBC, Peoplesoft) etc.
H.323 is an example of an application that sends signaling in both
dedicated stand-alone sessions, as well as in conjunction with data.
H.225.0 call signaling traffic traverses middleboxes by virtue of
static policy, no MIDCOM control needed. H.225.0 call signaling also
negotiates ports for an H.245 TCP stream. A MIDCOM agent is required
to examine/modify the contents of the H.245 so that H.245 can
traverse it.
H.245 traverses the middlebox and also carries Open Logical Channel
information for media data. So, the MIDCOM agent is once again
required to examine/modify the payload content needs to let the media
traffic flow.
The MIDCOM architecture takes into consideration, supporting
applications with independent signaling and data sessions as well as
applications that have signaling and data communicated over the same
session.
In the cases where signaling is done on a single stand-alone session,
it is desirable to have a MIDCOM agent interpret the signaling stream
and program the middlebox (that transits the data stream) so as to
let the data traffic through uninterrupted.
9. Applicability Statement
Middleboxes may be stationed in a number of topologies. However, the
signaling framework outlined in this document may be limited to only
those middleboxes that are located in a DMZ (De-Militarized Zone) at
the edge of a private domain, connecting to the Internet.
Specifically, the assumption is that you have a single middlebox
(running NAT or firewall) along the application route. Discovery of
a middlebox along an application route is outside the scope of this
document. It is conceivable to have middleboxes located between
departments within the same domain or inside the service provider's
domain and so forth. However, care must be taken to review each
individual scenario and determine the applicability on a case-by-case
basis.
The applicability may also be illustrated as follows. Real-time and
streaming applications, such as Voice-Over-IP, and peer-to-peer
applications, such as Napster and Netmeeting, require administering
firewalls and NAT middleboxes to let their media streams reach hosts
inside a private domain. The requirements are in the form of
establishing a "pin-hole" to permit a TCP/UDP session (the port
parameters of which are dynamically determined) through a firewall or
retain an address/port bind in the NAT device to permit sessions to a
port. These requirements are met by current generation middleboxes
using adhoc methods, such as embedding application intelligence
within a middlebox to identify the dynamic session parameters and
administering the middlebox internally as appropriate. The objective
of the MIDCOM architecture is to create a unified, standard way to
exercise this functionality, currently existing in an ad-hoc fashion,
in some of the middleboxes.
By adopting MIDCOM architecture, middleboxes will be able to support
newer applications they have not been able to support thus far.
MIDCOM architecture does not, and must not in anyway, change the
fundamental characteristic of the services supported on the
middlebox.
Typically, organizations shield a majority of their corporate
resources (such as end-hosts) from visibility to the external network
by the use of a De-Militarized Zone (DMZ) at the domain edge. Only a
portion of these hosts are allowed to be accessed by the external
world. The remaining hosts and their names are unique to the private
domain. Hosts visible to the external world and the authoritative
name server that maps their names to network addresses are often
configured within a DMZ (De-Militarized Zone) in front of a firewall.
Hosts and middleboxes within DMZ are referred to as DMZ nodes.
Figure 4 below illustrates the configuration of a private domain with
a DMZ at its edge. Actual configurations may vary. Internal hosts
are accessed only by users inside the domain. Middleboxes, located
in the DMZ may be accessed by agents inside or outside the domain.
\ | /
+-----------------------+
|Service Provider Router|
+-----------------------+
WAN |
Stub A .........|\|....
|
+---------------+
| NAT middlebox |
+---------------+
|
| DMZ - Network
------------------------------------------------------------
| | | | |
+--+ +--+ +--+ +--+ +-----------+
|__| |__| |__| |__| | Firewall |
/____\ /____\ /____\ /____\ | middlebox |
DMZ-Host1 DMZ-Host2 ... DMZ-Name DMZ-Web +-----------+
Server Server etc. |
|
Internal Hosts (inside the private domain) |
------------------------------------------------------------
| | | |
+--+ +--+ +--+ +--+
|__| |__| |__| |__|
/____\ /____\ /____\ /____\
Int-Host1 Int-Host2 ..... Int-Hostn Int-Name Server
Figure 4: DMZ network configuration of a private domain.
10. Acknowledgements
The authors wish to thank Christian Huitema, Joon Maeng, Jon
Peterson, Mike Fisk, Matt Holdrege, Melinda Shore, Paul Sijben,
Philip Mart, Scott Brim and Richard Swale for their valuable
critique, advice and input on an earlier rough version of this
document. The authors owe special thanks to Eliot Lear for kick-
starting the e-mail discussion on use-case scenarios with a SIP
application flow diagram through a middlebox. Much thanks to Bob
Penfield, Cedric Aoun, Christopher Martin, Eric Fleischman, George
Michaelson, Wanqun Bao, and others in the MIDCOM work group for their
very detailed feedback on a variety of topics and adding clarity to
the discussion. Last, but not the least, the authors owe much thanks
to Mark Duffy, Scott Brim, Melinda Shore and others for their help
with terminology definition and discussing the embedded requirements
within the framework document.
11. Security Considerations
Discussed below are security considerations in accessing a middlebox.
Without MIDCOM protocol support, the premise of a middlebox operation
fundamentally requires the data to be in the clear, as the middlebox
needs the ability to inspect and/or modify packet headers and
payload. This compromises the confidentiality requirement in some
environments. Further, updating transport headers and rewriting
application payload data, in some cases, by NAT prevents the use of
integrity protection on some data streams traversing NAT middleboxes.
Clearly, this can pose a significant security threat to the
application in an untrusted transport domain.
The MIDCOM protocol framework removes the need for a middlebox to
inspect or manipulate transport payload. This allows applications to
better protect themselves end-to-end with the aid of a trusted MIDCOM
agent. This is especially the case when the agent is a resident on
the end-host. When an agent has the same end-to-end ability as the
end-host to interpret encrypted and integrity protected data,
transiting a middlebox can be encrypted and integrity protected. The
MIDCOM agent will still be able to interpret the data and simply
notify the middlebox of open holes, install NAT table entries, etc.
Note, however, the MIDCOM framework does not help with the problem of
NAT breaking IPsec since in this case the middlebox still modifies IP
and transport headers.
Security between a MIDCOM agent and a middlebox has a number of
components. Authorization, authentication, integrity and
confidentiality. Authorization refers to whether a particular agent
is authorized to signal a middlebox with requests for one or more
applications, adhering to a certain policy profile. Failing the
authorization process might indicate a resource theft attempt or
failure due to administrative and/or credential deficiencies. In
either case, the middlebox should take the proper measures to
audit/log such attempts and consult its designated MIDCOM PDP for the
required action if the middlebox is configured with one.
Alternatively, the middlebox may resort to a default service deny
policy when a MIDCOM agent fails to prompt the required credentials.
Section 6 discusses the middlebox to MIDCOM PDP interactions in view
of policy decisions.
Authentication refers to confirming the identity of an originator for
all datagrams received from the originator. Lack of strong
credentials for authentication of MIDCOM messages between an agent
and a middlebox can seriously jeopardize the fundamental service
rendered by the middlebox. A consequence of not authenticating an
agent would be that an attacker could spoof the identity of a
"legitimate" agent and open holes in the firewall. Another would be
that it could otherwise manipulate the state on a middlebox, creating
a denial-of-service attack by closing needed pinholes or filling up a
NAT table. A consequence of not authenticating the middlebox to an
agent is that an attacker could pose as a middlebox and respond to
NAT requests in a manner that would divert data to the attacker.
Failing to submit the required/valid credentials, once challenged,
may indicate a replay attack, in which case a proper action is
required by the middlebox such as auditing, logging, or consulting
its designated MIDCOM PDP to reflect such failure. A consequence of
not protecting the middlebox against replay attacks would be that a
specific pinhole may be reopened or closed by an attacker at will,
thereby bombarding end hosts with unwarranted data or causing denial
of service.
Integrity is required to ensure that a MIDCOM message has not been
accidentally or maliciously altered or destroyed. The result of a
lack of data integrity enforcement in an untrusted environment could
be that an imposter will alter the messages sent by an agent and
bring the middlebox to a halt or cause a denial of service for the
application the agent is attempting to enable.
Confidentiality of MIDCOM messages ensure that the signaling data is
accessible only to the authorized entities. When a middlebox agent
is deployed in an untrusted environment, lack of confidentiality will
allow an intruder to perform traffic flow analysis and snoop the
middlebox. The intruder could cannibalize a lesser secure MIDCOM
session and destroy or compromise the middlebox resources he
uncovered on other sessions. Needless to say, the least secure
MIDCOM session will become the achilles heel and make the middlebox
vulnerable to security attacks.
Lastly, there can be security vulnerability to the applications
traversing a middlebox when a resource on a middlebox is controlled
by multiple external agents. A middlebox service may be disrupted
due to conflicting directives from multiple agents associated with
different middlebox functions but applied to the same application
session. Care must be taken in the protocol design to ensure that
agents for one function do not abruptly step over resources impacting
a different function. Alternately, the severity of such
manifestations could be lessened when a single MIDCOM agent is
responsible for supporting all the middlebox services for an
application, due to the reduced complexity and synchronization effort
in managing the middlebox resources.
References
[SIP] Rosenberg, J., Shulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., Schooler, E.,
"SIP: Session Initiation Protocol", RFC3261, June 2002.
[SDP] Handley, M. and V. Jacobson, "SDP: Session Description
Protocol", RFC2327, April 1998.
[H.323] ITU-T Recommendation H.323. "Packet-based Multimedia
Communications Systems," 1998.
[RTP] Schulzrinne, H., Casner, S., Frederick, R. and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", RFC1889, January 1996.
[RTSP] Schulzrinne, H., Rao, A. and R. Lanphier: "Real Time
Streaming Protocol (RTSP)", RFC2326, April 1998.
[FTP] Postel, J. and J. Reynolds, "File Transfer Protocol", STD
9, RFC959, October 1985.
[NAT-TERM] Srisuresh, P. and M. Holdrege, "IP Network Address
Translator (NAT) Terminology and Considerations", RFC
2663, August 1999.
[NAT-TRAD] Srisuresh, P. and K. Egevang, "Traditional IP Network
Address Translator (Traditional NAT)", RFC3022, January
2001.
[NAT-PT] Tsirtsis, G. and P. Srisuresh, "Network Address
Translation - Protocol Translation (NAT-PT)", RFC2766,
February 2000.
[IPsec-AH] Kent, S. and R. Atkinson, "IP Authentication Header", RFC
2402, November 1998.
[IPsec-ESP] Kent, S. and R. Atkinson, "IP Encapsulating Security
Payload (ESP)", RFC2406, November 1998.
[TLS] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC2246, January 1999.
[POL-TERM] Westerinen, A., Schnizlein, J., Strassner, J., Scherling,
M., Quinn, B., Herzog, S., Huynh, A., Carlson, M., Perry,
J. and S. Waldbusser, "Terminology for Policy-Based
Management", RFC3198, November 2001.
[REQMTS] Swale, R. P., Mart, P. A., Sijben, P., Brim, S. and M.
Shore, "Middlebox Communications (midcom) Protocol
Requirements", RFC3304, August 2002.
Authors' Addresses
Pyda Srisuresh
Kuokoa Networks, Inc.
475 Potrero Ave.
Sunnyvale, CA 94085
EMail: srisuresh@yahoo.com
Jiri Kuthan
Fraunhofer Institute FOKUS
Kaiserin-Augusta-Allee 31
D-10589 Berlin, Germany
EMail: kuthan@fokus.fhg.de
Jonathan Rosenberg
dynamicsoft
72 Eagle Rock Avenue
First Floor
East Hanover, NJ 07936
U.S.A.
EMail: jdrosen@dynamicsoft.com
Andrew Molitor
Aravox technologies
4201 Lexington Avenue North, Suite 1105
Arden Hills, MN 55126
U.S.A.
voice: (651) 256-2700
EMail: amolitor@visi.com
Abdallah Rayhan
WINCORE Lab
Electrical and Computer Engineering
Ryerson University
350 Victoria Street
Toronto, ON M5B 2K3
EMail: rayhan@ee.ryerson.ca, ar_rayhan@yahoo.ca
Full Copyright Statement
Copyright (C) The Internet Society (2002). 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, published
and distributed, 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 Society 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.
Acknowledgement
Funding for the RFCEditor function is currently provided by the
Internet Society.