To NACK or not to NACK? Negative Acknowledgments in Information-Centric Networking

TL;DR

This paper evaluates the use of negative acknowledgments (NACKs) in Information-Centric Networking, concluding that their security risks outweigh benefits, and recommends avoiding network-layer NACKs.

Contribution

The paper provides a comprehensive analysis of NACKs in ICN, highlighting security vulnerabilities and arguing against their use at the network layer.

Findings

NACKs help in flushing router state and notifying consumers in benign settings.

Secure NACKs can enable producer-bound flooding attacks.

Avoiding network-layer NACKs enhances security in ICN architectures.

Abstract

Information-Centric Networking (ICN) is an internetworking paradigm that offers an alternative to the current IP\nobreakdash-based Internet architecture. ICN's most distinguishing feature is its emphasis on information (content) instead of communication endpoints. One important open issue in ICN is whether negative acknowledgments (NACKs) at the network layer are useful for notifying downstream nodes about forwarding failures, or requests for incorrect or non-existent information. In benign settings, NACKs are beneficial for ICN architectures, such as CCNx and NDN, since they flush state in routers and notify consumers. In terms of security, NACKs seem useful as they can help mitigating so-called Interest Flooding attacks. However, as we show in this paper, network-layer NACKs also have some unpleasant security implications. We consider several types of NACKs and discuss their security design requirements and implications. We also demonstrate that providing secure NACKs triggers the threat of producer-bound flooding attacks. Although we discuss some potential countermeasures to these attacks, the main conclusion of this paper is that network-layer NACKs are best avoided, at least for security reasons.