SIP Protocol Agent Overview

StoneGate Firewall/VPN
SIP Protocol Agent Overview
Created: October 6, 2008

Table of Contents
Protocol Overview ............................................................................................................................ 2
Communication Model ..................................................................................................................... 2
Protocol Agent Description ............................................................................................................... 3
Operation .......................................................................................................................... 3
Supported SIP Methods ...................................................................................................... 3
Supported SIP Message Body Types .................................................................................... 4
Supported SDP Offer/Answer Exchanges .............................................................................. 4
SIP Header Fields and SDP Fields Modified for NAT Traversal ................................................ 4
Limitations ...................................................................................................................................... 5
Only UDP and TCP Transports Are Supported ........................................................................ 5
SDP Offer/Answer Exchanges with PRACK or UPDATE Methods Are Not Supported .................. 5
Limited Support for SIP Instant Messaging and Presence ...................................................... 5
Complex SIP Call Scenarios Might Not Be Handled Correctly .................................................. 5
Configuration .................................................................................................................................. 6

Protocol Overview
SIP (Session Initiation Protocol) is an application-layer control protocol that can establish, modify and terminate
multimedia sessions such as Internet telephony calls. SIP is designed and standardized by the IETF, and its base
protocol is specified in RFC 3261. Various extensions to the base protocol are defined in other RFC documents.
SIP is a text-based protocol, in which the protocol messages have a set of header fields followed by an optional
message body like in, for example, HTTP and SMTP protocols. The message body can contain various kinds of
application payloads. For real-time voice or multimedia communication management the SIP messages typically
contain SDP (Session Description Protocol, RFC 4566) payloads.
Communication Model
The communication model of SIP is more complex than the ordinary client-server paradigm used for typical
Internet protocols such as HTTP. The SIP elements such as User Agents and Proxies have both client and server
capabilities, and act in one or both of those roles depending on the particular call case in question.
The SIP message exchange can use various transport protocols, most typically TCP or UDP over IPv4 or IPv6. The
real-time multimedia sessions managed by SIP use RTP (Real Time Protocol) packets over UDP. The parameters
of the RTP packet streams are negotiated between the call end-points by using SDP payloads within SIP message
bodies. These RTP/UDP connections take different route through the IP network than the SIP message exchange;
most typically the RTP/UDP streams are routed directly between the call end-points (SIP User Agents). The
negotiated RTP/UDP connections are called related connections in this document.
SIP
SIP Proxy
SIP
SIP Proxy
SIP
SIP User Agent
RTP
SIP User Agent
The related connections do not use any well known port numbers, and therefore it is difficult to allow them
through a firewall without opening a wide range of UDP ports in the security policy. The SIP Protocol Agent in the
StoneGate Firewall can be used to dynamically open the related connections through the Firewall without using
static Access Rules for them.
2 StoneGate Firewall/VPN SIP Protocol Agent Overview

Protocol Agent Description
This document refers to the SIP Protocol Agent delivered with StoneGate Engine versions 4.3 and later.
Operation
The purpose of the SIP Protocol Agent is to allow SIP calls to pass through the firewall. The Protocol Agent has to
be attached to the SIP connection of the new call. The Protocol Agent interprets the SIP message exchange and
allows dynamic RTP and RTCP connections to open based on port negotiations within the parent connection.
When a NAT is applied to the SIP connection, the Protocol Agent tries to perform the same NAT operation to these
related connections and modify payload data of the parent connection.
The SIP Protocol Agent also checks the SIP message syntax for protocol anomalies and looks for known attack
vectors using SIP fingerprints delivered by Stonesoft in dynamic update packages.
The SIP Protocol Agent in StoneGate Firewall works transparently in the sense that the SIP elements such as User
Agents and Proxies are not aware of its presence. In particular, the Firewall’s IP address is never configured to
the other SIP elements, that is, it does not act as a SIP proxy or registrar server. Instead, the SIP Protocol Agent
interprets the SIP protocol messages while they are being routed through the Firewall, maintains protocol state to
the extent required, and modifies the messages slightly if necessary for NAT traversal. It does not add new SIP
Header Fields to the messages or create SIP messages of its own.
Supported SIP Methods
The following table shows which SIP request methods are recognized by the SIP Protocol Agent. Message
modification for NAT is done to the requests with a recognized method, and to their responses. The table also
shows the request methods and responses in which SDP bodies are interpreted by the PA. Note, that SIP
message exchanges where PRACK or UPDATE request or the corresponding response contains SDP are not
currently supported.
Method Reference Recognized
SDP handled in
the request
SDP handled
in responses
ACK RFC 3261 Yes Yes
BYE RFC 3261 Yes
CANCEL RFC 3261 Yes
INFO RFC 2976 Yes
INVITE RFC 3261 Yes Yes 1xx, 2xx
MESSAGE RFC 3428 Yes
NOTIFY RFC 3265 Yes
OPTIONS RFC 3261 Yes
PRACK RFC 3262 Yes No No
PUBLISH RFC 3903 Yes
REFER RFC 3515 Yes
3 StoneGate Firewall/VPN SIP Protocol Agent Overview

