Internet Draft                                            M. Stiemerling
Document: draft-stiemerling-nat-fw-config-00.txt              J. Quittek
Expires: May 2002                                        NEC Europe Ltd.

                                                           November 2001


   Simple NAT and Firewall Configuration (SNFC) Protocol Version 1.0

                <draft-stiemerling-nat-fw-config-00.txt>

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 (2001).  All Rights Reserved.


Abstract

   This memo specifies a 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 Simple NAT and Firewall Control (SNFC) protocol allows clients to
   send requests for this purpose to serving NATs and/or firewalls. The
   protocol is designed to provide a very simple and basic solution that
   can easily be implemented and used.




Stiemerling & Quittek                                           [Page 1]


Internet-Draft    Simple NAT and Firewall Configuration    November 2001


Table of Contents

   1 Introduction .................................................    2
   2 Terminology ..................................................    2
   3 SNFC Protocol Overview .......................................    4
   4 SNFC Messages ................................................    5
   4.1 Common Definitions .........................................    5
   4.2 Message Definitions ........................................    6
   4.3 Replies ....................................................    6
   5 Message Processing in Server .................................    8
   5.1 Syntax Checking ............................................    8
   5.2 Session State Machine ......................................    8
   5.2.1 Transistions from State CLOSED ...........................    9
   5.2.2 Transistions from State OPEN .............................   10
   5.3 Binding State Machine ......................................   10
   5.3.1 Transport Parameter Set Checking .........................   11
   5.3.2 Transitions from State BID_UNUSED ........................   12
   5.3.3 Transitions from BIND_IN_ONLY and BIND_OUT_ONLY ..........   13
   5.3.4 Transitions from State FULL_BINDING ......................   14
   6 Controling SNFC Sessions .....................................   15
   7 Controling Bindings and Pinholes .............................   17
   8 Security Considerations ......................................   19
   9 References ...................................................   19
   10 Authors' Address ............................................   20
   11 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 the 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 SNFC) 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,3]. The group currently discusses requirements for a
   signaling protocol [4]. The SNFC protocol described in this document
   shall contribute to the requirements discussion by demonstrating how
   a very simple and straight forward approach to such a protocol can


Stiemerling & Quittek                                           [Page 2]


Internet-Draft    Simple NAT and Firewall Configuration    November 2001


   look like. The SNFC 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 only four different kinds of requests and very simple state
   machines that are completely specified below.

   This memo describes the architectural background for the SNFC
   protocol and its basic concepts in section 3. Section 4 defines all
   SNFC 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 SNFC
   session, and section 7 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 8. 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.

   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 use of the
                                   term `firewall' refers 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 (cf.
                                   [1], Section 2.8) or the protected
                                   network of a firewall

   external side                   The public network of a NAT (cf. [1],
                                   Section 2.7) or firewall.

   inner or internal IP Address    An IP address which is located at the
                                   internal side of a NAT/firewall


Stiemerling & Quittek                                           [Page 3]


Internet-Draft    Simple NAT and Firewall Configuration    November 2001


   outer or external IP Address    An IP address which is located at the
                                   external side of a NAT/firewall.

   transport parameter set         A set consisting of three items: an
                                   IP address, a port number, and an IP
                                   protocol type.

   inner transport parameter set   Transport parameter set with inner IP
                                   address and port number.

   outer transport parameter set   transport parameter set with an outer
                                   IP address and port number.

   inner binding                   A binding of an inner transport
                                   parameter set of a host (TP0) to and
                                   an outer transport parameter set of a
                                   NAT/firewall (TP2), as shown in
                                   Figure 1.


         +----------+             +--------+             +----------+
         | internal |TP0       TP1|        |TP2       TP3| external |
         |   host   |-------------| NAT/FW |-------------|   Host   |
         +----------+  private/   +--------+   public    +----------+
                       protected               network
                       network

              Figure 1: Addresses of internal hosts, NAT/firewall,
                        and external hosts


   outer Binding                   A binding of an outer transport
                                   parameter set of a host (TP3) to and
                                   an outer transport parameter set of a
                                   NAT/firewall (TP2), as shown in
                                   Figure 1.

   uni-directional binding         An inner binding or an outer binding

   bi-directional binding          A combination of an inner binding and
                                   an outer binding

   full binding                    A bi-directional binding

   pin-hole                        A configuration of the firewall
                                   allowing packets matching a binding
                                   to pass the firewall. Like bindings,
                                   a pinhole may be uni-directional or
                                   bi-directional.



Stiemerling & Quittek                                           [Page 4]


Internet-Draft    Simple NAT and Firewall Configuration    November 2001


3.  SNFC Protocol Overview

   The SNFC protocol is intended to comply with the midcom architecture
   specified in [2]. The protocol allows a client (midcom agent) to
   establish a SNFC session with a server.  An important component of
   session establishment is the authentication and authorization of the
   client, because configuring a 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 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.
   The approach of SNFC is to use the same requests for both purposes.
   For example a `bind_in' request (described in sections 4 and 5)
   requests sends an inner transport parameter set to the server and
   requests the allocation of outer transport parameter set at the NAT
   and a binding between both sets:

    - In case of a pure NAT, the outer transport parameters are
      allocated and a binding is established providing proper address
      translation.

    - In case of a pure firewall, the allocated outer transport
      parameter 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 outer transport parameters
      are 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.


