The Security Cost Of Content Distribution NetworkArchitectures

Paul GiuraAT&T Security Research Center

New York, USApaulgiura@att.com

Gustavo de los ReyesAT&T Security Research Center

New York, USAgdelosreyes@att.com

Abstract—Content Distribution Network (CDN) architecturesface a wide range of security threats. In this paper, we comparethe cost of achieving low and high security for different CDNarchitectures. We reviewed the existing and emerging systems,identified the threats that they face, defined the general securityrequirements and considered the mechanisms available to meetthe requirements. To assess the security cost, we first definedthe process for selecting security mechanisms, and then definedthe process for ranking the mechanisms for each architecture.The security comparison result clearly shows that the more thecost of providing service is pushed to the end points, the higherthe security cost. To the best of our knowledge, this study is thefirst effort to assess a security cost comparison of different CDNarchitectures. Our work is orthogonal to other studies that tryto find ways of reducing the content distribution service cost,rather than quantifying the cost to provide service security.

I. INTRODUCTION

A very large amount of the network traffic content trans-ported over the Internet today is handled by specializedcontent distribution infrastructures, generally called ContentDistribution Networks (CDNs). The initial goal of designinga CDN was mainly to reduce the content distribution cost,rather than to strengthen the service security. In this paper welook at the CDN architectures from the security perspective.We propose a framework to asses the cost of providing securityto the content distribution service by taking into account fourmajor CDN architecture types. We believe our methodologyis robust and can be used as a guideline when designing andimplementing secure CDN systems.

A generic CDN is a system deployed across the Internet todistribute content (e.g. movies, pictures, large files, etc) trans-parently and efficiently, offering large capacity on demand todirect customers and a better end-user experience. An exampleof a CDN can be a global internet content and applicationdelivery infrastructure (e.g. commercial systems developedby Akamai [1] and Limelight [2], or academic experimentalsystems CoDeeN [3] and CoralCDN [4]), where the CDNcustomers are the content providers, the end users having mostof the time free access to the content. Another example canbe TV channels content distribution infrastructures (e.g. peer-to-peer TV distribution systems (P2PTV) used by Joost [5]),where the end-users’ access to the content is granted basedon paid subscription in many cases. Such a system can havea partially distributed architecture (e.g. caching edge servers

based), a fully distributed architecture (e.g peer-to-peer), or acombination of the two.

As with other on-line services that have to transparentlysatisfy millions of user requests, CDNs are vulnerable to awide range of security attacks. Some of the security attackscan be targeted at the content providers or at the end-users,while others at the CDN itself. In general, as a result ofan attack, all parties are affected to a certain extent. Forexample, in [6] authors describe and exploit a vulnerabilityfound in the resource name resolution mechanism, that forcesthe CDN edge servers to access the origin server for eachuser request, instead of using the valid local cached contentat the edge servers. In this way, the attacker can actuallyuse CDN resources to amplify the attack against the contentprovider. As a result, not only the user experience is affected,but also the content provider’s service is disrupted and theCDN mechanism is not serving its purpose.

In general, besides the specific attacks observed in [3] (e.g.unintentionally enabling spamming), there are several othertypes of attacks that can affect a CDN: Denial of Service(DoS) attack (e.g. legitimate users are deprived of the servicesthey would normally expect to have), Distributed Denial ofService (DDoS) attack (e.g. a multitude of compromisedsystems attack a single target, causing DoS for users of thetargeted system), confidentiality breach (e.g. access to re-stricted communication between users and content providers),privacy violation (e.g. access to user private data), deliveryof corrupted content (e.g. incomplete content), injection ofunwanted content (e.g. polluted content) and theft of service(e.g. a user has unlawful access to content).

In this work we present a method to assess the cost ofachieving low and high CDN service security for four architec-tures from two broad categories: a) caching edge-server basedand b) peer-to-peer (P2P) based. The caching-based categoryis represented by systems that have a number of caching edgeservers deployed across the Internet backbone, closer to theend users, from where the content is delivered. Because thenumber of caching servers used, in general, is much smallerthan the number of end-users requesting the content, the end-user - caching-server communication follows the client - servermodel. Therefore the caching-based CDNs have some amountof centralized systems functionality. On the other hand, theP2P based architectures are highly distributed and assume the

2011 35th IEEE Annual Computer Software and Applications Conference Workshops

978-0-7695-4459-5/11 $26.00 © 2011 IEEE

DOI 10.1109/COMPSACW.2011.31

128

2011 35th IEEE Annual Computer Software and Applications Conference Workshops

978-0-7695-4459-5/11 $26.00 © 2011 IEEE

DOI 10.1109/COMPSACW.2011.31

128

content is delivered not only from the cache servers, but alsofrom users that already retrieved and host the content.

