Forwarding-Loop Attacks in Content Delivery
Networks
Jianjun Chen∗†‡ , Jian Jiang§ , Xiaofeng Zheng∗†‡ , Haixin Duan†‡¶ ,Jinjin Liang∗†‡ , Kang Lik , Tao Wan∗∗ , Vern Paxson§¶ ,∗ Department of Computer Science and Technology, Tsinghua University† Institute for Network Science and Cyberspace, Tsinghua University‡ Tsinghua National Laboratory for Information Science and Technology{chenjj13, zhengxf12, liangjj09}@mails.tsinghua.edu.cn, duanhx@tsinghua.edu.cn§ University of California, Berkeley jiangjian@berkeley.edu¶ International Computer Science Institute vern@icir.org
k Department of Computer Science, University of Georgia kangli@cs.uga.edu∗∗ Huawei Canada tao.wan@huawei.com
Abstract—We describe how malicious customers can attack
the availability of Content Delivery Networks (CDNs) by creating
forwarding loops inside one CDN or across multiple CDNs. Suchforwarding loops cause one request to be processed repeatedly oreven indefinitely, resulting in undesired resource consumption andpotential Denial-of-Service attacks. To evaluate the practicalityof such forwarding-loop attacks, we examined 16 popular CDN
providers and found all of them are vulnerable to some form ofsuch attacks. While some CDNs appear to be aware of this threat
and have adopted specific forwarding-loop detection mechanisms,
we discovered that they can all be bypassed with new attack techniques. Although conceptually simple, a comprehensive defense
requires collaboration among all CDNs. Given that hurdle, we
also discuss other mitigations that individual CDN can implement
immediately. At a higher level, our work underscores the hazards
that can arise when a networked system provides users with
control over forwarding, particularly in a context that lacks asingle point of administrative control.

I.

I NTRODUCTION

Content Delivery Networks (CDNs) are widely used in theInternet to improve the performance, scalability and securityof websites. A CDN enhances performance for its customers’
websites by redirecting web requests from browsers to geographically distributed CDN surrogate nodes. A surrogate
serves the content directly if cached, or forwards requests to theorigin site otherwise. To improve availability, surrogates absorb
distributed denial-of-service (DDoS) attacks by distributing theattack traffic across many data centers. Some CDN providers
also provide WAF (Web Application Firewall) services tonormalize traffic and filter intrusions to their customer’s web
sites.

In this work we present “forwarding-loop” attacks, whichallow malicious CDN customers to attack CDN availability
by creating looping requests within a single CDN or acrossmultiple CDNs. Forwarding-loop attacks allow attackers tomassively consume CDN resources by building up a large
number of requests (or responses) circling between CDN
nodes. The impact can become more severe in the (common)case where attackers can manipulate DNS records to dynamically control a loop’s IP-level routing on a fine-grained basis.
Although many CDN providers have internal mechanisms(such as appending custom HTTP headers like CloudFlare’s
CF-Connecting-IP [19]) to detect repeated requests when
they circle back, we find that an attacker can bypass suchdefense mechanisms by using features offered by someother CDNs to filter HTTP headers. Our experiments with16 commercial CDNs show that all of them are vulnerable
to forwarding-loop attacks, even with their existing defense
mechanisms.
We also examine the threat of stealthy forwarding-loop
attacks. In the Dam Flooding Attack, an attacker secretly
and gradually accumulates a large number of pending CDN
requests over a lengthy period (hours). They then trigger a hugevolume of cascading traffic by suddenly providing bandwidthconsuming responses and controlling all responses to arrive
simultaneously. Worse, we find that internal CDN features—such as automatic server probing (Azure China), forwarding
retries (Akamai and CloudFront), and proactive decompressionof gzip’d responses (Akamai, Baidu and CloudFlare)—canamplify the DoS effect of forwarding-loop attacks and further
exacerbate the load on the CDN.
Overall, we make the following contributions:

Permission to freely reproduce all or part of this paper for noncommercial
purposes is granted provided that copies bear this notice and the full citationon the first page. Reproduction for commercial purposes is strictly prohibitedwithout the prior written consent of the Internet Society, the first-named author(for reproduction of an entire paper only), and the author’s employer if thepaper was prepared within the scope of employment.
NDSS ’16, 21-24 February 2016, San Diego, CA, USA
Copyright 2016 Internet Society, ISBN 1-891562-41-X
http://dx.doi.org/10.14722/ndss.2016.23442

1)

We describe forwarding-loop attacks that broadly
threaten CDN providers. Our study shows that theamplification attacks are severe and can consume
a huge volume of resources in commercial CDNs
at low cost. The attacks can potentially undermine
the security provided by CDNs, which are usuallyconsidered robust against DoS attacks.

2)

3)
4)

We performed controlled tests on 16 popular CDN
providers to verify the practicality of such attacks.
Although some CDN providers implemented defense
mechanisms for mitigating forwarding loops, weshow that those defenses can be bypassed.
We present the Dam Flooding attack, a highly damaging type of forwarding-loop attack.
We propose four approaches to preventing or mitigating forwarding-loop attacks, and discuss theiradvantages and limitations.

Forwarding
Server IP

HTTP GET/POST
http://example.com

BrowserFig. 1.

HTTP GET/POST
http://example.com

CDN Node

Web Site(example.com)

Normal CDN forwarding behavior.

a CDN’s performance. The higher the ratio, the more requests
that the CDN answers out of its cache, significantly reducing
response latency and as well as the load imposed on the origin
website. However, a user can force requests to come from theorigin website instead of the CDN’s cache. First, adding a
no-cache request header will make the CDN re-validate theresponse from the origin server [6]. Second, POST requests
usually will write through to the origin server [7], [16]. In
addition, most CDNs provide ways for customers to configure
the CDN to not cache certain URLs.

We organize the rest of this paper as follows. Section II
describes CDN operation, especially forwarding and filtering
techniques. In Section III we present various forwardingloop attacks and analyze the factors affecting them. We also
described our experiments to construct loops within and across
CDNs, and the “Dam Flooding” attack leveraging streaming
HTTP responses. We discuss possible defenses to prevent or
mitigate forwarding-loop attacks in Section IV and related
research regarding forwarding loops and CDN security in
Section V. We conclude in Section VI.
II.

Requestexample.com

Typical commercial CDNs usually have massive bandwidthand computational resources distributed around the Internet,
making them much more resilient to DDoS attacks than mostof websites. DDoS traffic targeting a CDN-protected website
will be directed to CDN servers distributed across data centerswith ample bandwidth, and then absorbed or blocked before
arriving the original website. Indeed, capacity for mitigating
DDoS attacks has become a “selling point” for today’s commercial CDNs.

BACKGROUND

CDNs are distributed systems with large numbers of servers
deployed across the Internet. Initially created to improve
website performance and scalability, many CDNs also provide
security features such as DDoS protection and Web Application Firewalls (WAFs) for websites. CDNs have evolved
to become important Internet infrastructure. For example, theleading CDN provider Akamai claims that it alone delivers
15–30% of all Web traffic [1].

Many CDNs also provide an additional security service
called content filtering, or WAF. A WAF applies a set ofrules to each HTTP request and response. Generally, theserules cover common attacks such as cross-site scripting (XSS)and SQL injection. By customizing WAF rules, customers canhave their CDNs examine HTTP requests and filter out some
suspicious traffic before it reaches the origin website.

Web access involving a CDN includes two steps: first,
a user’s request is directed to a CDN server geographicallyclose to the user; second, the CDN server obtains the content
for the responding to the request. The first step is called
request routing [2]. Commonly used request-routing techniques
include URL rewriting and DNS-based request routing [2].
URL rewriting requires website owners to change website
URLs to use CDN-assigned subdomains that resolve to CDN
servers. DNS-based request routing instead works by changing the DNS resolution of website domains, either directly
mapping to CDN server IP addresses, or using CNAMEs tochain to CDN subdomains. These request-routing techniques
usually determine the selection of edge (entry) server, butusers can also override a CDN’s selection by directly connecting to a desired edge server using its IP address rather
than hostname [22]. Users can obtain CDN IP addresses
by resolving CDN subdomains via public platforms such as
PlanetLab [20]. We verified that this technique for overriding
a CDN’s selection works for all CDNs in our study.

