Network Working Group S. Kiesel
Internet-Draft NEC
Intended status: Informational July 6, 2009
Expires: January 7, 2010
Interaction of dynamic firewall control protocols and SIP
draft-kiesel-mmusic-firewall-sip-00.txt
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
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.
This Internet-Draft will expire on January 7, 2010.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Kiesel Expires January 7, 2010 [Page 1]
Internet-Draft Firewalls and SIP interaction July 2009
Abstract
SIP-based multimedia applications dynamically negotiate parameters
for the related media streams, such as UDP port numbers. Therefore,
firewalls that want to inspect these streams have to interact with
the session signaling. Several architectures and protocols have been
developed for the dynamic control of firewalls on the media path, e.
g., MIDCOM, SIMCO, and the NSIS NAT/FW NSLP. This document
investigates problems with the interaction of standard SIP (as of RFC
3261) and these firewall control protocols, especially with respect
to error handling. It will be pointed out how existing SIP
extensions can be used for improving the interaction, and which
additional mechanisms need to be specified. While the actual
specification of such additional mechanisms is out of the scope of
this document, it solicits feedback and discussion.
Table of Contents
1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Scope of this document . . . . . . . . . . . . . . . . . . 4
2.2. Firewall control protocol terminology . . . . . . . . . . 5
3. Behaviour under normal conditions . . . . . . . . . . . . . . 7
4. Analysis of possible error conditions . . . . . . . . . . . . 9
4.1. Impact of firewall errors on SIP . . . . . . . . . . . . . 9
4.1.1. Firewall errors at SIP session establishment . . . . . 9
4.1.2. Firewall errors during existing SIP session . . . . . 13
4.2. Impact of SIP errors on firewall control . . . . . . . . . 14
5. Specification of mechanisms for proposed solution . . . . . . 15
5.1. SIP response code firewall failure . . . . . . . . . . . . 15
5.2. Firewall Precondition for SDP Media Streams . . . . . . . 15
5.3. Summary of required SIP extensions . . . . . . . . . . . . 16
6. Security Considerations . . . . . . . . . . . . . . . . . . . 17
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
8.1. Normative References . . . . . . . . . . . . . . . . . . . 19
8.2. Informative References . . . . . . . . . . . . . . . . . . 19
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 21
Kiesel Expires January 7, 2010 [Page 2]
Internet-Draft Firewalls and SIP interaction July 2009
1. Requirements notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Kiesel Expires January 7, 2010 [Page 3]
Internet-Draft Firewalls and SIP interaction July 2009
2. Introduction
Multimedia communication requires the exchange of signaling
information for call/session control, as well as the transport of the
actual user data (e. g., speech). Often, different protocols are
used for these two tasks. In the following, we assume that SIP/SDP
[RFC3261] is used for the signaling and RTP/RTCP [RFC3550][RFC3551]
is used for the media transport. Separate UDP or TCP flows are used
for conveying the messages of these protocols. Parameters for the
RTP streams, including end point IP addresses and port numbers are
negotiated dynamically using SDP messages embedded in the SIP
signaling. In many scenarios the SIP signaling messages travel along
a different path through the network (e. g., via proxies) than the
RTP media streams do (e. g., directly between the terminals).
A firewall is one or a group of network elements that enforce an
access control policy on the traffic at the border between network
domains with different security levels and requirements.
Specifically, both signaling traffic and media streams have to be
checked. The corresponding logical functions of the firewall will be
referred to as signaling component and media component, respectively.
How the signaling component decides whether to accept a SIP INVITE
message that tries to establish a new session is out of the scope of
this document. Once the signaling component has accepted a new call
the media component must be informed that the corresponding media
streams are allowed to pass the firewall.
Several architectures and protocols have been specified to control
the media compontent of a firewall, e. g., MIDCOM [RFC3303] [RFC5189]
[RFC5190] and SIMCO [RFC4540], the NSIS NAT/FW NSLP [RFC4080]
[I-D.ietf-nsis-nslp-natfw], etc. However, although support for SIP
based multimedia communications is one of the key motivations for
these protocols, the interaction between SIP an these firewall
control protocols has not been described in detail by an IETF
document so far.
2.1. Scope of this document
This document considers scenarios where the media component of the
firewall (i. e., the logical entity that inspects RTP media streams)
is controlled by a SIP entity, which is not the SIP endpoint, e.g., a
B2BUA. This is a typical usage scenario for MIDCOM (see Fig. 3 of
[RFC3303]) and similar path-decoupled firewall signaling
architectures. The same problems arise if path-coupled firewall
signaling is used only on parts of the end-to-end RTP path (e. g.,
using NSIS NAT/FW NSLP, see Fig. 2 of [RFC4080]).
Kiesel Expires January 7, 2010 [Page 4]
Internet-Draft Firewalls and SIP interaction July 2009
_________
--->| SIP |<-----\
/ | B2BUA | \
| |_________| |
1| |^ ^| 4|
| || || |
|8 2||3 7||6 |5
______________ | || || | _____________
| |<-/ _v|____|v___ \->| |
| External | Na | | Nc | SIP Phone |
| SIP phone |>------->| Middlebox |>------>| within |
| |<-------<|___________|<------<| Pvt. domain|
|____________| Nb Nd |____________|
Figure 1: MIDCOM framework with SIP (Fig. 3 of RFC 3303, corrected:
SIP proxy replaced with B2BUA)
Proxy1 Proxy2
+------+ +----+ +----+ +----+ +----+ +--------+
|Sender|-...->|Appl|--->| R |--->| R |--->|Appl|-...->|Receiver|
| | |+--+| |+--+| |+--+| |+--+| | |
+------+ ||NE||====||NE||====||NE||====||NE|| +--------+
|+--+| |+--+| |+--+| |+--+|
+----+ +----+ +----+ +----+
+--+
|NE| = NSIS ==== = Signaling ---> = Data flow messages
+--+ Entity Messages (unidirectional)
Appl = signaling application
Figure 2: On path NSIS proxy (Fig. 2 of RFC 4080)
2.2. Firewall control protocol terminology
In the following sections, the terminology and message names of the
MIDCOM architecture [RFC3303] and protocol [RFC5189] will be used.
However, the identified problems and proposed solutions apply to
other firewall control architectures and protocols as well.
Specifically, the MIDCOM "PER" (Policy Enable Rule) message is used
for requesting the firewall to open a "pinhole", which allows traffic
to flow through the firewall if it matches the filter criteria given
as parameters of the PER message. The firewall answers with a "PER
PR" (PER Positive Reply) message if it was able to open the requested
Kiesel Expires January 7, 2010 [Page 5]
Internet-Draft Firewalls and SIP interaction July 2009
pinhole, otherwise with a "PER NR" (PER Negative Reply) message.
If an existing pinhole is removed from the firewall at the request of
an authorized third party, the original creator is informed by means
of an "ARE" (Asynchronous Rule Event) message.
Kiesel Expires January 7, 2010 [Page 6]
Internet-Draft Firewalls and SIP interaction July 2009
3. Behaviour under normal conditions
Figure 3 shows a message sequence chart of the interaction between
SIP session signaling and firewall control in the error free case,
assuming the scenario as depicted in Figure 1. This message sequence
chart has also been depicted in Section 7.1 of [RFC3303] (with
slightly different notation). However, it will be shown later that
this straightforward way of interaction will cause problems under
error conditions.
Two pinholes are required to admit the media streams related to a
session, one per direction. The INVITE message contains information
(SDP_A) about the address at which the calling party is waiting for
incoming media streams. As soon as the INVITE message reaches the
B2BUA, the first PER transaction is issued to open a pinhole that
allows media to the calling party. The second PER request is sent by
the B2BUA upon reception of the 200 OK message, when the called party
has already picked up the receiver and the conversation is about to
start.
When either party indicates the session end by sending a SIP BYE
message, the pinholes are removed from the firewall by means of PLC
(Policy Lifetime Change) transactions, which set the remaining
lifetime of the pinholes to zero.
Kiesel Expires January 7, 2010 [Page 7]
Internet-Draft Firewalls and SIP interaction July 2009
Calling SIP B2BUA Middlebox Called
SIP Phone (MIDCOM agent) (Firewall) SIP Phone
| | | |
|--INVITE+SDP_A-->| | |
|<-100 Trying-----| | |
| | | |
| |+++++PER(SDP_A)++++++>| |
| |<++++PER PR(PID_A)++++| |
| | | |
|<=-=-=-=-=-=-=-=-=-=RTP/RTCP=-=-=-=-=-=-=-=-=... |
| | | |
| |-----INVITE+SDP_A------------------->| phone
| |<----180 Ringing---------------------| rings
|<--180 Ringing---| | |
| | | |
| | | | B goes
| |<----200 OK+SDP_B--------------------| off-hook
| | | |
| |+++++PER(SDP_B)++++++>| |
| |<++++PER PR(PID_B)++++| |
|<--200 OK+SDP_B--| | |
|-------ACK------>| | |
| |-----------ACK---------------------->|
| | | |
|<===================RTP/RTCP==========================>|
| | | |
|------BYE------->| | |
| |-----BYE---------------------------->|
| |<----200 OK -------------------------|
| | | |
| |+++++PLC(PID_A,LT=0)+>| |
| |<++++PLC PR(PID_A)++++| |
| | | |
| |+++++PLC(PID_B,LT=0)+>| |
| |<++++PLC PR(PID_B)++++| |
|<--200 OK--------| | |
| | | |
Legend: ++++ MIDCOM control traffic
---- SIP control traffic
<=-= RTP/RTCP media traffic (early media)
<==> RTP/RTCP media traffic (two-way)
Figure 3: MIDCOM / SIP interaction: error free session setup and
teardown
Kiesel Expires January 7, 2010 [Page 8]
Internet-Draft Firewalls and SIP interaction July 2009
4. Analysis of possible error conditions
This section investigates possible error conditions in the same
scenario as shown in the previous section. For now, it is assumed
that session signaling uses SIP as of [RFC3261], with no additional
protocol mechanisms. Later, such SIP extensions will be proposed to
mitigate the problems.
4.1. Impact of firewall errors on SIP
The basic problem in this error category is that the required
pinholes in the firewall cannot be opened, or that they will be
closed prematurely, before the normal session end. In these cases,
the session should not be established or it should be terminated
gracefully, and the users should be informed about the problem with a
reasonable error message.
4.1.1. Firewall errors at SIP session establishment
A PER request to open a new pinhole may fail for various reasons,
which fall into two classes:
o Technical errors, e. g., resource shortage at the firewall or
problems with the signaling association to it. These problems are
usually temporary effects, i. e., it may be worthwhile to retry
the call later.
o Violation of other policies that have higher precedence. See, for
example, the "Policy Interface" of [RFC3303] or the "PDR"
transaction in SIMCO [RFC4540]. This situation may be permanent,
e. g., due to static policies, or temporary, e. g., if a network
intrusion detection system believes that the network is already
under attack and no additional pinholes should be opened.
In some cases the middlebox may indicate why the request failed, e.
g., in the PER NR message.
In the following, the same basic scenario as in the previous good-
case (see Figure 3) will be assumed. If the transsaction for opening
the first pinhole fails, the call flow is straightforward (see
Figure 4). An error message indicating that firewall configuration
failed is returned to the calling user agent in response to the
INVITE message. For a discussion which SIP response code to use, see
Section 5.1.
Kiesel Expires January 7, 2010 [Page 9]
Internet-Draft Firewalls and SIP interaction July 2009
Calling SIP B2BUA Middlebox Called
SIP Phone (MIDCOM agent) (Firewall) SIP Phone
| | | |
|--INVITE+SDP_A-->| | |
|<-100 Trying-----| | |
| | | |
| |+++++PER(SDP_A)++++++>| | Firewall
| |<++++PER NR+++++++++++| | config
|<--5xx FW Error--| | | FAILED!
| | | |
Legend: ++++ MIDCOM control traffic
---- SIP control traffic
<=-= RTP/RTCP media traffic (early media)
<==> RTP/RTCP media traffic (two-way)
Figure 4: MIDCOM / SIP interaction: failure opening the first pinhole
The situation becomes more difficult if the second PER transaction
fails. From a SIP perspective, the calling party will be sent a
negative response to their INVITE, as above. Regarding the called
party, it is no longer possible for the B2BUA to abort the session
setup (e. g., by sending a CANCEL message), as the calling party has
already sent a final response (200) to the INVITE and assumes the
session to be established. In order to remove this session state
gracefully the B2BUA can send an ACK message immediately followed by
a BYE message.
However, the error occurs only after the called SIP phone has already
alerted its user and the session has been accepted. Therefore, from
the called user's perspective it looks like the calling party has
terminated the session immediately after it had been accepted. The
B2BUA should include a reason header [RFC3326] with the same error
code as above in the BYE message, in order to inform the called user
that this disturbing "ghost ring" was due to technical problems and
not caused intentionally by the calling party. Finally, the already
configured other pinhole has to be removed by means of a PLC
transaction (see Figure 5).
Even with the reason header, disturbing the called party with "ghost
rings" is unsatisfactory. One possible solution is the use of
preconditions, as outlined in [RFC3312] and [RFC4032], which specify
the integration of resource management and SIP. Indeed, from a
syntactical perspective, firewall control has similar issues as
resource control. However, the conditions whether a session is
admitted may be very different.
Kiesel Expires January 7, 2010 [Page 10]
Internet-Draft Firewalls and SIP interaction July 2009
Figure 6 and Figure 7 show call flows when using this mechanisms for
the successful case and when the second PER transaction fails,
respectively. The differences between the SDP messages SDP_A and
SDP_A1, or SDP_B and SDP_B1, respectively, will be explained in
Section 5.2.
Calling SIP B2BUA Middlebox Called
SIP Phone (MIDCOM agent) (Firewall) SIP Phone
| | | |
|--INVITE+SDP_A-->| | |
|<-100 Trying-----| | |
| | | |
| |+++++PER(SDP_A)++++++>| |
| |<++++PER PR(PID_A)++++| |
| | | |
|<=-=-=-=-=-=-=-=-=-=RTP/RTCP=-=-=-=-=-=-=-=-=... |
| | | |
| |-----INVITE+SDP_A------------------->| phone
| |<----180 Ringing---------------------| rings
|<--180 Ringing---| | |
| | | |
| | | | B goes
| |<----200 OK+SDP_B--------------------| off-hook
| | | |
| |+++++PER(SDP_B)++++++>| | Firewall
| |<++++PER NR+++++++++++| | config
|<--5xx FW Error--| | | FAILED!
| | | |
| |-----ACK---------------------------->| line
| |-----BYE (Reason: 5xx FW Error)----->| is dead
| |<----200 OK -------------------------|
| | | |
| |+++++PLC(PID_A,LT=0)+>| |
| |<++++PLC PR(PID_A)++++| |
| | | |
Legend: ++++ MIDCOM control traffic
---- SIP control traffic
<=-= RTP/RTCP media traffic (early media)
<==> RTP/RTCP media traffic (two-way)
Figure 5: MIDCOM / SIP interaction: ghost ring
Kiesel Expires January 7, 2010 [Page 11]
Internet-Draft Firewalls and SIP interaction July 2009
Calling SIP B2BUA Middlebox Called
SIP Phone (MIDCOM agent) (Firewall) SIP Phone
| | | |
|--INVITE+SDP_A-->| | |
| |+++++PER(SDP_A)++++++>| |
| |<++++PER PR(PID_A)++++| |
| | | |
|<=-=-=-=-=-=-=-=-=-=RTP/RTCP=-=-=-=-=-=-=-=-=... |
| | | |
| |-----INVITE+SDP_A------------------->| not yet
| |<----183 Session Progress+SDP_B------| ringing!
| | | |
| |+++++PER(SDP_B)++++++>| |
| |<++++PER PR(PID_B)++++| |
|<-183 SPro+SDP_B-| | |
|--PRACK--------->| | |
| |-----PRACK-------------------------->|
| |<----200 OK (PRACK)------------------|
|<-200 OK (PRACK)-| | |
|--UPDATE+SDP_A1->| | |
| |-----UPDATE+SDP_A1------------------>|
| |<----200 OK (UPDATE)+SDP_B1----------|
|<-200 OK (UPD.)--| | | phone
| |<----180 Ringing---------------------| rings
|<--180 Ringing---| | |
|--PRACK--------->| | |
| |-----PRACK-------------------------->|
| |<----200 OK (PRACK)------------------|
|<-200 OK (PRACK)-| | |
| | | |
| | | | B goes
| |<----200 OK (INVITE)-----------------| off-hook
|<-200 OK(INVITE)-| | |
|-------ACK------>| | |
| |-----------ACK---------------------->|
| | | |
|<===================RTP/RTCP==========================>|
| | | |
Legend: ++++ MIDCOM control traffic
---- SIP control traffic
<=-= RTP/RTCP media traffic (early media)
<==> RTP/RTCP media traffic (two-way)
Figure 6: MIDCOM / SIP interaction: successful session setup with
preconditions
Kiesel Expires January 7, 2010 [Page 12]
Internet-Draft Firewalls and SIP interaction July 2009
Calling SIP B2BUA Middlebox Called
SIP Phone (MIDCOM agent) (Firewall) SIP Phone
| | | |
|--INVITE+SDP_A-->| | |
| |+++++PER(SDP_A)++++++>| |
| |<++++PER PR(PID_A)++++| |
| | | |
|<=-=-=-=-=-=-=-=-=-=RTP/RTCP=-=-=-=-=-=-=-=-=... |
| | | |
| |-----INVITE+SDP_A------------------->| not yet
| |<----183 Session Progress+SDP_B------| ringing!
| | | |
| |+++++PER(SDP_B)++++++>| | Firewall
| |<++++PER NR+++++++++++| | config
|<--5xx FW Error--| | | FAILED!
| |-----CANCEL (Reason: 5xx FW Error)-->|
| |<----487 Request Terminated----------|
| | | |
| |+++++PLC(PID_A,LT=0)+>| |
| |<++++PLC PR(PID_A)++++| |
| | | |
Legend: ++++ MIDCOM control traffic
---- SIP control traffic
<=-= RTP/RTCP media traffic (early media)
<==> RTP/RTCP media traffic (two-way)
Figure 7: MIDCOM / SIP interaction: unsuccessful session setup with
preconditions
4.1.2. Firewall errors during existing SIP session
An existing pinhole may be closed at the discretion of the firewall
at any time, e. g., because a network intrusion detection system
considers the corresponding flows harmful. The "owner" that
requested the pinhole is informed by means of an ARE (Asynchronous
Rule Event) message. A similar situation occurs if pinholes are
softstate and a transaction for extending their lifetime fails. If
the media stream, which can no longer flow through the now closed
pinhole, is crucial to the session the B2BUA may terminate the
session by sending BYE messages to both parties. Again, it should
include a reason header, to inform that the session was terminated
due to technical problems and not at the request of the other party.
Any other pinhole belonging to that session should be closed by the
B2BUA (see Figure 8).
Kiesel Expires January 7, 2010 [Page 13]
Internet-Draft Firewalls and SIP interaction July 2009
Calling SIP B2BUA Middlebox Called
SIP Phone (MIDCOM agent) (Firewall) SIP Phone
| | | |
|<===================RTP/RTCP==========================>|
| | | |
| |<+++ARE(PID_B,LT=0)+++| |
| | | |
| |-----BYE (Reason: 5xx FW Error)----->|
| |<----200 OK -------------------------|
|<-BYE (Rsn:5xx)--| | |
|--200 OK-------->| | |
| | | |
| |+++++PLC(PID_A,LT=0)+>| |
| |<++++PLC PR(PID_A)++++| |
| | | |
Legend: ++++ MIDCOM control traffic
---- SIP control traffic
<=-= RTP/RTCP media traffic (early media)
<==> RTP/RTCP media traffic (two-way)
Figure 8: MIDCOM / SIP interaction: early closing of a pinhole
4.2. Impact of SIP errors on firewall control
The signaling component in the considered scenario needs to be
session stateful, e. g., a session stateful SIP B2BUA. Usually, SIP
creates a hard state in the B2BUA, i. e., the B2BUA assumes the
session to be active until a BYE or similar message is received.
However, due to network connectivity problems or software failures at
another SIP entity, this graceful session termination may never
occur, leaving stale state information at the B2BUA and open pinholes
in the media component. Eventually, it may happen that new sessions
cannot be established because resources in the B2BUA or in the media
component are exhausted due to these stale sessions.
The signaling component must consider SIP sessions as soft state, i.
e., it must use additional SIP mechanisms such as the keepalive
mechanism described in [RFC4028] to detect whether a SIP session is
still intended to be active. If the signaling component detects that
a session has terminated abnormally it must remove all corresponding
pinholes from the media component and delete state information.
Kiesel Expires January 7, 2010 [Page 14]
Internet-Draft Firewalls and SIP interaction July 2009
5. Specification of mechanisms for proposed solution
5.1. SIP response code firewall failure
The configuration of pinholes in the media component may fail for
various reasons:
o Temporary technical problems, e. g., resource shortage at the
media component or connectivity problems with the signaling
association
o Requested pinholes conflict with static policy
o Requested pinholes conflict with temporary policy, e. g., issued
by network intrusion detection system
These error conditions have to be indicated to the SIP user agents by
means of SIP Response Codes, which are registered with IANA
[iana.sip-response-codes]. TBD: Whether the different firewall error
conditions should be mapped to existing error codes, or whether one
or several new, firewall-specific SIP response codes should be
registered with IANA is subject to further discussion.
5.2. Firewall Precondition for SDP Media Streams
The Session Description Protocol Preconditions mechanism, defined in
[RFC3312] as updated by [RFC4032], allows to specify conditions,
which have to be satisfied for a given media stream in order for
session establishment or modification to proceed. That way, annoying
"ghost rings" can be avoided, i. e., situations in which it turns out
that a new multimedia session cannot be established only after the
called party has already been alerted (e.g., by a ringing phone). In
addition to the generic framework, [RFC3312] also defines the
Quality-of-Service (QoS) precondition, which can be used to ensure
availability of network resources prior to alerting the called party.
Further preconditions can be registered with IANA
[iana.sip-precond-types], e.g., the Security Precondition [RFC5027],
which can be used to ensure the availability of kryptrographic keys
at the endpoints, which are required for the desired encryption of a
media stream.
Similar to this, a new Firewall Precondition (proposed string: "fw"),
should be specified and registered with IANA.
Note that a normative specification of the firewall precondition is
out of the scope of this document and will be done in a separate
document, as IANA registration requires a standards-track RFC while
most of the content in this document is of informational nature.
Kiesel Expires January 7, 2010 [Page 15]
Internet-Draft Firewalls and SIP interaction July 2009
However, some properties of this firewall precondition will be
described here until a first version of the normative specification
is published:
The firewall precondition must always be used in conjunction with the
"end-to-end" status defined in the Preconditions framework,
indicating that all firewalls on the media path between the endpoints
have to be (or have been, respectively) configured to allow the
respective media stream. Usage of the firewall precondition in
conjunction with the "segmented" status type is unspecified. The
firewall precondition can be used with the strength-tag "mandatory"
(i.e., all firewalls have to be configured successfully before the
session establishment can proceed) or "none" (used by a user agent to
indicate that the precondition is supported in principle, but not
requested for this specific media stream).
5.3. Summary of required SIP extensions
The following list summarizes SIP mechanisms which go beyond the
scope of [RFC3261] and may help to avoid the problems analyzed in the
previous section:
o SIP Reason header field [RFC3326]
o One or several SIP response codes for indicating firewall
configuration problems (see Section 5.1)
o SIP Preconditions Framework [RFC3312][RFC4032]
o Firewall Preconditions for Session Description Protocol (SDP)
Media Streams (see Section 5.2)
o SIP Session Timers [RFC4028]
Kiesel Expires January 7, 2010 [Page 16]
Internet-Draft Firewalls and SIP interaction July 2009
6. Security Considerations
Firewalls are a widely deployed means for securing network
interconnections. The usage of SIP for establishing multimedia
sessions often requires a more dynamic control of these firewalls.
This document analyzes possible error conditions and proposes
additional mechanisms for handling them reasonably. It is assumed
that these additional mechanisms (e. g., error codes) as such do not
introduce new security issues. However, the overall solution has to
be thoroughly analyzed for possible security vulnerabilites, taking
into account the specific protocol that has been chosen for firewall
control.
Kiesel Expires January 7, 2010 [Page 17]
Internet-Draft Firewalls and SIP interaction July 2009
7. IANA Considerations
This document describes several error conditions that may occur when
firewalls are present on the RTP media path. These errors have to be
indicated to the SIP user agents by means of appropriate SIP Response
Codes (see Section 5.1). Whether existing response codes should be
re-used, or whether one or several new, firewall-specific SIP
Response Codes should be registered with IANA in the SIP Response
Code Registry [iana.sip-response-codes] is subject to further
discussion.
This document proposes the specification of a new "Firewall
Precondition" type for SIP and its registration with IANA in the SIP
precondition types registry [iana.sip-precond-types]. However, the
actual specification of this precondition is out of the scope of this
document and should be done in a separate document.
Kiesel Expires January 7, 2010 [Page 18]
Internet-Draft Firewalls and SIP interaction July 2009
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
[RFC3312] Camarillo, G., Marshall, W., and J. Rosenberg,
"Integration of Resource Management and Session Initiation
Protocol (SIP)", RFC 3312, October 2002.
[RFC3326] Schulzrinne, H., Oran, D., and G. Camarillo, "The Reason
Header Field for the Session Initiation Protocol (SIP)",
RFC 3326, December 2002.
[RFC4028] Donovan, S. and J. Rosenberg, "Session Timers in the
Session Initiation Protocol (SIP)", RFC 4028, April 2005.
[RFC4032] Camarillo, G. and P. Kyzivat, "Update to the Session
Initiation Protocol (SIP) Preconditions Framework",
RFC 4032, March 2005.
[iana.sip-precond-types]
Internet Assigned Numbers Authority (IANA), "Precondition
Types used with Session Initiation Protocol (SIP)", Web
Site http://www.iana.org/assignments/sip-precond-types,
August 2002.
[iana.sip-response-codes]
Internet Assigned Numbers Authority (IANA), "SIP Response
Codes Registry", Web
Site http://www.iana.org/assignments/sip-parameters,
June 2002.
8.2. Informative References
[I-D.ietf-nsis-nslp-natfw]
Stiemerling, M., Tschofenig, H., Aoun, C., and E. Davies,
"NAT/Firewall NSIS Signaling Layer Protocol (NSLP)",
draft-ietf-nsis-nslp-natfw-18 (work in progress),
February 2008.
[RFC3303] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A., and
Kiesel Expires January 7, 2010 [Page 19]
Internet-Draft Firewalls and SIP interaction July 2009
A. Rayhan, "Middlebox communication architecture and
framework", RFC 3303, August 2002.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003.
[RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and
Video Conferences with Minimal Control", STD 65, RFC 3551,
July 2003.
[RFC4080] Hancock, R., Karagiannis, G., Loughney, J., and S. Van den
Bosch, "Next Steps in Signaling (NSIS): Framework",
RFC 4080, June 2005.
[RFC4540] Stiemerling, M., Quittek, J., and C. Cadar, "NEC's Simple
Middlebox Configuration (SIMCO) Protocol Version 3.0",
RFC 4540, May 2006.
[RFC5027] Andreasen, F. and D. Wing, "Security Preconditions for
Session Description Protocol (SDP) Media Streams",
RFC 5027, October 2007.
[RFC5189] Stiemerling, M., Quittek, J., and T. Taylor, "Middlebox
Communication (MIDCOM) Protocol Semantics", RFC 5189,
March 2008.
[RFC5190] Quittek, J., Stiemerling, M., and P. Srisuresh,
"Definitions of Managed Objects for Middlebox
Communication", RFC 5190, March 2008.
Kiesel Expires January 7, 2010 [Page 20]
Internet-Draft Firewalls and SIP interaction July 2009
Author's Address
Sebastian Kiesel
NEC Europe Ltd.
Kurfuersten-Anlage 36
Heidelberg 69115
Germany
Phone: +49 6221 4342 232
Email: sebastian.kiesel@nw.neclab.eu
Kiesel Expires January 7, 2010 [Page 21]