# A Trusted Lightweight Communication Strategy for Flying Named Data Networking
## 2 Background and Related Works
### Components of Vanilla NDN  
Communication in vanilla NDN involves two types of packets (i) Interest packet that requests the content from the network and contains the name of the requested content. Interest packet consists of various fields such as Name, Nonce, Selectors, InterestLifeTime, and ForwardingHint. Name and Nonce are mandatory fields in an interest packet, whereas the rest of the fields are optional. Selectors are used to find the best match among the available data with the requested data in the interest. Finally, the lifetime and the forwarding hint are additional optional information provided by the requester. (ii) Data packet is a reply to the interest packet containing the actual requested content. Unlike the interest packet that explores the network looking for the desired content using a given forwarding strategy, the data packet is returned in a unicast manner and the data owner has to sign every single packet to prove the authenticity of the data [26].  
Every node in the vanilla NDN (a specific implementation of NDN) maintains the following three data structures:  
* Content Store (CS): Every node maintains a local cache memory to store the received content from other nodes. This node may be the requester or the intermediate relayer along the path. With CS, the local availability of content guarantees increased performance and reduces the delay.
* Pending Interest Table (PIT): PIT stores all the interests that a router has forwarded but not yet satisfied.
* Forwarding Information Base (FIB): It is a routing table matching the requested data name with its corresponding interface.  
NDN provides intrinsic security where the data itself is secured rather than the communication channel (as in the traditional networks) [8]. Each content is signed by the respective producer(s). Intrinsic security on one hand avoids the resource consuming complex mechanisms required for communication security and on the other hand makes the authenticated data locally available in the CS. Hence, most of the data-related attacks are automatically mitigated. The signature of a given data packet has two main fields, i.e., the signature type (generally SHA-256 with RSA), and the KeyLocator representing the name of the producer's public key. It specifies the name that points to another data packet containing the certificate or the public key needed to validate the signature value. Since the certificate is itself an NDN data packet, it has a signature field of its own. Figure 1 shows the format of an NDN data packet.  
Data packet in NDN is hierarchically checked for authentication. For instance, if a node receives a FANET course produced by an author 'A' and published in a blog 'LIM', the authentication of this packet is carried out using the following steps:  
1. Check the signature of the author,
2. Check the signature of the blog administrator who certified the author, and
3. Check the authority who certified the blog administrator. This latter is generally a trusted self signed authority, such us Google or Yahoo.  
If this whole key chain is verifiable, then the data packet is considered authentic, as shown in Figure 2.  
Figure 1: Format of NDN data packets [27].