III.

F ORWARDING -L OOP ATTACKSMalicious customers of CDNs can deliberately manipulate
the forwarding process (in the pull mode) to create forwarding
loops inside CDNs. Forwarding loops can cause CDNs toprocess one client request repetitively or even indefinitely. The
consequent amplification effect allows malicious customers tolaunch, with little resources and cost, resource-consuming DoS
attacks against CDNs.
In general, as shown in Figure 1, before a CDN node
forwards an HTTP request from a client, it checks the Hostheader of the request to look up any customer-specified forwarding destination. The node then connects to the forwarding
destination and relays the request. In the benign case, theforwarding destination returns a response that is further relayedby the CDN node to the client. However, if an attacker
intentionally configures the forwarding destination to point toanother CDN node, the forwarding process can continue, andmight eventually form a loop. Figure 2 illustrates a conceptual
view of a forwarding loop between three CDN nodes. Notethat the three nodes could be distributed either within a single
CDN or across different CDNs.

The second step, i.e., how the CDN server obtains therequested content, also has two different modes: push and pull.
In the push mode, website owners upload their content to the
CDN’s servers in advance. In the pull mode, the CDN server
works as a reverse proxy with caching. It firstly tries to respondfrom the local cache. In the case of a cache miss, it forwards
the request to the original website to retrieve the content. Most
CDNs support both modes. The vulnerability we examine inthis paper only occurs when using pull mode. In pull mode, thecache hit ratio becomes an important indicator for measuring

We have identified four approaches to create forwarding
loops: 1) self loop, which loops within a single CDN node;2Request

Forwarding

example.com

B

HTTP GET/POST
http://example.com

CDN NodeA

Browser

without strong customer identity verification (except Alibaba
and Tencent, per Section III-G). We then measured various
aspects of the CDNs using our testing accounts. This approachenables us to measure 16 popular CDNs around the world. We
found all of them vulnerable to some form of forwarding-loop
attacks. Table I presents the 16 CDNs and their vulnerability to
the four types of attack. While most CDNs can defend against
the first attack, little more than half can defend against thesecond, and none can defeat the last two.

Web Site(example.com)

HTTP GET/POST
http://example.com

HTTP GET/POST
http://example.com

We chose to measure the 16 CDNs that provide free or
free-trial accounts without strong identify verification to emphasize the fact that forwarding-loop attacks can be launchedanonymously and with little cost. Rigorous customer authentication can help raise the bar, but it does not suffice toprevent forwarding-loop attacks. We further discuss the issueof anonymity and cost in Section III-G.

CDN NodeB

CDN NodeC

HTTP GET/POST
http://example.com

RequestForwarding

RequestForwarding

example.com

A

example.com

C

As we will present in detail, the root cause of forwardingloop attacks is that CDN customers have flexible control
over their forwarding configuration, and CDNs lack sufficientdefensive mechanisms to ensure that these configurations—especially across multiple customers or multiple CDNs—will
not cause requests to be processed repeatedly. The fact that
CDN customers can override edge-server selection of CDNs
(as explained in Section II) further enables forwarding-loops
attacks on any CDN public IP address or data center thatan attacker seeks to target. Moreover, we identified a numberof factors that affect the efficacy of forwarding-loop attacks.
In the following sections, we first discuss how these factors
interact with forwarding-loop attacks and vary across CDN
implementations. We then present detailed mechanisms forthe four attacks, along with measurements and experiments
to assess them.

Fig. 2. A conceptual view of a CDN forwarding loop created by manipulating
forwarding configuration: see Section III-B through Section III-E for thedetailed mechanisms for constructing forwarding loops.
TABLE I.

V ULNERABILITY OF THE MEASURED CDN S TO FOUR TYPESOF FORWARDING - LOOP ATTACKS . (“Likely” refers to inference from indirect
evidence.)

Self-Loop

Intra-CDN Inter-CDN
loop

loop

Dam Flooding

Akamai3

3

Alibaba

3

3

3

3

3

3

Azure (China)

3

3

Baidu
CDN77

3

3

3

CDNlion

3

3

3

A. Factors affecting Forwarding Loops

CDN.net333

CDNsun3

3

3

CloudFlare

3

3

CloudFront

3

3

Fastly33Modification of the Host header. The Host header of arequest plays a key role in the forwarding process, as well as inforwarding-loop creation. A necessary condition for a request
to create a forwarding loop is that all involved CDN nodes
must forward the request in such a way that the successor nodetreats it as a benign request, and continues the forwarding.

Incapsula

3

3

3

3

3

3

3

3

3

3

KeyCDN

Likely3

Level3MaxCDN

Likely3

Tencent

Whether the successor node accepts the forwarded request
depends on the Host header. We can classify forwarding loops
into two categories based on whether the Host header changes
during the forwarding loop. Figure 2 shows the first category:a request is issued for the original domain of the website, andwhen forwarded by a CDN node, its Host header does notchange, thus not affecting acceptance and further forwardingof the forwarded request.
Another type of forwarding loop has a changing Hostheader. Our measurements show that CDN nodes can change
the Host header to reflect the forwarding destination, depending on the request-routing mechanism and the form of theforwarding destination. Table II presents detailed results. We
note that forwarding loops are feasible as long as all involved
nodes keep a valid domain name in the Host header, but canbe prevented by simply modifying the Host header to an IP
address, because we find that no CDN accepts requests with an
IP address in the Host header. As shown in Table II, this caseonly occurs at KeyCDN and MaxCDN when the request is2) intra-CDN loop, which loops around multiple nodes of one
CDN provider; 3) inter-CDN loop, which loops across multiple
CDNs; and 4) CDN Dam Flooding, which couples forwardingloop attacks with timely controlled HTTP responses to significantly increase damage.
We gathered a list of popular CDNs1 and signed up withthose (or their resellers) that provide free or free-trial accounts
1 Most from http://www.cdnplanet.com/cdns/.

3

TABLE II.

H OST MODIFICATION BEHAVIORS . (“N/A” indicates that the feature is either not available for testing due to our account’s limitations, or not
applicable.)

Request with CDN Subdomain
Forwarding to IP

Request with Customer Domain

Forwarding to Domain

Forwarding to IP

Forwarding to Domain

Akamai

N/A

Configurable

Alibaba

Configurable

Configurable

Azure (China)

N/A

Request Domain

Baidu

N/A

Request Domain

CDN77

Request Domain

Forwarding Domain

Request Domain

Forwarding Domain

CDNlionRequest Domain

Forwarding Domain

Request Domain

Forwarding Domain

CDN.netRequest Domain

Forwarding Domain

Request Domain

Forwarding Domain

CDNsunRequest Domain

Forwarding Domain

Request Domain

Forwarding Domain

CloudFlare
CloudFront

N/A
N/A

FastlyN/A

Incapsula

N/A

KeyCDN

Forwarding IP

Level3MaxCDN
Tencent

Request Domain

Request Domain

N/A

Request Domain

Forwarding Domain

Request Domain

N/A

Request Domain

Forwarding Domain

N/A

Request Domain

N/A
Forwarding IP

Forwarding Domain

Forwarding Domain

Configurable

N/A

Request Domain
TABLE IV.

issued with the CDN’s subdomain and the form of forwarding
destination is IP address. In all other cases we could test, thefeasibility of forwarding loops is not affected.

H EADER SIZE LIMITATION ( SINGLE / ALL HEADERS ).