For each broad category, caching-based and peer-to-peerbased, we considered two specific cases for our study. Forfirst category, we consider the cases when the entity thatdistributes the content either owns the network backbone oruses the backbone owned by some third party. In the case ofP2P based architectures, we consider the pure P2P architectureand the hybrid architecture. The hybrid architecture uses acombination of caching edge servers and independent peersto distribute the content. We will explain the assumptions anddetails for each of the architectures in Section III.

First, we define the general security requirements for aCDN. Then, based on commonly accepted best practices, weidentify the mechanisms to meet the security requirements forlow and high security levels. Next, we define the processfor selecting the security mechanisms, and then we definethe process for ranking the selected mechanisms for eacharchitecture. In the final step, we aggregate the cost to achievehigh and low security levels for all four architectures, anddiscuss our findings. Thus, with this work we make thefollowing key contributions:

• We identify the security requirements and the mecha-nisms generally used for a general CDN architecture.

• We provide a general ranking algorithm based on com-monly accepted best practices in the security industry.

• We evaluate the cost to achieve high and low securitylevels, when using four of the existing CDN architectures.

The rest of the paper is organized as follows. In Section IIwe define CDN security requirements and identify the mecha-nisms to meet the requirements, in Section III we present theassumptions and a description of the architectures considered,in Section IV we present the security cost ranking algorithmfor each architecture as well as the ranking results. Section Vsummarizes the related work and in Section VI we present ourconclusions.

II. SECURITY REQUIREMENTS AND MECHANISMS

In this section we define the security requirements for ageneric CDN architecture and consider the existing mech-anisms to meet the requirements. We consider the twomnemonics commonly used to summarize the security re-quirements that a CDN should provide: ‘CIA’ and ‘TripleA’. ’CIA’ is derived from Confidentiality (C), Integrity (I)and Availability (A). However, for stronger security anotherthree requirements, Authentication (e.g. content consumers orusers authentication), Access Control (e.g. using passwords)and Non-repudiation (e.g. proof of integrity and origin ofcontent), should be considered to form an enhanced ‘CIA’or the ‘CIA+’ as mentioned in [7]. ‘Triple A’ is derivedfrom Authentication, Authorization and Accounting, and theserequirements are partially included in the ‘CIA+’, as sub-requirements, and mostly capture the security requirementsof CDN distributing content to subscribers. Thus, ‘Triple A’requirements emphasize that the accounting service cannot

be used if the user is not authorized and a user cannot beauthorized if she was not authenticated.

Across all these general security requirements we considerConfidentiality, Integrity, Availability and Theft of ServicePrevention the most relevant for CDN security. For eachrequirement we present the definition, the specific set of CDNsub-requirements and the set of mechanisms commonly usedto meet the requirements.A. Confidentiality

Confidentiality ensures that the information is accessibleonly to those authorized to have access to it. We identifiedthe following set of CDN confidentiality sub-requirements:

(C1) Contracts confidentiality: The contracts’ details and thecontent metadata (ID and type) is known only by the user andthe content provider.

(C2) Content confidentiality: Content data is known only bythe user and the content provider.

(C3) User data confidentiality: User data is kept private (e.g.user name, billing address, SSN, etc).

(C4) Resources confidentiality: The resources used to pro-cess the data should be kept private (e.g. IP address space,protocols, OS, port numbers, etc).

Note that from the perspective of a content provider confi-dentiality is a business requirement while from the customerperspective it becomes a privacy concern. Confidentiality is

Confidentiality Sub-Requirement MechanismAuthentication (C1, C2) Token

PasswordBiometricsReputation mechanismsDigital signatures(IP) Address based

Authorization (C2) Access Control List (File, Network)Time based authorization

Content storage & transport Encryption (IPSec, SSL/TLS, other)confidentiality (C2) Non-encryption (Secure tunneling)

Aggregation of distributed dataUser data storage & transport Encryption (3DES, AES, other)confidentiality (C2, C3) Aggregation of distributed data

Software securityNetwork resources Firewallsconfidentiality (C4) Anonymization

NATs

TABLE I: Security mechanisms for confidentiality.supported by the access control mechanisms for authentication,authorization and accounting. Mechanisms for authenticationensure that the user of the system is the one that she claimsto be, authorization mechanisms are responsible to authorizethe already authenticated users to have access to certaincontent under the agreement rules. Accounting mechanismsare responsible for monitoring user activity.

Table I summarizes the confidentiality sub-requirementsand lists the mechanisms commonly used to meet theserequirements. Some of the mechanisms can satisfy more thanone CDN sub-requirement. Both contracts (C1) and content(C2) confidentiality can be achieved, to some extent, by usingauthentication through tokens, passwords, biometrics, digitalsignatures, user address (or geo-location) or a reputation basedmechanism. For example, a reputation system can authenticateusers based on the reputation created when using the system in

129129

