# A PEKS-Based NDN Strategy for Name Privacy
## 1 Introduction  
Today's Internet is growing incredibly year-by-year with big content providers. At the same time, people are trying to retrieve enormous online content from those providers. However, the current TCP/IP internet architecture based on end-to-end communication between two hosts becomes gradually insufficient [1]. In TCP/IP, Internet Protocol (IP) is the only protocol taking care of Network Layer, and it is known that it is not easy to add new functional components to the IP. Name Data Networking (NDN) [2], which is a branch of Information Centric Networking (ICN), has been proposed as a new Internet architecture for next-generation networks to address the existing problems of TCP/IP. Instead of using source and destination addresses, NDN identifies data content with a unique name that does not depend on the location. Security and strategy are added as two new features at the network layer in NDN architecture. These new features bring several benefits to NDN such as built-in data security and multipath forwarding. Furthermore, the in-network cache is used to store data packets for future retrieving [3, 4]. NDN names have a hierarchical human-readable structure and consist of several name components which are usually delimited by (\({}^{\prime}\)/) or (\({}^{\prime}\).) [5]. They are semantically related to content and can accordingly expose information about the content to an attacker who can then trace users' interests by examining names in their requests [6, 7]. Therefore, names should be protected to avoid these threats and to enhance users' privacy by ensuring that names in a packet reveal no information about the data inside the content object [8]. There are some proposed approaches for name privacy including an overlay-based network called Anonymous Named Data Networking Application (ANDANA) [9], and privacy-preserving content retrieval in information-centric networking (PrivICN) [7]. However, these approaches still have drawbacks. Due to data encryption, the caching mechanism cannot be fully used in AND\(\overline{\text{a}}\)NA. Proxy re-encryption is used in PrivICN to protect name privacy but this scheme is only designed for Intra-domain usage. Moreover, a pseudorandom function, which is common in PrivICN, is used by different content requesters to encrypt names. Consequently, if each of those content requesters encrypts the same plaintext name, generated encrypted names become the same. This fact allows attackers to identify multiple packets requesting the same content so that unlinkability between encrypted names is not guaranteed. The goal of our work is to protect names in NDN by applying \"public key encryption with keyword search (PEKS)\". Contributions of this paper are as follows:  
* It is ensured in our design that there exists unlinkability between encrypted names even though plaintext names are identical because random values chosen by content requesters are used in every encrypted names. * There is no master secret key in our work and key generation of private key does not depend on any master secret key. * Network nodes are able to check whether the data content is stored in the cache even though names are encrypted because the PEKS scheme provides searching encrypted name without revealing the plaintext information. Therefore, our work maintains cache ability on all routers in NDN network. We implement a new strategy, called PEKS-based NDN Strategy, based on Best Route Strategy and Multicast Strategy which are described in [10]. However, applying the PEKS scheme to NDN names occurs other issues. For example, string matching algorithms cannot be applied to lookup in tables, which cause a negative impact on computational efficiency. Other than this, there exist other efficiency problems such as packet size overhead and large table size because the encrypted names have a large and fixed length according to parameters of the PEKS scheme. Number of PEKS operations increases as the number of name components in a name, which results in a significant execution time overhead.