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

Multi Protocol Label Switching: Quality of Service, Traffic Engineering application, and Virtual Private Network application

This thesis discusses the QoS feature, Traffic Engineering (TE) application, and Virtual Private Network (VPN) application of the Multi Protocol Label Switching (MPLS) protocol. This thesis concentrates on comparing MPLS with other prominent technologies such as Internet Protocol (IP), Asynchronous Transfer Mode (ATM), and Frame Relay (FR). MPLS combines the flexibility of Internet Protocol (IP) with the connection oriented approach of Asynchronous Transfer Mode (ATM) or Frame Relay (FR). Section 1 lists several advantages MPLS brings over other technologies. Section 2 covers architecture and a brief description of the key components of MPLS. The information provided in Section 2 builds a background to compare MPLS with the other technologies in the rest of the sections. Since it is anticipate that MPLS will be a main core network technology, MPLS is required to work with two currently available QoS architectures: Integrated Service (IntServ) architecture and Differentiated Service (DiffServ) architecture. Even though the MPLS does not introduce a new QoS architecture or enhance the existing QoS architectures, it works seamlessly with both QoS architectures and provides proper QoS support to the customer. Section 3 provides the details of how MPLS supports various functions of the IntServ and DiffServ architectures. TE helps Internet Service Provider (ISP) optimize the use of available resources, minimize the operational costs, and maximize the revenues. MPLS provides efficient TE functions which prove to be superior to IP and ATM/FR. Section 4 discusses how MPLS supports the TE functionality and what makes MPLS superior to other competitive technologies. ATM and FR are still required as a backbone technology in some areas where converting the backbone to IP or MPLS does not make sense or customer demands simply require ATM or FR. In this case, it is important for MPLS to work with ATM and FR. Section 5 highlights the interoperability issues and solutions for MPLS while working in conjunction with ATM and FR. In section 6, various VPN tunnel types are discussed and compared with the MPLS VPN tunnel type. The MPLS VPN tunnel type is concluded as an optimal tunnel approach because it provides security, multiplexing, and the other important features that are reburied by the VPN customer and the ISP. Various MPLS layer 2 and layer 3 VPN solutions are also briefly discussed. In section 7 I conclude with the details of an actual implementation of a layer 3 MPLS VPN solution that works in conjunction with Border Gateway Protocol (BGP)

IP and ATM integration: A New paradigm in multi-service internetworking

ATM is a widespread technology adopted by many to support advanced data communication, in particular efficient Internet services provision. The expected challenges of multimedia communication together with the increasing massive utilization of IP-based applications urgently require redesign of networking solutions in terms of both new functionalities and enhanced performance. However, the networking context is affected by so many changes, and to some extent chaotic growth, that any approach based on a structured and complex top-down architecture is unlikely to be applicable. Instead, an approach based on finding out the best match between realistic service requirements and the pragmatic, intelligent use of technical opportunities made available by the product market seems more appropriate. By following this approach, innovations and improvements can be introduced at different times, not necessarily complying with each other according to a coherent overall design. With the aim of pursuing feasible innovations in the different networking aspects, we look at both IP and ATM internetworking in order to investigating a few of the most crucial topics/ issues related to the IP and ATM integration perspective. This research would also address various means of internetworking the Internet Protocol (IP) and Asynchronous Transfer Mode (ATM) with an objective of identifying the best possible means of delivering Quality of Service (QoS) requirements for multi-service applications, exploiting the meritorious features that IP and ATM have to offer. Although IP and ATM often have been viewed as competitors, their complementary strengths and limitations from a natural alliance that combines the best aspects of both the technologies. For instance, one limitation of ATM networks has been the relatively large gap between the speed of the network paths and the control operations needed to configure those data paths to meet changing user needs. IP\u27s greatest strength, on the other hand, is the inherent flexibility and its capacity to adapt rapidly to changing conditions. These complementary strengths and limitations make it natural to combine IP with ATM to obtain the best that each has to offer. Over time many models and architectures have evolved for IP/ATM internetworking and they have impacted the fundamental thinking in internetworking IP and ATM. These technologies, architectures, models and implementations will be reviewed in greater detail in addressing possible issues in integrating these architectures s in a multi-service, enterprise network. The objective being to make recommendations as to the best means of interworking the two in exploiting the salient features of one another to provide a faster, reliable, scalable, robust, QoS aware network in the most economical manner. How IP will be carried over ATM when a commercial worldwide ATM network is deployed is not addressed and the details of such a network still remain in a state of flux to specify anything concrete. Our research findings culminated with a strong recommendation that the best model to adopt, in light of the impending integrated service requirements of future multi-service environments, is an ATM core with IP at the edges to realize the best of both technologies in delivering QoS guarantees in a seamless manner to any node in the enterprise

A Survey on the Contributions of Software-Defined Networking to Traffic Engineering

