[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

Internet Engineering Task Force                             Jiri Kuthan
Internet Draft                                                GMD Fokus
draft-kuthan-midcom-framework-00.txt                 Jonathan Rosenberg
November, 2000                                              dynamicsoft
Expires: May 2001

          Middlebox Communication: Framework and Requirements

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-

   Internet-Drafts are draft documents valid for a maximum of six
   months and may be updated, replaced, or obsoleted by other documents
   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

   The list of Internet-Draft Shadow Directories can be accessed at


   The purpose of this document is to develop framework and
   requirements for a protocol that will allow for communicating
   control data associated with IP/transport-layer data flows or
   aggregates of them between intermediate packet processing devices
   and external controllers.

   The protocol will be extensible in order to allow for communicating
   arbitrary control data associated with packet flows and defining
   packet flow processing. It will include provisions for verifying the
   integrity of each message as well as ensuring authentication of all
   parties involved in the transactions.

   A major application of this protocol will be the control of packet
   processing policies in decomposed firewalls/NATs/NAT-PTs by
   externalized Application Level Gateways. This particular use will
   relieve firewalls/NATs from application-layer processing to improve
   their maintainability and performance.

   Examples of other possible applications include but are not limited
   to buffer management and load balancing.

J. Kuthan, J. Rosenberg                                       [Page 1]

Internet Draft    Middlebox Framework and Requirements    November 2000


   1 Introduction.....................................................2
   2 Terminology......................................................3
   3 Case Study: Traversal of Applications Using Session Control
    Protocols across Firewalls/NATs ..................................5
   4 Protocol Requirements for FCP....................................7
   4.1 FCP Operational Model..........................................7
   4.2 Functional Requirements: Management of Packet Flow Processing
      States .........................................................7
   4.3 Rule Manipulation Operations...................................7
   4.4 Soft-state Rule Design.........................................7
   4.5 Rule Language..................................................7
   4.5.1 Packet Matching Expressions..................................8
   4.5.2 Rule Processing Precedence...................................8
   4.5.3 Control State Content........................................9
   4.6 Feedback......................................................10
   4.7 Security......................................................11
   4.8 Reliability...................................................11
   4.9 Real-time Operation...........................................11
   4.10 Extensibility................................................11
   4.11 On Support Specific to NAT/NAPT/NAT-PT.......................12
   5 Related Issues..................................................13
   5.1 Access Control................................................13
   5.2 Rule Ownership................................................13
   5.3 Default Flows.................................................13
   5.4 Location of FCP Controllers...................................14
   6 Open Issues.....................................................14
   6.1 Location of Intermediate Devices..............................14
   7 Performance and Scalability Considerations......................15
   8 Security Considerations.........................................15
   9 Document Status.................................................15
   10 Acknowledgments................................................16

1 Introduction

   Though the Internet has been designed to provide network layer
   connectivity end to end [2] it actually consists of mixed network
   realms. These include IPv4 networks, IPv6 networks, networks hidden
   behind NATs and firewalls. This problem was referred to as
   "transparency loss" and discussed in [3]. Applications being run
   across mixed realms may experience lack of interoperability or
   suboptimal performance.

   To assists applications in traversing network boundaries Application
   Level Gateways (ALGs) embedded in intermediate devices have been
   used. However, tight coupling of application and network/transport
   layer processing results in reduced maintainability of the
   intermediate devices. Built-in application awareness typically
   requires updates of operating systems with new applications or
   versions of it. Operators of such systems wanting to support new

J. Kuthan, J. Rosenberg                                       [Page 2]

Internet Draft    Middlebox Framework and Requirements    November 2000

   applications cannot use software supplied by third parties and are
   at the mercy of vendors of their equipment. Furthermore, support of
   numerous application protocols increases complexity of such
   integrated systems and may affect performance.

   To deal with this sort of problems we suggest decomposition of
   application awareness from network/transport layer processing. We
   assume that applications control network/transport layer processing
   in intermediate devices through a generic application-independent
   control protocol. In the common case, the application-awareness
   resides in proxies ("externalized ALGs") that hide boundary
   traversals from end-devices.

                          +------+-----------+ |
    +----------+   FCP    |      | Per-Flow  | |
   +----------+|..........|      | State     | |
   |  ALGs    ||..........| FCP  | Table     | | policy   +--------+
   +----------+           | unit |-----------| | protocol | policy |
                          |      | ACL      ~~~~~~~~~~~~~~+ server |
                __________+------+-----------+ |          +--------+
                          |  Intermediate      |
                          |    Device          |
                 Device     |   |
                 Interfaces |   |      ...
                           IN  OUT     ...
       Legend: .... FCP
               ~~~~ policy protocol

             Figure 1: Middlebox Communication Architecture

   The rest of this document describes framework and requirements for
   the missing piece, the control protocol. We refer to this protocol
   as Flow Processing Control Protocol (FCP). Discussion on how FCP
   maps or does not map to an existing protocol is out of scope of this
   document. Section 2 defines terms used throughout this memo. In
   Section 3, we demonstrate the use of the FCP in a case study. We
   formulate protocol requirements in Section 4. Issues that are
   related to protocol operation but do not affect protocol
   specification are summarized in Section 5. Unresolved issues are
   identified in Section 6. Section 7 reviews performance issues.
   Security is considered in Section 8 and status of this memo in
   Section 9.

2 Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALLNOT",
   this document are to be interpreted as described in RFC 2119.

J. Kuthan, J. Rosenberg                                       [Page 3]

Internet Draft    Middlebox Framework and Requirements    November 2000

   o  Endpoint address - general term describing source or destination
      of a packet. This is, depending on context, IP address and/or
      TCP/UDP port number.
   o  Packet matching expression - expression that specifies values of
      header fields of packets to be selected. The inspected header
      fields MAY be but are not limited to source and destination IP
      addresses, TCP/UDP port numbers, etc.
   o  Packet flow - a sequence of packets matched by a packet matching
   o  Rule - a packet matching expression and control state used to
      determine processing of packets matched by the expression.
   o  Session - a set of packet flows belonging to an application.
   o  Session control protocol - a protocol used to negotiate endpoint
      addresses of flows belonging to a session. Examples of such
      protocols are SIP, H.323, RTSP.
   o  Proxy - an intermediary server that relays application messages
      from one entity to another one. A proxy acts as server for message
      senders and as client on behalf of the senders for message
      receivers. It may be used for enforcement of application-level
      policies such as content filtering or message translation. With
      applications using session control protocols, proxies typically
      relay session control protocols and do not relay data flows
      belonging to a session.
   o  Packet filter - a network device that examines headers of
      forwarded packets and allows only packets conforming to a security
      policy to pass through. The security policy defines which endpoint
      addresses are considered trustworthy and which are not. For
      example, it may permit data traffic of an application identified
      by a port numbe only from/to a trusted proxy.
   o  Network Address Translator (NAT) - a packet processing device that
      is able to map source and/or destination endpoint addresses of
      forwarded packet flows to a pool of other addresses. This
      technique is used to conserve IP address space and/or hide IP
      address of hosts behind the NATs from outside of the NATs. The NAT
      concept is described in [10].
   o  Bind - a pair consisting of an original and translated endpoint
   o  Intermediate device - a packet-processing device located along
      end-to-end path. It may be a packet filter, NAT, intrusion
      detection system, load balancer, etc.
   o  Firewall - centrally maintained devices set-up to increase network
      security by putting restrictions on information flows. The
      restrictions are applied with packet filters at the packet level
      and/or proxies at the application level. Optionally, NATs may be
      used. Note that the term "firewall" is sometimes used to refer to
      packet filters.
   o  Application Level Gateways (ALGs) - application-aware modules that
      control processing state in firewalls/NATs and manipulate
      application messages to accomplish firewall/NAT traversal.
      Typically, ALGs are embedded in firewalls/NATs. They may also be

J. Kuthan, J. Rosenberg                                       [Page 4]

Internet Draft    Middlebox Framework and Requirements    November 2000

      externalized to remote proxies if a control interface between them
      and firewalls/NATs is provided [4].
   o  Flow Processing Control Protocol (FCP) - protocol for
      communicating flow processing policy between external controllers
      and intermediate devices. The intermediate devices accept only
      authorized FCP requests. The authorization can come from an
      internal access control list or an external policy server.
   o  Access Control List (ACL) - policy defining who may
      access/manipulate controlled devices with FCP. The ACLs may be
      outsourced to an external policy server.

3 Case Study: Traversal of Applications Using Session Control Protocols
   across Firewalls/NATs

   Firewalls are trusted, administrator-maintained devices used to
   increase network security by enforcing restrictions on information
   flows. The restriction policies are centrally defined and maintained
   by network administrators. The firewalls consist of proxies and
   packet filters. Proxies are application-aware entities acting on
   behalf of untrusted hosts at application layer. They examine
   application protocol flows and allow only messages conformant to
   security policies to pass through. Optionally, they modify the
   messages to make them policy-conformant. Packet filters are used to
   impose security restrictions at lower layers. They usually inspect
   IP and TCP/UDP packet headers against tables of filtering rules.
   Only conforming IP packets are allowed to pass through filters. The
   packet filtering policy may be either 'default-permit' or 'default-
   deny'. 'Default-permit' policy allows all but explicitly stated IP
   flows whereas 'default-deny' policy allows only explicitly stated IP
   flows to pass through. Typically, the latter policy is set up to
   allow traffic from and to trusted proxies to pass through. It
   provides higher security by being more restrictive. Thus, it is
   frequently deployed in corporate networks.

   Unfortunately, this policy makes firewall traversal difficult for
   applications using session bundles. This means that such
   applications (e.g., SIP [5], H.323 [6], RTSP[7], and FTP
   [8])negotiate IP addresses and port numbers with a session control
   protocol dynamically and then use the negotiated addresses to
   establish packet streams for transport of data. This technique is
   useful, for example, if multiple applications want to receive RTP
   [9] flows and cannot share the same TCP/UDP port number or an
   application uses port numbers to demultiplex multiple incoming RTP
   flows. It is also necessary if IP address information is dynamic.

   As a result, dynamically created sessions fail to traverse firewalls
   deploying static 'default-deny' filtering policies. If network
   address translation (NAT)[10] is deployed the traversal fails as
   well because session signaling conveys unroutable IP addresses and
   port numbers. This problem has been addressed in firewalls/NATs by
   usage of embedded Application Level Gateways (ALGs) [15]. They adapt

J. Kuthan, J. Rosenberg                                       [Page 5]

Internet Draft    Middlebox Framework and Requirements    November 2000

   packet processing policy to application needs dynamically. However,
   embedded ALGs suffer from limited maintainability, increase
   complexity of firewalls/NATs and fail to operate if message
   authentication or encryption is used.

   Thus we suggest using external application proxies that control
   firewalls/NATs and relieve them from application processing.
   Arbitrary application proxies may be added to manageable firewalls
   easily. Hop-by-hop security is enabled. Existing software such as
   SIP proxies or H.323 gatekeepers may be used without duplicating the
   applications' protocol stacks in the firewalls/NATs. The reference
   scheme is depicted in Figure 2:. There are FCP-enabled, trusted,
   administrator-maintained proxies acting as external ALGs and
   controlling a packet filter located within the same administrative
   domain. The packet filter implements the 'default-deny' packet
   filtering policy. It permits session control traffic from and to the
   trusted proxies and accepts FCP requests from them. The proxies use
   their application-awareness to control the packet filter dynamically
   with FCP. They also enforce application-level policy such as
   dropping messages infected with known viruses, or lacking user
   authentication. The policy decisions may be delegated to an external
   policy server.

   | App.   |
   | Policy |         +---------+     SIP
   | Server |~~~~~~~~~| SIP     +_____________     |
   +--------+ ________| Proxy   |             \    |
             /        +---------+..           +----+---------------+
            |                     :    FCP    +------+-----------+ |__
            |  RSTP +----------+  :...........|      | Per-Flow  | |__
        SIP |   ____|  RSTP    |..............|      | State     | |__
            |  /    |  Proxy   |______________| FCP  | Table     | |
            | |     +----------+              | unit | --------  | |
            | |  FTP  +---------+.............|      | ACL       | |
            | |  _____|FTP Proxy|_____________+------+-----------+ |
            | | /     +---------+             |      Packet        |
            | | |                        -----|      Filter        |--
         +-----------+                  /-----|                    |--
        +-----------+|   data streams  //     +----+---------------+
       +-----------+||----------->----//           |
       |end-devices||------------<-----            |
       +-----------+   (RTP, ftp-data, etc.)       |
              Inside                               |       Outside

       Legend: ---- raw data streams
               ____ application control protocols
               .... FCP
               ~~~~ policy protocol

          Figure 2: Use of FCP for Firewall/NAT Decomposition

J. Kuthan, J. Rosenberg                                       [Page 6]

Internet Draft    Middlebox Framework and Requirements    November 2000

4 Protocol Requirements for FCP

4.1 FCP Operational Model

   In the remainder of this document we assume a model in which packet
   processing in an intermediate device located at a network edge is
   determined by an ordered set of rules. The rules consist of packet
   matching expressions and control state. The packet matching
   expressions select packets and associated control state determines
   how selected packets are treated. A packet may match multiple packet
   matching expressions. If this happens the first one will be taken.
   The rules are manipulated with FCP dynamically. Multiple FCP
   controllers MAY control a single intermediate device. It is expected
   that only a few trusted hosts from a single administrative domain
   will act as FCP controllers.

4.2 Functional Requirements: Management of Packet Flow Processing

   The primary goal of FCP is to allow for remote dynamic management of
   packet flow processing rules. As a minimum requirement, the FCP MUST
   enable controllers to permit/forbid processing of specific packet
   flows and request/release NAT/NAPT/NAT-PT[11] translations.

4.3 Rule Manipulation Operations

   FCP MUST allow for setting, releasing and querying packet flow
   processing rules. Operations like modification of existing rules and
   keeping them alive are most likely to be implemented with the 'set'

   The 'set' operation MAY either specify values of updated state
   elements explicitly or omit them to allow controlled entities to
   assign appropriate values. These MAY be default values (e.g. 0 for
   packet counter), ephemeral values, or current values if the state
   elements already exists (useful for keep-alive messages).

4.4 Soft-state Rule Design.

   To avoid accumulation of stale rules in case of controller failures
   rules MUST have timers that expire if they are no more refreshed by
   controllers. FCP MUST enable controllers to refresh rules
   periodically. FCP MUST also allow controllers to set the timer's
   length -- it is frequently a controller that knows best what timer
   length is appropriate. If a controller does not specify timer value
   explicitly a default value will be assigned. A trivial value for
   infinite timer MUST be defined.

4.5 Rule Language

J. Kuthan, J. Rosenberg                                       [Page 7]

Internet Draft    Middlebox Framework and Requirements    November 2000

   This section specifies requirements for the language of packet
   rules. Note that FCP-controlled hosts have to understand all
   expressions written in this language but FCP controllers may use
   only a subset of them.

4.5.1 Packet Matching Expressions

   A) As a minimum requirement, the language of packet matching
      expressions MUST allow for specification of the following
      protocols and their respective header fields:
     -  IPv4: source and destination IP address or group of them
        determined by a netmask, protocol number, TOS field
     -  IPv6: source and destination IP address or group of them
        determined by a netmask, next header fields (Note that multiple
        fields may need to be traversed until a match is found.),
        traffic class field
     -  UDP: source and destination port numbers or group of them
     -  TCP: source and destination port numbers or group of them, "SYN
        packets" permission
     -  ICMP: type and code
     -  IGMP: type

   B) FCP controllers MUST be able to specify in which direction
      packets may traverse controlled devices. This requires notion of
      device interfaces. The notion of interface is abstract and
      independent on interface technology and assigned IP address.
      Support for generic predefined interface names "in", "out",
      "loopback" (synonym for senders and receivers located at the
      controlled device), and "DMZ" (demilitarized zone) is REQUIRED.
      Packet traversal direction may be expressed in various ways, for
      example by inbound and outbound interfaces or by interface and
      direction in which packets pass it.

