SIP Extensions QoS, Authentication, Privacy, Billing, ... Project Packetcable

1. SIP ExtensionsQoS, Authentication, Privacy, Billing, ...Project Packetcable John R. Pickens, PhD VP Technology and CTO jpickens@com21.com 408 953 9228

2. Acknowledgements Presentation based in part on July 1999 IETF contributions W. Marshall, K. K. Ramakrishnan, E. Miller, G. Russell, B. Beser, M. Mannette, K. Steinbrenner, D. Oran, J. Pickens, P. Lalwaney, J. Fellows, D. Evans, K. Kelly, F. Andreasen AT&T, CableLabs, 3Com, Cisco, Com21, General Instrument, Lucent Cable, NetSpeak, Telcordia

3. Problem Statement • Personal Policy ==Cool ApplicationsAdministrative Policy == Desirable Service Revenue • SIP enables “personal policy” • How can SIP enable “administrative policy”?

4. Project Packetcable Overview • IP based multimedia networking services project, emphasizing IP telephony in the initial phases • Protocols based upon standards, with extensions (submitted to standards organizations) where needed • North American cable industry market, managed by Cablelabs, strong vendor support. • Distributed signaling paradigm is SIP (Packetcable 1.1). • Protocols and architecture developed for DOCSIS-based cable, but applicable to other broadband access network technologies. Note: Other backoffice uses of SIP are envisioned, not in the current work.

5. Packetcable Components

6. SIP Interfaces (Packetcable 1.1)

7. Call Management Server Interfaces NCS/MGCP DCS/SIP Translation, Congestion Control, PSTN DB access, Event recording, Routing Call Signaling Call Agent DCS-Proxy QoS Gate Controller Signaling DQos Call Management Server (CMS) COPS

8. Requirements from a Service Provider’s Perspective • Need for differentiated quality-of-service is fundamental • must support resource reservation and admission control, where needed • hope SIP enables lots of new services; also desire to meet needs of current users • Allow for authentication and authorization on a call-by-call basis • Can’ttrust CPE to transmit accurate information or keep it private • Need to guarantee privacy and accuracy of feature information • e.g., Caller ID, Caller ID-block, Calling Name, Called Party • privacy may also imply keeping IP addresses private • Protect the network from fraud and theft of service • critical, given the incentive to bypass network controls • We must be able to operate in large scale, cost-effectively • don’t keep state for stable calls in proxies; end-points can keep state associated with their own calls

9. MTA M Access PSTN Distributed Call Signaling Framework • Designed as a complete end-to-end signaling architecture for PacketCable • Philosophy: encourage features and services in intelligent end-points, wherever technically and economically feasible • “DCS-Proxy” designed to be scalable transaction server • Resource management protocol provides necessary semantics for telephony • “Gates” (packet classifiers) at network edge allow us to avoid theft of service DCS- Proxy+GC DCS- Proxy+GC Announcement Server M MTA ER Signaling Transport (IP) ER Media transport (IP) MTA = Media Terminal Adapter PSTN G/W M = Access Modem ER = Edge Router Local LD

10. DCS Architecture • Enhances SIP With Carrier Class Features • Resource Management • Privacy • Authorization and Theft of Service issues • Tight Coupling Between Call Signaling And QoS Control • Prevent Call Defects: don’t ring the phone if resources are unavailable • Prevent Theft Of Service: associate usage recording and resource allocation, ensuring non-repudiation • provide the ability to bill for usage, without trusting end-points • ensure quality requirements for service are met (e.g., don’t clip “Hello”) • Care taken to ensure untrusted end-points behave as desired • Privacy mechanisms built into architecture

11. DCS Architecture • Makes use of end-point intelligence • useful from the point of view of new feature creation • Distribution of state • Clients keep Call State • Edge Routers keep Connection State • DCS-Proxy only keeps Transaction State • Failure model minimizes service impacts due to component outages

12. MTA M Access DCS- Proxy+GC DCS- Proxy+GC Announcement Server M MTA ER Signaling Transport (IP) ER Media transport (IP) PSTN MTA = Media Terminal Adapter PSTN G/W M = Modem ER = Edge Router Local LD Connection State Call State Transaction State DCS Architecture

13. INVITE (no ring) INVITE (no ring) MTA M Access INVITE (no ring) Example Call Flow • MTA issues an INVITE to destination E.164 (or other) address • don’t know yet “what” resources are needed to “where” • provider may choose to block a call if resources are unavailable • but P(blocking) may be  P(call defect) • call defect: when the call fails after the parties are notified • Originating DCS-proxy performs authentication and authorization • Terminating DCS-proxy translates dest. number to local IP address Number-to-Address Translation Authentication, Authorization, Admission control DCS- Proxy DCS- Proxy Announcement Server M MTA CMTSER ER ER

14. 200 OK 200 OK Setup Gate Setup Gate 200 OK Example Call Flow (contd…) • 200 OK communicates call parameters and gate identity to MTA • Gate controllers setup “gates” at edge routers as part of call setup • gate is described as an “envelope” of possible reservations issued by MTA • gate permits reservation for this call to be admitted • Policy may be exercised either at Gate controller or associated policy server DCS- Proxy DCS- Proxy Announcement Server M MTA ER MTA M ER Access

