Enterprise SIP - PowerPoint PPT Presentation

About This Presentation
Title:

Enterprise SIP

Description:

bandwidth is (mostly) not the problem ' ... IM: AOL interworking, Windows Messenger ... Problem: generic identities are cheap ... – PowerPoint PPT presentation

Number of Views:311
Avg rating:3.0/5.0
Slides: 61
Provided by: henningsc
Category:
Tags: sip | aol | enterprise | problem

less

Transcript and Presenter's Notes

Title: Enterprise SIP


1
Enterprise SIP
  • Henning Schulzrinne
  • Avaya, LTS
  • March/April 2002

2
Overview
  • SIP status and outlook
  • SIP in the enterprise
  • architectures
  • CINEMA
  • SIP security issues
  • SIP standardization status
  • Commercial status

3
Where are we?
  • Not quite what we had in mind
  • initially, 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
  • cant get new services if other end is POTS ??
    why use VoIP if I cant get new services

4
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

5
Where are we?
  • SIP as the signaling protocol for future
    applications
  • 3GPP
  • Cable modems (DOCSIS DCS)
  • IM AOL interworking, Windows Messenger
  • but H.323 dominates videoconferencing, trunk
    replacement
  • Proprietary protocols dominate for Ethernet
    phones
  • Slow uptake of VoIP

6
SIP mid-term outlook
  • Initially, underestimated need for SIP eco
    system
  • SIP devices Cisco, Pingtel, Snom, Avaya, ...
  • but not yet orderable from CDW
  • insufficient number of low-end devices
  • Ethernet powering in infancy (and expensive, at
    1k/12 ports)
  • widely available SIP software Windows XP
    Messenger

7
SIP mid-term outlook
  • Emphasis initially on carriers, not enterprise,
    now on 3G
  • Need host of software hardware
  • SIP PBX interfaces ?
  • PBX T1 T1 gateway
  • SIP gateways reasonable selection
  • SIP conferencing limited
  • SIP VoiceXML server ?
  • SIP enterprise user interface ?

8
SIP 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

9
SIP phones
  • For residential use, need DSL/cable modem with
    multi-line POTS interface for basement
  • or Gigaset-style multi-line cordless phone

802.11
DSL CATV
10
SIP longer-term issues
  • SDPng?
  • XML-based generalization
  • better negotiation and grouping
  • API standardization
  • JAIN servlets
  • APIs for IM and presence
  • Operational issues
  • How to configure 10,000 phones without editing
    configuration files or logging into each phone?

11
SIP in the enterprise
  • Greenfield
  • save on wiring and admin expenses
  • per-seat cost similar (500)
  • Existing installations
  • small PBX (lt 8 lines) cheap
  • cant beat 80 phones
  • move towards multi-cordless (Gigaset, etc.)

12
Enterprise 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

13
Motivation
  • 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

14
Migration strategy
  • Add IP phones to existing PBX or Centrex system
    PBX as gateway
  • Initial investment ?2k for gateway
  • Add multimedia capabilities PCs, dedicated video
    servers
  • Reverse PBX replace PSTN connection with
    SIP/IP connection to carrier
  • Retire PSTN phones

15
IP PBX
16
IP Centrex
17
Example Columbia Dept. of 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 sip7134_at_cs
  • Ethernet phones, soft phones and conference room
  • CINEMA set of servers, running on 1U rackmount
    server

18
CINEMA components
Cisco 7960
MySQL
rtspd
sipconf
user database
LDAP server
plug'n'sip
RTSP
conferencing
media
server
server
(MCU)
wireless
sipd
802.11b
RTSP
proxy/redirect server
unified
messaging
server
Pingtel
sipum
Cisco
Nortel
2600
Meridian
VoiceXML
PBX
server
T1
T1
SIP
sipvxml
PhoneJack interface
sipc
SIP-H.323
converter
sip-h323
19
Experiences
  • Need flexible name mapping
  • Alice.Cueba_at_cs ? alice_at_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

