Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Video on demand wikipedia , lookup
Wireless security wikipedia , lookup
Remote Desktop Services wikipedia , lookup
Recursive InterNetwork Architecture (RINA) wikipedia , lookup
Net neutrality law wikipedia , lookup
Cracking of wireless networks wikipedia , lookup
Deep packet inspection wikipedia , lookup
Zero-configuration networking wikipedia , lookup
TV Everywhere wikipedia , lookup
Piggybacking (Internet access) wikipedia , lookup
SIP extensions for the IP Multimedia Subsystem wikipedia , lookup
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