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

A Repeater Encryption Unit for IPv4 and IPv6

IPsec is a powerful mechanism for protecting network communications. However, it is often viewed as difficult to use due to the elaborate configuration that is needed to ensure correct (and secure) operation. In this paper, we seek to answer the question of how to build IPsec VPNs without affecting the network assets. We exploit "repeater-encryption", which is similar to the IPsec bump-in-the-wire mode of operation. Our IPsec encryption unit works at Layer-2 of the network stack and does not encrypt control packets that are used for routing, address resolution and resource reservation. Although this is fairly straightforward for IPv4 networks, IPv6 introduces several new features and messages that complicate the operation of such a box. We report our findings of implementing transparent, repeater-based IPsec protection for IPv4 and IPv6. Our approach requires no configuration changes to other devices in the network, making it an attractive mechanism for security network traffic. We discuss the features of our IPsec encryption unit and show how it adapts to IPv4 and IPv6 networks. We also implement our approach on the OpenBSD IPsec stack to demonstrate its feasibility. We show that our transparent IPsec box can easily support speeds in excess of 100 Mbps

Investigation into the security and privacy of iOS VPN applications

Due to the increasing number of recommendations for people to use Virtual Private Networks (VPNs) to protect their privacy, more application developers are creating VPN applications and publishing them on the Apple App Store and Google Play Store. In this ‘gold rush’, applications are being developed quickly and, in turn, not being developed with security in mind.This paper investigated a selection of VPN applications available on the Apple App Store (for iOS devices) and tested the applications for security and privacy issues. This includes testing for any traffic being transmitted over plain HTTP, DNS leakage and transmission of personally identifiable information (such as phone number, International Mobile Equipment Identity (IMEI), email address, MAC address) and evaluating the security of the tunneling protocol used by the VPN.The testing methodology involved installing VPN applications on a test device, simulating network traffic for a pre-defined period of time and capturing the traffic. This allows for all traffic to be analysed to check for anything being sent without encryption. Other issues that often cause de-anonymization with VPN applications such as DNS leakage were also considered.The research found several common security issues with VPN applications tested, with a large majority of applications still using HTTP and not HTTPS for transmitting certain data. A large majority of the VPN applications failed to route additional user data (such as DNS queries) through the VPN tunnel. Furthermore, just fifteen of the tested applications were found to have correctly implemented the best-recommended tunneling protocol for user security.Outside of the regular testing criteria, other security anomalies were observed with specific applications, which included outdated servers with known vulnerabilities, applications giving themselves the ability to perform HTTPS interception and questionable privacy policies. From the documented vulnerabilities, this research proposes a set of recommendations for developers to consider when developing VPN applications

A Repeater Encryption Unit for IPv4 and IPv6

IPsec is a powerful mechanism for protecting network communications. However, it is often viewed as difficult to use due to the elaborate configuration that is needed to ensure correct (and secure) operation. In this paper, we seek to answer the question of how to build IPsec VPNs without affecting the network assets. We exploit "repeater-encryption", which is similar to the IPsec bump-in-the-wire mode of operation. Our IPsec encryption unit works at Layer-2 of the network stack and does not encrypt control packets that are used for routing, address resolution and resource reservation. Although this is fairly straightforward for IPv4 networks, IPv6 introduces several new features and messages that complicate the operation of such a box. We report our findings of implementing transparent, repeater-based IPsec protection for IPv4 and IPv6. Our approach requires no configuration changes to other devices in the network, making it an attractive mechanism for security network traffic. We discuss the features of our IPsec encryption unit and show how it adapts to IPv4 and IPv6 networks. We also implement our approach on the OpenBSD IPsec stack to demonstrate its feasibility. We show that our transparent IPsec box can easily support speeds in excess of 100 Mbps

Verkon migraatio IPv6-verkoksi