20
Experiences
  • 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

21
SIP doesnt have to be in a phone
22
SIP 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

23
SIP security
  • Exposes weak state of general Internet security
    tools
  • Attempt to re-use existing mechanisms
  • HTTP digest authentication, with additions to
    protect crucial headers (e.g., Contact in
    REGISTER) for e2e and proxy authentication
  • TLS and IPsec for hop-by-hop authentication and
    confidentiality
  • S/MIME for end-to-end

24
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

25
System model
outbound proxy
SIP trapezoid
a_at_foo.com 128.59.16.1
registrar
26
Threats for SIP-based systems
  • Bogus requests (e.g., fake From)
  • Modification of content
  • REGISTER Contact
  • SDP to redirect media
  • Insertion of requests into existing dialogs BYE,
    re-INVITE
  • Bid-down attacks attacker gets to pick algorithm
  • Denial of service (DoS) attacks
  • Privacy SDP may include media session keys
  • Inside vs. outside threats
  • Trust domains can proxies be trusted?

27
Threats attack modes
  • 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

28
L3/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

29
Hop-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

30
HTTP Digest authentication
  • 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

31
HTTP Digest authentication
REGISTER To sipalice_at_example.com
401 Unauthorized WWW-Authenticate Digest
realm"alice_at_example.com", qopauth,
nonce"dcd9"
REGISTER To sipalice_at_example.com Authorization
Digest username"alice", nc00000001,
cnonce"defg", response"9f01"
REGISTER To sipalice_at_example.com Authorization
Digest username"alice", nc00000002,
cnonce"abcd", response"6629"
32
End-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

33
End-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_at_aol.com doesn't prevent calls from
    jerk_at_yahoo.com (new day, sam person)

34
End-to-end authentication and 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

35
Ssh-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

36
DOS 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

37
DOS 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

38
DOS 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

39
Challenges NATs and firewalls
  • NATs and firewalls reduce Internet to web and
    email service
  • firewall, NAT no inbound connections
  • NAT no externally usable address
  • NAT many different versions -gt binding duration
  • lack of permanent address (e.g., DHCP) not a
    problem -gt SIP address binding
  • misperception NAT security

40
Challenges NAT and firewalls
  • 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

41
SIP security
  • Security with random strangers is hard!
  • Identities are cheap cant use for filtering
    bozos
  • often only need to verify that same good person
    as before see ssh
  • Symmetric (secret) key doesnt scale
  • Public key cryptography only modest help
  • need certification authorities
  • what is being certified?
  • CRLs
  • hard to move keys to new devices smartcard?
  • Kerberos needs extensions for interdomain

42
SIP security longer term
  • EAP for authentication (used in 3GPP)
  • Third-party signatures
  • this caller is an employee of Visa
  • REFER authentication
  • Alice (verifiable) asked Bob to call Carol

43
Instant message presence
  • SIMPLE MESSAGE, SUBSCRIBE, NOTIFY
  • Also for various SIP-related events, e.g., in
    REFER and conferences
  • Just a special case of event notification tell
    me if something happened something happened!

44
Event 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

45
Event 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

46
SIP 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

47
Standardization
  • Organizations
  • IETF for core protocols
  • SIP for protocol extensions
  • SIPPING for BCPs, requirements
  • SIMPLE for IM presence
  • MMUSIC for SDP SDPng
  • 3GPP (3GGP2) for requirements
  • PacketCable for residential requirements

48
SIP standardization
  • RFC 2543 as core spec, being updated on fast
    track (at RFC editor)
  • "SIP Session Initiation Protocol"
  • "Reliability of Provisional Responses in SIP"
  • "SIP Locating SIP Servers"
  • "An Offer/Answer Model with SDP"
  • "SIP-Specific Event Notification"
  • "Support for IPv6 in SDP"