4.5.2 Rule Processing Precedence

   The ability to indicate desired rule processing precedence is
   REQUIRED to enable controlled devices to resolve conflicts between
   multiple applicable matching rules in a predictable manner. If no
   precedence is specified for a rule, default precedence will be
   assigned by FCP-controlled device. Multiple rules MAY share a single

     Note: Though precedence sharing leaves processing order of rules
     with the same precedence undetermined it greatly simplifies
     certain common cases. For example, allocating a single precedence
     for all dynamically generated firewall pinholes does not affect
     firewall's behavior because all the pinhole rules result in the
     same action, which is packet forwarding. Then none of multiple FCP
     controllers needs to determine at which position a new rule will
     be inserted in a rule base.

J. Kuthan, J. Rosenberg                                       [Page 8]

Internet Draft    Middlebox Framework and Requirements    November 2000

4.5.3 Control State Content

   The control state associated with a packet matching expression in a
   rule keeps information related to a packet flow. It MAY include flow
   processing actions, timer information, number of matched packets,
   traffic limitations, etc. Members of the control states are subject
   to future extensions.

   The following control state members are REQUIRED:

   A) "Action" defines whether matched packets are forwarded. It takes
      the values 'pass packets', 'drop packets with or without ICMP

   B) "Rule timer" defines time remaining until state expiration. See
      also discussion of soft-state rule design.

   C) "Logging" of asynchronous events related to a rule. The protocol
      MUST allow FCP controllers to request logging of asynchronous
      events such as packet match and timer expiration. The protocol
      MUST enable controllers to specify log level and frequency. The
      log frequency is used to avoid voluminous logging if an event
      occurs frequently. Choice of the notification/logging mechanism
      is a configuration option that does not need to be specified with

   D) Unique "flow state identifiers" are REQUIRED unless matching
      expressions are uniquely identifiable. Otherwise, state
      modification/releasing could not work consistently. The
      identifiers may be generated either by controllers or by
      controlled devices. They may be random or ephemeral. If
      controllers generate them, they MUST be random to avoid
      collisions with identifiers generated by other controllers. If
      controlled devices generate identifiers, they MAY be ephemeral.
      Ephemeral identifiers are typically shorter but lose their
      uniqueness under a failure.

   E) "Packet modifier" allows to describe one or more rules for re-
      writing header fields of matched accepted packets. The modifier
      rules will consist of identification of the packet fields to be
      changed, operators (at least the assignment operator is REQUIRED)
      and operands. In particular, the modifier MUST be able to change
      the following protocol header fields:
     -  IPv4: IP addresses, TOS field
     -  IPv6: IP addresses, traffic class field
     -  UDP: port numbers
     -  TCP: port numbers

       Note that if modifiers are used packet checksums MUST be