4.  SNFC 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.


Stiemerling & Quittek                                           [Page 5]


Internet-Draft    Simple NAT and Firewall Configuration    November 2001


4.1.  Common Definitions

   The following definitions are used in the subsequent chapters to
   define the SNFC protocol messages.

      IPAddress      = IPv4Address / IPv6Address / "0"
      IPv4Address    = 1*3DIGIT 3("." 1*3DIGIT)
      IPv6Address    = 1*4HEXDIG 7( ":" 1*4HEXDIG)
      Port           = 1*DIGIT
      MID            = 1*DIGIT                    ; Message ID number

   The MID is an identifier for the client, to recognize which reply
   belongs to which request, i.e. the MID in the reply is allways the
   same as in the request.

      BID            = 1*DIGIT                    ; Binding ID number

   The BID is the handle for the Firewall/NAT to identify the correct
   pin-hole 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" / "ANY" ; IP protocol type
     Authentication = 1*VCHAR
     Challenge      = 1*VCHAR
     Message        = 1*VCHAR
     Timeout        = 1*DIGIT                    ; timeout in seconds
     TPS            = IPAddress WSP Port WSP PT  ; transport param. set
     TPS_in         = TPS                        ; internal TPS
     TPS_ex         = TPS                        ; external TPS
     Version        = "SNFC/1.0"

4.2.  Message Definitions

   The following ABNF definitions define the set of SNFC requests which
   can be sent from a client to a server.

     request =  "open"     WSP MID WSP Version WSP Authentication CRLF
     request =/ "close"    WSP MID CRLF
     request =/ "bind_in"  WSP MID WSP BID WSP TPS WSP Timeout CRLF
     request =/ "bind_out" WSP MID WSP BID WSP TPS WSP Timeout CRLF

   The `open' and the `close' request are exclusively used for session
   control. The `bind_in' and the `bind_out' request are exclusively
   used for binding and pinhole 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


Stiemerling & Quittek                                           [Page 6]


Internet-Draft    Simple NAT and Firewall Configuration    November 2001


   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 SNFC version 1.0.
   They are defined only for future SNFC 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 concening session control
     x3z   replies for requests concening binding and pinhole 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 MID CRLF         ; syntax Error
     Reply =/ "411" WSP MID CRLF         ; unknown or illegal request
     Reply =/ "510" WSP Message CRLF     ; illegal message

     Reply =  "220" WSP MID CRLF         ; OK
     Reply =/ "420" WSP MID CRLF         ; protocol version mismatch
     Reply =/ "421" WSP MID WSP Challenge CRLF  ; authentication failed
     Reply =/ "520" WSP Message CRLF     ; session closed

     Reply =/ "231" WSP MID WSP BID WSP TPS
                    WSP Timeout CRLF     ; OK for uni-direct. binding
     Reply =/ "232" WSP MID WSP BID WSP TPS_in WSP TPS_ex
                    WSP Timeout CRLF     ; OK for full binding
     Reply =/ "233" WSP MID WSP BID CRLF ; binding removed
     Reply =/ "430" WSP MID CRLF         ; unknown or illegal BID
     Reply =/ "431" WSP MID CRLF         ; binding Refused
     Reply =/ "432" WSP MID CRLF         ; illegal IP Address
     Reply =/ "433" WSP MID CRLF         ; protocol type not supported
     Reply =/ "434" WSP MID CRLF         ; illegal port number
     Reply =/ "435" WSP MID CRLF         ; cannot modify binding
     Reply =/ "530" WSP BID CRLF         ; binding timed out