49
Recent SIP developments
  • SIP revision (RFC2534bis) done
  • semantically-oriented rewrite
  • layers message, transport, transaction,
    transaction user
  • SDP extracted into separate draft
  • UA and proxy have the same state machinery
  • better Route/Record-Route spec for loose routing
  • no more Basic authentication
  • few optional headers (In-Reply-To, Call-Info,
    Alert-Info, )
  • Integration of reliable provisional responses and
    server features
  • DNS SRV modifications

50
Other current SIP RFCs
  • RFC 3087 (I) Control of Service Context using
    SIP Request-URI
  • RFC 3050 (I)Common Gateway Interface for SIP
  • CPL A Language for User Control of Internet
    Telephony Services to Proposed Standard (PS) in
    RFC editor queue

51
In SIP working group last call
  • The SIP UPDATE Method
  • Integration of Resource Management and SIP
  • SIP Extensions for Network-Asserted Caller
    Identity and Privacy within Trusted Networks
  • SIP Extensions for Media Authorization

52
SIP drafts ready for WGLC
  • User Requirements for SIP in support of deaf,
    hard of hearing and speech-impaired individuals
  • ISUP to SIP Mapping
  • SIP Call Control - Transfer
  • DHCPv4 Option for SIP Servers
  • SIP Caller Preferences and Callee Capabilities
  • SIP Call Flow Examples
  • MIB for Session Initiation Protocol
  • The SIP Session Timer (done)

53
Work in progress
  • Total of unexpired 44 (24 draft-ietf) SIP, 60
    (10) SIPPING drafts
  • Examples
  • SIP Extension for Registering Non-Adjacent
    Contacts
  • Universal Emergency Address for SIP-based
    Internet Telephony
  • SIP Communications Resource Priority Header
  • Mapping of ISUP Overlap Signalling to SIP

54
SIP standardization pending
  • May (or not) become WG work item
  • conference control requirements phase
  • call history, call reason
  • group communications for messaging
  • emergency communications (911)
  • device configuration
  • AAA for SIP
  • ...

55
Summary of standardization
  • Core documents RFCs shortly
  • some long-term stable I-Ds need final push out
    the door
  • call transfer biggest open issue of wide interest
  • infrastructure issues (AAA, 911)
  • conferencing services

56
Commercial SIP efforts
  • Number of robust SIP phones
  • not yet in Wal-Mart
  • SIP carriers terminate LAN VoIP
  • China Telecom, DeltaThree, Denwa, eStara,
    TalkingNets, Vonage, Webley, Worldcom, ...
  • number portability?
  • 911
  • 50 vendors at SIPit (10th)
  • Building blocks media servers, unified
    messaging, conferencing, VoiceXML,

57
Implementations (selection)
  • Test tools Catapult, Radcom, SIPcomm/Columbia
  • Libraries (C or Java) Altium, SIPcomm/Columbia,
    RADvision, dynamicsoft, Trillium, Ubiquity,
    Vovida, ...
  • User agents Indigo, Microsoft, SIPcomm/Columbia,
    Ubiquity
  • Phones Cisco, Pingtel, Siemens, Snom
  • Gateways Cisco, Mediatrix, Nuera, Sonus,
    Vegastream

58
Implementations (selection)
  • Proxy servers Cisco, CommWorks, dynamicsoft,
    Columbia/SIPcomm, Hotsip, Hughes, Indigo,
    Ubiquity, Vovida
  • Unified messaging Columbia/SIPcomm
  • Conferencing Voyant, Columbia/SIPcomm

59
Conclusion
  • Infrastructure takes time even early adopters
    compare to PBX
  • Standardization slower than it should be ("day
    job problem"), but critical things done (thanks,
    3GGP!)
  • Security not yet perfect, but deployable
  • Shifting vendor stances, but continues to be very
    diverse

60
For more information...
  • SIP http//www.cs.columbia.edu/sip
  • CINEMA http//www.cs.columbia.edu/IRT/cinema
Write a Comment
User Comments (0)
About PowerShow.com