OCP: A protocol for secure communication in federated content networks

ARTICLE IN PRESS

JID: COMCOM

[m5G;August 5, 2015;19:0]

Computer Communications xxx (2015) xxx–xxx

Contents lists available at ScienceDirect

Computer Communications journal homepage: www.elsevier.com/locate/comcom

OCP: A protocol for secure communication in federated content networks Hélcio M. Pimentel, Samuel Kopp, Marcos A. Simplicio Jr.∗, Regina M. Silveira, Graça Bressan

Q1

Escola Politécnica, Universidade de São Paulo, São Paulo, Brazil

a r t i c l e

i n f o

Article history: Available online xxx Keywords: Federated Content Delivery Networks Network security Overlay networks Interdomain

a b s t r a c t Content Distribution Networks (CDNs) are networks that make intense use of caching and multicast overlay techniques for transmitting video and other stream media, a type of traffic that has been growing tremendously in the last years. To cope with this increasing demand, several telecommunications companies have been associated to create federated CDNs (FCDNs), that involves many different providers and, hence, distinct domains. Although beneficial in terms of increased capillarity and scalability of service delivery, the interaction between FCDN elements from different providers brings many new challenges. Among them, one that has received little attention so far refers to security, an essential service for preventing the misuse of the FCDN resources. Aiming to tackle this issue, this paper presents the Overlay Communication Protocol (OCP), a security mechanism that allows the secure signaling communication in FCDNs. OCP takes into account all elements involved in the content delivery process, addressing Route Forgery attacks and concealing the network structure from potential attackers. Together with the protocol description and security analysis, we also present experimental results on its implementation, showing that it introduces little impact on the overall network performance. © 2015 Elsevier B.V. All rights reserved.

1

1. Introduction

2

In recent years, the distribution of multimedia content through the Internet has grown tremendously. According to Cisco [1], the global Internet traffic is expected to raise from 28 TBytes/s in 2013 to 50 TBytes/s in 2018, and the contribution of IP video to these numbers should increase from 66 to 79% in the same period (not including video exchanged through peer-to-peer file sharing). This trend also is likely to be intensified by the increasing popularization of applications that use digital video in areas such as entertainment, education, culture and so on. A Content Delivery Network (CDN) [2] is one of the main technologies enabling the consumption of multimedia content in different contexts (e.g., the Internet), making use of caching and multicast overlay techniques for transmitting video and other streaming media [3–6]. Given their success, CDNs are now evolving to consider the integration of different Content Networks to tackle scalability and cost issues, as well as to create new business opportunities [7]. These associations can be tailored for building a Licensed CDN, Meta-CDN or Federated CDN (FCDN) [7], but many Internet Service Providers (ISPs) indicate that the FCDN strategy is more

3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

∗

Corresponding author. Tel.: +55 11 30912968; fax: +55 11 30915280. E-mail addresses: [email protected] (H.M. Pimentel), [email protected] (S. Kopp), [email protected] (M.A. Simplicio Jr.), [email protected] (R.M. Silveira), [email protected] (G. Bressan).

advantageous due to the fact that it can make content delivery more profitable and highly cost-effective [8]. Albeit promising, FCDNs still face many and complex challenges, especially due to the need of interactions between elements managed by different providers. One example refers to the application of coordination mechanisms as a way to improve the content distribution, building optimized overlay routes [9,10], and delivering better Quality of Experience (QoE)[11]. Another aspect, which is of especial interest in this article, is that the large infrastructure of such networks also turn them into potential targets of malicious entities aiming to misuse their computational and communication power to promote attacks against the system itself or against other systems. For example, malicious users may try to take advantage of the lack of a central orchestration authority to forge routes to invalid contents, which enables attacks such as cache pollution or Distributed Denial of Service (DDoS) [12]. As another example, attackers can explore the information exchange between the CDNs to learn about their internal structure, as such information leakage can considerably facilitate subsequent attacks [13,14]. Countering such issues is an involved task, which becomes even more complex in interdomain scenarios due to the reduced coordination among nodes from the different content distribution domains. In this article, we tackle the above-mentioned issues by providing a solution that (1) allows the construction of authenticated interdomain paths for content delivery while (2) ensuring the confidentiality

http://dx.doi.org/10.1016/j.comcom.2015.07.026 0140-3664/© 2015 Elsevier B.V. All rights reserved.

Please cite this article as: H.M. Pimentel et al., OCP: A protocol for secure communication in federated content networks, Computer Communications (2015), http://dx.doi.org/10.1016/j.comcom.2015.07.026

20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44

ARTICLE IN PRESS

JID: COMCOM 2

[m5G;August 5, 2015;19:0]

H.M. Pimentel et al. / Computer Communications xxx (2015) xxx–xxx

Fig. 1. Example of Federated Content Distribution Network with content agents (CAs) responsible for multimedia distribution.

45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67

of the corresponding CDNs’ internal network information. To accomplish this goal, we propose the Overlay Communication Protocol (OCP), a lightweight security protocol especially tailored for interdomain networks’ signaling communication, as necessary for FCDNs operation. OCP is highly distributed, meaning that every control message contains all security information required by the hops involved in an interdomain route, avoiding the need for validation by a central authority and allowing fake requests (e.g., spoofed in a DoS attack) to be quickly discarded. In addition, the security information in every message is organized in a stackable manner so that it can be consumed throughout the network, enabling the interconnection of multiple independent networks in a lightweight fashion. We note that, although initially built as a proof-of-concept security solution, OCP is currently part of an FCDN being built by RNP (The Brazilian National Education and Research Network), which shows its practical interest in providing security in CDNs composed by multiple domains. The remainder of this paper is organized as follows. Section 2 described in more detail the concept of FCDNs, while Section 3 discusses the security issues that arise in these networks. The OCP solution is presented in Section 4. The security and performance analysis of the proposed solution are then analyzed in Sections 5 and 6, respectively. Section 7 outlines relevant related works. Finally, Section 8 presents our concluding remarks and considerations.

68

2. Federated content networks

69

Traditional CNDs are highly distributed infrastructures, potentially within third-party networks, able to deliver content from customers to end users worldwide. Nowadays, many ISPs use their own network infrastructure to build and operate their content distribution services, taking advantage of business opportunities brought by CDNs. However, due to constraints imposed by the coverage of their own networks, these CDNs are not implemented in a distributed manner across multiple networks and, therefore, are unable to operate globally. To solve this issue, CDNs can become interconnected, forming a Federated CDN (FCDN), thus increasing their combined coverage area in a more scalable manner [15]. This trust relationship also brings a considerable decrease in costs, which can reach 95% [8]. There are, however, technological challenges involved in the integration of different CDNs, which led to the creation of working groups focused on this issue, such as the IETF Content Distribution Network Interconnection (CDNI)[16]. Another emergent model of interconnected CDNs is the Meta-CDN [17], which is basically a broker in the selection of others CDNs, using several criteria to estimate which is the best CDN for each case. Despite the similarity between the Federated CDNs and the Meta-

70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88

CDN, one major difference is on how the CDNs are organized in each model: in a federation strategy, they cooperate for content distribution; in a Meta-CDN, there is a hierarchy, with the broker making delegations between the various CDNs but, at least in principle, not taking part in the content delivery itself. The infrastructure of a (F)CDN can be very complex, composed by many elements placed at strategic locations, each having a different function in the system [15]. In a nutshell, however, a (F)CDN interacts with the following entities: (1) Users, i.e., the content consumers; (2) Content Providers that supply multimedia content to the network, such as a web site in which videos are published; and (3) other CDNs. During the content delivery process, the path taken by the content is then (Content Provider → CDN → · · · → CDN → User), where the number of CDNs involved depends on the size of the federation and on the distance between the User and the Content Provider [18]. Internally, each CDN comprises: (1) Content Agents that handle the content adequately, such as edge/surrogate servers that provide data delivery and/or content adaptation services; (2) Managers that coordinate the content delivery by the Content Agents, such as a request router that redirects the Users to the appropriate Content Agent and also communicates with neighboring Managers for enabling interdomain delivery. Fig. 1 illustrates such FCDN scenario. This figure shows a User U requesting some content from a Content Provider Portal CP, whose media distribution is performed by CDN CNA . In this case, even though CNA has no Content Agents near U, CNA can still deliver that content with the expected QoS by leveraging on CDNs CNB and CNC . In order do so, the Managers from each CDN must collaborate, exchanging control messages for choosing the Content Agent that will be part of the “route” between the User and the media server inside CNA . The route contains all information required by the Content Agents from each CDN, allowing them to retrieve the content and deliver it to the User. In addition to interconnection, different CDNs also collaborate for ensuring that the required services are provided across their domains. To accomplish this task, Managers from neighboring CDNs must exchange information about the services provided by each of them. As a result, whenever a Manager receives a request, it can supply some service(s) locally and also ask their neighbors to act accordingly inside their own domains. In some cases, neighboring Managers may also instruct their own Content Agents to provide extra services in addition to those originally asked by the Manager from the network where the requested content is originally stored. Service-related data can be combined with the route information itself and become part of the access information delivered to users in the form of a URI (Uniform Resource Identifier).

Please cite this article as: H.M. Pimentel et al., OCP: A protocol for secure communication in federated content networks, Computer Communications (2015), http://dx.doi.org/10.1016/j.comcom.2015.07.026

89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134

ARTICLE IN PRESS

JID: COMCOM

[m5G;August 5, 2015;19:0]

H.M. Pimentel et al. / Computer Communications xxx (2015) xxx–xxx

Manager A

1

Manager B

Manager C

2

3

5

4

Manager A

1

6

2

3

Manager B

3

Manager C

5 4

6

(b)

(a) Client