Stiemerling & Quittek                                           [Page 7]


Internet-Draft    Simple NAT and Firewall Configuration    November 2001


5.  Message Processing in Server

   This section describes the processing steps performed by a SNFC
   server after receiving a message. Common to all incoming messages is
   that first the syntax is checked.  Then we distinguish messages
   concerning session control ans messages concerning the control of
   address bindings.  For both 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 message identifier
   (MID). 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
   message identifier, then the message is discarded. An asynchronous
   `510' reply may be generated in this case. Otherwise, the command
   string is checked to be valid, i.e. to be one of the strings `open',
   `close', bind_in', bind_out', `refresh', or `remove'.  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 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
      - `420' reply
      - `421' reply
      - `520' reply

   Additionally, a `510' reply may be generated in the CLOSED state as
   described below.

   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.




Stiemerling & Quittek                                           [Page 8]


Internet-Draft    Simple NAT and Firewall Configuration    November 2001


                      open 42X
                      close 220
                      520
                    +-----------+
                    |           v
                +-------------------+
                |      CLOSED       |
                +-------------------+
                    |           ^ close 220
           open 220 |           | open 42X
                    v           | 520
                +-------------------+
                |       OPEN        |
                +-------------------+
                    |           ^
                    +-----------+
                      open 220

          Figure 2: Session state machine


   The initial state of all sessions is CLOSED. If a client establishes
   a connection to the server by successfully creating a socket, then a
   session in state CLOSED is assigned to this 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
   SNFC 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 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 `220' reply is generated and the session enters state
   OPEN. Otherwise, a `421' reply is generated and the session remains
   in state CLOSED with the connection still established.

   At any time the server may generate an asynchronous `520' reply
   followed by closing the connection. In this case the session will
   remain in state CLOSED. Particularly, the server may generate a `520'
   reply, if a connection is established and the time the session
   remains in state CLOSED exceeds a given timeout value.





Stiemerling & Quittek                                           [Page 9]


Internet-Draft    Simple NAT and Firewall Configuration    November 2001


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 connection being
   closed. The same transition occurs if the server decides to close the
   session. Then it generates a `520' reply, closes the 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 connection is closed, and the state machine enters state CLOSED.
   Otherwise, the contained `Authentication' string is analysed. If the
   authentcation check is successful, a `220' reply is generated and the
   session remains in state OPEN. Otherwise, a `421' reply is generated
   and the session enters state CLOSED with the connection kept
   established.

   At any time the server may generate an asynchronous `520' reply
   followed by closing the connection. In this case the session will
   enter state CLOSED.

5.3.  Binding State Machine

   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_OUT_ONLY,
   FULL_BINDING.  Transistion between the states occur in conjunction
   with the following messages:

      - `bind_in' request
      - `bind_out' request
      - `23X' replies
      - `43X' replies
      - `530' 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 unused because it is
   not assigned to any binding, then the server will discard the request
   and generate a `430' 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 there exists a state machine as shown in
   Figure 3. If the server receives a `bind_in` or a `bind_out' 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


Stiemerling & Quittek                                          [Page 10]


Internet-Draft    Simple NAT and Firewall Configuration    November 2001


   with the initial state BID_UNUSED.


                              bind_X(BID=0) 43X
                              bind_X(BID=0,timeout=0) 233
                                +-----------+
                                |           v
          bind_out(BID=0) 231 +---------------+ bind_in(BID=0) 231
               +--------------|  BID_UNUSED   |--------------+
               |              +---------------+              |
               |                   ^ bind_X(timeout=0) 233   |
               v                   | bind_X 43X              v
            +---------------+      | 530        +---------------+
         +->| BIND_OUT_ONLY |----->+<-----------| BIND_IN_ONLY  |<-+
         |  +---------------+      ^            +---------------+  |
         |        |  |             |                   |  |        |
         +--------+  |        +---------------+        |  +--------+
        bind_out 231 +------->| FULL_BINDING  |<-------+  bind_in 231
                  bind_in 232 +---------------+ bind_out 232
                                |           ^
                                +-----------+
                                 bind_X 232

                        Figure 3: 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.