Modification of other header fields. CDNs also varyregarding changing other header fields when forwarding arequest. Such behaviors, summarized in Table III, affect theefficacy of forwarding loops.
We first find that 9 CDNs depend on standard or selfdefined headers to detect forwarding loops. We measured theseresults by connecting our origin server and, separately, eachcommercial CDN node in a loop. If requests in the loop always
stop in a short time unless we remove a certain header or set
the value of certain header on our origin server, then we deducethat the CDN uses the header for loop detection. We find that
Akamai and Tencent add Akamai-Origin-Hop and X-DaaTunnel headers with integer values that count forwarded hops.
These appear to restrict forwarding to maximum values of 12
and 6, respectively. Alibaba, CloudFront and Level3 append
standard Via headers with the server’s hostname. They also
check for the presence of certain strings within any existing
Via header to detect loops. Fastly also appends a self-definedheader Fastly-FF with its hostname, and rejects a request if
its hostname already appears in the header value. Incapsula
adds a new header, Incapsula-Proxy-ID, with the ID set toits internal identifier, basing loop detection on the presenceof this header. Baidu and CloudFlare servers append their IP
addresses to the X-Forwarded-For header, and also add theself-defined header CF-Connecting-IP (Baidu confirmed thatthey have a partnership with CloudFlare, which CloudFlarelater announced). Baidu and CloudFlare servers reject a request
if its IP address already appears in the X-Forwarded-For

VendorLimitation

VendorLimitation

Akamai

16KB/16KB

CloudFlare

32KB/92KB

Alibaba

32KB/64KB

CloudFront

24KB/24KB

Azure (China)

20KB/20KB

Fastly64KB/64KB

Baidu

32KB/92KB

Incapsula

25KB/>1600KB

CDN77

16KB/64KBKeyCDN

8KB/32KB

CDNlion

16KB/64KB

Level3

9KB/12KB

CDN.net

16KB/64KBMaxCDN

32KB/156KB

CDNsun16KB/64KB

Tencent

6KB/6KB

header, or given the presence of a CF-Connecting-IP header.
We also find that all CDNs except KeyCDN, MaxCDN,
and Tencent increase the header size whenever forwarding arequest, usually by adding or appending header fields like Via
or X-Forwarded-For, although not necessarily using thesefields for loop detection. This behavior causes forwarding
loops to eventually stop, because all CDNs implement bounds
on the header size of acceptable requests. If in each round of aforwarding loop, the header size of the request increases, thenthe loop will break when the header size exceeds the boundat any node. Table IV summarizes the header size limitationsof different CDNs.
Several CDNs reset the value of certain header fields
instead of appending on them. CDN77, CDN.net, CDNlion
and CDNSun reset the Via header, and KeyCDN resets the X4

TABLE III.

H EADER ( EXCEPT H OST ) MODIFICATION BEHAVIORS

Size Increase

Loop Detection

Reset

AkamaiVia, X-Forwarded-For

Akamai-Origin-Hop

AlibabaVia, X-Forwarded-For

Via

Azure (China)

X-Forwarded-For

Baidu

X-Forwarded-For

CDN77

X-Forwarded-For

Via

CDNlionX-Forwarded-For

Via

CDN.netX-Forwarded-For

Via

CDNsunX-Forwarded-For

Via

X-Forwarded-For, CF-Connecting-IP

CloudFlare

X-Forwarded-For

X-Forwarded-For, CF-Connecting-IP

CloudFront

Via, X-Forwarded-For

Via

FastlyFastly-FF, X-Varnish

Fastly-FF

Incap-Proxy-ID, X-Forwarded-For

Incap-Proxy-ID

Incapsula

FilteringNon-self-defined
X-Forwarded-For

KeyCDNVia, X-Forwarded-For

Level3Via

MaxCDNAny header
X-Daa-Tunnel

Tencent

TABLE V.

Abort Forwarding
Timeout occurs at AA

F ORWARDING TIMEOUTS AND THE ADOPTION OF ABORTFORWARDING .

A

Forwarding

Connection-close event
propagates to C and then B
BC

Timeout (second)C

AkamaiLoop TerminatedAlibaba60

3

Azure (China)

900

3

Baidu

100

3

CDN77

60

CDNlion60

CDN.net60

B

Loop Formed

No Abort Forwarding
Timeout occurs at AAA

C keeps the forwarding
connection to B
B

C
Loop Formed

Fig. 3.

Abort Forwarding

B

C

Loop Continued

The differences between abort forwarding and no abort forwarding.

CDNsun60

CloudFlare100

3

CloudFront

90

3

FastlyForwarded-For header to its own IP address. As we shall see,these behaviors cause undesirable interactions that increase theefficacy of forwarding-loop attacks.
Fastly and MaxCDN support WAFs that allow customerdefined rules to remove HTTP headers in requests [5] [14].
According to our measurements, Fastly prevents removal of
the headers added by its own servers, while MaxCDN does
not appear to impose any such limitation.

240

configurable (max 75)

Incapsula

360

3

KeyCDN60

3Level360

MaxCDN

60

3

Tencent

10

3

When a timeout occurs at a node in a forwarding loop,
the node closes the corresponding connection to its successor.
This closing action triggers a client-side connection close
event at its successor node. If the successor node reacts by
abort forwarding, i.e., closing the corresponding forwarding

Handling timeouts. After forwarding a request to its
destination, a CDN node waits for a response until a timeout
occurs. Table V shows the timeout periods we measured,ranging from 60 seconds to 900 seconds.
5

TABLE VI.

DNS RESOLUTION BEHAVIORS .

TABLE VII.

DNS Cache (resolver) Minimum TTL (second)

S UPPORT OF HTTP STREAMING .

Request Streaming

Response Streaming

Akamaiper CDN node

≈ 60

Akamai3

3

Alibabaper data center≈ 60

Alibaba3

3

Azure (China)

per CDN node≈0

Azure (China)

3

3

Baidu

per CDN node

≈ 60

Baidu

3

CDN77

Google Public DNS

≈0

CDN77

3

CDNlionGoogle Public DNS≈0

CDNlion3

CDN.netGoogle Public DNS≈0

CDN.net3

CDNsunGoogle Public DNS≈0

CDNsun3

CloudFlareper data center≈0

CloudFlare

3

CloudFront

per data center≈0

CloudFront

3

3

Fastlyper CDN node≈0

Fastly33Incapsula

N/A

N/A

Incapsula

3

3

KeyCDN

Google Public DNS≈0KeyCDN

Level3

per CDN node≈5

Level3MaxCDN

per CDN node≈0

MaxCDN

3

Tencent

per data center≈0

Tencent3

connection, the close event will further propagate to the next
node, and so forth. In a forwarding loop, abort forwarding
propagates faster than request forwarding, because a clientside connection close event occurs immediately after receivinga single FIN packet, while receiving and forwarding a request
requires many more packets. If all CDN nodes involved ina forwarding loop adopt abort forwarding, then the reaction
triggered by the timeout will eventually catch up with therequest forwarding to stop the loop. In this way, the lifecycle of the forwarding loop is bounded by the minimum
timeout of the nodes plus the time for the abort event tocatch up to the forwarding. However, if one node does not
implement abort forwarding, the abort propagation will stopat that node; consequently, the request continues to circulate
among all nodes in the loop.

333

and MaxCDN) deploy independent DNS resolvers on eachnode. Alibaba, CloudFlare, CloudFront and Tencent have one
or more DNS resolvers shared per data center. The others use
Google Public DNS, which deploys different instances acrossgeographical locations using anycast. Among the 15 CDNs we
could measure, Akamai, Alibaba, and Baidu’s DNS resolvers
set a minimum TTL of 60 seconds; Level3’s resolver can set aminimum TTL of 5 sec; the other CDNs appear to respect TTL
values in DNS responses even when set to zero (no caching).
This latter behavior allows an attacker to dynamically reroutean ongoing loop in a fine-grained and timely manner.
We note that self-loops, intra-CDN loops, and inter-CDN
loops do not require dynamic rerouting via DNS, but its availability provides additional flexibility for attackers to create andcontrol forwarding loops. For dam-flooding attacks, this featureis required in the flooding phase to change the forwarding
destination (Per Section III-E).

