Transcript What is SIP? - Columbia University

Global Ubiquitous
Computing
Henning Schulzrinne
Columbia University
(KAIST KNSS)
March 5, 2004
Agenda






SIP overview
SIP for ubiquitous computing
Location-based services
Emergency calling
Services, carriers and service creation
Security issues
March 5, 2004
2
SIP Overview
March 5, 2004
3
Internet services – the missing
entry
Service/delivery
synchronous
asynchronous
push
instant messaging
presence
event notification
session setup
media-on-demand
messaging
pull
data retrieval
file download
remote procedure call
peer-to-peer file sharing
March 5, 2004
4
Filling in the protocol gap
Service/delivery
synchronous
asynchronous
push
SIP
RTSP, RTP
SMTP
pull
HTTP
ftp
SunRPC, Corba, SOAP
(not yet standardized)
March 5, 2004
5
SIP as service enabler

Rendezvous protocol


lets users find each other by
only knowing a permanent
identifier
Mobility enabler:

personal mobility


terminal mobility


one terminal, multiple IP
addresses
session mobility


one person, multiple
terminals
one user, multiple terminals in
sequence or in parallel
service mobility

services move with user
March 5, 2004
6
What is SIP?





Session Initiation Protocol  protocol that establishes,
manages (multimedia) sessions
 also used for IM, presence & event notification
 uses SDP to describe multimedia sessions
Developed at Columbia U. (with others)
Standardized by
 IETF (RFC 3261-3265 et al)
 3GPP (for 3G wireless)
 PacketCable
About 60 companies produce SIP products
Microsoft’s Windows Messenger (≥4.7) includes SIP
March 5, 2004
7
Philosophy






Session establishment & event notification
Any session type, from audio to circuit emulation
Provides application-layer anycast service
Provides terminal and session mobility
Based on HTTP in syntax, but different in protocol operation
Peer-to-peer system, with optional support by proxies
 even stateful proxies only keep transaction state, not call
(session, dialogue) state
 transaction: single request + retransmissions
 proxies can be completely stateless
March 5, 2004
8
Basic SIP message flow
March 5, 2004
9
SIP trapezoid
outbound proxy
destination proxy
(identified by SIP URI domain)
1st request
SIP trapezoid
2nd, 3rd, … request
[email protected]:
128.59.16.1
registrar
voice traffic
RTP
March 5, 2004
10
message body
header fields
request line
SIP message format
request
INVITE sip:[email protected] SIP/2.0
response
SIP/2.0 200 OK
Via: SIP/2.0/UDP here.com:5060
From: Alice <sip:[email protected]>
To: Bob <sip:[email protected]>
Call-ID: [email protected]
CSeq: 1 INVITE
Subject: just testing
Contact: sip:[email protected]
Content-Type: application/sdp
Content-Length: 147
Via: SIP/2.0/UDP here.com:5060
From: Alice <sip:[email protected]>
To: Bob <sip:[email protected]>
Call-ID: [email protected]
CSeq: 1 INVITE
Subject: just testing
Contact: sip:[email protected]
Content-Type: application/sdp
Content-Length: 134
v=0
o=alice 2890844526 2890844526 IN IP4 here.com
s=Session SDP
c=IN IP4 100.101.102.103
t=0 0
m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000
v=0
o=bob 2890844527 2890844527 IN IP4 there.com
s=Session SDP
c=IN IP4 110.111.112.113
t=0 0
m=audio 3456 RTP/AVP 0
a=rtpmap:0 PCMU/8000
SDP
March 5, 2004
11
RFC 3261


Backward compatible with RFC 2543 – no new version
Major changes:

specification behavior-oriented, not header-oriented





mandate support for UDP and TCP
formal offer/answer model for media negotiation
uses both SRV and NAPTR for server location, load balancing and
redundancy
much more complete security considerations





e.g., separation into ‘layers’
“sips:’’ for secured (TLS) path
PGP removed due to lack of use
Basic authentication removed as unsafe
S/MIME added for protecting message bodies (and headers, via
encapsulation)
Route/Record-Route simplified
March 5, 2004
12
PSTN vs. Internet Telephony
PSTN:
Signaling & Media
Internet
telephony:
Signaling & Media
China
Signaling
Signaling
Media
Belgian customer,
currently visiting US
Australia
March 5, 2004
13
SIP addressing

Users identified by SIP or tel URIs





tel: URIs describe E.164 number, not dialed digits
(RFC 2806bis)
tel URIs  SIP URIs by outbound proxy
A person can have any number of SIP URIs
The same SIP URI can reach many different
phones, in different networks


tel:110
sip:sos@domain
sequential & parallel forking
SIP URIs can be created dynamically:




