View
213
Download
0
Category
Preview:
Citation preview
March 5, 2004
Henning Schulzrinne
Columbia University(Sprint Labs, Burlingame, CA)
Global UbiquitousComputing
2March 5, 2004
Agenda
SIP overview SIP for ubiquitous computing Location-based services Emergency calling Services, carriers and service creation Security issues
3March 5, 2004
SIP Overview
4March 5, 2004
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
5March 5, 2004
Filling in the protocol gapService/delivery synchronous asynchronous
push SIP
RTSP, RTP
SMTP
pull HTTP
ftp
SunRPC, Corba, SOAP
(not yet standardized)
6March 5, 2004
SIP as service enabler Rendezvous protocol
lets users find each other by only knowing a permanent identifier
Mobility enabler: personal mobility
one person, multiple terminals
terminal mobility one terminal, multiple IP
addresses session mobility
one user, multiple terminals in sequence or in parallel
service mobility services move with user
7March 5, 2004
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
8March 5, 2004
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
9March 5, 2004
Basic SIP message flow
10March 5, 2004
SIP trapezoid
SIP trapezoid
outbound proxy
a@foo.com: 128.59.16.1
registrar
1st request
2nd, 3rd, … request
voice trafficRTP
destination proxy(identified by SIP URI domain)
11March 5, 2004
SIP message format
SDP
INVITE sip:bob@there.com SIP/2.0
Via: SIP/2.0/UDP here.com:5060From: Alice <sip:alice@here.com>To: Bob <sip:bob@there.com>Call-ID: 1234@here.comCSeq: 1 INVITESubject: just testingContact: sip:alice@pc.here.comContent-Type: application/sdpContent-Length: 147
v=0o=alice 2890844526 2890844526 IN IP4 here.coms=Session SDPc=IN IP4 100.101.102.103t=0 0m=audio 49172 RTP/AVP 0a=rtpmap:0 PCMU/8000
SIP/2.0 200 OK
Via: SIP/2.0/UDP here.com:5060From: Alice <sip:alice@here.com>To: Bob <sip:bob@there.com>Call-ID: 1234@here.comCSeq: 1 INVITESubject: just testingContact: sip:alice@pc.here.comContent-Type: application/sdpContent-Length: 134
v=0o=bob 2890844527 2890844527 IN IP4 there.coms=Session SDPc=IN IP4 110.111.112.113t=0 0m=audio 3456 RTP/AVP 0a=rtpmap:0 PCMU/8000m
essa
ge b
ody
head
er fi
elds
requ
est l
ine
request response
12March 5, 2004
RFC 3261 Backward compatible with RFC 2543 – no new version Major changes:
specification behavior-oriented, not header-oriented e.g., separation into ‘layers’
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
“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
13March 5, 2004
PSTN vs. Internet Telephony
Signaling & Media Signaling & Media
Signaling Signaling
Media
PSTN:
Internettelephony:
China
Belgian customer,currently visiting US
Australia
14March 5, 2004
SIP addressing Users identified by SIP or tel URIs
sip:alice@example.com 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 sequential & parallel forking
SIP URIs can be created dynamically: GRUUs conferences device identifiers (sip:foo@128.59.16.15)
Registration binds SIP URIs (e.g., device addresses) to SIP “address-of-record” (AOR)
tel:110 sip:sos@domain
domain 128.59.16.17via NAPTR + SRV
15March 5, 2004
3G Architecture (Registration)
visited IM domain
home IM domain
servingCSCF
interrogating
proxy
interrogating
mobility managementsignaling
registration signaling (SIP)_
16March 5, 2004
SIP is PBX/Centrex readycall waiting/multiple calls
RFC 3261
hold RFC 3264
transfer RFC 3515/Replaces
conference RFC 3261/callee caps
message waiting message summary package
call forward RFC 3261
call park RFC 3515/Replaces
call pickup Replaces
do not disturb RFC 3261
call coverage RFC 3261
from Rohan Mahy’s VON Fall 2003 talk
simultaneous ringing RFC 3261
basic shared lines dialog/reg. package
barge-in Join
“Take” Replaces
Shared-line “privacy” dialog package
divert to admin RFC 3261
intercom URI convention
auto attendant RFC 3261/2833
attendant console dialog package
night service RFC 3261
centr
ex-s
tyle
featu
res
boss/admin features
attendant features
17March 5, 2004
Example SIP phones
about $85
18March 5, 2004
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
19March 5, 2004
SIP, SIPPING & SIMPLE –00 drafts
0
10
20
30
40
50
60
70
1999 2000 2001 2002 2003
SIPSIPPINGSIMPLE
includes draft-ietf-*-00and draft-personal-*-00
20March 5, 2004
Ubiquitous computing Location-based services Emergency calling
21March 5, 2004
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)
22March 5, 2004
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
23March 5, 2004
Context-aware communications Traditional emphasis: communicate anywhere, anytime, any media largely
possible today New challenge: tailor reachability Context-aware communications
modify when, how, where to be reached machine: context-dependent call routing human: convey as part of call for human usage
context-aware services leveraging local resources awareness of other users
sources of location information voluntary and automatic
location-based services privacy concerns applies to other personal information activity, reachability, capabilities, bio sensor data, …
emergency services as a location-based service
24March 5, 2004
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
25March 5, 2004
“Legacy” IM & presence systems SIP-based systems centralized systems (single name space)
federated systems, similar to email mostly instant text messages
media-agnostic – transmit any media object separate from session-based services (VoIP, video
conferencing)integrated:
use IM as part of media sessionsuse presence to facilitate session setup
limited presence status, mostly manually setrich presence, with time informationimported from sensors, calendars, backend systems, …
proprietary systems (AOL, Yahoo!, MSN, ICQ, …)standards-based systems
26March 5, 2004
Presence and event notification Presence = special case of
event notification “user Alice is available for
communication” Human users:
multiple contacts per presentity device (cell, PDA, phone, …) service (“audio”)
activities, current and planned surroundings (noise, privacy,
vehicle, …) contact information composing (typing, recording
audio/video IM, …)
Multimedia systems: REFER (call transfer) message waiting indication conference floor control conference membership push-to-talk system configuration
General events: emergency alert (“reverse
911”) industrial sensors (“boiler
pressure too high”) business events (“more than
20 people waiting for service”)
27March 5, 2004
IETF efforts SIP, SIPPING and SIMPLE working groups
but also XCON (conferencing) Define SIP methods PUBLISH, SUBSCRIBE, NOTIFY GEOPRIV:
geospatial privacy location determination via DHCP information delivery via SIP, HTTP, … privacy policies
SIMPLE: architecture for events and presence configuration (XCAP) session-oriented IM (↔ page mode) filtering, rate limiting and authorization
28March 5, 2004
RPID: rich presence
Provide watchers with better information about the what, where, how of presentities
facilitate appropriate communications: “wait until end of meeting” “use text messaging instead of phone call” “make quick call before flight takes off”
designed to be derivable from calendar information or provided by sensors in the environment
allow filtering by “sphere” – the parts of our life don’t show recreation details to colleagues
29March 5, 2004
RPID: rich presence
Classification: contact-type
device, in-person, service, presentity
class for labeling
sphere “work”, “home”, …
relationship “family”, “associate”,
“assistant”, “supervisor”
Activities: activity
“on-the-phone”, “away”, “appointment”, …
idle last usage of device
Surroundings: placetype
“home”, “office”, “industrial”, …
privacy “public”, “private”
30March 5, 2004
CIPID: Contact Information
More long-term identification of contacts Elements:
card – contact Information home page icon – to represent user map – pointer to map for user sound – presentity is available
31March 5, 2004
Timed Status Presence is about here & now but often only have (recent)
past – e.g., calendar or future
“will be traveling in two hours” “will be back shortly”
allows watcher to plan communication
loose synchronization of calendars
<tuple id="7c8dqui">
<contact> sip:bob@example.com</contact><status> <basic>open</basic></status>
<fs:timed-statusfrom="2003-08-15T10:20:00.000-
05:00“until="2003-08-22T19:30:00.000-
05:00"><basic>closed</basic></fs:timed-status></tuple><note>I'll be in Tokyo next
week</note>
32March 5, 2004
GEOPRIV and SIMPLE architectures
targetlocationserver
locationrecipient
rulemaker
presentity
caller
presenceagent
watcher
callee
GEOPRIV
SIPpresence
SIPcall
PUBLISHNOTIFY
SUBSCRIBE
INVITE
publicationinterface
notificationinterface
XCAP(rules)
INVITE
DHCP
33March 5, 2004
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
incoming communications changes based on where I am configuration
devices in room adapt to their current users awareness
others are (selectively) made aware of my location security
proximity grants temporary access to local resources
34March 5, 2004
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 delivery@pizza.com 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
35March 5, 2004
DHCP for locations modified dhcpd (ISC) to generate location information use MAC address backtracing to get location information
DHCPserver
458/17 Rm. 815458/18 Rm. 816
DHCP answer:sta=DC loc=Rm815lat=38.89868 long=77.03723
8:0:20:ab:d5:d
CDP + SNMP8:0:20:ab:d5:d 458/17
36March 5, 2004
SIP URIs for locations
Identify confined locations by a SIP URI, e.g., sip:rm815@cs.columbia.edu
Register all users or devices in room
Allows geographic anycast: reach any party in the room
a@foo.com: 128.59.16.1
Room 815
sip:rm815
location beacon
Contact: alice
Contact: bob
37March 5, 2004
Presence policy
subscriptionpolicy
event generatorpolicy
subscriberfilter
rate limiter
change to previousnotification?
for eachwatcher
subscriber (watcher)
SUBSCRIBE
NOTIFY
38March 5, 2004
Policy relationships
geopriv-specific presence-specific
common policy
RPID CIPID
future
39March 5, 2004
Privacy rules
Conditions identity, sphere, validity time of day current location identity as <uri> or
<domain> + <except> Actions
watcher confirmation Transformations
include information reduced accuracy
User gets maximum of permissions across all matching rules
Extendable to new presence data rich presence biological sensors mood sensors
40March 5, 2004
Example: user-adaptive device configuration
“all devices that are in the building”RFC 3082?
PA
devicecontroller
SUBSCRIBEto each room
SUBSCRIBE to configurationfor users currently in rooms
1. discover room URI2. REGISTER as contact for room URI
tftp
HTTP
SLP
802.11 signal strength
location
REGISTERTo: 815cepsrContact: alice@cs
SIP
room 815
41March 5, 2004
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)
42March 5, 2004
Location-based IM & presence
43March 5, 2004
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 same standards no custom configuration
Components: universal identifier “sos” configure local emergency
numbers find right PSAP identify and verify PSAP
On-going effort in IETF and NENA
44March 5, 2004
Location-based call routing – UA knows its location
GPS
40.86N 73.98ECN=us A1=NJ A2=Bergen
INVITE sips:sos@
DHCP
outboundproxy server
provided by local ISP? 40.86N 73.98E: Leonia, NJ fire dept.
leonia.nj.us.sos.arpaPOLY 40.85 73.97 40.86 73.99NAPTR … firedept@leoniaboro.org
45March 5, 2004
Location-based call routing – network knows location
IP
48° 49' N 2° 29' E
TOA
include locationinfo in 302
INVITE sips:sos@ INVITE sips:sos@paris.gendarme.fr
map location to (SIP) domain
outbound proxy
46March 5, 2004
Service creation
47March 5, 2004
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) ≠ network-
layer service provider enterprise may run its own services Columbia doesn’t use an ‘email service provider’…
48March 5, 2004
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
49March 5, 2004
Call routing services
Outsourcing allows temporarily disconnected end users
Staged service:
carrier proxy user proxy
basic call routing
personalpreference
s
50March 5, 2004
Carrier services: Identity management
Identity assertion (notary) services best done by larger organization server certificates name recognition recourse
Anonymity services needs to have large user population to provide effective
hiding Portable services
high availability and universal reachability
51March 5, 2004
Service creation
programmer, carrier
end user
network servers SIP servlets, sip-cgi
CPL
end system VoiceXML VoiceXML (voice),
LESS
Tailor a shared infrastructure to individual users traditionally, only vendors (and sometimes carriers) learn from web models
52March 5, 2004
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
53March 5, 2004
CPL Location set stored as implicit global variable
operations can add, filter and delete entries Switches:
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
54March 5, 2004
CPL example
String-switchfield: from
match:*@example.com
otherwise
proxytimeout: 10s
locationurl: sip:jones@
example.comvoicemail.
merge: clear
locationurl: sip:jones@
example.com
redirect
Call
busy
timeout
failure
55March 5, 2004
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:jones@example.com&Subject=lookup%20failed" /> </failure> </lookup> </incoming></cpl>
56March 5, 2004
Service creation environment for CPL and LESS
57March 5, 2004
Security issues
58March 5, 2004
Security issues: Threats
Fraud authentication (Digest) VSP-provided customer
certificates for S/MIME authenticated identity body
SIP spam domain-based
authentication trait-based authentication
(future) return calls reputation systems
DOS attacks layered protection
User privacy and confidentiality TLS and S/MIME for
signaling SRTP for media streams IPsec unlikely (host vs.
person) Needs to work across
domains and administrations
59March 5, 2004
DOS attack prevention
authentication
return routability
port filtering (SIP only)address-based rate limiting
UDP: SIPTCP: SYN attack precautions neededSCTP: built-in
60March 5, 2004
Denial-of-service attacks – signaling attack targets:
DNS for mapping SIP proxies SIP end systems at PSAP
types of attacks: 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 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)
61March 5, 2004
TLS End-to-end security
S/MIME but PKI issues proxy inspection of
messages TLS as convenient
alternatives need only server
certificates allows inspection for 911
services and CALEA hop-by-hop
home.comDigest
62March 5, 2004
TLS performance
63March 5, 2004
TLS performance
Key Size vs Time taken to initiate, setup and complete a SSL connection
0
200
400
600
800
1000
1200
1400
1600
1800
1024 2048 4096
Key size (bits)
Tim
e (
milliseco
nd
s)
Time taken to send connection request to serverTime taken to accept connection request from clientTime taken to send connection accept to client over network
64March 5, 2004
TLS performanceKey Size Vs Total time taken to set up a SSL connection
0
200
400
600
800
1000
1200
1400
1600
1800
1024 2048 4096
Key Size (Bits)
Tim
e (
Milliseco
nd
s)
Total time taken to setup SSL connection at the client Total time taken to setup SSL connection at the server
65March 5, 2004
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
Recommended