The Road Ahead for Networking: A Survey on ICN-IP Coexistence Solutions

In recent years, the current Internet has experienced an unexpected paradigm shift in the usage model, which has pushed researchers towards the design of the Information-Centric Networking (ICN) paradigm as a possible replacement of the existing architecture. Even though both Academia and Industry have investigated the feasibility and effectiveness of ICN, achieving the complete replacement of the Internet Protocol (IP) is a challenging task. Some research groups have already addressed the coexistence by designing their own architectures, but none of those is the final solution to move towards the future Internet considering the unaltered state of the networking. To design such architecture, the research community needs now a comprehensive overview of the existing solutions that have so far addressed the coexistence. The purpose of this paper is to reach this goal by providing the first comprehensive survey and classification of the coexistence architectures according to their features (i.e., deployment approach, deployment scenarios, addressed coexistence requirements and architecture or technology used) and evaluation parameters (i.e., challenges emerging during the deployment and the runtime behaviour of an architecture). We believe that this paper will finally fill the gap required for moving towards the design of the final coexistence architecture.Comment: 23 pages, 16 figures, 3 table

Security for the Industrial IoT: The Case for Information-Centric Networking

Industrial production plants traditionally include sensors for monitoring or documenting processes, and actuators for enabling corrective actions in cases of misconfigurations, failures, or dangerous events. With the advent of the IoT, embedded controllers link these `things' to local networks that often are of low power wireless kind, and are interconnected via gateways to some cloud from the global Internet. Inter-networked sensors and actuators in the industrial IoT form a critical subsystem while frequently operating under harsh conditions. It is currently under debate how to approach inter-networking of critical industrial components in a safe and secure manner. In this paper, we analyze the potentials of ICN for providing a secure and robust networking solution for constrained controllers in industrial safety systems. We showcase hazardous gas sensing in widespread industrial environments, such as refineries, and compare with IP-based approaches such as CoAP and MQTT. Our findings indicate that the content-centric security model, as well as enhanced DoS resistance are important arguments for deploying Information Centric Networking in a safety-critical industrial IoT. Evaluation of the crypto efforts on the RIOT operating system for content security reveal its feasibility for common deployment scenarios.Comment: To be published at IEEE WF-IoT 201

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

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.Comment: 10 pages, 7 figure