Internet Draft M. Stiemerling Document: draft-stiemerling-midcom-simco-01.txt J. Quittek Expires: November 2002 NEC Europe Ltd. June 2002 Simple Middlebox Configuration (SIMCO) Protocol Version 1.0 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. 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-Drafts. 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 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 Distribution of this document is unlimited. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract This memo specifies the Simple Middlebox Configuration (SIMCO) protocol for configuring Network Address Translators (NATs) and firewalls dynamically to create address bindings and open pinholes. NATs and firewalls are a problem for applications using voice and video streaming, such as IP telephony, because they need to establish voice or video channels dynamically. The SIMCO protocol allows clients to send requests for this purpose to serving NATs and/or firewalls. The protocol is designed to provide a simple and basic solution that can easily be implemented and used, while still meeting almost all requirements defined by the MIDCOM working group (see [4]). Stiemerling & Quittek [Page 1] Internet-Draft Simple Middlebox Configuration June 2002 Table of Contents 1 Introduction ................................................. 2 2 Terminology .................................................. 3 2.1 General .................................................... 3 3 SIMCO Protocol Overview ...................................... 4 4 SIMCO Messages ............................................... 5 4.1 Common Definitions ......................................... 6 4.2 Message Definitions ........................................ 6 4.3 Replies .................................................... 7 5 Message Processing in Server ................................. 8 5.1 Syntax Checking ............................................ 9 5.2 Session State Machine ...................................... 9 5.2.1 Transistions from State CLOSED ........................... 10 5.2.2 Transistions from State NOAUTH ........................... 11 5.2.3 Transistions from State OPEN ............................. 12 5.3 Binding-Group State Machine ................................ 12 5.3.1 Transitions from State GID_UNUSED ........................ 13 5.3.2 Transitions from State GID_USED .......................... 14 5.4 Binding State Machine ...................................... 14 5.4.1 Binding Parameter Set Checking ........................... 16 5.4.2 Transitions from State BID_UNUSED ........................ 17 5.4.3 Transitions from BID_RES ................................. 18 5.4.4 Transitions from State FULL_BINDING ...................... 19 6 Controlling SIMCO Sessions ................................... 20 7 Controlling Binding-Groups ................................... 22 8 Continuing States after Session Termination .................. 22 8.1 CLOSE Request .............................................. 22 8.2 Asynchronous Session Termination ........................... 22 8.3 TCP connection teardown .................................... 23 9 Controlling Bindings ......................................... 23 10 Security Considerations ..................................... 25 11 References .................................................. 25 12 Authors' Address ............................................ 26 13 Full Copyright Statement .................................... 27 1. Introduction In today's network environments the use of firewalls and Network Address Translators (NATs) is widespread. Firewalls and NATs improve network security and in times of IPv4 address depletion NATs are keeping the Internet growing. However, NATs and firewalls also are an obstacle to many applications, because in order to traverse them, application specific and session specific configuration is required. A good example (and the main driver for developing SIMCO) is IP telephony. For a connection, two voice channels - one for each direction - need to be established. Typically, UDP is used to carry voice data, but for most NATs and firewalls it is a problem to Stiemerling & Quittek [Page 2] Internet-Draft Simple Middlebox Configuration June 2002 provide the required address mapping and to open corresponding pinholes for UDP traffic without manual configuration. Possible solutions are application level gateways linked to the NAT/firewall or signaling between the application and the NAT/firewall. Providing a signaling-based solution is the main goal of the midcom working group [2,3]. The SIMCO protocol described in this document provides a simple and straight forward approach to such a protocol while meeting all requirements specified in [4], except the deny actions for firewalls. It is fully in line with the MIDCOM protocol semantics specified in [13]. The SIMCO protocol is a client/server protocol with the NAT/firewall (middlebox) serving application-level clients (midcom agents) requesting address bindings and firewall configurations. It contains five different request types and very simple state machines that are completely specified below. A complete NAT/firewall configuration is out of scope of this protocol. This memo describes the architectural background for the SIMCO protocol. Section 2 defines the terminology used throughout this memo and section 3 explains the basic concept of the protocol. Section 4 defines all SIMCO messages, and section 5 specifies processing of the messages at a NAT/firewall including the complete specification of state machines. Section 6 explains how a client can open and close a SIMCO session, section 7 shows how it deals with a binding-group and section 8 explains how it can request address bindings and pinhole configurations. Both sections include example message sequences for these actions. Most of the security issues are discussed in section 9. They are very important, because many network security concepts strongly depend on proper firewall configuration. 2. Terminology This section defines the terminology that is used throughout this document. 2.1. General NAT Network Address Translation, according to [1]: Network Address Translation is a method by which IP addresses are mapped from one address realm to another, providing transparent routing to end hosts Firewall A general firewall contains two components: a packet filter examining information of Layer 2-4 and an Application Level Gateway (ALG). In this document we restrict the use of Stiemerling & Quittek [Page 3] Internet-Draft Simple Middlebox Configuration June 2002 the term `firewall' to packet filters, unless metioned explicitly NAT/firewall A NAT or a firewall or a combination of both Internal side The private network of a NAT (see [1], Section 2.8) and/or the protected network of a firewall External side The public network of a NAT (see [1], Section 2.7) and/or firewall. Internal IP Address An IP address which is located at the internal side of a NAT/firewall External IP Address An IP address which is located at the external side of a NAT/firewall. NAT Address binding For a NAT, the address binding is the phase in which an internal IP address is associated with an external IP address or vice versa, for purpose of translation (see [1], Section 3.2.1) Pinhole A configuration of the firewall allowing packets matching a pinhole to pass the firewall. Like bindings, a pinhole may be uni-directional, bi- directional or a wildcarded Address set A set consisting of three items: an IP address, a port number and the number of consecutive ports. Protocol type The IP protocol type as defined in [9,10,11] Address binding or binding An address binding consists of three address sets. The source address set, destination address set and the external address set. Address reservation or reservation The allocation of needed resources and mapped address/port number at a NAT for a later address translation. Binding parameter set A set consisting of a protocol type and an address set. Stiemerling & Quittek [Page 4] Internet-Draft Simple Middlebox Configuration June 2002 SIMCO server A node which accepts SIMCO requests from SIMCO clients and requests pinholes or NAT address bindings on behalf of the SIMCO clients. SIMCO client A node which requests pinholes or NAT address bindings at the SIMCO server. SIMCO session or session A session including a SIMCO client and a SIMCO server using the SIMCO protocol for communication TCP connection A TCP connection as defined in [12] Binding-group A binding-group consists of zero or more address binding or address reservations. 3. SIMCO Protocol Overview The SIMCO protocol is intended to comply with the midcom architecture specified in [2] and fulfill the requirements specified in [4] with the exception requirement 2.2.11, because no deny actions for firewalls are supported. The protocol allows a client (midcom agent) to establish a SIMCO session with a server. An important component of session establishment is the authentication and authorization of the client, as well as of the server, because configuring a NAT/firewall is a very sensitive issue of security concepts. For the transmission between client and server TCP is used, this avoids dealing with flow control issues and gives the opportunity of using Transport Layer Security (TLS [5]) mechanism. Instead of TLS, IPSEC [6,7] may be used as well. The protocol uses ASCII encodings, because this simplifies documentation, implementation and debugging. This encoding is not considered to reduce scalability significantly. Once a SIMCO session is established, the client can request the establishments of address bindings at a NAT controlled by the server and the opening of pinholes at a firewall controlled by the server. Should the request include the allocation of port numbers, the SIMCO server will take care about the oddity of the ports. Therefore the oddity of the new allocated ports will remain the same as in the request. The address bindings are organized in groups, so that a complete group can be modified or deleted with a single request. The approach of SIMCO is to use the same requests for requesting NAT translation (including IPv6 to IPv4 translation, and firewall Stiemerling & Quittek [Page 5] Internet-Draft Simple Middlebox Configuration June 2002 pinholes. For example a `bind' request (described in sections 4 and 5) sends two address sets to the server and requests the allocation of an external address set at the NAT/Firewall and a binding between both sets: - In case of a pure NAT, the external address set is allocated and a binding is established providing proper address translation. - In case of a pure firewall, the allocated external address set is identical with the internal one sent with the request, and just a pinhole is configured allowing packets matching the transport parameter set to pass. - In case of a combined NAT/firewall, the external address set is allocated, a binding is established providing proper address translation, and a pinhole is configured for allowing the packets matching the binding to pass. This integration of requests for address binding and for pinhole configuration leads to a very simple protocol with just two requests for binding and pinhole control and one for group control. 4. SIMCO Messages The message formats described below are defined using the Augmented BNF (ABNF) defined in RFC 2234 [8]. The definitions for `DIGIT', `HEXDIG', `WSP', `CRLF', `CR', `VCHAR' and `LF' are imported from appendix A of RFC 2234 and not repeated here. 4.1. Common Definitions The following definitions are used in the subsequent chapters to define the SIMCO protocol messages. IPAddress = IPv4Address / IPv6Address / "0" IPv4Address = 1*3DIGIT 3("." 1*3DIGIT) IPv6Address = 1*4HEXDIG 7( ":" 1*4HEXDIG) Port = 1*DIGIT NOSP = 1*DIGIT ; Number Of Subsequent Ports RID = 1*DIGIT ; Request ID number An IPAddress of "0" and a Port with a zero value are used for address or port wildcarding respectively. The RID is an identifier for the client, to recognize which reply belongs to which request, i.e. the RID in the reply is allways the same as in the request. GID = 1*DIGIT ; Group ID number BID = 1*DIGIT ; Binding ID number Stiemerling & Quittek [Page 6] Internet-Draft Simple Middlebox Configuration June 2002 The GID is used for grouping different bindings into one group, for the purpose of handling a group of bindings with a single request. A GID of zero in a group request means not allocated GID. The BID is the handle for the firewall/NAT to identify the correct binding and it may correlate with the corresponding pin-hole number in the firewall/NAT. A BID of zero means not allocated BID. PT = "UDP" / "TCP" / "ICMP" / "IP" ; IP protocol type Authentication = 1*4096VCHAR ; limited to 4096 Bytes Challenge = 1*4096VCHAR ; limited to 4096 Bytes Message = 1*VCHAR Timeout = 1*DIGIT ; timeout in seconds ADR = IPAddress WSP Port ; addresses SBPS = PT WSP NOSP WSP ADR ; single binding parameter set DBPS = PT WSP NOSP WSP ADR_src WSP ADR_dst ; double binding parameter set ADR_src = ADR ; source ADR ADR_dst = ADR ; destination ADR Version = "SIMCO/1.0" 4.2. Message Definitions The following ABNF definitions define the set of SIMCO requests which can be sent from a client to a server. request = "open" WSP RID WSP Version WSP Challenge WSP Authentication CRLF request =/ "close" WSP RID CRLF request =/ "group" WSP RID WSP GID WSP Timeout CRLF request =/ "resv" WSP RID WSP GID WSP BID WSP SBPS WSP Timeout CRLF ; SBPS contains address to be mapped request =/ "bind" WSP RID WSP GID WSP BID WSP DBPS WSP Timeout CRLF The requests are grouped into three catgeories: Session control, binding control and binding-group control. The `open' and the `close' request are exclusively used for session control. The `resv' and `bind' requests are exclusively used for address binding control. The 'group' request is used for group control. 4.3. Replies Every reply message starts with a three digit reply code and ends with `CRLF'. The three digits in a reply code have a special meaning. Stiemerling & Quittek [Page 7] Internet-Draft Simple Middlebox Configuration June 2002 The first digit identifies the class of a reply message. The following classes exist: 1yz transient positive response 2yz permanent positive response 3yz transient negative response 4yz permanent negative response 5yz asynchronous notification The classes 1yz and 3yz are currently not used by SIMCO version 1.0. They are defined only for future SIMCO extensions. The second digit encodes the specific category. The following categories exist: x1z syntax errors that don't fit any other category x2z replies for requests concerning session control x3z replies for requests concerning group control x4z replies for requests concerning address binding control The third digit gives a finer gradation of meaning in each category specified by the second digit. Below is the ABNF definition of all reply messages and codes: Reply = "410" WSP RID CRLF ; syntax Error Reply =/ "411" WSP RID CRLF ; unknown or illegal request Reply =/ "510" WSP Message CRLF ; illegal message Reply =/ "220" WSP RID CRLF ; OK Reply =/ "221" WSP RID WSP Challenge WSP Challenge CRLF ; Need further Authentication Reply =/ "222" WSP RID WSP CAP CRLF ; Authentication successful and Capabilities Reply =/ "420" WSP RID CRLF ; protocol version mismatch Reply =/ "421" WSP RID CRLF ; authentication failed Reply =/ "520" WSP Message CRLF ; session closed Reply =/ "231" WSP RID WSP GID WSP Timeout CRLF ; OK for binding-group Reply =/ "233" WSP RID WSP GID CRLF ; binding-group removed Reply =/ "430" WSP RID CRLF ; unknown or illegal GID Reply =/ "431" WSP RID CRLF ; binding-group refused Reply =/ "530" WSP GID CRLF ; binding-group timed out Reply =/ "241" WSP RID WSP GID WSP BID WSP SBPS WSP Timeout CRLF ; OK for reservation Reply =/ "242" WSP RID WSP GID WSP BID WSP DBPS WSP Timeout CRLF Stiemerling & Quittek [Page 8] Internet-Draft Simple Middlebox Configuration June 2002 ; OK for full binding Reply =/ "243" WSP RID WSP GID WSP BID CRLF ; binding removed Reply =/ "440" WSP RID CRLF ; unknown or illegal BID Reply =/ "441" WSP RID CRLF ; binding Refused Reply =/ "442" WSP RID CRLF ; illegal IP Address Reply =/ "443" WSP RID CRLF ; protocol type not supported Reply =/ "444" WSP RID CRLF ; illegal port number Reply =/ "445" WSP RID CRLF ; binding modific. rejected Reply =/ "446" WSP RID CRLF ; illegal NOSP Reply =/ "540" WSP BID CRLF ; binding timed out The SIMCO server advertises its capabilites in the `222' reply to the client. Therefore the following fields are defined: CAP = MAX_TO WSP BOX_TYPE WSP AWC WSP PWC MAX_TO = 1*DIGIT ; maximal timeout granted by the server BOX_TYPE = "NAT" / "FW" / "NATFW" / "NAPT" / "NAPTFW" BOX_TYPE =/ "NAT-PT" / "NAT-PTFW" ; types of the middle box AWC = "YES" / "NO" ; IP address wildcard supported PWC = "YES" / "NO" ; Port number wildcard supported 5. Message Processing in Server This section describes the processing steps performed by a SIMCO server after receiving a message. The incoming messages are processed in "first come, first served" manner, i.e. an incoming request has to be entirely processed before the next request can be processed. Common to all incoming messages is that first the syntax is checked. Then we distinguish messages concerning session control ,messages concerning the control of address bindings and messages concerning the control of groups. For all kinds, we define a state machine and discuss states and transitions. 5.1. Syntax Checking When the server receives a message, it first tries to recognize a request consisting of the command string and a request identifier (RID). Messages generated by syntax checking are: - `410' reply - `411' reply - `510' reply If the server is not able to extract both the command string and the request identifier, then the message is discarded. An asynchronous `510' reply may be generated in this case. In the case that the request identifier is not valid, an asychronous '510' reply may be generated. Otherwise, the command string is checked to be valid, Stiemerling & Quittek [Page 9] Internet-Draft Simple Middlebox Configuration June 2002 i.e. to be one of the strings `open', `close', `resv', `bind' or `group'. If the string is invalid, a `411' reply is sent and processing of the message stops. If a syntax error is detected, a `410' reply is sent and processing of the message stops. Otherwise, the message is further processed as described below. 5.2. Session State Machine The SIMCO session state machine has three states: CLOSED, NOAUTH and OPEN. Transisions between these states only appear in conjunction with one or two of the following messages: - `open' request - `close' request - `220' reply - `221' reply - `222' reply - `420' reply - `421' reply - `520' reply Additionally, a `510' reply may be generated in the CLOSED state as described below. Figure 1 shows the state machine of a single session with all possible transitions. Please note that a server may serve several clients at a time by running several concurrent sessions. Stiemerling & Quittek [Page 10] Internet-Draft Simple Middlebox Configuration June 2002 open 42X close 220 520 +-----------+ | v +-------------------+ | CLOSED |------+ +-------------------+ | open ^ ^ close 220 | 221 | | open 42x | | | 520 v | | +-------------------+ | +-----| NOAUTH | | +-------------------+ | | | close 220 | open | open 42X | 222 | 520 | +-------------------+ | | OPEN |<-----+ +-------------------+ | ^ +-----------+ open 222 Figure 1: Session state machine The initial state of all sessions is CLOSED. The SIMCO server listens on a specified port for incoming connections (The suggested listening port for testing is 30303). If a client establishes a TCP connection to the server by successfully creating a socket, then a session in state CLOSED is assigned to this TCP connection. For closed sessions only two requests are accepted: `open' and `close'. All other requests received in this state are discarded. An asynchronous `510' reply may be generated in this case. In the OPEN state, all SIMCO messages are accepted. However, only `open' and `close' messages have an impact on the session state. 5.2.1. Transistions from State CLOSED If an `open' request is received, then first the contained `Version' string is checked. If the version indicated by the string is not compatible to one of the versions supported by the server, then a `420' reply is generated, the TCP connection is closed, and the state machine remains in state CLOSED. Otherwise, the contained 'Challenge' string is checked as the server challenge string and the 'Authentication' string is ignored. If the challenge is string is valid, a `221' reply is generated and the session enters enters state Stiemerling & Quittek [Page 11] Internet-Draft Simple Middlebox Configuration June 2002 NOAUTH. The `221' reply contains: - The agent challenge, stored in `Challenge' - The server authentication, stored in `Authentication' Please note that the server challenge sent by the agent may be a "0" string, i.e. the client doesn't request a server authentication. Due to this the server authentication in the `221' reply will be a "0" string as well. The server may decide, depending on his local policies, not to request the authentication of the client, by sending a "0" agent challenge string. In the case that the check of the server challenge failes, a `421' reply is generated and the session remains in state CLOSE, with the TCP connection still established. The SIMCO client checks the middlebox authentication and challenge string of the `221' reply and closes the TCP connection immediately if any of the strings is not valid. At any time the server may generate an asynchronous `520' reply followed by closing the TCP connection. In this case the session will remain in state CLOSED. Particularly, the server may generate a `520' reply, if a TCP connection is established and the time the session remains in state CLOSED exceeds a given timeout value. 5.2.2. Transistions from State NOAUTH If a `close' request is received, then the server generates a `220' reply and the session enters state CLOSED with the TCP connection being closed. The same transition occurs if the server decides to close the session. Then it generates a `520' reply, closes the TCP connection, and enters session state CLOSED. If an `open' request is received, it is processed as in the CLOSED state. First the contained `Version' string is checked. If the version indicated by the string is not compatible to one of the versions supported by the server, then a `420' reply is generated, the TCP connection is closed, and the state machine enters state CLOSED. Otherwise the `Authentication' string is checked wether it is valid or not. The `Challenge' string is ignored. Should this test fail, the server generates a `421' reply, closes the TCP connection and the session enters the state CLOSED. Is the agent authentication valid, the server generates a `222' reply and the session enters state OPEN. The `222' reply contains: Stiemerling & Quittek [Page 12] Internet-Draft Simple Middlebox Configuration June 2002 - the MAX_TO set to the maximum granted binding timeout, - the BOX_TYPE set to the kind of middle box - the WC value set to `YES' if wildcarding is supported and `NO` if wildcarding is not supported. At any time the server may generate an asynchronous `520' reply followed by closing the TCP connection. In this case the session will enter state CLOSED. 5.2.3. Transistions from State OPEN If a `close' request is received, then the server generates a `220' reply and the session enters state CLOSED with the TCP connection being closed. The same transition occurs if the server decides to close the session. Then it generates a `520' reply, closes the TCP connection, and enters session state CLOSED. If an `open' request is received, it is processed as in the CLOSED state. First the contained `Version' string is checked. If the version indicated by the string is not compatible to one of the versions supported by the server, then a `420' reply is generated, the TCP connection is closed, and the state machine enters state CLOSED. Otherwise, the contained `Authentication' string is analysed if the string is equal to the already sent authentication, the server generates a `222' reply. The parameters of the `222' reply have to be same as in all `222' replies before. Otherwise, a `421' reply is generated and the session enters state CLOSED with the TCP connection kept established. At any time the server may generate an asynchronous `520' reply followed by closing the TCP connection. In this case the session will enter state CLOSED. 5.3. Binding-Group State Machine A binding-group consists of zero or more bindings, whereas address bindings have to belong to a binding-group. Address bindings can be added to a binding-group or can be removed from a binding-group. When the session state machine is in state OPEN, the server accepts further requests regarding binding-groups. The state machine of a binding-group contains two states: GID_UNUSED and GID_USED. Transistions between the states occur in conjunction with the following messages: - `group' request Stiemerling & Quittek [Page 13] Internet-Draft Simple Middlebox Configuration June 2002 - 23X replies - 43X replies - 530 reply All of these requests and replies refer to exactly one binding-group which is indicated by the GID field of the message. The GID uniquely identifies a binding-group. GIDs are allocated and assigned to binding-groups by the server. If a request contains a GID which is unused, because it is not assigned to any binding-group, then the server will discard the request and generates a `430' reply. GID 0 is an exception, it is reserved for a special purpose and it is never assigend to an existing binding-group. For GIDs other than 0 a state machine exists as shown in Figure 2. If the server receives a `group' request containing GID 0 then a new GID is allocated. Before the request can be executed, a new binding-group state machine is instantiated for this GID with the inital state GID_UNUSED. group(GID=0) 43X group(GID=0,timeout=0) 233 +----------+ | v +------------+ + --| GID_UNUSED |<-+ | +------------+ | group(GID=0) | ^ | group(timeout=0) 231 | 530 | | 233 | | | | +------------+ | +-->| GID_USED |--+ +------------+ | ^ +----------+ group 231 Figure 2: Binding-Group state machine When a binding-group state machine makes a transistion to the state GID_UNUSED (including transistions from state GID_UNUSED), then the GID is considered to be unused. The client should not use this GID any further, because it may be used re-used by the server when allocating a new GID. 5.3.1. Transitions from State GID_UNUSED In state GID_UNUSED only `group' requests with GID 0 can have an effect on the state machine. Stiemerling & Quittek [Page 14] Internet-Draft Simple Middlebox Configuration June 2002 If the timeout specified by the request is 0, then the server generates a `233' reply and the binding-group state machine remains in state GID_UNUSED. If the timeout specified by the request is not 0, then the server allocates a new binding-group with a new GID and the binding-group state machine enters the state GID_USED. The server generates a `231' reply on successfully allocating a new binding-group. The timeout choosen by the server is less than or equal to the value specified by the client in the `group' request. Should the allocation of the binding-group fail, a '431' response is generated and the state remains in the state GID_UNUSED. The binding-group can now be filled with address bindings or remain empty. 5.3.2. Transitions from State GID_USED In the state GID_USED the binding-group timeout can be modified or the binding-group can be removed. If a `group` request is received with a timeout value of non-zero, the timeout of the binding-group is modified and a '231' message is generated. The timeout choosen by the server is less than or equal to the value specified by the client in the `group' request. The timeout of all address bindings in this binding-group is set to the choosen timeout value. If a 'group' request is received with a timeout value of zero, the server removes immediately all address bindings in this binding-group and removes the binding-group as well. A '233' reply is generated. After exceeding the timeout of the binding-group the server removes immediately all address bindings in this binding-group and removes the binding-group as well. The server may generate an asynchronous `530' reply. The `530' reply may be generated in the case of any failure condition or resource conflict in the server. In this case the server sends the `503' reply before it removes all address bindings belonging to this binding-group without any further modifications to the agent and the binding-group itself. 5.4. Binding State Machine All requested bindings have to belong to an already allocated binding-group (see section 5.3). It is not necessary to allocate a new group for each new binding, instead of this one group can be used as a default group. To continue the processing of bindings, an Stiemerling & Quittek [Page 15] Internet-Draft Simple Middlebox Configuration June 2002 already allocated group identifier (GID) must be provided with the `resv' or `bind' request, otherwise a `430' reply is generated and the message is discarded. When the session state machine is in state OPEN, the server accepts further requests regarding bindings. The state machine of a binding contains four states: BID_UNUSED, BID_RES and FULL_BINDING. Transistion between the states occur in conjunction with the following messages: - `resv' request - `bind' request - `24X' replies - `44X' replies - `540' reply All of these requests and replies refer to exactly one binding which is indicated by the BID field of the message. The BID uniquely identifies a binding. BIDs are allocated and assigned to bindings by the server. If a request contains a BID which is unused, because it is not assigned to any binding, then the server will discard the request and generate a `440' reply. BID 0 is an exception, it is reserved for a special purpose and it is never assigned to an existing binding. For all BIDs other than 0 a state machine exists as shown in Figure 3. If the server receives a `resv` or a `bind' request containing BID 0 then a new BID is allocated. Before the request can be executed, a new binding state machine is instantiated for this BID with the initial state BID_UNUSED. Stiemerling & Quittek [Page 16] Internet-Draft Simple Middlebox Configuration June 2002 bind(BID=0) 44x bind(BID=0,to=0) 243 resv(BID=0) 44x resv(BID=0,to=0) 241 +-----------+ | v resv(BID=0) 241 +-------------+ +-------------------| BID_UNUSED |<--+ | +-------------+ | +---+ | ^ | | | | | 540 | | bind 242 | bind(to=0)243 | v v resv 44x | | | bind 44x | +-------------+ bind 44x | | | 540 | | BID_RES |--------------+ | | | +-------------+resv(to=0)243 | | | | | bind(to=0)243 | | +---+ | | | resv 241 | bind 242 v | | +-------------+ | +---------------->|FULL_BINDING |-----+ +-------------+ | ^ +---------+ bind 242 resv 411 Figure 3: Binding state machine (to stands for timeout) When a binding state machines makes a transition to the state BID_UNUSED (including transitions from state BID_UNUSED), then the BID is considered to be unused. The client should not use this BID any further, because it may be re-used by the server when allocating a new BID. Please note that every `resv` and `bind' request keeps the port oddity of TCP and UDP as given in the request message. 5.4.1. Binding Parameter Set Checking When a `resv` or a `bind' request is processed, the binding parameter set contained in the message is checked. The checking procedure is common for all states: - The IP address is checked whether it is considered invalid for some reason or blocked by local policy. The server generates a `442' reply when this IP address will be rejected. Stiemerling & Quittek [Page 17] Internet-Draft Simple Middlebox Configuration June 2002 - The protocol type is checked, whether it is valid and supported. If the check fails, a `443' reply is generated. - The port number is checked whether it is valid. If the check fails, a `444' reply is generated. - The NOSP parameter is checked whether it is valid. If the check fails, a `446' reply is generated. If the checks are successful the server may perform further checks on the combination of the elements of the binding parameter set, for example it may check available resource or it may consult a policy- based access control system checking whether the client is allowed to make the current request. If one of these checks fails, then the server generates a `441' reply. Otherwise the server will continue with establishing the requested binding. 5.4.2. Transitions from State BID_UNUSED In state BID_UNUSED, only `resv` or `bind` requests with BID 0 can have an effect on the state machine. The server first performs the parameter checks described above. If one of them fails, the binding state machine remains in state BID_UNUSED. If the timeout specified by the request message is 0, then the server generates a `243' reply and the binding state machine remains in state BID_UNUSED. If a `resv' request passes all checks described above, then the server reserves the needed address binding resources in the firewall/NAT. In the NAT case, the internal address set is mapped into the external address set. The `resv' request can only be used for mapping internal to external address sets. The state machine for this BID enters the state BID_RESV and the server generates a `241' reply reporting: - the BID allocated for this binding, - the binding parameter set of the external address set, - the timeout in seconds after which the binding will automatically be removed by the server. The timeout chosen by the server is less than or equal to the value specified by the client in the `resv' request message, but not greater than the binding-group timeout of the corresponding binding-group If a `bind' request passes all checks described above, then the server allocates the requested address bindings in the firewall/NAT with the ADS_src as source address set and ADS_dst as destination Stiemerling & Quittek [Page 18] Internet-Draft Simple Middlebox Configuration June 2002 address set. In the NAT case the mapping between internal address set and external address set is allocated and activated. Then the state machine for this BID enters the state FULL_BINDING and the server generates a `242' reply reporting - the BID allocated for this binding, - the first binding parameter set with the internal address set (only if supported by NAT) and the second binding parameter set with the external address set, - the timeout in seconds after which the binding will automatically be removed by the server. The timeout chosen by the server is less than or equal to the value specified by the client in the `bind' request message, but not greater than the binding-group timeout of the corresponding binding-group 5.4.3. Transitions from BID_RES In state BID_RES only a resource reservation in the firewall/NAT has been made. This reservation is usefull in conjunction with NATs, because sometimes the translated address set has to be known, before the actual source and destination address binding are fully known. The `resv' requests returns the external address set. In this state the client can request to extend the lifetime of the reservation or the extension to a complete address binding. The request must contain the BID of the already existing partial binding. If the request fails the transport parameter set checking, then the server generates the according `44X' reply and also it removes the already established reservation. The binding state machine then enters state BID_UNUSED. If the timeout specified by the request message is 0, then the server generates a `243' reply and removes the already established reservation. The binding state machine then enters the state BID_UNUSED. Otherwise, if the request passes the checks of the binding parameter set, the server creates a binding to the already known BID and chooses a timeout less than or equal to the value specified by the request, but not greater than the binding-group timeout of the corresponding binding-group. The server generates a `242' reply reporting the chosen timeout and the internal and the external address set allocated at the NAT/firewall. The internal address set will be set to a wildcard address set if the NAT doesn't allocated internal address sets or if the device is a pure firewall. The BID state machine enters state FULL_BINDING. Other options for the client are requests for Stiemerling & Quittek [Page 19] Internet-Draft Simple Middlebox Configuration June 2002 - updating the timeout, - removing the binding. For timeout update and for binding removal the client must use exactly the binding parameter set already contained in the previous requests for this BID. Should the binding parameter set differ from the previous request, the server generates a `445' and the already established reservation is removed. If the timeout specified in the request message is 0, the server will remove the binding and generate a `243' reply, and the binding state machine enters state BID_UNUSED. If the timeout specified in the `resv' request is larger than 0, the server must process an update of the reservation's timeout without any interruption of the NAT/firewall operation for this reservation. The server chooses a timeout less than or equal to the value, but not greater than the binding-group timeout of the corresponding group, in the request message and reports it by generating `241' reply. The binding state machine remains in its state. At any time, the server may remove the binding. It must do so at latest if the timeout expires. But also at any earlier time it may do so, for example if the policy for granting binding requests has changed, if a mis-use of the binding was detected, or if the server cannot continue the operation of the binding for technical reasons. In such a case the server generates an asynchronous `540' message indicating the removal of the binding and the binding state machine enters state BID_UNUSED. 5.4.4. Transitions from State FULL_BINDING In state FULL_BINDING the client can request to - update the timeout, - remove the binding. For timeout update and for binding removal the client can use the `bind' request. A `resv' request results in `411' reply, the binding state machine remains in FULL_BINDING and the binding itself is kept unchanged. The request must use exactly the binding parameter set already contained in the previous `bind' request. The server must ensure that such unchanged transport parameters pass the transport parameter check. If the timeout specified in the request message is 0, the server will remove the binding and generate a `243' reply, and the binding state Stiemerling & Quittek [Page 20] Internet-Draft Simple Middlebox Configuration June 2002 machine enters state BID_UNUSED. If the timeout specified in the message is larger than 0, the server must process an update of the binding's timeout without any interruption of the NAT/firewall operation for this binding. The server chooses a timeout less than or equal to the value in the request message, but no greater than the binding-group timeout of the corresponding group, and reports it by generating `241' reply. The binding state machine remains in its state. If the binding parameter set specified in the request message differs from ones used in the previous message, the server generates a `445' and the already established partial binding is removed. At any time, the server may remove the binding. It must do so at latest if the timeout expires. But also at any earlier time it may do so, for example if the policy for granting binding requests has changed, if a mis-use of the binding was detected, or if the server cannot continue the operation of the binding for technical reasons. In such a case the server generates an asynchronous `540' message indicating the removal of the binding and the binding state machine enters state BID_UNUSED. 6. Controlling SIMCO Sessions After a secure TCP connection has been established between client and server (for example by using TLS [5] or IPSEC [6,7]), the SIMCO session requires an initial authentication of the client and the server. This might be technically superfluous, for example if the client already authenticated itself when establishing the connection, but it is an inevitable step of establishing a SIMCO session. The client sends an `open' request contains a server challenge string. The server respectively authenticates itself by sending the corresponding authentication string in the `221` reply and requests the client authentication via an client challenge. The client responses with another `open' request, containing the agent authentication. The client may choose to send an "0" challenge to the server, i.e. the client doesn't need the authentication of the server. Vice versa the server may send a "0" challenge to the client, i.e. the server doesn't need the authentication of the client. The client closes immediately the SIMCO session and TCP connection when he receives an invalid authentication string from the server. The server generates a `421' reply if the authentication fails and close immediately the TCP connection. The procedure is illustrated by the following Example (a). For message flow examples in this memo we use the following Stiemerling & Quittek [Page 21] Internet-Draft Simple Middlebox Configuration June 2002 indication of the direction of a message: C->S: from the client to the server C<-S: from the server to the client --: comment line . . .: some unspecified messages Example (a): successful authentication -- TCP connection establishment and TLS or IPSEC establishment -- client sends dummy authentication string: 0 C->S: open 1300 SIMCO/1.0 F1EFE 0 -- server returns challenge string and his authentication C<-S: 221 1300 13e66f34b7416ab9389ccc5b441290aa df3ee4523ac3c32 -- client sends correct authentication C->S: open 1301 SIMCO/1.0 0 ab54346de6933ff4556a1b23efd70082 -- server sends the reply with his capabilities C<-S: 222 1301 1800 FW YES -- session now in state OPEN . . . -- SIMCO message exchange . . . -- client closes session C->S: close 40163 C<-S: 220 Ok -- session now in state CLOSED -- connection terminated If the client fails to authenticate itself after an invalid `open' request, the server disconnects itself from the client. The server in Example (b) disconnects after the `open' request. Example (b): failed authentication -- TCP connection establishment and TLS or IPSEC establishment -- client sends invalid authentication string C->S: open 55000 SIMCO/1.0 F1EFE 0 -- server returns challenge string C<-S: 421 55000 13e66f34b7416ab9389ccc5b441290aa df3ee4523ac3c32 -- client sends invalid authentication string C->S: open 55333 SIMCO/1.0 0 beef C->S: 421 55333 -- server in state CLOSED, client disconnected The client closes a session by sending a `close' request. All established bindings configured by this client will remain established until their timeout expires. Also the server may terminate an open session by sending an asynchronous `520' reply. Stiemerling & Quittek [Page 22] Internet-Draft Simple Middlebox Configuration June 2002 7. Controlling Binding-Groups The client can request to establish, extend, and remove binding- groups. The request `group' is the only request that is needed to perform all of the above mentioned actions. With the requests `resv' and `bind' bindings can be added to a binding-group or removed from a binding-group. Each binding-group has a timeout value, which determines when a binding-group is automatically removed by the SIMCO server. But before removing the binding-group, all bindings in the binding-group are removed at first. The timeout value of the binding-group is the upper limit of the single binding timeouts, i.e. a single binding can never have a timeout value greater than the binding-group timeout. Control of binding-group is illustrated by the next Example: -- server is in state OPEN -- request a new binding-group with a timeout of 2000 seconds C->S: group 32345 0 2000 -- server allocates a new group identifier (GID) of 1 and grants a -- binding-group timeout of 1800 seconds C<-S: 231 32345 1 1800 . . . -- The client removes the binding-group after 1000 seconds C->S: group 32345 1 0 -- binding-group removed C<-S: 231 32345 1 8. Continuing States after Session Termination This section describes the behaviour of the bindings and binding groups of a particular session, when the session is terminated. 8.1. CLOSE Request On receiving a `close' request the server terminates the SIMCO session immediately. The binding and binding-groups of this session may continue to exist after the termination of the session, until their timeout expires. However, the server is free to remove them at any time. 8.2. Asynchronous Session Termination As defined in section 5.2.3, the server may decide to terminate the SIMCO session at an point of time. The server generates a `520' reply and removes afterwards all bindings and binding-groups of this session. Stiemerling & Quittek [Page 23] Internet-Draft Simple Middlebox Configuration June 2002 8.3. TCP connection teardown In the case that the TCP connetions is closed without a prior `close' request or the TCP connetions is broken, the server keeps all bindings and binding-groups of the corresponding session until their timeout expires. However, the server is free to remove them at any time. 9. Controlling Bindings The client can request to reserve, establish, extend and remove bindings. All of these requests, are variants of a `resv', or a `bind' request. A successful `bind' request allows a UDP data stream matching the corresponding parameter set to pass the NAT/firewall from the source address set to the destination address set, i.e. only a unidirectional flow is permitted. For the UDP flow in the other direction a second `bind' requests with source and destination address set swapped has to be generated. For TCP only one `bind' request is needed to establish a bidirectional flow. Each binding has a timeout value, which determines when a binding is automatically removed by the SIMCO server. The client makes a timeout proposal in his `resv' or `bind' request and the server may accept this proposal or choose a smaller timeout value. The upper limitvfor the binding timeout is the timeout of the corresponding binding- group. For example the server may be configured to accept all timeout values up to a predefined maximum value. The server informs the client about the chosen timeout in by the next reply. Control of bindings nad pinholes is illustrated by Example (c) showing the establishment and removal of a uni-directional UDP binding and pinhole. Example (c): NAT control of UDP address binding -- server is in state OPEN. -- request with GID=1, BID=0 for binding inner IP address 10.11.1.45 -- and UDP port 16175 for 180 seconds C->S: resv 2044 1 0 UDP 1 10.11.1.45 16175 180 -- server allocates external IP address 195.37.70.5 and UDP port -- 13222 and binds it to the internal binding parameter set -- for 180 seconds. BID=1248. C<-S: 241 2044 1 1248 UDP 1 195.37.70.5 13222 180 -- binding reserved -- Enable the binding C->S: bind 2050 1 1248 UDP 1 10.11.1.45 16175 139.6.138.20 4325 180 -- server enables binding Stiemerling & Quittek [Page 24] Internet-Draft Simple Middlebox Configuration June 2002 C<-S: 242 2050 1 1248 UDP 1 0.0.0.0 0 195.37.70.5 13222 180 -- no more messages concerning this BID for 160 seconds . . . -- binding and pinhole not needed anymore -- request to remove by setting timeout to 0 C->S: bind 2067 1 1248 UDP 1 10.11.1.45 16175 139.6.138.20 4325 0 -- binding and pinhole removed C<-S: 243 2067 1 1248 Example (d) shows the message flow of a similar request, but in this case the server is a pure firewall without any NAT function. Therefore the allocated binding parameter set is equal to the one in the request. Example (d): Firewall control of UDP address binding -- server is in state OPEN. -- request with GID=1,BID=0 for binding inner IP address 195.37.70.163 -- and UDP port 16175 for 180 seconds C->S: bind 2144 1 0 UDP 1 195.37.70.163 16175 139.6.138.20 3838 180 -- server does not allocate its own address, but it opens -- a pinhole for the requested binding parameter set. C<-S: 242 2144 1249 UDP 1 0.0.0.0 0 195.37.70.163 16175 180 -- pinhole open -- no more messages concerning this BID for 160 seconds . . . -- pinhole not needed anymore -- request to remove by setting timeout to 0 C->S: bind 2164 1 0 UDP 1 195.37.70.163 16175 139.6.138.20 3838 0 -- pinhole removed C<-S: 243 2164 1 1249 The message flow for setting up a binding with multiple ports at a NAT is illustrated by Example (e). Example (e): NAT control of UDP partial binding with multiple ports -- server is in state OPEN. -- request with GID=1,BID=0 for binding inner IP address 10.11.1.50 -- and UDP ports 4000/4001 for 540 seconds C->S: resv 2432 1 0 UDP 2 10.11.1.50 4000 540 -- server allocates external IP address 195.37.70.5 and UDP ports -- 30100/30101 and binds it to the internal binding parameter set -- for 300 seconds. BID=1251. S->C: 241 2432 1 1251 UDP 2 195.37.70.5 30100 300 The last Example (f) shows the rejection of a request, because an illegal internal IP address is used. Stiemerling & Quittek [Page 25] Internet-Draft Simple Middlebox Configuration June 2002 Example (f): Rejection of illegal internal IP address -- server is in state OPEN C->S: bind 458 1 0 TCP 1 102.12.12.251 1254 100.100.10.2 80 300 C<-S: 442 458 -- no new binding or pinhole established 10. Security Considerations By their nature firewalls and NATs are a very sensitive points concerning network security. In general it appears to be contradictive to open a port at a firewall for configuring pinholes, because this might make the firewall vulnerable. Therefore, effective means are required for inhibiting mis-use of the SIMCO service. A SIMCO server should use a restricted list of clients that are allowed to use the service. Beyond checking the clients IP address and requiring authentication when building up a secure TCP connection with TLS or IPSEC, the server should expect the client to authenticate itself by using a shared secret or based on a public key infrastructure. The TCP connection also needs to be protected for ensuring integrity of the requests made by the client. Finally, confidentiality of the data exchang between client and server is required to hide information about the participants of communication services that are enabled by SIMCO. 11. References [1] Srisuresh,P., and Holdrege, M., "IP Network Translator (NAT) Terminology and Considerations", RFC 2663, August 1999 [2] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A., Rayhan, A., "Middlebox Communication Architecture and framework", Internet Draft, work in progress, , December 2001 [3] Huitema, C., "MIDCOM Scenarios", expired Internet Draft, work in progress, , May 2001 [4] Swale, R.P., Mart, P.A., Sijben, P., Brimm, S., Shore, M., "Middlebox Control (MIDCOM) Protocol Architecture and Requirements", Internet Draft, work in progress, , November 2001 [5] Dierks, T., Allen, C., "The TLS Protocol Version 1.0", RFC 2246, January 1999 Stiemerling & Quittek [Page 26] Internet-Draft Simple Middlebox Configuration June 2002 [6] Kent, S., and Atkinson, R., "IP Authentication Header", RFC 2402, November 1998 [7] Kent, S., and Atkinson, R., "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998 [8] Crocker, D., and Overell, P., "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997 [9] DARPA, "Internet Protocol"RFC 791, September 1981 [10] Deering S., Hinden R., "Internet Protocol, Version 6 (IPv6), Specifiation", RFC 2460, December 1998 [11] Reynolds J., "Assigned Numbers", RFC 3232, January 2002 [12] DARPA, "Transmission Control Protocol", RFC 793, September 1981 [13] Stiemerling, M., Quittek, J., "MIDCOM Protocol Semantics", Internet Draft, work in progress, , June 2002 12. Authors' Address Martin Stiemerling NEC Europe Ltd. Network Laboratories Adenauerplatz 6 69115 Heidelberg Germany Phone: +49 6221 90511-13 Email: stiemerling@ccrle.nec.de Juergen Quittek NEC Europe Ltd. Network Laboratories Adenauerplatz 6 69115 Heidelberg Germany Phone: +49 6221 90511-15 EMail: quittek@ccrle.nec.de Stiemerling & Quittek [Page 27] Internet-Draft Simple Middlebox Configuration June 2002 13. Full Copyright Statement Copyright (C) The Internet Society (2001). 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. Stiemerling & Quittek [Page 28] Internet-Draft Simple Middlebox Configuration June 2002