Client

Fig. 2. Two approaches for route construction: (a) recursive and (b) iterative.

169

The process of directing the User to the appropriate Content Agent is commonly known as request-routing, and is composed of two subprocesses: request steering and route construction. Request steering corresponds to the mechanisms for efficiently directing client requests to a certain destination. Examples include Global Server-Load Balancing (GSLB), DNS-based, HTML rewriting, anycasting, and combinations of these approaches [15]. Depending on how the client interacts with the system for reaching the Content Agent, these mechanisms can be classified as direct or mediated solutions. Direct solutions are those in which the URI provided by a Content Provider’s portal already indicates the Content Agent that will deliver the content to the User, e.g., via DNS or IP anycast. Mediated solutions, on the other hand, comprise mechanisms in which the User interacts with another entity (e.g., a request router), which is then responsible for redirecting that User to the adequate Content Agent, e.g., via HTTP Redirect. Route construction, on its turn, consists in choosing the Content Agents that will be involved in the content delivery process and also selecting the corresponding services that must be enforced by each of these Content Agents. There are basically two strategies for achieving this goal: one iterative and another recursive [19]. Both are illustrated in Fig. 2. In the iterative approach, Managers repeatedly redirect the User (e.g., via HTTP redirect) until the Manager of the Content Network that is closest to that User is reached. In the example of Fig. 1, MA would redirect the User to MB , which in turn would redirect the User to MC ; the latter would then provide the User with the URI for some suitable Content Agent inside CNC , completing the process. In the recursive approach, Managers in the path between the Content Provider and the User interact directly, recursively building the route that will allow the content to be delivered to that User. In the example of Fig. 1, MA would contact MB , which in turn would contact MC ; after MC identifies a suitable Content Agent inside CNC , its response would be sent to MB , forwarded to MA and finally reach the User in the form of a URI that specifies the whole route for accessing the desired media.

170

3. Network security threats in FCDNs

171

As discussed in Section 2, using control messages for defining routes and interconnecting CDNs adds flexibility to the system. However, if not treated properly, the same messages can also be misused by malicious entities for crafting attacks against the network infrastructure or against third parties. In this section, we discuss possible threats considering a networkoriented threat model, i.e., a scenario where: (1) no legitimate entity composing the content delivery system (Managers, Content Agents, Content Repository and Content Provider Portal) is compromised, and thus, they can all be trusted; but (2) external entities (including users and any passive or active entity lurking in the network, potentially trying to pose as one of the system’s elements) are considered potential attackers. In addition, since the system is actually composed by different administrative domains, we consider that each CDN trusts each other for their assigned task of content delivery, but not neces-

135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168

172 173 174 175 176 177 178 179 180 181 182 183 184 185

sarily with information about its internal organization (e.g., which are the addresses of their content agents, the services provided by them, or how they interconnect). The different classes of threats appearing in this context, namely Steering Forgery (SF), Route Forgery (RF) and Network Information Leakage (IL), as well as the corresponding network communications targeted by them, are illustrated in Fig. 3 and detailed in the following sub-sections.

192

3.1. Steering Forgery (SF)

193

A first threat appears in a scenario in which attackers are able to provide clients with a fake URI, e.g., by using a bogus Content Provider Portal or by intercepting and modifying the original messages containing the URI information. If the Users have no means to verify whether such URI is valid or not, they can be easily diverted to an incorrect address, such as a non-existent server or a server containing invalid/malicious content. In fact, a similar strategy can also be used to mount Distributed Denial of Service (DDoS) attacks [20], in which lots of hosts are lured into sending requests to a single target chosen by the attackers, thus disrupting that target’s ability to use the network.

194

187 188 189 190 191

195 196 197 198 199 200 201 202 203 204

3.2. Route Forgery (RF)

205

A second issue appears if attackers pretending to be legitimate Users are able to provide fake route messages to a Content Agent when requesting a content. For example, suppose that the attacker forges a URI so that it contains a valid content identifier ID , but the address of the node (Content Agent) holding the content corresponds to a fake repository under the attacker’s control. If the legitimacy of the request is not verified, the Content Agents involved in this request will transmit the corresponding content and possibly also cache it locally without knowing that it was actually fabricated by the attacker. The attacker could even create the impression that the counterfeit content is very popular by sending many fake requests for that content from different Users, thus stimulating its caching throughout the network. This could be accomplished, for example, by means of a botnet or via IP spoofing. As a result of this cache pollution attack, when valid users try to access the real content associated with ID , they would receive the tainted cached data instead. URI-fabrication techniques can also be used to create DDoS attacks against a legitimate Content Provider. This can be accomplished with a URI that makes the Content Agents repeatedly contact a same Content Provider even when the requested content is locally cached [12].

206

3.3. Network Information Leakage (IL)

226

A third issue comes from the fact that control messages which are not properly protected become vulnerable to eavesdropping and, thus, may end up disclosing sensitive information about the system itself or about its users. For example, if the replies provided by the Manager disclose the addresses of internal nodes involved in some content

Please cite this article as: H.M. Pimentel et al., OCP: A protocol for secure communication in federated content networks, Computer Communications (2015), http://dx.doi.org/10.1016/j.comcom.2015.07.026

186

207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225

227 228 229 230 231 232

JID: COMCOM 4

ARTICLE IN PRESS

[m5G;August 5, 2015;19:0]

H.M. Pimentel et al. / Computer Communications xxx (2015) xxx–xxx

Fig. 3. Network threat model for FCDNs assumed in the discussion: system entities are trusted, while external agents (E) and users (U) are considered potential attackers exploiting Steering Forgery (SF), Route Forgery (RF) or Network Information Leakage (IL).

240

delivery, attackers can use information about the network topology for building more effective attacks (e.g., maximizing cache pollution by compromising strategically placed nodes) [13,14]. In addition, if the users’ content requests are left unprotected, any entity monitoring the network could link users to each content accessed and then build a profile based on their preferences [21]. Such privacy issues may discourage users to continue using the system’s services, negatively impacting its success.

241

4. The Overlay Communication Protocol (OCP)

242

266

In this section, we describe the Overlay Communication Protocol (OCP), which has been especially developed for providing secure and lightweight network signaling for interdomain communications. Whereas, among the threats discussed in Section 3, Steering Forgery can be effectively addressed by standard mechanisms for secure communications (e.g., HTTPS), the same does not apply to Route Forgery and Network Information Leakage, which are the focus of OCP’s design. To accomplish this task, OCP specifies: (1) a message structure capable of conveying all information required during content delivery in a secure manner; (2) a manner by which Managers from each CDN can interact for designating Content Agents that will take part in the content delivery process; (3) a manner by which Content Agents interact during content delivery itself; and (4) a key management model that meets the requirements of the security algorithms employed. As a result, the proposed protocol allows different overlay networks (e.g., CDNs) to build interdomain routes in a straightforward and scalable manner, enabling the construction of secure FCDNs. In what follows, we first present the design decisions that guided the protocol specification. After that, we describe the key management process used by OCP, as well as the layout of the OCP messages conveyed to users in the form of a URI, and how they are constructed and used by the network nodes. Finally, as the whole process is easier to understand through a step by step example, we illustrate this process in the example interdomain network depicted in Fig. 1.

267

4.1. Design decisions

233 234 235 236 237 238 239

243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265

•

•

•

•

•

268 269 270 271 272 273

The following design decisions are part of the protocol’s specification: •

The FCDN inter-domain security model reflects the model of Autonomous Systems. Thus, the establishment of trust relationships is maintained between adjacent CDNs, similarly to what happens in the Internet with the inter-domain Border Gateway Protocol

1

(BGP). This ensures that the CDNs keep their independence and can take their own internal management decisions, but still can interact with their neighbors in an agreed upon manner. Content request messages provided by users contain all the necessary information from retrieving the content, such as the route to be taken and the required security information. The goal of this strategy is to allow for distributed validation of those messages by the own Content Agents, so there is no need for them to contact a Manager before content transmission can start. As a result, the request message’s decoding is the only impact of the protocol on the media delivery process itself. The content request message is encapsulated in a URI format. This format is adopted because URIs are widely employed in a variety of scenarios, including not only web browsers but also several stream media players (e.g., VLC1 ). Therefore, by enclosing all required information for content delivery in URIs, the integration between potential players and the FCDN delivery mechanisms is straightforward, while standard alternatives might not be as general (e.g., using cookies would restrict the solution basically to web browsers, while also raising security issues such as Cross Site Request Forgery (CSRF)[22]). For performance reasons, the request message uses a stack structure associated with a symmetric encryption algorithm that allows for partial content decryption (e.g., the CTR mode [23]). With this structure, each node only needs to decrypt the information to be used locally, and not the entire message, reducing the processing costs, and also remove the said information after use, reducing bandwidth usage. At the same time, it prevents the leakage of internal information about a CDN’s node to other CDNs in the federation or to eavesdroppers. Adoption of standard digital certificates management and key distribution model. Namely, while digital certificates is unavoidable when one needs to guarantee trust between the elements managed by different authorities, OCP simply builds upon the Public Key Infrastructure (PKI) model for the distribution of symmetric keys for the CDNs’ nodes. The symmetric keys are then employed during content distribution, avoiding the impact that (potentially expensive) public-key operations could have on this process. Independence of network meta-information exchange mechanisms, meaning that the process of indicating which networks may be serviced by each CDN is independent of the content delivery process (i.e., outside the scope of OCP). This is actually similar to what is proposed by the CDNI work group [19], which makes http://www.videolan.org/vlc/

Please cite this article as: H.M. Pimentel et al., OCP: A protocol for secure communication in federated content networks, Computer Communications (2015), http://dx.doi.org/10.1016/j.comcom.2015.07.026

