Ende-til-ende sikkerhet i IP-baserte nett med satellittkommunikasjon

The main characteristics of the satellite channel are large delay and bit error. Both characteristics make TCP perform poorly in satellite communication, and force optimization of TCP and even definition of new transport protocols. Using the optimized protocols only in the satellite channel complicates the use of host-to-host IPsec connections. This dissertation proposes and tests different host-to-host security solutions for such systems. The proposals use IPsec, SSL, TLS and SSH. The tests show that secure communication performs as good as insecure communication in a satellite channel. Further studies of IPsec shows that the replay window, as specified in RFC 2401, is too small when used in communication with high bandwidth and large delay. The dissertation implements a new replay mechanism with larger window. Through tests it is proved that it performs as fast as the original implementation

Fast, Effective and Stable IP Recovery using Resilient Routing Layers

Abstract. Recovery at the IP layer is hampered by the slow convergence of IP rerouting. Recovery times in the range of seconds do not adhere to the requirements of many Internet applications today. To offer fast, pre-configured and loop-free IP recovery we have proposed a new method named Resilient Routing Layers (RRL). In this paper we demonstrate how RRL also can provide resource-effective recovery in IP networks. We compare the performance of RRL with what intuitively should be the most resourceeffective method: Full global rerouting.

Deliverable D1.1 - NEAT Architecture

Ossification of the Internet transport-layer architecture is a significant barrier to innovation of the Internet. Such innovation is desirable for many reasons. Current applications often need to implement their own mechanisms to receive the transport service they need, but many do not have the breadth of adapting to all possible network characteristics. An updated transport architecture can do much to make the Internet more flexible and extensible. New ground-breaking services often require different or updated transport protocols, could benefit from better signalling between application and network, or desire a more flexible choice of which network path is used for which traffic. This document therefore proposes a new transport architecture. Such architecture lowers the barrier to service innovation by proposing a “transport system”, the NEAT System, that can leverage the rich set of available transport protocols. It paves the way for an architectural change of the Internet where new transport-layer services can seamlessly be integrated and quickly made available, minimising deployment difficulties, and allowing Internet innovators to take advantage of them wherever possible. The document provides a survey of the state-of-the-art to identify the architectural obstacles to, and opportunities for, evolution of the transport layer. It also details a set of general requirements for a new transport architecture. This new architecture is motivated by a set of use-cases, followed by a description of the NEAT architecture for a transport system, designed to permit applications to select appropriate transports based on their needs and the available transport services.A New, Evolutive API and Transport-Layer Architecture for the Internet (NEAT

Deliverable D3.3 - Extended Transport System and Transparent Support of Non-NEAT Applications

This deliverable summarises and concludes our work in Work Package 3 (WP3) to extend the transport services provided by the NEAT System developed in Work Package 2, and to enable non-NEAT applications to harness the transport services offered by NEAT. We have demonstrated how a policy- and information-based selection of transport protocol by NEAT could provide a more efficient transport service for web applications. The information on which NEAT makes its transport selection decisions resides in the Characteristics Information Base (CIB). The CIB is populated by various CIB sources, and in WP3 we have designed, implemented, and evaluated various CIB sources, including meta data from mobile broadband networks, passive measurements, IPv6 Provisioning Domain protocols and the Happy Eyeballs mechanism, which caches the outcome of its connection attempts. A key property of NEAT is that it not only “vertically” decouples applications from transport protocols, but also “horizontally”. Particularly, it enables applications to harness information about resource availability and policies from Software Defined Networking (SDN) controllers in managed networks, without these applications actually being SDN-aware. To extend the use of NEAT to non-NEAT applications, we have implemented a BSDcompatible sockets API on top of NEAT and a NEAT proxy that intercepts and replaces standard TCP connections with NEAT flows, i.e., with the transport solutions deemed most appropriate by NEAT.We have also proposed a way for non-NEAT applications to make use of NEAT through the deployment of NEAT-enabled virtual appliances in SDN-controlled networks: connections from these applications are routed via an SDN-controlled proxy that terminates the original connection and replaces it with a NEAT-selected connection.A New, Evolutive API and Transport-Layer Architecture for the Internet (NEAT