1 / 60

Enterprise SIP

Enterprise SIP. Henning Schulzrinne Avaya March 29, 2001. Overview. SIP status and outlook SIP in the enterprise architectures CINEMA SIP security issues SIP standardization status Commercial status. Where are we?. Not quite what we had in mind

Ava
Download Presentation

Enterprise SIP

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Enterprise SIP Henning Schulzrinne Avaya March 29, 2001

  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 • “can’t get new services if other end is POTS’’  “why use VoIP if I can’t 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 (< 8 lines) cheap • can’t 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 sip:7134@cs • Ethernet phones, soft phones and conference room • CINEMA set of servers, running on 1U rackmount server

  18. CINEMA components Cisco 7960 MySQL sipconf rtspd 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 Nortel Cisco Meridian 2600 VoiceXML PBX server T1 T1 SIP sipvxml PhoneJack interface sipc SIP-H.323 converter sip-h323

  19. Experiences • 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

  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 doesn’t 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@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: sip:alice@example.com 401 Unauthorized WWW-Authenticate: Digest realm="alice@example.com", qop=auth, nonce="dcd9" REGISTER To: sip:alice@example.com Authorization: Digest username="alice", nc=00000001, cnonce="defg", response="9f01" REGISTER To: sip:alice@example.com Authorization: Digest username="alice", nc=00000002, 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@aol.com doesn't prevent calls from jerk@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 -> binding duration • lack of permanent address (e.g., DHCP) not a problem -> 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 – can’t use for filtering bozos • often only need to verify that same “good” person as before – see ssh • Symmetric (secret) key doesn’t 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

More Related