274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316

JID: COMCOM

ARTICLE IN PRESS

[m5G;August 5, 2015;19:0]

H.M. Pimentel et al. / Computer Communications xxx (2015) xxx–xxx

5

Fig. 4. Key exchange in interdomain scenario.

317 318

OCP more flexible regarding the management mechanisms of the CDNs.

319

4.2. Key management

320

Aiming to ensure the continuous security of the network, OCP defines a key management model for regularly renewing the symmetric keys employed in the system. The goal of this model is that, at any given point of time, every domain has one key shared internally (called a domain key) and one key shared with each neighboring domain (called an interdomain key), as illustrated in Fig. 4. OCP assumes standard mechanisms for the deployment of public/private keys and the corresponding digital certificates on Managers and Content Agents that compose the FCDN. This usually involves (1) the generation of public/private key pairs on each authorized machine, (2) the subsequent signature of the corresponding public keys by a Certificate Authority and (3) the publication of the resulting certificates on a public key repository. The Certificate Authority adopted by each domain can be either commercial or controlled by that CDN, as long as the certificates issued to any pair of neighboring Managers are mutually accessible and considered valid, ensuring a trust relationship between the corresponding domains; certificates issued to Content Agents, on the other hand, can be placed on internal repositories from each CDN, and only need to be accessed/recognized by that CDN’s Manager. The renewal of these certificates (e.g., after their expiration) is then handled similarly, according to each CDN’s security policies. Under these settings, the Managers are responsible (1) for periodically establishing interdomain keys with Managers from neighboring CDNs (e.g., using a suitable authenticated key-agreement protocol, such as SMQV [24]), as well as for (2) for the generation and regular renewal of the random symmetric keys inside their own domains. More precisely, the Content Agents inside each domain must periodically contact their local Manager for receiving a fresh domain key list and, if those agents are in the frontier of interconnected CDNs, an additional of interdomain key list; in the latter case, these agents are called Border Content Agents. On the application layer, this key delivery process can be done using a simple HTTPS RESTful request containing in response the ordered keys list to be used, for example; however, since the packets carry secret data, this communication must be protected using a secure channel, which can be accomplished using a mutually authenticated TLS (Transport Layer Security) [25] session with the aforementioned digital certificates. Both domain and interdomain key lists are composed of the currently active key, p > 0 past keys and f > 0 future keys. A suitable choice of p and f (e.g., p = f = 1) can effectively avoid the need for

321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360

strict synchronization between the key renewal process (by Managers) and the key request process (by agents), since the additional (past and future) keys compensate for eventual intervals between such events. For example, if agent A1 requests keys right after they are renewed, but agent A2 from the same domain does not do so, in principle they would end up with different “current keys” and, thus, would be unable to communicate: while A1 would have keys kt , A2 would still be using the older key kt−1 . In OCP, however, agent A1 does not receive only kt , but the set {kt−p , . . . , kt , . . . , kt+ f }. For p = f = 1, for example, A1 will receive keys {kt−1 , kt , kt+1 } after requesting new keys to the Manager, while A2 will have {kt−2 , kt−1 , kt }; hence, they can still communicate using either kt or kt−1 , even though they are not strictly synchronized. Therefore, the node that encrypts and authenticates data simply uses what it sees as its “current key” (e.g., for A1 in the previous example, kt ) and identifies the key being used with the Key ID field, while the receiving node uses that key for decryption and verification. While the key exchange in OCP leverages on a traditional Public Key Infrastructure (PKI) and public-key cryptography, the route construction and consumption themselves rely on the symmetric keys already distributed to the Content Agents, as described in more detail in the following sub-sections. This approach is adopted for performance reasons, since key distribution is expected to occur much less frequently and involve an approximately constant set of communicating nodes than route construction. For example, the distribution of symmetric keys could be performed every one hour, based on the specific security aspects of the adopted algorithm (see discussion in Section 5.2). In comparison, route construction operations occur as often as the content is requested by users (e.g., several hundred requests per minute). Hence, the overall overhead of this strategy is lower than what would be obtained with the straightforward approach of digitally signing all URIs. Concerning key sizes, modern systems with 128-bit security level should use 256-bit keys (one half for encryption and the other half for authentication) or simply 128-bit keys if an all-in-one authenticatedencryption algorithm [26] is employed (e.g., EAX [27]).

363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396

4.3. The OCP message

397

The OCP message contains all information about the network nodes and services used to handle the content delivery request. The overall format of the OCP message is shown in Fig. 5. Its fields are described as follows:

398

•

Header: encloses information about the request, namely (1) the requester ID, which identifies the entity that generated the

Please cite this article as: H.M. Pimentel et al., OCP: A protocol for secure communication in federated content networks, Computer Communications (2015), http://dx.doi.org/10.1016/j.comcom.2015.07.026

361 362

399 400 401 402 403

JID: COMCOM 6

ARTICLE IN PRESS

[m5G;August 5, 2015;19:0]

H.M. Pimentel et al. / Computer Communications xxx (2015) xxx–xxx

Fig. 5. OCP Message Model. Shaded fields are encrypted.

Fig. 6. OCP message marshaled into URI format.

404 405 406 407 408

•

409 410 411 412 413 414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433 434 435 436 437 438 439 440 441 442 443 444 445 446 447 448

•

message, (2) the message generation timestamp, (3) the user’s network address. Some bytes from this field are also used as part of a non-repeating Initialization Vector (IV) for the route encryption process, as further discussed in Section 5. ServiceSet: specifies the services that shall be provided by Content Agents when handling the content. Each Service field comprises the following sections: – Spec ID: an identifier for the service specification. The specification defines both a list of standard parameters required for accessing that service and variable information to be filled in each particular case. For example, a media delivery service could enclose fixed information such as a TCP port number and the underlying communication protocol (e.g., HTTP), as well as variable information such as the media identifier. A video adaptation service, on the other hand, could require the same fixed information, while the variable parameters could be the target video resolution and frame rate. As discussed in Section 2, the specifications and their IDs must be agreed upon by all members of the FCDN (or, at least, by neighboring CDNs) prior to content delivery. – Service body: encloses the values of the variable parameters required in the service specification, for each particular case. PathSet: encloses the list of Content Agents that will participate in the content delivery from the source to the user, as well as security-related information for each of these nodes. The Content Agents from a same (inter)domain are grouped together into a same Path field, which comprises the following sections: – Domain ID: the identification of the (inter)domain; – Key ID: the ID of the current key for that (inter)domain, which is used for encryption and authentication; – Node set: the sequence of addresses for Content Agents that will participate in the content delivery inside that (inter)domain; each node is matched with the index of a service from the ServiceSet field, allowing that node to identify the service it shall enforce during delivery; – Auth: an authentication tag that refers to the whole message (including Header, ServiceSet and the PathSet).

The resulting message is marshaled into a URI, so it can be accessed by the User that requested the content. One example is shown in Fig. 6. In which the message is serialized by using a variation of the Base64 encoding and nested fields are separated by brackets. The general format of the URI is “http://[address:port of the Content Agent to be contacted by the User]/[path for the service in that Content Agent]/ocp/[serialized OCP message using some suitable encoding]”

4.4. Route construction by Managers

449

OCP follows the recursive approach for route construction, meaning that Managers communicate directly for building an OCP Message with the list of hops to the requested content. The reason for this choice is threefold. First, the recursive approach is more effective in concealing network information from end-users, since the latter interacts with a single Manager. Second, it provides lower latency in the interdomain scenario, given that the involved Managers communicate directly instead of repeatedly redirecting the user. Finally, this method potentially facilitates traffic engineering and applicationlayer load balancing, since Managers from different domains can collaborate and determine the best route to the requested resource by considering the current load in each network. The OCP route construction process is depicted in Fig. 7. Initially, the User contacts the Content Provider Portal asking for a URI for accessing the content. At that moment, the Portal may use either the direct or mediated request steering strategy (see Section 2) to provide the User with the requested URI. OCP provides support for any of these strategies, so a real deployment can choose any of them after taking into account some corresponding performancesecurity trade-offs. Namely, the direct approach leads to higher overhead on the Portal itself, since the latter needs to wait for the Manager’s response instead of simply redirecting users as in the mediated strategy; on the other hand, the direct approach potentially improves security because it does not reveal any information about the Manager to the User, unlike the mediated one. Moreover, for the mediated alternative to be more secure, the Portal should sign the redirection credentials so that the Manager is able to verify their authenticity (i.e., that they were provided by a valid Portal) when those credentials are later presented by the User. Whichever the request steering approach adopted, the Manager from the CDN that holds the content is responsible for the URI construction. This Manager collaborates with Managers from neighboring CDNs, by choosing the nodes and services that will be involved in the content delivery process and building the URI with this information. More precisely, the first Manager searches its own CDN for the media content, identifying the address of the server that holds it. It then creates an OCP message, adding the list of services to be enforced inside its own CDN to the message’s ServiceSet field. The Manager also creates the first Path field with all nodes from the source to the Border Content Agent that connects with the next CDN, but not including the latter; each of these nodes is also matched with the index of a service in the ServiceSet. Every Service field and this Path are then encrypted with that domain’s key, which is identified in the Key

450

Please cite this article as: H.M. Pimentel et al., OCP: A protocol for secure communication in federated content networks, Computer Communications (2015), http://dx.doi.org/10.1016/j.comcom.2015.07.026

451 452 453 454 455 456 457 458 459 460 461 462 463 464 465 466 467 468 469 470 471 472 473 474 475 476 477 478 479 480 481 482 483 484 485 486 487 488 489 490 491 492

JID: COMCOM

ARTICLE IN PRESS

[m5G;August 5, 2015;19:0]