Figure 3 illustrates how a timeout event is propagated tostop a forwarding loop if all nodes in the loop implement abort
forwarding; and, in comparison, how a timeout event is locallylimited if not all nodes support abort forwarding.

Non-streaming versus streaming. Attackers expect thatforwarding loops should not only last indefinitely, but also
propagate data as quickly as possible in order to consume
maximal resources. One important factor related to the speed ofa forwarding loop is whether a CDN supports HTTP streaming. HTTP streaming is a feature of HTTP 1.1 enabled byannouncing a Transfer-Encoding: chunked header instead of
the Content-Length header. It provides a persistent connection
to transmit dynamically generated content on demand without
knowing the content length in advance. For forwarding loops,
a streaming-compatible CDN node will start relaying a requestor response to its next hop immediately after receiving its
initial chunk, rather than waiting for the complete content.
This makes the loop circulate faster. In order to initiate aforwarding loop with HTTP streaming, all involved nodes must
support this feature. Our measurements show that while 9 outof the 16 CDNs do not accept HTTP streaming in requests,

As shown in Table V, numerous CDNs do not adopt abort
forwarding when a client-side connection closes.
DNS resolution behaviors. Per Table II, 15 out of 16 measured CDNs (except Incapsula) support using domain names
as forwarding destinations. For these CDNs, an attacker canchange the DNS records of the forwarding domains to control
an ongoing forwarding loop dynamically, e.g., switching theloop from one set of IP addresses to another set of IP addresses.
Our measurements show that, in general, CDNs do notshare DNS results (via common caches or resolvers) acrosstheir servers or data centers. They also respect the time-tolive (TTL) value in DNS responses. Per Table VI, of the
15 CDNs supporting the use of domain names as forwarding
destinations, 6 (Akamai, Azure China, Baidu, Fastly, Level3
6

all support streaming responses (Table VII).

A

Figure 4 presents how non-streaming and streaming loops
generate different traffic patterns. We presume the path between two nodes A and B is symmetric with network latencyl, and the request (or response) circling around A and B
requires time t to fully transmit. Assuming the data is always
transmitted at full bandwidth, both the non-streaming and thestreaming loops generate square waves along (each directionof) the path between A and B, with the same pulse height
representing the full bandwidth, and the same pulse widthreflecting t. Yet, the periods of the two waves (i.e., the roundtrip times of the two loops) are different. While the squarewave generated by the non-streaming loop has a period of
2 × (t + l), the square wave caused by the streaming loop hasa period of 2 × l.

B

A

A

t

t

l

l

As the streaming loop runs faster, it keeps the path busier(in both directions). If the data is large enough so that t ≥ 2×l,then the neighboring traffic pulses caused by the streaming
loop overlap, which means that the path is fully occupied.
In practice, overlaps of two or more rounds of a streaming
loop could also result in higher traffic peaks than that of anon-streaming loop, because the data transmission between
two successive nodes might not be able to utilize all available
bandwidth due to factors such as TCP’s congestion control.

The difference between non-streaming and streaming loops.

KBytes

450
400
350
300
250
200
150
100
50
00

We conducted a local experiment to verify our analysis. We
set up two Nginx 1.8.0 servers, both connected to the same
Ethernet. To simulate an Internet environment, we used thetc Traffic Control tool to add 125 ms of network latency foreach server. In this setting, the full bandwidth is 100Mb/s andthe network latency is 250ms. We first sent a single 500KB
POST request to create a streaming loop between the twoservers by configuring their Nginx instances to disable request
body buffering. We then repeated the procedure with a nonstreaming loop setting.

A

Streaming Loop

Non-streaming Loop

Fig. 4.

B

streaming
non-streaming

10

20

30
Seconds

40

50

60

Fig. 5. Traffic generated by a single request (500KB) in a non-streaming
versus a streaming loop.

of loopback and internal IP addresses at the web interface does
not suffice to defend against self-loops. For CDNs supporting
domain names as forwarding destination, the attacker can use
this feature to bypass blacklists implemented at the web interface. For example, CloudFlare allows specifying a CNAME
domain for the forwarding destination, enabling an attacker
to later change the resolution to the loopback address or a
CloudFlare IP address.

Figure 5 shows the traffic in one direction generated via
non-streaming and streaming loops. As expected, the nonstreaming loop generates a periodic wave; each distinct pulse
represents one round of the loop; the peaks near 179KB/s.
In comparison, multiple rounds of the streaming loop overlap
because the time needed to transmit the request is much higher
than the network latency (with the effect of TCP slow start),
resulting in a curve without distinct pulses and much higher
peaks (about 443KB/s).

We also tested three popular open-source reverse proxies
that are commonly used by commercial CDNs: Squid, Nginx,
and Varnish. Both Nginx and Varnish by default allow selfloops, and we also could not find any option or popularextension for loop-prevention. Squid prevents loops by addinga Via header to forwarded requests and rejecting incoming
requests that contain the same hostname in its Via header.
This defense is similar with those of the 9 loop-aware CDNs
presented in Table III.

B. Self-Loop
Self-loops occur when requests are forwarded circularly
within a single CDN node. The attack is simple to mount:
the attacker only needs to specify the forwarding destinationof their domain as the loopback address (i.e., 127.0.0.1), or
the IP address of a given CDN node. Yet self-loops can beparticularly damaging, because the circulation happens without
network latency, potentially consuming resources very quickly.

Testing the feasibility of self-loop attacks on commercial
CDNs requires care to avoid potentially inducing considerable
damage. The 9 loop-aware CDNs are not vulnerable to this
attack, while the other 7 CDNs are likely vulnerable. Amongthe 7 CDNs, 5 (Azure China, CDN77, CDNlion, CDN.net,
CDNsun) have size-increasing headers, per Table IV. For these
CDNs, we found a technique to infer some further information.

We found that 13 out of 16 CDNs’ web interfaces accept
the loopback address or the IP address of their nodes as
forwarding destinations. Baidu and CloudFlare however do notallow such forwarding destinations. CloudFront further rejects
specifying forwarding destinations using any raw IP address or“localhost”. It is worth noting that merely enforcing a blacklist

We first send a request to one CDN node with a size
exceeding its maximum value, and record the corresponding
response (e.g., 400 Bad Request—Request Header Or
7

Cookie Too Large). Next, we send another self-loop request
to the same node but slightly smaller (200 bytes less) than
the size limit. Doing so ensures that if the CDN is vulnerable
to self-loops, the crafted request can at most only loop a few
times before reaching the header size limitation. If for bothrequests we observe the same response indicating an excessive
request size, we can infer that the CDN is vulnerable to selfloop attacks. Otherwise, we conclude that the CDN prohibits
request forwarding to the loopback or self address. Using thistechnique to test the 5 CDNs, we find only Azure (China) isvulnerable to self-loop attacks.

an attacker’s forwarding domain. Attackers can create loops
between two nodes A and B of the same CDN by controlling
the DNS resolution of their forwarding domains so that queries
from A are provided with the IP address B, and vice versa.
Depending on how a CDN manages its DNS resolutions, theattacker might need to select A and B from different data
centers or regions.
That said, we note that this attack does not affect the
9 CDNs that employ loop-detection headers.
Experiments. We conducted a proof-of-concept experiment on MaxCDN. We used two MaxCDN nodes plus one
VPS (Virtual Private Server) under our control, employing thesecond strategy described above to form a three-node loop.
The VPS acts as a transparent HTTP proxy to collect data
and minimize harm. We also added a 0.6 seconds delay at our
HTTP proxy to slow down the loop speed to ensure that theexperiment did not cause significant real-world damage. We
ran the experiment for 60 seconds and received 59 requests at
our VPS for only one request we sent out.

The remaining two CDNs (KeyCDN and MaxCDN) arestill likely vulnerable to self-loop attacks.
Experiments. We conducted two local experiments usinga Linux machine running an Nginx server to understand thepotential consequences of self-loops. We first tested with thedefault configuration of Nginx, finding that request-forwarding
to a loopback address circulated 511 times in ≈ 0.1 seconds
before returning the error response 400 Request Header Or
Cookie Too Large. By default Nginx limits the size of a single
header to not exceed 8KB. When forwarding a request, Nginx
appends its address in a X-Forwarded-For header, causing
the header size to increase. We then removed the header size
limitation and conducted the experiment again. This time theself-loop ran 28,231 times in 5 seconds, ultimately returninga 504 error because the loop had exhausted all of the source
ports available for loopback connections. (The Linux kernel’sdefault port range for a user-space application spans 32,768–
61,000.)D. Inter-CDN Loops
If attackers extend the multiple-node forwarding loop tospan multiple CDNs, they can evade the protection of loopdetection headers to attack all 16 CDNs. This approach works
by chaining loop-aware CDNs with other CDNs that disrupt
the loop-detection headers.
As presented in Section III-A and Table III, Fastly
and MaxCDN provide customer-defined header filtering. The
header filtering feature of Fastly does not facilitate evading
loop detection because Fastly adds a non-filterable loop detection header. However, including MaxCDN in a chain enables
disrupting all loop-detection headers because it provides unlimited header filtering. I.e., attackers only need to add one
MaxCDN node in their forwarding loops to attack even loopaware CDNs.

As presented in Table III and Table IV, Azure (China) isvulnerable to self-loop attacks and increases the header size
when forwarding a request; therefore, it is subject to the casedemonstrated in the first experiment. Self-loops on KeyCDN
and MaxCDN, which do not increase the header size perTable IV, likely behave like the second experiment; that is, they
could exhaust all source ports of localhost before a timeout
occurs (60 seconds, per Table V).

The behavior of resetting headers also enables evasionsof loop detection. As shown in Table III, CDN77, CDNlion,
CDN.net and CDNsun reset Via, a standard header used by
Alibaba, CloudFront and Level3 to detect forwarding loops.
Therefore, attackers can mount a forwarding loop between any
one node from the former 4 CDNs and nodes from the latter
3 CDNs.

C. Intra-CDN Loops
Attackers can also create forwarding loops across multiple
nodes within a single CDN. As mentioned above, 15 CDNs
(all except Incapsula) allow customers to use domain names
as forwarding destinations. When forwarding a request to adomain, 10 of the 15 CDNs (except Azure China, Baidu,
CloudFlare, Fastly and Tencent) change the Host header
to reflect the forwarding domain. For each of these CDNs,
attackers can create forwarding loops across multiple nodes by
chaining multiple attacking accounts using multiple forwarding
domains. For example, they can set up account A1 forwarding
domain D1 to domain D2 , account A2 forwarding domain D2
to domain D3 , and so forth. Account An closes the loop by
forwarding domain Dn to domain D1 . This creates a loop
across n domains, which can further be mapped to different
CDN nodes.

Another use of header filtering and header resetting is
to counter the effect of increasing header size so that thelife-cycle of a forwarding loop escapes the bound normally
imposed by header-size limitations. For example, we can form
a loop among one CloudFront node, one CDN77 node andone KeyCDN node. The CDN77 node resets the Via header
used by CloudFront for loop detection. The KeyCDN node
resets the X-Forwarded-For header, which appears to be theonly header whose size would otherwise steadily increase by
CloudFront and CDN77. KeyCDN itself does not detect loops,
nor does it increase header sizes. In addition, because CDN77
does not adopt abort forwarding, forwarding timeouts will notterminate the forwarding loop. In principle, such loops could
last indefinitely.

Attackers can also create loops across multiple CDN nodes
by dynamically changing forwarding destinations using DNS.
As shown in Table VI, for the 15 CDNs supporting domainnames for forwarding, none of these CDNs share a global DNS
cache. Thus, different CDN nodes will independently resolve

Experiments. We created a forwarding loop among 4 systems: CloudFlare, CDN77, MaxCDN and a server under our8Request

Forwarding

example.com

attacker.com

attacker.com
DNS Server

104

4

103

5

2
1

6
CDN NodeA

Attacker
ServerKBytesAttacker
Client

7

9
8.1

3.3

3.1

8.3

102
101
100

3.2
CDN NodeB

CDN NodeC

Traffic generated by all three requests
Traffic generated by the first two requests
Traffic generated by the first request

10-1 0

8.2
RequestForwarding

RequestForwarding

example.com

A

example.com

C

10

20

30
40
Seconds

50

60

70

Fig. 7. Traffic generated by three forwarding loops in a “dam flooding”
attack. The flooding event occurs at 50 seconds).

