Internet Draft M. Stiemerling Document: draft-stiemerling-midcom-simco-00.txt J. Quittek Expires: July 2002 NEC Europe Ltd. February 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. Stiemerling & Quittek [Page 1] Internet-Draft Simple Middlebox Configuration January 2002 Table of Contents 1 Introduction ................................................. 2 2 Terminology .................................................. 2 2.1 General .................................................... 3 2.2 Address Bindings ........................................... 4 2.2.1 NAT ...................................................... 5 2.2.2 Firewall ................................................. 6 3 SIMCO Protocol Overview ...................................... 6 4 SIMCO Messages ............................................... 7 4.1 Common Definitions ......................................... 8 4.2 Message Definitions ........................................ 8 4.3 Replies .................................................... 9 5 Message Processing in Server ................................. 11 5.1 Syntax Checking ............................................ 11 5.2 Session State Machine ...................................... 11 5.2.1 Transistions from State CLOSED ........................... 12 5.2.2 Transistions from State OPEN ............................. 13 5.3 Binding-Group State Machine ................................ 14 5.3.1 Transitions from State GID_UNUSED ........................ 15 5.3.2 Transitions from State GID_USED .......................... 16 5.4 Binding State Machine ...................................... 16 5.4.1 Binding Parameter Set Checking ........................... 17 5.4.2 Transitions from State BID_UNUSED ........................ 18 5.4.3 Transitions from BIND_INT_ONLY and BIND_EXT_ONLY ......... 19 5.4.4 Transitions from State FULL_BINDING ...................... 21 6 Controlling SIMCO Sessions ................................... 21 7 Controlling Binding-Groups ................................... 23 8 Controlling Bindings ......................................... 23 9 Security Considerations ...................................... 26 10 References .................................................. 27 11 Authors' Address ............................................ 27 12 Full Copyright Statement .................................... 28 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 provide the required address mapping and to open corresponding pinholes for UDP traffic without manual configuration. Possible Stiemerling & Quittek [Page 2] Internet-Draft Simple Middlebox Configuration January 2002 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]. 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 six different request types and 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 the term `firewall' to packet filters, unless metioned explicitly Stiemerling & Quittek [Page 3] Internet-Draft Simple Middlebox Configuration January 2002 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 a sequence of consecutive ports. Protocol type The IP protocol type as defined in [9,10,11] Address binding or binding An address binding consists of four address sets. For the exact definition of an address binding see section 2.2 Full binding A set of four address sets, see section 2.2 Partial binding A set of two address sets, see section 2.2 Internal partial binding A binding of an internal located address set to an external valid address set Stiemerling & Quittek [Page 4] Internet-Draft Simple Middlebox Configuration January 2002 External partial binding A binding of an external located address set to an internal valid address set Binding parameter set A set consisting of a protocol type and an address set. 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 bindings 2.2. Address Bindings SIMCO is dealing with two different types of middle boxes: NATs and firewalls. To clarify the meaning of address bindings in the SIMCO protocol we discuss the address bindings in the cases of NAT and firewall. Figure 1 shows a working scenario for the SIMCO protocol, whereas two hosts, host A and host B, communicate with each other via the NAT/firewall. The SIMCO signalling is omitted for the sake of simplicity. Host A uses the internal address set ADS0 and Host B uses the external address set ADS3. 2.2.1. NAT After an appropriate configuration of the NAT, the NAT maintains an internal address set ADS1 and an external address set ADS2. Please note that depending on the NAT type, ADS1 may not be required. The NAT translates address sets located in the internal network to valid address sets in the external networks and vice versa. Due to this the relationship between the address sets is ADS0 != ADS2 and ADS3 != ADS1. Stiemerling & Quittek [Page 5] Internet-Draft Simple Middlebox Configuration January 2002 +--------+ ************ | Host A |----* Internal * | (ADS0) | * Network * +---%----+ ************ % | % | % +--------+ % | (ADS1)%%%%%%%%%%%%%%%% % | | % % | NAT | % % |Firewall| % %%%%%%%%%%%%%%%%%%(ADS2) | % +--------+ % | % | % ************ +---%----+ * External *----| (ADS3) | * Network * | Host B | ************ +--------+ Figure 1: SIMCO bindings Figure 1 shows two partial bindings. The bound address sets are connected by %-lines. (ADS0/ADS2) is one partial binding and (ADS3/ADS1) is another partial binding. These two partial bindings together, constitute a full binding [(ADS0/ADS2)/(ADS1/ADS3)]. The partial binding (ADS0/ADS2) is called an internal partial binding, because the corresponding host is located inside the internal network. The partial binding (ADS3/ADS1) is called an external partial binding, because the corresponding host is located inside the external network. Note: The definition of the NAT address binding can be found in [1], Section 3.2.1. 2.2.2. Firewall After an appropriate configuration of the firewall in figure 1, the firewall maintains an pinhole for the address sets ADS0 and ADS3. The other address sets are ADS2=ADS0 and ADS3=ADS1. The meaning of the partial and full binding remain the same as in the section 2.2.1. 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]. The protocol allows a client (midcom agent) to establish a SIMCO session with a server. An important component of session establishment is Stiemerling & Quittek [Page 6] Internet-Draft Simple Middlebox Configuration January 2002 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 message. The approach of SIMCO is to use the same requests for requesting NAT translation, as well as IPv6 to IPv4 translation, and firewall pinholes. For example a `bind_in' request (described in sections 4 and 5) sends an internal address set 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 three 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 Stiemerling & Quittek [Page 7] Internet-Draft Simple Middlebox Configuration January 2002 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 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 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 pinhole 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*VCHAR Challenge = 1*VCHAR 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_int WSP ADR_ext ; double binding parameter set ADR_int = ADR ; internal ADR ADR_ext = ADR ; external 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 Stiemerling & Quittek [Page 8] Internet-Draft Simple Middlebox Configuration January 2002 request =/ "close" WSP RID CRLF request =/ "bind_int" WSP RID WSP GID WSP BID WSP SBPS WSP Timeout CRLF request =/ "bind_ext" WSP RID WSP GID WSP BID WSP SBPS WSP Timeout CRLF request =/ "bind_full" WSP RID WSP GID WSP BID WSP DBPS WSP Timeout CRLF request =/ "group" WSP RID WSP GID 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 `bind_in', `bind_ext' and `bind_full' 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. 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 Stiemerling & Quittek [Page 9] Internet-Draft Simple Middlebox Configuration January 2002 Reply =/ "221" WSP RID WSP Authentication WSP CAP CRLF ; OK with capabilities Reply =/ "420" WSP RID CRLF ; protocol version mismatch Reply =/ "421" WSP RID WSP Challenge 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 partial binding Reply =/ "242" WSP RID WSP GID WSP BID WSP DBPS WSP Timeout CRLF ; 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 his capabilites in the `221' reply to the client. Therefore the following fields are defined: CAP = MAX_TO WSP BOX_TYPE WSP WC MAX_TO = 1*DIGIT ; maximal timeout granted by the server BOX_TYPE = "NAT" / "FW" / "NATFW" ; types of the middle box WC = "YES" / "NO" ; Wildcarding supported Stiemerling & Quittek [Page 10] Internet-Draft Simple Middlebox Configuration January 2002 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, i.e. to be one of the strings `open', `close', `bind_int', `bind_ext', `bind_full' 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 just two states: CLOSED 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 - `420' reply - `421' reply - `520' reply Additionally, a `510' reply may be generated in the CLOSED state as described below. Stiemerling & Quittek [Page 11] Internet-Draft Simple Middlebox Configuration January 2002 Figure 2 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. open 42X close 220 520 +-----------+ | v +-------------------+ | CLOSED | +-------------------+ | ^ close 220 open 221 | | open 42X v | 520 +-------------------+ | OPEN | +-------------------+ | ^ +-----------+ open 221 Figure 2: Session state machine The initial state of all sessions is CLOSED. The SIMCO server listens on port 6666 for incoming connections. 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 `Authentication' string is analysed. If the authentcation check is successful, a `221' reply is generated and the session enters state OPEN. Otherwise, a `421' reply is generated and the session remains in state CLOSED with the TCP connection still established. The `221' reply contains: Stiemerling & Quittek [Page 12] Internet-Draft Simple Middlebox Configuration January 2002 - the authentication string of the SIMCO server, - 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. The SIMCO client checks the authentication string of the `221' reply and close the TCP connection immediately if the authentication string 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 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 authentcation check is successful, a `221' reply is generated and the session remains in state OPEN. Otherwise, a `421' reply is generated and the session enters state CLOSED with the TCP connection kept established. The `221' reply contains: - the authentication string of the SIMCO server, - 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. The SIMCO client checks the authentication string of the `221' reply and close the TCP connection immediately if the authentication string is not valid. Stiemerling & Quittek [Page 13] Internet-Draft Simple Middlebox Configuration January 2002 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 - 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 3. 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. Stiemerling & Quittek [Page 14] Internet-Draft Simple Middlebox Configuration January 2002 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 3: 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. 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. Stiemerling & Quittek [Page 15] Internet-Draft Simple Middlebox Configuration January 2002 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. 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 already allocated group identifier (GID) must be provided with the `bind_int', `bind_ext' or `bind_full' 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, BIND_IN_ONLY, BIND_EXT_ONLY, FULL_BINDING. Transistion between the states occur in conjunction with the following messages: - `bind_int' request - `bind_ext' request - `bind_full' 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 Stiemerling & Quittek [Page 16] Internet-Draft Simple Middlebox Configuration January 2002 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 4. If the server receives a `bind_int`, a `bind_ext' or a `bind_full' 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. bind_X(BID=0) 44X bind_X(BID=0,timeout=0) 243 +------------------------+ +----------+ | | | v | bind_ext(BID=0) 241 +---------------+ bind_int(BID=0) 241 | +--------------| BID_UNUSED |--------------+ | | +---------------+ | | | ^ bind_X(timeout=0) 243 | | v | bind_X 44X v | +---------------+ | 540 +---------------+ | +->| BIND_EXT_ONLY |----->+<-----------| BIND_INT_ONLY |<-+ | | +---------------+ ^ +---------------+ | | | | | | | | | | +--------+ | +---------------+ | +--------+ | bind_ext 241 +------->| FULL_BINDING |<-------+ bind_int 241 | bind_int 242 +---------------+ bind_ext 242 | bind_full 242 ^ | ^ bind_full 242 | | +-----------+ +------------------------+ bind_X 242 bind_full 242 Figure 4: Binding state machine 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 `bind_int`, `bind_ext' and `bind_full' request keeps the port oddity as given in the request message. 5.4.1. Binding Parameter Set Checking When a `bind_int`, a `bind_ext' or a `bind_full' request is processed, the binding parameter set contained in the message is checked. The checking procedure is common for all states: Stiemerling & Quittek [Page 17] Internet-Draft Simple Middlebox Configuration January 2002 - The IP address is checked whether it is an internal IP address in case of a `bind_int' request or an external address in case of a `bind_ext' request or internal and external IP addresses in case of a `bind_full', respectively. If the check fails or if the IP address is considered invalid for some other reason, then the server generates a `442' reply. - 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 `bind_int`, `bind_ext' or `bind_full` 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 `bind_int' request passes all checks described above, then the server allocates an external address set provided by the firewall/NAT and it establishes a partial binding of the requested binding parameter set with the new allocated address. Then the state machine for this BID enters the state BIND_INT_ONLY and the server generates a `241' reply reporting - the BID allocated for this binding, - the binding parameter set of the bound 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_int' request message, but not greater than the binding- Stiemerling & Quittek [Page 18] Internet-Draft Simple Middlebox Configuration January 2002 group timeout of the corresponding binding-group If a `bind_ext' request passes the checks, the server allocates an internal address set provided by the firewall/NAT and it establishes a partial binding of the requested binding parameter set to the new allocated address. Then the state machine for this BID enters the state BIND_EXT_ONLY and the server generates a `241' reply reporting - the BID allocated for this binding, - the binding parameter set of the bound internal 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_ext' request message, but not greater than the binding- group timeout of the corresponding binding-group If a `bind_full' request passes all checks described above, then the server allocates an external address set and internal address set, provided by the firewall/NAT and it establishes a binding of the requested binding parameter sets with the new allocated addresses. 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 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_full' request message, but not greater than the binding- group timeout of the corresponding binding-group 5.4.3. Transitions from BIND_INT_ONLY and BIND_EXT_ONLY In state BIND_INT_ONLY and BIND_EXT_ONLY a partial address binding is established. In these states the client can request to extend the binding to a full binding one by sending a `bind_ext' request in state BIND_INT_ONLY, by sending a `bind_int' request in state BIND_EXT_ONLY or by sending a `bind_full' in both states, respectively. 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 partial binding. The binding state machine then Stiemerling & Quittek [Page 19] Internet-Draft Simple Middlebox Configuration January 2002 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 partial binding. 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 full 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 BID state machine enters state FULL_BINDING. Other options for the client are requests for - 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 partial binding 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 `bind_int' or `bind_ext' request 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, 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. Stiemerling & Quittek [Page 20] Internet-Draft Simple Middlebox Configuration January 2002 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 a `bind_int' request, a `bind_ext' request or `bind_full' request. The request must use exactly the binding parameter set already contained in the previous `bind_int' request, `bind_ext' request or `bind_full', respectively. 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 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 authenticates itself by sending an `open' request containing Stiemerling & Quittek [Page 21] Internet-Draft Simple Middlebox Configuration January 2002 an authentication string. The server respectively authenticates itself by sending an authentication string in the `221` reply. These might be shared secrets (cookies) in simple authentication systems. The client closes immediately the SIMCO session abd TCP connection when he receives an invalid authentication string from the server. For more secure challenge-reply authentication, the client first sends an `open' request with an arbitrary authentication string. When - as expected - the authentication failed, the server the server returns a challengestring in the following `421' reply. Then the client sends a second `open' request now containing the correct authentication string derived from the challenge string. This procedure is illustrated by the following Example (a). For message flow examples in this memo we use the following 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 C<-S: 421 1300 13e66f34b7416ab9389ccc5b441290aa -- client sends correct authentication C->S: open 1301 SIMCO/1.0 F1EFE ab54346de6933ff4556a1b23efd70082 -- server sends the reply with his authentication and capabilities C<-S: 221 1301 fe43ec43aa3ff4e789 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 a number of invalid `open' requests, the server may disconnect itself from the client. The server in Example (b) disconnects after two invalid `open' requests. Example (b): failed authentication -- TCP connection establishment and TLS or IPSEC establishment Stiemerling & Quittek [Page 22] Internet-Draft Simple Middlebox Configuration January 2002 -- client sends invalid authentication string C->S: open 55000 SIMCO/1.0 F1EFE 34EFA -- server returns challenge string C<-S: 421 55000 13e66f34b7416ab9389ccc5b441290aa -- client sends invalid authentication string C->S: open 55333 SIMCO/1.0 F1EFE 125d5 C->S: 421 55333 13e66f34b7416ab9389ccc5b441290aa -- 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. 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 `bind_int', `bind_ext' and `bind_full' 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. Controlling Bindings The client can request to establish, extend, modify and remove bindings. All of these requests, are variants of a `bind_int', a `bind_ext' or a `bind_full' request. The `bind_int' request name is derived from `establish a binding of the binding parameter set of an Stiemerling & Quittek [Page 23] Internet-Draft Simple Middlebox Configuration January 2002 external address of the NAT/firewall to the parameter set of an internal address'. A successful `bind_int' request allows a data stream matching the corresponding parameter set to pass the NAT/firewall from the external network to the internal one. The `bind_ext' request is defined analogously. The `bind_full' request name is derived from `establishing a full binding with required binding parameter sets`. 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 `bind_int', `bind_ext' or `bind_full' request and the server may accept this proposal or choose a smaller timeout value. The upper limit of the for the 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: bind_int 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 1248 UDP 1 195.37.70.5 13222 180 -- binding established -- 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_int 2067 1 1248 UDP 1 10.11.1.45 16175 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 Stiemerling & Quittek [Page 24] Internet-Draft Simple Middlebox Configuration January 2002 -- and UDP port 16175 for 180 seconds C->S: bind_int 2144 1 0 UDP 1 195.37.70.163 180 -- server does not allocate its own address, but it opens -- a pinhole for the requested binding parameter set. C<-S: 241 2144 1249 UDP 1 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_int 2164 1 1249 UDP 1 195.37.70.163 16175 0 -- pinhole removed C<-S: 243 2164 1 1249 The message flow for controling a full binding at a NAT is illustrated by Example (e). It also shows the extension of the timeout. Example (e): NAT control of TCP full binding -- server is in state OPEN. -- request with GID=1,BID=0 for binding inner IP address 10.11.1.50 -- and TCP port 4524 for 540 seconds C->S: bind_int 8888 1 0 TCP 1 10.11.1.50 4524 540 -- server allocates external IP address 195.37.70.5 and TCP port -- 17250 and binds it to the internal binding parameter set -- for 300 seconds. BID=1250. C<-S: 241 8888 1 1250 TCP 1 195.37.70.5 17250 300 -- request with BID=1250 for binding outer IP address -- 134.169.34.13 and TCP port 22343 for 540 seconds C->S: bind_ext 8889 1 1250 TCP 1 134.169.34.13 22343 540 -- server allocates internal IP address 10.11.1.2 and TCP port -- 5537 and binds it to the external binding parameter set -- for 300 seconds. C<-S: 242 8889 1 1250 TCP 1 10.11.1.2 5537 195.37.70.5 17250 300 -- no more messages concerning this BID for 280 seconds . . . -- binding and pinhole used and need longer as prior granted -- request to extend timeout by 200 seconds C->S: bind_int 9023 1 1250 TCP 1 10.11.1.50 4524 260 -- request granted C<-S: 242 9023 1 1250 TCP 1 10.11.1.2 5537 195.37.70.5 17250 260 -- no more messages concerning this BID for 120 seconds . . . -- binding and pinhole not needed anymore -- request to remove by setting timeout to 0 C->S: bind_ext 9077 1 1250 TCP 1 134.169.34.13 22343 0 -- binding and pinhole removed C<-S: 243 9077 1 1250 Stiemerling & Quittek [Page 25] Internet-Draft Simple Middlebox Configuration January 2002 The message flow for setting up a partial binding with multiple ports at a NAT is illustrated by Example (f). Example (f): 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: bind_int 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 (g) shows the rejection of a request, because an illegal internal IP address is used. Example (g): Rejection of illegal internal IP address -- server is in state OPEN C->S: BIND_INT 458 1 0 UDP 1 102.12.12.251 1254 300 C<-S: 442 458 -- no new binding or pinhole established 9. 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. Stiemerling & Quittek [Page 26] Internet-Draft Simple Middlebox Configuration January 2002 10. 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 [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 11. Authors' Address Martin Stiemerling NEC Europe Ltd. Network Laboratories Adenauerplatz 6 69115 Heidelberg Germany Phone: +49 6221 90511-13 Stiemerling & Quittek [Page 27] Internet-Draft Simple Middlebox Configuration January 2002 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 12. 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 January 2002