Abstract
Content-Centric Networking (CCN) is considered as a promising alternative to traditional IP-based networking for vehicle-to-everything communication environments. In general, CCN packets must be fragmented and reassembled based on the Maximum Transmission Unit (MTU) size of the content delivery path. It is thus challenging to securely protect fragmented packets against attackers who intentionally inject malicious fragments to disrupt normal services on CCN-based vehicular networks. This paper presents a new secure content fragmentation method that is resistant to Denial-of-Service (DoS) attacks in CCN-based vehicular networks. Our approach guarantees the authenticity of each fragment through the immediate fragment verification at interim nodes on the routing path. Our experiment results demonstrate that the proposed approach provides much stronger security than the existing approach named FIGOA, without imposing a significant overhead in the process. The proposed method achieves a high immediate verification probability of 98.2% on average, which is 52% higher than that of FIGOA, while requiring only 14% more fragments than FIGOA.
1. Introduction
Smart transportation based on vehicle-to-everything (V2X) communications is considered as a promising technology due to its potential to provide intelligent services for driving safety and efficiency. Due to the limitation of traditional IP-based networking in vehicular network environments, the transition to a new network paradigm is being discussed. As one of these research directions, several previous studies have proposed various possible Content-Centric Networking (CCN) architectures for V2X communication environments [1–3].
CCN [4] was originally proposed as a future Internet architecture that provides named data, name-based request and routing, and in-network data caching. Those characteristics seem to be well suited to V2X communications that require high mobility and intermittent connectivity of vehicles. In other words, CCN allows a vehicle to retrieve interested data from any nearby entities even though the vehicle has no connectivity with the original data publisher. Because V2X communication systems are generally designed for the vehicle and pedestrian communication to guarantee the safety of people, establishing secure communication between network entities has naturally become the most critical issue for V2X communications.
In this paper, we particularly focus on the problem to provide the authenticity of packet fragments in CCN. To apply the CCN architecture to V2X communication services, it is important to mitigate various network attacks. For example, an attacker can generate a massive amount of fake fragments [5] to disrupt normal services on V2X communication. A possible solution for checking the authenticity of incoming fragments is to use a digital signature system. CCN already mandates that every content be digitally signed by its publisher, and this allows a receiving node to verify the authenticity of the received content through the signature verification. However, each content packet in CCN can be fragmented according to the Maximum Transmission Unit (MTU) size of the data delivery path. Therefore, checking the authenticity of incoming fragments at the content level is not efficient because this process typically incurs a significant delay to collect necessary fragments and reassemble them. These delays are even accumulated at every hop on the routing path. A better option that avoids such latency is fragment-based authentication rather than content-based one, so that each fragment whose authenticity has been confirmed can efficiently be propagated to the next hop without waiting for the remaining fragments.
FIGOA [5] is a recent approach to fragment-based authentication in CCN that integrates a one-way hash chain and signature. However, due to the use of one-way hash chain, any single fragment loss results in that none of the subsequent fragments on the hash chain can be verified immediately upon receipt. Consequently, propagation delays can be significant with unverifiable fragments for some V2X applications requiring timely delivery of data packets (e.g., the message for a fatal road accident). To prevent such authentication delays from leading to propagation delays, FIGOA takes a strategy of just forwarding fragments whose authenticity has not been confirmed yet. Unfortunately, this opens the door to DoS attacks to exhaust the fragment buffers of network nodes (e.g., vehicles and roadside units) by intentionally introducing a massive amount of immediately unverifiable fake fragments. Furthermore, CCN-based vehicular networking typically requires network nodes to cache and forward overheard unsolicited data as well as solicited data to facilitate data discovery and delivery under the mobility of vehicles [6–10], and this feature even increases the impact of such DoS attacks. To make matters worse, such flooding of fragments also makes it infeasible to identify the origin of the attack.
Figure 1 illustrates the DoS attack against FIGOA in the CCN-based vehicular network. The adversary who overhears the interest messages requesting the contents (e.g., and ) injects a massive amount of immediately unverifiable fake fragments of the requested contents. According to the optimistic forwarding of FIGOA, the unverified fake fragments are propagated over the vehicles and used to consume the fragment buffers of the vehicles. As particularly illustrated with in Figure 1, the unverified fragments broadcast by affect all the remaining nodes within ’s signal range as well as and that requested the contents.
In this paper, we present the design and analysis of an efficient, secure, and DoS-resilient fragment authentication technique for CCN-based vehicular networks. The proposed technique not only guarantees the authenticity of fragments but also provides resistance to DoS attacks exploiting authentication delays. Our key contribution is to propose a novel hash tree construction, which seamlessly integrates an erasure code (for forward error correction) into a hash tree. The proposed hash tree achieves a high immediate verification probability for each fragment upon receipt. Specifically, our analysis results demonstrate that our approach achieves a high immediate verification probability of 98.2% on average over all the test cases, which is 52% higher than that of FIGOA, while requiring 14% more fragments than FIGOA.
As another layer of protection against DoS attacks, we have devised an adaptive forwarding strategy for fragments whose authenticity cannot be confirmed immediately upon receipt. By adaptively adjusting the probability of forwarding such fragments according to the recently observed ratio of authentic/inauthentic fragments, it allows the rapid propagation of legal fragments in benign environments, while effectively filtering out illegal fragments in hostile environments.
The rest of this paper is organized as follows. Section 2 provides some preliminary information on CCN, hash tree, and Rabin’s Information Dispersal Algorithm. Section 3 presents the proposed techniques for secure and DoS-resilient fragment authentication and delivery. Section 4 describes the analysis results of the security and efficiency of the proposed approach. Section 5 overviews related work, and Section 6 concludes this paper.
2. Background
2.1. Overview of CCN
Every CCN packet contains a content name instead of a host identifier. In particular, a user requests a content by issuing an interest that contains the name of the content. Each CCN node performs content name-based routing for this interest, so that it can be delivered to the corresponding content publisher. Upon receiving the interest, the publisher replies back with the requested content, and the content is delivered to the user by following the reverse path of the interest via the CCN’s routing mechanism. During delivery, the content is fragmented according to the MTU size of the network link. In addition, each CCN node performs in-network caching to reduce redundant data transmissions and latency. To enable the user to confirm the authenticity of a received content, every content is appended with the publisher’s digital signature.
2.2. Hash Tree
We adopt the general scheme of a hash tree described in [11]. A hash tree is constructed over multiple pieces of data to be authenticated, where a leaf node in the tree holds each data piece. Each internal node stores a set of hash values, each of which is the result of applying a collision-resistant hash function (e.g., SHA-256) to the value(s) stored at each of its child nodes. The hash value at the root node is signed using a digital signature algorithm such as RSA, DSA, or ECDSA. Figure 2 presents an example of a hash tree to authenticate eight data pieces, ~. We assume that each internal node in this tree can have up to four hash values or a single digital signature along with a hash value. We refer to the path from each node up to the root node as its authentication path. In Figure 2, for example, the authentication path of consists of , , , and . Given all the nodes over an authentication path, it is possible to verify their authenticity by performing signature verification on the root node and repeatedly computing and comparing hash values along the authentication path. When a piece of data corresponding to a leaf node (i.e., ~) is modified, the hash values stored at its ancestor nodes, including the root node, are all changed. Moreover, due to the collision-resistance of the hash function, it is not feasible to modify any piece of data without the sign key. Thus, all of the data pieces are authenticated with just a single signature (SIG).
2.3. Information Dispersal Algorithm
We use Rabin’s Information Dispersal Algorithm (IDA) [12] to enable the loss-resilient recovery of the hash values stored at internal nodes in a hash tree. Rabin’s IDA is a type of erasure code and consists of two operations: and . For a given chunk consisting of equal-length blocks, generates encoded blocks , each of which has the same length as an input block. Given any out of encoded blocks, reconstructs the original . Thus, up to block losses can be tolerated by using IDA. We refer to the ratio as the redundancy rate of IDA.
3. Our Approach
This section presents the proposed techniques for achieving secure and DoS-resilient fragment authentication in CCN. The key contribution is to apply the systematic IDA into a hash tree so that the system becomes more resilient to time delays and packet losses. In the existing hash tree structure described in Section 2.2, missing any internal node disables immediate verification of its child nodes upon receipt due to the loss of the hash values of the child nodes. To address this problem, we apply IDA for the hash values at each height of the hash tree, and this enables immediate verification of child nodes upon receipt even under a certain degree of losses by recovering missing hash values in a prompt manner. Moreover, the systematic property allows the hash values included in the internal nodes to directly appear in the encoded results generated by the dispersal operation. Thus if some of the hash values are received correctly, then we do not need to perform the recovery operation for the received hash values. This technique can significantly reduce the computation cost at receivers. In addition, receiving some of the hash values at height allows us to immediately verify the corresponding child nodes at height upon receipt without waiting for nodes at height to be received. This increases the chance of immediate verification in out-of-order delivery situations.
Notations summarizes the notations that will be used in the remainder of this paper.
3.1. Content Fragmentation and Authentication
Given a content object () to be transmitted, we first divide it into equal-sized fragments. For the fragment size , we typically use the MTU size of the routing path via which will be delivered or if available the globally smallest MTU. Next, we construct a -nary hash tree over the fragments of as described in Section 2.2. Each node in the hash tree corresponds to one fragment, and so we will use the terms “node” and “fragment” interchangeably hereafter. The hash tree illustrated in Figure 2 represents the case that consists of eight fragments, denoted as ~, and each internal node can have up to four children’s hash values ().
Unfortunately, in such a hash tree structure, any missing internal fragment results in the failure to construct the authentication path of all its child fragments. Thus, it becomes infeasible to immediately verify those child fragments upon receipt. To solve this problem, we integrate Rabin’s IDA into the hash tree construction to add some extra redundant fragments to the internal fragments at each height of the tree, ensuring that we can tolerate up to a certain degree of fragment losses.
Systematic IDA. Directly applying Rabin’s IDA is not efficient due to the mandatory requirement of the recovery procedure. In other words, a receiver must always perform the recovery procedure in order to recover the original data from the received or more packets. We propose customizing IDA such that the original data directly appears on the encoded blocks. As a result, it is possible to skip the recovery procedure as long as all of the original data blocks are given correctly. In other words, a receiver performs the recovery procedure only when some original data blocks are lost. Such a coding scheme that includes the original input in the encoded output is called systematic code. Thus, we refer to the two procedures of our customized IDA as SystematicDispersal and SystematicRecovery, respectively, in the remainder of this paper.
To achieve the above property, we adopt Vandermonde matrix [13] as the encoding matrix of IDA. Let be a Vandermonde matrix (), where and all ’s are nonzero elements of a finite field such as . has the following properties [13]:(i)Any rows out of rows in are linearly independent.(ii)Even if any rows in are substituted with the rows of an identity matrix, the modified matrix still has the above property.
Let be a chunk of bytes, where represents the th byte in (). For simplicity, we assume that is a multiple of , and all computations in our customized IDA are performed in .
To customize IDA into a systematic code, we have to properly arrange the input data, so that the input data directly appears as the first encoded blocks. This leads to the customized encoding procedure :(1)The input is grouped into blocks of bytes: , , and then it is arranged in an matrix as follows: Each row of corresponds to each block of bytes in .(2)Select the following Vandermonde matrix for encoding: where ’s () are different nonzero elements of .(3)Encode into blocks (rows) () as follows: where . Each row of the resulting matrix corresponds to one encoded block. Therefore, the original is directly included in the first encoded blocks. We refer to the first blocks and the remaining blocks as original and redundant blocks, respectively.
Given any encoded blocks (), we can perform to reconstruct any missing original data block(s):(1)Let be the matrix composed of the row vectors in which are used to generate the given encoded blocks (step 2 in ). is invertible because of the linear independence condition on . Compute .(2)Recover the original data using the given encoded blocks and as follows:
The systematic IDA allows us to tolerate up to original data block losses, and at the same time if all of the first blocks are received correctly, the recovery procedure is no longer required. Moreover, if a network node receives some original data blocks correctly, it does not need to compute the corresponding rows in (in step 2 of ). This significantly reduces the computational cost at each receiver.
Figure 3 illustrates an example application of the systematic IDA to the given data that is composed of four data blocks. Calling generates the total of six encoded blocks: four original blocks ~ and two redundant blocks and . Even though two original blocks and are lost in transmission, they can be recovered from the four received encoded blocks by calling .
Construction of Content Fragments. Now, we present the process to construct the proposed hash tree for a given , which is described in Algorithm 1. Figure 4 shows an example of the proposed hash tree constructed over which is composed of eight fragments. When IDA is not applied at height (in lines – in Algorithm 1), (e.g., in Figure 4), and fragments are constructed by splitting . In line , we compute the hash values of each fragment, respectively, at height , and concatenate them together to produce (i.e., ). For simplicity, we assume that is a multiple of . Then directly becomes ~ at the upper height , where . Next, we generate additional redundant fragments ~ at height by calling in line . In Figure 4, for example, , and calling additionally generates and at height 1. The recovery of any missing original fragment (e.g., either or ) is possible with any two fragments among ~. That is, we can tolerate up to two fragment losses. We repeat the same process for each height of the tree until the tree converges into a single node/fragment at a certain height (e.g., at height 2). We compute the hash value of that single fragment and its signature, and these finally form the root (e.g., ) of the tree (in line ).
| ||||||||||||||||||||||||||||||||||||
3.2. Transmitting and Verifying Fragments
Immediate verification of received fragments is an important capability for mitigating DoS attacks. To achieve this, ancestors in the hash tree must be received earlier than their children. One possible way to achieve this goal is to enable the sender to transmit the fragments at each height only after it confirms that the receiver has received a sufficient number (≥mi) of fragments at every upper height to recover the hash values there. In other words, the sender should wait for the acknowledgment of height from the receiver before transmitting the fragments at the lower height . However, this approach may introduce some overheads (e.g., latency and message transmission) caused by the introduction of height-by-height acknowledgments.
In CCN, every fragment of the same content is labeled with the same content name, and this increases the chance that the fragments of the same content are delivered through the same routing path [14]. In consequence, these fragments are likely to arrive in the same order as transmission. To leverage this property, we transmit the fragments at height earlier than those at height , and for the same height we transmit to in a sequential order. This transmission method increases the chance of immediate verification of fragments upon receipt. In addition, the use of IDA in our approach further increases the probability of immediate verification, even with the occurrence of fragment losses. Moreover, taking advantage of the systematic property of our customized IDA, as soon as receiving an original fragment with its hash value, it is possible to immediately verify any child fragments of the received fragment without performing the recovery procedure. This is also of benefit to increase the chance of immediate verification in out-of-order delivery situations.
The root and its only child fragments (e.g., and ) in the hash tree are critical points of failure, because missing any of these disables the immediate verification of all the remaining fragments. To make these resistant against fragment loss, we transmit extra redundant copies for each of them. This can tolerate up to a fragment loss rate of .
Now, we describe the procedures to verify and forward received fragments. Notations summarizes the descriptions of , , and . For each incoming fragment , we first check if it contains a signature. If so, we verify the fragment through signature verification and append it to only if it is valid. If contains no signature, then we check if its parent fragment is already in . In that case, we compute the hash value of and compare it with the one stored at the parent fragment; in . If both hash values are the same, then we append to . After adding each fragment to , we also forward it to the next hop, while dropping all inauthentic fragments without forwarding and buffering. If the parent fragment of is not in , cannot be verified right away. We refer to this kind of fragments as unverifiable fragments and will discuss how to handle unverifiable fragments later in this section.
If and some of ~ are missing, then we perform to recover those that are missing. After these are recovered, we also append them to . In addition, if some of ~ are missing, then we also regenerate the missing redundant fragments for further forwarding by performing .
In Figure 4, for example, let us assume that has arrived and . In that case, it is possible to immediately verify by computing its hash value and comparing it with in . In addition, if only and are in , then we can recover by calling . Now, we are ready to immediately verify any of ~ upon receipt.
Even though the proposed method increases the chance for immediate verification of fragments, unverifiable fragments can still occur in the proposed method. That is, incoming fragments can be categorized into the three groups (authentic, inauthentic, or unverifiable). To reduce the delay in processing unverifiable fragments, we proposed a strategy to make an adaptive decision on whether or not to buffer and/or further forward received unverifiable fragments based on the statistics of the authenticity of other recently received fragments.
For this strategy to work in practice, we count the numbers (, , and defined in Notations) of authentic, inauthentic, and unverifiable fragments, respectively, received within a specified time interval. With the probability of , we forward the received unverifiable fragment to the next hop and then buffer it to . In contrast, with the probability of , we discard it without forwarding and buffering. Finally, with the probability of , we only buffer it to without forwarding. The principle behind this strategy is that, in benign environments, where almost every fragment is authentic, incoming unverifiable fragments are also highly likely to be authentic. Thus, it is reasonable to forward them rather than dropping them to avoid undesirable retransmissions and propagation delays. On the other hand, in hostile environments, unverifiable fragments are likely to be malicious, and so they should be filtered out with a high chance to prevent malicious fragments from being propagated over the network.
In order for the fragments in to eventually be verified, whenever a new fragment is added to , we check if any of its child fragments is in . If this is the case, we try to verify their authenticity recursively along the authentication path.
3.3. Adjusting Fragment Size
In CCN, the fragments of some content stored in the intermediate node’s cache could be possibly delivered through a routing path whose MTU size does not match the fragment size. Let and denote the original fragment size and the new fragment size for the new routing path, respectively. In the case that , if , we could construct a larger fragment by merging adjacent fragments at the same height of the hash tree. To support the case that , the one-way hash chain-based approach of FIGOA [5] can be integrated into our hash tree as follows: each fragment in our hash tree is further split into multiple smaller fragments, and a one-way hash chain is constructed over the smaller fragments as in FIGOA.
4. Analysis
In this section, we analyze the security and efficiency of the proposed approach and compare the results with FIGOA. We use the same notations as in Notations.
Communication Overhead. To investigate the communication overhead introduced by using the systematic IDA and the hash tree, we analyze the total number of fragments generated from the proposed hash tree for a given content.
Theorem 1. Given a content object (), the total number of fragments generated from the proposed hash tree is (see Notations for the meanings of , , , , , and ).
Proof. For height , . For each height from 1 to , and ; the term is required to ensure that the hash tree eventually converges to the single root node. For both heights and , and . In consequence, the total number of fragments generated from our hash tree is .
Computation Overhead. We analyze the computation cost required to verify a content object. For the entire hash tree constructed over the content object, a single signature verification is required to verify the root fragment. For all the remaining fragments, a single hash operation is required to verify each of them. Thus, at most, hash operations are required in total.
Consider the computation cost to recover missing fragments. Recovery operations may be required for each height from to of the hash tree. Let denote the number of missing original fragments at height . Recovering fragments first requires a single matrix inversion operation that costs [13]. Next, the cost to reconstruct fragments is , and this cost typically dominates the cost of matrix inversion because the single matrix inversion cost is amortized over fragments [13]. depends on network condition, and when the packet loss rate is , in the average case, and in the worst case. As a result, the cost of recovery operations is determined by . In our experiments shown in Figure 5, for example, over all the test cases, and the cost of recovery operations is low for such small values of .
(a) Varying content sizes with the fixed fragment size of 1500 bytes
(b) Varying fragment sizes with the fixed content size of 16K bytes
Immediate Verification Probability. Immediate verification of received fragments can mitigate DoS attacks. Thus, in the following, we analyze the probability that each fragment in the proposed hash tree can be verified immediately upon receipt. Let denote the probability that any fragment is received correctly without any error or loss.
Theorem 2. Upon receiving a fragment at height (), the probability that is immediately verifiable is for , and (see Notations for the meanings of , , , and ).
Proof. In order for to be immediately verifiable, at least one of the following two conditions should be satisfied for every height on the authentication path from the node corresponding to to the root:(i)The fragment at height has been received correctly.(ii)Otherwise, at least out of the remaining fragments have been received correctly.The probability that at least one of the above two conditions is satisfied for height is . Therefore, the probability that is immediately verifiable upon receipt is .
Theorem 3. The expected probability that any fragment in the proposed hash tree is immediately verifiable upon receipt is (see Notations for the meanings of , , and ).
Proof. Let be a random variable representing the probability that each fragment from the proposed hash tree is immediately verifiable upon receipt. Then, the set of all possible values that can take is . The probability is . Therefore, the expected probability that any fragment in the proposed hash tree is immediately verifiable upon receipt is .
Based on the derived formulas, we compared our approach with FIGOA in terms of the number of fragments and the immediate verification probability. Figures 5(a) and 5(b) show the results when varying the content size, fragment size, and fragment loss rate, respectively. To investigate the impact of the fragment loss rate, we used four different loss rates: (2%), 0.04 (4%), 0.08 (8%), and 0.16 (16%). We set and for all of the test cases. To summarize the results, our approach provides a 52% higher immediate verification probability than FIGOA on average, while requiring 14% more fragments. Moreover, our approach achieved a high average immediate verification probability of 98.2% over all the test cases.
Effects of Buffer Replacement Policies. Because receivers have a fragment buffer of limited size, buffer replacement policies may affect the performance. The following are buffer replacement policies when has been received under the condition that no empty slot is available in the buffer. We try to find a slot to replace with in the following order of the policies described below:(i)Replacing unnecessary fragments (RUNF): if we have all original fragments (~) for any height , then we no longer need to keep any redundant fragment (~) of height . In addition, any fragment at upper heights (>k) is no longer required because we have finished using the hash values included in those fragments. Thus we replace such a fragment in the buffer with (ii)Replacing unverified fragments (RUVF): if any unverified fragment exists in the buffer, we replace it with because it can sometimes be inauthentic one.(iii)Replacing fragments that will be less utilized (RFLU): if we fail to find any slot by following RUNF and RUVF, then we prefer to pick any slot with a fragment that belongs to any lower height (<i) but is not a descendant of . If there is no such a slot, then we search for fragments at the same height as in the buffer, pick the one with the largest number of child fragments that have been received, and replace it with .
To investigate the impact of the above policies on immediate verification of fragments, we performed simulation studies of the following four strategies. In strategy 1, we applied all three policies (RUNF, RUVF, and RFLU) sequentially. In strategy 2, we applied the first two policies (RUNF and RFLU) only; if there is no buffer slot that is empty or occupied with unverified fragments, we pick a random slot and replace it with . In strategy 3, we applied RUNF only; if there is no buffer slot that is empty or occupied with unverified fragments, we pick a random slot and replace it with . In strategy 4, we did not apply any policies and pick a random slot and replace it with .
Figure 6 shows the simulation results. The -axis shows the size of buffer, and the -axis shows the ratio of the number of immediately verified fragments to the total number of received fragments. We used the following parameter settings: K bytes, bytes, , , and . To investigate the impact of buffer size, we used four different buffer sizes: , , , and . Note that is the minimum required buffer size according to RUNF. Among the four strategies, strategies 1, 2, and 3 (about 0.94) outperformed strategy 4 (about 0.91). Hence, it is our recommendation to use strategy 3 (RUNF only) because it can simplify the process of buffer replacement. Interestingly, as shown in Figure 6, the buffer size made little impact on the ratio of immediately verified fragments when the buffer size is sufficiently large (at least ).
Resistance to DoS Attacks. Now we discuss the DoS resistance of our approach. The only strategy DoS attackers can take against our adaptive fragment forwarding mechanism is to inject a large number of immediately unverifiable fake fragments, hoping that they will be propagated over the network. Suppose that the victim node receives an unverifiable fake fragment from the attacker. According to our adaptive forwarding strategy, the fake fragment can be forwarded to the next node with a probability of . However, as the victim continuously receives such unverifiable fake fragments in the DoS attack situation, the value for the victim increases, and this leads to a decrease in the value of . That is, the probability that fake fragments can be propagated decreases. As a result, it is impossible for the attacker’s fake fragments to be continuously forwarded to the next node. As an additional countermeasure, we can monitor the ratio of immediately unverifiable fragments received from each neighbor. If for any neighbor node the ratio is lower than the expected immediate verification probability, then we can suspect the neighbor to be abnormal.
Authenticity of Fragments. For a computationally bounded adversary running in a polynomial time, it is infeasible to generate fragments that can pass the verification process of our approach. The adversary could try to construct a hash tree over his own forged content and then digitally sign the hash value associated with the root node, pretending to be a trusted content publisher. Without the knowledge of the trusted publisher’s private key, however, it is computationally infeasible to forge the trusted publisher’s signature if we use a secure digital signature algorithm (e.g., RSA and ECDSA).
As an alternative strategy, given a fragment of a valid content object from a trusted source, the attacker may attempt to find that satisfies . As long as the attacker finds such , it will pass our verification process while being misidentified as a fragment of the given content from the trusted source. However, since the cryptographic hash function used (e.g., SHA-2) is (weak) collision-resistant, it is also computationally infeasible to find such different from .
5. Related Work
There exist a number of studies on CCN-based vehicular networking. Several data naming approaches were developed for efficient data management and retrieval in CCN-based vehicular networks (e.g., [2, 6, 8, 15]). In particular, the authors in [6] proposed a naming scheme to describe a valid spatial and temporal scope of a given content. The authors in [15] proposed another naming scheme to indicate the popularity and cacheability properties of a given content. The authors in [8] developed a hybrid naming scheme that integrates hierarchical and flat naming.
CCN-based vehicular networking typically adopts interest and content flooding to enable fast content discovery, and thus it is critical to reduce the overhead introduced by flooding. In [10, 16], the authors proposed selective flooding approaches such that an intermediate node determines whether or not it floods the received interest according to its knowledge of any node having the requested content or the distance from itself to the known content provider. Several papers discussed randomizing and suppressing transmissions of interest and content messages to avoid potential collisions in shared wireless medium (e.g., [3, 9, 10, 16]). The authors in [7] suggested using cellular network for CCN signaling and short-range communication for content distribution, when multiple radio interfaces are available on network nodes.
Several other groups of researchers developed in-network caching and forwarding algorithms of contents, which are optimized for vehicular network environments (e.g., [6–10]). The key idea common to all these approaches is caching and forwarding overheard unsolicited contents as well as solicited contents in order to maximize the effectiveness of overhearing in wireless communication. In [6], based on the proposed naming scheme that represents a valid spatial and temporal scope of a content, the authors proposed an approach to selectively cache the contents within valid spatial and temporal ranges.
It is also crucial to protect CCN from malicious attacks. In particular, several groups of researchers proposed techniques to deal with illegal contents in CCN environments. In [17, 18], the authors developed a naming scheme to include the hash value of a content in the content name, so that an intermediate node can identify an invalid content by comparing the hash value of the received content with the hash value in the requested content name. In [19, 20], the hash value of the public key of a content publisher is included in an interest message in order for the receiver to check that the received content is from the actual owner of the public key. Several approaches were developed to take advantage of users’ feedback of data authenticity in order to filter out invalid contents (e.g., [18, 21, 22]).
Several other approaches were developed to protect in-network caches from malicious attacks. In [23], an intermediate node probabilistically selects some of the received contents, verifies the selected contents, and caches only the correct contents. In [24], the authors proposed selective caching of contents according to their popularity in order to prevent cache pollution attacks that aim to intentionally replace popular contents currently stored in the caches with unpopular contents to degrade the effectiveness of in-network caching. In [25], the authors proposed a method to identify cache pollution attacks by analyzing incoming interests.
Finally, we provide an overview of erasure codes. There are two categories of erasure codes: fixed rate and rateless. Given original data blocks, a fixed rate erasure code generates a limited number () of encoded blocks, where should be determined prior to encoding, and the recovery of the original data blocks is guaranteed if a certain number () of encoded blocks are given. Besides Rabin’s IDA [12], Reed-Solomon code [26], Low-Density Parity-Check code [27], and Tornado code [28] belong to this category. On the other hand, a rateless erasure code can generate a potentially unlimited number of encoded blocks on demand, and if a certain number of encoded blocks are given, the original data blocks can be recovered with a certain probability, where the probability increases as the number of given encoded blocks increases. Luby Transform code [29] and Raptor code [30] are examples of rateless erasure codes.
In our approach, we used Rabin’s IDA because of the following requirements. Our approach requires that generating all the encoded fragments in the proposed hash tree should be completed before the content publisher signs the root node of the hash tree in order to accommodate the immediate verification of encoded fragments. In addition, the recovery of any missing original fragment at any height of the hash tree should be guaranteed if at least encoded fragments out of the total of fragments are received. Rabin’s IDA meets these two requirements.
6. Conclusion
In this paper, we presented the design and analysis of a secure and DoS-resilient fragment authentication technique for CCN-based vehicular networks. Our approach not only guarantees the authenticity of fragments but also provides high resistance to DoS attacks through the immediate verification of incoming fragments and the adaptive forwarding strategy for immediately unverifiable fragments. The results of our analysis showed that the proposed approach provides much stronger security than FIGOA without imposing a significant overhead. Specifically, our approach achieves a high immediate verification probability of 98.2% on average over all the test cases in the experiments. In comparison with FIGOA, our approach also achieves on average 52% higher immediate verification probability, while requiring 14% more fragments than FIGOA.
Notations
| Content object to be fragmented and authenticated | |
| Height and degree, respectively, of a hash tree | |
| The th fragment at height of a hash tree | |
| Number of original fragments at height before applying IDA | |
| Number of encoded fragments at height after applying IDA to original fragments () | |
| Redundancy rate of IDA | |
| Total number of fragments generated from a hash tree | |
| Size of each fragment | |
| Cryptographic hash function (e.g., SHA-256) | |
| Digital signature of an input hash value | |
| Concatenation of and | |
| Size of in bytes | |
| Equal to | |
| Buffer to store received fragments | |
| Set of authentic fragments in | |
| Set of height fragments in | |
| Set of unverifiable fragments in whose authenticity cannot be verified immediately upon receipt | |
| Respective numbers of authentic, inauthentic, and unverifiable fragments received for a period of time | |
| Fragment loss rate. |
Conflicts of Interest
The authors declare that they have no conflicts of interest.
Acknowledgments
This research was supported by Basic Science Research Program through the National Research Foundation of Korea (NRF) funded by the Ministry of Education (NRF-2016R1A6A3A11930593) and by the MSIT (Ministry of Science and ICT), Korea, under the ITRC (Information Technology Research Center) support program (IITP-2017-2015-0-00403) supervised by the IITP (Institute for Information & communications Technology Promotion).