H.M. Pimentel et al. / Computer Communications xxx (2015) xxx–xxx

7

Fig. 7. Interdomain route construction.

493 494 495 496 497 498 499 500 501 502 503 504 505 506 507 508 509 510 511 512 513 514 515 516 517 518 519 520 521 522 523 524 525 526 527 528 529 530 531 532 533 534 535 536 537 538

ID section of the Path field. Hence, all information related to some domain are only accessible by nodes that belong to that domain. The whole message is authenticated with the same key and the resulting tag is appended to the Path field. After the domain nodes have been added to the OCP message, the Manager needs to handle the interdomain connection. To do so, it adds a new Service and Path fields for its Border Content Agent that connects with the next domain. This Service field specifies the service to be enforced by the Border Content Agent, whose address is the only one inside this Path’s Node Set section. The Service and Path fields added are then encrypted under the current interdomain key, identified in the Key ID of this new Path. Finally, the whole message is once again authenticated, this time by using the interdomain key. This partially-built OCP message is then (recursively) forwarded to the next Manager, which checks its authenticity by using the interdomain key and once again adds the required Service and Path fields. The last Manager in this chain – i.e., the Manager that is in the same CDN as the User – identifies the route to the User and adds a Path field containing such nodes. After that, it also appends a last interdomain Path field and a last Service field, both encrypted with the previous Manager’s interdomain key. The information enclosed in those fields are meant for the first Manager, to which the OCP message is then sent. Specifically, the NodeSet of this last Path field contains only the address of the Content Agent nearest to the User and, thus, must appear in the final URI built by the first Manager as discussed in Section 4.2; the last Service field encloses the port of that Content Agent, which also appears in the URI, and possibly other relevant information for that Manager. Obviously, this last Path and Service fields are not necessary in a single-domain scenario and, hence, can be omitted in such cases. As the OCP message travels back, revisiting the Managers that participated in its construction, the last Path and Service fields are verified and decrypted by every Manager. They are then re-encrypted and re-authenticated with the interdomain key shared with the next Manager to be visited. It is important to emphasize that, since the Auth section of this last Path field refers to the entire message, each of those Managers can ascertain the final OCP message’s authenticity before it reaches the first Manager. When this finally happens, the first Manager verifies its authenticity, decrypts the last Path and Service fields, extracts the required information from those fields, and then remove those fields from the OCP message. Messages that fail the verification process must be discarded and, depending on the system’s policy, the corresponding user could be notified of the error. The resulting OCP message is used for creating a URI, which is then delivered to the user. This URI reveals only strictly necessary informa-

tion about the network, namely the address to the first Content Agent that must be contacted by the user for acquiring the requested content. We note that different CDNs may use identical or distinct templates for specifying their services. However, OCP requires that each pair of neighboring CDNs share those templates among their Managers. This allows the Managers to assign the adequate services for nodes inside the managed domain and also for Border Content Agents in adjacent domains. Each Service is gradually stacked onto each other during the construction of the OCP Message, thus allowing different Managers to include new services whenever necessary.

544

4.5. Route consumption by User

550

After construction, the User receives the OCP message in the form of a URI, which can then be used for requesting the corresponding content. This process is illustrated in Fig. 8. When a Content Agent CAi receives the request, it needs to identify (1) the services it must provide and, if the content is not locally stored, (2) the contact information of the next Content Agent CAi−1 to which the request must be forwarded. The first piece of information is enclosed in the Service Set field, as referenced in the Node Set section of the message for every node. The second piece of information can be retrieved by accessing CAi−1 ’s address in the Node Set and corresponding services in the Service Set. Notice that both pieces of information are encrypted with keys known by CAi and, thus, can be decrypted by it if necessary. Usually, the above process will take place only after the whole message’s authenticity is verified (using the last Auth section), since unauthentic messages should be promptly discarded. As an extra authentication action, the first Content Agent can also check if the User U requesting the content is indeed the one that the route was built for. This is accomplished by matching U’s network address with the address defined in the Header field. Finally, and albeit not mandatory, the first Content Agent may also discard authentic messages if they are older than a certain time as proposed in [28]; this can be done simply by checking the message’s timestamp enclosed in the Header field. A particularity of OCP refers to the manner in which the fields are stacked together. Specifically, before the OCP Message is forwarded to the next Content Agent, the information regarding that node is removed from the NodeSet field in the respective Path, similarly to a pop() operation in a stack. Also, if the node is the last one in respective Path, only then the whole path is removed. In other words, information for past Content Agents is removed along the way, “consumed” by those Content Agents. On the other hand, a small processing

Please cite this article as: H.M. Pimentel et al., OCP: A protocol for secure communication in federated content networks, Computer Communications (2015), http://dx.doi.org/10.1016/j.comcom.2015.07.026

539 540 541 542 543 545 546 547 548 549

551 552 553 554 555 556 557 558 559 560 561 562 563 564 565 566 567 568 569 570 571 572 573 574 575 576 577 578 579 580 581 582

JID: COMCOM 8

ARTICLE IN PRESS

[m5G;August 5, 2015;19:0]

H.M. Pimentel et al. / Computer Communications xxx (2015) xxx–xxx

Fig. 8. Interdomain route consumption.

583 584 585 586 587 588

589 590 591 592 593 594 595 596 597 598 599 600 601 602 603 604 605 606 607 608 609 610 611 612 613 614 615 616 617 618 619 620 621 622 623 624 625

overhead is introduced because the (now modified) message must have its authentication tag recalculated by each Content Agent. This is performed using the key shared with the next Content Agent defined in the Path field, which can be either a domain or an interdomain key. After an authentic OCP Message finally reaches the last Content Agent, that node starts transmitting the requested content. 4.6. Example scenario In order to give a better understanding of OCP, in what follows we describe a concrete example of the protocol’s operation in the threedomain scenario shown in Fig. 1, for which we assume that the User requests some content whose media ID is aFx1Rd31. Without loss of generality, in this example we adopt the mediated approach for request steering, mainly because it is commonly used in CDNs. The OCP message build in this scenario is depicted in Fig. 9. Its construction comprises the following steps: 1. A User U, connected to CDN C (CNC ), accesses the Content Provider CP and requests some content, e.g., by means of a web Content Provider Portal (CPP). 2. CP responds with the URI for a Manager MA from CDN A (CNA ), hired by that provider for content delivery. 3. U contacts MA , requesting a URI for the content. MA then builds an OCP Message containing: • A Header with information about the request; • A service field Service1 , identified as ss1, which defines the URI for the content and is used by the content source src; • A second service field Service2 , identified as ss2, specifying the service to be enforced inside CNA ; • Path1 , containing all Content Agents from CNA that will be part of the content delivery (namely, src, CAA1 and CAA2 ) and the corresponding services. Service1 , Service2 and the Node set section of Path1 are all encrypted using CNA ’s current domain key kA . The whole message is then authenticated, generating the authentication tag Auth1 . 4. Since CNA has no Content Agent near U, MA stacks two extra fields to the message, Service3 and Path2 , which are meant to the Border Content Agent CAA3 . This path contains interdomain information, so it is encrypted with the interdomain key kAB . The same key is also used for authenticating the whole message, creating the Auth2 tag. MA then sends this partially-built OCP message to the next Manager, MB , which belongs to CNB . 5. MB , in its turn, first verifies the authenticity of the message by checking Auth2 , and only then decrypts Service3 in order to learn which services are required from the nodes inside its domain.

Next, MB adds to the message the service delivery information (Service4 ) related to its own network, as well as a field Path3 with the set of nodes from CNB that will be part of the content route. These fields are all encrypted and the whole message is authenticated using the domain key kB . Once again, since U does not belong to CNB , MB also adds two extra fields to the OCP message, Service5 and Path4 , which enclose interdomain-related information and are encrypted with the interdomain key kBC . The message is authenticated using the same key and then forwarded to MC in CNC . 6. Similarly to MB , MC verifies the message authentication and decrypts Service5 in order to learn how to respond to the request. It also adds two fields to the OCP message, Path5 and Service6 , which designate the three nodes and corresponding services from CNC that will be involved in the content delivery. Both fields are encrypted and the whole message is then authenticated with domain key kC . We note that, since U will contact CAC3 directly, MC may want to force this Content Agent to verify this URI’s validity (e.g., verifying the timestamp and/or U’s network address) as previously discussed in Section 4.5. This can be accomplished, for example, by adding some rules linked to CAC3 ’s identification into Service6 . MC also adds two last fields to the OCP message: Path6 , containing CAC3 ’s address, and Service7 . This information is intended for the first Manager, so it can generate a URI containing the correct instructions for the content delivery by CAC3 . These final pieces of information are encrypted and authenticated with the interdomain key kBC . Finally, MC sends the now complete OCP Message back to MB . 7. MB verifies the message’s authenticity, decrypts fields Path6 and Service7 with kBC , and re-encrypts them with kAB , so it can be read by MA . MB also computes a new authentication tag for the resulting message using the same interdomain key kAB , replacing Auth6 with this new tag. The result is sent back to MA . 8. As soon as MA receives the response message, it checks its authenticity and decrypts Path6 and Service7 . Using the information enclosed in these fields, MA creates the URI to be used by U to access the requested content. This URI contains all OCP message fields except for Path6 and Service7 , whose information was used to generate the plaintext portion of the URI. The URI built in this manner can be easily validated by CAC3 , e.g., for verifying if it is indeed the first node to be contacted by U. Now that the URI construction is finished, MA sends it to U. Thereafter, the route consumption is performed as follows: 1. U uses the URI provided by MA for contacting the Content Agent CAC3 .

