Session initiation protocol
This presentation is the property of its rightful owner.
Sponsored Links
1 / 41

Session Initiation Protocol PowerPoint PPT Presentation


  • 89 Views
  • Uploaded on
  • Presentation posted in: General

Session Initiation Protocol. By, Vivek Nemarugommula. Background. Overview Of Operation Structure Of The Protocol Definitions SIP Messages Dialogs. Overview.

Download Presentation

Session Initiation Protocol

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Session initiation protocol

Session Initiation Protocol

By,

Vivek Nemarugommula


Background

Background

  • Overview Of Operation

  • Structure Of The Protocol

  • Definitions

  • SIP Messages

  • Dialogs


Overview

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

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.


Session initiation protocol

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 Entities In The Network


Sip functional entities

SIP Functional Entities

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

  • No forwarding of requests, usually “search intensive”


Sip messages

SIP messages

  • SIP is a Client-Serverprotocol similar to HTTP. Most SIP

    components can act as client and as server.

  • A SIP transactionis 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 Basic Request Methods


Sip responses

SIP Responses


Sip session establishment and call termination

SIP Session Establishment and Call Termination


Sip signalling

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 signalling1

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 direct invitation


Sip call flow with proxy server

SIP Call Flow with Proxy Server


Sip call flow with redirect server

SIP Call Flow with Redirect Server


Example request response

Example Request/Response


Benchmarks sipstone

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

  • 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

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

Registration


Types of tests

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 tests1

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

Proxy 200 test


Definition of terms

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

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

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

Metrics

  • We also define an initial composite benchmark called SIPstone-A that weighs the ten processing rate metrics as follows:


Summary of requirements

Summary Of Requirements

  • Below, R is the request handling rate.


Sip security

SIP Security

  • Security Framework

  • Classic Threat Models

  • Solutions


Session initiation protocol

Security Framework


Session initiation protocol

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


Session initiation protocol

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

Solutions For Securing SIP


Http basic authentication

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 (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

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

Shared secret

  • Avoid SIP-PGP mistakes:

    • canonical form

    • header ordering

    • special headers


Ip security ipsec

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

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

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


  • Login