15. MTA M Access Backbone Reservation PATH / Reserve PATH / Reserve Resource Management: 1st Phase • MTA initiates resource reservation • access resources are “reserved” after an admission control check • this insures that resources are available when terminating MTA rings • backbone resources are “reserved” (e.g., explicit reservation or “packet marking”) • Originating MTA starts end-to-end handshake with terminating MTA • originating MTA sends INVITE(ring), terminating MTA sends 180 RINGING, 200 OK Gate- controller Gate- controller Announcement Server M MTA ER ER

16. INVITE(ring) MTA M Access 180 Ringing 200 OK Commit/Commit Ack Commit/Commit Ack Resource Management: 2nd Phase • MTA knows voice path is established when it receives a 200 OK • MTAs initiate resource “commitment” • resources “committed” over access channel • CMTS starts sending unsolicited grants; usage recording is started • commitment deferred until far end pick up, to prevent theft of service; allow efficient use of constrained resources in access network • Commit opens the “gate” for this flow Gate- controller Gate- controller Announcement Server M MTA ER ER

17. Critical Messages and their Relationships MTAO ERO GCO GCT ERT MTAT INVITE (AI, E.164T, CPO) INVITE ($, CPO, E.164T, CIO) INVITE (GIDT, E.164T, CPO, [CIO](GCT)) 200 OK (IPT, CIT) 200 OK (IPT) 200 OK (GIDO,IPT, [CIT](GCO)) Resource Reservation Starts ringback INVITE (RING) 180 RINGING 200 OK Call In Progress

18. “Gates” and Edge Router Functionality • “Gates” in edge routers opened for individual calls • call admission control and policing implemented in edge routers • gate utilizes packet filters that already exist in edge routers: “allow a call from this source to this destination” etc. • gate allows communication between a source and a destination, for a particular range of traffic parameters, and a particular duration • however, policy is controlled by the proxy • Proxy sets up gate in edge router after Call Setup authorized • permit access to managed network resources: users receive dependable QoS • MTA makes resource reservation request by signaling to edge router • edge router admits the reservation if consistent with gate parameters • edge router generates usage recording events based on reservation state

19. Signaling Performance Requirements • Short post-dial delay • no perceptible difference in post-dial delay compared to circuit-switched network • Short post-pickup delay • delay from when the user picks up a ringing phone and the voice path being cut-through should be small • called party’s “hello” must not be clipped • calling party’s response to hearing the “hello” must also not be clipped • Probability of Blocking: a metric to which provider may engineer net • Probability of Call Defect (i.e., call that has both parties invited to and then fails) due to lack of resources needs to be much smaller • target rates not necessarily under the control of the provider • Flexibility in deployment of DCS-Proxy: start small.

20. SIP Extensions • Two-phase invite • OSPS (Operator Services Positioning System) • Billing info • Gate info • Call State • Ring indicator • Privacy

21. SIP Support needed forResource Management • Additional header in initial INVITE message • No-Ring = “NoRing” “:”

22. State Header • Motivation: • Call state stored at endpoints by their SIP-Proxies during the initial INVITE exchange. This allows Proxies to be stateless during the call. • Endpoint passes state information to Proxies when call characteristics require change. • State information includes, but is not limited to: participating endpoint information, billing information. • State information cannot be altered undetectably by endpoints. • Syntax of the State Header State = "State" ":" private private = alpha *alphanum • Usage: • “State” header encrypted and signed by Proxy and sent to called endpoint in an INVITE message. • ‘State” header encrypted and signed by Proxy and sent to the calling endpoint in the response to the INVITE.

23. OSPS Header(Operator Services Positioning System) • Motivation: • PSTN based services like Busy Line Verify and Emergency Interrupt require special treatment. • PSTN operator is unaware that the call is to a destination on the IP network. • PSTN gateway initiates SIP INVITE to endpoint. This includes the OSPS header. • An active endpoint receiving an INVITE containing this header does not return “Busy”. • Header Format OSPS = “OSPS” “:” OSPS-Tag OSPS-Tag = “BLV” | “EI”

24. Call (QoS) Authorization • Client needs to know the location of GATE • Gate-ID = 1*alphanum • Header placed in messages from Proxy to Client

25. Proxy-Proxy: Billing header • Billing Information: • Billing-ID = “DCS-Billing-ID” ”:” 1*unreserved • Billing-Info= “DCS-Billing-Info” “:” hostport [“/”Key] “<“Acct-Data“>” • Gate-Location = “DCS-Gate-Location” “:” hostport “/” Gate-ID [ Gate-Key] • User-param: • telephone-subscriber = global-phone-number | local-phone-number | augmented-phone-number user-param = “user=” ( “ip” | “phone” | “lnp-phone”) • Notes:New headers should not be sent to User Agents. Only between Proxies. Also, sensitive information (billing info) should only be passed on secure links.

26. Privacy (Outline Issues/Approaches) • Calling Identity Delivery Blocking (CIDB) • Depends on trusted intermediary (DCS Proxy) • User agent control • Inference attacks • DNS name inference • IP address inference • Anonymizer proposals • Potential exposures: From header field, Contact header field, Via header fields, Call-ID, SDP parameters, RTCP

27. Summary • SIP is design basis of carrier class service in Packetcable • SIP extensions proposed (administrative policy, privacy, …) • RSVP Extensions also proposed (not covered in this presentation) • Dialogue underway between Packetcable members and IETF to refine extension proposals • Packetcable vendors in various stages of prototyping and implementation • Future work and open issues • IP Address privacy issues • Multiple administrative domain issues • Interoperability with other SIP client issues • LAESS Issues