Group-Interest-Based Verifiable CCN

To solve various problems of the Internet, content centric networking (CCN), one of information centric networking architectures (ICN), provides both an in-network content caching scheme and a built-in content verification scheme. However, a user is still asked to generate many request messages when retrieving fragmented content through CCN. This model can seriously increase the amount of network traffic. Furthermore, when receiving content, a user is asked to verify the received content before using it. This verification process can cause a serious service delay. To improve such inefficiencies, this paper proposes a transmission process to handle request messages at one time. Also, it suggests an efficient content verification method using both hash chains and Merkel-hash tree.


Introduction
The Internet was originally designed to establish reliable connections between remotely located hosts [1].The initial designers of the Internet did not expect that the Internet would be utilized for various services/applications as now.Also, they did not consider various problems which are currently faced by the Internet: as various services/applications begin to utilize the Internet, the amount of network traffic rapidly increases, which leads to serious network congestion [2].For example, as mobile/smart consumer devices are popularized, it becomes trendy for users to actively generate/share content from their daily lives with others using their own mobile/smart devices.Also, the quality of shared content has become higher than that of the past [3].Furthermore, various IoT (Internet of Things) services like a vehicle communication system gather/provide massive amounts of information through the Internet [4].
Besides a network congestion problem, the weak security of the Internet is also a serious problem which should be improved [5,6].
To solve such problems of the Internet, various future Internet architectures/technologies like information centric networking architecture (ICN) are introduced [7].Specially, since ICN is focusing on contents itself, not on a host providing the content, ICN can make it possible that a user receives content from several possible hosts caching the content.So a user can access content through ICN more efficiently as well as more rapidly than through the Internet [8][9][10].
Content centric networking architecture (CCN) is one of ICN [11,12].CCN has several distinguishing characteristics as follows: (i) It is designed as a request-driven communication model.
(ii) It utilizes in-network caching functionality to enhance network efficiency.
(iii) It delivers network packets referring to a content identity, not to a device identity (e.g., IP/MAC address) so as to efficiently use cached content.
(iv) It provides a built-in content verification mechanism to authenticate both received content and the original publisher of the content.
However, such characteristics of CCN still cause network/computation inefficiencies.Actually, to distribute content through CCN, the content is fragmented into several segments with small size, and each segment of the content is handled as an independent data in CCN.Hence, when requesting the content, a user should generate a request 2 Mobile Information Systems message for each segment of the content.These request messages can increase the amount of network traffic so as to be misused by denial-of-service (DoS) attackers [13,14].
Furthermore, since CCN utilizes content cached in intermediated nodes, it is possible that a user receives content from unknown (malicious) nodes, not from the original publisher of the content.So CCN highly recommends that a user verifies received content before using the content.This content verification process could solve certain security problems of the Internet such as malware and man-in-themiddle attacks [15].However, since a user is asked to verify all segments of content, such a recursive verification process can cause long service delays [16,17].
Hence, utilizing CCN for various IT services like multimedia content distribution services as well as various IoT services, the transmission and computation overheads of CCN should be improved [18].Hence, this paper proposes a process to handle a set of serial request messages at one time to enhance the network efficiency of CCN as well as an improved content verification mechanism to reduce the service latency of CCN.

Content Centric Networking
To enhance network efficiency, CCN implements a contentcaching functionality on network nodes.Then if a node caching content receives a request packet (Interest) for the cached content, the node transmits the cached content as a response packet (data) to the sender of the Interest and then finishes forwarding the Interest.Hence, a user can receive the content more rapidly than when receiving the content from the original provider of the content.Also, since request messages that converged to the original provider of the content can be handled by intermediated nodes, CCN can solve a network congestion problem which can happen close to the content provider.
Also, to efficiently use the cached content, CCN utilizes the hierarchical identity of content as a packet forwarding address.Since this hierarchical identity of content should be uniquely defined in network, when receiving Interest, an intermediated node can search cached content in its storage (content store, CS) just analyzing the forwarding address of the Interest.The hierarchical identity of content is called a content name.
Figure 1 describes CCN process to handle Interest/data: (1) If a user generates/sends Interest for a segment of content (e.g., a.mpg), an intermediated node receives the Interest through its interface (e.g., Face 1).
(2) The node checks whether the requested segment has been cached in CS.If it has been, the node sends back the cached segment through Face 1 as data.Then the node completes the processing of the received Interest.
(3) If the requested segment is not cached in CS, the node checks its pending Interest table (PIT) to confirm whether it has already forwarded the same Interest.If the node did, since the content name of the Interest has been recorded in its PIT, the node can find an entry of PIT which is relevant to the Interest.In this case, the node just adds Face 1 on the found entry of PIT, and then stops handling the Interest.(4) If there is no found entry of PIT, the node compares the content name of the Interest with the entries of its forwarding information based (FIB) table using the longest prefix match in order to select a proper interface (e.g., Face 3) through which it will forward the Interest.
(5) The node records both the content name of the Interest and the incoming interface (Face 1) of the Interest on its PIT.(6) The node forwards the Interest through Face 3.
(7-8) When receiving data, the node checks whether there is an entry of PIT which is matched to the content name of the data.If there is no proper entry of PIT, the node discards the data and then stops handling the data.
(9-10) If there is a proper entry of PIT, the node saves the data in CS and then forwards the data through the faces of the found entry of PIT.Specially, if the node is an end-user's device, it should first check the validity of the data and then save the data in CS only if the data is valid.Finally, the node deletes the found entry of PIT.