the past (e.g. if no illegal activities were recorded in the first 15days of service, then authenticate as legitimate user). After theauthentication, the content confidentiality (C2) is strengthenedby using authorization mechanisms such as access control lists(e.g. lists with registered users, with authorized IP addresses)or time based authentication systems (e.g. deliver specificcontent after a predefined hour in the day). Both user data(C3) and content confidentiality (C2) can be achieved by usingspecific encryption mechanisms for each case. Data transportconfidentiality can be achieved by using secure transportprotocols (e.g. SSL/TLS), or by aggregating the data at theend points from different sources. For example, if pieces of adata file are distributed at different peers, if an attacker doesn’thave knowledge about the content location and how to put allthe pieces together, she is not able to gain access to the filecontent. CDN resources confidentiality (C4) can be achievedby using general network filtering and hiding mechanismssuch as firewalls, anonymization or network address translation(NAT) mechanisms, currently used in practice.B. Integrity

Integrity refers to the trustworthiness of information re-sources. Integrity mechanisms ensure that communication be-tween entities is not being tampered with by another party,especially one that can intercept and modify their commu-nications. We identified the following set of CDN integritysub-requirements:

(I1) Data integrity: The received content is what the userrequested (e.g. user will not receive polluted content).

(I2) Source integrity: The source of data is the claimedprovider of data.

(I3) Service and features integrity: The service contains thespecified features that operate as advertised (e.g. if the CDNcontract is for advertisement free content then the contentreceived is advertisement free).

Integrity Sub-Requirement MechanismData integrity (I1) Message Integrity Code (MIC)

Message Authentication Code (MAC)Source integrity (I2) Source digital signatures

Reputation mechanismsService integrity (I3) Software integrity

TABLE II: Security mechanisms for integrity.Table II summarizes the integrity sub-requirements and

enumerates mechanisms commonly used to satisfy them. Ingeneral, data integrity (I1) can be achieved by using Mes-sage Integrity Codes (MIC) or Message Authentication Codes(MAC). Esentailly, MIC and MAC are short pieces of infor-mation sent with the data in order to authenticate the content atthe destination. The difference between MIC and MAC is that,a MAC contains a secret key, known only by the sender andreceiver, and the data checksum. A MIC contains only the datachecksum. In many cases using a MIC is sufficient if sourceintegrity is not a requirement. However, in many other cases(e.g. when subscribing to a service) the source integrity is arequirement. Therefore source integrity (I2) can be achieved byusing a MAC, digital signatures or reputation mechanisms formore flexible CDN systems (e.g. accept content from sources

that delivered unaltered data in the past). To provide serviceintegrity (I3), the system should use mechanisms for softwareintegrity (e.g. antivirus, patching, resource monitoring etc),deployed at the content provider and in the CDN itself.

C. Availability

Availability refers to the availability of information re-sources. We identified the following CDN availability sub-requirements :

(A1) Quality of Service (QoS) assurance: Availability at thespecified QoS (e.g. content will be available at the contractspecified bit rate).

(A2) Denial of Service (DoS) resilience: Resilience to slowrate attacks (such as resilience to attacks that exploit knownvulnerabilities and can cause DoS).

(A3) Distributed Denial of Service (DDoS) resilience:Resilience to flooding attacks (e.g. amplification attacks orattacks sustained by botnets)

Table III lists the major security sub-requirements for avail-ability and commonly used mechanisms. In general, for aCDN, the quality of service (A1) is affected whenever the con-tent is not available at the required data rate. From a securityperspective there are two major requirements for availabilitythat can affect the QoS: denial of service (DoS) resilience(A2) and distributed denial of service (DDoS) resilience(A3). We consider that DoS resilience can be improved by

Availability Sub-Requirement MechanismDoS prevention (A1, A2) Patching

AntivirusIPS/IDS/Firewall

DDoS prevention (A1, A3) ScrubbersIngress filteringTracebackRate LimitingOver-provisioningResidual Risk

TABLE III: Security mechanisms for availability.

using fundamental security mechanisms at both levels: serverlevel and network level. Thus, a CDN can use mechanismsthat can reduce the impact of known security vulnerabilitiesand threats, such as software patching and antivirus at theserver level, and Intrusion Prevention Systems (IPS), IntrusionDetection Systems (IDS) or firewalls at the network level orserver level. Another major sub-requirement, and arguably themost difficult to meet, is the resilience to DDoS attacks. Someof the existing mechanisms such as ingress filtering [8], ratelimiting, traceback [9] tools or scrubbers1 are commonly usedin practice. In most cases existing systems use a combina-tion of them. However, the efficiency of each mechanismis correlated with the number of instances deployed in thenetwork. Based on the risk analysis, many such mechanismsare deployed, resulting in over-provisioning, which is listedas a mechanism itself. However, since there is no completesolution to the DDoS problem, there is a significant amountof residual risk associated with it. Table III shows the residual

