2. March 5, 2004 Henning Schulzrinne Columbia University (KAIST KNSS) Global Ubiquitous Computing

3. 2 March 5, 2004 Agenda SIP overview SIP for ubiquitous computing Location-based services Emergency calling Services, carriers and service creation Security issues

4. 3 March 5, 2004 SIP Overview

5. 4 March 5, 2004 Internet services – the missing entry Service/deliverysynchronousasynchronous pushinstant messaging presence event notification session setup media-on-demand messaging pulldata retrieval file download remote procedure call peer-to-peer file sharing

6. 5 March 5, 2004 Filling in the protocol gap Service/deliverysynchronousasynchronous pushSIP RTSP, RTP SMTP pullHTTP ftp SunRPC, Corba, SOAP (not yet standardized)

7. 6 March 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

8. 7 March 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

9. 8 March 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

10. 9 March 5, 2004 Basic SIP message flow

11. 10 March 5, 2004 SIP trapezoid outbound proxy a@foo.com: 128.59.16.1 registrar 1 st request 2 nd, 3 rd, … request voice traffic RTP destination proxy (identified by SIP URI domain)

12. 11 March 5, 2004 SIP message format SDP INVITE sip:bob@there.com SIP/2.0 Via: SIP/2.0/UDP here.com:5060 From: Alice To: Bob Call-ID: 1234@here.com CSeq: 1 INVITE Subject: just testing Contact: sip:alice@pc.here.com Content-Type: application/sdp Content-Length: 147 v=0 o=alice 2890844526 2890844526 IN IP4 here.com s=Session SDP c=IN IP4 100.101.102.103 t=0 0 m=audio 49172 RTP/AVP 0 a=rtpmap:0 PCMU/8000 SIP/2.0 200 OK Via: SIP/2.0/UDP here.com:5060 From: Alice To: Bob Call-ID: 1234@here.com CSeq: 1 INVITE Subject: just testing Contact: sip:alice@pc.here.com Content-Type: application/sdp Content-Length: 134 v=0 o=bob 2890844527 2890844527 IN IP4 there.com s=Session SDP c=IN IP4 110.111.112.113 t=0 0 m=audio 3456 RTP/AVP 0 a=rtpmap:0 PCMU/8000 message body header fields request line request response

13. 12 March 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

14. 13 March 5, 2004 PSTN vs. Internet Telephony Signaling & Media Signaling Media PSTN: Internet telephony: China Belgian customer, currently visiting US Australia

15. 14 March 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.17 via NAPTR + SRV

16. 15 March 5, 2004 3G Architecture (Registration) visited IM domain home IM domain serving CSCF interrogating proxy interrogating mobility management signaling registration signaling (SIP)_

17. 16 March 5, 2004 SIP is PBX/Centrex ready call waiting/multiple calls RFC 3261 holdRFC 3264 transferRFC 3515/Replaces conferenceRFC 3261/callee caps message waitingmessage summary package call forwardRFC 3261 call parkRFC 3515/Replaces call pickupReplaces do not disturbRFC 3261 call coverageRFC 3261 from Rohan Mahy’s VON Fall 2003 talk simultaneous ringingRFC 3261 basic shared linesdialog/reg. package barge-inJoin “Take”Replaces Shared-line “privacy”dialog package divert to adminRFC 3261 intercomURI convention auto attendantRFC 3261/2833 attendant consoledialog package night serviceRFC 3261 centrex-style features boss/admin features attendant features

18. 17 March 5, 2004 Example SIP phones about $85

19. 18 March 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

20. 19 March 5, 2004 SIP, SIPPING & SIMPLE –00 drafts includes draft-ietf-*-00 and draft-personal-*-00

21. 20 March 5, 2004 Ubiquitous computing  Location-based services  Emergency calling

22. 21 March 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)

23. 22 March 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

24. 23 March 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

25. 24 March 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 timeCPL capabilitiescaller preferences locationlocation-based call routing location events activity/availabilitypresence sensor data (mood, bio)not yet, but similar in many aspects to location data

26. 25 March 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

27. 26 March 5, 2004 GEOPRIV and SIMPLE architectures target location server location recipient rule maker presentity caller presence agent watcher callee GEOPRIV SIP presence SIP call PUBLISH NOTIFY SUBSCRIBE INVITE publication interface notification interface rule interface INVITE

28. 27 March 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

29. 28 March 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 branchdelivery@pizza.com 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

30. 29 March 5, 2004 Presence policy subscription policy event generator policy subscriber filter rate limiter change to previous notification? for each watcher subscriber (watcher) SUBSCRIBE NOTIFY

31. 30 March 5, 2004 Example: user-adaptive device configuration “all devices that are in the building” RFC 3082? PA device controller SUBSCRIBE to each room SUBSCRIBE to configuration for users currently in rooms 1.discover room URI 2.REGISTER as contact for room URI tftp HTTP SLP 802.11 signal strength  location REGISTER To: 815cepsr Contact: alice@cs SIP room 815

32. 31 March 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)

33. 32 March 5, 2004 Location-based IM & presence

34. 33 March 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

35. 34 March 5, 2004 Location-based call routing – UA knows its location GPS 40.86 N 73.98E CN=us A1=NJ A2=Bergen INVITE sips:sos@ DHCP outbound proxy server provided by local ISP? 40.86N 73.98E: Leonia, NJ fire dept. leonia.nj.us.sos.arpa POLY 40.85 73.97 40.86 73.99 NAPTR … firedept@leoniaboro.org

36. 35 March 5, 2004 DHCP for locations modified dhcpd (ISC) to generate location information use MAC address backtracing to get location information DHCP server 458/17  Rm. 815 458/18  Rm. 816 DHCP answer: sta=DC loc=Rm815 lat=38.89868 long=77.03723 8:0:20:ab:d5:d CDP + SNMP 8:0:20:ab:d5:d  458/17

37. 36 March 5, 2004 Location-based call routing – network knows location IP 48° 49' N 2° 29' E TOA include location info in 302 INVITE sips:sos@ INVITE sips:sos@paris.gendarme.fr map location to (SIP) domain outbound proxy

38. 37 March 5, 2004 Service creation

39. 38 March 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’…

40. 39 March 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

41. 40 March 5, 2004 Call routing services Outsourcing allows temporarily disconnected end users Staged service: carrier proxyuser proxy basic call routing personal preferences

42. 41 March 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

43. 42 March 5, 2004 Service creation programmer, carrier end user network serversSIP servlets, sip-cgi CPL end systemVoiceXMLVoiceXML (voice), LESS Tailor a shared infrastructure to individual users traditionally, only vendors (and sometimes carriers) learn from web models

44. 43 March 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

45. 44 March 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

46. 45 March 5, 2004 CPL example

47. 46 March 5, 2004 CPL example <lookup source="http://www.example.com/cgi-bin/locate.cgi?user=jones" timeout="8">

48. 47 March 5, 2004 Service creation environment for CPL and LESS

49. 48 March 5, 2004 Security issues

50. 49 March 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

51. 50 March 5, 2004 DOS attack prevention authentication return routability port filtering (SIP only) address-based rate limiting UDP: SIP TCP: SYN attack precautions needed SCTP: built-in

52. 51 March 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)

53. 52 March 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.com Digest

54. 53 March 5, 2004 TLS performance

55. 54 March 5, 2004 TLS performance

56. 55 March 5, 2004 TLS performance

57. 56 March 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