Download telekom - Columbia University

Henning Schulzrinne
(with Jong Yul Kim, Kundan Singh, Wonsang Song, Anshuman Rawat,
Matthew Mintz-Habib, Amrita Rajagopal and Xiaotao Wu)
Columbia University
Dept. of Computer Science
Making services bloom outside the walled garden
Overview
• Internet design philosophy – an attempt at a summary
• Advanced VoIP services and issues
– emergency calling
– location-based services
– secure VoIP
– spam/spit
– quality-of-service
• A peer-to-peer approach to VoIP
Telekom - February 2006
2
Internet philosophy
Telekom - February 2006
sockets
RJ-45
enterprise
consumer ISP
OS vendors
software
services
Yahoo iTunes
Google MSN
mySpace Skype
eBay
enterprise
consumer ISP
• Innovation is created at the edges
– providers benefit by increased
usage
– content innovation
• Wikipedia, Flickr, blogs,
eBay
• cf. WAP
– service innovation
• IM, Skype, distributed games
• Reliability and ubiquity are
created by the network
– room for improvement (99.5%
now)
services & applications
(HTTP, SIP, RTSP, …)
ISP
(IP, DHCP, DNS)
network access
(fiber, copper,
wireless)
natural
monopoly or
oligopoly
geographic
range
3
Internet philosophy
Telekom - February 2006
sockets
RJ-45
enterprise
consumer ISP
OS vendors
software
services
Yahoo iTunes
Google MSN
mySpace Skype
eBay
enterprise
consumer ISP
• Small number of narrow and stable
interfaces:
– HTML (+ PDF, flash) for content
– socket API for applications
– RJ-45 (Ethernet) for landline &
enterprise
– 802.11/16/… for wireless
• Provides sufficient scale as incentive
– reduces uncertainty on platform and
access
• Allows same applications in enterprise
and consumer space
– cf. difficulty with wireless
applications
• Allows same company to provide all
three layers
– avoids collapse of monopoly rent if
bypass succeeds
services & applications
(HTTP, SIP, RTSP, …)
ISP
(IP, DHCP, DNS)
network access
(fiber, copper,
wireless)
natural
monopoly or
oligopoly
geographic
range
4
IP “hourglass”
email WWW phone...
SMTP HTTP RTP...
TCP UDP…
IP
ethernet PPP…
CSMA async sonet...
copper fiber radio...
Telekom - February 2006
Steve Deering,
IETF Aug. 2001
5
The real Internet hourglass (slightly simplified)
p2p (port 80)
web
web services
HTTP
TCP
IP
Ethernet
Telekom - February 2006
6
Internet eco-system
geography
customer
choice
expertise
customer
interaction
income
services &
content
international
dozens to
infinite
software
server farms
marketing
almost none
(anonymous, selfservice)
advertising
pre-pay
ISP
regional &
national
handful
BGP
SNMP
limited
phone support
rent
pre-pay (wireless)
network
access
regional &
national
handful
construction
fiber splicing
RF propagation
truck roll
hardware
rent
IRUs
Telekom - February 2006
7
Walled gardens
• Walled garden = certain applications can only be provided by the
access provider (e.g., wireless carrier)
– due to handset lockdown
– due to network restrictions
– due to lack of service interface (e.g., QoS)
• Economic argument: “provides monopoly rent”
– variation: don’t just want to be “dumb bit pipe”
– but marketing, size, trust advantages don’t depend on this
• Technical argument: “reliable, consumer-friendly services require it”
• Hard to make work for corporations
– doesn’t integrate well with enterprise networks and applications
– at best, requires extra servers (BlackBerry email)
• Corporations and universities don’t have email carriers, either
– some may outsource (e.g., to gmail)
• VoIP: large enterprises may contract directly with PSTN gateway
provider
– everything else can be run in-house
Telekom - February 2006
8
Stakeholders and arguments
• Customers
– low cost
– avoid lock-in
– new applications and services
– ease of use
• Carriers
– extract differential value of different kinds of bits
• user value of voice vs. email vs. web vs. video
– avoid commodization
• “Technically necessary” vs. “good for my business”
• Will focus on technical issues
Telekom - February 2006
9
Network neutrality
• = network does not favor particular applications (or packets)
–
does not filter, drop, delay based on ports, sources or destinations
–
“information networks ought to be as neutral as possible between competing content,
applications and services” (Wikipedia)
• more precise: same services available to everyone, as unbundled service elements
–
e.g., if QoS, can be purchased separately
–
e.g., location available without buying restaurant guide
• FCC: Powell 2004
–
Consumers are entitled to access the lawful Internet content of their choice;
–
Consumers are entitled to run applications and services of their choice, subject to the
needs of law enforcement;
–
Consumers are entitled to connect their choice of legal devices that do not harm the
network; and
–
Consumers are entitled to competition among network providers, application and service
providers, and content providers.
• Legal discussion in the US
–
revision of Telecom Act of 1996
• Variations (Wikipedia)
–
Most Favored Nation: operators must offer to all companies transit on equal terms, and
cannot discriminate as between them;
–
Radical Bit Anti-Discrimination: operators must pass all packets blindly, and never make
any decisions based on information specific to any packet;
–
Enough and as Good: if operators prioritize bandwidth, they must leave enough and as
good bandwidth to permit non-prioritized services to reach consumers;
–
Tiering only: Operators may discriminate as between their customers, but must offer the
same services to content, application and service providers;
–
Police what you own: Operators may exercise discrimination with respect to entirely
private networks, but not inter-networks.
Telekom - February 2006
10
Evolution of VoIP
“how can I make it
stop ringing?”
long-distance calling,
ca. 1930
“amazing – the
phone rings”
1996-2000
“does it do
call transfer?”
going beyond
the black phone
catching up
with the digital PBX
2000-2003
Telekom - February 2006
200411
Classical IETF interfaces
“UNI”
host
end system
UA
signaling
name
mapping
L3 config
L3
L2
router
proxy
server
“NNI”
SIP
SIP
DNS
DNS
DHCP, PPP
BGP
OSPF
IPv4/IPv6
IPv4/IPv6
Ethernet
SONET
Telekom - February 2006
12
Interconnection approaches
Property
NGN, 3GPP
“Internet”
interconnection
per service
service neutral
end device control
carrier-controlled
user-provided
end device type
mostly hardware
software, maybe hardware
state preference
call state-full
stateless
transaction-stateful
interconnect arrangement
pre-arranged
serendipitous
interconnect discovery
pre-configured
DNS
billing preference
per service
usage-based
bandwidth-based
services fixed-rate or ad-supported
billing arrangement
clearing house
sender keeps
independent
Telekom - February 2006
13
SIP division of labor
proxy
B2BUA
UA
State
stateless
transaction-stateful
call stateful
call stateful
Headers
inspect
insert
modify (rarely)
inspect
insert
modify
inspect
reflect
Bodies
ignore
some inspect
inspect
insert
modify
inspect
Fork
yes
separate call legs
no
Media
no
maybe
yes
Services
rendezvous
call routing
call stateful
media-related
Telekom - February 2006
14
IETF “4G” (access-neutral) model
Check
reputation of
columbia.edu
sip:[email protected] 
sip:[email protected]
TLS
columbia.edu
example.com
Visited
network
NSIS NTLP
for QoS
802.1x
DIAMETER
server
AP
[email protected]
isp.net
Telekom - February 2006
15
Emergency calling
emergency call
• Location-based service 
center
– route calls to best PSAP based on caller’s location
– deliver location information to PSAP to dispatch help
• Has to work even if
– caller is roaming
– has a VSP from another country (or no VSP)
– bought phone in Finland
• But also supports
– better resiliency during catastrophes (Katrina-like events)
– multimedia
– situational awareness
• Standardization efforts:
– IETF ECRIT working group  protocols
– NENA (National Emergency Number Association)  requirements,
overall architecture, transition
– ETSI EMTEL  architecture? requirements?
• Implemented all-IP prototype at Columbia University
– testing with real PSAPs
Telekom - February 2006
16
Components of emergency calling
Contact well-known
number or identifier
Route call to locationappropriate PSAP
Deliver precise location
to call taker to dispatch
emergency help
now
transition
all IP
112
911
112
911
dial 112, 911
signal sos@
selective
router
VPC
DNS
phone
number 
location
(ALI lookup)
in-band  key
 location