1Specialized network devices that allow only legitimate traffic to beforwarded on through the network towards the target.

130130

risk as a mechanisms for availability for the completeness ofour presentation.D. Theft of Service Prevention

Theft of service (TS) is committed when a person obtainsvaluable content and services without lawfully compensatingthe provider of said content and services. Theft of servicehappens mostly in the cases when the CDN delivers contentto the users based on subscription. We identified the followingsub-requirements to prevent and detect theft of service:

(TS1) Users authentication: All users are authenticated (e.g.before accessing the service).

(TS2) Users authorization: Users only receive content theyare authorized to receive (e.g. users will not receive morecontent than the contract specifies).

(TS3) Digital Rights Management (DRM): Users are notable to share what is not allowed to share.

TS Prevention Sub-Requirement MechanismAuthentication (TS1) See mechanisms listed in Table IAuthorization (TS2)DRM (TS3) Restricted codingMonitoring (TS3) Watermarking

TABLE IV: Security mechanisms for TS prevention.

Table IV lists the commonly used mechanisms to preventtheft of service. The first two sub-requirements refer to theusers’ authentication and authorization, and the commonlyused mechanisms for them were presented in Table I. In gen-eral, the DRM concept describes any technology that restrictsuses of digital content not desired or intended by the contentprovider. In our vision, DRM has two major components:prevention of unlawful content usage, done in most cases usingrestricted coding, and detection of unlawful content usagethrough monitoring, using watermarking techniques.E. Security Levels

We evaluate the security cost for two security levels: highsecurity and low security. For example, high security can berequired for the distribution of financial information, premiumTV contents, software updates, etc. For the low security levelwe relaxed part of the requirements, namely confidentiality,integrity and theft of service prevention, but we considerthe availability highly important for all the architectures. Forexample, low security can be required for distribution of freeTV channels, free multimedia content etc.

III. CDN ARCHITECTURES

In this section we present the assumptions we make in orderto conduct our CDN security cost analysis. We describe thefour types of architectures that we consider as well as thethreats that they face.

A. Backbone Owned CDN Architecture

The backbone owned (BB) CDN architecture assumes thatthe network backbone is owned by the same entity distributingthe content. The Internet service to the end-users is deliveredby a third party Internet Service Provider (ISP). For example,dedicated infrastructures used by Limelight [2] and AT&T [10]fall in this category. Such an architecture assumes that the

content is served from several caching edge servers deployedacross the network backbone, and their number is muchsmaller than the number of end-users requesting the content.Hence, we consider that the system has some amount ofsimilarity with a centralized architecture, where the centralcomponents are the caching servers together with the mainte-nance and control components. Figure1a shows a high levelrepresentation of such an architecture. As with the majorityof central managed systems, this architecture is vulnerable toDistributed Denial of Service (DDoS) attacks. Such attacks aremost of the time generated as a result of a coordinated activityattributed to a large number of compromised machines tryingto access the same resource at the same time. Assuming thetransporting network backbone and the CDN are owned bythe same entity creates the advantage of having control overthe distribution systems (e.g. caching edge servers), and themechanisms to prevent and mitigate DDoS attacks. Owningthe network backbone can have high impact in reducing thecost of providing high integrity, availability and assuring highsecurity levels.

CDN Owner Backbone

Edge

Server

Edge

Server

3rd Party ISP

Content

User

UserUser

User

(a) Backbone owned (BB)

3rd Party Backbone

Edge

Server

Edge

Server

3rd Party ISP

Content

User

UserUser

User

(b) Third Party Owned (3P)

Fig. 1: Caching edge-servers CDN architectures.B. Third Party Owned CDN Architecture

The Third Party Owned (3P) CDN is very similar to theprevious architecture with the exception that the distributionnetwork backbone is owned by other providers rather thenonly the provider that owns the caching edge servers. Thisdifference is an important control factor for selecting themechanisms to meet the security requirements. Examples ofsuch architectures include systems developed by Akamai [1]or Amazon CloudFront [11], with servers deployed all over theworld distributing content over third party networks. Figure 1brepresents the third party owned CDN architecture at a highlevel.

C. Peer-to-peer CDN Architecture

The peer-to-peer (P2P) architecture assumes that the contentwill be delivered either from dedicated peers, that are ownedby the content distribution entity and are used to improvethe Quality of Service (QoS), or from end-users peers thathave already downloaded the content and are able to shareit with other peers by using their own resources. In mostcases, when users subscribe to receive content, to meet thebasic security requirements, the service provider must usean authentication mechanism for the end-users and a centralcontent monitoring component, such as a tracker in BitTorent[12] like systems. Thus, even in a general P2P architecture,

131131

for high security requirement, there exists at least a centralizedcomponent represented by the authentication and monitoringmechanisms. Therefore, because of the need to use a central-ized mechanism, when assessing the cost to secure the pureP2P architecture, the cost for high security level increases dueto the DDoS resilience cost specific to securing centralizedsystems. Figure 2a shows an intuitive representation of the P2Parchitecture described. However, when used for applications