Fig. 6. The process of a CDN Dam Flooding Attack: 1) the attacker client
sends a request to A; 2) A queries attacker.com to forward the request,
and is directed to B; 3) the request circulates across B, C, and back toA; 4) the attacker points attacker.com to his server; 5) the next DNS
query for attacker.com from A is mapped to the attacker’s server; 6) A
forwards the request to the attacker’s server; 7) the attacker’s server replies
with a streaming response; 8) the streaming response flows through C and B,
then back to A, repeating many times; 9) A finally relays the response to theattacker client.

that initiated the loop. While the filling phase itself generates
some attacking traffic, the flooding phase bursts the traffic by
utilizing HTTP streaming with large and continuous chunks,
with the impact of each chunk magnified by the number ofturns it makes around the forwarding loop. The attacker canalso coordinate DNS resolution to flood all filled forwarding
loops simultaneously. The overlap of multiple streaming loops
serves to enlarge the traffic burst.

control. We configured MaxCDN to delete any header that
detects loops or increases header size. We use the CDN77
node’s no-abort-forwarding to counter the effect of forwarding
timeouts. Again, we used our server as a transparent HTTP
proxy with a delay of 0.6 seconds to collect data and limit
the resource load imposed by the loop. We initiated the loop
using a single request; it lasted more than 5 hours, passing
17,266 requests through our server. When the loop finallystopped, a 522 error was received, indicating that CloudFlare
could not connect to our server. Our server also received
many retransmitted TCP packets, from which we infer that theloop ceased because of network connectivity issues between
CloudFlare and our server.

We note that dynamically changing forwarding destinations
using DNS is not a necessary condition to create streaming
loops. For instance, in the example given in Section III-C,
instead of chaining the attacking account An back to A1 , theattacker can alter the entry for An to point to their server, sothat a request becomes forwarded to his server after n hops
between CDN nodes, with a streaming response then fed backalong the flow in reverse. That said, using DNS provides theattacker with more control on how and when to “flood” thefilled loops.
Experiments. To assess the efficacy of this attack inpractice without unduly stressing a production CDN, we set up
our own VPS as the victim CDN node, imposing a strict traffic
limitation of no more than 100Mb/s. On CDN77, we configure
the forwarding destination to a domain under our control. On
our VPS, we configure the forwarding destination to a CDN77
IP address. In this way, we create a forwarding loop between
our VPS and the CDN77 node. Note that our VPS has theabort-forwarding feature, does not support request streaming,but does support response streaming.

E. The CDN Dam Flooding Attack
As presented in Section III-A, HTTP streaming makes
forwarding-loop attacks more potent by enabling them to “fillthe pipe” with traffic. However, for the attacks discussed above,
Azure (China) is the only applicable target for streaming loops,
because it is the only CDN that both supports streaming
requests and does not deploy loop detection (per Table III
and Table VII). Since all CDNs we examined support HTTP
streaming for responses, we can extend the attacks by employing responses rather than requests to create streaming loops.

In the filling phase, we respond to DNS queries with the
IP address of our VPS and then send a single 366-byte request
to the CDN77 node 3 times spaced 10 seconds apart. Thus,
the attack uses a total of three small initial requests. We thenwait for the three requests to loop between the CDN77 nodeand our CDN node for 30 seconds.

