One document matched: draft-stiemerling-midcom-simco-03.txt
Differences from draft-stiemerling-midcom-simco-02.txt
Internet Draft M. Stiemerling
Document: draft-stiemerling-midcom-simco-03.txt J. Quittek
Expires: August 2003 NEC Europe Ltd.
February 2003
Simple Middlebox Configuration (SIMCO) Protocol Version 2.0
<draft-stiemerling-midcom-simco-03.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 (2003). 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 [4] and it
Stiemerling & Quittek [Page 1]
Internet-Draft Simple Middlebox Configuration February 2003
implements the MIDCOM semantics [3].
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
10.1 Changes ................................................... 18
10.1.1 Changes to Draft Version -02 ............................ 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 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.
Stiemerling & Quittek [Page 2]
Internet-Draft Simple Middlebox Configuration February 2003
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
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
policy rule group and section 8 explains how it can request address
bindings and pinhole configurations. Bot 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
Stiemerling & Quittek [Page 3]
Internet-Draft Simple Middlebox Configuration February 2003
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
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
Stiemerling & Quittek [Page 4]
Internet-Draft Simple Middlebox Configuration February 2003
avoids dealing with flow control issues and gives the opportunity of
using Transport Layer Security (TLS [5]) mechanism. Instead of TLS,
IPSEC [6,7] may be used as well. The protocol uses ASCII encodings,
because this simplifies documentation, implementation and debugging.
This encoding is not considered to reduce scalability significantly.
Once a SIMCO session is established, the client can request the
establishments of address bindings at a NAT controlled by the server
and the opening of pinholes at a firewall controlled by the server,
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.
To read this document it is necessary to be familiar with the MIDCOM
semantics described in [3] .
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.
Stiemerling & Quittek [Page 5]
Internet-Draft Simple Middlebox Configuration February 2003
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 )
Port = 1*5DIGIT ; TCP/UDP port
NOSP = 1*5DIGIT ; Number Of Subsequent Ports
PP = "ANY" / "EVEN" / "ODD"
; Port parity to keep
RID = 1*DIGIT ; Request ID number
OWNER = 1*5DIGIT ; Owner of Rule or Group
An IPAddress of "0.0.0.0", "::" respectively 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 0 in a `PER' or `PRR' request requests a new
policy rule group in the middlebox. Non 0 GIDs indentify an already
existing 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
Stiemerling & Quittek [Page 6]
Internet-Draft Simple Middlebox Configuration February 2003
ADR = IPAddress WSP Port ; addresses
ADR0 = ADR ; internal addresses
ADR1 = ADR ; inside addresses
ADR2 = ADR ; outside addresses
ADR3 = ADR ; external addresses
TOPOLOGY = "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
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" ; Persistent 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 =/ "GLC" WSP RID WSP GID WSP LT CRLF
; Group Lifetime Change
request =/ "GL" WSP RID CRLF
Stiemerling & Quittek [Page 7]
Internet-Draft Simple Middlebox Configuration February 2003
; 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 PP WSP LT CRLF
; Policy Rule Reservation
request =/ "PER" WSP RID WSP GID WSP PID WSP PT
WSP NOSP WSP PP WSP TOPOLOGY
WSP ADR0 WSP ADR3 WSP LT CRLF
; Policy Rule Enable
request =/ "RLC" WSP RID WSP PID WSP LT CRLF
; Policy Lifetime Change
request =/ "PRS" WSP RID WSP PID CRLF
; Policy Rule 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 for future SIMCO extensions and must be ignored by
SIMCO version 2.0 implementations.
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
Stiemerling & Quittek [Page 8]
Internet-Draft Simple Middlebox Configuration February 2003
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
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 =/ "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
; Policy Rule Control
Reply =/ "240" WSP RID WSP GID WSP PID WSP ADR1 WSP ADR2 WSP LT
CRLF
; PRR request successful, reservation done
Reply =/ "241" WSP RID WSP GID WSP PID WSP ADR1 WSP ADR2 WSP LT
CRLF
; PER request successful, policy is enabled
Reply =/ "242" WSP RID WSP LT CRLF
; RLC request successful, policy lifetime changed
Reply =/ "243" WSP RID CRLF
; RLC 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
Stiemerling & Quittek [Page 9]
Internet-Draft Simple Middlebox Configuration February 2003
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
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 ; parity 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 must be generated in this case. In the case that the
request identifier is not valid, an asychronous '510' reply must be
generated. Otherwise, the command string is checked to be valid,
Stiemerling & Quittek [Page 10]
Internet-Draft Simple Middlebox Configuration February 2003
i.e. to be one of the strings `SE', `ST', `GLC', `GL' , `GS', `PRR',
`PER', `RLC', or `PRS'. 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.
5.2. Session State Machine
The SIMCO session state machine models exactly the state machine
described in [3] Figure 1. 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 February 2003
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 must 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.4 Policy
Group Transactions. SIMCO implements this implicit group
Stiemerling & Quittek [Page 12]
Internet-Draft Simple Middlebox Configuration February 2003
establishment by using the GID parameter in the `PRR' and `PER'
requests. Is the GID in `PRR' or `PER' equal to 0, the middlebox
will establish according to [3] section 2.4, a new policy rule group.
Any other GID not equal 0 refers to an already established policy
rule group that has been created by the middlebox due to a prior
received `PRR' or `PER' request.
5.4. Policy State Machine
The policy rule behaviour is described in [3], section 2.3 Policy
Rule Transactions. The SIMCO policy state machine models exactly the
state machine described in [3] Figure 2.
When the session state machine is in state OPEN, the server accepts
further requests regarding policy rules. The state machine of a
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
- `RLC' request
- `24X' replies
- `44X' replies
- `45X' replies
- `540' reply
Stiemerling & Quittek [Page 13]
Internet-Draft Simple Middlebox Configuration February 2003
PRR/44x 45x
PER/44x 45x
+-----------+
| v
PRR/240 +-+-------------+
+-----------------+ POLICY UNUSED |<-+
+----+ | +---------------+ |
| | | ^ | |
| v v 540 | | |
| +-------------+ PER/44x 45x| | PER(pid=0) | 540
| | RESERVED +------------+ | /241 | RLC(lt=0)/
| +-+----+------+ RLC(lt=0)/ | | 243
| | | 243 | |
+----+ | v |
RLC(lt>0)/ | PER(pid!=0)/241 +---------------+ |
242 +---------------->| POLICY INUSE +--+
RLC/44x 45x +-+-------------+
| ^
+-----------+
lt = lifetime RLC(lt>0)/242
RLC/44x 45x
Figure 2: 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.
- 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 `455' reply is generated.
- The NOSP parameter is checked whether it is valid. If the check
fails, a `456' 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
Stiemerling & Quittek [Page 14]
Internet-Draft Simple Middlebox Configuration February 2003
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
--: 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
Stiemerling & Quittek [Page 15]
Internet-Draft Simple Middlebox Configuration February 2003
. . .
-- 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.
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 (c):
-- server is in state OPEN, and the middlebox is a packet filter
-- request a new policy enable rule and a new policy rule
-- group lifetime of 2000 seconds
C->S: PER 32345 0 0 TCP4 1 ANY BI 139.6.138.20 34211 195.37.70.5 80
2000
-- server allocates a new group identifier (GID) of 1, a PID 45 and
-- grants a lifetime of 1800 seconds
C<-S: 241 32345 1 45 139.6.138.20 34211 195.37.70.5 80 1800
. . .
-- The client removes the policy rule group and policy rule after
-- 1000 seconds
C->S: GLC 32400 1 0
-- policy rule group removed
C<-S: 233 32400
Stiemerling & Quittek [Page 16]
Internet-Draft Simple Middlebox Configuration February 2003
8. Controlling Policy Rules
The client can request to reserve, establish, and remove policy
rules.
Control of traditional NAT bindings and firewall pinholes is
illustrated by Example (d) showing the establishment and removal of a
uni-directional UDP binding and pinhole.
Example (d): NAT control of UDP address binding
-- server is in state OPEN.
-- request with GID=33, for inner IP address 10.11.1.45
-- and UDP port 16175 for 180 seconds
C->S: PRR 1000 33 UDP4 1 ANY 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 33 1248 0.0.0.0 0 195.37.70.5 13222 180
-- Now enable the policy rule
C->S: PER 2044 33 1248 UDP 1 ANY INBOUND
10.11.1.45 16175 139.6.138.20 4325 180
-- server enables policy rule
C<-S: 241 2044 33 1248 139.6.138.20 4325 195.37.70.5 13222
-- client removes policy rule after 100 seconds
C->S: RLC 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
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
Stiemerling & Quittek [Page 17]
Internet-Draft Simple Middlebox Configuration February 2003
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?
10.1. Changes
10.1.1. Changes to Draft Version -02
- `GE' request has been removed since the policy rule group
establishment is now implicit.
- `AGD' asynchronous notification has been removed due to change
group behaviour.
- Renamed `PLC' to `RLC' and `PS' to `PRS'.
- The SIMCO server must now return a `510' message during session
startup. This has been changed from `may' to `must'.
- A GID of 0 does not longer reference to the default group, since
default groups are not supported. A GID of 0 requests the
establishment of a entire new policy rule group.
- `435' reply deleted, due to the changed group behaviour.
- `231'reply deleted, due to the changed group behaviour.
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, <draft-ietf-midcom-
semantics-01.txt>, March 2003
Stiemerling & Quittek [Page 18]
Internet-Draft Simple Middlebox Configuration February 2003
[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
[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
Kurfuersten-Anlage 36
69115 Heidelberg
Germany
Phone: +49 6221 90511-13
Email: stiemerling@ccrle.nec.de
Juergen Quittek
NEC Europe Ltd.
Network Laboratories
Kurfuersten-Anlage 36
69115 Heidelberg
Germany
Phone: +49 6221 90511-15
EMail: quittek@ccrle.nec.de
Stiemerling & Quittek [Page 19]
Internet-Draft Simple Middlebox Configuration February 2003
13. Full Copyright Statement
Copyright (C) The Internet Society (2003). 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 February 2003
| PAFTECH AB 2003-2026 | 2026-04-26 12:57:39 |