1 / 41

Session Initiation Protocol

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

alden
Télécharger la présentation

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Session Initiation Protocol By, Vivek Nemarugommula

  2. Background • Overview Of Operation • Structure Of The Protocol • Definitions • SIP Messages • Dialogs

  3. 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)

  4. 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.

  5. Sessions • Simple: Two-way telephone call • Collaborative multi-media conference • Voice enriched e-commerce • Instant Messaging with buddy list

  6. SIP Entities In The Network

  7. 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”

  8. 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)

  9. SIP Basic Request Methods

  10. SIP Responses

  11. SIP Session Establishment and Call Termination

  12. 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.

  13. 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

  14. SIP Call Flow with direct invitation

  15. SIP Call Flow with Proxy Server

  16. SIP Call Flow with Redirect Server

  17. Example Request/Response

  18. 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.

  19. 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.

  20. 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.

  21. Registration

  22. 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.

  23. 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.

  24. Proxy 200 test

  25. 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

  26. 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

  27. 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.

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

  29. Summary Of Requirements • Below, R is the request handling rate.

  30. SIP Security • Security Framework • Classic Threat Models • Solutions

  31. Security Framework

  32. 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

  33. 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

  34. Solutions For Securing SIP

  35. 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.

  36. 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.

  37. 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)

  38. Shared secret • Avoid SIP-PGP mistakes: • canonical form • header ordering • special headers

  39. 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.

  40. 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.

  41. 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

More Related