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]