in-band
Telekom - February 2006
17
The core emergency calling problem
Voice Service Provider (VSP)
sees emergency call
but does not know caller location
ISP/IAP knows user location
but does not handle call
Telekom - February 2006
18
UA recognition & UA resolution
DHCP (w/loc)
LLDP-MED (L2)
GPS (outdoors)
mapping
location  URL
leonianj.gov
9-11
INVITE sip:[email protected]
To: urn:service:sos
INVITE sip:[email protected]
To: urn:service:sos
<location>
<location>
Telekom - February 2006
19
UA recognition & proxy resolution
mapping
provider.com
9-11
INVITE urn:service:sos
To: urn:service:sos
INVITE sip:[email protected]
To: urn:service:sos
<location>
<location>
Telekom - February 2006
20
UA recognition & proxy resolution
(proxy location determination)
mapping
provider.com
9-11
INVITE urn:service:sos
To: urn:service:sos
INVITE sip:[email protected]
To: urn:service:sos
<location>
how does
proxy insert
location?
redirect?
Telekom
- February 2006
21
Proxy recognition & proxy resolution
mapping
provider.com
9-11
INVITE sip:[email protected];user=phone
To: sip:[email protected];user=phone
INVITE sip:[email protected]
To: sip:[email protected];user=phone
Location: <location>
Telekom - February 2006
22
LUMP architecture
G
tree guide
G
G
G
T1: .us
G
broadcast (gossip)
T2: .de
resolver
seeker
313 Westview
Leonia, NJ US
T2
T1
(.de)
T3
(.dk)
(.us)
Leonia, NJ  sip:[email protected]
Telekom - February 2006
23
Location-based services
• Guidance and mapping services
–
including meta-data such as traffic information
• Finding services based on location
–
–
–
physical services (stores, restaurants, ATMs, …)
electronic services (media I/O, printer, display, …)
needs to use end system location information
• Using location to improve (network) services
–
communication
• incoming communications changes based on where I am
• proximity triggers communications
–
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
Telekom - February 2006
24
GEOPRIV and SIMPLE architectures
rule
maker
DHCP
XCAP
(rules)
target
publication
interface
location
server
PIDF-LO
presentity
caller
PUBLISH
INVITE
presence
agent
notification
interface
location
recipient
GEOPRIV
watcher
SIP
presence
SUBSCRIBE
NOTIFY
INVITE
Telekom - February 2006
callee
SIP
call
25
The role of presence for call routing
• Presence as cross-system glue
– narrow interface for location
information, device state, user
behavior, …
• Two modes:
– watcher uses presence information
to select suitable contacts
• advisory – caller may not adhere
to suggestions and still call
when you’re in a meeting
– user call routing policy informed by
presence
• likely less flexible – machine
intelligence
• “if activities indicate meeting,
route to tuple indicating
assistant”
• “try most-recently-active
contact first” (seq. forking)
PUBLISH
PA
translate
RPID
CPL
NOTIFY
LESS
INVITE
Telekom - February 2006
26
Location data & privacy
• Location =
– civic location (street)
– geo (longitude + latitude)
– descriptive (“hotel”)
• All presence data, particularly
location, is highly sensitive
• Basic location object (PIDF-LO)
describes
– distribution (binary)
– retention duration
• Policy rules for more detailed
access control
– who can subscribe to my
presence
– who can see what when
<tuple id="sg89ae">
<status>
<gp:geopriv>
<gp:location-info>
<gml:location>
<gml:Point gml:id="point1“
srsName="epsg:4326">
<gml:coordinates>37:46:30N 122:25:10W
</gml:coordinates>
</gml:Point>
</gml:location>
</gp:location-info>
<gp:usage-rules>
<gp:retransmission-allowed>no
</gp:retransmission-allowed>
<gp:retention-expiry>2003-06-23T04:57:29Z
</gp:retention-expiry>
</gp:usage-rules>
</gp:geopriv>
</status>
<timestamp>2003-06-22T20:57:29Z</timestamp>
</tuple>
Telekom - February 2006
27
Presence & location privacy rules
• Conditions
• User gets maximum
– identity, sphere,
of permissions
validity
across all matching
– time of day
rules
– current location
• Extendable to new
– identity as <uri> or
presence data
<domain> + <except>
– rich presence
• Actions
– biological sensors
– watcher confirmation
– mood sensors
• Transformations
– include information
– reduced accuracy
Telekom - February 2006
28
<actions>
<conditions>
<transformations>
<ruleset>
Example privacy rules document
<rule id=1>
<identity><id>[email protected]</id></identity>
<sub-handling>allow</sub-handling>
<provide-services>
<service-uri-scheme>sip</service-uri-scheme>
<service-uri-scheme>mailto</service-uri-scheme>
</provide-services>
<provide-person>true</provide-person>
<provide-activities>true</provide-activities>
<provide-user-input>bare</provide-user-input>
Telekom - February 2006
29
Location-based service language
NOTIFY
true
false
action
alert
IM
proximity
conditions
occupancy
time
actions
alert
incoming
message
outgoing
log
call
transfer
events
notify
message
subscription
join
Telekom - February 2006
30
Secure VoIP
• What is security?
– Caller privacy protection: media + signaling
•  secure RTP (SRTP) + TLS or S/MIME
– Anonymity protection
• the anonymity of large providers
– Theft-of-service protection
• access link: 802.1x and similar (+ RADIUS)
• voice service: SIP Digest authentication +
RADIUS/DIAMETER for roaming
• Conflicts of goals
– theft-of-service protection ↔ emergency calling
– anonymity, caller privacy ↔ legal intercept
Telekom - February 2006
31
Secure VoIP, cont’d.
• Assume secure channel (TLS) and/or SIP payload (S/MIME)
• Session keys are exchanged in-band between parties
– e.g., via SDP
• Used for SRTP keying
• Possibly use SIP preconditions to require use of secure
channel and negotiate crypto algorithms
Telekom - February 2006
32
Quality of service
selfinterference
backbone
access links
peering
• QoS = packet-level loss & delay + reliability (longer outages)
– latter tends to be more of a problem…
• Per-flow resource reservation scales well in access networks
• Difficulty: most of the time, high-priority traffic sees same backbone
queueing delay (~0) and loss (0) as low-priority traffic
– thus, incentive to label traffic best effort most of the time
• Hypothesis: most QoS problems are self-interference and access link
problems
– can be solved with DiffServ and 802.11e
– may need rate limit for high-priority traffic on access link
Telekom - February 2006
33
New IETF signaling protocol architecture: NSIS
signaling-layer protocol
(NSLP)
NAT/FW, QoS,
measurement, …
transport layer (NTLP)
(GIST)
transport layer
(RA + UDP; TCP [+ TLS])
• Generalized version of RSVP:
– separating transport & signaling applications
– allows use of secure transport
– supports node mobility
• Support
Telekom - February 2006
34
Unsolicited calls and messages: “SPIT”
• SPIT = Spam for Internet
Telephony
– spim = spam for IM
• Possibly at least as large a
problem as email spam
– more annoying (ring, pop-up)
– Bayesian content filtering
unlikely to work
•  identity-based filtering
• PKI for every user unrealistic
• Use two-stage authentication
– well-proven domain-level
authentication via TLS certs
– SIP identity work  outbound
proxy certifies
• uses Digest auth locally
(shared secret)
• “I, example.com have
verified that this is Alice”\
• Also proposed:
– computational puzzles
– e-postage
mutual
PK authentication (TLS)
Digest
Telekom - February 2006
home.com
35
Spam for Internet Telephony (SPIT)
• Black lists only modestly helpful
– “bad” users can likely get fresh identities
 personal