We call this attack “CDN Dam Flooding” because it
involves two phases analogous to the filling and flooding ofa dam. Figure 6 shows how the attack works. In the fillingphase, the attacker launches a number of forwarding loops
via the strategies described in Section III-C or Section III-D,
using domain names as forwarding destinations. In the flooding
phase, the attacker changes the resolution of these names todirect the forwarding destinations to a server of the attacker’sthat replies to incoming requests with a large file transmittedusing HTTP streaming. For each forwarding loop, a streaming
response flows along the CDN nodes in reverse order, formultiple rounds, until reaching a broken connection caused
by a forwarding timeout at some CDN node, or the client

In the flooding phase, we change the DNS replies to direct
the three loops to our web server. Our server replies to any
request with a 1 MB file, sent using HTTP streaming.
Figure 7 shows the HTTP traffic on our VPS during thefilling and flooding phases. The burst attack lasts in total forabout 69 seconds. During the first phase, the three forwarding
loops slowly increase the traffic volume from zero to 7 KB/s
over 50 seconds. In the second phase, the traffic volume
immediately peaks, reaching about 9.2MB/s. While we as the9attacker sent out three requests and three responses totaling
about 3MB traffic, our VPS as a victim received about 224MB,
an amplification factor of 74.

200

Requests number

150

Combining with gzip bombs. This attack can be substantially enhanced if the attacker incorporates gzip bombs. In
step 7 of Figure 6, the attacker needs to send a large responseto the CDN as quickly as possible to increase the peak burstof the attack. gzip bombs, which are small compressed files
easy to transport across a network, can help a great deal toachieve this goal. When unpacked by a CDN, they balloon
into extremely large output.

100

50

00

20

40

60

80
Seconds

100

120

140

160

Fig. 8. Traffic generated by one request due to CloudFront’s retransmission.

A key factor of this attack is whether CDNs will decompress gzip’d responses. To assess this, we conducted ameasurement of the 16 commercial CDNs. First, our client senta request to the CDN indicating that it does not accept gzipencoded HTTP replies. Next, our original server returned agzip’d response. If the client receives decompressed content,
this means that the CDN will decompress gzip’d responses.
We found that 3 (Akamai, Baidu and CloudFlare) out of the
16 CDNs will decompress gzip’d responses for clients that
do not support “gzip” encoding.

results in an amplification factor of approximately 17,000—
1,000 times that of the first experiment.
F. Other CDN Quirks
We also observed two rare behaviors that can further
enhance the efficacy of forwarding-loop attacks.

Although only 3 CDNs can be exploited by gzip bombs,
we emphasize that adding one gzip-decompressing node intoa loop suffices to attack all involved nodes with the effect ofgzip bombs, even if the other nodes do not support gzip
decompression. For example, in the scenario of Figure 6, even
if the three nodes A, B, C do not support gzip decompression, the attacker can direct step 6 to a gzip-decompressing
node, which forwards the request to the attack server and is
fed a gzip bomb in return. The gzip-decompressing node
then forwards the large unpacked response to node A, where
it further loops among the three nodes.

Aggressive active probing. We found that Azure (China)
proactively and frequently issues HTTP requests to forwarding
destinations, presumably for availability testing. We configured
a forwarding destination on Azure (China) and monitored
for 36 hours. In total we received 106,764 requests from69 different IP addresses. This behavior—if intended rather
than a bug or misconfiguration—would allow attackers togenerate forwarding loops without even using an initiator.
Forwarding retries. We also found that when the origin
does not give a response in certain time, CloudFront andAkamai will retransmit requests to the origin websites. Upon
receiving a request from a client, a CloudFront server forwards
the request to its forwarding destination. If it does not receivea response, the server then retransmits the request twice,
30 seconds and 60 seconds after first sending it, respectively,
before returning a timeout error to the client after 90 seconds.
Akamai servers also retry one time at 120 seconds before
a final timeout at 240 seconds. In forwarding-loop attacks,
each request retransmission kicks off a new loop. In addition,even if the server closes the previous forwarding connection
before issuing a retransmission, the original loop will still
continue if any node in the loop does not implement abort
forwarding. Together, these behaviors can make the numberof loops increase exponentially.

To estimate the maximum amplification factor a gzip
bomb can provide, we performed a simple local experiment.
We first use dd to generate a 100GB file containing only
the character ’1’. We then compressed it using gzip withcompression level 9, yielding a 96.2MB file, reflecting acompression ratio of 1,064. The compression ratio serves as
an extra amplification factor (in addition to the number oftimes that the response loops) to significantly enlarge the attack
traffic.
With Baidu’s permission, we used the Baidu CDN to
conduct two experiments to verify the feasibility and theefficacy of dam flooding attacks with gzip bombs. We set
up two local CDN servers using Nginx; created a forwarding
loop between them; and set their network latency to 200 ms.
In the filling phase, we sent a single GET request into theloop. After 10 seconds, we pointed the forwarding destination
to our web server, sited behind Baidu. In the first experiment,
our server replied to the request with a uncompressed 1MB fileconsisting of a single repeated character. We then repeated theprocedure with a 1KB file reflecting a gzip’d version of theprevious 1MB file.

To examine these possibilities, we created a forwarding
loop between a CloudFront server and our HTTP forwarder.
Our forwarder did not support abort forwarding or request
streaming. We sent a single request (376 bytes) to the CloudFront server and captured HTTP traffic at our forwarder. After
156 seconds, we manually stopped the loop by killing theprocess of our forwarder, to avoid adversely affecting the
CloudFront platform. Figure 8 shows the results. We see thatthe number of requests starts to increase at 30 seconds anddoes so much quickly every subsequent 30 seconds, reaching
200 at the end of the experiment. During the experiment,
our forwarder received a total of 3,096 requests sent by the
CloudFront server, even though we only sent one request.

In the first experiment, the 1MB response looped 16 times,
with the traffic received at one local server totaling 16.6MB,
an amplification factor of approximately 17. In comparison, inthe second experiment the 1KB response looped 17 times, andat one server induced a total traffic volume of 17.7MB. This
10

TABLE VIII.

CDN REGISTRATION REQUIREMENTS AND COST.

Register Requirements
Akamai

Email address

Price

Anonymity

Free trial

3

Free trial

3

Credit cardlearning of this issue from one of their clients, even though
we did not include their service in our study because they
do not offer anonymous customer accounts. We also reported
the problem to CNCERT/CC and the CERT coordination
center (CERT/CC) through the HackerOne platform.2 Below
we summarize the discussions.

Email address
AlibabaPhone number

CloudFlare: acknowledged our report and particularly
thanked us for reporting the problem of gzip bombs. They
also actively discussed with us the potential consequences andpossible defenses, and suggested that we report the problem
to CERT/CC for coordinated disclosure.

Bank card
Azure

Email address

Free trial(China)Phone number(1 CNY)

Baidu

Email address

Free service

3

CDN77

Email address

Free trial

3

CDNlion

Email address

Free trial

3

CDN.netEmail address

Free trial

3

CDNsunEmail address

Free trial

3

CloudFlare

Email address

Free service

3

Free trial

3

CloudFront

Email address
Credit card

3

FastlyEmail address

Free service

3

Incapsula

Email address

Free service

3

KeyCDN

Email address

Free trial

3

Level3

Email address

Free trial

3

MaxCDN

Email address

Free trial

3

Free trial

3

Baidu: was interested in the attacks and had an in-depth
discussions with us about the specifics. In particular, theystated that they have seen a few real-world cases of forwardingloop attacks, which led them to add a self-defined loop detection header.3 However, they did not foresee that interactions
among CDNs could re-enable this attack.
Alibaba: discussed with us about the details of the attacks
and their potential consequences. They chose monitoring andrate-limiting to mitigate the problem.
Tencent: evaluated the problem as a high-risk vulnerability.
They stated that they view it as indeed a problem for the
CDN industry, and they would internally assess how to defend
against it. They thanked us for our report and provided a rewardof ≈ $300.
Fastly: acknowledged and discussed our report with us.
They stated that both no-abort-forwarding and HTTP Streaming provide desirable performance properties, allowing themto optimize customer traffic. To defend against inter-CDN
loops, they suggest that a unified, standard loop-detection
header holds the most promise, and are evaluating how tobest contribute to such an effort. In the mean-time, they arealso evaluating how to improve their existing loop-detection
mechanisms, given the knowledge of other CDN practices.
They thanked us and offered several T-shirts as a token ofgratitude.

