Securing Internet of Things with Lightweight IPsec

Real-world deployments of wireless sensor networks (WSNs) require secure communication. It is important that a receiver is able to verify that sensor data was generated by trusted nodes. In some cases it may also be necessary to encrypt sensor data in transit. Recently, WSNs and traditional IP networks are more tightly integrated using IPv6 and 6LoWPAN. Available IPv6 protocol stacks can use IPsec to secure data exchange. Thus, it is desirable to extend 6LoWPAN such that IPsec communication with IPv6 nodes is possible. It is beneficial to use IPsec because the existing end-points on the Internet do not need to be modified to communicate securely with the WSN. Moreover, using IPsec, true end-to-end security is implemented and the need for a trustworthy gateway is removed. In this paper we provide End-to-End (E2E) secure communication between an IP enabled sensor nodes and a device on traditional Internet. This is the first compressed lightweight design, implementation, and evaluation of 6LoWPAN extension for IPsec on Contiki. Our extension supports both IPsec's Authentication Header (AH) and Encapsulation Security Payload (ESP). Thus, communication endpoints are able to authenticate, encrypt and check the integrity of messages using standardized and established IPv6 mechanisms

The Impact of IPv6 on Penetration Testing

In this paper we discuss the impact the use of IPv6 has on remote penetration testing of servers and web applications. Several modifications to the penetration testing process are proposed to accommodate IPv6. Among these modifications are ways of performing fragmentation attacks, host discovery and brute-force protection. We also propose new checks for IPv6-specific vulnerabilities, such as bypassing firewalls using extension headers and reaching internal hosts through available transition mechanisms. The changes to the penetration testing process proposed in this paper can be used by security companies to make their penetration testing process applicable to IPv6 targets

Deliverable JRA1.1: Evaluation of current network control and management planes for multi-domain network infrastructure