REGISTER RFC 3261 Yes
SUBSCRIBE RFC 3265 Yes
UPDATE RFC 3311 Yes No No
Supported SIP Message Body Types
SIP messages can contain a message body of several different types, but the SIP Protocol Agent only interprets
message bodies whose Content-Type is application/sdp, which is defined in RFC 4566. The contents of such
message bodies are used to open the related media connections, and the IP addresses and ports in the body are
modified as necessary for NAT traversal.
Other body types are passed without examination, and possible IP addresses in them are not modified. Also
Multipart MIME bodies are not examined, even if there is a part with content type application/sdp.
Supported SDP Offer/Answer Exchanges
The parameters of the related connections are negotiated between the call end-points using the so-called SDP
Offer/Answer model, which is specified in RFC 3264. The following table describes which SIP message exchanges
are supported by the SIP Protocol Agent for carrying the SDP Offer and Answer.
Offer Answer Reference Supported
INVITE request 2xx INVITE response RFC 3261 Yes
2xx INVITE response ACK request RFC 3261 Yes
INVITE request 1xx INVITE response RFC 3262 Yes
1xx INVITE response PRACK request RFC 3262 No
PRACK request 200 PRACK response RFC 3262 No
UPDATE request 2xx UPDATE response RFC 3311 No
SIP Header Fields and SDP Fields Modified for NAT Traversal
SIP messages carry IP address and port numbers both in the message headers and in the message body. The SIP
Protocol Agent examines certain SIP Header Fields, as well as the SDP bodies in SIP protocol messages, and
modifies the embedded IP address and port numbers using the same NAT rules that are applied to the transport
connection (UDP or TCP) carrying the SIP protocol messages. These rules are configured in the NAT Rules tab of
the Firewall’s security policy in the StoneGate Management Center.
The IP address and port numbers within SIP Header Fields are primarily used for routing the responses back to
where the request originated, and for announcing a contact address where further requests can be sent. The
following SIP Header Field are examined and modified, if necessary:
4 StoneGate Firewall/VPN SIP Protocol Agent Overview

• Request URI
• From:
• To:
• Via:
• Contact:
• Record-Route:
The IP addresses and port numbers in SDP message bodies show where the SIP entity is prepared to receive
media. The following SDP lines are examined and modified if necessary:
• m=
• c=
Limitations
Only UDP and TCP Transports Are Supported
The SIP Protocol Agent is not able to interpret SIP traffic over SSL or TLS transports since the messages are
encrypted.
The SIP Protocol Agent does not support SIP over SCTP (Stream Control Transmission Protocol) transport.
SDP Offer/Answer Exchanges with PRACK or UPDATE Methods Are Not Supported
In some SIP environments the PRACK and/or UDPATE request methods are used to carry SDP offers or answers
within a SIP dialog. However, the SIP Protocol Agent does not examine the SDP body in those requests and their
answers.
The PRACK method is usually used without SDP body, and in that case there is no problem. The UPDATE method,
on the other hand, is specifically used to update SDP information, and the call most likely fails in this case.
Fortunately the use of the UPDATE method is quite rare. A so-called re-INVITE is more common for updating
connection parameters and is supported by the SIP Protocol Agent.
Limited Support for SIP Instant Messaging and Presence
The SIP protocol can be used for instant messaging and presence applications with the SIP/SIMPLE protocol
extensions (defined in multiple RFC documents). The SIP Protocol Agent recognizes the SIP request methods
MESSAGE, PUBLISH, SUBSCRIBE and NOTIFY, and supports NAT modifications to the message header fields in
them.
However, the various types of message bodies possibly contained in these messages are not interpreted and
modified, even if the Content-Type is application/sdp. Also, no related connections are opened based on
these SIP request methods.
Complex SIP Call Scenarios Might Not Be Handled Correctly
The SIP Protocol Agent makes decisions about related connection management based on the SIP messages it
sees. However, in certain complex call scenarios it may fail to make correct decisions, either because it does not
have sufficient information, or because it’s internal logic is not intelligent enough.
One case where the SIP Protocol Agent may have trouble deciding correct actions is when the SIP signaling for a
call crosses the Firewall more than once. For example, if there are two SIP phones in the internal network and one
5 StoneGate Firewall/VPN SIP Protocol Agent Overview

