Addressing Scalability

The basic design of Charon assumes routers always hold the content summary for a certain prex under attack. However, this may be unlikely to scale in real settings for several reasons. First, routers would need to store content summaries for a large number of content providers, e.g., all the prex names available in the router's FIB. Still, this would be reasonable, assuming those were mostly stored on secondary memory and moved to main memory at run-time accordingly. Second, those summaries may need to be updated by content providers or new summaries may be needed due to routing updates. For the above reasons, it seems reasonable to foresee a way for routers to occasionally fetch and/or regularly update content summaries. The basic design of Charon enforces no specic solution for that purpose rather highlights a few possibilities. Content summaries could be made available to routers via either a trusted centralized authority (as it happens for today's public key certicates) or could be directly asked to the respective content producers. In the latter case, encryption should be used to avoid prospective attackers to fetch the content summaries and generate set of forged content identiers which generate false positives. Furthermore, once the summaries are issued by the content providers, they would be cached in the network as ordinary Data packets. Therefore, the latency necessary to retrieve the summaries is reduced and the risk of relying on a single centralized point of failure too. In both cases, a secure communication channel between the router and the source of the summaries should exist to prevent attackers from getting the information required to obtain a clear version of a summary. The architecture envisioned by Charon is illustrated in Fig. 4.3.

With regard to the scalability of the countermeasure, Charon oers a considerable advantage over existing reactive countermeasures. In fact, while reactive countermeasures must be deployed in several network areas and orchestrated so for the attacks to be properly detected, the check performed by a proactive countermeasure like Charon is independent from the position in the network where that is deployed. In fact, Charon can be selectively deployed in a few specic points of network without compromising its overall ecacy. In particular, edge-routers are perfect candidates since they block the fake Interests as soon as those enter the mainstream network. Additional deployment of the countermeasure in inner network tiers would not bring any tangible benet assuming the content summaries are mostly identical, that is, having the same false error probability. The deployment at the edge also reliefs core network routers to perform additional per-packet processing which could not be sustained at certain link speeds.

12_{In Greek mythology, Charon is the Hades' ferryman who carries souls across the rivers dividing the world of} the living from the world of the dead.

Tier 3 network

Backbone (Tiers 1 and 2)

Legitimate Interest Data Malicious Interest Tier 3 network Router running Charon Interest Processing /en.wikipedia.org/wiki/icn.html Check summary Yes, forward No, drop The name content

identifier is checked against the BF-based content summary.

Wikipedia Page Titles Content summary, e.g., /contentSummary/en.wikipedia.org Internet users Option 1: fetching from A Certificate Authority Option 2: fetching from the content provider

Figure 4.3  An overview of the architectural components for the deployment of the proactive countermeasure Charon.

Finally, Charon envisions the possibility for routers to ask for dierent summaries of the same content list. The reason for this feature is to allow routers to decide about the size of the lter to store and the computational overhead to sustain. The false probability error in BFs depends on three factors: the number of elements in the set n, the size of the lter m, the number of hash functions k. Thus, for example, a smaller lter could be required by a provider whether a higher false probability error would be considered acceptable.

4.3. Evaluation

4.3 Evaluation

The evaluation reported in this section concerns two main factors. First, it shows that the proactive Charon design is more robust than the best state-of-the-art countermeasures against all the latest stealthy attacks proposed in [111]. In fact, Charon entirely preserves the quality of service perceived by clients when the network is under those attacks. Moreover, Charon shields the network infrastructure from the overload of state in PITs created by the attackers ooding with malicious Interests. Second, it outlines the importance of evaluating the impact of the application of the IFA countermeasures on legitimate trac. Indeed, by precisely tracking the forwarding decisions taken on both malicious and legitimate interests in the network simulations, it is possible to see two dierent concerning behaviors: i) a considerable amount of legitimate trac is always dropped as a consequence of the mitigation and the eect of this behavior on some kind of trac, e.g., video streaming, stays unclear, ii) the portion of legitimate trac dropped does not necessarily depend on the router load rather on whether or not Malicious In- terests and Legitimate ones enter the router from the same downstream interface.

The rest of the section is organized as follows. The evaluation settings and metrics are summa- rized in Sec. 4.3.1. A novel evaluation metric which measures the impact of a defense mechanism on legitimate trac is introduced in Sec. 4.3.2. Finally, the performance of Charon compared to the state-of-the art countermeasures is discussed in Sec. 4.3.3.