Please cite this article as: H.M. Pimentel et al., OCP: A protocol for secure communication in federated content networks, Computer Communications (2015), http://dx.doi.org/10.1016/j.comcom.2015.07.026

626 627 628 629 630 631 632 633 634 635 636 637 638 639 640 641 642 643 644 645 646 647 648 649 650 651 652 653 654 655 656 657 658 659 660 661 662 663 664 665 666 667 668 669 670

JID: COMCOM

ARTICLE IN PRESS

[m5G;August 5, 2015;19:0]

H.M. Pimentel et al. / Computer Communications xxx (2015) xxx–xxx

9

Fig. 9. Message sample. Encrypted fields are shaded.

671 672 673 674 675 676 677 678 679 680 681 682 683 684 685 686 687 688 689 690 691 692 693 694 695 696 697 698 699 700 701 702 703 704 705 706 707

2. CAC3 verifies the message’s authenticity and decrypts Path5 and Service6 using the domain key kC . From the information enclosed in Path5 , CAC3 can also verify whether it is indeed the first agent to be contacted for the content, preventing manipulations of the URI’s plaintext part from going unnoticed. Assuming that the content is not locally available, CAC3 must contact CAC2 , as specified in the received URI. Before doing that, however, CAC3 removes its own information from Path5 ’s Node set section and re-computes Auth5 accordingly, using the domain key kC . 3. When the message reaches CAC2 , it also verifies the message and decrypts Path5 and Service6 using kC . Once again, assuming that the content is not locally available, CAC2 contacts CAC1 after removing its information from the message and recomputing Auth5 ; 4. CAC1 acts like its predecessors, verifying the whole message and decrypting Path5 and Service6 using kC . However, since it is the last node in Path5 , it removes this entire field as well as Service6 from the OCP message before forwarding it to CAB3 . 5. As soon as CAB3 receives the message, it verifies Auth4 and decrypts Path4 and Service5 with the interdomain key kBC . Assuming that CAB3 does not have the content, it acts like CAC1 and removes the entire Path4 and Service5 field from the message before forwarding it to CAB2 . 6. CAB2 verifies Auth3 and decrypts Path3 and Service4 using kB , removes its own information from Path3 , recomputes Auth3 and forwards the resulting OCP message to CAB1 . 7. Assuming that CAB1 does not have the content in cache either, it removes Path3 and Service4 from the OCP message and then forwards it to CAA3 . 8. CAA3 uses the interdomain key kAB for verifying the whole message and for decrypting Path2 and Service3 . If it is unable to provide the requested content from its local cache, it removes both fields from the message and forwards the result to CAA2 . 9. CAA2 decrypts Path1 and Service2 using kA . CAA2 then removes its information from Path1 , recomputes Auth1 , and sends the resulting message to CAA1 ; 10. CAA1 does as its predecessor, decrypting Path1 and Service2 , removing its own information from Path1 and recomputing Auth1 .

11. Finally, CAA1 contacts src for the content specified in Service1 . The content streaming process then begins, the content being delivered from src all the way back to U, passing through all previously configured Content Agents.

708

5. Security analysis

712

In what follows, we show how an FCDN adopting the proposed OCP protocol can addresses the Steering Forgery, Route Forgery and Network Information Leakage threats discussed in Section 3. Namely, OCP deals with the last two threats, while the first can be addressed with standard security mechanisms commonly employed in the Internet.

713

5.1. Dealing with Steering Forgery

719

Steering Forgery is an issue that can be efficiently addressed by standard mechanisms for secure communications, so there is no need for OCP to deal with it differently. Specifically, a common way of dealing with URI forgery is to provide authenticated communications (e.g., via HTTPS) between the User and the system entities, including Content Providers and Managers, similarly to what is done in the Internet to prevent phishing [29]. Indeed, this is the approach adopted in the actual deployment of OCP mentioned in Section 1. Another alternative is to sign the URIs provided by the system to the users, and then validate the signature on the user’s side. In both cases, any URI forgery attempt can be detected by the User by means of standard verification mechanisms.

720

5.2. Handling Route Forgery with Data authentication

732

The straightforward method for obtaining data authentication, which is adopted in OCP, is to employ a Message Authentication Code (MAC) [30]. This ensures that messages generated by OCP can have their integrity and authenticity verified by each network node even in an interdomain scenario. More precisely, the Content Agents that

Please cite this article as: H.M. Pimentel et al., OCP: A protocol for secure communication in federated content networks, Computer Communications (2015), http://dx.doi.org/10.1016/j.comcom.2015.07.026

709 710 711

714 715 716 717 718

721 722 723 724 725 726 727 728 729 730 731

733 734 735 736 737

JID: COMCOM 10

738 739 740 741 742 743 744 745 746 747 748 749 750 751 752 753 754 755 756 757 758 759 760 761 762 763 764 765 766 767 768 769 770 771 772 773 774 775 776 777 778 779 780 781 782 783 784 785 786 787 788 789 790 791 792 793 794 795 796 797 798 799 800 801 802

ARTICLE IN PRESS

[m5G;August 5, 2015;19:0]

H.M. Pimentel et al. / Computer Communications xxx (2015) xxx–xxx

use the OCP are able to verify the authenticity of the request, so that illegitimate (e.g., forged or modified) requests are swiftly discarded. As a result, since the entire route is authenticated in OCP and verified during its consumption, attempts to create fake URIs can be easily detected by the Content Agents involved. Cache pollution is, thus, prevented by the fact that invalid Content Agents are not allowed to participate in the content delivery process. At the same time, a (D)DoS attack in which the attacker tries to flood a single Content Repository with requests to several multimedia contents only succeed if legitimate Managers direct too many of those requests to a same repository; with the deployment of adequate load balancing mechanisms, however, this is highly unlikely to happen. A similar argument applies to Content Agents, as their presence in a content delivery path can be controlled by a Manager depending on the agent’s current load, and OCP ensures that such choice cannot be manipulated by attackers. Therefore, attempts to forge requests so they create multiple flows passing through a same Content Agent (e.g., by changing the target content) will fail because those requests will be simply discarded by the first hop in the path. Sending multiple apparently legitimate requests (e.g., using a botnet) for different contents, on the other hand, will create multimedia flows according to the Managers’s rules, which may include algorithms to eliminate bottlenecks. We note that OCP’s approach for data authentication is not only effective, but also efficient. Indeed, one alternative to using MACs would be to employ digitally signed URIs, but this would lead to (1) higher computational costs, since digital signature algorithms are on the order of 1000 times more computationally expensive than MACs, and (2) a higher control overhead, since digital signatures are usually longer than authentication tags generated by MACs. This would be especially troublesome in the interdomain scenario of FCDNs, as every node would have to verify signatures from different network elements for every new request. This property, besides making a better use of the system’s resources, avoids DDoS attacks in which a hop’s computational resources are exhausted when trying to verify a high load of forged requests. Regarding implementation, since the authentication tags in an OCP message generated are repeatedly modified along its path, an interesting approach is to adopt an incremental MAC. The concept of incrementality, originally introduced in [31], can be better explained through an example: suppose one computes the MAC of a message M, resulting in the tag T, and later this message is modified, becoming M . With an incremental MAC function, the new tag M can be computed from T at a cost proportional to the amount of alteration made in M (e.g., addition or modification of blocks), thus avoiding the need of computing T completely from scratch. As long as the tags are not truncated, incremental MAC functions such as PMAC1 [32] are interesting options for use with OCP. The secure operation of MAC algorithms requires their keys to be replaced long before a collision occurs, i.e., before two or more distinct messages end up leading to the same authentication tag [30]. Even though the resulting key usage limit depends on the specific details of the algorithm, the birthday-paradox dictates that collisions are likely to exist in a set of 2n/2 messages for conventional MACs based on an n-bit block cipher (e.g., PMAC1 or CMAC [30]). For most applications, the default recommendation is thus to limit the key reuse to no more than 248 messages for 128-bit block ciphers [30]. In this manner, the probability of collision is expected to remain below one in a billion. Finally, the length τ of the authentication tags must be large enough to prevent attackers from creating forgeries (i.e., valid message-tag pairs) without knowing the secret authentication key. For a secure MAC algorithm, against which no attack faster than brute-force is known, this task involves about 2τ −1 attempts. For this reason, a conservative recommendation is to adopt τ ≥ 122 bits [33].

5.3. Handling Network Information Leakage with data encryption

803

Network Information Leakage issues can be solved by properly concealing all system information whose disclosure is not strictly necessary, using data encryption mechanisms such as ciphers to protect the nodes’ addresses. In OCP, only authorized entities (i.e., nodes who have the corresponding cryptographic keys) are able to decrypt the data and obtain the information enclosed by it. This ensures that eavesdroppers have minimal access to network information, since only the address of the Content Agent that is directly contacted by the user requesting content can be read (but not modified) by attackers monitoring the network. All other addresses and all services enclosed in the OCP Message are readable exclusively by legitimate Content Agents. Therefore, this information cannot be used by attackers trying to find critical network components, such as potential bottlenecks that could be preferential targets in DDoS attacks. Furthermore, since different keys are used in each domain, OCP also prevents the unnecessary disclosure of information about nodes and services in one domain to Content Agents from another domain. Regarding implementation, one simple way of encrypting the OCP message fields is to employ a 128-bit block cipher (e.g., the Advanced Encryption Standard – AES [34]) operating in counter mode (CTR) [23]. The advantage of CTR is that data blocks are encrypted independently, since it uses the exclusive-OR (XOR) operation for combining each of them with the result of encrypting a counter value. Consequently, Content Agents can decrypt only the part of the message in which they are interested instead of the entire message, incurring a smaller processing overhead. In addition, the removal of parts of the data during route consumption does not lead to the need of re-encrypting (parts of) the message. One important requirement of CTR, however, is that it requires a unique counter value for each plaintext block that is ever encrypted under a same key, across all messages [23]; otherwise, an attacker can easily recover the plaintext blocks encrypted under the repeated counter value. In OCP, this is accomplished by using an especiallybuilt 128-bit IV as the initial value for the counter that can be retrieved from the Header of the OCP Message: it is the result of concatenating (1) a 32-bit block from the requester identifier that generated the message and (2) a 64-bit nanosecond-precision timestamp, while the last 32-bit block is reserved for incremental space. This incremental space is split into two equal parts, one reserved for the encryption of Path and the other one for the encryption of Service. As a result, we ensure that the most-significant 96 bits of any two IVs generated by some entity in a time window of 264 /109 seconds (i.e., ≈ 544 years) will never be identical, meaning that each message receives a different initial counter. Therefore, any message whose Path and Service portions are both smaller than 231 blocks (i.e., smaller than ≈ 256 GiB) can be handled safely, since in this case the leftmost 96 bits of the counter will remain unchanged in spite of the counter value being incremented during the route construction phase.