Content

User(Peer)

Content

Content

User(Peer)

User(Peer)

User(Peer)

User(Peer)Peer

Authentication/Monitoring System

(a) Peer-to-peer (P2P)

Authentication System

(b) Hybrid (Hy)

Fig. 2: Peer-to-peer and Hybrid CDN architectures.with low security requirements, P2P architectures prove to bea good alternative to the centralized systems for both: highcontent availability and reduced cost of content distribution.

D. Hybrid Architecture

The hybrid architecture (Hy) combines two of the CDNarchitectures presented above, the third party owned CDNarchitecture and the P2P architecture. This architecture as-sumes the content is delivered from the edge servers as wellas the end-user peers. An example of a commercial system,called LiveSky, using a hybrid architecture is described in[13]. The general functionality is as follows. When the userrequests content, the system will first contact the monitoringcomponent that knows the location of each piece of content.If the content requested was already served to some peersinside the same ISP, the content will get delivered from thatlocation, thus saving the cost of delivering it from the cachingedge server. If the content requested is not at the peers, thenthe content will get delivered from the edge server as in thegeneral CDN architecture. The main advantage of a hybridarchitecture is in reducing the transport cost of traversingthe boundaries between different ISPs, or of traversing theaccess link. A high level representation of this architecture isshown in Figure 2b. Intuitively, the hybrid architecture seemsto provide the best performance in terms of data availabilityand system scalability. From a security perspective we arguethat it inherits most of the limitations of both caching edgeservers based and P2P based architectures.

IV. RANKING PROCESS

In this section we compare the architectures presented abovefrom the security perspective. We perform the first comparisonby selecting the mechanisms described in Section II for eacharchitecture depending on its specifics. Further, we considerthe security strength of each mechanism and the difficulty ofimplementing it for each architecture. The final comparison isbased on the cost to satisfy individual requirements for eacharchitecture. It takes into account the cost of implementing

each chosen mechanism considering deployment, maintenancecost, hardware cost and usability difficulty. In the rankingprocess we evaluated each architecture using the followingsimple evaluation algorithm. For each architecture and eachsecurity level:

Step 1: Select the mechanisms to meet the requirementsbased on commonly accepted security best practices.

Step 2: Evaluate the cost of each mechanism (on a scalefrom 1[low] to 5[high]) in Step 1 based on:

• Deployment and maintenance cost.• Hardware cost.• Usability difficulty.Step 3: For each requirement sum up all the difficulty scores

of the mechanisms used.Step 4: Sum up all the scores for each requirement.

We use a numeric scale, from 1[low] to 5[high], to evaluateeach of the mechanisms meeting sub-requirements. Note thatthe evaluation numbers do not represent absolute values for theevaluation cost. The numbers represent the relative evaluationcost for each mechanism corresponding to the same sub-requirement based on common best practices, real deploymentscenarios and our experience. The results displayed using thesenumbers are intended for security cost (difficulty) visualizationrather than as absolute experimental results. Next in thissection we present the evaluation of security cost for variousmechanisms grouped by sub-requirement, for low (L) and high(H) security levels, for each of the architectures: backboneowned (BB), third party owned (3P), peer-to-peer (P2P) andhybrid (Hy).A. Confidentiality Cost

Table V lists for each confidentiality sub-requirement andeach of the four architectures the evaluation cost to achievelow and high security. We consider the same mechanisms usedto meed the requirements described in Section II, and choseto assign a cost based on commonly accepted security bestpractices. For the mechanism not selected we consider the costto be zero and corresponds to empty positions in the table.

Confidentiality BB 3P P2P HyMechanisms L H L H L H L HToken 2 2 2 2Password 1 1 1 1Digital signatures 2 2ACL (File, Network) 3 3 3 3Encryption (IPSec, SSL/TLS) 3 3 3 3Aggregate distributed data 2 2Encryption (3DES, AES) 3 3 3 3Software security 3 3 3 3 3 3 3 3Firewalls 2 2 2 2 2 2Anonymization 3 3 3 3NATs 2 2 2 2 2 2CONFIDENTIALITY SCORE 8 18 8 18 7 21 11 25

TABLE V: Security cost of confidentiality mechanisms forlow (L) and high (H) security, for each CDN architecture:backbone owned (BB), third party owned (3P), peer-to-peer(P2P) an hybrid (Hy).

For caching edge server based architectures, BB and 3P,we assume the predominant authentication mechanisms arepasswords for low security, and tokens for high security. For

132132

P2P and hybrid architectures, since the content is deliveredalso from the user peers, the use of digital signatures is amandatory requirement for high security. We estimated aboutthe same cost (difficulty) for token and digital signatures usagefor the two architectures because both approaches require theuse of a dedicated infrastructure.