or both of them use a SIP proxy in an external network, the call signaling between the phones goes from internal
to external network and then back to internal network, crossing the Firewall twice. The SIP Protocol Agent is able
to detect this if the signaling visits only one SIP entity in the external network, but fails to detect it if there are, for
example, multiple SIP proxies visited in the external network. When the situation is detected, the SIP Protocol
Agent correctly creates just one call and does not do unnecessary NAT translations for the related connections.
Configuration
The following table describes the parameters of the SIP Protocol Agent. They can be configured in the Protocol
Parameters tab of a Service Element that defines SIP in its Protocol field.
Parameter Values Description
Allow Related Connections
Enforce Client Side Media
Enforce Server Side Media
Maximum Number Of Calls
On (default) / Off
Yes (default) / No
Yes (default) / No
0 (default) /
positive integer
Allows the SIP media connections based on the signaling
connection.
Allows checking that the media stream used over SIP uses the
same address as the SIP traffic on the host that is the ‘client’
in SIP communications.
Allows checking that the media stream used over SIP uses the
same address as the SIP traffic on the host that is the ‘server’
in SIP communications.
Maximum number of concurrent SIP calls allowed by the
Access Rule. Value 0 means unlimited.
The following table describes the generic SIP situations. They can be used in the Inspection Rules to configure
logging of SIP events and to define actions when protocol violations are detected.
Situation
Description
SIP_Call-Established
SIP_Call-Hangup
SIP_Message-Handled
SIP_Message-No-
Transaction
SIP_Message-Parse-Error
SIP_Method-NNN
SIP_Method-Unknow
SIP phone call established.
SIP phone call hang up.
A SIP message successfully parsed and handled.
A SIP message not belonging to any existing transaction was seen.
SIP message processing failed because of a parse error.
The SIP request method NNN was seen in a SIP request (one situation for each
supported SIP request method NNN).
The SIP request method seen in a SIP request was unknown.
In addition to the generic SIP situations there are SIP fingerprint situations for detecting known attack vectors
within SIP packets. Custom fingerprint situations can be created as well in the StoneGate Management Center.
6 StoneGate Firewall/VPN SIP Protocol Agent Overview

Copyright and Disclaimer
© 2000—2008 Stonesoft Corporation. All rights reserved.
These materials, Stonesoft products, and related documentation are protected by copyright and other laws, international
treaties and conventions. All rights, title and interest in the materials, Stonesoft products and related documentation shall
remain with Stonesoft and its licensors. All registered or unregistered trademarks in these materials are the sole property of
their respective owners. No part of this document or related Stonesoft products may be reproduced in any form, or by any
means without written authorization of Stonesoft Corporation.
Stonesoft provides these materials for informational purposes only. They are subject to change without notice and do not
represent a commitment on the part of Stonesoft. Stonesoft assumes no liability for any errors or inaccuracies that may
appear in these materials or for incompatibility between different hardware components, required BIOS settings, NIC drivers,
or any NIC configuration issues. Use these materials at your own risk. Stonesoft does not warrant or endorse any third party
products described herein.
THESE MATERIALS ARE PROVIDED "AS-IS." STONESOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, AS TO, THE
INFORMATION CONTAINED HEREIN. IN ADDITION, STONESOFT MAKES NO EXPRESS OR IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE OR USE WITH RESPECT THE INFORMATION CONTAINED IN
THESE MATERIALS. IN NO EVENT SHALL STONESOFT BE LIABLE FOR ANY INDIRECT, SPECIAL, CONSEQUENTIAL OR
INCIDENTAL DAMAGES, INCLUDING, BUT NOT LIMITED TO, LOST PROFITS OR LOSS OR DAMAGE TO DATA ARISING FROM THE
USE OF THESE MATERIALS, EVEN IF ADVISED IN ADVANCE OF THE POSSIBILITY OF SUCH DAMAGES.
Trademarks and Patents
Stonesoft, the Stonesoft logo and StoneGate are all trademarks or registered trademarks of Stonesoft Corporation. Multi-link
technology, multi-link VPN, and the StoneGate clustering technology-as well as other technologies included in StoneGate-are
protected by patents or pending patent applications in the U.S. and other countries. All other trademarks or registered
trademarks are property of their respective owners.
Stonesoft Corporation
Itälahdenkatu 22A
FI-00210 Helsinki
Finland
Tel. +358 9 476 711
Fax +358 9 4767 1234
Stonesoft Inc.
1050 Crown Pointe Parkway
Suite 900
Atlanta, GA 30338
USA
Tel. +1 770 668 1125
Fax +1 770 668 1131
Copyright 2008 Stonesoft Corporation. All rights Reserved. All specifications are subject to change.