J. Kuthan, J. Rosenberg                                       [Page 9]

Internet Draft    Middlebox Framework and Requirements    November 2000

   The following control state members are RECOMMENDED:

   F) "Packet counter" keeps number of packets matched by a rule.

   G) "Maximum packets per second" specifies the maximum allowed packet
      rate of a flow. Packets exceeding this rate will be dropped.

   H) "Maximum bitrate" specifies the maximum allowed bitrate of a
      flow. Packets exceeding this rate will be dropped.

   I) "Inactivity timer" specifies period of time after which a rule is
      released if no packet matches.

   J) "Reflexive Rules": In order to allow replies to TCP/UDP data
      flows originated from the internal side of firewall while still
      keeping the filtering policy as restrictive as possible, so-
      called reflexive rules are used. Reflexive rules are rules that
      allow packet flows reverse to explicitly permitted active flows.
      They are defined implicitly by permitting their generation within
      specification of the original explicit rules. They specify the
      same protocol, IP addresses, port numbers as flows matching the
      original rule do except the addresses and port numbers are
      swapped. If permitted, packet filters generate a reflexive rule
      whenever a new flow matches an explicit rule. No controller's
      intervention is needed. The reflexive rules are valid only
      temporarily. They MUST be released when an inactivity timer
      expires, the flow is terminated explicitly (e.g., by a FIN
      segment with TCP) or the original rule is deleted. If creation of
      reflexive rules is supported, FCP MUST allow to specify values of
      their control state members.

       Note: If endpoint address modifiers are enabled in the original
       rules they MUST be reflected in the reflexive rules; namely
       packet-matching expressions of the reflexive rules MUST match
       flows reverse to modified flows and modifiers MUST be enabled to
       translate endpoint addresses of reverse flow to addresses before

