NEC Europe Network Laboratories--MIDCOM

MIDCOM Middlebox Traversal



The Internet is, despite the fact of openness and end-to-end philosophy, separate by several devices that control packet flows and do address translation; the first are packet filter firewalls that enforce local network policies to packet flows and the latter are Network Address Translators (NATs) in all flavours. The general term for this kind of devices is middlebox. These middleboxes can allow Internet traffic to traverse as long as they know how to handle this and as long as the local policies permit the traffic. This holds true for applications like WWW that use fixed port numbers and TCP for instance. Other applications, like IP telephony, use unpredictable port numbers and UDP. The latter type of traffic is likely to be blocked by any middlebox. The MIDCOM project works on two solutions for traversing middleboxes, a call agent based off-path and RSVP related path-coupled signalling approach. The other side are applications that run over the Internet and rely on the end-to-end service of the Internet and do not known anything about middleboxes and their impact on network behaviour. As long as the applications use fixed port numbers and certain transport protocols, like TCP, they easily can traverse these types of middleboxes mentioned earlier. But when the applications use unpredictable port numbers and UDP as transport protocol for instance, middleboxes are obstacles for several reasons. One example is IP telephony over NATs; usually there is no way of using IP telephones across NATs.


Middleboxes in Internet

One attempt to cope with this problem is embedding application logic into middleboxes, known as application level gateways (ALGs) integrated into middleboxes (see Figure 2). These ALGs intercept traffic for a given application and configure the middlebox accordingly.


Traditional Middleboxes with integrated ALGs

Applications can now traverse middleboxes, but some limitations apply to this concept: Middlebox can only understand known applications. The introduction of a new application or protocol results in a new middlebox operating system or even new hardware. The middlebox has to deal with regular traffic and the processing of application information in the ALGs. The scalability of this resolution is limited, since the middlebox has to perform not only packet filtering and address translation tasks Some signal protocols, like SIP, using a different path as the actual data traffic takes (topology problem). So the wrong middlebox might be configured

Two solutions to this list of problems are decomposed Middleboxes (off-path signalling) and path-coupled signalling.
Decomposed Middleboxes
The decomposed middlebox architecture separates the application level gateway (ALG) from the middlebox and introduces a new configuration protocol between those. Through the separation the middlebox is relieved of the application level gateway burden, but the topology problem is still valid.

Decomposed Middleboxes

The protocol between ALGs and middlebox is the MIDCOM protocol. The IETF Middlebox Communication (MIDCOM) working group is defining this protocol currently. Two RFCs are already published, one for the MIDCOM framework (RFC 3303) and MIDCOM protocol requirements (RFC 3304). The protocol semantics are currently under discussion and will be finished soon. The working group is considering a MIB module as the MIDCOM protocol solution. NEC's network laboratories develop their own MIDCOM type protocol, based on the framework, protocol requirements and protocol semantics: SImple Middlebox Configuration (SIMC) Protocol. The SIMCO protocol is a lightweight MIDCOM protocol.

Path-coupled Signalling
Another way of configuring middleboxes dynamically is path-coupled signalling. The middlebox configuration signalling follows the same way as the actual traffic, as known for instance of RSVP Quality of Service (QoS) signalling. The Next Step in Signalling (NSIS) working group of the IETF is designing a new QoS protocol that can succeed RSVP in the future. This NSIS protocol should not be limited to QoS signalling only, but provide other functionalities like middlebox configuration as well. The idea is to send packets with middlebox configuration information along the data path and the middlebox are configured according this information (see figure below).

Path-coupled Middlebox Configuration


M. Stiemerling, J. Quittek, Middlebox Configuration Protocol Design, IEEE IPOM 2002 Workshop, October 2002. MIDCOM Semantics: M. Stiemerling, J. Quittek, T. Taylor: MIDCOM Protocol Semantics, RFC 3989, February 2005. MIDCOM MIB: J. Quittek, M. Stiemerling, P. Suresh: Definitions of Managed Objects for Middlebox Communication, <draft-ietf-midcom-mib-05.txt>, March 2005. NEC's MIDCOM Protocol called SIMCO: M. Stiemerling, J. Quittek, C. Cadar: Simple Middlebox Configuration (SIMCO) Protocol Version 3.0, Internet draft, <draft-stiemerling-midcom-simco-07.txt>, September 2004. MIDCOM MIB Analysis: M. Barnes, W. Hardaker, D. Harrington, J. Quittek, M. Stiemerling, T. Taylor: Middlebox Communications (MIDCOM) Protocol Managed Objects Analysis, Internet draft, <draft-ietf-midcom-mib-analysis-01.txt>, October 2003. M. Barnes (Ed.), J Renkel, J. Quittek, D. Harrington, S. Sen, C. Aoun, T. Taylor, K.-H. Chan, L.-N. Hamer, R. Penno: MIDCOM Protocol Evaluation: Middlebox Communications (MIDCOM) Protocol Evaluation, RFC 3097, June 2005.

For more information please use our contact form. IETF MIDCOM working group IETF NSIS working group

Last modified 01-Sep-2010

| Back to Projects | Top |