sip:[email protected]
GRUUs
conferences
device identifiers (sip:[email protected])
Registration binds SIP URIs (e.g., device
addresses) to SIP “address-of-record” (AOR)
domain 
128.59.16.17
via NAPTR + SRV
March 5, 2004
14
3G Architecture (Registration)
mobility management
signaling
serving
CSCF
interrogating
proxy
interrogating
home IM domain
registration signaling (SIP)_
visited IM domain
March 5, 2004
15
centrex-style features
SIP is PBX/Centrex ready
call waiting/multiple
calls
RFC 3261
hold
RFC 3264
transfer
RFC 3515/Replaces
conference
RFC 3261/callee caps
message waiting
boss/admin features
simultaneous ringing
RFC 3261
basic shared lines
dialog/reg. package
barge-in
Join
“Take”
Replaces
message summary
package
Shared-line “privacy”
dialog package
call forward
RFC 3261
divert to admin
RFC 3261
call park
RFC 3515/Replaces
intercom
URI convention
call pickup
Replaces
auto attendant
RFC 3261/2833
do not disturb
RFC 3261
attendant console
dialog package
call coverage
RFC 3261
night service
RFC 3261
attendant features
March 5, 2004
16
from Rohan Mahy’s VON Fall 2003 talk
Example SIP phones
about $85
March 5, 2004
17
SIP architecture biases





International  no national
variants
Internet = intranet
separation of data and
signaling
 signaling nodes can be
anywhere
end-to-end security where
possible, hop-by-hop
otherwise
 S/MIME bodies
 TLS (sips:)
end system control of
information


proxies can
 inspect, modify and add
headers
 may be able to inspect the
message body (if not
encrypted)
 should not modify the
message body  may
break end-to-end integrity
no security by obscurity
 don’t rely on address or
network hiding
March 5, 2004
18
SIP, SIPPING & SIMPLE –00 drafts
70
60
50
40
SIP
SIPPING
SIMPLE
30
20
10
0
1999
2000
2001
2002
2003
includes draft-ietf-*-00
and
draft-personal-*-00
March 5, 2004
19
Ubiquitous computing 
Location-based services 
Emergency calling
March 5, 2004
20
What is ubiquitous
computing?


“Ubiquitous computing has as its goal the enhancing computer use by
making many computers available throughout the physical environment,
but making them effectively invisible to the user.” (Weiser, 1993)
“Ubiquitous computing is not virtual reality, it is not a Personal Digital
Assistant (PDA) such as Apple's Newton, it is not a personal or intimate
computer with agents doing your bidding. Unlike virtual reality,
ubiquitous computing endeavers to integrate information displays into
the everyday physical world. It considers the nuances of the real world
to be wonderful, and aims only to augment them.” (Weiser, 1993)
March 5, 2004
21
Ubiquitous computing aspects




Also related to pervasive computing
Mobility, but not just cell phones
Computation and communications
Integration of devices
 “borrow” capabilities found in the environment  composition
into logical devices
 seamless mobility  session mobility
 adaptation to local capabilities
 environment senses instead of explicit user interaction
 from small dumb devices to PCs

light switches and smart wallpaper
March 5, 2004
22
Context-aware communications



Traditional emphasis: communicate anywhere, anytime, any media  largely
possible today
New challenge: tailor reachability
Context-aware communications




context-aware services



voluntary and automatic
location-based services  privacy concerns



leveraging local resources
awareness of other users
sources of location information


modify when, how, where to be reached
 machine: context-dependent call routing
 human: convey as part of call for human usage
applies to other personal information
activity, reachability, capabilities, bio sensor data, …
emergency services as a location-based service
March 5, 2004
23
Context



context = “the interrelated conditions in which something exists
or occurs”
anything known about the participants in the (potential)
communication relationship
both at caller and callee
time
CPL
capabilities
caller preferences
location
location-based call routing
location events
activity/availability
presence
sensor data (mood, bio)
not yet, but similar in many aspects to
location data
March 5, 2004
24
Location-based services


Finding services based on location
 physical services (stores, restaurants, ATMs, …)
 electronic services (media I/O, printer, display, …)
 not covered here
Using location to improve (network) services
 communication


configuration


devices in room adapt to their current users
awareness


incoming communications changes based on where I am
others are (selectively) made aware of my location
security

proximity grants temporary access to local resources
March 5, 2004
25
GEOPRIV and SIMPLE
architectures
rule
maker
rule
interface
target
presentity
caller
publication
interface
PUBLISH
INVITE
location
server
presence
agent
notification
interface
location
recipient
GEOPRIV
watcher
SIP
presence
SUBSCRIBE
NOTIFY
INVITE
callee
SIP
call
March 5, 2004
26
SIP URIs for locations
location beacon