Group-Interest Operation
As shown in Figure 1, to transmit content, it is first required to generate/send Interest.Specially, CCN asks a content publisher to fragment content into several segments with small size to distribute the content.Then CCN deals with each segment of the content as a single data.So, for receiving the content, a user should generate/send many Interests, even though the only difference of these Interests is just the number of segment.This requesting process may increase the amount of network traffic.Also, after receiving the  − 1th segment of content, a user can generate/transmit Interest for the th segment of the content.This linear process can lead to long content retrieval latency.
To improve such problems, we suggest a Group-Interest for requesting  serial segments at one time.Table 1 shows an Interest structure for a Group-Interest:  Also, it is necessary to modify the process of data in order to handle a Group-Interest.Specially, it is needed to prevent duplicated packet transmission.For that, Pseudocode 3 shows a modified process.The major differences of the modified data process are as follows: (i) If data is relevant to a Group-Interest and the same data has been forwarded already, a node does not forward the data again even though the relevant entry of PIT exists.
(ii) If data is relevant to a Group-Interest, relevant PIT entry is not instantly deleted from PIT.

Content Verification
In CCN, since a node can receive a segment of content from an anonymous network node caching the segment as well as from the original publisher of the segment, it is possible that malicious nodes send a forged segment.
Hence, a content verification process is one of the essential requirements of CCN.However, since a user should recursively verify each segment of content whenever the user receives the segment, this recursive verification process can cause another inefficiency of CCN.

