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 User Agent (UA)1. Intelligent endpoint entity capable of managing its own sessions2. Paradigm: Intelligence to the edge!3. Initiates and terminates SIP requests; Always call stateful4. Is an application, containing both UA client (UAC) and UA server

(UAS)Registrar

1. Register current physical address of user agent2. Provide location information based on the registrations3. Essential for reachability

Proxy Server1. Intermediate SIP node (“SIP router”)2. Routes SIP requests towards their target3. Accesses location and routing information to do its job4. SIP Proxies can be: stateless, transaction stateful or call stateful5. Additional jobs: e.g. access control, NAT / Firewall control

Redirect Server1. Find location information and return it to user agent2. No forwarding of requests, usually “search intensive”

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 FrameworkAuthentication 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-in-the-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_Protocol http://www.cs.columbia.edu/sip/ http://bscwpub-itec.uni-klu.ac.at/pub/

bscw.cgi/d73544/13-Multimedia-SIP.pdf http://www.tmf.org/hospitalqi/sip/benchmark/

Benchmark%20Processes%20to%20Improve%20SIP.pdf