challenges of voice-over-ip – the second quarter century

1

Challenges of Voice-over-Challenges of Voice-over-IP – The Second Quarter IP – The Second Quarter CenturyCentury

Henning SchulzrinneDept. of Computer Science

Columbia University

2

OutlineOutline A brief history Challenges:

QoS Security NATs Service creation Scaling Interworking Emergency calls

CINEMA project at Columbia

3

A brief historyA brief history August 1974

Realtime packet voice between USC/ISI and MIT/LL, using CVSD and NVP.

December 1974 Packet voice between CHI and MIT/LL, using LPC and NVP

January 1976 Live packet voice conferencing between USC/ISI, MIT/LL,

SRI, using LPC and NVCP Approximately 1976

First packetized speech over SATNET between Lincoln Labs and NTA (Norway) and UCL (UK)

1990 ITU recommendation G.764 (Voice packetization –

packetized voice protocols)

4

A brief historyA brief history February 1991

DARTnet voice experiments August 1991

LBL's audio tool vat released for DARTnet use March 1992

First IETF MBONE broadcast (San Diego) January 1996

RTP standardized (RFC 1889/1890) November 1996

H.323v1 published February/March 1999

SIP standardized (RFC 2543)

5

VoIP applicationsVoIP applications Trunk replacements between PBXs

Ethernet trunk cards for PBXs T1/E1 gateways

IP centrex – outsourcing the gateway Denwa, Worldcom

Enterprise telephony Cisco Avvid, 3Com, Mitel, ...

Consumer calling cards (phone-to-phone) net2phone, iConnectHere (deltathree), ...

PC-to-phone, PC-to-PC net2phone, dialpad, iConnectHere, mediaring, ...

6

Where are we?Where are we? Variety of robust SIP phones (and

lots of proprietary ones) not yet in Wal-Mart

SIP carriers terminate LAN VoIP number portability? 911

50+ vendors at SIPit Building blocks: media servers,

unified messaging, conferencing, VoiceXML, …

7

Status in 2002Status in 2002

2000: 6b wholesale, 15b minutes retail

2001: 10b worldwide – 6% of traffic (only phone-to-phone)

e.g., net2phone: 341m min/quarter

8

Where are we?Where are we? Not quite what we had in mind

initially, SIP for initiating multicast conferencing

in progress since 1992 still small niche even the IAB and IESG meet by POTS conference…

then VoIP written-off equipment (circuit-switched) vs. new

equipment (VoIP) bandwidth is (mostly) not the problem “can’t get new services if other end is POTS’’

“why use VoIP if I can’t get new services”

9

Where are we?Where are we?

VoIP: avoiding the installed base issue cable modems – lifeline service 3GPP – vaporware?

Finally, IM/presence and events probably, first major application offers real advantage: interoperable

IM also, new service

10

VoIP at HomeVoIP at Home Lifeline (power) Multiple phones per household

expensive to do over PNA or 802.11 BlueTooth range too short need wireless SIP base station +

handsets PDAs with 802.11 and GSM? (Treo++)

Incentives SMS & IM services

11

SIP phonesSIP phones Hard to build really basic phones

need real multitasking OS need large set of protocols:

IP, DNS, DHCP, maybe IPsec, SNTP and SNMP UDP, TCP, maybe TLS HTTP (configuration), RTP, SIP

user-interface for entering URLs is a pain see “success” of Internet appliances “PCs with handset” cost $500 and still

have a Palm-size display

12

VoIP protocol componentsVoIP protocol components RTP for data transmission

ROHC, CRTP for header compression SIP or H.323 for call setup

(signaling) sometimes, H.248 (Megaco) for control

of gateways ENUM for mapping E.164 numbers

to (SIP) URIs TRIP for large gateway clouds

13

Challenges: QoSChallenges: QoS Bottlenecks: access and interchanges Backbones: e.g., Worldcom Jan. 2002

50 ms US, 79 ms transatlantic RTT 0.067% US, 0.042% transatlantic packet

loss Keynote 2/2002: “almost all had error

rates less then 0.25%” (but some up to 1%)

LANs: generally, less than 0.1% loss, but beware of hubs

14

15

Challenges: QoSChallenges: QoS Not lack of protocols – RSVP, diff-serv Lack of policy mechanisms and

complexity which traffic is more important? how to authenticate users? cross-domain authentication may need for access only – bidirectional traffic DiffServ: need agreed-upon code points

NSIS WG in IETF – currently, requirements only

16

Challenges: SecurityChallenges: Security Classical model of restricted access

systems -> cryptographic security Objectives:

identification for access control & billing phone/IM spam control (black/white

lists) call routing privacy

17

SIP securitySIP security

Bar is higher than for email – telephone expectations (albeit wrong)

SIP carries media encryption keys Potential for nuisance – phone

