Internet Draft M. Stiemerling Document: draft-stiemerling-midcom-simco-02.txt J. Quittek Expires: March 2003 NEC Europe Ltd. October 2002 Simple Middlebox Configuration (SIMCO) Protocol Version 2.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. The protocol meets all requirements defined by the MIDCOM working group (see [4]) and it implements the MIDCOM semantics [3]. Stiemerling & Quittek [Page 1] Internet-Draft Simple Middlebox Configuration October 2002 Table of Contents 1 Introduction ................................................. 2 2 Terminology .................................................. 3 3 SIMCO Protocol Overview ...................................... 4 4 SIMCO Messages ............................................... 5 4.1 Common Definitions ......................................... 5 4.2 Message Definitions ........................................ 7 4.3 Replies .................................................... 7 5 Message Processing in Server ................................. 9 5.1 Syntax Checking ............................................ 10 5.2 Session State Machine ...................................... 10 5.2.1 State Transistions ....................................... 12 5.2.2 Authentication Procedure ................................. 12 5.3 Policy Group State Machine ................................. 12 5.4 Policy State Machine ....................................... 13 5.4.1 Address Parameter Set Checking ........................... 14 5.4.2 Special Addresses in Address Parameter ................... 15 6 Controlling SIMCO Sessions ................................... 15 7 Controlling Policy Rule Groups ............................... 16 8 Controlling Policy Rules ..................................... 17 9 Security Considerations ...................................... 17 10 Open Issues ................................................. 18 11 References .................................................. 18 12 Authors' Address ............................................ 19 13 Full Copyright Statement .................................... 20 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 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,4]. 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], and working group Stiemerling & Quittek [Page 2] Internet-Draft Simple Middlebox Configuration October 2002 decisions. It is fully in line with the MIDCOM protocol semantics specified in [3]. 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. The syntax to the semantics (see [3]) is described and the simple state machines 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. The document uses the terminology of [3] and these definitions: 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 NAT/firewall A NAT or a firewall or a combination of both NAT Address binding For a NAT, the address binding is the phase in which an internal IP address is associated with an external IP Stiemerling & Quittek [Page 3] Internet-Draft Simple Middlebox Configuration October 2002 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 two items: an IP address and a port number Protocol type The IP protocol type as defined in [9,10,11] 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] 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 implements completely the MIDCOM protocol semantics defined in [3], including all optional transactions. The SIMCO 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. Stiemerling & Quittek [Page 4] Internet-Draft Simple Middlebox Configuration October 2002 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, i.e. the client can request policy rules at the middlebox. Should the request include the allocation of port numbers, the SIMCO server will take care about the oddity of the ports, depending on the client request.The policy rules 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 pinholes. For example a Policy Enable Rule `PER' 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 traditional 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. 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 IPv4Address = 1*3DIGIT 3("." 1*3DIGIT) IPv6Address = hexseq | hexseq "::" [ hexseq ] | "::" [ hexseq ] hexseq = 1*4HEXDIG *( ":" 1*4HEXDIG ) Stiemerling & Quittek [Page 5] Internet-Draft Simple Middlebox Configuration October 2002 Port = 1*5DIGIT ; TCP/UDP port NOSP = 1*5DIGIT ; Number Of Subsequent Ports PO = "ANY" / "EVEN" / "ODD" ; Port oddity to keep RID = 1*DIGIT ; Request ID number OWNER = 1*5DIGIT ; Owner of Rule or Group 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*5DIGIT ; Group Identifier PID = 1*5DIGIT ; Policy Rule Identifier The GID is used for grouping different policy rules into one group, for the purpose of handling a group of policy rules with a single request. A GID of zero identifies the default group. The PID is the handle for the firewall/NAT to identify the correct policy rule and it may correlate with the corresponding pin-hole number in the firewall/NAT. A PID of zero means not allocated PID. PT = "IP4" / "IP6" / "UDP4" / "UDP6" / / "TCP4" / "TCP6" ; protocol type MA = 1*4096VCHAR ; Middlebox authentication, limited to 4096 Bytes AA = 1*4096VCHAR ; Agent authentication, limited to 4096 Bytes MC = 1*4096VCHAR ; Middlebox challenge, limited to 4096 Bytes AC = 1*4096VCHAR ; Agent challenge, limited to 4096 Bytes EM = "NONE" ; No encryption supported Message = 1*512VCHAR ; A text message LT = 1*DIGIT ; lifetime in seconds ADR = IPAddress WSP Port ; addresses ADR0 = ADR ; internal addresses ADR1 = ADR ; inside addresses ADR2 = ADR ; outside addresses ADR3 = ADR ; external addresses WAY = "INBOUND" / "OUTBOUND" / "BI" ; direction of communication ACTION = "ENABLE" / "RESERVED" ; for PS reply GLIST = 1*(GID WSP) ; for GS reply PLIST = 1*(PID WSP) ; for PS reply Stiemerling & Quittek [Page 6] Internet-Draft Simple Middlebox Configuration October 2002 Version = "SIMCO/2.0" The SIMCO server advertises its capabilites to the client (see section 4.3 Replies). Therefore the following fields are defined: CAP = MAX_LT WSP BOX_TYPE WSP IPWC WSP PWC WSP INT_IP WSP EXT_IP WSP PERSIST WSP TRANSACTIONS CRLF MAX_LT = 1*DIGIT ; maximal lifetime granted by the server BOX_TYPE = "NAT" / "FW" / "NATFW" / "NAPT" / "NAPTFW" BOX_TYPE =/ "NAT-PT" / "NAT-PTFW" ; types of the middle box IPWC = "YES" / "NO" ; IP address wildcard supported PWC = "YES" / "NO" ; Port number wildcard supported INT_IP = "IP" / "IPv4" / "IPv6" ; EXT_IP = "IP" / "IPv4" / "IPv6" ; PERSIST = "YES" / "NO" ; Persistens Rules TRANSACTION = ["GE" WSP] ["GLC" WSP] ["GL" WSP] ["GS" WSP] TRANSACTION = ["PRR" WSP] ["PLC" WSP] ["PS" WSP] ;list of supported optional transactions 4.2. Message Definitions The following ABNF definitions define the set of SIMCO requests which can be sent from a client to a server.The definitions are grouped into section, group and policy rule requests. ; Session Control Requests request = "SE" WSP RID WSP VERSION WSP MC WSP AA WSP EM CRLF ; Session Establishment request =/ "ST" WSP RID CRLF ; Session Termination ; Policy Group Control request =/ "GE" WSP RID WSP LT CRLF ; Group Establishment request =/ "GLC" WSP RID WSP GID WSP LT CRLF ; Group Lifetime Change request =/ "GL" WSP RID CRLF ; Group List request =/ "GS" WSP RID WSP GID CRLF ; Group Status ; Policy Rle Control request =/ "PRR" WSP RID WSP GID WSP PT WSP NOSP WSP PO WSP LT CRLF ; Policy Rule Reservation request =/ "PER" WSP RID WSP GID WSP PID WSP PT WSP NOSP WSP PO WSP TOPOLOGY WSP ADR0 WSP ADR3 WSP LT CRLF Stiemerling & Quittek [Page 7] Internet-Draft Simple Middlebox Configuration October 2002 ; Policy Rule Enable request =/ "PLC" WSP RID WSP PID WSP LT CRLF ; Policy Lifetime Change request =/ "PS" WSP RID WSP PID CRLF ; Policy Status 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 2.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 policy rule control x5z more replies for requests concerning policy rule 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: ; Syntax Errors Reply = "410" WSP RID CRLF ; syntax Error Reply =/ "411" WSP RID CRLF ; unknown or illegal request Reply =/ "412" WSP RID CRLF ; Request not supported Reply =/ "510" WSP Message CRLF ; illegal message ; Session Control Reply =/ "220" WSP RID CRLF ; session closed Reply =/ "221" WSP RID WSP MA WSP AC CRLF ; need further auth. Reply =/ "222" WSP RID WSP CAP CRLF ; OK with capabilities Reply =/ "420" WSP RID CRLF : protocol version mismatch Reply =/ "421" WSP RID CRLF ; authentication failed Stiemerling & Quittek [Page 8] Internet-Draft Simple Middlebox Configuration October 2002 Reply =/ "422" WSP RID CRLF ; no authorization Reply =/ "423" WSP RID CRLF ; encryption method not supported Reply =/ "424" WSP RID CRLF ; no resources available Reply =/ "520" WSP Message CRLF ; asynchronous session termination (AST) ; Policy Group Control Reply =/ "231" WSP RID WSP GID WSP LT CRLF ; OK for policy group Reply =/ "232" WSP RID WSP LT CRLF ; OK for policy group lifetime change Reply =/ "233" WSP RID CRLF ; policy group deleted Reply =/ "234" WSP RID WSP GLIST CRLF ; GL reply Reply =/ "235" WSP RID WSP GOWNER WSP LT WSP PLIST CRLF ; GS reply Reply =/ "430" WSP RID CRLF ; transaction not supported Reply =/ "431" WSP RID CRLF ; not authorized for transaction Reply =/ "432" WSP RID CRLF ; no resources available Reply =/ "433" WSP RID CRLF ; not authorized for GLC Reply =/ "434" WSP RID CRLF ; unknown or illegal GID Reply =/ "435" WSP RID CRLF ; no GLC for default group Reply =/ "436" WSP RID CRLF ; lifetime can't be extended Reply =/ "437" WSP RID CRLF ; not authorized for GL Reply =/ "530" WSP GID CRLF ; asynchronous group deletion (AGD) ; Policy Rule Control Reply =/ "240" WSP RID WSP PID WSP ADR1 WSP ADR2 WSP LT CRLF ; PRR request successful, reservation done Reply =/ "241" WSP RID WSP PID WSP ADR1 WSP ADR2 WSP LT CRLF ; PER request successful, policy is enabled Reply =/ "242" WSP RID WSP LT CRLF ; PLC request successful, policy lifetime changed Reply =/ "243" WSP RID CRLF ; PLC request successful, policy has been deleted Reply =/ "244" WSP RID WSP OWNER WSP GID WSP ACTION WSP PT WSP NOSP WSP WAY WSP ADR0 WSP ADR3 WSP ADR1 WSP ADR2 WSP LT CRLF Reply =/ "440" WSP RID CRLF ; transaction not supported Reply =/ "441" WSP RID CLRF ; not authorized for transaction Reply =/ "442" WSP RID CRLF ; no resources available Reply =/ "443" WSP RID CRLF ; GID/PID pair doesn't match Reply =/ "444" WSP RID CRLF ; unknown of illegal PID Reply =/ "445" WSP RID CRLF ; no ADR1 reservation supported Reply =/ "446" WSP RID CRLF ; no ADR2 reservation supported Reply =/ "447" WSP RID CRLF ; not authorized for this policy Reply =/ "448" WSP RID CLRF ; not authorized for this group Reply =/ "449" WSP RID CRLF ; protocol type doesn't match Reply =/ "450" WSP RID CRLF ; conflict with existing rule Stiemerling & Quittek [Page 9] Internet-Draft Simple Middlebox Configuration October 2002 Reply =/ "451" WSP RID CRLF ; not authorized to change lifetime Reply =/ "452" WSP RID CRLF ; lifetime can't be extended Reply =/ "453" WSP RID CRLF ; illegal IP Address Reply =/ "454" WSP RID CRLF ; protocol Type not supported Reply =/ "455" WSP RID CRLF ; illegal port number Reply =/ "456" WSP RID CRLF ; illegal NOSP Reply =/ "457" WSP RID CRLF ; already enable PID Reply =/ "458" WSP RID CRLF ; oddity doesn't match Reply =/ "540" WSP PID CRLF ; asynchronous policy rule deletion (APD) 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 policy rules and messages concerning the control of groups. 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 - `412' 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 `SE', `ST', `GE', `GLC', `GL' , `GS', `PRR', `PER', `PLC', or `PS'. If the string is invalid, a `411' reply is sent and processing of the message stops. Does the command string belong to the strings above, but the command is optional and not implemented, the server generates a `412' reply. 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. Stiemerling & Quittek [Page 10] Internet-Draft Simple Middlebox Configuration October 2002 5.2. Session State Machine The SIMCO session state machine models exactly the state machine described in [3] Figure 2. It has three states: CLOSED, NOAUTH and OPEN. Transisions between these states only appear in conjunction with one or two of the following messages: - `SE' request - `ST' request - `220' reply - `221' reply - `222' reply - `42X' replies - `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. Clients may as well participate in several concurrent sessions with different server. Stiemerling & Quittek [Page 11] Internet-Draft Simple Middlebox Configuration October 2002 mc = middlebox challenge SE/42x ma = middlebox authentication +-------+ ac = agent challenge | v aa = agent authentication +----------+ | CLOSED |----------------+ +----------+ | SE(mc!=0)/ | ^ ^ | 221 SE(mc=0, | | | 520 | aa=OK)/ | | | SE/42x v 222 | | | ST/220 +----------+ | | +------------| NOAUTH | | | +----------+ | | 520 | SE(mc=0, v | ST/220 | aa=OK)/ +----------+ | 222 | OPEN |<---------------+ +----------+ 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: `SE' and `ST'. 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 `SE' and `ST' messages have an impact on the session state. 5.2.1. State Transistions The state transistions are described in [3], section 2.2 Session Control Transactions. 5.2.2. Authentication Procedure The authentication procedure is described in [3], section 2.2.1 Session Establishment. 5.3. Policy Group State Machine The policy group behaviour is described in [3], section 2.3 Policy Group Transactions. The SIMCO policy group state machine models Stiemerling & Quittek [Page 12] Internet-Draft Simple Middlebox Configuration October 2002 exactly the state machine described in [3] Figure 3. SIMCO defines the group identifier 0 as the default group. Thus this GID can not be deleted or extend in his lifetime. When the session state machine is in state OPEN, the server accepts further requests regarding policy groups. The state machine of a policy group contains two states: GROUP UNUSED and GROUP INUSE. Transistions between the states occur in conjunction with the following messages: - `GE' request - `GLC' request - 23X replies - 43X replies - 530 reply GE/43x +--------+ | v +----------+ | GROUP | | UNUSED | +----------+ | ^ GE/231 | | GLC(lt=0)/ 233 | | 530 v | +----------+ | GROUP | | INUSE | +----------+ | ^ +--------+ GLC(lt>0)/232 GLC/43x lt = lifetime Figure 2: Policy Group state machine 5.4. Policy State Machine The policy rule behaviour is described in [3], section 2.4 Policy Transactions. The SIMCO policy state machine models exactly the state machine described in [3] Figure 5. When the session state machine is in state OPEN, the server accepts further requests regarding policy rules. The state machine of a Stiemerling & Quittek [Page 13] Internet-Draft Simple Middlebox Configuration October 2002 policy rule contains three states: POLICY UNUSED, RESERVED, and POLICY INUSE. A PER request with policy identifier (PID) of 0 requests the establishement of a new policy enable rule. Transistion between the states occur in conjunction with the following messages: - `PRR' request - `PER' request - `PLC' request - `24X' replies - `44X' replies - `45X' replies - `540' reply PRR/44x 45x PER/44x 45x +-----------+ | v PRR/240 +-+-------------+ +-----------------+ POLICY UNUSED |<-+ +----+ | +---------------+ | | | | ^ | | | v v 540 | | | | +-------------+ PER/44x 45x| | PER(pid=0) | 540 | | RESERVED +------------+ | /241 | PLC(lt=0)/ | +-+----+------+ PLC(lt=0)/ | | 243 | | | 243 | | +----+ | v | PLC(lt>0)/ | PER(pid!=0)/241 +---------------+ | 242 +---------------->| POLICY INUSE +--+ PLC/44x 45x +-+-------------+ | ^ +-----------+ lt = lifetime PLC(lt>0)/242 PLC/44x 45x Figure 3: Policy rule state machine 5.4.1. Address Parameter Set Checking When a `PRR` or a `PER' request is processed, the address parameters contained in the message are 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 `453' reply when this IP address will be rejected. Stiemerling & Quittek [Page 14] Internet-Draft Simple Middlebox Configuration October 2002 - The protocol type is checked, whether it is valid and supported. If the check fails, a `454' reply is generated. - The port number is checked whether it is valid. If the check fails, a `456' reply is generated. - The NOSP parameter is checked whether it is valid. If the check fails, a `447' reply is generated. If the checks are successful the server may perform further checks on the combination of the elements of the address parameter sets, 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 `447' reply. Otherwise the server will continue with establishing the requested policy rule. 5.4.2. Special Addresses in Address Parameter For wildcarding purposes SIMCO defines an IP address and port wildcarding. Any IPv4 address is "0.0.0.0" and any IPv6 address is "::" . A port wildcard is always set to "0". When no IP address has been assigned by the SIMCO server it returns a NONE IP address in its `244' reply. The NONE IPv4 address is 255.255.255.255 and NONE IPv6 address is FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF. 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 complete authentication procedure is described in [3] Section 2.2.1. 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 indication of the direction of a message: C->S: from the client to the server C<-S: from the server to the client Stiemerling & Quittek [Page 15] Internet-Draft Simple Middlebox Configuration October 2002 --: comment line . . .: some unspecified messages Example (a): successful authentication -- TCP connection establishment and TLS or IPSEC establishment -- client sends a middlebox challenge C->S: SE 1300 SIMCO/2.0 F1EFE 0 NONE -- server returns its authentication and an agent challenge C<-S: 221 1300 13e66f34b7416ab9389ccc5b441290aa df3ee4523ac3c32 -- client sends correct authentication C->S: SE 1301 SIMCO/2.0 0 ab54346de6933ff4556a1b23efd70082 NONE -- server sends the reply with his capabilities C<-S: 222 1301 1800 NATPTFW NO YES IPv4 IPv4 NO PRR -- session now in state OPEN . . . -- SIMCO message exchange . . . -- client closes session C->S: ST 54321 C<-S: 220 54321 -- 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: SE 1300 SIMCO/2.0 F1EFE 0 NONE -- server returns its authentication and an agent challenge C<-S: 221 1300 13e66f34b7416ab9389ccc5b441290aa df3ee4523ac3c32 -- client sends invalid authentication C->S: SE 1301 SIMCO/2.0 0 BEEF NONE C<-S: 421 1301 -- server in state CLOSED, client disconnected 7. Controlling Policy Rule Groups The client can request to establish, extend, and remove policy rules groups other than the default group. Each policy rule group has a lifetime value, which determines when a group is automatically removed by the SIMCO server. But before removing the group, all policy rules in the group are removed at first. Control of binding-group is illustrated by the next Example: Stiemerling & Quittek [Page 16] Internet-Draft Simple Middlebox Configuration October 2002 -- server is in state OPEN -- request a new binding-group with a timeout of 2000 seconds C->S: GE 32345 2000 -- server allocates a new group identifier (GID) of 1 and grants a -- group lifetime of 1800 seconds C<-S: 231 32345 1 1800 . . . -- The client removes the binding-group after 1000 seconds C->S: GLC 32400 1 0 -- policy rule group removed C<-S: 233 32400 8. Controlling Policy Rules The client can request to reserve, establish, and remove policy rules. Control of NAT bindings and firewall 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, for inner IP address 10.11.1.45 -- and UDP port 16175 for 180 seconds C->S: PRR 1000 1 UDP 1 ANY OUTSIDE 180 -- server allocates external IP address 195.37.70.5 and UDP port -- 13222 and binds it to the internal addresses -- for 180 seconds. For adr1 a zero IP address and -- port number are returned, since it is a traditional -- NAT. PID=1248. C<-S: 240 1000 1248 0.0.0.0 0 195.37.70.5 13222 180 -- Now enable the policy rule C->S: PER 2044 1 1248 UDP 1 ANY INBOUND 10.11.1.45 16175 139.6.138.20 4325 180 -- server enables policy rule C<-S: 241 2044 1248 139.6.138.20 4325 195.37.70.5 13222 -- client removes policy rule after 100 seconds C->S: PLC 3021 1248 0 -- server removes policy rule C<-S: 243 3021 9. Security Considerations By their nature firewalls and NATs are a very sensitive points concerning network security. In general it appears to be Stiemerling & Quittek [Page 17] Internet-Draft Simple Middlebox Configuration October 2002 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. 10. Open Issues - More Examples on policy rule configuration need? 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", RFC 3303, August 2002 December 2001 [3] Stiemerling, M., Quittek J., Taylor T., "MIDCOM Protocol Semantics", Internet Draft, work in progress, , October 2002 [4] Swale, R.P., Mart, P.A., Sijben, P., Brimm, S., Shore, M., "Middlebox Control (MIDCOM) Protocol Architecture and Requirements", RFC 3304, August 2002 [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 Stiemerling & Quittek [Page 18] Internet-Draft Simple Middlebox Configuration October 2002 [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 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 19] Internet-Draft Simple Middlebox Configuration October 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 20] Internet-Draft Simple Middlebox Configuration October 2002