This deliverable includes a compilation and evaluation of available control and management architectures and protocols applicable to a multilayer infrastructure in a multi-domain Virtual Network environment.The scope of this deliverable is mainly focused on the virtualisation of the resources within a network and at processing nodes. The virtualization of the FEDERICA infrastructure allows the provisioning of its available resources to users by means of FEDERICA slices. A slice is seen by the user as a real physical network under his/her domain, however it maps to a logical partition (a virtual instance) of the physical FEDERICA resources. A slice is built to exhibit to the highest degree all the principles applicable to a physical network (isolation, reproducibility, manageability, ...). Currently, there are no standard definitions available for network virtualization or its associated architectures. Therefore, this deliverable proposes the Virtual Network layer architecture and evaluates a set of Management- and Control Planes that can be used for the partitioning and virtualization of the FEDERICA network resources. This evaluation has been performed taking into account an initial set of FEDERICA requirements; a possible extension of the selected tools will be evaluated in future deliverables. The studies described in this deliverable define the virtual architecture of the FEDERICA infrastructure. During this activity, the need has been recognised to establish a new set of basic definitions (taxonomy) for the building blocks that compose the so-called slice, i.e. the virtual network instantiation (which is virtual with regard to the abstracted view made of the building blocks of the FEDERICA infrastructure) and its architectural plane representation. These definitions will be established as a common nomenclature for the FEDERICA project. Other important aspects when defining a new architecture are the user requirements. It is crucial that the resulting architecture fits the demands that users may have. Since this deliverable has been produced at the same time as the contact process with users, made by the project activities related to the Use Case definitions, JRA1 has proposed a set of basic Use Cases to be considered as starting point for its internal studies. When researchers want to experiment with their developments, they need not only network resources on their slices, but also a slice of the processing resources. These processing slice resources are understood as virtual machine instances that users can use to make them behave as software routers or end nodes, on which to download the software protocols or applications they have produced and want to assess in a realistic environment. Hence, this deliverable also studies the APIs of several virtual machine management software products in order to identify which best suits FEDERICA’s needs.Postprint (published version

Coherent, automatic address resolution for vehicular ad hoc networks

Published in: Int. J. of Ad Hoc and Ubiquitous Computing, 2017 Vol.25, No.3, pp.163 - 179. DOI: 10.1504/IJAHUC.2017.10001935The interest in vehicular communications has increased notably. In this paper, the use of the address resolution (AR) procedures is studied for vehicular ad hoc networks (VANETs). We analyse the poor performance of AR transactions in such networks and we present a new proposal called coherent, automatic address resolution (CAAR). Our approach inhibits the use of AR transactions and instead increases the usefulness of routing signalling to automatically match the IP and MAC addresses. Through extensive simulations in realistic VANET scenarios using the Estinet simulator, we compare our proposal CAAR to classical AR and to another of our proposals that enhances AR for mobile wireless networks, called AR+. In addition, we present a performance evaluation of the behaviour of CAAR, AR and AR+ with unicast traffic of a reporting service for VANETs. Results show that CAAR outperforms the other two solutions in terms of packet losses and furthermore, it does not introduce additional overhead.Postprint (published version

Description and Experience of the Clinical Testbeds

This deliverable describes the up-to-date technical environment at three clinical testbed demonstrator sites of the 6WINIT Project, including the adapted clinical applications, project components and network transition technologies in use at these sites after 18 months of the Project. It also provides an interim description of early experiences with deployment and usage of these applications, components and technologies, and their clinical service impact

SDN Architecture and Southbound APIs for IPv6 Segment Routing Enabled Wide Area Networks

The SRv6 architecture (Segment Routing based on IPv6 data plane) is a promising solution to support services like Traffic Engineering, Service Function Chaining and Virtual Private Networks in IPv6 backbones and datacenters. The SRv6 architecture has interesting scalability properties as it reduces the amount of state information that needs to be configured in the nodes to support the network services. In this paper, we describe the advantages of complementing the SRv6 technology with an SDN based approach in backbone networks. We discuss the architecture of a SRv6 enabled network based on Linux nodes. In addition, we present the design and implementation of the Southbound API between the SDN controller and the SRv6 device. We have defined a data-model and four different implementations of the API, respectively based on gRPC, REST, NETCONF and remote Command Line Interface (CLI). Since it is important to support both the development and testing aspects we have realized an Intent based emulation system to build realistic and reproducible experiments. This collection of tools automate most of the configuration aspects relieving the experimenter from a significant effort. Finally, we have realized an evaluation of some performance aspects of our architecture and of the different variants of the Southbound APIs and we have analyzed the effects of the configuration updates in the SRv6 enabled nodes

A survey on subjecting electronic product code and non-ID objects to IP identification

Over the last decade, both research on the Internet of Things (IoT) and real-world IoT applications have grown exponentially. The IoT provides us with smarter cities, intelligent homes, and generally more comfortable lives. However, the introduction of these devices has led to several new challenges that must be addressed. One of the critical challenges facing interacting with IoT devices is to address billions of devices (things) around the world, including computers, tablets, smartphones, wearable devices, sensors, and embedded computers, and so on. This article provides a survey on subjecting Electronic Product Code and non-ID objects to IP identification for IoT devices, including their advantages and disadvantages thereof. Different metrics are here proposed and used for evaluating these methods. In particular, the main methods are evaluated in terms of their: (i) computational overhead, (ii) scalability, (iii) adaptability, (iv) implementation cost, and (v) whether applicable to already ID-based objects and presented in tabular format. Finally, the article proves that this field of research will still be ongoing, but any new technique must favorably offer the mentioned five evaluative parameters.Comment: 112 references, 8 figures, 6 tables, Journal of Engineering Reports, Wiley, 2020 (Open Access

Evaluating the security vulenerabilities of the IP6to4 tunnelling mechanism

The two versions of Internet Protocol (IP) rely on mechanisms that will convert one protocol to the other and vice versa. Version 4 is still prevalent in the Internet backbone and version 6 in most private networks. In this research we focus on the automatic tunnelling mechanism that provides the encapsulation at one end of the transition tunnel and the de-encapsulation at the other end dependant on the direction of transition. In our research we asked: How secure is the automatic tunnelling mechanism? It is a simple question but important given the number of times transition may occur in any communication and the potential for vulnerabilities. To test the capability of the software instance we launched attacks on the inside and the outside of the tunnel; recorded performance variations and noted opportunities for information sniffing. In all instances the results show weaknesses that can be exploited and the potential for an outsider to not only launch for example DoS attacks but to also disrupt the information being managed in the tunnel. How secure is the automatic tunnelling mechanism