Email address
Tencent

Phone number
Bank card

G. Anonymity and Cost
One may argue that these attacks cannot be launched in thereal world because of the associated costs and risk of exposing
the attacker’s identity. However, CDN providers, presumably
for competitive reasons, provide much convenience for theirprospective customers (and thus for attackers). Table VIII
shows the registration information required to begin using thefree or free-trial services of the CDN providers in our study.
11 out of 16 CDNs require only a valid email address. Akamai
and CloudFront CDNs require valid credit cards (could be giftcards, or stolen), Azure (China) requires valid phone number(could be anonymous). Alibaba and Tencent require users toverify their identity through a valid bank card, which takes anattacker more effort to keep anonymous.

CDN77: thanked us for our report and informed us thatthey will change their system to not reset Via. They also said
that no-abort-forwarding is an important performance feature
for their CDN, so they are inclined to keep it. To defend against
forwarding loops, they are considering implementing a constraint on forwarding destinations to mitigate intra-CDN loops.
They are also willing to cooperate with other CDN providers
to define a unified loop-detection header for mitigating interCDN loops.
Akamai, Azure (China) and CloudFront: acknowledged
our report, but provided no further comment to date.
Verizon (EdgeCast): stated that this problem is valid andcan be a great danger to CDNs and the Internet in general.
They are also interested in working with other CDNs to define
a unified loop-detection header.

H. Disclosure and Response
We attempted to contact all 16 CDN vendors. For 4 CDNs
(CDNlion, CDN.net, CDNsun and KeyCDN), we could not
find specific security contacts, and our messages to the generalemail addresses found on their websites or WHOIS information did not receive any reply. For the other 12 CDNs, we wereable to provide detailed report to their security contacts, and9 replied (all but Incapsula, Level3 and MaxCDN). In addition,
Verizon (EdgeCast) contacted us to discuss the problem afterIV.

P OSSIBLE D EFENSES AND M ITIGATIONS

Unifying and standardizing loop-detection header. As
we have presented, forwarding-loop attacks within one CDN
2 http://hackerone.com/cert
3 This happened before Baidu’s partnering with CloudFlare.

11that CDN to CloudFlare. In general, a more fine-grained policy
such as per-account rate-limiting could avoid this problem.

can be completely defeated with loop-detection headers, a
simple and clean solution. However, even if all CDNs adopt
loop detection headers, the issue of forwarding loops across
CDNs will remain if any CDN unintentionally provide ways
for attackers to strip the loop-detection headers of other CDNs.

However, it is worth noting that any form of rate-limiting
can be evaded by sufficient planning by attackers. In theextreme case, a forwarding-loop attack could be launched sothat attacking traffic comes from different IP addresses andattributed to different (bogus) customer accounts. Also, thereturning-with-302 strategy will not work if the major attacking traffic comes from responses using the dam-flooding attack.
Nevertheless, monitoring and rate-limiting could substantiallyraise the operational overhead of forwarding-loop attacks.

We therefore suggest that CDNs should agree upon aunified loop-detection header, and prohibit disruptive operations on it. A possible candidate would be the Via header,which the current standard already requires nodes to add when
forwarding/proxying HTTP requests [8]. The standard also
states that proxies “SHOULD NOT” tamper with entries inthe Via header set by different organizations.

Constraint on forwarding destination. Another possible
mitigation is to enforce a blacklist-like policy on forwarding
destinations. For example, a CDN can reject a request if its forwarding destination belongs to another CDN. Such constraints
could also be implemented with finer-grained conditions. In
CloudFlare’s response to us, they mentioned not accepting
a request if it comes from a CDN and goes to another.
CDN77 also expressed interest in implementing blacklistbased mitigations. The downside of this approach is that it
requires considerable efforts to maintain an accurate list of
CDN IP addresses. It also discourages benign customers fromchaining multiple CDNs, which has real-world utility [4].

A number of the CDN vendors with whom we discussed
the attacks view this approach as the most desirable solution,
and agreed that all CDNs should comply with the standard
and not disrupt the Via header. CloudFlare is implementing aloop-detection mechanism using Via.
While this approach is conceptually simple, it needs considerable coordination efforts to be implemented and enforced.
It also requires ongoing compliance testing to ensure prompt
detection of gaps in deployment. In that light, CDNs should
also consider immediately adoptable mitigations, as follows.
Obfuscating self-defined loop-detection headers. A lightweight mitigation is to implement a self-defined loop detection
header in a way that resists stripping by “bad actors” (attackers
setting up particular forwarding paths or rules). One approach
would be to obfuscate the header by generating its name via
encrypting a mix of a certain keyword and a random nonce,
which is verifiable by decrypting and validating the presenceof the keyword.

V.

R ELATED WORKCDN loop attacks and their prevention. The only material we know of that studied the problem of forwarding loops
in CDNs is a blog post from the OpenCDN team [17]. They
mention approaches for constructing loops in CDNs that lackloop-detection capabilities. Our work contributes further in thisregard in that we broadly explore the possibilities of suchattacks, and expand their scope via self-loops, evading loop
detection of one CDN by abusing features of other CDNs,
construction of the dam flooding attack, and comprehensive
measurement of how forwarding-loop attacks could work inreal world.

Such headers will resist stripping by regular-expression like
WAF rules because the attacker will not know how to specify
the header’s name. We have implemented this mitigation basedon Nginx 1.8.0. However, it will not help if a CDN provides
whitelist-based WAF rules (only propagate headers that matcha specified set).

Some publications discuss detecting internal forwarding
loops inside a single CDN. Yao proposed a “Hop Counter”
HTTP header to detect forwarding loops [23]. CoralCDN prevents internal loops by checking the “User-Agent” header [9].
However, these approaches do not consider that the undesiredinteractions among CDNs can provide opportunities to evadesuch defenses.

Monitoring and rate-limiting. Another mitigation CDNs
could implement is some form of rate-limiting. For example, a
CDN could monitor traffic volume or concurrent connections
per source IP address or per customer, rejecting or downgrading subsequent requests from the same source/customer once
their activities exceed pre-defined threshold. In particular, agracefully downgrading approach that differentiates requests
forming forwarding loops and those of legitimate clients is to
respond to potentially problematic requests with a 302 informing the initiator to try again later. While a normal client willusually follow the redirection automatically, measurementsof our implementation confirm that this approach suffices
to terminate forwarding loops because all CDNs we tested
merely relay the 302 response back, rather than following theredirection.

The Content Distribution Network Interconnection (CDNI)
working group of the IETF works on standardizing how
multiple CDNs can cooperate with each other [11], [18]. They
have considered addressing potential loops in the requestrouting process that determines the appropriate edge serverusing HTTP redirection or DNS CNAMEs among multiple
CDNs [3]. However, they have yet to consider the problem
of forwarding loops, which could occur when the edge server
forwards the request to the original website. Our suggestion of
unifying and standardizing on an HTTP header for forwardingloop detection appears to fit within their scope.

CloudFlare informed us that they have implemented alimit on concurrent connections per source IP address, anda performance downgrade similar to the returning-with-302
strategy once the source exceeds the threshold. However, theyexpressed concerns with the “greylisting” vulnerability that
this strategy introduces: attackers triggering the threshold on
IP addresses of one CDN to affect other customers chaining

Other CDN security issues. Prior work has examinedother types of attacks, and associated defenses, relevant to
CDNs. Triukose et al. proposed an attack that abuses the
no-abort-forwarding of Akamai and Limelight to launch DoS
12