MHT-Based Content Verification Scheme.
To efficiently verify both the segments of content as well as the original publisher of the content, CCN utilizes a Merkel-hash tree (MHT) [11,[19][20][21].Figure 2 shows an example of a MHTbased content verification scheme: assume that a contentpublisher fragments content into 7 segments { 2 , . . .,  8 } and then generates meta-data  1 describing the structure of the segments of the content.From now on, we assume that content consists of 8 segments including a metadata segment.
Step 1 (constructing MHT).A content-publisher builds a binary tree with 8 leaf nodes and then assigns { 1 , . . .,  7 ,  8 } to leaf nodes in numerical order.Then the publisher computes the hash value (  ) of each segment   using the one-way hash function .The publisher uses (  ) as the node value   of a leaf node   which is assigned to   .
Step 2 (computing node values).For each node   except for leaf nodes, the publisher computes a node value   = ( 2 ‖  2+1 ), where ‖ is a concatenation operation and   is the parent node of two child nodes,  2 and  2+1 .
Step 3 (signing a root node value).After computing all node values of the binary tree, the publisher signs a root node value  1 with its signature key SK to generate a signature value (sign).
Step 4 (generating a witness of a segment   ).For each segment   , let   s be the sibling nodes of the nodes on the path, from a leaf node assigned to   to the root node  1 .The publisher generates a witness   which consists of the node values,   s, of   s.For example, the  1 of  1 is { 9 ,  5 ,  3 } in Figure 2. The witness is needed to verify the sign.That is, using both   and   , any verifier can compute the same  1 and then verify the sign.
If a user receives   , the user recursively computes the necessary hash values using both   and   to compute the root node value,  1 .Then the user verifies the packaged sign using the computed  1 .In practice, after verifying the sign packaged in the first type of data,  1 , the user temporarily saves the computed  1 .Then, the user does not need to verify the sign again for verifying   ( > 1).Instead, it is sufficient that the user just compares the computed  1 with the previously saved  1 .Hence, it is possible to reduce the operation time of a segment verification process.
However, as shown in Figure 3, the operation delay of a MHT-based verification scheme is still a burden to CCN. Figure 3(a) shows the comparison result of response times when sharing 256 segments of content between two smart phones over WLAN using three different methods: (i) [No verification] is a case that a user does not verify received data at all.
(ii) [Sign] is a case that each data has a relevant signature value in order that any user receiving the data can instantly verify the data.
(iii) [MHT] is a case to verify data using MHT.
The result shows that a MHT-based verification scheme can reduce the response time needed to verify segments as compared with [Sign].That is, [MHT] is more efficient than [Sign] by about 75%.
However, as shown in Figure 3(b), the computation overhead of MHT has increased proportionally to the number of segments, that is, to the size of content.It means that a MHTbased verification process can still cause a serious service delay when distributing high-quality, large-size content.This overhead is due to the fact that the number of recursive hash operations of a MHT-based scheme increases.Hence, to improve the performance of the content verification process  of CCN, it is necessary to reduce the total number of hash operations needed to verify the segments of content.

Hash Chain Based MHT Verification.
To reduce an operation delay caused by the content verification process of CCN, in this section, it is proposed to combine MHT with a hash chain which is a general approach to reduce the amount of verification data.It is called a hash chain based MHT scheme (H-MHT).

Verifiable Data Generation.
As shown in Figure 4, H-MHT utilizes both MHT and hash value chains: let the number ( = 2  ) of the leaf nodes of MHT be 4. Let the number () of the segments of content be 14.That is, the content consists of 14 segments, { 1 , . . .,  14 } including a metadata segment.
Step 3 (constructing MHT).For each , it computes (  (,1) ) and then assigns the computed hash value to a leaf node of MHT as its node value in order.Also, it computes the witness   of   (,1) .Finally, it signs the  1 of MHT with its private key SK.Let the generated signature value be sign.
Step 4 (generating  () =  (,) ).For each  > 1, let sign () be the signature value of ( (,) ) generated with SK.The publisher generates  (,) which is data for delivering a segment  (,) as follows: The sign () attached to  (,) is an optional field considering packet loss situation.Hence, if packet loss rate is negligible or the impact of packet loss is not serious, sign () can be removed from  (,) .
If the two values are the same, the user regards  () as valid data.Then the user temporarily saves ( (+1) ) packaged in  () to verify the next data,  (+1) .
Case 3 ( > 1 but ( () ) has not been saved).(a) If  = 1, the user computes  1 using   and then compares the computed  1 with the previously saved  1 in Case 1.If the two values are equal, the user regards  (,1) as valid and then temporarily saves ( (+1) ) packaged in  () =  (,1) to verify the next data,  (+1) =  (,2) , if  () is not the final segment of content.

Group-Interest Performance.
To evaluate the transmission overheads of a Group-Interest, we assume the following: (i) There are 5 networks connected by 5 border gateways.
Each network has a binary tree-shaped network topology with depth 3 consisting of multiple CCN routers.Each end-user is initially placed and then is connected to CCN router, respectively.
(ii) During this simulation, a user utilizes only Group-Interests for requesting content and keeps trying to send Interests at a predefined sending rate.
Then we measure the total amount of transmitted Interest.Figure 5 shows two results.First, if a bundle size is 1, it means a Group-Interest is actually a general Interest.So when using a Group-Interest ( > 1), the transmission overheads of CCN can meaningfully be reduced.Second, the larger the size of the bundle of segments is, the more the transmission overheads of Interest are improved.That is, a Group-Interest is especially efficient when being applied to large size content.However, even if some segments requested by a Group-Interest have been responded, the Group-Interest is continuously forwarded until all requested segments are retrieved.Hence, when utilizing a Group-Interest with size m, transmission performance is not enhanced proportionally to m.

Content Verification Performance.
To analyze the performance of the proposed content verification scheme, we assume the configuration of simulation as described in the previous evaluation.Also, H-MHT and MHT use a binary tree with 8 and 64 leaf nodes, respectively.And we use general Interests, not Group-Interests.Then we measure the time for retrieving content.As shown in Figure 6, the response time is improved by about 20%.Also, we measure the computation overheads of computing hash values for verifying content.Figure 7 shows results considering the cases in which content is fragmented into 256, 1024, 4096, 16384, and 65536 segments, respectively.Then we measure the average time required to compute all hash values for verifying the content: (i) [MHT] shows the computation overhead of the case of bundle size 1.
(ii) [H-MHT-n] show the results of the cases of bundle size n.
As shown in Figure 7, the larger the bundle size is (as well as the more segments the content is fragmented into), the more efficient the communication overhead is. Figure 8 is the result of performance measurement of H-MHT considering different bundle sizes.For that, we assume that content is fragmented into 256, 1024, 4096, 16384, and 65536 segments.Let the number of segments be 2  .For each case, we consider the bundle size as 2 ×0.25 , 2 ×0.5 , and 2 ×0.75 , respectively.As shown in Figure 8, when using the case of a bundle size 2 ×0.5 , the computation efficiency of computing hash values is dramatically improved.But it becomes less effective when using larger bundle sizes than 2 ×0.5 .

Conclusion
This paper makes two main points to enhance the performance of CCN.First, since CCN is designed as a requestdriven communication model and utilizes fragmented content segments, when requesting content, a user should generate a number of similar Interests to retrieve the content.Using a Group-Interest, it is possible to reduce transmission overheads for forwarding Interests.
Second, an enhanced content verification process is proposed to reduce service latency due to the content verification process of CCN.For that, it is proposed to utilize hash chains.However, when applying a hash chain, it should be considered how to handle packet loss situation.So we also use both MHT and the signature of each segment.Combining MHT to hash chains, it is possible to reduce the computation overheads of a content verification process as well as to limit the effect of packet loss situation.Also, the proposed scheme is designed as being suitable for a Group-Interest.The proposed scheme can provide improved service scalability and low computation costs by reducing the number of hash operations.
These features are important in mobile consumer environments since most mobile consumer devices inherently have limited resource capability.Specially, since various IoT services utilize thin devices like a sensor, these features are meaningful to such services.

Figure 1 :
Figure 1: CCN forwarding model using Interest and data.

Figure 2 :Figure 3 :
Figure 2: MHT-based contents verification: each CCN data contains a segment, a relevant witness, and a signature.

Figure 6 :Figure 7 :
Figure 6: A comparison of response times to share a content fragmented into 256 segments between two smart phones.

Figure 8 :
Figure 8: The computation overhead considering different bundle sizes.

Table 1 :
The structure of a (Group-) Interest.

Table 2 :
The structure of PIT to handle a (Group-) Interest.To handle a Group-Interest, it is necessary to modify the structure of PIT entry as shown in Table 2: [Flag], [Flag], and [Flag] are added.(i) [Falg] describes whether this PIT entry is relevant to a Group-Interest or not.If Flag = 0, this PIT entry is for a general Interest.In this case, both Flag and Flag are unmeaning.Otherwise, it means that this PIT entry is relevant to a Group-Interest.Specifically, the value of Flag is the number of the first segment of the Group-Interest.Since the proposed process of Interest as shown in Pseudocode 1 can handle a Group-Interest as well as a general Interest, a user can selectively generate either a general Interest or a Group-Interest considering response status.That is, after receiving some data packets relevant to a Group-Interest, to request remaining data again, a user can selectively generate either a general Interest or a Group-Interest.
requests serial segments with identities from Seg to Seg + Seg − 1.If Seg = 1, this Interest is a general Interest, not a Group-Interest.(ii)[Seg]isthetotalnumber of segments which consists of the requested content.This field is used for verifying Seg.That is, if Seg + Seg − 1 > Seg, Seg is invalid.(ii)[Flag] is the number of segments which the Group-Interest requires.This field can be used to delete entry of PIT.(iii) [Flag] describes whether the relevant data has been received or not.If Flag = 1, it means that the data Interest Operation Code Input: Interest, Face Output: void delete expired entries of PIT; // call DeleteEntryOfPIT( ); set -Flag = 0; // forwardingFlag for each index  from Seg to Seg + Seg −1 { generate Interest[] such that Interest[].name==Interest.nameandInterest[].Seg== Interest.Seg;find an entry ([]) of PIT relevant to Interest[]; if there is no, add a new entry to its PIT for Interest[]; else { if Face isn't in [].face,add Face to [].face;if [].Flag> 0 and [].Flag== 1, set [].Flag = 0; else stop handling Interest[]; } find an entry ([]) of CS relevant to Interest[] if there is [], then { transmit [] through [].face;if [].Flag== 1, then set [].Flag = 1.else delete [] from PIT; // general Interest } else set -Flag = 1; if [].Flag> 0 and [].Flag== 0, set -Flag = 1;Pseudocodes 1 and 2 are pseudocodes describing how to handle both a general Interest and a Group-Interest.As described in Pseudocode 1, the major differences between the eral Interests.These Interests are, respectively, corresponding to serial segments requested by the Group-Interest.These disassembled Interests are only internally used for managing PIT.That is, when handling PIT, a node uses these disassembled Interests, not the original Group-Interest.(ii)Eachentry of PIT generated from a Group-Interest is deleted when either the entry has expired or after all segments requested by the Group-Interest have been forwarded to requestors.(iii)A Group-Interest is forwarded until all segments requested by the Group-Interest have been transmitted to requestors.