VoCCN: Voice Over Content-Centric Networks
Van Jacobson D. K. Smetters Nick Briggs Michael Plass Paul Stewart James D. Thornton and Rebecca Braynard PARC 3333 Coyote Hill Road Palo Alto, CA, USA, 94304 {van,smetters,briggs,plass,stewart,jthornton,rbraynar}@parc.com
ABSTRACT Alice's VoIP Provider Bob's VoIP Provider
A variety of proposals call for a new Internet architecture fo- 1 cused on retrieving content by name, but it has not been clear Signaling Path that any of these approaches can offer the generality to sup- port Internet applications like real-time streaming or email. Internet We present a detailed description of a prototype implemen- tation of one such application – Voice over IP (VoIP) – in Router A Router B a content-based paradigm. This serves as a good example to show how content-based networking can offer advantages 2 for the full range of Internet applications, if the architecture Media Path has certain key properties. IP IP Alice Bob 1. INTRODUCTION Figure 1: Voice-over-IP data flows There is widespread agreement that content – what a user wants – should have a more central role in fu- ture network architectures than it does in the Internet’s This paper describes how to map the existing VoIP current host-to-host conversation model [8, 4, 22, 3, 1, architecture into CCN in a way which preserves security, 13, 5, 17, 18, 21, 6, 2, 7, 14, 15, 16]. But while it interoperability, and performance. The mapping tech- is clear that architectures based on Pub-Sub and simi- niques are not unique to VoIP, but are examples of gen- lar data-oriented abstractions provide a good fit to the eral transformations that we believe can be applied to massive amounts of static content exchanged via the almost any conversational Internet protocol. Through World Wide Web and various P2P overlay networks, it the example of VoCCN, therefore, we explore the prop- is less clear how well they fit more conversational traffic erties that can enable networking models focused on such as email, e-commerce transactions or VoIP. content to be more general than traditional conversa- To investigate this question we have implemented tional models. These new architectures can therefore VoCCN — a real-time, conversational, telephony ap- deliver benefits for both static content and the full range plication over Content-Centric Networking (CCN) [14, of conversational communication applications that are 15, 16] and found it to be simpler, more secure and more important in the Internet today. scalable than its VoIP (Voice-over-IP) equivalent. Our implementation uses standard SIP [10] and RTP [20] 2. VOIP BACKGROUND payloads which gives it complete and secure interop- Voice over Internet Protocol (VoIP) is the dominant erability with standard-conforming VoIP implementa- open protocol for Internet telephony. Figure 1 depicts tions via a simple, stateless, IP-to-CCN gateway. the components of a standard VoIP exchange. When Alice and Bob wish to make a phone call, their VoIP Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are phones set up an audio link using the Session Initiation not made or distributed for profit or commercial advantage and that copies Protocol (SIP) [10] via what is termed the signaling bear this notice and the full citation on the first page. To copy otherwise, to path. As VoIP endpoints are often mobile or located republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. on dynamic IP addresses, signaling path exchanges are A version of this paper to appear in ACM ReArch’09, December 1, 2009, mediated by proxies – service providers or corporate Rome, ITALY. VoIP signaling gateways that receive and forward mes- Copyright c 2009 Palo Alto Research Center, Incorporated. All rights reserved. sages on behalf of their client endpoints. To place a call to Bob, Alice’s endpoint will first contact her SIP proxy who will forward the call invitation to Bob’s SIP proxy, as only Bob’s proxy knows the current IP ad- dress of Bob’s endpoint. The body of the invitation contains both information about Alice and the RTP [20] address where she expects to receive audio (or other me- Internet dia streams) from Bob, should he accept the call. Bob’s CCN accept of the invite contains the RTP address of where Router A Router B he expects to receive audio from Alice which allows a di- Signaling & Media Path rect, bi-directional media path between their endpoints. VoIP media (voice, video, etc.) are typically secured and authenticated using either an encrypted form of CCN CCN RTP (SRTP [11]) or by tunneling RTP inside another Alice Bob secure network protocol (e.g., DTLS [9]). The encryp- tion keys are either set up via the signaling path, which Figure 2: Voice-over-CCN data flows must then itself be encrypted, or in-band in the media path (ZRTP [23]). Signaling path authentication and lishers, and have them create, and then publish, the encryption is typically done via wrapping the signaling desired content in response. exchange in DTLS and relying on a Public Key Infras- Second, we must have a way to transition from this tructure (PKI) to authenticate the exchange or using initial rendezvous to a bi-directional flow of conversa- a key agreement protocol such as Multimedia Internet tional data. In standard IP, there are packets (either Keying (MIKEY [12]) embedded in the signaling mes- designated packets in the rendezvous sequence, or all sages. MIKEY has the advantage of providing end-to- TCP or UDP packets) that contain the information end security and authenticating its own messages while needed to name the destination to which replies should minimizing signaling path roundtrips, but does not pro- be sent. For example, a TCP packet header contains vide confidentiality of the signaling pathway. a source IP address and port plus a protocol identifier. In a SIP exchange, the SDP content of the SIP message 3. ARCHITECTURE (shown in Figure 3) identifies the address to use for the media conversation. To translate this into a content- The complex data paths of Figure 1 result from a mis- oriented model, we need constructable names: it must match between the user’s goal and the network’s means be possible to construct the name of a desired piece of of achieving it: Alice simply wants to talk to Bob but content a priori, without having been given the name the network requires that the communication be ad- up front or having previously seen the content – the dressed to the IP address of Bob’s phone. All the in- service consumer must be able to figure out how to a frastructure in the Figure, together with the several ser- request that will reach the service provider. This can vices, devices and DNS name registrations that are not be done if: shown, exist solely to map from the user/application’s world view into the network’s world view. One strong • There is a deterministic algorithm by which both driver for content-oriented networking is that this trans- the data provider and data consumer arrive at the lation (typically referred to as middleware) is not needed. same (routable) name based on data available to Ideally data should flow directly from producer to in- both. terested consumer, as shown in Figure 2. Our VoCCN • Consumers can retrieve content based on partially- prototype achieves this. specified names. There are a couple of problems that must be solved in order to map conversational protocols like SIP and The former requirement guarantees that consumer RTP into a content-oriented model. First, we must sup- and producer will arrive at the same name, and that port service rendezvous. To initiate a call, the caller’s names will not depend on data neither has (such as phone must be able to request a connection with the naming content by its cryptographic digest, impossible callee, and get a confirmation response. This requires for data the consumer has not seen, or that does not yet the callee’s phone to offer a service contact point. In exist). The latter deals with the fact that without sig- standard IP, a port number serves as such a service nificant prearrangement to allow for a source of shared contact point at which a process can receive requests, to randomness, such constructed names will not be unique. which it dynamically generates responses. To translate By allowing flexibility in the query mechanism, we can this into a content-oriented model, we need on-demand allow for uniquely named content, while matching it to publishing: the ability to request content that has not deterministically generated queries. For example, gen- yet been published, route that request to potential pub- erating a query for a structured name that matches only tent from anything existing. Note that the entire SIP INVITE sip:[email protected] SIP/2.0 INVITE message is included in the requested content Via: SIP/2.0/CCN bigco.com:5060 name. The callee receiving the interest can unpack the From: Alice Briggs
/domain/sip/bob/invite/EpkB(sk)/Esk(SIP INVITE message)
Data: Name: /domain/sip/bob/invite/EpkB(sk)/Esk(SIP INVITE message) Signaling Path Signature Info:
Content: Esk(SIP response message)
Interest: /domain/bob/call-id/rtp/seq-no
Data: Name: /domain/bob/call-id/rtp/seq-no Signature Info:
Figure 4: Protocol exchange.
3.2 VoCCN/VoIP Interoperability gateway/SIP proxy, and all messages translated by the In order to achieve interoperability between VoIP and proxy are digitally signed (by the proxy) before sending VoCCN, we have designed (but not yet implemented) them into the CCN infrastructure. The proxy can also a stateless VoCCN-VoIP gateway. This gateway, which encrypt the SIP messages between itself and the CCN also serves as the SIP proxy for VoIP calls, translates endpoint. from VoIP packets (SIP and SRTP) to VoCCN packets (which again merely encapsulate SIP and SRTP for this 4. IMPLEMENTATION application), and vice versa. We have implemented a proof-of-concept VoCCN client On recieving a SIP or SRTP packet, the proxy merely as an extension to an open source Linux VoIP phone, examines that packet, and generates a corresponding Linphone (version 3.0). We made Linphone exchange CCN data packet whose name is determined based on data over CCN by taking advantage of the ability to information in the original inbound packet header (see plug new transports into libeXoSIP and liboRTP, the below). It then forwards it into the CCN routing fab- libraries it uses for SIP and RTP. ric in response to an interest from the other endpoint To implement our content-based network substrate, involved in the call. The proxy then performs the CCN- we used the open source Content-Centric Networking specific parts of the call on behalf of the legacy VoIP (CCN) Toolkit, available from [19]. This toolkit pro- client – generating and sending an interest in the next vides both a content router, which runs on every CCN- packet of the exchange, where the name used in the in- aware node, and a set of interface libraries to simplify terest is also computed as a function of information in the process of writing content-based applications. We the inbound VoIP packet. ran content routers on endpoint nodes, which sent CCN The proxy retains no state about the call; respond- packets via an overlay consisting of UDP sent over pre- ing only to received (CCN or VoIP) packets – the call configured point-to-point or multicast links. “state” is contained at the endpoints and in the inter- ests noted in the forwarding tables along the path to 4.1 Security the content source. The proxy also has limited partic- All VoCCN packets in both the signaling and the me- ipation in call security. Key exchange and media path dia paths were digitally signed, using per-user key pairs. encryption (if supported by the VoIP client) is end-to- The corresponding public keys were also distributed via end. SIP signaling security is protected by legacy mech- CCN. A simple extension would have these keys further anisms between the VoIP client and the VoCCN-VoIP signed (again as CCN data) by an organizational root key, effectively building a corporate PKI. LinPhone Packet Interarrival Time To provide media path security, we ran all calls over 1 1 SRTP, using pre-existing hooks to integrate libsrtp, 0.9 an open SRTP implementation, with Linphone. We 0.8 implemented a MIKEY [12] library to perform key ex- change in the signaling path. We selected MIKEY over 0.7 DTLS for its ability to perform a complete SIP exchange 0.6 and key setup in a single round trip. 0.5 To provide signaling path security, we implemented 0.4 a simple inline message encryption and authentication 0.3
scheme (shown in Figure 4). The caller, after gener- CDF: Proportion of Packets 0.2 ating a SIP invite message, would encrypt and crypto- graphically authenticate (using a symmetric-key MAC, 0.1 Stock LinPhone CCN LinPhone - Encrypted HMAC) that message using a randomly-generated sym- 0 0 10 20 30 40 50 60 70 80 90 100 metric key, sk. The caller would then encrypt that key Packet Interarrival Time (ms) under the public key of the callee (pkB in Figure 4). When constructing a call-initiating interest message, Figure 5: Cumulative distribution of inter- the caller would include both the encrypted key block packet intervals, or jitter, for a 10-minute voice (EpkB(sk) in Figure 4) and the encrypted and authen- call. ticated SIP message (Esk(SIP INV IT E message) in Figure 4) as components of the name it was express- by either stock Linphone or our VoCCN client, however ing interest in. The callee, on receiving the interest, a small number of VoCCN packets (less than 0.1%) were could decrypt the key block with its private key, re- dropped by Linphone for having arrived too late. cover sk, and use it to verify and decrypt the SIP IN- VITE (which itself contained the first, separately au- 5. CONCLUSIONS thenticated, MIKEY key exchange message). The caller Content-oriented network architectures not only move would then use sk to encrypt its SIP response message. content scalably and efficiently, they can also implement The net result offers much better security than most IP-like conversational services like voice calls, email or common production VoIP deployments, which are of- transactions. To demonstrate this we have implemented ten unencrypted and unauthenticated; when they are and tested a Voice-over-CCN prototype. The result is protected it is usually only in a hop-by-hop fashion by functionally and performance equivalent to Voice-over- secure tunnels between proxies. Our VoCCN implemen- IP but substantially simpler in architecture, implemen- tation instead provides true end-to-end security. tation and configuration. Because it does not require 4.2 Performance VoIP’s inbound SIP proxy (with the associated signal- ing state concentration), it is intrinsically more scalable. Subjective voice call quality of our VoCCN imple- Because CCN secures content rather than the connec- mentation was quite good (as measured between two tions it travels over, VoCCN does not require delega- reasonably fast workstations, on either 100Mbs or 1Gbs tion of either trust or keys to proxies or other network switched networks). intermediaries and thus is far more secure than VoIP. To evaluate CCN’s ability to support timely delivery Finally, thanks to certain affordances offered by CCN’s of realtime data we looked at the arrival times of pack- structured naming, VoCCN is completely interoperable ets in our VoCCN implementation. Figure 5 shows the with VoIP via simple, stateless gateways. distribution of inter-packet intervals, effectively packet jitter, for a 10-minute voice call made using stock Lin- 6. REFERENCES phone (solid line) over UDP RTP, and our Linphone- [1] W. Adjie-Winoto, E. Schwartz, H. Balakrishnan, based VoCCN client (dashed line) (expected interval 20 and J. Lilley. The Design and Implementation of msec). Steplike appearance is due to the Linux ker- an Intentional Naming System. SIGOPS Oper. nel scheduling quantum (for a single process in the case Syst. Rev., 33(5):186–201, 1999. of stock Linphone, and 3 processes for VoCCN). The [2] B. Ahlgren, M. D’Ambrosio, M. Marchisio, VoCCN call has slightly fewer packets at or below the I. Marsh, C. Dannewitz, B. Ohlman, expected inter-packet interval, and a small number of K. Pentikousis, O. Strandberg, R. Rembarz, and long-interval packets at the tail. No packets were lost V. Vercellone. Design considerations for a network 1This provided both encryption and content authentication; of information. In CONEXT, 2008. though the latter was redundant given CCN’s digital signa- [3] H. Balakrishnan, K. Lakshminarayanan, ture on each packet. S. Ratnasamy, S. Shenker, I. Stoica, and M. Walfish. A Layered Naming Architecture for real-time applications. the Internet. In SIGCOMM, 2004. [21] D. Trossen. Conceptual architecture of PSIRP [4] H. Balakrishnan, S. Shenker, and M. Walfish. including subcomponent descriptions (D2.2), June Semantic-Free Referencing in Linked Distributed 2008. http://psirp.org/publications. Systems. In IPTPS, February 2003. [22] M. Walfish, H. Balakrishnan, and S. Shenker. [5] M. Caesar, T. Condie, J. Kannan, Untangling the Web from DNS. In NSDI, 2004. K. Lakshminarayanan, I. Stoica, and S. Shenker. [23] P. Zimmermann, A. Johnston, and J. Callas. ROFL: Routing on Flat Labels. In SIGCOMM, ZRTP: Media Path Key Agreement for Secure 2006. RTP. http://www.philzimmermann.com/zfone/ [6] C. Dannewitz, K. Pentikousis, R. Rembarz, draft-zimmermann-avt-zrtp-15.html. E. Renault, O. Strandberg, and J. Ubillos. Scenarios and research issues for a network of information. In Proc. 4th Int. Mobile Multimedia Communications Conf., July 2008. [7] C. Esteve, F. L. Verdi, and M. F. Magalh˜aes. Towards a new generation of information-oriented internetworking architectures. In CONEXT, 2008. [8] M. Gritter and D. R. Cheriton. An architecture for content routing support in the internet. In Usenix Symposium on Internet Technologies and Systems (USITS), 2001. [9] IETF. Datagram transport layer security. [10] IETF. RFC 3261 – SIP: Session initiation protocol. [11] IETF. RFC 3711 – The Secure Real-time Transport Protocol (SRTP). [12] IETF. RFC 3830 – MIKEY: Multimedia Internet KEYing. [13] V. Jacobson. A new way to look at networking, August 2006. http://video.google.com/ videoplay?docid=-6972678839686672840&ei= iUx3SajYAZPiqQLwjIS7BQ&q=tech+talks+van+ jacobson. [14] V. Jacobson. Making the case for content-centric networking: An interview with Van Jacobson. ACM Queue, January 2009. [15] V. Jacobson. Special plenary invited short course: (CCN) content-centric networking. In Future Internet Summer School, August 2009. [16] V. Jacobson, D. K. Smetters, J. D. Thornton, M. Plass, N. Briggs, and R. Braynard. Networking named content. In In submission to CoNext ’09, 2009. [17] T. Koponen, M. Chawla, B.-G. Chun, A. Ermolinskiy, K. H. Kim, S. Shenker, and I. Stoica. A Data-Oriented (and Beyond) Network Architecture. In SIGCOMM, 2007. [18] B. Ohlman et al. First NetInf architecture description, April 2009. http://www.4ward-project.eu/index.php?s= file download&id=39. [19] PARC. CCN toolkit. http://hTBDi, September 2009. URL will be available by final version of paper. [20] RTP. RFC 1889 – RTP: A transport protocol for