Download SIP messages

Session Initiation Protocol
By,
Vivek Nemarugommula
Background





Overview Of Operation
Structure Of The Protocol
Definitions
SIP Messages
Dialogs
Overview




SIP is an application-layer control protocol that can establish,
modify, and terminate multimedia sessions (conferences) such
as Internet telephony calls.
SIP = ‘Session Initiation Protocol’ Proposed IETF Standard RFC
3261.
Peer-to-peer application layer protocol where
endpoints (User Agents) initiate, modify and terminate sessions.
SIP uses existing IETF protocols to provide media
negotiation (SDP), media transport (RTP), name
resolution and mobility (DHCP, DNS), and application encoding
(MIME)
SIP: Basic Idea





Users are known by SIP URIs.
Text-based encoding based on a
HTTP-like request/ response
transaction model.
Simple extensions by introducing
new ‘Methods’ and ‘Headers`
No relation between (SIP) signaling
path and data stream path.
Telephony services across the
internet.
Sessions




Simple: Two-way telephone call
Collaborative multi-media conference
Voice enriched e-commerce
Instant Messaging with buddy list
SIP Entities In The Network
SIP Functional Entities
1.
2.
3.
4.
1.
2.
3.
1.
2.
3.
4.
5.
1.
User Agent (UA)
Intelligent endpoint entity capable of managing its own sessions
Paradigm: Intelligence to the edge!
Initiates and terminates SIP requests; Always call stateful
Is an application, containing both UA client (UAC) and UA server (UAS)
Registrar
Register current physical address of user agent
Provide location information based on the registrations
Essential for reachability
Proxy Server
Intermediate SIP node (“SIP router”)
Routes SIP requests towards their target
Accesses location and routing information to do its job
SIP Proxies can be: stateless, transaction stateful or call stateful
Additional jobs: e.g. access control, NAT / Firewall control
Redirect Server
Find location information and return it to user agent
SIP messages



SIP is a Client-Server protocol similar to HTTP. Most SIP
components can act as client and as server.
A SIP transaction is composed of a request of a client to
a server and its response.
Message parts are:
Start Line: conveys message type & protocol version
Headers: to convey message attributes and to modify
message meaning
Body: to describe the session to be initiated or to transport
opaque textual or binary data. Body types: SDP, MIME, others)
SIP Basic Request Methods
SIP Responses
SIP Session Establishment
and Call Termination
Sip Signalling




To initiate a session, the caller (or User Agent Client) sends a
request with the SIP URL of the called party.
If the client knows the location of the other party it can send
the request directly to their IP address; if not, the client can
send it to a locally configured SIP network server.
The server will attempt to resolve the called user's location and
send the request to them.
There are many ways it can do this, such as searching the DNS
or accessing databases. Alternatively, the server may be a
redirect server that may return the called user location to the
calling client for it to try directly.
Sip Signalling


During the course of locating a user, one SIP network
server can proxy or redirect the call to additional
servers until it arrives at one that definitely knows
the IP address where the called user can be found.
Once found, the request is sent to the user and then
several options arise. In the simplest case, the user's
telephony client receives the request, that is, the
user's phone rings. If the user takes the call, the
client responds to the invitation with the designated
capabilities* of the client software and a connection
is established. If the user declines the call, the
session can be redirected to a voice mail server or to
another user
SIP Call Flow with direct
invitation
SIP Call Flow with Proxy
Server
SIP Call Flow with
Redirect Server
Example
Request/Response
Benchmarks-SIPstone



SIPstone is a benchmark for SIP (Session Initiation Protocol [1])
proxy and redirect Servers (SIPServer). The benchmark
attempts to measure the request handling capacity of a SIP
server or a cluster of SIP servers.
SIP-based Internet telephony systems need to be appropriately
dimensioned, as the call and registration rate can reach several
thousand requests a second.
The benchmark currently is limited to evaluating the sustainable
rate of what we believe to be a representative workload,
consisting of registrations, successful forwarding and
unsuccessful call attempts.
SIPstone


SIPstone describes a workload for SIP requests in proxies using
a set of tests that exercise various components of typical SIP
servers.
Architecture:
The “server under test” (SUT) is a SIP proxy, redirect or
registrar server whose performance is to be estimated. The
benchmark consists of a set of SIPstone load generators that
create the SIP request load, a call handler that simulates a user
agent server and a central benchmark manager (“coordinator”)
that coordinates the execution of the benchmark, and the SUT.
Description Of Tests
The benchmark currently consists of five tests. Each test is
performed using both UDP and TCP, with results reported
separately for each transport protocol
The individual tests are:


Registration: Registrations are sent by the load generator,
using digest authentication. For simplicity, account name and
user secret are typically chosen to be the same. The message
flow is shown in Fig. 1. The transaction delay is measured from
sending the first REGISTER request to receiving the final 200
response, including the 401 “Unauthorized” message.
Registration
Types Of Tests
Redirect: The load generator sends an
INVITE request to the SUT acting as a
redirect server. The transaction delay
is measured from sending the INVITE

request to receiving the 3xx response.
Types Of Tests


Proxy 480: The load generator sends an INVITE request to the
SUT acting as a redirect server. The call destinations are known
to the server, but have not registered, so that the server returns
a 480 (Temporarily unavailable) response. The request is not
authenticated.
Proxy 200: The load generator alternates between INVITE and
BYE transactions to the SUT acting as a non-forking proxy
server. The BYE transaction is sent immediately after the INVITE
transaction completes.
The TRT is measured only for the INVITE request.
Proxy 200 test
Definition of terms





Measurement Interval (MI): Themeasurement interval is
defined as the steady state period during the execution of the
benchmark from which the reported performance metric is derived.
During the measurement interval, the UACs generate SIP requests.
Transaction Response Time (TRT): The transaction response time
is defined as the time elapsed from the first byte sent by a UAC to
initiate a transaction until the last byte received by the UAC that ends
the transaction.
Registrations per second (RPS): is defined as the average number
of successful registrations per second during the measurement interval.
Calls per second (CPS): Calls per second is defined as the average
number of calls per second completed with a 2xx or 4xx response
during a measurement interval.
Transaction failure probability (TFP): The transaction failure
probability is the fraction of transactions that fail, i.e, where the server
does not return a provisional or final response within the time limit
Measurement Methology



To determine the RPS and CPS values, the request rate is increased
until the TFP increases to 5%, evaluated across a measurement
interval of 15 minutes. The highest sustained throughput is reported as
the benchmark number.
For more detailed benchmarks, the TRT as a function of the transaction
rate should be plotted, with at least four measurements recommended.
The average TRT of a measurement interval is computed by averaging
over the successful (timely) responses
Metrics And Parameters





Description of the clustering configuration, including the
number of hosts and the load balancing mechanism used (e.g.,
DNS SRV or stateless proxy);
The number of connections requested by the clients and
accepted by the SUT per second. The intent is to count only the
number of new connections made successfully by the clients in
generating the load for the benchmark.
CPU and memory utilization of server at various loads;
A curve plotting the TRT as a function of request arrival rates,
with at least four plot points and one value at approximately
10% of the capacity;
CPS and RPS.
Metrics

We also define an initial composite benchmark called SIPstone-A that
weighs the ten processing rate metrics as follows:
Summary Of Requirements

Below, R is the request handling rate.
SIP Security



Security Framework
Classic Threat Models
Solutions
Security Framework
Authentication
is means of identifying another entity. There are many ways to authenticate
another entity, but the typical computer based methods involve user
ID/password or digitally signing a set of bytes using a keyed hash
Confidentiality
Cryptographic confidentiality means that only the intended recipients will be
able to determine the contents of the confidential area
Integrity
A message integrity check is means of insuring that a message in transit was
not altered
Authorization
Once identification of a correspondent is achieved, a decision must be made
as to whether that identity should be granted access for the requested
services. This is the act of authorization. This is often done using access
control lists (ACL).
Privacy
They want to make sure others do not know what they are doing or
transmitting. Some people prefer anonymity. In a higher education
environment, faculty and student reserve the right to privacy.
Non-repudiation
Reverse protection
Administration
Billing and accounting, maintenance of Call Data Records (CDRS)
Audit-trail
Do not shred documents – Enron!
Classic Threat Models



Registration Hijacking – A registrar assesses the
identity of a UA. The From header of a SIP request
can be arbitrarily modified and hence open to
malicious registration.
Impersonating a server – A UA contacts a Proxy
server to deliver requests. The server could be
impersonated by an attacker. Mobility in SIP further
complicates this.
Tampering with message bodies
More threats


Tearing down sessions – insert a BYE
Denial of Service attacks - Denial of service
attacks focus on rendering a particular network
element unavailable, usually by directing an
excessive amount of network traffic at its interfaces.
In much architecture SIP proxy servers face the
public Internet in order to accept requests from
worldwide IP endpoints. SIP creates a number of
potential opportunities for distributed denial of
service attacks that must be recognized and
addressed by the implementers and operators of SIP
systems
Solutions For Securing SIP
HTTP Basic Authentication



HTTP basic authentication [Fr99] requires the transmission
of a username and a matching password embedded in the
header of a HTTP request.
Included in a SIP request this user information could be
used by a SIP proxy server or destination user agent to
authenticate a SIP client or the previous SIP hop in a
proxy chain.
Because the cleartext password can be easily sniffed and
therefore poses a serious security risk, the use of HTTP
basic authentication has been deprecated by SIPv2.
Pretty Good Privacy (PGP)

Pretty Good Privacy [El96] could be
potentially used to authenticate and
optionally encrypt MIME payloads
contained in SIP messages but version
2 of SIP has deprecated the use of PGP
in favour of S/MIME.
S/MIME
• Existing solution, existing code
• Treat SIP message like email
attachment:
• Content-Type: message/sip ???
• Requires client certs?
• What if ssh-style security is sufficient
(same host as last time, but can’t prevent
MiM for first attempt)
Shared secret

Avoid SIP-PGP mistakes:



canonical form
header ordering
special headers
IP Security (IPsec)


IPsec is a general purpose mechanism that can be used to protect the
SIP messages right on the network level. Due to the requirement that
each proxy server on the path must have read/write access to the SIP
header, IPsec ESP (Encapsulating Security Payload) or AH
(Authentication Header) in transport mode [KA98] must be applied on
a hop-by-hop basis
The Internet Key Exchange (IKE) protocol [HC98] which is used to set
up IPsec security associations supports both Pre-Shared Key (PSK) and
Public Key (PKI) based authentication. Because the IP addresses of the
SIP user agents will be mostly dynamic and taking into account that
IKE Main Mode in that case does not work with pre-shared secrets and
that IKE Aggressive Mode is fraught with security problems (man-inthe-middle attacks, off-line dictionary attacks on the PSK, etc.), public
key based authentication will be the preferred method.
Conclusions


Session Initiation Protocol (SIP) has become a strong, catalytic force
shaping today's telecom industry.
Using SIP, telephony becomes another web application and integrates
easily into other Internet services.




SIP was designed to specifically reuse as many existing protocols and
protocol design concepts.
SIP was also designed so that it would be easy to bind SIP functions to
existing protocols and applications, such as e-mail and Web browsers
SIP is independent of the packet layer and only requires an unreliable
datagram service, as it provides its own reliability mechanism
SIP security is very important based on its growth.
References







http://www.ietf.org/rfc/rfc3261.txt
http://www.sipcenter.com/sip.nsf/html/What+Is+SIP
+Introduction\
http://www.sipstone.org/files/sipstone_0402.pdf
http://en.wikipedia.org/wiki/Session_Initiation_Protoc
ol
http://www.cs.columbia.edu/sip/
http://bscwpub-itec.uniklu.ac.at/pub/bscw.cgi/d73544/13-Multimedia-SIP.pdf
http://www.tmf.org/hospitalqi/sip/benchmark/Bench
mark%20Processes%20to%20Improve%20SIP.pdf