Insinöörityön tarkoituksena oli kuvitteellisen keskikokoisen suomalaisen liikunta-aiheisia verkkopalveluja tarjoavan yrityksen verkon migraatio IPv6-verkoksi. Lisäksi työssä perehdyttiin IPv6-migraation tietoturvaan. Insinöörityön tavoitteena oli löytää juuri tälle esimerkkiyritykselle sopivat IPv6-migraatiotekniikat ja toteuttaa ne soveltuvilta osin migraatiotekniikoiden teorioita tukemaan. Tavoitteena oli tuottaa käytännön osaamista oikeiden IPv6-migraatiotekniikoiden ja osoitteiden valinnassa sekä osoittaa käytännössä, kuinka yritys voi päivittää verkkonsa katkottomasti IPv6-yhteensopivaksi. Työssä käytettiin kahta IPv6-migraatiotekniikkaa: kaksoispinotekniikkaa sisäverkon migraatioon ja IPv4-upotettua IPv6-osoitetekniikkaa yrityksen ulkoverkon migraatioon. Kaksoispinotekniikkaan sisäverkon osalta päädyttiin lähinnä tekniikan pitkäikäisyyden vuoksi: IPv4-protokollaa tullaan käyttämään vielä pitkään ja kaksoispinototeutuksella ei tarvitse verkkoylläpidossa huolehtia mahdollisista siirtymistä jompaan kumpaan protokollaan, kun konfiguraatio kumpaakin protokollaa varten on kerran toteutettu. IPv4-upotetun IPv6-osoitetekniikan merkittävimpänä etuna on helppous: yritys voi taval-laan muuntaa tällä tekniikalla olemassa olevat julkiset IPv4-osoitteensa IPv6-osoitteiksi. Työ koostui kokonaisverkkotopologian suunnittelusta, määrittelystä ja toteutusvaiheesta, johon sisältyi paljon verkkolaitteiden konfiguraatioiden toteutusta kahdella eri protokollalla ja lisäksi näiden konfiguraatioiden testaamista. Insinöörityön tuloksena syntyi teoriatutkimuksen ja suunnittelun lisäksi käytännön toteutustyö, jossa suunniteltiin IPv4-verkko keskikokoisen yrityksen tarpeisiin ja määriteltiin tämä verkko toimimaan myös IPv6-verkkona ja IPv6-osoitteilla.The topic of this thesis is migration of the IPv6 network for an imaginary middle size Finnish company. In addition, this thesis deals with IPv6 migration data security. The objectives of the study were to find the most suitable IPv6 migration techniques for the company and to implement real migration in a laboratory environment to support the theories presented in this thesis. One of the most important objectives was to increase understanding of real IPv6 migration techniques and selection of suitable IPv6 addresses and to demonstrate how this type of a company can upgrade its network device configurations seamlessly to make them IPv6 compatible. In this study two migration techniques were used: the dual stack technique for private network migration and the IPv4 embedded IPv6 address technique with the well-known prefix for the public addresses and external network migration. The dual stack technique was chosen mostly because of its long lifecycle. The IPv4 protocol will still be used for long a time and with the dual stack technique the company does not need to worry about whether its network is capable of communicating with other networks no matter what protocols they use. This study included theoretical studies and practical laboratory work. Network design was put into reality by implementing the configurations for laboratory network devices according to the topology. The migration study could be further developed by researching IPv6 migration techniques in more detail and testing, comparing and rating them. Also further and more deep re-search regarding the security of the migration techniques would be useful if this study was to be continued

Enabling Practical IPsec authentication for the Internet