Since the appearance of OpenFlow back in 2008, software-defined networking (SDN) has gained momentum. Although there are some discrepancies between the standards developing organizations working with SDN about what SDN is and how it is defined, they all outline traffic engineering (TE) as a key application. One of the most common objectives of TE is the congestion minimization, where techniques such as traffic splitting among multiple paths or advanced reservation systems are used. In such a scenario, this manuscript surveys the role of a comprehensive list of SDN protocols in TE solutions, in order to assess how these protocols can benefit TE. The SDN protocols have been categorized using the SDN architecture proposed by the open networking foundation, which differentiates among data-controller plane interfaces, application-controller plane interfaces, and management interfaces, in order to state how the interface type in which they operate influences TE. In addition, the impact of the SDN protocols on TE has been evaluated by comparing them with the path computation element (PCE)-based architecture. The PCE-based architecture has been selected to measure the impact of SDN on TE because it is the most novel TE architecture until the date, and because it already defines a set of metrics to measure the performance of TE solutions. We conclude that using the three types of interfaces simultaneously will result in more powerful and enhanced TE solutions, since they benefit TE in complementary ways.European Commission through the Horizon 2020 Research and Innovation Programme (GN4) under Grant 691567 Spanish Ministry of Economy and Competitiveness under the Secure Deployment of Services Over SDN and NFV-based Networks Project S&NSEC under Grant TEC2013-47960-C4-3-

Deliverable DJRA1.2. Solutions and protocols proposal for the network control, management and monitoring in a virtualized network context