spam at 2 am Safety – prevent emergency calls

18

System modelSystem model

SIP trapezoid

outbound proxy

a@foo.com: 128.59.16.1

registrar

19

ThreatsThreats Bogus requests (e.g., fake From) Modification of content

REGISTER Contact SDP to redirect media

Insertion of requests into existing dialogs: BYE, re-INVITE

Denial of service (DoS) attacks Privacy: SDP may include media session

keys Inside vs. outside threats Trust domains – can proxies be trusted?

20

ThreatsThreats

third-party not on path can generate requests

passive man-in-middle (MIM) listen, but not modify

active man-in-middle replay cut-and-paste

21

L3/L4 security optionsL3/L4 security options IPsec

Provides keying mechanism but IKE is complex and has interop problems works for all transport protocol (TCP, SCTP,

UDP, …) no credential-fetching API

TLS provides keying mechanism good credential binding mechanism no support for UDP; SCTP in progress

22

Hop-by-hop security: TLSHop-by-hop security: TLS

Server certificates well-established for web servers

Per-user certificates less so email return-address (class 1)

certificate not difficult (Thawte, Verisign)

Server can challenge client for certificate last-hop challenge

23

HTTP Digest HTTP Digest authenticationauthentication

Allows user-to-user (registrar) authentication mostly client-to-server but also server-to-client

(Authentication-Info) Also, Proxy-Authenticate and

Proxy-Authorization May be stacked for multiple proxies

on path

24

HTTP Digest HTTP Digest authenticationauthentication

REGISTERTo: sip:alice@example.comAuthorization: Digest username="alice", nc=00000002, cnonce="abcd", response="6629"

REGISTERTo: sip:alice@example.comAuthorization: Digest username="alice", nc=00000001, cnonce="defg", response="9f01"

401 UnauthorizedWWW-Authenticate: Digest realm="alice@example.com", qop=auth, nonce="dcd9"

REGISTERTo: sip:alice@example.com

25

End-to-end authenticationEnd-to-end authentication

What do we need to prove? Person sending BYE is same as

sending INVITE Person calling today is same as

yesterday Person is indeed "Alice Wonder,

working for Deutsche Bank" Person is somebody with account at

MCI Worldcom

26

End-to-end authenticationEnd-to-end authentication Why end-to-end authentication?

prevent phone/IM spam nuisance callers trust: is this really somebody from my

company asking about the new widget? Problem: generic identities are cheap

filtering bozo@aol.com doesn't prevent calls from jerk@yahoo.com (new day, sam person)

27

End-to-end authentication End-to-end authentication and confidentialityand confidentiality

Shared secrets only scales (N2) to very small groups

OpenPGP chain of trust S/MIME-like encapsulation

CA-signed (Verisign, Thawte) every end point needs to have list of Cas need CRL checking

ssh-style

28

Ssh-style authenticationSsh-style authentication

Self-signed (or unsigned) certificate

Allows active man-in-middle to replace with own certificate always need secure (against

modification) way to convey public key

However, safe once established

29

DOS attacksDOS attacks

CPU complexity: get SIP entity to perform work

Memory exhaustion: SIP entity keeps state (TCP SYN flood)

Amplification: single message triggers group of message to target even easier in SIP, since Via not

subject to address filtering

30

DOS attacks: amplificationDOS attacks: amplification Normal SIP UDP operation:

one INVITE with fake Via retransmit 401/407 (to target) 8 times

Modified procedure: only send one 401/407 for each INVITE

Suggestion: have null authentication prevents amplification of other responses E.g., user "anonymous", password empty

31

DOS attacks: memoryDOS attacks: memory

SIP vulnerable if state kept after INVITE

Same solution: challenge with 401 Server does not need to keep

challenge nonce, but needs to check nonce freshness

32

Challenges: NATs and Challenges: NATs and firewallsfirewalls NATs and firewalls reduce Internet

to web and email service firewall, NAT: no inbound connections NAT: no externally usable address NAT: many different versions -> binding

duration lack of permanent address (e.g., DHCP)

not a problem -> SIP address binding misperception: NAT = security

33

Challenges: NAT and Challenges: NAT and firewallsfirewalls Solutions:

longer term: IPv6 longer term: MIDCOM for firewall

control? control by border proxy?

short term: NAT: STUN and SHIPWORM send packet to external server server returns external address, port use that address for inbound UDP packets

34

Challenges: service Challenges: service creationcreation

Can’t win by (just) recreating PSTN services

Programmable services: equipment vendors, operators: JAIN local sysadmin, vertical markets: sip-

cgi proxy-based call routing: CPL voice-based control: VoiceXML

35

Emergency callsEmergency calls Opportunity for enhanced services:

video, biometrics, IM Finding the right emergency call center

