# Reputation-Based Trust Approaches in Named Data Networking
## 3 Reputation-Based Approaches in NDN
### Motivation
To make things worse, subsequent Interests for the same content are satisfied by the infected CS and the fake content is spread to the network. In the case of a cache poisoning attack, the adversary exploits the lack of any in-network signature verification. In the NDN/CCN architecture, consumers are obliged to verify the signatures of received content, while routers are not mandated to do so. There are three main reasons for this: (1) the computational cost of in-network cryptographic operations such as signature verification, can be considered prohibitive at line speed (at least for high-speed networks), (2) an additional overhead is being introduced in order to fetch the associated certificate chain, and (3) there is no unified trust model in NDN [23]. Regarding signature verification, it is considered as a heavy cryptographic operation, especially when compared to signature generation [24; 25]. NDN currently offers two signature algorithms by default, RSA and ECDSA. Based on previous results, the authors of Reference [26] argue that stretching existing state of the art signatures (and their computationally expensive cryptographic primitives, such as modular exponentiations or elliptic curve point multiplications) so as to perform wire-speed verification over line-rates in the order of 10 or 100 Gbps is hard, to say the least. Results in Reference [27] showed that an optimized software implementation of RSA1024 signature verification running on Intel Core 2 Duo 2.53 GHz CPU allows a router to verify about 150 Mbps of traffic, assuming 1500 Bytes per content packet, or even worse with smaller-sized packets. As a result, the authors conclude that NDN routers with multiple Gigabit-speed interfaces would need an unrealistic amount of computing power to verify signatures of Data packets at wire speed. A more recent study [28] focused on the per-packet verification cost and showed that the default NDN signature verification algorithm requires 0.0839 ms for verification of a 1000 bytes content packet on an Intel Core 2 1.83 GHz processor, using MD5 as the message-digest algorithm, RSA1024 as the asymmetric cryptographic algorithm, and DES-XEX3/CTR as the symmetric cryptographic algorithm. This amounts to 11,918 packet signature decryptions per second, far from meeting Gbps forwarding requirements. While another study [24] calculated that the average time for signature verification ranges from 1.274 ms (RSA algorithm) to 6.869 ms (Ring signature), on an Intel \({}^{\textregistered}\) Core\({}^{\text{TM}}\) i7-7700 CPU @3.6 GHz, 16 GB RAM desktop computer (packet size is not specified). What is more, the results in Reference [29] show that the performance impact by signature verification may be high even on end-user client nodes, as throughput decreased by 5 to 20 times on web browsers running NDN.JS when signature verification was enabled. The authors contribute the severity of the decrease on the fact that JavaScript is not optimized for computation-intensive tasks, which made signature verification the bottleneck in content processing. Equipping routers with Bloom Filters so that they perform mainly lookup operations and probabilistic signature verification (as proposed in access control models [30; 31]) could bypass signature verification for each Data packet by all routers (e.g., by storing the namespaces of identified attackers), but additional issues remain. Besides the excessive cost of signature verification, routers would need to fetch multiple public key certificates in order to trust the public key that verifies a content signature, which increases the overhead significantly. Furthermore, each content-producing NDN application can independently specify the trust model it utilizes. Therefore, there are diverse trust policies defined by different applications at the same time. This means that each router should know the specific trust schema used by each NDN application. Since there is a wide variety of applications in a network, this requirement entails considerable trust-related complexity for routers.