This deliverable presents several research proposals for the FEDERICA network, in different subjects, such as monitoring, routing, signalling, resource discovery, and isolation. For each topic one or more possible solutions are elaborated, explaining the background, functioning and the implications of the proposed solutions.This deliverable goes further on the research aspects within FEDERICA. First of all the architecture of the control plane for the FEDERICA infrastructure will be defined. Several possibilities could be implemented, using the basic FEDERICA infrastructure as a starting point. The focus on this document is the intra-domain aspects of the control plane and their properties. Also some inter-domain aspects are addressed. The main objective of this deliverable is to lay great stress on creating and implementing the prototype/tool for the FEDERICA slice-oriented control system using the appropriate framework. This deliverable goes deeply into the definition of the containers between entities and their syntax, preparing this tool for the future implementation of any kind of algorithm related to the control plane, for both to apply UPB policies or to configure it by hand. We opt for an open solution despite the real time limitations that we could have (for instance, opening web services connexions or applying fast recovering mechanisms). The application being developed is the central element in the control plane, and additional features must be added to this application. This control plane, from the functionality point of view, is composed by several procedures that provide a reliable application and that include some mechanisms or algorithms to be able to discover and assign resources to the user. To achieve this, several topics must be researched in order to propose new protocols for the virtual infrastructure. The topics and necessary features covered in this document include resource discovery, resource allocation, signalling, routing, isolation and monitoring. All these topics must be researched in order to find a good solution for the FEDERICA network. Some of these algorithms have started to be analyzed and will be expanded in the next deliverable. Current standardization and existing solutions have been investigated in order to find a good solution for FEDERICA. Resource discovery is an important issue within the FEDERICA network, as manual resource discovery is no option, due to scalability requirement. Furthermore, no standardization exists, so knowledge must be obtained from related work. Ideally, the proposed solutions for these topics should not only be adequate specifically for this infrastructure, but could also be applied to other virtualized networks.Postprint (published version

A survey of Virtual Private LAN Services (VPLS): Past, present and future

Virtual Private LAN services (VPLS) is a Layer 2 Virtual Private Network (L2VPN) service that has gained immense popularity due to a number of its features, such as protocol independence, multipoint-to-multipoint mesh connectivity, robust security, low operational cost (in terms of optimal resource utilization), and high scalability. In addition to the traditional VPLS architectures, novel VPLS solutions have been designed leveraging new emerging paradigms, such as Software Defined Networking (SDN) and Network Function Virtualization (NFV), to keep up with the increasing demand. These emerging solutions help in enhancing scalability, strengthening security, and optimizing resource utilization. This paper aims to conduct an in-depth survey of various VPLS architectures and highlight different characteristics through insightful comparisons. Moreover, the article discusses numerous technical aspects such as security, scalability, compatibility, tunnel management, operational issues, and complexity, along with the lessons learned. Finally, the paper outlines future research directions related to VPLS. To the best of our knowledge, this paper is the first to furnish a detailed survey of VPLS.University College DublinAcademy of Finlan

Planning tools for MPLS networks

Verkot, joissa MPLS-tekniikkaa (Multi Protocol Label Switching) käytetään pakettien reitittämiseen, kasvavat jatkuvasti yhä suuremmiksi ja toiminnallisuus, jota verkoissa tarvitaan, monipuolistuu koko ajan. Tämän syyn vuoksi verkon suunnittelija tarvitsee yhä parempia apuvälineitä, jotta suunnittelu olisi onnistunutta, optimaalista ja tuottaisi halutun tuloksen. Tämän diplomityön tarkoitus on selvittää tärkeimmät toiminnallisuudet ja ominaisuudet, joita MPLS-verkkojen suunnitteluun laadittu työkalu vaatii. Diplomityö on jaettu kolmeen osaan. Ensimmäisessä osassa valotetaan MPLS-verkkojen käyttämää tekniikkaa. Tuossa osiossa käydään läpi tekniikat ja protokollat, joita MPLS-verkot käyttävät erinäisiin tehtäviin. Ensin käydään läpi yleisesti miksi MPLS-tekniikkaa ylipäätään tarvitaan ja miksi sitä käytetään verkkojen reitittämiseen. Tämän jälkeen tarkastellaan MPLS-protokollan otsikkokenttää ja sen osien käyttötarkoitukset selitetään. Sitten tarkastellaan MPLS-verkon rakennetta ja siihen kuuluvia laitteita. Seuraavaksi siirrytään osioon, joka selvittää kaikki yleisesti MPLS-polkujen rakentamiseen käytettävät protokollat ja miten ne eroavat toisistaan. Tämän jälkeen kerrotaan MPLS-vuonohjauksesta Differentiated Services-tekniikan avulla ja siitä miten se auttaa erilaisten liikenneluokkien erittelyssä MPLS-liikenteessä. Viimeinen kohta tässä osassa listaa erilaiset VPN-yhteydet, jotka ovat mahdollisia MPLS-tekniikkaa käytettäessä. Osio selventää näiden tekniikoiden eroavaisuudet ja mahdollisuudet, joita nämä MPLS-tekniikan avulla toteutettavat VPN-yhteydet suovat verrattuna aiempiin VPN-toteutuksiin. Toinen osa tässä diplomityössä kertoo verkon suunnittelusta. Ensin käydään läpi verkon suunnittelua yleisellä tasolla. Tämä osa sisältää verkon suunnittelun eri vaiheet pääosittain: erilaiset ennustusmallit esitellään ja selvitetään mitoituksen ja vuonohjauksen rooli verkkosuunnittelussa. Näiden jälkeen siirrytään yleisestä verkonsunnittelusta osioihin, joita käytetään MPLS-verkon suunnittelussa ja joiden yleisesti oletetaan tai halutaan löytyvän MPLS-verkkoihin tarkoitetusta suunnittelutyökalusta. Viimeinen kohta kertoo toiminnallisuus- ja skaalautuvuushaasteista, joihin MPLS:n on tekniikkana vastattava nykypäivänä. Kolmannessa osiossa tarkastellaan kahta eri suunnittelutyökalua, jotka on laadittu MPLS-verkkojen suunnitelua varten: WANDL-yhtiön julkaisemaa IP/MPLSView:ta ja Aria Networks Oy:n julkaisemaa iVNT:ta. Tässä osiossa käydään läpi näiden työkalujen toiminnallisuutta kertomalla erilaisista simulaatiomahdollisuuksista, joita kumpikin työkalu tarjoaa. Lisäksi kerrotaan mitä toimintoja ja protokollia näihin työkaluihin on mallinnettu, miten hyvin työkalut skaalautuvat kaupallisten MPLS-verkkojen tarpeisiin ja minkälaisita moduuleista työkalut on rakennettu. Työn lopussa on pohdittu näiden kolmen osion perusteella, että mitkä ominaisuudet tulisi ottaa huomioon MPLS-verkon suunnittelutyökalua laadittaessa ja millä tavalla nämä ominaisuudet tulisi toteuttaa työkalussa. Näiden jälkeen on työhön vielä tehty loppuyhteenveto, joka kertoo työ tuloksista ja mahdollisista jatkokehitysmahdollisuuksista. MPLS-verkon suunnittelu koostuu monesta eri vaiheesta, ja jokainen vaihe sisältää suuren määrän toiminnallisuusvaatimuksia. Nämä toiminnallisuusvaatimukset on mallinnettava MPLS-verkkojen suunnitteluun laaditussa työkalussa, jos halutaan että työkalu pystyy mallintamaan koko verkon suunnitteluprosessin alusta loppuun. Tärkeimmät toiminnallisuudet, jotka MPLS-verkon suunnittelutyökalun tulee omata ovat simulointimahdollisuudet MPLS-poluille (LSP:t), MPLS-TE:lle, eri VPN-tyypeille ja DiffServ-liikenteelle, sillä nämä ovat tärkeimmät toiminnallisuudet MPLS-verkoissa tänä päivänä. Jos edellä mainittu toiminnallisuus on toteutettu ja mallinnettu suunnittelutyökalussa ja työkalu osaa optimoida liikennettä hyvin saadaan verkon pääoma- ja operaationaaliset kulut laskemaan. MPLS-verkon suunnittelutyökalua laadittaessa on myös tärkeää ottaa huomioon työkalun skaalautuvuusominaisuudet. Runkoverkot voivat koostua tänä päivänä tuhansista solmuista ja sadoista tuhansista liikennevirroista, joten suunnitelutyökalun tulisi omata toiminnallisuutta joka automatisoi joitain vaiheita verkonsuunnittelussa, mikä mahdollistaa tämän kokoluokan verkkojen suunnittelun. Tällainen toiminnallisuus voisi esimerkiksi olla automatisoitu vuonohjaus ja verkkojen topologiakokonaisuuden vienti ja tuonti suunnittelutyökaluun ja siitä ulos. /Kir1