necessarily reflect the views of their employers or the funding
agencies.

attacks on their customers [22]. This behavior is also related tothe effects of forwarding-loop attacks, and our measurements
show that Akamai, among other CDNs, still uses no-abortforwarding, which is vulnerable to Triukose et al.’s attack, andmakes forwarding-loop attacks more effective, although Fastly
and CDN77 explained that this is intended for performance
consideration. Su et al. discussed several Akamai implementation considerations that attackers could exploit to degradestreaming services [21]. Lesniewski-Laas et al. proposed asolution called “SSL splitting” to protect the integrity of dataserved by untrusted proxies [10]. Michalakis et al. also studied
the problem of content integrity in untrusted peer-to-peer
CDNs, and developed a system to ensure such integrity [15].
Levy et al. presented a system called “Stickler” to help website
publishers to guarantee the integrity of web content served to
end users through CDNs [12]. Liang et al. investigated theauthentication problem of deploying HTTPS in CDNs [13].
VI.

R EFERENCES
[1]
[2]
[3]

[4]

[5]

[6]

C ONCLUSION[7]

We have presented how malicious customers can launch
forwarding-loop attacks against CDNs, along with a comprehensive study of their practicality in the real world. The key
issue is that features of one CDN may have unintentional andundesired interactions that can disrupt another CDN’s internal
loop-prevention mechanisms. We believe that forwarding-loop
attacks could pose severe threats to CDNs’ availability, andhope that our work will provide insight into those issues
and help CDNs fully understand them. In the short term,
we suggest that CDNs adopt one or more of the mitigation
mechanisms discussed in the paper. In the longer term, we
hope our work will motivate CDN vendors to address the root
cause of the problem, and possibly other potential problems
caused by the lack of coordination among CDNs.

[8]
[9]

[10]

[11]
[12]

Finally, at a higher level our work underscores the hazards
that can arise when a networked system provides users with
control over forwarding—particularly in a context that lacks
a single point of administrative control, and thus allows
forwarding manipulation by leveraging inconsistencies among
policies and technical mechanisms used by different networking providers.
VII.

[13]

[14]
[15]

ACKNOWLEDGMENTS[16]

We especially thank Jie Ma, Jinghui Feng, Tingting Li and
Haoting from Baidu’s CDN team for valuable discussions andauthorization to test on their CDN platform. We also gratefully
thank Nick Sullivan from CloudFlare, Daniel McCarney from
Fastly, Tomas Kvasnicka from CDN77, Amir Khakpour from
Verizon (EdgeCast), and Hanqing Wu from Alibaba for theirhelpful comments. We also thank the anonymous reviewers,
and Zhou Li, Jianwei Zhuge, Kun Yang, Kun Du, Huiming
Liu, Wei Liu, and Qin Chen for suggestions and feedback.
This work was funded by Tsinghua National Laboratory for
Information Science and Technology (TNList) Academic Exchange Foundation, National Natural Science Foundation ofChina (grant #: 61472215) and was also partially supportedby the US National Science Foundation under grant CNS1237265, and by generous support from Google and IBM.
Any opinions, findings, and conclusions or recommendations
expressed in this material are those of the authors and do not

[17]
[18]
[19]

[20]

[21]

[22]

13

Akamai, “Facts & Figures ,” http://www.akamai.com/html/about/facts
figures.htm, 2015, [Accessed Aug. 2015].
A. Barbir, B. Cain, R. Nair, and O. Spatscheck, “Known Content
Network (CN) Request-Routing Mechanisms,” IETF RFC 3568, 2003.
T. Choi, Y. Seo, D. Kim, J. Lee, J. Koo, J. Shinn, and
K. Park, “CDNi Request Routing Redirection with Loop Prevention,” http://tools.ietf.org/html/draft-choi-cdni-req-routing-redir-loopprevention-01, 2013, [Accessed Aug. 2015].
CloudFlare, “Content Delivery Network: We‘ve built the nextgeneration CDN,” https://www.cloudflare.com/features-cdn, [Accessed
Aug. 2015].
Fastly, “Adding or modifying headers on HTTP requests and responses,” https://docs.fastly.com/guides/basic-configuration/adding-ormodifying-headers-on-http-requests-and-responses, [Accessed Aug.
2015].
R. Fielding, M. Nottingham, and J. Reschke, “Hypertext Transfer
Protocol (HTTP/1.1): Caching,” IETF RFC 7234, 2014.
R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach,
and T. Berners-Lee, “Hypertext Transfer ProtocolHTTP/1.1,” IETF RFC
2616, 1999.
R. Fielding and J. Reschke, “Hypertext Transfer Protocol (HTTP/1.1):
Message Syntax and Routing,” IETF RFC 7230, 2014.
M. J. Freedman, “Experiences with CoralCDN: a five-year operationalview,” in Proceedings of the 7th USENIX Conference on Networked
Systems Design and Implementation (NSDI). USENIX Association,
2010.
C. Lesniewski-Laas and M. F. Kaashoek, “SSL Splitting: Securely
Serving Data from Untrusted Caches,” Computer Networks, vol. 48,
no. 5, pp. 763–779, 2005.
K. Leung and Y. Lee, “Content Distribution Network Interconnection(CDNI) Requirements,” IETF RFC 7337, 2014.
A. Levy, H. Corrigan-Gibbs, and D. Boneh, “Stickler: Defending
Against Malicious CDNs in an Unmodified Browser,” in WEB 2.0
SECURITY & PRIVACY. IEEE, 2015.
J. Liang, J. Jiang, H. Duan, K. Li, T. Wan, and J. Wu, “When
HTTPS Meets CDN: A Case of Authentication in Delegated Service,”in Proceedings of the 35th IEEE Symposium on Security and Privacy(S&P). IEEE Computer Society, May 2014.
MaxCDN, “EdgeRules Features,” https://www.maxcdn.com/one/tutorial/edgerules-features/, [Accessed Aug. 2015].
N. Michalakis, R. Soulé, and R. Grimm, “Ensuring Content Integrity for
Untrusted Peer-to-Peer Content Distribution Networks,” in Proceedingsof the 4th USENIX conference on Networked systems design & implementation (NSDI). USENIX Association, 2007, pp. 11–11.
M. Nottingham, “Caching POST,” https://www.mnot.net/blog/2012/09/
24/caching POST, 2012, [Accessed Aug. 2015].
OpenCDN, “The Idea of Traffic Amplification Attacks,”
http://drops.wooyun.org/papers/679, 2013, [Accessed Aug. 2015].
L. Peterson, B. Davie, and R. van Brandenburg, “Framework for Content
Distribution Network Interconnection (CDNI),” IETF RFC 7336, 2014.
J. Roberts, “How does CloudFlare Handle HTTP Request Headers? ,”https://support.cloudflare.com/hc/en-us/articles/200170986-How-doesCloudFlare-handle-HTTP-Request-headers, 2015, [Accessed Aug.
2015].
A.-J. Su, D. R. Choffnes, A. Kuzmanovic, and F. E. Bustamante,“Drafting behind akamai (travelocity-based detouring),” SIGCOMM
Comput. Commun. Rev., vol. 36, no. 4, pp. 435–446, Aug. 2006.
[Online]. Available: http://doi.acm.org/10.1145/1151659.1159962
A.-J. Su and A. Kuzmanovic, “Thinning Akamai,” in Proceedings of
the 8th ACM SIGCOMM conference on Internet measurement (IMC).
ACM, 2008, pp. 29–42.
S. Triukose, Z. Al-Qudah, and M. Rabinovich, “Content Delivery
Networks: Protection or Threat?” in Computer Security–ESORICS 2009.
Springer, 2009, pp. 371–389.

[23]Y. Xi, “Method and Device for Defending CDN Flow Amplification Attacks,” https://www.google.com/patents/CN103685253A?cl=en,
2013, [Accessed Aug. 2015].

14