5.3.1.  Transport Parameter Set Checking

   When a `bind_in` or a `bind_out' request is processed, the transport
   parameter set contained in the message is checked. The checking
   procedure is common for all states:

     - The IP address is checked whether it is an inner IP address in
       case of a `bind_in' request or an outer address in case of a
       `bind_out' request, respectively. If the check fails or if the IP
       address is considered invalid for some other reason, then the
       server generates a `432' reply.

     - The protocol type is checked, whether it is valid and supported.
       If the check fails, a `433' reply is generated.

     - The port number is checked whether it is valid.  If the check
       fails, a `434' reply is generated.



Stiemerling & Quittek                                          [Page 11]


Internet-Draft    Simple NAT and Firewall Configuration    November 2001


   If the checks are successful the server may perform further checks on
   the combination of the elements of the transport 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 `431' reply. Otherwise the server will continue
   with establishing the requested binding.

5.3.2.  Transitions from State BID_UNUSED

   In state BID_UNUSED, only `bind_in` and `bind_out' 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 `233' reply and the binding state machine remains in
   state BID_UNUSED.

   If a `bind_in' request passes all checks described above, then the
   server allocates an external address provided by the Firewall/NAT and
   it establishes a uni-directional binding of the requested transport
   parameter set with the new allocated address. Then the state machine
   for this BID enters the state BIND_IN_ONLY and the server generates a
   `231' reply reporting

     - the BID allocated for this binding,

     - the transport parameter set of the bound external address,

     - 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_in' request message.

   If a `bind_out' request passes the checks, the server allocates an
   internal address provided by the Firewall/NAT and it establishes a
   uni-directional binding of the requested transport parameter set to
   the new allocated address.  Then the state machine for this BID
   enters the state BIND_OUT_ONLY and the server generates a `231' reply
   reporting

     - the BID allocated for this binding,

     - the transport parameter set of the bound internal address,

     - 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_out' request message.


Stiemerling & Quittek                                          [Page 12]


Internet-Draft    Simple NAT and Firewall Configuration    November 2001


5.3.3.  Transitions from BIND_IN_ONLY and BIND_OUT_ONLY

   In state BIND_IN_ONLY and BIND_OUT_ONLY a uni-directional address
   binding is established. This might be sufficient for UDP connections,
   but not for TCP. In these states the client can request to extend the
   binding to a bi-directional one by sending a `bind_out' request in
   state BIND_IN_ONLY or by sending a `bind_in' request in state
   BIND_OUT_ONLY, respectively. The request must contain the BID of the
   already existing uni-directional binding.

   If the request fails the transport parameter set checking, then the
   server generates the according `43X' reply and also it removes the
   already established uni-directional binding. The binding state
   machine then enters state BID_UNUSED.  If the timeout specified by
   the request message is 0, then the server generates a `233' reply and
   removes the already established uni-directional binding. The binding
   state machine then enters state BID_UNUSED.

   Otherwise, if the request passes the checks of the transport
   parameter set, the server creates a bi-directional binding to the
   already known BID and chooses a timeout less than or equal to the
   value specified by the request. The server generates a `232' reply
   reporting the chosen timeout and the internal and the external
   address allocated at the NAT/firewall. The BID state machine enters
   state FULL_BINDING.

   Other options for the client are requests for

     - updating the timeout,

     - modifying the binding while keeping the BID and keeping the
       address allocated by the server,

     - removing the binding.

   Each of these actions requires the client sending another `bind_in'
   request in state BIND_IN_ONLY or sending another `bind_out' request
   in state BIND_OUT_ONLY.

   For timeout update and for binding removal the client must use
   exactly the transport parameter set already contained in the previous
   requests for this BID. 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 `233' 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


Stiemerling & Quittek                                          [Page 13]