(PSAP) VoIP admin domain may span multiple 911

calling areas Common emergency address User location

GPS doesn’t work indoors phones can move easily – IP address does

not help

36

Emergency callsEmergency calls

EPAD

INVITE sip:sos@psap.leonia.nj.us

Location: 07605

REGISTER sip:sos

Location: 07605

302 MovedContact: sip:sos@psap.leonia.nj.usContact: tel:+1-201-911-1234

SIP proxyINVITE sip:sos

Location: 07605

common emergency identifier: sos@domain

37

Scaling and redundancyScaling and redundancy Single host can handle 10-100

calls + registrations/second 18,000-180,000 users 1 call, 1 registration/hour

Conference server: about 50 small conferences or large conference with 100 users

For larger system and redundancy, replicate proxy server

38

Scaling and redundancyScaling and redundancy DNS SRV records allow static load

balancing and fail-over but failed systems increase call setup

delay can also use IP address “stealing” to

mask failed systems, as long as load < 50%

Still need common database can separate REGISTER make rest read-only

39

Large systemLarge system

_sip._udp SRV 0 0 sip1.example.com

0 0 sip2.example.com

0 0 sip3.example.com

a2.example.comsip2.example.co

m

sip3.example.com

a1.example.com

sip1.example.com

b1.example.com

b2.example.com

sip:bob@example.com

sip:bob@b.example.com

_sip._udp SRV 0 0 b1.example.com

0 0 b2.example.com

stateless proxies

40

Enterprise VoIPEnterprise VoIP Allow migration of enterprises to IP

multimedia communication Add capacity to existing PBX,

without upgrade Allow both

IP centrex: hosted by carrier “PBX”-style: locally hosted Unlike classical centrex, transition can

be done transparently

41

MotivationMotivation Not cheaper phone calls Single number, follow-me – even for

analog phone users Integration of presence

person already busy – better than callback physical environment (IR sensors)

Integration of IM no need to look up IM address missed calls become IMs move immediately to voice if IM too tedious

42

Migration strategyMigration strategy

1. Add IP phones to existing PBX or Centrex system – PBX as gateway

Initial investment: $2k for gateway

2. Add multimedia capabilities: PCs, dedicated video servers

3. “Reverse” PBX: replace PSTN connection with SIP/IP connection to carrier

4. Retire PSTN phones

43

Example: Columbia Dept. Example: Columbia Dept. of CSof CS About 100 analog phones on small PBX

DID no voicemail

T1 to local carrier Added small gateway and T1 trunk Call to 7134 becomes sip:7134@cs Ethernet phones, soft phones and

conference room CINEMA set of servers, running on 1U

rackmount server

44

CINEMA componentsCINEMA components

RTSP

sipum

Cisco 7960

sipvxmlSIP

rtspdsipconfLDAP server

MySQL

PhoneJack interface

sipc

T1T1

sipd

mediaserver

RTSP

SIP-H.323converter

messagingserver

unified

server(MCU)

user database

conferencing

sip-h323

VoiceXMLserver

proxy/redirect server

Cisco2600

Pingtel

wireless802.11b

PBX

MeridianNortel

plug'n'sip

45

ExperiencesExperiences Need flexible name mapping

Alice.Cueba@cs alice@cs sources: database, LDAP, sendmail aliases, …

Automatic import of user accounts: In university, thousands each September

/etc/passwd LDAP, ActiveDirectory, …

much easier than most closed PBXs Integrate with Ethernet phone

configuration often, bunch of tftp files

Integrate with RADIUS accounting

46

ExperiencesExperiences

Password integration difficult Digest needs plain-text, not hashed

Different user classes: students, faculty, admin, guests, …

Who pays if call is forwarded/proxied? authentication and billing behavior of

PBX and SIP system may differ but much better real-time rating

47

SIP doesn’t have to be in a SIP doesn’t have to be in a phonephone

48

Event notificationEvent notification

Missing new service in the Internet Existing services:

get & put data, remote procedure call: HTTP/SOAP (ftp)

asynchronous delivery with delayed pick-up: SMTP (+ POP, IMAP)

Do not address asynchronous (triggered) + immediate

49

Event notificationEvent notification

Very common: operating systems (interrupts,

signals, event loop) SNMP trap some research prototypes (e.g.,

Siena) attempted, but ugly:

periodic web-page reload reverse HTTP

50

SIP event notificationSIP event notification

Uses beyond SIP and IM/presence: Alarms (“fire on Elm Street”) Web page has changed

cooperative web browsing state update without Java applets

Network management Distributed games

51

ConclusionConclusion Transition to VoIP will take much longer

than anticipated replacement service digital telephone took 20 years... 3G (UMTS R5) as driver?

combination with IM, presence, event notification

Emphasis protocols operational infrastructure security service creation PSTN interworking