Identify confined locations
by a SIP URI, e.g.,
sip:[email protected]


Register all users or
devices in room
Allows geographic
anycast: reach any party
in the room
sip:rm815
Contact: bob
[email protected]:
128.59.16.1
Contact: alice
Room 815
March 5, 2004
27
Location-based SIP services



Location-aware inbound routing
 do not forward call if time at callee location is [11 pm, 8 am]
 only forward time-for-lunch if destination is on campus
 do not ring phone if I’m in a theater
outbound call routing
 contact nearest emergency call center
 send [email protected] to nearest branch
location-based events
 subscribe to locations, not people
 Alice has entered the meeting room
 subscriber may be device in room  our lab stereo changes CDs
for each person that enters the room
March 5, 2004
28
Presence policy
SUBSCRIBE
subscription
policy
subscriber (watcher)
for each
watcher
event generator
policy
subscriber
filter
rate limiter
change to previous
notification?
NOTIFY
March 5, 2004
29
Example: user-adaptive device
configuration
“all devices that are in the building”
RFC 3082?
802.11 signal
strength 
location
SLP
device
controller
REGISTER
To: 815cepsr
Contact: alice@cs
PA
HTTP
tftp
SUBSCRIBE
to each room
1. discover room URI
2. REGISTER as contact for room URI
SIP
room 815
SUBSCRIBE to configuration
for users currently in rooms
March 5, 2004
30
Location-based services in
CINEMA


Initial proof-of-concept implementation
Integrate devices:


lava lamp via X10 controller  set personalized light mood
setting
Pingtel phone  add outgoing line to phone and register
user



painful: needs to be done via HTTP POST request
stereo  change to audio CD track based on user
Sense user presence and identity:







passive infrared (PIR) occupancy sensor
magnetic swipe card
ibutton
BlueTooth equipped PDA
IR+RF badge (in progress)
RFID (future)
biometrics (future)
March 5, 2004
31
Location-based IM & presence
March 5, 2004
32
Emergency (911) services


Old wireline and wireless
models don’t work any more
All wireline systems are
potentially mobile (nomadic)

device bought in Belgium
place call in Canada
with VSP in Mexico
and maybe a VPN for extra
excitement…






Customer may not have a
traditional voice carrier at all


corporate
residential  VSP in a
different country
Needs to work
internationally


Components:





same standards
no custom configuration
universal identifier  “sos”
configure local emergency
numbers
find right PSAP
identify and verify PSAP
On-going effort in IETF and
NENA
March 5, 2004
33
Location-based call routing – UA
knows its location
GPS
INVITE sips:sos@
40.86N 73.98E
CN=us A1=NJ A2=Bergen
outbound
proxy server
leonia.nj.us.sos.arpa
POLY 40.85 73.97 40.86 73.99
NAPTR … [email protected]
provided
by local
ISP?
DHCP
40.86N 73.98E: Leonia, NJ fire dept.
March 5, 2004
34
DHCP for locations


modified dhcpd (ISC) to generate location information
use MAC address backtracing to get location information
8:0:20:ab:d5:d
DHCP
server
CDP + SNMP
8:0:20:ab:d5:d  458/17
458/17  Rm. 815
458/18  Rm. 816
DHCP answer:
sta=DC loc=Rm815
lat=38.89868 long=77.03723
March 5, 2004
35
Location-based call routing –
network knows location
TOA
outbound proxy
IP
include location
info in 302
INVITE sips:sos@
INVITE sips:[email protected]
48° 49' N 2° 29' E
map location to
(SIP) domain
March 5, 2004
36
Service creation
March 5, 2004
37
PSTN vs. VoIP and the role of
carriers

PSTN: only carriers can get full signaling
functionality (SS7)



UNI vs. NNI signaling
VoIP: same signaling, same functionality
Application-layer service providers (VSP) ≠ networklayer service provider


enterprise may run its own services
Columbia doesn’t use an ‘email service provider’…
March 5, 2004
38
Network vs. end system services

Really two meanings:
 services implemented in user agent (instead of proxy)
 services implemented in server run by end user (instead of
carrier) 




business
residential
Variation on old Centrex vs. PBX argument
 except that media routing no longer an issue
Often, services require or can use both:
 e.g., the history of speed dial



CLASS service: translation in CO
(semi)intelligent end systems: locally, possibly with hotsync to PC
intelligent end system, but network-synchronized
March 5, 2004
39
Call routing services


Outsourcing allows temporarily disconnected end
users
Staged service:
carrier proxy
user proxy
basic call
routing
personal
preferences
March 5, 2004
40
Carrier services: Identity
management

Identity assertion (notary) services





Anonymity services


