SIP - Gruppo Telecomunicazioni e Tecnologie dell`Informazione

Servizi Applicativi su Internet
SIP
Session Initiation Protocol
Ing. Pierluigi Gallo
Introduzione 1/2
2
  Protocollo di segnalazione basato su IP
  Standard IETF (poi accettato anche da
3GPP)
  Utilizza alcuni paradigmi e strumenti di
Internet (URL, DNS, proxy, …)
  Protocollo di controllo e segnalazione per la
gestione delle sessioni tra utenti
  Registrations, invitations, acceptations, and
disconnections
  Non dipende dai protocolli di livello inferiore
(TCP, UDP, X.25, ATM, …)
Ing. Pierluigi Gallo
a.a. 2010/2011
Introduzione 2/2
3
  1996 - Henning Schulzrinne, Mark Handley
  Prima RFC nel 1999 (RFC n. 2543)
  RFC 3261 del 2000
  Alternativa ad H.323
  Flessibile e semplice
  Offre funzionalità avanzate
  Consente di gestire sessioni I cui dati possono essere
di diverso tipo:
 
 
 
 
Audio (Fonia)
Video
Instant messaging
Notifica presenza
Ing. Pierluigi Gallo
a.a. 2010/2011
4
SIP - Session Initiation Protocol
  Controlla la segnalazione su reti IP
  Determina la locazione del
terminale chiamato
  Determina la sua eventuale
disponibilità
  Supporta trasferimento e
terminazione chiamata
  E’ basato su un modello clientserver
  E’ un protocollo text-based
(come HTTP) basato su richieste/
risposte
Ing. Pierluigi Gallo
  Inizia, modifica e termina la sessione
  Assume che il livello di trasporto sia
inattendibile
  Non definisce attributi di sessione
rimanendo indipendente
  Supporta servizi unicast e multicast
  Supporta la mobilità
  Usato per il VoIP
a.a. 2010/2011
SIP ed il livello applicazione
5
  Livello applicazione
  DHCP, HTTP, HTTPS , SMTP, POP3, IMAP, FTP, SFTP, DNS,
SSH, IRC, SNMP, SIP, RTSP, Rsync, Telnet, HSRP, RTP,
BGP, RIP, IGRP,...
  Livello di trasporto
  TCP, UDP, SCTP, DCCP ...
  Livello di rete
  IPv4, IPv6, ICMP, ICMPv6, IGMP, IPsec, OSPF ...
  Data link
 
Ethernet, WiFi, PPP, Token ring, ARP, ATM, FDDI,
LLC, SLIP, WiMAX, HSDPA, MPLS ...
Ing. Pierluigi Gallo
a.a. 2010/2011
Caratteristiche
6
 E’ un protocollo di livello applicazione
 Supporta i seguenti protocolli:
 SDP (Session Description Protocol) per negoziare
le caratteristiche della sessione multimediale
 RTP (Real-time Transport Protocol) per il trasporto
dei dati multimediali
 RTSP (Realt-Time Streaming Protocol)
 RTCP (Real Time Control Protocol) per monitorare
la qualità del servizio e per comunicare
informazioni sui partecipanti di una sessione in
corso
 MGCP (Media Gateway Control Protocol) per
controllare un eventuale accesso alla PSTN
 SAP (Session Announcement Protocol)
Ing. Pierluigi Gallo
a.a. 2010/2011
7
Caratteristiche
 Porta di default 5060 (TCP UDP)
 non criptato
  porta 5061 (TLS)
  criptato
  sessioni unicast e multicast
  ciascuna sessione puo’ riguardare uno o piu’ flussi
multimediali
 I flussi multimediali sono trasportati da altri protocolli
  RTP/RTSP (SIP si occupa solo della segnalazione)
 I parametri vengono negoziati mediante altri
protocolli
  porte, protocolli, codec,
Ing. Pierluigi Gallo
a.a. 2010/2011
Applicazioni
8
  chiamate voce
  videoconferenze
  instant messaging
  presence notification
  trasferimento files
  giochi online
  mobilita’
Ing. Pierluigi Gallo
a.a. 2010/2011
Altri protocolli di segnalazione
9
  segnalazione PSTN
Ing. Pierluigi Gallo
a.a. 2010/2011
10
Architettura
  Segnalazione e dati viaggiano in flussi differenti
  UAC: user agent client che fa le richieste
  UAS: user agent che risponde alle richieste
UAC
CHIAMANTE
INVITE
UAS
UAC
SIP
PROXY
UAC
UAS
INVITE
UAS
CHIAMATO
UAC
BYE
Ing. Pierluigi Gallo
a.a. 2010/2011
SIP: Funzionalità di base
11
 User location: dispositivo terminale usato per la
comunicazione
 User capabilities: mezzo e parametri di trasmissione
 User availability: capacità, disponibilità e volontà del
chiamato di stabilire la comunicazione
 Call setup: "ringing", instaurazione di una chiamata
tra chiamante e chiamato (in modo simile alla
PSTN)
 Call handling: gestione della chiamata
dall’instaurazione all’abbattimento
Ing. Pierluigi Gallo
a.a. 2010/2011
Lo stack protocollare SIP
Audio/Video Coding
RTP/RTCP
12
SIP
UDP o TCP (tipicamente su porta 5060)
IP
Network Access Layer (ATM, Ethernet, PPP, …)
Ing. Pierluigi Gallo
a.a. 2010/2011
Elementi del sistema SIP
13
  UA - User Agent
  UAC - User Agent Client (per l’invio delle richieste)
  UAS - User Agent Server (per ricevere i messaggi ed
inviare le risposte)
  Registrar Server (contiene le informazioni di accesso
agli UA per la risoluzione degli indirizzi SIP)
  Location Server (contiene le corrispondenze tra gli
UA e gli indirizzi Ip e consente una loro variazione
dinamica per gestire la mobilità)
  Network Server
  Proxy
  Redirect
Ing. Pierluigi Gallo
a.a. 2010/2011
14
Indirizzi SIP
  Sono identificati attraverso un URL (Universal
Resource Locator) SIP
  Il formato è identico a quello degli indirizzi e-mail:
user@host
Nome utente
Oppure
Numero di telefono
Nome Dominio
Oppure
Indirizzo IP
Esempi:
[email protected]
[email protected];user=phone
nomeutente:password@host:port;uri-parameters?headers
Ing. Pierluigi Gallo
a.a. 2010/2011
Messaggi:
15
•  Messaggi di testo simili all’HTTP
•  Start line
–  Request (client-server)
–  Response (server-client)
•  Uno o più campi di header
•  Chiamante e chiamato
•  oggetto
•  Una linea vuota che simboleggia le fine
degli header
•  Message body (opzionale)
•  Tipo di sessione
•  Tipo di protocollo
Ing. Pierluigi Gallo
a.a. 2010/2011
Message – Transaction - Dialog
16
•  Un messaggio è una richiesta o una
risposta
•  L’insieme di una richiesta e della/e
successiva/e risposta/e viene detta
Transaction
•  Una transazione è individuata da una
transaction-ID che tiene conto della
sorgente, del destinatario e del numero di
sequenza
•  Una relazione tra entità paritetiche che si
scambiano richieste e risposte viene detta
Dialog
Ing. Pierluigi Gallo
a.a. 2010/2011
17
Metodi
  Sono composte da:
  Metodi
  Request URI (Universal Resource Identifier)
  Versione del protocollo SIP in uso
  I metodi possibili sono:
  Invite
  Ack
  Options
  Bye
  Cancel
  Register
  Info
Ing. Pierluigi Gallo
a.a. 2010/2011
Metodi
18
  Un messaggio SIP contiene un metodo
  Dopo I metodi vengono gli headers
  Riga vuota
  Headers del protocollo SDP
Ing. Pierluigi Gallo
a.a. 2010/2011
19
Richieste
Ing. Pierluigi Gallo
a.a. 2010/2011
Register
20
 Consente ad un client di registrare
su un register server un utente
identificato dall’indirizzo contenuto
nel campo to
 Registrazione su più server
  diverse registrazioni su un unico
server
Ing. Pierluigi Gallo
a.a. 2010/2011
Invite
21
 Inizia una sessione invitando il chiamato a
parteciparvi
 Indicazione del chiamante e del chiamato
 Specifica il tipo di dati
 Contiene, tipicamente, una descrizione di
sessione scritta in SDP, con le informazioni
sufficienti all’instaurazione della connessione
 Viene confermato con un ACK sulla risposta
finale
Ing. Pierluigi Gallo
a.a. 2010/2011
Cancel
22
  Permette ad un client di cancellare una richiesta
inviata precedentemente
  Termina una richiesta pendente
  Si usa cancel quando la sessione non ha ancora
avuto inizio, altrimenti BYE
Ing. Pierluigi Gallo
a.a. 2010/2011
BYE
23
  Abbatte una sessione (Dialog)
  Può essere inviato sia dal chiamante che dal
chiamato
Ing. Pierluigi Gallo
a.a. 2010/2011
Info
24
• Permette lo scambio di
informazioni personali lungo
un percorso di segnalazione
• Consente lo scambio di
informazioni di sessioni in
corso
• DTMF
Ing. Pierluigi Gallo
a.a. 2010/2011
25
Risposte
Ing. Pierluigi Gallo
a.a. 2010/2011
26
Risposte
 Sei classi di risposte:
 Informational 1XX
 Success
2XX
 Redirection
3XX
 Request Failure
4XX
 Server Failure 5XX
 Global Failure
6XX
 Tutte le risposte eccetto le 1xx sono considerate
final e quindi vanno seguite da ACK
Ing. Pierluigi Gallo
a.a. 2010/2011
27
Informational 1XX
  Viene inviato quando il server sta contattando il
chiamato e il tempo risulta superiore a 200ms
  Esempio: 180 - ringing - l’utente localizzato è in
attesa di risp.
  Trying
Success 2XX
•  Indica che la richiesta è stata accettata con
successo
•  Esempio: 200 - messaggio di OK
Redirection 3XX
•  Vengono passate informazioni riguardo alla nuova
posizione dell’utente cercato
Ing. Pierluigi Gallo
a.a. 2010/2011
Request Failure 4XX
28
  Richiesta fallita a causa del client
  Esempio: 404 - not found - utente non reperibile
Server Failure 5XX
•  Richiesta fallita a causa del server
•  Esempio: 501 - not implemented - il server non
supporta le modalità necessarie per soddisfare la
richiesta
Global Failure 6XX
•  Il server non risponde ad informazioni definitive
Ing. Pierluigi Gallo
a.a. 2010/2011
29
SIP Diagram
A
…….
Proxy
…….
Proxy
…….
B
(Registrar local services)
Register
Register
200 Ok
200 Ok
Invite
100 Trying
180 Ringing
200 Ok
Invite
100 Trying
180 Ringing
200 Ok
Invite
180 Ringing
200 Ok
Ack
Media Session
Bye
200 Ok
Ing. Pierluigi Gallo
a.a. 2010/2011
Registrar server
30
  Server dedicato alla registrazione di un utente
alla rete
  Puo’ essere integrato all’interno del Proxy
  le richieste di registrazione vengono
memorizzate all’interno dei location server, i quali
forniscono la corrispondenza tra indirizzo e
location
  Una registrazione puo’ essere effettuata in
multicast (sip.mcast.net 224.0.1.75)
Ing. Pierluigi Gallo
a.a. 2010/2011
Registration and invite
31
Tratto dalla RFC 3261
Ing. Pierluigi Gallo
a.a. 2010/2011
32
Processo di registrazione
REGISTER sip:registrar.work.com SIP/2.0
SIP/2.0 200 OK
REGISTER sip:registrar.work.com SIP/2.0
Via: SIP/2.0/UDP station1.work.com;
branch=z9hG4bK123
Max-Forwards: 70
From: SIP: [email protected];tag=123456
To: sip:[email protected]
Call-ID: [email protected]
Cseq: 1 REGISTER
Contact: sip: [email protected]
Expires: 7200
Content-Length: 0
SIP/2.0 200 OK
Via: SIP/2/0/UDP station1.work.com; branch=z9hG4bK123
From: sip:[email protected]
Call-ID: [email protected]
CSEQ: 1 REGISTER
Contact: sip:[email protected]
Expires: 3600
Content-Length: 0
Ing. Pierluigi Gallo
a.a. 2010/2011
Proxy server
  Gestisce le richieste o le inoltra ad altri server
  Può essere usato per inoltrare una chiamata
Ing. Pierluigi Gallo
33
Redirect servers
34
  Map the destination address to zero or more new
addresses
  Do not initiate any SIP requests
Ing. Pierluigi Gallo
a.a. 2010/2011
SIP Call Establishment
Ing. Pierluigi Gallo
35
a.a. 2010/2011
Chiamata ad un numero
36
  Prova a
chiamare lo
stesso utente su
più destinazioni
  Il primo che
risponde va a
buon fine, gli altri
vengono chiusi
Ing. Pierluigi Gallo
a.a. 2010/2011
Header:
37
  Consente di specificare:
 
 
 
 
Chiamante
Chiamato
Percorso
Tipo di messaggio
  Il protocollo prevede 37 tipi di intestazioni, divisi in 4
gruppi:
  Intestazioni generale (richieste e risposte)
  Intestazioni di entità (relative a tipo e lunghezza del
messaggio)
  Intestazioni di richiesta (consentono informazioni di
richiesta aggiuntive)
  Intestazioni di risposta (consentono informazioni di
risposta aggiuntive)
Ing. Pierluigi Gallo
a.a. 2010/2011
Gestione della mobilità
38
  Il messaggio Register consente la registrazione di
uno UA nel Registrar Server della rete corrente
  Il Registrar Server può essere individuato:
  Mandando un messaggio multicast ad un indirizzo
noto
  Contattando l’Home Domain Registrar (individuabile
attraverso il server DNS)
  Usando SLP (Server Location Protocol)
  SLP è stato progettato per facilitare l’operazione di
discovery di risorse della rete quali Web Servers,
stampanti, fax…
Ing. Pierluigi Gallo
a.a. 2010/2011
Uno scenario di
funzionamento
Proxy/Registrar
Server
Register
UA
200 OK
39
UA
Registration
Invite
Invite
100 Trying
180 Ringing
180 Ringing
200 OK
200 OK
Ack
Ack
Call Setup
Bye
Bye
100 Trying
200 OK
200 OK
Teardown
Ing. Pierluigi Gallo
a.a. 2010/2011
Dettaglio di un pacchetto
“Invite”
40
INVITE sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP vo1.hq.university.com
To: Bob <sip:[email protected]>
From: Alice <sip:[email protected]>; tag=18271
Call-ID: [email protected]
CSeq: 12921 INVITE
Contact: <sip:[email protected]>
Alice invita Bob.
Il pacchetto Invite viene inoltrato dallo UA di Alice al
proxy server vo1.hq.university.com.
La chiamata viene indentificata univocamente grazie
al campo Call-ID.
Ing. Pierluigi Gallo
a.a. 2010/2011
a.a. 2010/2011
Transactions
Ing. Pierluigi Gallo
41
42
Transazione
UAC
Ing. Pierluigi Gallo
Outbound
Proxy
Inbound
proxy
response
Server transaction
Client transaction
response
request
Server transaction
Client transaction
response
request
Server transaction
Client transaction
request
UAS
a.a. 2010/2011
Client Transaction
43
  Una client transaction é implementata con una
State Machine
  TU = transaction user (ogni entita’ SIP eccetto i
proxy stateless)
  Quando TU vuole iniziare una nuova transaction,
crea una client transaction la quale inizia
l’esecuzione di una macchina a stati (ce ne sono
diverse in base al tipo di transaction)
  Due tipi di client transaction
  INVITE transaction (relativa ad una richiesta INVITE)
  hanno una durata maggiore rispetto a quelle di altro
tipo in quanto richiedono l’intervento umano per
accettare la chiamata
  Non-INVITE transaction (per gli altri tipi di richieste)
  Terminano immediatamente
Ing. Pierluigi Gallo
a.a. 2010/2011
44
INVITE transaction
A
…….
Proxy
…….
Proxy
…….
B
(Registrar local services)
Register
Register
200 Ok
200 Ok
3-way
handshake
Invite
100 Trying
180 Ringing
200 Ok
Invite
100 Trying
180 Ringing
200 Ok
Invite
180 Ringing
200 Ok
Ack
Media Session
Bye
Ing. Pierluigi Gallo
200 Ok
a.a. 2010/2011
INVITE transaction
45
Se il protocollo di trasporto é inaffidabile (UDP), la client
transaction ritrasmette le richieste con un intervallo
che inizialmente é T1 e poi va raddoppiando ad ogni
ritrasmissione
Se il protocollo di trasporto é affidabile -> no
ritrasmissione
T = 2n Ti con n = numero di ritrasmissioni
Ti é l’RTT stimato (default 500 ms)
Ti influenza tutti gli altri timers
Dopo la ricezione di un messaggio 1XX cessano le
ritrasmissioni
Ing. Pierluigi Gallo
a.a. 2010/2011
FSM INVITE transaction
46
RFC 3261
Ing. Pierluigi Gallo
a.a. 2010/2011
47
SIP Model (1)
Simplified message formats:
 REGISTER <Domain> <To> <From> <Contact(device)
>
 OK <To> <From>
 INVITE <To> <From><Via><Content>
 BYE <To> <From>
 ACK <To> <From>
Ing. Pierluigi Gallo
a.a. 2010/2011
SIP: aspetti di sicurezza
48
 Model SIP URI registration and look
for registration hijack attacks.
 Model interdomain session setup
and look for message tampering
and proxy impersonation attacks.
 Add proxy-to-proxy authentication
and secrecy (TLS) to model.
Ing. Pierluigi Gallo
a.a. 2010/2011
Authentication
49
  Server Authentication: using TLS: server offers a
certificate to the UA, preventing proxy
impersonating
  User Authentication: using HTTP digest: server
challenges a user with a 401 Proxy
Authentication, preventing registration hijacking
Ing. Pierluigi Gallo
a.a. 2010/2011
Secretezza del messaggio
50
 Mechanisms that rely on existence of
end-user certificates are seriously limited
(S/MIME).
 May use self-signed certificates
  Susceptible to obvious MITM attack, but…
  Attacker can only exploit on initial key
exchange.
  Difficult for attacker to remain in path of all
future dialogs.
  Same vulnerability in SSH => key fingerprints.
  For VoIP, users could read off key fingerprint.
 Or, use preconfigured certificates when
there is an established trust between all
SIP entities.
Ing. Pierluigi Gallo
a.a. 2010/2011
Attacchi DoS
51
  Floods of messages directed at proxies can lock
up resources on the server.
  UAs and proxies should challenge questionable
requests.
  Mutual authentication of proxies (TLS)
  Reduces potential for intermediaries to introduce
falsified requests or responses.
  Harder for attackers to make innocent SIP nodes into
agents of amplification.
Ing. Pierluigi Gallo
a.a. 2010/2011
SIP Vulnerabilities
52
  Proxy Impersonation
  Message Tampering
  Session Teardown
  Spoofed BYEs
  Denial of Service
  Malformed packets
  REGISTER and INVITE flooding
  Registration Hijacking
Ing. Pierluigi Gallo
a.a. 2010/2011
53
SIP Security
 Registration hijacking
  Authenticate originators of requests
 Proxy impersonation
  Authenticate servers
 Message tampering
  Secure body and certain headers end-toend
 Session teardown
  Authenticate sender of BYE
  Confidentiality so attacker can’t learn To,
From tags
 Denial of Service
  Authenticate and authorize registrations
Ing. Pierluigi Gallo
a.a. 2010/2011
a.a. 2010/2011
Esercitazione
UA, Proxy, Java API e programmazione
Ing. Pierluigi Gallo
54
Esercitazione SIP
55
  Visualizzazione dei messaggi tramite Wireshark
  Utilizzo di un SIP client (softphone e.g. Xlite)
  Le JAIN API ed implementazione di un semplice UA
Ing. Pierluigi Gallo
a.a. 2010/2011
Software SIP open source
56
  Server:
  Sip X
  SER – Sip Express Router
  Asterisk
  User Agents:
  X-Lite
  SoftPhone
  Windows Messenger
Ing. Pierluigi Gallo
a.a. 2010/2011
Jain: API Java per SIP
57
 Fornisce un’interfaccia standard in Java allo
stack di segnalazione SIP
– interfaccia allo stack
– interfaccia ai messaggi
– gestione degli eventi e della loro semantica
– garantisce la portabilità delle applicazioni
API in Java per SIP
Ing. Pierluigi Gallo
a.a. 2010/2011
Caratteristiche del Server:
58
  Configurabilità dello stack SIP
  Implementazione del Location/Registrar
  Accessibilità controllata dall’amministratore
  Gestione dinamica dei bind secondo le specifiche di
protocollo
  Implementazione del Proxy
  Statefull
  Stetelless
Ing. Pierluigi Gallo
a.a. 2010/2011
Implementazione del
Registrar
59
 Dall’RFC 3261:
  When receiving a REGISTER request, a
registrar follows these steps:
  The registrar inspects the Request-URI to
determine whether it has access to
bindings for the domain identified in the
Request-URI.
  The registrar extracts the address-of-record
from the To header field of the request. If
the address-of-record is not valid for the
domain in the Request-URI, the registrar
MUST send a 404 (Not Found) response and
skip the remaining steps.
Ing. Pierluigi Gallo
a.a. 2010/2011
Implementazione del
Registrar (2)
60
  Dall’RFC 3261:
  The registrar now processes each contact address in
the Contact header field in turn. For each address, it
determines the expiration interval
  The registrar returns a 200 (OK) response. The
response MUST contain Contact header field values
enumerating all current bindings.
Ing. Pierluigi Gallo
a.a. 2010/2011
Implementazione del Proxy
(1)
61
  Dall’RFC 3261:
  For all new requests, including any with unknown
methods, an element intending to proxy the request
MUST:
  1. Validate the request
  2. Preprocess routing information
  3. Determine target(s) for the request
  4. Forward the request to each target
  5. Process all responses
Ing. Pierluigi Gallo
a.a. 2010/2011
Implementazione del Proxy
(2)
62
  Dettaglio del “Forward the request to each
target” (dall’RFC 3261):
 
 
 
 
 
 
1. Make a copy of the received request
2. Update the Request-URI
3. Update the Max-Forwards header field
4. Optionally add a Record-route header field value
5. Optionally add additional header fields
6. Postprocess routing information
Ing. Pierluigi Gallo
a.a. 2010/2011
Implementazione del Proxy
(3)
63
  Dall’RFC 3261:
  7. Determine the next-hop address, port, and
transport
  8. Add a Via header field value
  9. Add a Content-Length header field if necessary
  10. Forward the new request
  11. Set timer C
Ing. Pierluigi Gallo
a.a. 2010/2011
Link utili
64
  SIP Center: www.sipcenter.com
  SIP Forum: www.sipforum.org
  Lista di Server Pubblici SIP:
  www.cs.columbia.edu/sip/servers.html
  GNU o SIP library:
  www.fsf.org/software/osip/
Ing. Pierluigi Gallo
a.a. 2010/2011