4.6 Feedback

   FCP controllers need to receive feedback on their control messages
   in order to learn about results of requested operations. Both
   positive and negative responses are REQUIRED.

   Positive responses indicate successful operation and MAY possibly
   describe content of the controlled states or part of them. Per-flow
   control state or part of it is always returned if it was asked for
   by 'query' operation.

J. Kuthan, J. Rosenberg                                      [Page 10]

Internet Draft    Middlebox Framework and Requirements    November 2000

   Negative responses indicate failures and describe reasons for them.
   Minimum negative responses REQUIRED are "Authentication failed",
   "Not permitted", "Syntax Error".

4.7 Security

   In order to prevent unauthorized entities from manipulating the
   state of controlled device the FCP channel MUST be secure. It MUST
   include provisions for verifying the integrity of each message as
   well as ensuring authentication of all parties involved in the

   It is RECOMMENDED that the FCP channel is private so that a
   malicious listener cannot find out packet processing policy easily.

   The security protocols may take place either at lower layers (IPSec,
   TSL) or at the FCP layer.

   Though IP-address based authentication may be satisfactory in
   particular cases cryptographic authentication is REQUIRED generally.

       Note that we discuss the security between FCP controllers and
       controlled device. Security mechanisms used by applications to
       communicate with FCP controllers are a separate issue out of
       scope of this memo.