Internet-Draft    Simple NAT and Firewall Configuration    November 2001


   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 and reports it by generating `231' reply.  The
   binding state machine remains in its state.

   If the transport parameters specified in the request message differ
   from the ones used in the previous message, then they are checked by
   the server. A `43X' reply is generated on failure of one of these
   checks. Then the server is supposed to modify the binding. If it is
   not capable of doing so, it generates a `435' reply, removes the
   binding and the binding state machine enters state BID_UNUSED.

   Otherwise, the server will replace the established binding with a new
   one. The modified binding will keep the address allocated by the
   server, but bind it to the transport parameter set contained in the
   message. The BID remains unchanged. Then the server generates a `231'
   reply confirming the change and reporting the chosen timeout. 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 `530' message
   indicating the removal of the binding and the binding state machine
   enters state BID_UNUSED.

5.3.4.  Transitions from State FULL_BINDING

   In state FULL_BINDING the client can request to

     - update the timeout,

     - remove the binding,

     - modify the binding while keeping the BID and keepig the addresses
       allocated by the server.

   For timeout update and for binding removal the client can use a
   `bind_in' request or a `bind_out' request. The request must use
   exactly the transport parameter set already contained in the previous
   `bind_in' request or `bind_out' request, 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 `233' reply, and the binding state
   machine enters state BID_UNUSED.



Stiemerling & Quittek                                          [Page 14]


Internet-Draft    Simple NAT and Firewall Configuration    November 2001


   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 and reports it by generating `231' reply.  The
   binding state machine remains in its state.

   If the transport parameter set specified in the request message
   differ from the ones used in the previous message, then they are
   checked by the server. A `43X' reply is generated on failure of one
   of these checks. Then the server is supposed to modify the binding.
   If it is not capable of doing so, it generates a `435' reply, removes
   the binding and the binding state machine enters state BID_UNUSED.

   Otherwise, the server will replace the established binding with a new
   one. The modified binding will keep the addresses allocated by the
   server, but bind it to the transport parameter set contained in the
   message. The BID remains unchanged. Then the server generates a `232'
   reply confirming the change and reporting the chosen timeout. The
   binding state machine remains in state FULL_BINDING.

   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 `530' message
   indicating the removal of the binding and the binding state machine
   enters state BID_UNUSED.


6.  Controling SNFC Sessions

   After a secure TCP connection has been established between client and
   server (for example by using TLS [5] or IPSEC [6][7]), the SNFC
   session requires an initial authentication of the client. 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 SNFC session. The client
   authenticates itself by sending an `open' request containing an
   authentication string. This might be a shared secret (cookie) in
   simple authentication systems.

   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).


Stiemerling & Quittek                                          [Page 15]


Internet-Draft    Simple NAT and Firewall Configuration    November 2001


   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 SNFC/1.0 0
      -- server returns challenge string
      C<-S: 421 1300 13e66f34b7416ab9389ccc5b441290aa
      -- client sends correct authentication
      C->S: open 1301 SNFC/1.0 ab54346de6933ff4556a1b23efd70082
      C<-S: 220 1301
      -- session now in state OPEN
      . . .
      -- SNFC 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
      -- client sends invalid authentication string
      C->S: open 55000 SNFC/1.0 34EFA
      -- server returns challenge string
      C<-S: 421 55000 13e66f34b7416ab9389ccc5b441290aa
      -- client sends invalid authentication string
      C->S: open 55333 SNFC/1.0 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.





Stiemerling & Quittek                                          [Page 16]


Internet-Draft    Simple NAT and Firewall Configuration    November 2001


7.  Controling Bindings and Pinholes

   The client can request to establish, entend, modify and remove uni-
   directional and bi-directional bindings and pinholes. All of these
   requests, are variants of a `bind_in' or a `bind_out' request. The
   `bind_in' request name is derived from `establish a binding of the
   transport parameter set of an external address of the NAT/firewall to
   the parameter set of an internal address'.  A successful `bind_in'
   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_out' request is defined analogously.

   Each binding has a timeout value, which determines when a binding is
   automatically removed by the SNFC server. The client makes a timeout
   proposal in his `bind_in' or `bind_out' request and the server may
   accept this proposal or choose a smaller timeout value. 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): control of uni-directional UDP binding and pinhole
      -- server is in state OPEN.
      -- request with BID=0 for binding inner IP address 10.11.1.45
      --   and UDP port 16175 for 180 seconds
      C->S: bind_in 2044 0 10.11.1.45 16175 UDP 180
      -- server allocates external IP address 195.37.70.5 and UDP port
      --   13222 and binds it to the internal transport parameter set
      --   for 180 seconds. BID=1248.
      C<-S: 231 2044 1248 195.37.70.5 13222 UDP 180
      -- binding established and pinhole open
      -- no more messages concerning this BID for 245 seconds
      . . .
      -- binding and pinhole not needed anymore
      -- request to remove by setting timeout to 0
      C->S: bind_in 2067 1248 10.11.1.45 16175 UDP 0
      -- binding and pinhole removed
      C<-S: 233 2067 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 transport parameter set is equal to the one
   in the request.

   Example (d): control of uni-directional UDP pinhole only
      -- server is in state OPEN.
      -- request with BID=0 for binding inner IP address 195.37.70.163