On the Move to Meaningful Internet Systems 2006: OTM 2006 Workshops (First International Workshop on Information Security (IS'06), OTM Federated Conferences and workshops). Montpellier, Oct,/Nov. 2006There is a strong consensus about the need for IPsec, although its use is not widespread for end-to-end communications. One of the main reasons for this is the difficulty for authenticating two end-hosts that do not share a secret or do not rely on a common Certification Authority. In this paper we propose a modification to IKE to use reverse DNS and DNSSEC (named DNSSEC-to-IKE) to provide end-to-end authentication to Internet hosts that do not share any secret, without requiring the deployment of a new infrastructure. We perform a comparative analysis in terms of requirements, provided security and performance with state-of-the-art IKE authentication methods and with a recent proposal for IPv6 based on CGA. We conclude that DNSSEC-to-IKE enables the use of IPsec in a broad range of scenarios in which it was not applicable, at the price of offering slightly less security and incurring in higher performance costs.Universidad de Montpellier IIPublicad

Reduction of Routing Delay in an Enterprise Network using Dynamic Multipoint Private Network

The more integrated networks are with the internet, the more our security concerns grow. Virtual Private Networks (VPNs) have been used to solve the problem of internet security. As more locations need to be securely connected, more configurations and greater complexity are given to a network design. Dynamic Multipoint VPN (DMVPN) was used in this research with some supporting protocols to allow changing of Internet Protocol (IP) addresses of remote locations. It proves to be a very scalable VPN technique with minimal configurations and robustness. Lesser delay between two branches of an organization among other advantages, such as elimination of triangular routing, and dynamic changing IP addresses were achieved

Performance evaluation of HIP-based network security solutions

Abstract. Host Identity Protocol (HIP) is a networking technology that systematically separates the identifier and locator roles of IP addresses and introduces a Host Identity (HI) name space based on a public key security infrastructure. This modification offers a series of benefits such as mobility, multi-homing, end-to-end security, signaling, control/data plane separation, firewall security, e.t.c. Although HIP has not yet been sufficiently applied in mainstream communication networks, industry experts foresee its potential as an integral part of next generation networks. HIP can be used in various HIP-aware applications as well as in traditional IP-address-based applications and networking technologies, taking middle boxes into account. One of such applications is in Virtual Private LAN Service (VPLS), VPLS is a widely used method of providing Ethernet-based Virtual Private Network that supports the connection of geographically separated sites into a single bridged domain over an IP/MPLS network. The popularity of VPLS among commercial and defense organizations underscores the need for robust security features to protect both data and control information. After investigating the different approaches to HIP, a real world testbed is implemented. Two experiment scenarios were evaluated, one is performed on two open source Linux-based HIP implementations (HIPL and OpenHIP) and the other on two sets of enterprise equipment from two different companies (Tempered Networks and Byres Security). To account for a heterogeneous mix of network types, the Open source HIP implementations were evaluated on different network environments, namely Local Area Network (LAN), Wireless LAN (WLAN), and Wide Area Network (WAN). Each scenario is tested and evaluated for performance in terms of throughput, latency, and jitter. The measurement results confirmed the assumption that no single solution is optimal in all considered aspects and scenarios. For instance, in the open source implementations, the performance penalty of security on TCP throughput for WLAN scenario is less in HIPL than in OpenHIP, while for WAN scenario the reverse is the case. A similar outcome is observed for the UDP throughput. However, on latency, HIPL showed lower latency for all three network test scenarios. For the legacy equipment experiment, the penalty of security on TCP throughput is about 19% compared with the non-secure scenario while latency is increased by about 87%. This work therefore provides viable information for researchers and decision makers on the optimal solution to securing their VPNs based on the application scenarios and the potential performance penalties that come with each approach.HIP-pohjaisten tietoliikenneverkkojen turvallisuusratkaisujen suorituskyvyn arviointi. Tiivistelmä. Koneen identiteettiprotokolla (HIP, Host Identity Protocol) on tietoliikenneverkkoteknologia, joka käyttää erillistä kerrosta kuljetusprotokollan ja Internet-protokollan (IP) välissä TCP/IP-protokollapinossa. HIP erottaa systemaattisesti IP-osoitteen verkko- ja laite-osat, sekä käyttää koneen identiteetti (HI) -osaa perustuen julkisen avainnuksen turvallisuusrakenteeseen. Tämän hyötyjä ovat esimerkiksi mobiliteetti, moniliittyminen, päästä päähän (end-to-end) turvallisuus, kontrolli-informaation ja datan erottelu, kohtaaminen, osoitteenmuutos sekä palomuurin turvallisuus. Teollisuudessa HIP-protokolla nähdään osana seuraavan sukupolven tietoliikenneverkkoja, vaikka se ei vielä olekaan yleistynyt laajaan kaupalliseen käyttöön. HIP–protokollaa voidaan käyttää paitsi erilaisissa HIP-tietoisissa, myös perinteisissä IP-osoitteeseen perustuvissa sovelluksissa ja verkkoteknologioissa. Eräs tällainen sovellus on virtuaalinen LAN-erillisverkko (VPLS), joka on laajasti käytössä oleva menetelmä Ethernet-pohjaisen, erillisten yksikköjen ja yhden sillan välistä yhteyttä tukevan, virtuaalisen erillisverkon luomiseen IP/MPLS-verkon yli. VPLS:n yleisyys sekä kaupallisissa- että puolustusorganisaatioissa korostaa vastustuskykyisten turvallisuusominaisuuksien tarpeellisuutta tiedon ja kontrolliinformaation suojauksessa. Tässä työssä tutkitaan aluksi HIP-protokollan erilaisia lähestymistapoja. Teoreettisen tarkastelun jälkeen käytännön testejä suoritetaan itse rakennetulla testipenkillä. Tarkasteltavat skenaariot ovat verrata Linux-pohjaisia avoimen lähdekoodin HIP-implementaatioita (HIPL ja OpenHIP) sekä verrata kahden eri valmistajan laitteita (Tempered Networks ja Byres Security). HIP-implementaatiot arvioidaan eri verkkoympäristöissä, jota ovat LAN, WLAN sekä WAN. Kaikki testatut tapaukset arvioidaan tiedonsiirtonopeuden, sen vaihtelun (jitter) sekä latenssin perusteella. Mittaustulokset osoittavat, että sama ratkaisu ei ole optimaalinen kaikissa tarkastelluissa tapauksissa. Esimerkiksi WLAN-verkkoa käytettäessä turvallisuuden aiheuttama häviö tiedonsiirtonopeudessa on HIPL:n tapauksessa OpenHIP:iä pirnempi, kun taas WAN-verkon tapauksessa tilanne on toisinpäin. Samanlaista käyttäytymistä havaitaan myös UDP-tiedonsiirtonopeudessa. HIPL antaa kuitenkin pienimmän latenssin kaikissa testiskenaarioissa. Eri valmistajien laitteita vertailtaessa huomataan, että TCP-tiedonsiirtonopeus huononee 19 ja latenssi 87 prosenttia verrattuna tapaukseen, jossa turvallisuusratkaisua ei käytetä. Näin ollen tämän työn tuottama tärkeä tieto voi auttaa alan toimijoita optimaalisen verkkoturvallisuusratkaisun löytämisessä VPN-pohjaisiin sovelluksiin