best done by larger organization
server certificates
name recognition
recourse
needs to have large user population to provide effective
hiding
Portable services

high availability and universal reachability
March 5, 2004
41
Service creation



Tailor a shared infrastructure to individual users
traditionally, only vendors (and sometimes carriers)
learn from web models
programmer,
carrier
end user
network servers SIP servlets,
sip-cgi
CPL
end system
VoiceXML (voice),
LESS
VoiceXML
March 5, 2004
42
Call Processing Language
(CPL)




XML-based “language” for processing requests
intentionally restricted to branching and subroutines
no variables (may change), no loops
thus, easily represented graphically






and most bugs can be detected statically
termination assured
mostly used for SIP, but protocol-independent
integrates notion of calendaring (time ranges)
structured tree describing actions performed on call setup event
top-level events: incoming and outgoing
March 5, 2004
43
CPL

Location set stored as implicit global variable


Switches:







operations can add, filter and delete entries
address
language
time, using CALSCH notation (e.g., exported from Outlook)
priority
Proxy node proxies request and then branches on response (busy,
redirection, noanswer, ...)
Reject and redirect perform corresponding protocol actions
Supports abstract logging and email operation
March 5, 2004
44
CPL example
busy
Call
String-switch
field: from
location
url: sip:jones@
example.com
proxy
timeout: 10s
timeout
failure
match:
*@example.com
otherwise
location
url: sip:jones@
voicemail.
example.com
merge: clear
redirect
March 5, 2004
45
CPL example
<?xml version="1.0" ?>
<!DOCTYPE call SYSTEM "cpl.dtd">
<cpl>
<incoming>
<lookup source="http://www.example.com/cgi-bin/locate.cgi?user=jones"
timeout="8">
<success>
<proxy />
</success>
<failure>
<mail url="mailto:[email protected]&Subject=lookup%20failed" />
</failure>
</lookup>
</incoming>
</cpl>
March 5, 2004
46
Service creation environment for
CPL and LESS
March 5, 2004
47
Security issues
March 5, 2004
48
Security issues: Threats

Fraud




authentication (Digest)
VSP-provided customer
certificates for S/MIME
authenticated identity body

DOS attacks


User privacy and
confidentiality

SIP spam




domain-based
authentication
trait-based authentication
(future)
return calls
reputation systems



layered protection
TLS and S/MIME for
signaling
SRTP for media streams
IPsec unlikely (host vs.
person)
Needs to work across
domains and
administrations
March 5, 2004
49
DOS attack prevention
port filtering (SIP only)
address-based rate limiting
return routability
authentication
UDP: SIP
TCP: SYN attack precautions needed
SCTP: built-in
March 5, 2004
50
Denial-of-service attacks –
signaling

attack targets:







DNS for mapping
SIP proxies
SIP end systems at PSAP
amplification  only if no routability
check, no TCP, no TLS
state exhaustion  no state until
return routability established
bandwidth exhaustion  no defense
except filters for repeats
one defense: big iron & fat pipe
danger of false positives
unclear: number of DOS
attacks using spoofed IP
addresses

types of attacks:




mostly for networks not
following RFC 2267 (“Network
Ingress Filtering: Defeating
Denial of Service Attacks
which employ IP Source
Address Spoofing”)
limit impact of DOS: require
return routability



built-in mechanism for SIP
(“null authentication”)
also provided by TLS
allow filtering of attacker IP
addresses (pushback)
March 5, 2004
51
TLS

End-to-end security 
S/MIME



but PKI issues
proxy inspection of
messages
TLS as convenient
alternatives



Digest
home.com
need only server
certificates
allows inspection for 911
services and CALEA
hop-by-hop
March 5, 2004
52
TLS performance
March 5, 2004
53
TLS performance
Key Size vs Time taken to initiate, setup and complete a SSL connection
1800
1600
Time (milliseconds)
1400
1200
1000
800
600
400
200
0
1024
2048
4096
Key siz e ( b it s)
Time taken to send connection request to server
Time taken to accept connection request from client
Time taken to send connection accept to client over network
March 5, 2004
54
TLS performance
Key Size Vs Total time taken to set up a SSL connection
1800
1600
1400
Time (Milliseconds)
1200
1000
800
600
400
200
0
1024
2048
4096
Key Size (Bits)
Total time taken to setup SSL connection at the client
Total time taken to setup SSL connection at the server
March 5, 2004
55
Conclusions




SIP: missing piece for
 session-based services
 general event notification  presence
Location-based and context-aware services
 e.g., emergency calling
Service creation  from global to local killer app
 challenge: automated configuration and deployment
Security: layered approach
 email and web approaches apply
 can hopefully offer stronger caller authentication
 TLS as deployable version of PKI
March 5, 2004
56