Jyot Saini, CSC 466
10/17/22
The Problem:
Named Data Networking is a proposed alternative to traditional TCP/IP by shifting HTTP’s request (for a named data object)-and-response (containing the object) semantics at the application layer to the network layer. This shift inevitably leads to a new security framework that differs greatly from the one that researchers have grown familiar with. NDN is inherently resistant to lots of vulnerabilities that plague the internet today, but exposes new threat surfaces for attackers to exploit as well.
Main Idea:
Making named data the centerpiece of the architecture leads to a new security framework that secures data directly, and uses name semantics to enable applications to reason about security and to automate the use of cryptographic keys. In this paper, the authors introduce NDN’s approaches to security bootstrapping, data authenticity, confidentiality, and availability.
Major Strengths:
NDN secures data directly, removing any reliance on the security of intermediate communication channels, allowing applications to protect what really matters to them — the data itself.
In NDN, entities may utilize local authorities instead of commercial certificate authorities as trust anchors (using a trust model resembling SDSI/SPKI); trust policies are expressed explicitly through the relationships between semantically meaningful names in a systematic way, allowing applications to focus on security instead of blindly accepting signatures. Simultaneously, naming conventions help facilitate automated key management, thereby improving system usability.
Major Weaknesses:
The Content Store and the Pending Interest Table in an NDN router increase the attack surface, exposing the network to novel attacks.
It is possible that a Data Packet’s name and signature could expose the Producer’s identity if not secured properly.
Possible Improvement:
Many suggestions have been made by researchers to help reduce the risks of cache poisoning and other security challenges, but here the reliance on trust anchors seems counterintuitive to me for a peer-to-peer network. It centralizes authority in what should be a distributed system, so I would like to consider the possibility of relying on local and distributed verification systems (such as checksums for data validity, or local stores of trusted Producers) to mitigate the use of trust anchors.