804

6. Performance analysis To evaluate the impact of OCP, one first idea could be to use RNP’s production environment in which the protocol is currently deployed, which corresponds to an infrastructure interconnecting 27 points of presence (PoPs) and several international links (see Fig. 10) [35]. Indeed, among the institutions that rely on this infrastructure, there are several universities with individual CDNs for providing content to their own campuses, forming an FCDN for nation-wide multimedia content delivery. However the task of measuring the impact of the protocol in this network is not feasible, since many variables (e.g., load balancing and caching mechanisms) would inevitably influence the results, while turning such mechanisms off is not an option in a production environment. In addition, since OCP influences the

Please cite this article as: H.M. Pimentel et al., OCP: A protocol for secure communication in federated content networks, Computer Communications (2015), http://dx.doi.org/10.1016/j.comcom.2015.07.026

805 806 807 808 809 810 811 812 813 814 815 816 817 818 819 820 821 822 823 824 825 826 827 828 829 830 831 832 833 834 835 836 837 838 839 840 841 842 843 844 845 846 847 848 849 850 851

852 853 854 855 856 857 858 859 860 861 862 863 864

ARTICLE IN PRESS

JID: COMCOM

[m5G;August 5, 2015;19:0]

H.M. Pimentel et al. / Computer Communications xxx (2015) xxx–xxx

11

Fig. 10. The Brazilian National Education and Research Network (RNP). Source: http://www.rnp.br/en/.

886

performance of signaling tasks but not the transmission of the content itself, the actual bandwidth and latency overhead introduced by would likely be hard to perceive when such control packets dispute the network bandwidth with actual multimedia content. Given these restrictions, a better way of evaluating the impact is by applying it in a controlled environment, in which OCP’s security mechanisms can be turned on and off easily, thus allowing an actual and isolated evaluation of its impacts. Aiming to provide such controlled measurements but still using a real experimental testbed, we use nodes from PlanetLab2 , a global experimental network with physical networking nodes, to implement the three-domain scenario shown in Fig. 1. The multimedia source belongs to content network CN1 and the user requesting content belongs to CN3 , which means that the content must pass through CN2 during transmission. In what follows, we evaluate OCP’s performance by measuring the latency overheads introduced by the protocol during the content request process, comparing it with a scenario in which no security mechanism is employed. Then, aiming to assess the URI Request Size of OCP message, we calculate the number of bytes used as a function of the number of domains, services and Content Agents involved, which makes the analysis more precise and easily applicable for any particular scenario.

887

6.1. Latency

865 866 867 868 869 870 871 872 873 874 875 876 877 878 879 880 881 882 883 884 885

888 889 890 891 892

The sources of latency in OCP are basically the processing overhead in each node (related to data decryption, verification and re-authentication) as well as the larger size of the messages to be transmitted. Therefore, the total latency in a system using OCP can be computed by Eq. 1: it takes into account the total round-trip time 2

PlanetLab: http://www.planet-lab.org/

(RTT) between all pairs of nodes in the network, RTTmtu , and also the delay resulting from the processing and transmission of the request message, both due to OCP’s security mechanisms and to the application itself.

895 896

Delayapp = Transmission(|M payload |) + Processingapp Delayocp = Transmission(|Mocp |) + Processingocp Latency = RT Tmtu + Delayocp + Delayapp

(1)

To assess the impact of OCP over the content request latency, we measured the latency between pairs of PlanetLab’s nodes in the three-domain network depicted in Fig. 1, with and without the OCP mechanisms. To account for transient network delays, every measurement was repeated 10 times, leading to a standard deviation below 1 millisecond in all cases. Fig. 11 shows the result of the analysis for the route consumption process. This figure highlights the source of latency in each node of the network, namely: 1. The basic RTT between Content Agents: measured using simple ICMP messages; 2. The application overhead: the latency measured in the multimedia delivery service when no security is employed; 3. OCP’s overhead: the difference, in terms of measured latency, between the OCP-enabled setting and an OCP-free scenario (i.e., when all information is unencrypted and there is no authenticity verification operation). Fig. 11 also provides the accumulated value for each of these parameters as the number of nodes involved in the communication increases. Since the route consumption process involves more elements than route construction, the latency introduced by OCP in the former process is higher than in the latter. Therefore, this analysis upper-bounds OCP’s impact in terms of latency. Nonetheless, even in this worst-case

Please cite this article as: H.M. Pimentel et al., OCP: A protocol for secure communication in federated content networks, Computer Communications (2015), http://dx.doi.org/10.1016/j.comcom.2015.07.026

893 894

897 898 899 900 901 902 903 904 905 906 907 908 909 910 911 912 913 914 915 916 917 918 919

ARTICLE IN PRESS

JID: COMCOM

H.M. Pimentel et al. / Computer Communications xxx (2015) xxx–xxx

y(

)

12

[m5G;August 5, 2015;19:0]

Fig. 11. Impact of OCP over content request latency. Table 1 Notation used for our performance analysis. Symbol

Meaning

H nid hp hs

Length of the OCP message header. Length of the node identifier. Total length of the fixed-size sections in Path field (Domain ID, Key ID and Auth). Total length of the fixed-size sections in Service field (Spec ID). Number of nodes in the OCP Message. Number of services in the OCP Message. Number of domains addressed in the OCP Message. Total length of the Service Body section. Total length of the PathSet field in the OCP Message. Total length of the ServiceSet field in the OCP Message. Total Length of the OCP Message.

ν σ δ λ

PS(ν , δ ) SS(s) MT(ν , δ , σ , λ)

σ , and the total length λ of the Service Body sections enclosed by the

948

OCP message.

949

928

scenario, Fig. 11 shows that OCP’s impact remains very low, much smaller than the RTT or the application’s overhead itself. More precisely, if we assume that the content is in cache, the latency added by OCP is only 6 ms, which is insignificant when compared with the latency of a common HTTP request (60–250 ms, according to our tests in the same environment). In the worst case, when no caching mechanism is at play, OCP’s latency still corresponds only to 94 ms, or 10.31% of the total latency, as can be seen in the column corresponding to the last node in the chain (CAC3 ).

929

6.2. URI request size

930

To evaluate the size of OCP’s Request URI, we can consider only the Route Construction phase, since it corresponds to a worst-case scenario: this is the situation in which the OCP Message reaches its maximum length in an URI while in transit. For convenience and easy reference, Table 1 shows the notation employed. Assume a fixed length hp for the Domain ID, Key ID and Auth fields, and also a fixed length nid for the node identifier. In this scenario, Eq. 2 gives the length of the PathSet field as a function of the number of domains, δ , and nodes (Content Agents), ν , enclosed by the OCP Message in the interdomain scenario (i.e., for δ ≥ 2). We note that the PathSet field is actually smaller in the single-domain scenario, since in that case there is no need to include a second (and last) Path and Service fields to be removed by the requesting Manager. Nonetheless, Eq. 2 is enough for our purposes since it represents the worst-case scenario for the URI size.

We can now use Eq. 4 to evaluate the size of OCP message in the example scenario presented in Section 4.6, which involves 3 domains, 7 service instances, 9 Content Agents, and the content source. This is actually a larger scenario than what is currently seen in RNP’s OCP implementation, which usually spans 3–5 nodes, but shows how the protocol can handle large FCDN deployments. In this example, we assume that the lengths for each field in an OCP message are those presented in Table 2, which are reasonable estimates for real implementations. For example, the length of the client’s address depends on the specific network-layer protocol, such as IPv4 or IPv6; in this example, we consider 4-byte IPv4 addresses. Similarly, the Service Body itself has a variable length, depending on the service’s complexity; in our example, we consider the average length of each Service Body to be 32 bytes (which is enough to hold, for example, the sample services shown in Fig. 9), leading to λ = 32 × σ bytes. The same Table 2 also shows the resulting OCP message size calculation. We can conclude that the total length of the signaling messages remains quite low, on the order of hundreds of bytes (434 bytes in our example), which is negligible in terms of network overhead when we compare this value with the actual multimedia content being delivered. In addition, while this message traverses the network it have its size reduced by each network element, so its impact becomes even

920 921 922 923 924 925 926 927

931 932 933 934 935 936 937 938 939 940 941 942 943 944 945

PS(ν, δ) = nid × ν + 2δ × h p 946 947

(2)

Similarly, for a fixed length of the Spec ID field, Eq. 3 provides the length of the ServiceSet field as a function of the number of services

SS(σ , λ) = hs × σ + λ

(3)

If we add Eqs. 2 and 3 together and also include the length of the Header field, H, we obtain Eq. 4. This equation gives the total length of the OCP Message, considering the numbers of domains, nodes and services enclosed by it.

