Embed Size (px)
Citation preview
PIT Overload Analysis in Content Centric Networks
Matteo VirgilioDepartment of Control and
Computer EngineeringPolitecnico di Torino
Guido MarchettoDepartment of Control and
Computer EngineeringPolitecnico di Torino
Riccardo SistoDepartment of Control and
Computer EngineeringPolitecnico di Torino
ABSTRACTContent Centric Networking represents a paradigm shift inthe evolution and definition of modern network protocols.Many research efforts have been made with the purpose ofproving the feasibility and the scalability of this proposal.Our main contribution is to provide an analysis of the Pend-ing Interest Table memory requirements in real deploymentscenarios, especially considering the impact of distributeddenial of service attacks. In fact, the state that the pro-tocol maintains for each resource request makes the routersmore prone to resources exhaustion issues than in traditionalstateless solutions. Our results are derived by using a fullcustom simulator and considering the different node archi-tectures that have been proposed as valid reference models.The main outcomes point out differentiated weaknesses ineach architecture we investigated and underline the need forimprovements in terms of security and scalability.
KeywordsContent Centric Networking, Security, DDoS attacks, Sim-ulation
1. INTRODUCTIONContent Centric Networking (CCN) [7] is emerging as one
of the possible dominant paradigms for the future networkarchitecture. Starting from the valid claim that in a contentdistribution network it is actually important to address re-sources themselves, rather than their physical location, CCNaims to change the traditional network operation by mak-ing all network devices name-aware. Then, routing decisionsare taken according to the name of the resource the user isrequesting.The approach is promising and may represent one of themost significant innovations in the networking field. How-ever, its new operating mode opens the path for possibleissues and threats that were not present in the traditionalnetwork. These have to be properly investigated in order
Permission to make digital or hard copies of all or part of this work for personal orclassroom use is granted without fee provided that copies are not made or distributedfor profit or commercial advantage and that copies bear this notice and the full cita-tion on the first page. Copyrights for components of this work owned by others thanACM must be honored. Abstracting with credit is permitted. To copy otherwise, or re-publish, to post on servers or to redistribute to lists, requires prior specific permissionand/or a fee. Request permissions from [email protected]’13, August 12, 2013, Hong Kong, China.Copyright 2013 ACM 978-1-4503-2179-2/13/08 ...$15.00.
to have an exhaustive evaluation of the overall CCN archi-tecture. For example, content delivery is based on a statusinformation (the requested URI) that has to be maintainedat nodes in the so called Pending Interest Table (PIT). Thismay pose strict constraints in terms of reliability and scal-ability. In fact, this table may overflow, with consequentservice disruption and possible network collapse. Further-more, these constraints might be even exploited by attackersin order to slow down or even interrupt the normal networkoperation.In this paper we deal with this specific problem by providinga performance evaluation of some possible PIT architecturesin terms of resilience to (possibly malicious) overload con-ditions. In particular, we consider three PIT architectures,referenced in the available CCN literature: (i) a PIT storingall the bytes composing an URI, which we call SimplePIT;(ii) a PIT storing a fixed length entry for an URI, which wecall HashedPIT; (iii) a PIT implemented through multipleBloom Filters placed in each router interface, as describedin [18]. This solution is known as DiPIT.The experiments are conducted by means of an ad-hoc sim-ulator, designed to recreate the behavior of a CCN networkand to track memory usage at CCN nodes. In order to ob-tain significant results, the simulator implements the topol-ogy of a prominent Italian ISP. The paper has the followingstructure: Section 2 briefly introduces CCN and its architec-ture. Section 3 dives into PIT overloading issues, explainingthe importance of this problem in the CCN context. Sec-tion 4 offers an overview of the related work in this field.Section 5 introduces our experimental analysis and presentsthe obtained results. Finally, Section 6 concludes the paperand also presents some possible future work.
2. CONTENT CENTRIC NETWORKINGContent Centric Networking (CCN) relies on two main
types of packets: Interest packets and Data packets. Theformer are used by clients to request a (piece of) resource.They include the content name, in the form of a Uniform Re-source Identifier (URI), plus a set of parameters useful forInterest processing. The latter are transmitted as responsesto client requests and are used to deliver pieces of data.One of the key features of the CCN architecture is the cach-ing capability. A CCN node, e.g., an edge router, can storeData packets in its local repository and autonomously servefuture requests for that content, without forwarding aheadInterest packets. This possibly leads to a reduced latencytime experienced by clients and to a lower bandwidth usage.In order to correctly deliver data, CCN nodes are equipped
67
with three data structures: (i) The Content Store (CS),which is the area where Data packets are cached. Each In-terest arrival causes a Content Store lookup: if the requestedname is present in the store, the response is immediatelygenerated; (ii) The Pending Interest Table (PIT), which isthe data structure where routers annotate forwarded Inter-ests and the respective arrival interfaces. Multiple Interestsfor the same URI are aggregated in a single entry (Interestmerging) to improve the system scalability; (iii) The For-warding Information Base (FIB), which is the equivalent ofthe IP routing table. When a client generates an Interest,each router in the path towards the destination adds an en-try in its PIT. In this way, devices readily forward packetsto the right hosts when the response comes back. The entryremains in the PIT for a time interval called LifeTime, whichis specified in the Interest itself. If the LifeTime expires andthe response has not yet arrived, the memory is released.Notice that this parameter is chosen by clients. Hence, atleast according to the current CCN rules, it is not under thenetwork control.
3. PROBLEM DESCRIPTIONThe PIT is the fundamental structure used to maintain
the state of each active flow. It grows with users sendingtheir Interests and shrinks when Data packets arrive at therouter. Considering the access speed required for such astructure and the possibilities offered in this sense by cur-rent memory technologies, the PIT size might represent abottleneck for the entire CCN infrastructure.The problem might be exacerbated by a massive usage oflong Interest LifeTimes, which would further increase thenumber of simultaneous entries in the PIT. Despite the pullnature of CCN, this possibility cannot be excluded as itwould be necessary for supporting publish/subscribe ser-vices [6] where users subscribe for a given content that willbe asynchronously produced in the future. Many of theseservices are implemented, for example, by means of HTTPlong polling strategies, which make extensive use of long (po-tentially unanswered) requests. [9] presents a complete dis-cussion on the best practices about timer setting and on how’long’ these requests should be. In general, 30 s is considereda safe value, as longer timers may be undesirable for inter-mediate proxies placed between the server and the client.However, solutions with longer values are widely adoptedin common web applications (e.g.,FaceBook and some web-based mail applications, which to our experience often usetimers of more than one minute). In addition to that, wehave to consider that one or more malicious users could craftartificial requests with the purpose of filling the availablePIT memory on routers, thus implementing a DistributedDenial of Service (DDoS) attack.With PIT overflow, users would see their Interests discardedby routers and, consequently, they would experience an in-creasing rate of retransmissions until the network completelycollapses. With this problem in mind, some possible PITarchitectures have been proposed with the aim of reducingthe required table size. A first simple solution [7] is to re-alize the PIT by means of a hash-table, where each URI isencoded using a fixed number of bits. Other possible so-lutions deploy more complex architectures. For example,[3] proposes a tree-like structure to arrange the PIT entriesin order to also ensure high lookup, insertion, and deletionspeed, while [18] presents a very efficient PIT architecture
based on Bloom Filters.While these solutions may be effective during normal oper-ation, performance degradation might be experienced whenthe system is under the abovementioned DDoS attacks. Thiskind of attack may be implemented by distributedly gener-ating Interest packets that contain a valid destination prefixbut non-existing resource names, so that routers properlyforward Interests and store new entries in their PITs, butresponses never come back. The destination might possi-bly be colluded with the attacker and simply drop incomingpackets. In order to maximize the impact of the attack, amalicious user could request always different resources thusavoiding Interest merging. Furthermore, the attacker couldalso select large values for the LifeTime field. Figure 1 shows
Figure 1: Attack scenario
a very simple network consisting of three routers, an attacker(or, equivalently, a bot net), a normal client and a bad des-tination, which is placed ad hoc by the attacker. The roleof the bot net is that of generating Interests towards thefake destination. Routers along the dashed path (R1 andR2) are flooded with unanswered Interests, which indeed in-creases their memory usage.This paper presents an analysis of the PIT resilience to pos-sible overload and consequent service disruption. A compre-hensive simulation study of the possible PIT architectures isdone in order to evaluate their performance from this per-spective.
4. RELATED WORKThe feasibility of the CCN approach with regard to the
amount of requested resources at nodes, together with aproper CCN node dimensioning, has been recently objectof a wide research activity. For example, [2] presents an effi-cient router design and describes some possible usage scenar-ios. Designing an efficient forwarding plane is also the sub-ject of [19], which identifies key issues related to the protocolfast speed implementation and establishes some principles tobe observed in order to design scalable forwarding architec-tures. Furthermore, [11] presents a feasibility study of CCNand concludes that CCN nodes based on current technolo-gies would still be unable to sustain requests arrival rates atthe Internet scale. However, they can sustain rates at Con-tent Distribution Network and small ISP scale. Specifically
68
concerning the PIT dimensioning problem, two recent pa-pers propose different architectures conceived for reducingthe PIT size. As also described in the previous section, [3]proposes a tree-like PIT structure, while [18] present a PITarchitecture based on Bloom Filters. However, both papersdo not provide a quantitative evaluation of the PIT overloadproblem and do not consider possible DDoS attacks.Concerning the security threats in a CCN network, the avail-able literature mainly covers privacy, data authentication,and data integrity issues. For example, [15] addresses theprivacy problem deriving from the stateful operation of CCNrouters, while data authentication and integrity have beenconsidered since the seminal CCN papers [7, 8]. Instead, acomprehensive study of the possible PIT overload issue de-riving from a DDoS attack is missing. [4] presents a solutionto mitigate these attacks, while the ongoing work by Gastiet al. [12] gives an introductive overview of the problem andof some ongoing experiments. Hence, the available informa-tion is somewhat complementary to the results of this paper,which provides a quantitative evaluation of the resilience ofsome proposed PIT architectures to this kind of attack.
5. PIT RESILIENCE ANALYSISThis section focuses on the evaluation of the PIT resilience
to possible overload. Our analysis is performed by simula-tion and considers three possible PIT architectures: (i) aPIT storing all the bytes that compose an URI, referred to asSimplePIT; (ii) a PIT storing fixed length entries evaluatedas hash values of the URIs, referred to as HashedPIT; (iii)a PIT implemented through multiple Bloom Filters placedin each router interface, as described in [18]. This last so-lutions is known as DiPIT. The PIT architecture presentedin [3] is not explicitly investigated here as it shares with theHashedPIT the same principle of introducing fixed lengthentries (in [3] the numerical codes that make up the logicaltree structure are reduced to fixed length).While in the first two cases PIT overloading can be mea-sured in terms of memory occupancy, with possible memoryoverflow, in the latter case this is not possible as the DiPITis based on Counting Bloom Filters, where memory occu-pancy is constant. In essence, the filter fills the entire mem-ory size and each Interest is encoded in a sequence of ’1s’ tobe added at given positions of the filter. In this case, PIToverloading results in a high rate of the so called false posi-tive events, namely, the node erroneously concludes that anInterest is present in the filter and either does not propagateit or erroneously removes some entries from the PIT whena chunk is received. In both cases this results in a degra-dation of the service perceived, as both events require oneor more Interest retransmissions. [18] proposes an effectivecombination of filters to reduce the false positive probabil-ity during normal operation (see [18] for further details), butthis may increase when the network is under attack. In or-der to quantitatively evaluate the effect of false positives andalso enable a coherent comparison among the three consid-ered PIT architectures, we base our analysis on the averagepercentage of Interest retransmissions that occur at users’machines. This is clearly proportional to the average down-load time they experience, and hence it is a metric of theoverall network performance.A further issue to address is the selection of a proper simu-lator complying with the requirements of our study. SomeCCN simulators are available, but all are customized for spe-
Figure 2: Telecom Italia topology
cific analyses. For example, ccnSim [5] has been designedmainly for the evaluation of cache replacement techniquesand hence is not optimized for experimenting on the PITmanagement. Hence, in order to focus our analysis on PITissues and meet our specific requirements, we developed afull custom event-driven Java simulator1.
5.1 Simulation scenarioWith the main aim of obtaining significant and quanti-
tative results, the network configuration and user behaviormodels are refined to faithfully recreate realistic scenarios.In particular, we adopt as a reference the network of TelecomItalia, a prominent Italian ISP. Data related to the TelecomItalia network that are of interest in this context are pub-licly available on the web.First of all, the topology adopted in our simulations repro-duces the real structure of the Telecom Italia network [16](see Figure 2, represented at Point of Presence (PoP) gran-ularity). The network is divided in two areas: the first onethat covers Northern Italy and the second one that coverscentral and Southern Italy. PoPs are almost equally dividedbetween the Northern and the Southern areas and in oursimulator each PoP is represented by a router. This topol-ogy is typical also of many ISPs in Europe.Concerning the network population, we adopt the numberof broadband Internet subscriptions currently active in theTelecom Italia network — around 9 million — available inthe ISP investor relation [17]. We also assume the topologi-cal distribution of users among the ISP PoPs to be directlyproportional to the geographical distribution of the ISP cus-tomers. This allows us to accurately reproduce the downloadtraffic pattern of the ISP users. Furthermore, access band-widths are considered uniform for simplicity and equal to 7Mbps (download) and 1 Mbps (upload), which are the val-ues characterizing a large percentage of Telecom Italia users.The overall header size of the protocols underlying CCN isassumed fixed to 20 bytes.
Regarding the selection of the content to be retrieved by
1The NS-3 based NdnSIM CCN simulator [1] was not yetavailable when we started our project, but we plan to moveto that environment for our future work on this topic
69
clients, we assume a Zipf- Mandelbrot probability distribu-tion, which Saleh et al. [14] proved to properly model thebehavior of users in a content distribution P2P network.Given the content delivery nature of a CCN network, thisprobability distribution could reasonably model the user be-havior also in our case. According to the Zipf’s Law andgiven the total number of resources in the network, whichare uniformly distributed among per-PoP content providers,the corresponding distribution function is expressed as fol-lows:
p(i) =1
(i+ q)α∀i ∈ [1, N ]
where p(i) is the probability of extracting the i-th contentavailable in the network, q and α are two parameters that[14] fixed to α = 0.55, q = 25 for a residential ISP (as Tele-com Italia is), and N is the total amount of resources.Download requests are modeled using a Poisson process withaverage rate equal to 500 requests per second. This resultsin an average value of around 12 million simultaneously ac-tive downloads in the steady state. We believe this networkload is even higher than that observed in a 9 million usersnetwork during normal operation and hence it is significantfor our study.Another key parameter for our evaluation is the memoryavailability at CCN nodes. Reasonable values for the PITsize that match both the required memory access speed andcurrent memory technologies are some hundreds of MB [18],available by means of the SRAM technology. In order tobe more conservative and also with the aim of analyzing apossible near future scenario, we fix the PIT size to 1 GB.In the DiPIT case, this value refers to the overall availablefilters memory (the PITs plus the shared Bloom filter).Concerning the attack parameters, we consider a maximumaggregate attack bandwidth of 4 Gb/s, which is a realisticvalue for a medium scale ISP such as Telecom Italia [13], andInterest LifeTimes values that vary between 4 s (the defaultvalue considered in the CCNx [10], the prototypal imple-mentation of CCN node) and 180 s. Notice that those arereasonable LifeTime values if we think to enable completepublish/subscribe services in a CCN network, as discussedin Section 3.
5.2 ResultsThis section reports on the simulation results obtained for
the three considered PIT architectures: the SimplePIT, theHashedPIT and the DiPIT. We consider a distributed botnet sending Interests to fake destinations connected to theRome edge router. Hence, our analysis focuses on the RomePoP as it is the most overloaded node. In essence, we keeptrack of the memory usage at the Rome PoP. Furthermore,we also measure the average percentage of retransmissionsexperienced by users, as depicted above.
5.2.1 I scenario - SimplePITIn the first scenario, we consider to deploy a SimplePIT
at each router. This PIT implementation stores the entireURI in the memory so it is the simplest architecture we canthink of. In order to maximize transmission efficiency, andconsequently maximize attack impact, it is important for theattackers to craft very long URIs. We selected 1000 bytesin our simulation. In particular, each malicious URI has avalid 13 bytes prefix (e.g. /it/badPubRm/ required forreaching the destination) and a non-existing resource name
whose length is set to a randomly selected string of 1000bytes.Simulation results concerning the memory occupancy at theRome PoP and the related retransmission rate are shownin Table 1 for several values of the overall bot net band-width and of the fake Interest LifeTimes (retransmissionsare referred only to finished downloads). Users do not ex-perience a considerable retransmission rate until the PIT iscompletely full. However, by increasing either the overallattack bandwidth or the Interest LifeTime, routers start tobe unable to correctly handle incoming traffic and all theconnections are significantly slowed down.These results can be analytically justified. Let us considerthe following case as an example (we recall that the overallheaders of underlying protocols is fixed to 20 bytes in oursimulations):
Battackers = 2 Gbps, LifeT ime = 4sec (1)
|Interest|attackers = 1033 bytes(
URI︷︸︸︷1013 +
HEADER︷︸︸︷20 )(2)
The number of Interests per second generated by the botnet can be calculated in the following manner:
(2 ∗ 109) bps
(1033 ∗ 8) bits≡ 242013
Interest
sec(3)
Considering a 4 s LifeTime, we obtain:
≈ 242013 ∗ 4 = 968.052 entries⇒ ≈ 980MB occupied (4)
which is consistent with our simulation result.
5.2.2 II scenario - HashedPITIn the second scenario, we consider the HashedPIT, na-
mely, a centralized hash table storing a fixed length entryfor each URI in transit. We exploit the SHA-1 hashing al-gorithm in order to ensure a negligible collision rate. In thiscontext, the best size for an attacker’s URI is 20 bytes, ac-cording to the SHA-1 output digest (160 bits). Longer URIsare useless as would be reduced to 20 byte strings by CCNnodes. In this case the resultant attackers transmission effi-ciency, here intended as the amount of transmitted data thatwill be stored in the PIT with respect to the total traffic gen-erated by the host, is around 50% due to the non-negligibleunderlying header size (20 byte headers in our simulationslead to 20 / (20+20) = 50 % transmission efficiency). Sincein the previous case the efficiency was about 98% (1013 bytelong URIs lead to 1013 / (1013 + 20) ≈ 98% ), one couldinfer that an attacker has simply to double its bandwidth toget the same impact of the SimplePIT case. This is only par-tially confirmed by simulation results presented in Table 1.We can observe how, as expected, the memory occupancyis halved at equal simulation conditions and, consequently,the retransmission rate grows slowly with the increase of theattack intensity. However, it is worth noticing the greaterattack effectiveness when the PIT is almost completely fullwith respect to the previous case. Such a situation here pre-vents users from finishing any downloads and the numberof retransmissions tends to infinite, namely, no useful dataare received by clients, who continue to retransmit Inter-ests: the network is completely unusable. The infinite valuein Table 1 just represents the situation in which no stablevalue is reached for the number of retransmitted packet fromthe client point of view. This is due to the fact that the first
70
Attack settingsSimplePIT HashedPIT DiPIT
Retransmissions RAM Usage Retransmissions RAM Usage Retransmissions RAM Usage
Band = 100 Mbps 0 ≈ 49 MB 0 ≈ 25 MB % ≈ 0.01 % 1 GBLifeTime = 4 sec
Band = 500 Mbps 0 ≈ 245 MB 0 ≈ 125 MB ≈ 2.42 % 1 GBLifeTime = 4 sec
Band = 2 Gbps 0 ≈ 980 MB 0 ≈ 500 MB ≈ 87.6 % 1 GBLifeTime = 4 sec
Band = 4 Gbps ≈ 15 % ≈ FULL ≈ 83 % ≈ FULL ≈ 90 % 1 GBLifeTime = 4 sec
Band = 100 Mbps 0 ≈ 735 MB 0 ≈ 375 MB ≈ 21 % 1 GBLifeTime = 60 sec
Band = 100 Mbps ≈ 37 % ≈ FULL 0 ≈ 750 MB ≈ 86 % 1 GBLifeTime = 120 sec
Band = 100 Mbps ≈ 52 % ≈ FULL ∞ ≈ FULL ≈ 88 % 1 GBLifeTime = 180 sec
Table 1: PITs performance evaluation
data structure is more complex to overfill as stored Interestsare of highly variable length and attackers do not have exactinformation of the amount of memory that is still availableat routers. Hence, when the PIT is almost full many attack-ers’ fake Interests are discarded as they are too large withrespect to the available space. Some shorter users’ Inter-est can instead be accommodated and hence the network isstill able to operate, although with a significantly reducedefficiency. In the HashedPIT case, instead, 20 bytes is al-ways the best choice for URI length so the attack is moreeffective and destructive. This clearly does not mean thatthe SimplePIT can be considered resilient to DDoS attacksas specific attacker techniques may be adopted to possiblysaturate the PIT. This analysis is left for future work.
5.2.3 III scenario - DiPITThe last scenario refers to a very different PIT and router
architecture. The central PIT is split into multiple smallerper-interface PITs, each implemented by a Counting BloomFilter data structure. The specific description of this pro-posal and the algorithm adopted is available in [18]. Theretransmissions observed in this case are due to the BloomFilter false positive events, as described above in this sec-tion. The probability for a Bloom Filter to return a false
positive may be approximately evaluated2 as (1− e−k∗nm )k,
where k is the number of hash functions deployed to code agiven element, n is the number of elements currently in thefilter, and m is the total size of the filter. In our simulatoreach Bloom Filter is modeled by means of this probabilityfunction. Furthermore, the specific architecture based ondifferent filters and the insertion/deletion algorithms pre-sented in [18] are reproduced in order to obtain consistentresults.In [18], the authors also suggest possible values for k, whichvary according to the Interest arrival rate that the router hasto support. We set this value to 4 hash functions becauselarger values are not suitable for high-end routers. For theBloom Filter, we assume for simplicity 8 bit counters andno counter overflow. Simulation results are presented in Ta-ble 1. It is worth noticing how although the DiPIT does notsuffer from memory overflow (neglecting counter overflow),
2Assuming independence for the probabilities of each bitbeing set.
false positive events become a truly limiting factor whenthe network is under attack and many entries are insertedinto the filter. In fact, considerable retransmission rates areobserved also with non-huge attack intensities.
5.3 DiscussionThese simulation results lead us to a twofold conclusion.
First, none of the analyzed PIT architectures is overloadedduring normal operation in the considered network scenario.Even with a low intensity attack, memory usage is reason-able and no retransmissions are observed. This in some wayconfirms that even a traditional SimplePIT-based solutionmight be currently deployed at ISP scale, as also concludedby the analysis in [11]. However, second, there are signif-icant weaknesses in all the architectures when the attackintensity grows.To summarize our results, Figure 3 plots the number ofpending downloads in the network over time for some ref-erence values of attack bandwidth B and fake Interest Life-Time. In Figure 3(a), the considered attack intensity leadsthis number to slowly diverge with a similar trend for boththe HashedPIT and DiPIT based nodes. For the SimplePITwe do not observe a significant gap with respect to the sys-tem behavior during normal operation. Figure 3(b) consid-ers a more critical scenario: B=100 Mbps, LifeTime=180 sand also B=4 Gbps, Lifetime=30 s for the SimplePIT. Wecan observe how the SimplePIT is only partially affected inthis second case, while the system fast exits the steady statedue to retransmission rate divergence when the HashedPITis deployed. We can conclude that the HashedPIT is the ar-chitecture most affected by the considered attack, while theSimplePIT is the architecture most resilient for the reasonsexplained above. The DiPIT has an intermediate behavior.Clearly, these results hold in our attack scenario. Startingfrom this point, one could design other specific attacker be-haviors that even worsen the perceived service, especially forthe SimplePIT. For example, an attacker may: (i) combinebroad bandwidth and higher LifeTime to increase attackeffectiveness; (ii) distribute more zombies around the net-work to avoid attack source detection; (iii) exploit more badprefixes in order to make any countermeasures even morecomplex to deploy. This is a non-exhaustive list that fur-ther motivates the real need for proper countermeasures toDDoS in a CCN network.
71
(a) (b)
Figure 3: Network performance evaluation
6. CONCLUSION AND FUTURE WORKThis paper compares the existing PIT architectures with
the aim of providing a quantitative evaluation of their re-silience to overload conditions, especially when these aredue to DDoS attacks. Our results show how all architec-tures are affected by these attacks and hence further stud-ies are needed to figure out possible countermeasures. Onecan be, for example, the introduction of smarter algorithmsfor LifeTime management at content routers, which adaptLifeTimes as a function of the network load: a router cangrant larger LifeTime values in case of low traffic conges-tion and, conversely, implement a sort of LifeTime shapingwhen the load increases. With such a mechanism, we wouldbreak down the hypothesis that intermediate nodes do notmanage LifeTime values as well as PIT entries removal (forexample by discarding the ones which have a too long expira-tion time). Other mechanisms could be based on an InterestRED (Random Early Discard) strategy based on the amountof occupied memory. The higher the congestion, the largeris the probability of discarding an incoming Interest. Thiswould call for a complete performance comparison with ex-isting mechanisms that, in the context of IP networks, droppackets to handle traffic congestion. Last but not least, itis necessary to figure out possible strategies to detect anddrop malicious Interests. These and other possible mecha-nisms will be subject of our future work. We will perform aquantitative evaluation of all of them, also considering theircomplexity in terms of additional computing and memoryresource needs.
7. ACKNOWLEDGMENTSThe authors would like to thank Prof. Luigi Ciminiera,
who had a fundamental role in starting up this work.
8. REFERENCES[1] A. Afanasyev, I. Moiseenko, and L. Zhang. ndnsim:
Ndn simulator for ns-3. Technical Report, NDN-0005,Oct. 2012.
[2] S. Arianfar, P. Nikander, and J. Ott. Oncontent-centric router design and implications. InReARCH ’10, Philadelphia, PA, USA, Nov. 2010.
[3] H. Dai, B. Liu, Y. Chen, and Y. Wang. On pendinginterest table in named data networking. In ANCS’12, Austin, TX, USA, Oct. 2012.
[4] Huichen Dai, Yi Wang, Jindou Fan, and Bin Liu.Mitigate ddos attacks in ndn by interest traceback. InNOMEN ’13, Turin, Italy, Apr. 2013.
[5] D.Rossi and G. Rossini. Caching performance ofcontent centric networks under multi-path routing(and more). Technical Report, Telecom Paris Tech,2011.
[6] P.Th. Eugster, P. A. Felber, R. Guerraoui, andA. Kermarrec. The many faces of publish/subscribe.ACM Computing Surveys, 35:114–131, 2003.
[7] V. Jacobson, D. K. Smetters, N. H. Briggs, M. F.Plass, P. Stewart, J. D. Thornton, and R. L.Braynard. Networking named content. In CoNEXT’09, Rome, Italy, Dec. 2009.
[8] V. Jacobson, D. K. Smetters, N. H. Briggs, M. F.Plass, P. Stewart, J. D. Thornton, and R. L.Braynard. Voccn: Voice-over content-centric networks.In ReArch ’09, Rome, Italy, Dec. 2009.
[9] S. Loreto, P. Saint-Andre, S. Salsano, and G. Wilkins.Known issues and best practices for the use of longpolling and streaming in bidirectional http. RFC 6202,Apr. 2011.
[10] PARC. Ccnx technical documentation.http://www.ccnx.org/.
[11] D. Perino and M. Varvello. A reality check for contentcentric networking. In ICN ’11, Toronto, Canada,Aug. 2011.
[12] P.Gasti, G. Tsudik, E. Uzun, and L. Zhang. Dos &ddos in named-data networking. arXiv:1208.0952,Aug. 2012.
[13] Radware. Global application & network securityreport. Annual Report, 2011.
[14] O. Saleh and M. Hefeeda. Modeling and caching ofpeer-to-peer traffic. In ICNP ’06, Santa Barbara, CA,USA, Nov. 2006.
[15] S.Arianfar, T. Koponen, B. Raghavan, and S. Shenker.On preserving privacy in content-oriented networks. InICN ’11, Toronto, Canada, Aug. 2011.
[16] A. Soldati. Telecom italia ip backbone and peeringpolicies. In Italian Peering Forum (PFI 2008), 2008.
[17] Telecom Italia S.p.A. Resoconto intermedio di gestioneal 31 marzo 2012 (in italian).http://1q2012.telecomitalia.com/attachments/telecomitalia2012q1it.pdf, 2012.
[18] W. You, B. Mathieu, P. Truong, J. Peltier, andG. Simon. Dipit: a distributed bloom-filter based pittable for ccn nodes. In ICCCN ’12, Munich, Germany,July 2012.
[19] Haowei Yuan, Tian Song, and Patrick Crowley.Scalable ndn forwarding: Concepts, issues andprinciples. In ICCCN ’12, Munich, Germany, July2012.
72
