Middlebox communication architecture and framework
RFC 3303
|
| Document |
Type |
|
RFC - Informational
(August 2002; No errata)
|
|
Last updated |
|
2015-10-14
|
|
Stream |
|
IETF
|
|
Formats |
|
plain text
pdf
html
bibtex
|
| Stream |
WG state
|
|
(None)
|
|
Document shepherd |
|
No shepherd assigned
|
| IESG |
IESG state |
|
RFC 3303 (Informational)
|
|
Consensus Boilerplate |
|
Unknown
|
|
Telechat date |
|
|
|
Responsible AD |
|
Scott Bradner
|
|
IESG note |
|
Responsible: RFC Editor
|
|
Send notices to |
|
(None)
|
Network Working Group P. Srisuresh
Request for Comments: 3303 Kuokoa Networks
Category: Informational J. Kuthan
Fraunhofer Institute FOKUS
J. Rosenberg
dynamicsoft
A. Molitor
Aravox Technologies
A. Rayhan
Ryerson University
August 2002
Middlebox communication architecture and framework
Status of this Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved.
Abstract
A principal objective of this document is to describe the underlying
framework of middlebox communications (MIDCOM) to enable complex
applications through the middleboxes, seamlessly using a trusted
third party. This document and a companion document on MIDCOM
requirements ([REQMTS]) have been created as a precursor to
rechartering the MIDCOM working group.
There are a variety of intermediate devices in the Internet today
that require application intelligence for their operation. Datagrams
pertaining to real-time streaming applications, such as SIP and
H.323, and peer-to-peer applications, such as Napster and NetMeeting,
cannot be identified by merely examining packet headers. Middleboxes
implementing Firewall and Network Address Translator services
typically embed application intelligence within the device for their
operation. The document specifies an architecture and framework in
which trusted third parties can be delegated to assist the
middleboxes to perform their operation, without resorting to
embedding application intelligence. Doing this will allow a
middlebox to continue to provide the services, while keeping the
middlebox application agnostic.
Srisuresh, et al. Informational [Page 1]
RFC 3303 MIDCOM Architecture and Framework August 2002
1. Introduction
Intermediate devices requiring application intelligence are the
subject of this document. These devices are referred to as
middleboxes throughout the document. Many of these devices enforce
application specific policy based functions such as packet filtering,
VPN (Virtual Private Network) tunneling, Intrusion detection,
security and so forth. Network Address Translator service, on the
other hand, provides routing transparency across address realms
(within IPv4 routing network or across V4 and V6 routing realms),
independent of applications. Application Level Gateways (ALGs) are
used in conjunction with NAT to examine and optionally modify
application payload so the end-to-end application behavior remains
unchanged for many of the applications traversing NAT middleboxes.
There may be other types of services requiring embedding application
intelligence in middleboxes for their operation. The discussion
scope of this document is however limited to Firewall and NAT
services. Nonetheless, the MIDCOM framework is designed to be
extensible to support the deployment of new services.
Tight coupling of application intelligence with middleboxes makes
maintenance of middleboxes hard with the advent of new applications.
Built-in application awareness typically requires updates of
operating systems with new applications or newer versions of existing
applications. Operators requiring support for newer applications
will not be able to use third party software/hardware specific to the
application and are at the mercy of their middlebox vendor to make
the necessary upgrade. Further, embedding intelligence for a large
number of application protocols within the same middlebox increases
complexity of the middlebox and is likely to be error prone and
degrade in performance.
This document describes a framework in which application intelligence
can be moved from middleboxes into external MIDCOM agents. The
premise of the framework is to devise a MIDCOM protocol that is
application independent, so the middleboxes can stay focused on
services such as firewall and NAT. The framework document includes
some explicit and implied requirements for the MIDCOM protocol.
However, it must be noted that these requirements are only a subset.
Show full document text