For low security, we assume no authorization is requiredonce the users pass the authentication step. Thus, the cost toachieve authorization is not existent (e.g. for example whenusers access content based on free registration). However,for high security (e.g. when accessing premium internet TVservice offering multiple plans at different prices) a strongauthorization mechanism, in a form of access control lists(ACL) is needed. We consider the authorization mechanismsto be equally costly across all four architectures since in allcases we assume it is centralized.

In general, for content storage and transport confidentiality,none of the architectures use a mechanism for low security(e.g. content is public and sent in clear, web pages, internetvideo, etc). In the case of high confidentiality, we assumeall architectures make use of some encryption mechanisms.However, because of the high distribution of the content inP2P and hybrid architectures, another mechanism to aggregateall the data is needed, increasing the security cost.

To provide user data storage and transport confidentiality,we assume all architectures should have the highest level ofsecurity for the software used for those tasks. In general,user data information is considered highly sensitive and isprotected by regulatory compliance mechanisms that shouldbe implemented based on strict standards. However, for lowsecurity, users consent to send data over unprotected channels(e.g. registering to receive feeds from news sites), and theirdata to be stored unencrypted. For high security, encryptionis required by default for both transport and storage, thereforebeing more costly.

Lastly, being able to achieve resource confidentiality is astrong requirement for a CDN because it allows to hide thepotential vulnerabilities that attackers can exploit to compro-mise the availability of the service. Thus, we consider equallycostly to achieve both, low and high resource confidentiality,for each architecture. The variation in security costs is mostlydetermined by specific implementations. For example, forBB and 3P architectures one can use firewalls and NetworkAddress Translation (NAT) mechanisms to hide the networkresources. For P2P architecture one can use an anonymiza-tion mechanism. In the case of the hybrid architecture themechanisms for both centralized and P2P should be used, thusmaking the hybrid architecture having higher security cost.

Figure 3a summarizes the cost to achieve confidentiality forlow and high security for all four architectures based on theconfidentiality scores displayed in the last row of Table V.From the graph we can see that, for low security require-ments, the security cost difference among architectures is notsignificant. However, for high security the cost to achieveconfidentiality increases if more content is pushed to the peers.The higher cost of the hybrid architecture is explained by

the need to meet higher confidentiality requirements for botharchitectural components: caching edge servers and peer-to-peer component.

B. Integrity Cost

We evaluated the cost to achieve integrity by considering themechanisms for each sub-requirement and ranking them basedon the same algorithm described above. Table VI lists thedifficulty scores for the mechanisms used to achieve integrityfor low and high security for the four architectures.

Integrity BB 3P P2P HyMechanisms L H L H L H L HMIC 1 1 1 1MAC 2 2 2 2Source digital signatures 2 2 2 2Reputation mechanisms 2 2 2 2Software integrity 3 3 3 3 3 3 3 3INTEGRITY SCORE 4 7 4 7 6 9 6 9

TABLE VI: Security cost of integrity mechanisms.

In general, we believe that for low security, all architec-tures should use a checksum mechanism (MIC) to ensurethe integrity of the data at end-points. In most cases theimplementation of MIC mechanisms is not costly since it doesnot require the use of a dedicated infrastructure. However,using a MIC does not guarantee the authentication of thedata source and, in most cases, when high data integrity isrequired (e.g. financial data, software updates distribution, etc),the use of a MAC is used to validate the data integrity and toauthenticate the data source. Since a MAC mechanism requiresa non-trivial distributed infrastructure to distribute the sharedkey, the cost of using this mechanism is higher than that ofimplementing MIC. For low security, source integrity is nota strong requirement for centralized architectures, BB and 3P,since the edge servers are in control of the same party. How-ever, for the highly distributed architectures, a mechanism forsource integrity is implemented (e.g. a reputation mechanismsfor P2P applications based on user reviews). For high securityall the architectures use a mechanism for source integrity suchas source digital signatures. In addition, highly distributedarchitectures, P2P and hybrid, use reputation mechanismsto strengthen the authentication of data sources. Finally, inorder to provide service integrity, all the architectures shouldguarantee the integrity of the software used for the contentdistribution service. We consider the cost of achieving softwareintegrity is the highest among the integrity sub-requirementsbecause it is highly customized and it is specific to eacharchitecture implementation. That is different from the rest ofmechanisms for integrity whose implementations are mostlybased on standards.

Figure 3b shows the cost to achieve integrity across thearchitectures for low and high requirements based on thenumbers from the last row of Table VI. Similar to the caseof providing confidentiality, we can see that the cost ofachieving integrity is higher for distributed infrastructuresfor both P2P and hybrid cases. However, inside each broadcategory, caching based or p2p based, the costs to achieveboth low and high integrity are estimated to be equal because

133133