4.8 Reliability

   As with almost any other control protocol reliability is REQUIRED
   regardless if it is implemented by FCP itself or an underlying
   transport protocol.

4.9 Real-time Operation

   The protocol transactions must be fast in terms of RTT to avoid
   introducing delays to applications. Unless network loss results in
   retransmission, total transaction time SHOULD be one RTT.

       Note: If TCP is used as underlying protocol to provide
       reliability, pre-established TCP connections may be used to
       reduce transaction time.

4.10 Extensibility

   Protocol extensibility is REQUIRED in order to enable reuse of FCP
   for control of a variety of packet-processing mechanisms. In
   particular, adding new control state fields (e.g., buffer management
   information), new reply codes and elements of packet matching
   expression language MUST be supported.

J. Kuthan, J. Rosenberg                                      [Page 11]

Internet Draft    Middlebox Framework and Requirements    November 2000

   The protocol MUST convey protocol version number in order to make
   transition to potential future versions easier.

4.11 On Support Specific to NAT/NAPT/NAT-PT

   One of the FCP purposes is to communicate NAT/NAPT/NAT-PT binds
   between controllers and controlled devices. Knowledge of the binds
   is necessarily needed by session control proxies to operate

   The primary question is who creates the binds. One alternative is
   controllers request a new bind and NATs create and return it. The
   other choice is the controllers create a bind and instruct NATs to
   use it.

   Locating the bind logic in NATs follows the decomposition concept
   "IP/transport intelligence in controlled devices, application
   intelligence out of them". It relieves controllers such as SIP
   proxies from maintenance of the address pools and making bind
   assignments. It avoids collisions that would be due if multiple
   controllers would access a single device. (We do not consider
   splitting a pool of public addresses among multiple controllers a
   solution. It would beat the purpose of NAT which is address

   A minor drawback of this logic placement is it requires two-stage
   transactions if NATs are co-located with firewalls. In the first
   stage, a controller must find out, if NAT applies to a given address
   and request a bind to include in its signaling. In the second stage,
   when application signaling is over, it permits a packet flow using
   the reserved translation. With bind logic residing in controllers,
   both operations may be done jointly in the second phase and the
   first phase can be skipped.

   A specific scenario where locating the bind logic to controllers is
   advantageous is if a controller wants to make sure the same address
   translation is applied in multiple controlled devices. Clearly, this
   would not be possible if the devices assigned the binds

   We leave the answer to location of bind intelligence to
   configuration. It is REQUIRED that FCP supports both alternatives.
   The following protocol operations are REQUIRED:

   o  FCP controllers MUST be able to request NAT translations. If NAT
      is used, controlled devices allocate an address translation and
      return it.
   o  FCP controllers MUST be able to set NAT translations. (Note that
      this can be accomplished with modifiers.) Controlled devices MUST
      be able to indicate if the translation cannot be set because it is
      already reserved.

J. Kuthan, J. Rosenberg                                      [Page 12]

Internet Draft    Middlebox Framework and Requirements    November 2000

   o  With NAPT, allocating port blocks is REQUIRED, i.e., FCP
      controllers MUST be able to request a translation of a contiguous
      block of port numbers and controlled devices MUST allocate a
      contiguous block of translated port numbers to such request. The
      least significant bit of both private and translated port numbers
      MUST be same. It is needed, for example, by RTP [9], which
      recommends allocation of even port numbers for itself, subsequent
      port number for RTCP and contiguous block of port numbers for
      layered encoding applications.
   o  The controllers MUST be able to release the allocated bindings.
   o  The allocated address bindings are subject to timer expiration in
      a similar way as soft-state packet-processing rules are.

5 Related Issues

   This Section explicitly names related features that are out of scope
   of protocol requirements and are matter of implementation,
   administrative policy or anything else.

5.1 Access Control

   There may be different access control lists (ACLs) defining who may
   access and modify what rules in an intermediate device. For example,
   an ACL may specify that an FCP controller may only control rules
   describing traffic to and from a specific subnet. Additionally, it
   may define in which way the controller is required to authenticate
   and which precedence it may use for its rules. The access control
   policies may be stored and applied locally or they may be outsourced
   to an external policy server using a policy protocol. In either case
   they are out of scope of FCP. The only required FCP feature is
   authentication support.

5.2 Rule Ownership

   Multiple controllers may control a single device with FCP. It is
   desirable to avoid modification of per-flow control states by other
   entities than those that created them (perhaps with exception of a
   network manager). Thus, the controlled devices MUST implement the
   notion of rule ownership. The only required protocol functionality
   is authentication.

5.3 Default Flows

   If a packet does not match any of matching expressions maintained in
   a packet filter a default rule has to be applied. Otherwise, packet
   handling would be undefined. Thus, all packet filters controlled by
   FCP must always maintain the default rule. The matching expression
   of the rule matches all packets at lowest priority so that any other
   matching rules take precedence over it. The content of the default
   control state MAY be modified with FCP, the matching expression MUST

J. Kuthan, J. Rosenberg                                      [Page 13]

Internet Draft    Middlebox Framework and Requirements    November 2000

5.4 Location of FCP Controllers

   FCP controllers may be located on any side of controlled network
   device. Their location with respect to the controlled device does
   not affect protocol specification but may result in different
   protocol flows. For example, an application proxy located on the
   private side of a NAT needs to set up a single permanent translation
   that enables it to receive inbound messages and forward them to
   their destinations. If the proxy is located on the public side, it
   needs to set up multiple translations for inbound messages forwarded
   to individual destinations located on the private side.

6 Open Issues

6.1 Location of Intermediate Devices

   Determining which intermediate device a controller should control is
   out of the scope of this document. Administrators can accomplish
   this task manually. Alternatively, a discovery protocol could be

   A difficult problem arises if packet flows may take path through
   multiple intermediate devices at the network edge. FCP controllers
   cannot easily determine which of them they should control. The
   problem is illustrated in the example depicted in Figure 3:

                           IN | OUT
   +-----+    SIP     +------------+            +-------+
   | SIP |____________| firewall 1 |____________| SIP   |
   |proxy|............|            |            | proxy |
   +-----+    :       +------------+            +-------+
      |       : FCP       ... |                     |
      | MGCP  :       +------------+           MGCP |
      |       :.......|firewall i  |                |
   +--------+      :  +------------+            +-------+
   |media   |      :      ... |        ?<-------|media  |
   |gateway |--->? :  +------------+            |gateway|
   +--------+      :..|firewall N  |            +-------+

          Figure 3: Controlling Multiple Intermediate Devices

   In this example, multiple firewalls 1 .. N are present in a network.
   A SIP proxy relays SIP signaling, has knowledge of all the firewalls
   and is authorized to control them. It knows source and destination
   endpoints of data flows belonging to a session but does not know
   which of the firewalls they will traverse. It cannot calculate it

J. Kuthan, J. Rosenberg                                      [Page 14]

Internet Draft    Middlebox Framework and Requirements    November 2000

   because it does not know routing tables along the entire end-to-end

   Solutions are still sought. A possible solution is to let
   controllers instruct all controlled devices in parallel, most likely
   using multicast. This solution scales only for a small number of
   controlled devices. With NAT, it assumes the translation assignments
   to be communicated from FCP controllers to controlled devices.

7 Performance and Scalability Considerations

   The ability to add processing rules to control packet-processing
   devices dynamically may result in creation of large and rapidly
   changing rule tables. For example, if FCP is used to open pinholes
   in a 'default-deny-and-dynamic-open' firewall for Internet telephony
   sessions the table size grows with number of sessions linearly. The
   lookup processing overhead grows as well and may lead to increased
   packet latency. Maintenance of per-flow states makes use of FCP
   meaningful only in network edges.
   Mechanisms for fast rule lookup in large, frequently changing filter
   databases are needed. Results of some recent research in this area
   were published in [12], [13], and [14]. Use of packet modification
   may also affect processing performance.

   A performance improvement may be reached administratively by
   definition of an application-aware rule precedence policy. A
   controller may request that rules for packet flows with higher
   expected packet rate will be assigned a higher precedence than rules
   for packet flows with lower packet rate. Then, the most commonly
   accessed rules will be processed first and average packet processing
   time will decrease. Note that this mechanism is not extremely fair
   to streams with low bandwidth consumption since their processing
   time will increase.

8 Security Considerations

   The security requirements for the control protocol are described in
   Section 4.7. Note that security of the protocol does not help alone.
   Additionally, security of the entire control system is subject to
   security of the FCP controllers and access control in FCP-controlled
   devices (see Section 5.1.).

9 Document Status

   This document is in the stage of collection of requirements and open
   issues. Numerous updates result from discussions on the foglamps
   mailing list. Previous versions were issued as draft-kuthan-fcp-

J. Kuthan, J. Rosenberg                                      [Page 15]

Internet Draft    Middlebox Framework and Requirements    November 2000

10 Acknowledgments

   Numerous people have been contributing to collection of these
   requirements. Many document clarifications and enhancements resulted
   from discussions on the foglamps mailing list. We specially
   acknowledge the following people for their help: Scott Bradner,
   Stefan Foeckel, Melinda Shore, Dave Oran, and Jon Peterson. The
   firewall traversal problem was stated in [15], [16].


A Examples

   This section shows how to use FCP by examples. Many of the examples
   refer to the application described in Section 3 and use SIP as a
   prominent example of a session control protocol.

A.1 FCP Transaction Examples

   This section illustrates how FCP requests could look like. The
   requests in the following examples use abstract syntax in this form:

   <state manipulation operation>
   PME=<packet matching expression>
   [<control-state-element-id> [=<value>] ...]

   The syntax of packet matching expression is borrowed from tcpdump.
   An additional keyword 'if' specifies interface to whose incoming
   queue the matching expression is applied. A similar syntax is used
   for definition of packet modifiers. Discussion on how these abstract
   FCP examples map or do not map to existing protocols is out of scope
   of this document.

   In the examples bellow, a protected host behind a firewall has the
   address, an outside host has the address and
   the firewall's outbound interface has

   Example 1: Opening a Pinhole in a Packet Filter for an Outgoing Flow

   In this example, a controller opens a pinhole for a packet flow
   being sent from the inside to the outside host.

   PME='if in and udp src port 55 and src host and udp dst
   port 77 and dst host'

   => REPLY: OK

   Example 2: Opening a Pinhole in a Packet Filter w/NAPT for an
   Outgoing Flow

J. Kuthan, J. Rosenberg                                      [Page 16]

Internet Draft    Middlebox Framework and Requirements    November 2000

   In this example, a controller queries a NAT bind and opens a pinhole
   for a translated packet flow being sent from the outside to the
   inside host through a NAT.


   => REPLY: NAT_OK, udp:

   PME='dst host and udp dst port 55 and if out and src host and udp src 77'
   => REPLY: OK

   Example 3: TOS Control

   The controller instructs the controlled device to set TOS of matched
   packets to hexadecimal value 0x10.

   PME='if in and udp src port 55 and src host and udp dst
   port 77 and dst host'

   => REPLY: OK

   Example 4: Querying Number of Matched Packets

   PME='if in and udp src port 55 and src host and udp dst
   port 77 and dst host'

   => REPLY: OK, packet_count=333

   Example 5: Refreshing Per-Flow State

   PME='if in and udp src port 55 and src host and udp dst
   port 77 and dst host'

   => REPLY: OK

   Example 6: Network Ingress Filtering

   See [17] for more details on this scenario. The first rule denies
   all packets on the "in" interface. The second rule with higher
   priority explicitly permits packets from the 10.1.2 network.

J. Kuthan, J. Rosenberg                                      [Page 17]

Internet Draft    Middlebox Framework and Requirements    November 2000

   PME='if in'

   => REPLY: OK

   PME='if in and src net 10.1.2'

   => REPLY: OK

   Example 7: Reflexive HTTP Rules

   The next rule allows controlled packet filters to create temporary
   rules that permit inbound TCP packets for HTTP transactions
   initiated from the internal side of a firewall.

   PME='if in and tcp dst port 80'
   REFLEXIVE='permit=yes, timer=180s, if=out'

   => REPLY: OK

   If an HTTP request from to matches
   this rule a reflexive rule of the following form is generated:

   PME='if=out and tcp src port 80 and src host and tcp
   dst port 37313 and dst host'

   Example 8: Packet Redirection

   In this scenario, all HTTP traffic from inside network is redirected
   to a Web proxy ( transparently. This scenario is sometimes
   also referred as 'transparent proxy'. The rule allows for automatic
   creation of reflexive rules.

   PME='if in and tcp dst port 80'
   modifier='ip dst host ='
   reflexive_rules='permit=yes, inactivity_timer=240s, if=dmz'

   => REPLY: OK

   If an HTTP request from to matches
   this rule a reflexive rule of the following form is generated:

   PME='if=dmz and tcp src port 80 and src host and tcp dst
   port 37313 and dst host'

J. Kuthan, J. Rosenberg                                      [Page 18]

Internet Draft    Middlebox Framework and Requirements    November 2000

   modifier='ip src host=

A.2 Using FCP to Get an Outgoing SIP/SDP Session through a 'Default-
Deny' Firewall w/NAPT

   This example illustrates how FCP can be used to get an outgoing SIP
   call through a firewall deploying 'default-deny' packet filtering
   policy. Network configuration as displayed in Figure 1 is assumed:
   The packet filter allows SIP signaling only from/to a SIP proxy, the
   proxy rejects calls considered untrustworthy, and instructs the
   packet filter to open pinholes for RTP streams belonging to
   trustworthy SIP/SDP sessions for the time of session duration.
   Additionally, NAPT is deployed.

   Precise timing of opening and closing pinholes in SIP sessions and
   issues such as 183 provisional media and re-invites are subject to
   discussion which is out of scope of this document. Management of
   RTCP and ICMP pinholes is omitted for the sake of simplification.
   Note that the pinholes in the packet filter are quite 'wide'. This
   means they allow packets with arbitrary source address and port
   number to pass through because SDP does not communicate source
   endpoint addresses.

   Notation: In the diagram "INV" means an INVITE message
   with the SDP body indicating IP address with port 55 as the
   receiving address and port for an incoming media-stream. Similarly
   "200 OK" indicates an OK response with IP address and port 77 for receiving media. The value
   stands for any IP address and port number. Per-flow control states
   in this example are identified by packet matching expressions.

   |           INSIDE                            |      OUTSIDE       |
   UAC             SIP Proxy   AuthServer       NAT/FW              UAS
   |                   |         |               |                    |
   |                   |         |               |                    |

     /* process SIP invitation, bind to a public address for receiving
        media, modify the invitation accordingly; do not open firewall
        pinholes until both parties agree to establish a call; note
        that binding of source address for outgoing media is not done
        because SDP does not care about source addresses */

   | ----------------->|         |               |                    |
   | INV   |         |               |                    |
   |                   | ------> |               |                    |
   |                   | auth ?  |               |                    |
   |                   | <------ |               |                    |

J. Kuthan, J. Rosenberg                                      [Page 19]

Internet Draft    Middlebox Framework and Requirements    November 2000

   |                   | OK auth |               |                    |
   |                   |         |               |                    |
   |                   | ----------------------> |                    |
   |                   |FCP query_nat            |                    |
   |                   | udp :        |                    |
   |                   | <---------------------- |                    |
   |                   |OK udp: |                    |
   |                   | -------------------------------------------> |
   |                   |    INV                    |

     /* process SIP OK, open NAT-enabled pinholes for outgoing and
        incoming media as soon as SIP ACK arrives */

   |                   | <------------------------------------------- |
   |                   |         200 OK              |
   | <-----------------|                         |                    |
   | 200 OK                     |                    |
   | ----------------->|--------------------------------------------->|
   | ACK               | ----------------------> |                    |
   |                   |FCP SET                  |                    |
   |                   |PME='dst udp                 |
   |                   | src udp       |                    |
   |                   | if=in', action=PASS     |                    |
   |                   | <---------------------- |                    |
   |                   | FCP OK                  |                    |
   |                   | ----------------------> |                    |
   |                   |FCP SET                  |                    |
   |                   |PME='dst udp |                    |
   |                   | src udp       |                    |
   |                   | if=out', action=PASS    |                    |
   |                   | <---------------------- |                    |
   |                   | FCP OK                  |                    |
   |                   | -------------------------------------------> |
   |                   |         ACK             |                    |
   | ...............................................................> |
   |      UDP/RTP DST                                |
   | <...........................................~................... |
   |  UDP/RTP DST            UDP/RTP DST|

     /* close pinholes when either party sends SIP BYE */

   |                   | <------------------------------------------- |
   | <---------------- |        BYE              |                    |
   | BYE               |                         |                    |
   | ----------------->|                         |                    |
   | 200 OK            | ----------------------> |                    |
   |                   |FCP RELEASE              |                    |
   |                   |PME='dst udp                 |
   |                   | src udp       |                    |
   |                   | if=in'                  |                    |
   |                   | <---------------------- |                    |

J. Kuthan, J. Rosenberg                                      [Page 20]

Internet Draft    Middlebox Framework and Requirements    November 2000

   |                   | FCP OK                  |                    |
   |                   | ----------------------> |                    |
   |                   |FCP RELEASE              |                    |
   |                   |PME='dst udp |                    |
   |                   | src udp       |                    |
   |                   | if=out'                 |                    |
   |                   | <---------------------- |                    |
   |                   | FCP OK                  |                    |
   |                   | ----------------------> |                    |
   |                   |FCP release_bind         |                    |
   |                   | udp        |                    |
   |                   | <---------------------- |                    |
   |                   | OK                      |                    |
   |                   | -------------------------------------------> |
   |                   |         200 OK          |                    |

           Figure 4: Protocol Flow for "SIP Session over NAT"

B Bibliography

   1  S. Bradner: " The Internet Standards Process -- Revision 3", RFC
      1602, IETF, October 1996.
   2  B. Carpenter: "Achitectural Principle of the Internet", RFC 1958,
      IETF, June 1996.
   3  B. Carpenter: "Internet Transparency", RFC 2775, IETF, February
   4  P. Srisuresh: " Framework for interfacing with Network Address
      Translator", IETF, Internet Draft, July 2000. Work in progress.
   5  M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg: "SIP:
      Session Initiation Protocol", RFC 2543, IETF, March 1999.
   6  ITU-T Recommendation H.323. "Packet-based Multimedia
      Communications Systems," 1998.
   7  H. Schulzrinne, A. Rao, R. Lanphier: "Real Time Streaming
      Protocol", RFC 2326, IETF, April 1998.
   8  Postel, J. and J. Reynolds, "File Transfer Protocol (FTP)", RFC
      959, IETF. October 1985.
   9  Schulzrinne, Casner, Frederick, Jacobson: "RTP: A Transport
      Protocol for Real-Time Applications", Internet Draft, Internet
      Engineering Task Force, March 2000, Work in progress.
   10 P. Srisuresh and M. Holdrege: "IP network address translator
      (NAT) terminology and considerations", RFC 2663, IETF, August
   11 G. Tsirtsis, P. Srisuresh: "Network Address Translation -
      Protocol Translation (NAT-PT)", RFC 2766, IETF, February 2000.
   12 A. Feldmann, S. Muthukrishnann: "Tradeoffs for Packet
      Classification", In Proc. IEEE INFOCOM 2000, 2000.
   13 V. Srinivasan, S. Suri, G. Varghese: "Packet Classification Using
      Tuple Space Search", In Proc. ACM SIGCOMM '99, 1999.

J. Kuthan, J. Rosenberg                                      [Page 21]

Internet Draft    Middlebox Framework and Requirements    November 2000

   14 P. Gupta, N. McKeown: "Packet Classification on Multiple Fields",
      In Proc. ACM SIGCOMM '99, 1999.
   15 J. Rosenberg, D. Drew, H. Schulzrinne:  "Getting SIP through
      Firewalls and NATs", Internet Draft, Internet Engineering Task
      Force, Feb. 2000. Work in progress.
   16 M. Shore: "H.323 and Firewalls: Problem Statement and Solution
      Framework", Internet Engineering Task Force, Feb. 2000. Work in
   17 P. Ferguson, D. Senie: "Network Ingress Filtering: Defeating
      Denial of Service Attacks which Employ IP Source Address
      Spoofing", RFC 2827, IETF, May 2000.

C Glossary of Abbreviations

   ACL    Access Control List
   ALG    Application Level Gateway
   DMZ    Demilitarized Zone
   FCP    Flow Processing Control Protocol
   FTP    File Transfer Protocol
   IP     Internet Protocol
   HTTP   Hypertext Transfer Protocol
   MGCP   Media Gateway Control Protocol
   NAPT   Network Address Port Translation
   NAT    Network Address Translation
   NAT-PT Network Address Translation - Protocol Translation
   RTP    Transport Protocol for Real-time Applications
   RTSP   Real Time Streaming Protocol
   RTT    Round Trip Time
   SDP    Session Description Protocol
   SIP    Session Initiation Protocol
   TCP    Transmission Control Protocol
   TOS    Type of Service
   UDP    User Datagram Protocol

D Authors' Addresses

   Jiri Kuthan
   GMD Fokus
   Kaiserin-Augusta-Allee 31
   D-10589 Berlin, Germany
   E-mail: kuthan@fokus.gmd.de

   Jonathan Rosenberg
   200 Executive Drive
   Suite 120
   West Orange, NJ 07052
   email: jdrosen@dynamicsoft.com

J. Kuthan, J. Rosenberg                                      [Page 22]

Internet Draft    Middlebox Framework and Requirements    November 2000

E 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 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

J. Kuthan, J. Rosenberg                                      [Page 23]

Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/