whitelist
(called, emailed)
 domain
reputation
 user
reputation
relies on
trustable
identity
Telekom - February 2006
36
SPIT: domain classification
• Classification of domains based on their identity instantiation and
maintenance procedures plus other domain policies.
• Admission controlled domains
– Strict identity instantiation with long term relationships
• Example: Employees, students, bank customers
• Bonded domains
– Membership possible only through posting of bonds tied to a
expected behavior
• Membership domains
– No personal verification of new members but verifiable
identification required such as a valid credit card and/or payment
• Example: E-bay, phone and data carriers
• Open domains
– No limit or background check on identity creation and usage
• Example: Hotmail
• Open, rate limited domains
– Open but limits the number of messages per time unit and prevents
account creation by bots (CAPTCHA)
• Example: Yahoo
Telekom - February 2006
37
P2P for VoIP
• SIP VoIP is peer-to-peer
– media and mid-call requests are sent end-to-end
– but fixed server set registered in DNS for AOR domain
–  p2p = user nodes perform server functionality
• Motivation
– scalable growth: server count grows with user population
– quick deployment in network islands
– Skype envy 
• Functions that can be placed on peer-to-peer nodes
– Signaling and identifier mapping
• map AOR [email protected]  one or more contacts
– Presence
• publish and subscribe
– NAT traversal
• discover external IP address (STUN) + relaying where needed
– Media storage
• voice mail, ring tones, recordings, …
– Conferencing
• mixing and replication
Telekom - February 2006
38
P2P-SIP: Using an External P2P network (DHT)
• Service model
– Join DHT to provide service
• Data model
– Treat DHT as database
[5]
bob
[3]
[2]
bob
192.1.2.3
DHT
[1]
[4]
[3]
[5]
DHT
[1]
Service
node
(128.3.4.5)
alice
[2]
alice
[1] put(k,192.1.2.3), k is H(bob)
[2] get(k) gives 192.1.2.3
[3] INVITE sip:bob to 192.1.2.3
[1]
[2]
[3]
[4]
[5]
join(128.3.4.5)
lookup(H(bob)) gives 128.3.4.5
REGISTER sip:bob to 128.3.4.5
lookup(H(bob)) gives 128.3.4.5
INVITE sip:bob to 128.3.4.5
Telekom - February 2006
39
P2P-SIP: Logical Operations
• Contact management
– put (user id, signed contact)
• Key storage
– User certificates and private configurations
• Presence
– put (subscribee id, signed encrypted subscriber id)
– Composition needs service model
• Offline message
– put (recipient, signed encrypted message)
• NAT and firewall traversal
– STUN and TURN server discovery needs service model
Telekom - February 2006
40
P2P-SIP: Implementation in SIPc
• OpenDHT
– Trusted nodes
– Robust
– Fast enough (<1s)
• Identity protection
– Certificate-based
– SIP id == email
• P2P for
Calls, IM, presence,
offline message,
STUN server discovery
and name search
Telekom - February 2006
41
P2P-SIP: What is OpenDHT?
• Service model, unlike earlier library model of Chord or CAN
– DHT accessed via SunRPC & XML-RPC
– Easy deployment and maintenance
• 200-300 Bamboo DHT nodes on PlanetLab
– Public DHT service running since April 2004
– Many existing applications: i3, CFS, Ostream, HIP,…
• DHT API (server side on Bamboo nodes)
– PUT(key,value,H(secret),ttl) where H() is SHA1
– GET(key)  (value,H(secret),remaining-ttl)
– REMOVE(key,H(value),secret,ttl)
• ReDiR API (client side for lookup/join/leave)
– Can build anycast, multicast, range search using this
• Fair resource (disk) allocation among clients (IP addr)
Telekom - February 2006
42
Hybrid architecture
• Cross register, or
• Locate during call setup
– DNS, or
– P2P-SIP hierarchy
Telekom - February 2006
43
Concerns about 3G + NGN
• Complexity
– many signaling hops  server cost, delay
• Assumption of heavy-weight peering
– “lawyer employment act of 2004”
– rather than email-style “all I need is a name” peering
• Coupling of application signaling and network signaling
– incentive to bypass if cost/byte is higher
– makes it more costly to add new QoS-sensitive
applications
• IPTV, remote instrumentation, etc.
– got us tromboning before: mobility issues
Telekom - February 2006
44
Conclusion
• Importance of few, narrow, stable interfaces
• Finished or emerging solutions for providing
– emergency calling
– location-based services
– VoIP security
– SPIT protection
– QoS
• as building blocks, not monolithic architecture
– allow change as technology improves
• Walled gardens are failure prone
– if wall falls, sudden collapse ($1/minute  0 minutes)
• Client-server SIP complemented by peer-to-peer SIP
– quick setup situations
– low-cost installations (SOHO)
Telekom - February 2006
45