(a) Confidentiality cost. (b) Integrity cost. (c) Availability cost.

Fig. 3: The cost of achieving confidentiality, integrity an availability for each architecture for low and high security requirements.

the differentiating factor between them does not include anintegrity benefit when switching from BB to 3P, or from P2Pto hybrid.

C. Availability Cost

Table VII lists the cost of mechanisms used to achieve lowand high availability for all the architectures. Since availabilityis a strong business requirement, and the system should beavailable at all times, we argue that there is no differencebetween low and high security. However, across architecturesthere are significant differences in the ability to provideavailability. As such, in the case of the BB architecture theCDN has more control of deploying mechanisms to preventand cope with DDoS attacks. In this case, a significant costof over-provisioning and residual risk can be cut from thedesign compared to similar 3P architecture. For P2P dis-tributed systems, even though some advantages are inheritedfrom the underlying highly distributed architecture, the weakpoints remain the authentication and monitoring componentsavailability.

Availability BB 3P P2P HyMechanisms L H L H L H L HPatching 2 2 2 2 2 2 2 2Antivirus 4 4 4 4IPS/IDS/Firewall 3 3 3 3 3 3Scrubbers 3 3Rate Limiting 1 1 1 1Overprovisioning 2 2 5 5 5 5 5 5Residual Risk 3 3 3 3 3 3AVAILABILITY SCORE 10 10 13 13 15 15 18 18

TABLE VII: Security cost of availability mechanisms.

Figure 3c shows the availability cost difference betweenthe architectures. One can see that in cases when availabilityis a strong requirement (e.g. no down time accepted) thehighest cost to achieve it is required by the hybrid architecture.We don’t show in the figure cases when availability require-ment can be relaxed and no authentication and monitoringis required. In these scenarios, the P2P based systems mightbe able to provide the lowest cost to achieve availability atthe expense of lower integrity and confidentiality. However,because P2P based CDNs are not able to guarantee the QoS,such an architecture might not be an acceptable solution insome business models.

D. Theft of Service Protection Cost

In cases when content distribution is based on user subscrip-tion for a specific service plan, theft of service preventionbecomes important. Table VIII list the estimated cost formajor DRM mechanisms. In most cases, for low securityrequirements (e.g. distribution of open source software, etc)there is not a significant cost associated with DRM. However,in cases when security requirements are high the cost tomeet DRM requirements is estimated to be roughly the sameamong the four architectures. This is the case because themechanisms are strictly related to the content itself rather thanbeing influenced by the architecture. Hence, once the contenthas reached the end user, the rights on the content should beprotected regardless of the architecture used for distribution.

TS Protection BB 3P P2P HyMechanisms L H L H L H L HRestricted coding 2 2 2 2Watermarking 2 2 2 2TS PREVENTION SCORE 0 4 0 4 0 4 0 4

TABLE VIII: Security cost of TS protection mechanisms.

E. CDN Security Cost

Figure 4 shows the overall cost to achieve low and highsecurity for the four architectures we investigated. We can seethat for both high and low security requirements, the backboneowned CDN has the lowest security cost and the hybridarchitecture the highest security cost. The second lowestsecurity cost is achieved by the third party owned backbonearchitecture and the third lowest by the P2P architecture.Therefore, based on our reasoning presented in this paper, wecan state that the more content is pushed to the end-pointsthe higher the cost for security guarantees. However, for somecases not covered in this paper, when low security is acceptable(e.g. free file sharing) the cost benefit of using a distributedarchitecture, such as peer-to-peer or hybrid, might provide alower cost for content distribution over time, but with lowsecurity guarantees.

V. RELATED WORK

There is a significant body of research done in the areaof content distribution networks in the last decade. Most

134134

Fig. 4: Overall difficulty scores for each architecture.

of the previous work is looking at methods to reduce end-user perceived latency, to increase CDN reliability, to provideefficient load balancing or to enhance the performance ofCDNs in general. However, to the best of our knowledge, noneof the previous work is concerned with assessing the cost ofsecurity for a CDN service.

In [14] and [13], the authors quantify the benefit of using thehybrid architecture for distributing content but do not considerthe security implications of pushing more content control at theuser endpoints. Even though the P2P architectures are highlydistributed, most of the existing systems have a centralizedcomponent that makes them vulnerable to denial of serviceattacks that will increase the cost to achieve high security.Authors in [15] perform an impressive work to reverse engi-neer Skype [16] protocol, and show the existence of a centralcomponent in the system, that is the login server. We quantifiedthis aspect when we evaluated the cost for architectures thathave a P2P component.

Attacks described in [6] exploit the vulnerability of threewell known CDNs and show how an attacker can use theCDN servers to amplify an attack against a customer web site.Therefore, even well established industry CDN providers canbe vulnerable to simple attacks, if not enough considerationis given to basic security requirements. In our work weconsider CDN software security (exploited in this case) asa strong requirement and argue that it can be achieved withconsiderable cost.