Stiemerling & Quittek                                          [Page 17]


Internet-Draft    Simple NAT and Firewall Configuration    November 2001


      --   and UDP port 16175 for 180 seconds
      C->S: bind_in 2144 0 195.37.70.163 16175 UDP 180
      -- server does not allocate its own address, but it opens
      -- a pinhole for the requested transport parameter set.
      C<-S: 231 2144 1249 195.37.70.163 16175 UDP 180
      -- pinhole open
      -- no more messages concerning this BID for 245 seconds
      . . .
      -- pinhole not needed anymore
      -- request to remove by setting timeout to 0
      C->S: bind_in 2164 1249 195.37.70.163 16175 UDP 0
      -- pinhole removed
      C<-S: 233 2164 1249

   The message flow for controling a bi-directional binding and pinhole
   is illustrated by Example (e). It also shows the extension of the
   timeout.

   Example (e): control of bi-directional TCP binding and pinhole
      -- server is in state OPEN.
      -- request with BID=0 for binding inner IP address 10.11.1.50
      --   and TCP port 4524 for 540 seconds
      C->S: bind_in 8888 0 10.11.1.50 4524 TCP 540
      -- server allocates external IP address 195.37.70.5 and TCP port
      --   17250 and binds it to the internal transport parameter set
      --   for 300 seconds. BID=1250.
      C<-S: 231 8888 1250 195.37.70.5 17250 TCP 300
      -- request with BID=1250 for binding outer IP address
      --   134.169.34.13 and TCP port 22343 for 540 seconds
      C->S: bind_out 8889 1250 134.169.34.13 22343 TCP 540
      -- server allocates internal IP address 10.11.1.2 and TCP port
      --   5537 and binds it to the external transport parameter set
      --   for 300 seconds.
      C<-S: 232 8889 1250 10.11.1.2 5537 TCP 195.37.70.5 17250 TCP 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_in 9023 1250 10.11.1.50 4524 TCP 260
      -- request granted
      C<-S: 232 9023 1250 10.11.1.2 5537 TCP 195.37.70.5 17250 TCP 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_out 9077 1250 134.169.34.13 22343 TCP 0
      -- binding and pinhole removed
      C<-S: 233 9077 1250




Stiemerling & Quittek                                          [Page 18]


Internet-Draft    Simple NAT and Firewall Configuration    November 2001


   The last Example (f) shows the rejection of a request, because an
   illegal internal IP address is used.

   Example (f): Rejection of illegal internal IP address
      -- server is in state OPEN
      C->S: BIND_IN 458 0 102.12.12.251 1254 UDP 300
      C<-S: 432 458
      -- no new binding or pinhole established


8.  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 SNFC
   service.

   A SNFC 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 SNFC.


9.  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, <draft-ietf-midcom-framework-04.txt>,
     October 2001

[3]  Huitema, C., "MIDCOM Scenarios", Internet Draft, work in progress,
     <draft-ietf-midcom-scenarios-02.txt>, May 2001

[4]  Swale, R.P., Mart, P.A., Sijben, P., "Middlebox Control (MIDCOM)
     Protocol Architecture and Requirements", Internet Draft, work in
     progress, <draft-ietf-midcom-requirements-02.txt>, July 2001



Stiemerling & Quittek                                          [Page 19]


Internet-Draft    Simple NAT and Firewall Configuration    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


10.  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



11.  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


Stiemerling & Quittek                                          [Page 20]


Internet-Draft    Simple NAT and Firewall Configuration    November 2001


   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 21]