MT (ν, δ, σ , λ) = PS(ν, δ) + SS(σ , λ) + H

951 952 953

(4)

Please cite this article as: H.M. Pimentel et al., OCP: A protocol for secure communication in federated content networks, Computer Communications (2015), http://dx.doi.org/10.1016/j.comcom.2015.07.026

950

954 955 956 957 958 959 960 961 962 963 964 965 966 967 968 969 970 971 972 973 974 975

ARTICLE IN PRESS

JID: COMCOM

H.M. Pimentel et al. / Computer Communications xxx (2015) xxx–xxx Table 2 OCP message size in our example scenario, assuming IPv4 addresses. Message header lenght (H) Length of node ID (nid ) Path length (hp ) Total number of nodes (ν ) Number of domains (δ ) Service length (hs ) Total service body len. (λ) Number of services (σ ) PS(ν, δ) SS(σ , λ) MT(ν, δ, σ , λ)

976 977 978 979 980

981 982 983 984 985 986 987 988 989 990 991 Q2

992 993 994 995 996 997 998 999 1000 1001 1002 1003 1004 1005 1006 1007 1008 1009 1010 1011 1012 1013 1014 1015 1016 1017 1018 1019 1020 1021

16 6 20 10 3 2 224 7 180 238 434

smaller. Furthermore, the representation of the OCP message in a URI format can still fit any modern browser: for example, using Base64 encoding, the total length of the URI would be approximately 579 characters, way below the 2,083 supported by the most restrictive mainstream browser in use nowadays, Internet Explorer3 . 7. Related work Many existing articles dealing with security concerns in CDNs focus on access control, preventing the use of network resources by unauthorized users. In such solutions, authorized users must present credentials containing their access rights (e.g., signed tokens [36] or browser cookies [28,37]) to the Content Agents in order to access the desired content. In comparison, the OCP solution not only gives support to access control mechanisms but also deals with other security concerns such as cache pollution and DDoS attacks. A broader analysis of security in CDNs is presented in [38], in which the authors identify several security concerns that may appear in this context. Even tough they enumerate generic security mechanisms that are commonly used to address these concerns and discuss the overall cost of implementing them in different scenarios, no concrete solution combining such mechanisms is provided. The interest on the interconnection of CDNs recently lead to the creation of a quite a few RFCs and Internet drafts focused on the subject, including its main requirements and characteristics [16,19], the analysis of use cases [39], experiments in this scenario [40], among several others (see http://datatracker.ietf.org/wg/cdni/ for a complete list). The literature also shows some recent works focused on architectural approaches for building FCDNs [41] and on studying their pricing model [42]. However, one of the few works that discusses trust relationships in the interdomain scenario is the Internet Draft by Peterson et al. [21]. Despite raising many important issues, the document is still a working Internet draft and does not go as far as proposing solutions for them. Similarly, the work by Turrini [43] shows concern for authentication between participating CDNs, but no concrete solution is proposed. Commercial CDNs usually use some type of security mechanism for protecting their networks. Akamai, for example, employs a number of network security tools, including Firewalls, HTTP authorization controls, user priorization, SSL, digital certificates, and DoS detection/mitigation mechanisms [44]. Nonetheless, as discussed in [13], some security issues still make Akamai vulnerable to DoS attacks. Most of these issues are related to the user’s ability to override DNS redirections (thus circumventing load balancing tools) and also to the excessive amount of information disclosed to users in the content URIs. The need of concealing the CN’s internal organization from end users is also highlighted in [14], but in a centrally controlled CDN, owned by a single entity, this is a less challenging issue: one can

3 Source: “WWW FAQs: What is the maximum length of a URL?” (http://www. boutell.com/newfaq/misc/urllength.html)

[m5G;August 5, 2015;19:0] 13

simply expose a border server to users and configure the whole route internally (inside their own domain), a facility that does not apply to FCDNs. OCP deals with the vulnerabilities identified by [13,14] in a lightweight fashion while enabling application-layer load balancing and the interconnection of multiple CDNs. Meanwhile, security mechanisms deployed by traditional CDNs end up being complementary to OCP. Finally, there are also works that focus on securing inter-AS routing protocols, such as for the Border Gateway Protocol (BGP) (for a survey, see [45]). However, the requirements of such solutions are quite different from those involved in OCP. This difference comes from the fact that BGP focus on the exchange of topology information between AS and neighborhood discovery, i.e., the question it handles is “which networks are reachable and what are the costs involved”. In this context, the security mechanisms employed must allow the validation of topology information and encryption/authentication of the “out-of-band” messages coming from a number of distributed sources. Meanwhile, OCP’s goal is to setup a suitable overlay route to a given resource upon request, which is done through the cooperation among neighbors who already know each other both for route construction and consumption. Since these operations are performed sequentially and “in-band” with the users’ requests, they require lightweight and low-latency security mechanisms so not to impact the whole process of content delivery. Therefore, BGP’s security mechanisms in the network layer end up being complementary to those provided by OCP in the overlay. Even though the interest in providing security to such scenario is likely to grow with the expansion of federated (content) networks and new solutions may appear in the future, to the best of our knowledge OCP is the first protocol to cope with the need of building interdomain paths for content delivery while ensuring the authenticity of these routes and protecting internal network information from leaking to users or neighboring CDNs.

1023 1024 1025 1026 1027 1028 1029 1030 1031 1032 1033 1034 1035 1036 1037 1038 1039 1040 1041 1042 1043 1044 1045 1046 1047 1048 1049 1050 1051 1052 1053 1054

8. Conclusions

1055

Relying on Content Distribution Networks (CDNs) for distributing multimedia content over the Internet is today an appealing approach. However, there are still some issues to be treated in such solutions, especially in terms of security, since large content delivery infrastructures are likely to become target of malicious entities aiming to misuse its capabilities. This problem is even more challenging when we consider Federated CDNs (FCDNs), which allow for a wider service coverage but makes the interactions between the network’s elements more complex. While straightforward approaches such as using tokens and browser cookies can guarantee user authorization, they do not consider the communication between the FCDN’s elements and, thus, are unable to provide a comprehensive security solution. Aiming to fill this gap, in this paper we present the Overlay Communication Protocol (OCP), a flexible, robust and lightweight mechanism for securing the signaling communication between FCDN elements. OCP tackles a variety of network security issues, from the construction of routes inside the FCDN to their usage by end users. At the same time, and as attested by experimental results, the proposed solution does not impose significant impact in terms of latency and size of request messages. As a final remark, we notice that the OCP protocol is currently being integrated into RNP’s network mentioned in Section 6, with positive results in terms of low overhead and security added to the system.

1056

Acknowledgment

1057 1058 1059 1060 1061 1062 1063 1064 1065 1066 1067 1068 1069 1070 1071 1072 1073 1074 1075 1076 1077 1078 1079

1080

This work supported by RNP, by FAPESP (Fundação de Amparo à 1081 Pesquisa do Estado de São Paulo) under grant 2011/21592-8 and by 1082

Please cite this article as: H.M. Pimentel et al., OCP: A protocol for secure communication in federated content networks, Computer Communications (2015), http://dx.doi.org/10.1016/j.comcom.2015.07.026

1022

JID: COMCOM 14

ARTICLE IN PRESS H.M. Pimentel et al. / Computer Communications xxx (2015) xxx–xxx

1084

the Brazilian National Counsel of Technological and Scientific Development (CNPq) under productivity research grant 305350/2013-7.

1085

References

1083

1086 1087 1088 1089 1090 1091 1092 1093 1094 1095 1096 1097 1098 1099 1100 1101 1102 1103 1104 1105 1106 1107 1108 1109 1110 Q3 1111 1112 1113 1114 1115 1116 1117 1118 1119 1120 1121 1122 1123 1124 1125 1126 1127 1128 1129 1130 1131 1132 1133 1134 1135 1136 1137 1138 1139 1140 1141 1142 1143 1144 1145 1146 1147 1148 1149 1150

[m5G;August 5, 2015;19:0]

[1] Cisco, The Zettabyte Era - Trends and Analysis, Tech. rep., Cisco, 2014. http://www.cisco.com/en/US/solutions/collateral/ns341/ns525/ns537/ns705/ ns827/VNI_Hyperconnectivity_WP.pdf. [2] A. Vakali, G. Pallis, Content delivery networks: status and trends, IEEE Internet Comput. 7 (6) (2003) 68–74. [3] J. Jannotti, D. Gifford, K. Johnson, F. Kaashoek, J. O’Toole, Overcast: reliable multicasting with an overlay network, in: Usenix OSDI Symposium, USENIX Association, Berkeley, CA, USA, 2000, pp. 197–212. [4] D. Andersen, H. Balakrishnan, F. Kaashoek, R. Morris, Resilient overlay networks, in: Proceedings of the 8th ACM Symposium on Operating Systems Principles (SOSP’01), ACM, New York, NY, USA, 2001, pp. 131–145, doi:10.1145/502034.502048. [5] D. Clark, B. Lehr, S. Bauer, P. Faratin, R. Sami, J, Overlay networks and the future of the Internet, Commun. Strategies 63 (3) (2006) 1–21. [6] Z. Li, P. Mohapatra, QRON: QoS-aware routing in overlay networks, IEEE J. Sel. Areas Commun. 22 (1) (2004) 29–40, doi:10.1109/JSAC.2003.818782. [7] B. Frank, I. Poese, Y. Lin, G. Smaragdakis, A. Feldmann, B. Maggs, J. Rake, S. Uhlig, R. Weber, Pushing CDN-ISP collaboration to the limit, ACM SIGCOMM Comput. Commun. Rev. 43 (3) (2013) 34, doi:10.1145/2500098.2500103. [8] A. Balachandran, V. Sekar, A. Akella, S. Seshan, Analyzing the potential benefits of CDN augmentation strategies for Internet video workloads, in: Proceedings of the 2013 Conference on Internet Measurement Conference (IMC’13), ACM, New York, NY, USA, 2013, pp. 43–56, doi:10.1145/2504730.2504743. [9] J. Seedorf, E. Burger, Application-layer traffic optimization (ALTO) problem statement, 2009, (http://tools.ietf.org/html/rfc5693). [10] V. Gurbani, V. Hilt, I. Rimac, M. Tomsu, E. Marocco, A survey of research on the application-layer traffic optimization problem and the need for layer cooperation, Commun. Mag. IEEE 47 (8) (2009) 107–112. [11] X. Liu, F. Dobrian, H. Milner, J. Jiang, V. Sekar, I. Stoica, H. Zhang, A case for a coordinated internet video control plane, in: Proceedings of the ACM Conference on Applications, technologies, architectures, and protocols for computer communication (SIGCOMM 2012), ACM, New York, NY, USA, 2012, pp. 359–370, doi:10.1145/2342356.2342431. [12] S. Triukose, Z. Al-Qudah, M. Rabinovich, Content delivery networks: protection or threat? in: Computer Security – ESORICS 2009, in: Lecture Notes in Computer Science, 5789, Springer Berlin / Heidelberg, 2009, pp. 371–389, doi:10.1007/9783-642-04444-1_23. [13] A. Su, A. Kuzmanovic, Thinning Akamai, in: Proceedings of the 8th ACM SIGCOMM Conference on Internet measurement (IMC’08), ACM, New York, NY, USA, 2008, pp. 29–42, doi:10.1145/1452520.1452525. [14] H. Yin, X. Liu, G. Min, C. Lin, Content delivery networks: a bridge between emerging applications and future IP networks, IEEE Netw. 24 (4) (2010) 52–56, doi:10.1109/MNET.2010.5510919. [15] R. Buyya, M. Pathan, A. Vakali, Content Delivery Networks, Lecture Notes In Electrical Engineering, 9, Springer, 2008. [16] B. Niven-Jenkins, F.L. Faucheur, N. Bitar, RFC 6707 – content distribution network interconnection (CDNI) problem statement, 2012, (http:// tools.ietf.org/html/rfc6707). [17] J. Broberg, R. Buyya, Z. Tari, MetaCDN: harnessing ’Storage Clouds’ for high performance content delivery, J. Netw. Comput. Appl. 32 (5) (2009) 1012–1022, doi:10.1016/j.jnca.2009.03.004. [18] R. Kadlic, J. Blichar, P. Podhradsky, New trends in content delivery networks, in: Proceedings of the International Conference on Systems, Signals and Image Processing (IWSSIP’14), IEEE, 2014, pp. 155–158. [19] K. Leung, Y. Lee, RFC 7337 – content distribution network interconnection (CDNI) requirements, 2014, (https://tools.ietf.org/html/rfc7337). [20] J. Mirkovic, P. Reiher, A taxonomy of DDoS attack and DDoS defense mechanisms, SIGCOMM Comput. Commun. Rev. 34 (2) (2004) 39–53, doi:10.1145/997150.997156. [21] L. Peterson, B. Davie, R. van Brandenburg, RFC 7336 – framework for content distribution network interconnection (CDNI), 2014, (https:// tools.ietf.org/html/rfc7336). [22] N. Jovanovic, E. Kirda, C. Kruegel, Preventing cross site request forgery attacks, in: Proceedings of the Securecomm Workshops, 2006, pp. 1–10, doi:10.1109/SECCOMW.2006.359531.

[23] NISTSpecial Publication SP 800-38A – Recommendations for Block Cipher Modes of Operation, Methods and Techniques, National Institute of Standards and Technology, http://csrc.nist.gov/publications/nistpubs/800-38a/sp800-38a.pdf, December 2001. [24] A. Sarr, P. Elbaz-Vincent, J.-C. Bajard, A new security model for authenticated key agreement, in: Security and Cryptography for Networks, 6280, Springer Berlin Heidelberg, 2010, pp. 219–234, doi:10.1007/978-3-642-15317-4_15. [25] T. Dierks, E. Rescorla, The transport layer security (TLS) protocol version 1.2, 2008, (https://tools.ietf.org/html/rfc5246). [26] J. Black, Authenticated encryption, in: Encyclopedia of Cryptography and Security, Springer US, 2011, pp. 52–61, doi:10.1007/978-1-4419-5906-5_548. [27] M. Bellare, P. Rogaway, D. Wagner, The EAX mode of operation: a two-pass authenticated-encryption scheme optimized for simplicity and efficiency, in: Proceedings of the Fast Software Encryption - FSE’04, 2004, pp. 389–407. http://www.cs.ucdavis.edu/˜rogaway/papers/eax.pdf [28] J. Giles, R. Sailer, D. Verma, S. Chari, Authentication for distributed web caches, in: Computer Security – ESORICS 2002, vol. 2502 of Lecture Notes in Computer Science, Springer Berlin / Heidelberg, 2002, pp. 126–146, doi:10.1007/3-540-45853-0_8. [29] R. Dhamija, J.D. Tygar, M. Hearst, Why phishing works, in: Proceedings of the SIGCHI Conference on Human Factors in Computing Systems, CHI ’06, ACM, New York, NY, USA, 2006, pp. 581–590, doi:10.1145/1124772.1124861. [30] NIST, Special Publication 800-38B Recommendation for Block Cipher Modes of Operation: the CMAC Mode for Authentication, National Institute of Standards and Technology, U.S. Department of Commerce, http:// csrc.nist.gov/publications/PubsSPs.html 2005. [31] M. Bellare, O. Goldreich, S. Goldwasser, Incremental cryptography: the case of hashing and signing, in: Advances in Cryptology (Crypto’94), in: Lecture Notes in Computer Science, 839, Springer-Verlag, 1994, pp. 216–233. [32] P. Rogaway, Efficient instantiations of tweakable blockciphers and refinements to modes OCB and PMAC, in: Advances in Cryptology (Asiacrypt’04), 3329, SpringerVerlag, Heidelberg, Germany, 2004, pp. 16–31. [33] CSEC, CSEC approved cryptographic algorithms for the protection of sensitive information and for electronic authentication and authorization applications within the government of Canada, http://www.cse-cst.gc.ca/its-sti/ publications/itsa-asti/itsa11e-eng.html, 2011. [34] NSIT, Federal Information Processing Standard (FIPS 197) – Advanced Encryption Standard (AES), National Institute of Standards and Technology, http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf, 2001. [35] RNP, National education and research network – services (in portuguese), http://portal.rnp.br/web/servicos, (November 2001). [36] J. Kurian, K. Sarac, A security framework for service overlay networks: access control, in: Proceedings of the 5th International Conference on Broadband Communications, Networks and Systems (BROADNETS’08), IEEE, 2008, pp. 412–419, doi:10.1109/BROADNETS.2008.4769117. [37] B. Zhou, X. Pan, Cookie-based CDN security authorization design, in: Proceedings of the International Conference on Internet Technology and Applications (iTAP), IEEE, 2011, pp. 1–3, doi:10.1109/ITAP.2011.6006202. [38] P. Giura, G. Reyes, The security cost of content distribution network architectures, in: Proceedings of the IEEE 35th Annual Computer Software and Applications Conference Workshops (COMPSACW), 2011, pp. 128–135, doi:10.1109/COMPSACW.2011.31. [39] G. Bertrand, E. Stephan, T. Burbridge, P. Eardley, K. Ma, G. Watson, RFC 6770 – use cases for content delivery network interconnection, 2012, (http://tools.ietf.org/html/rfc6770. [40] G. Bertrand, F. Le Faucheur, L. Peterson, Content distribution network interconnection (CDNI) experiments, 2012, (Internet-Draft:(http://tools.ietf.org/html/ draft-bertrand-cdni-experiments-02). [41] I. Más, A. Evans, P. Stallard, A. Damola, Managing the Growth of Video over IP, Tech. rep., Ericsson, 2011. http://www.ericsson.com/res/thecompany/ docs/publications/ericsson_review/2011/Media-Delivery-Network.pdf. [42] T. Pham, S. Fdida, P. Antoniadis, Pricing in information-centric network interconnection, in: Proceedings of the IFIP Networking Conference, 2013, pp. 1–9. [43] E. Turrini, An architecture for Content Delivery Networks federation, Universita‘ di Bologna e Padova, 2004 Ph.D. thesis. [44] Akamai, Akamai security capabilities: protecting your online channels and web applications (whitepaper), 2009, (http://www.akamai.com/). [45] K. Butler, T. Farley, P. McDaniel, J. Rexford, A survey of BGP security issues and solutions, Proceedings of the IEEE 98 (1) (2010) 100–122, doi:10.1109/JPROC.2009.2034031.

Please cite this article as: H.M. Pimentel et al., OCP: A protocol for secure communication in federated content networks, Computer Communications (2015), http://dx.doi.org/10.1016/j.comcom.2015.07.026

1151 1152 1153 1154 1155 1156 1157 1158 1159 1160 1161 1162 1163 1164 1165 1166 1167 1168 1169 1170 1171 1172 1173 1174 1175 1176 1177 1178 1179 1180 1181 1182 1183 1184 1185 1186 1187 1188 1189 1190 1191 1192 1193 1194 1195 1196 1197 1198 1199 1200 1201 1202 1203 1204 1205 1206 1207 1208 1209 1210 1211 1212 1213 1214 1215 1216 1217 1218 1219