Finally, in [3] authors present their experiences with an aca-demic CDN [17] deployed on PlanetLab nodes, the methodsused to achieve high reliability and the mechanisms used tosolve some of the security problems they encountered. Theirsecurity measures consist of classification, rate limiting andprivilege separation. We believe these security mechanismscapture the requirements for the particular open proxy CDNinstance to some extent, and are a subset of the mechanismswe discussed in this paper. Moreover, when security require-ments are high, more security mechanisms are needed and wecovered them in our research.

VI. CONCLUSION

In this paper we proposed a framework to assess the costof providing security to the content distribution service bytaking into account four major CDN architectures from twobroad categories: caching edge-server based and peer-to-peerbased. We showed that, to achieve high security, the backboneowned CDN has the lowest security cost. Owning the transport

network backbone has a major impact in reducing cost and inthe ability to deploy specific infrastructure to achieve highsecurity.

Even though more detailed mechanisms can lead to adifferent difficulty score, we believe our methodology is robustand provides useful guidelines for designing a more secureCDN infrastructure, and to assess the security cost of CDNservice. To the best of our knowledge, our study is the firsteffort to compare different CDN architectures from the costof security perspective. In future work we seek to analyzethe overall cost tradeoff to provide service with differentlevels of security based on real measurements. Since hybridarchitecture pushes bandwidth cost into the peers, thus savingthe distribution cost, and at the same time has highest securitycost, it will be interesting to see what will be the overall CDNservice cost and what is the real cost tradeoff.

ACKNOWLEDGMENT

We would like to thank Cristina Serban and Ramesh Sub-baraman for their suggestions and helpful discussions, and allthe anonymous reviewers for their valuable comments.

REFERENCES

[1] “Content Delivery Network,” Akamai Inc., 2011,http://www.akamai.com.

[2] “Content Delivery Network,” Limelight Networks, 2011,http://www.limelightnetworks.com.

[3] L. Wang, K. S. Park, R. Pang, V. Pai, and L. Peterson, “Reliability andsecurity in the CoDeeN content distribution network,” in Proceedingsof the annual conference on USENIX Annual Technical Conference, ser.ATEC ’04, 2004.

[4] M. J. Freedman, “Experiences with CoralCDN: a five-year operationalview,” in Proceedings of the 7th USENIX conference on networkedsystems design and implementation, ser. NSDI’10, 2010.

[5] “Peer-to-peer television,” Joost, 2011, http://www.joost.com.[6] S. Triukose, Z. Al-Qudah, and M. Rabinovich, “Content delivery net-

works: protection or threat?” in Proceedings of the 14th Europeanconference on research in computer security, ser. ESORICS’09, 2009.

[7] W. Stallings, Network Security Essentials: Applications and Standards(3rd Edition). Upper Saddle River, NJ, USA: Prentice-Hall, Inc., 2006.

[8] P. Ferguson and D. Senie, “Network Ingress Filtering: Defeating Denialof Service Attacks which employ IP source address spoofing,” UnitedStates, 2000.

[9] S. Savage, D. Wetherall, A. Karlin, and T. Anderson, “Practical net-work support for IP traceback,” in Proceedings of the conference onApplications, Technologies, Architectures, and Protocols for ComputerCommunication, ser. SIGCOMM ’00, 2000.

[10] “Intelligent Content Distribution Service,” AT&T Inc., 2011,www.business.att.com/content/productbrochures/icds.pdf.

[11] “Amazon CloudFront,” Amazon Inc., 2011,http://aws.amazon.com/cloudfront/.

[12] “Bittorent,” BitTorrent Inc., 2011, http://www.bittorent.com.[13] H. Yin, X. Liu, T. Zhan, V. Sekar, F. Qiu, C. Lin, H. Zhang, and B. Li,

“Design and deployment of a hybrid CDN-P2P system for live videostreaming: experiences with LiveSky,” in Proceedings of the seventeenACM international conference on Multimedia, ser. MM ’09, 2009.

[14] C. Huang, A. Wang, J. Li, and K. W. Ross, “Understanding hybridCDN-P2P: why Limelight needs its own Red Swoosh,” in Proceedingsof the 18th International Workshop on Network and Operating SystemsSupport for Digital Audio and Video, ser. NOSSDAV ’08, 2008.

[15] S. Baset and H. Schulzrinne, “An analysis of the skype peer-to-peerinternet telephony protocol,” in Proceedings of the 25th IEEE Interna-tional Conference on Computer Communications, ser. INFOCOM 2006,2006.

[16] “Skype,” Skype Limited, 2011, http://www.skype.com.[17] “CoDeeN - A CDN on Planetlab,” Princeton University, Network

Systems Group, 2011, http://www.codeen.cs.princeton.edu.

135135