DOCSLIB.ORG

An Identifier-Locator Approach to Host Multihoming

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
An Identifier-Locator Approach to Host Multihoming An identifier-locator approach to host multihoming Bruce Simpson Saleem N. Bhatti University of St Andrews, UK University of St Andrews, UK [email protected] [email protected] Abstract—Host multihoming allows individual hosts to be demonstrate multihoming and load balancing functions. We multiply connected to the network, e.g. by concurrent use of two evaluate its performance in comparison to IPv6. We use the network prefixes, each network prefix tied to a separate network terms Locator and Identifier as defined in RFC6115 [8]. interface. Such multihoming capability improves the host’s ability to implement such features as load-balancing, fail-over and multi- We begin in Section II by describing how an ‘ID/Loc’ path transport protocols. However, IP does not directly support split affects routing state for multihomed sites (and hosts). host multihoming today. The Identifier / Locator split solution After presenting some related work in Section III, we describe space is seen as one way for reducing such negative impact. how the ILNPv6 host architecture has been implemented in We present an evaluation of host-multihoming as a prototype Section IV, with emphasis on how existing Application Pro- implementation of the Identifier Locator Network Protocol (ILNP) on FreeBSD, as a superset of IPv6 – called ILNPv6. We demon- gramming Interfaces (APIs) are affected. Section V describes strate load-balancing using ILNPv6 multihoming and compare our experimental configuration, method and results. Scalability performance with IPv6 forwarding at the end host. and performance is discussed briefly in Section VI, and we conclude in Section VII. I. INTRODUCTION The growth of the Internet routing table is a significant II. BACKGROUND problem. It is known that load balancing and multihoming The overloaded use of IP addresses today may be under- are the two principal factors involved. Whilst much of this stood by considering the bindings of an IP address within the growth is at the edge [1]–[4] of the network, it impacts upon protocol stack [9], as shown in Table I. The second column the core network: the state required for these functions must shows that IP addresses are used as both node identifiers and be propagated throughout the routing infrastructure. topological locators. Whilst this table describes these in terms There is significant overlap between node identity and of ‘names’ we do not discuss this beyond API compatibility. network location as represented by the way IP addresses have TABLE I been used for 35 years [5], [6]. Architectures which propose USE OF NAMES IN IP AND ILNP aseparationoflocationfromidentitymaymitigatetheeffects of routing table growth [1]. Whilst IPv6 has expanded the Protocol layer IP (v4 and v6) ILNP (ILNPv6) Application FQDN*, IP address FQDN or app-specific address space, the routing and addressing architecture has Transport IP address (node) Identifier (NID), NID not changed to reflect location independence. The Identifier- Network IP address Locator (L64), L64 Locator Network Protocol (ILNP) is a host-based, end-to-end (interface) IP address dynamic binding ‘ID/Loc’ architecture. ILNP nodes do not use IP addresses * Fully Qualified Domain Name but instead use Node Identifier and topologically-significant The IP network layer and routing functions use the IP Locators. address to identify IP sub-networks, i.e. network location. Amultihomedhost(orsite)isconnectedtomorethanone Such use of IP addresses as locators requires that routers IP network. With IP today, multihoming and load balancing exchange information about IP address prefixes and the paths must be implemented within the routing infrastructure. In by which they may be reached, e.g. using routing protocols ‘ID/Loc’ architectures, these may be realised as a choice such as the Border Gateway Protocol (BGP). between network locations. ILNP advertises network location Transport layer communication protocols (such as TCP and values in the Domain Name System (DNS) [7]. Load balancing UDP) also use the IP address to identify nodes. In conjunction can be viewed as a choice between these locations (based on an with port numbers, these are used to uniquely identify sessions additional policy), and therefore may be implemented without between two hosts. However, as can be seen in Table I, the requiring support from network routers or ‘middleboxes’. It overloaded use of the IP address creates an implicit binding. is, effectively, a policy applied to the forwarding plane. Transport layer sessions become ‘bound’ to specific interfaces as they are established, making it difficult to separate location A. Contribution from identity within the current IP architecture. Host-based While ILNP is a radically different architecture, the claim approaches to the ‘ID/Loc’ split aim to disentangle these two is that it can be implemented on the current codebase, rather uses, which we discuss further in Subsec. IV-A and IV-J. than requiring a ‘clean-slate’ approach. We examine how the Multi-homing may be desirable for hosts, e.g. to achieve FreeBSD stack can be modified to implement ILNPv6 and robustness through diverse connectivity. However, it needs special treatment for IP [10]. Moreover, it contributes to rout- of network addresses. Compared to ILNPv6, HIP poses an ing table growth by requiring routers to advertise additional additional requirement for use of cryptographic identities, prefixes. This can be demonstrated by considering Fig. 1. Here, which may not be suited for all uses. Additionally, HIP asitenetworkusestwoprefixes,P1 and P2.Thesemustboth requires existing applications to be ported to a new API, while be visible upstream from the two ISPs, ISP1 and ISP2. ILNP can work with the existing sockets API (see later). Level 3 Multihoming Shim Protocol for IPv6 (SHIM6) [14] supports multihoming and traffic engineering for IPv6. SHIM6 is host-based and end-systems use two IPv6 address – one as an Identifier and one as a Locator. It is implemented as ashimunderneathIPv6transportprotocolAPIs.Afour-way handshake is used to establish a SHIM6 context (exchange of Identifier and Locator values), and separate security mecha- nisms are required to protect its signalling [15], [16]. The Locator/Identifier Separation Protocol (LISP) [17] pro- poses a complete routing architecture and is not host based. Fig. 1. Illustrative scenario for multihoming: a site network,withasiteborder router (SBR), connecting to two separate ISPs. We assume that,inthiscase, This has the advantage that end-host stacks do not need to the site network has two routing prefixes, P1 and P2. change. LISP’s Routing Locators (RLOCs) and Endpoint Iden- We assume that these prefixes are de-aggregated within tifiers (EIDs) re-use IP address values. LISP requires an in- the global routing table, i.e. that connectivity to each ISP is network mapping system between the two namespaces. LISP topologically diverse (common practice where BGP is used to uses a ‘map-and-encapsulate’ (map-encap) approach to for- multihome sites). Such prefixes are also known as Provider warding (i.e. tunnelling), creating an overlay mesh. Additional Independent (PI) prefixes, allocated to allow the user (the headers are interposed between existing IPv4 header fields, end site) to maintain use of these prefixes even if their ISP which are normally visible only to LISP-enabled routers. LISP changes. Therefore, ISP1 and ISP2, as well as upstream routers may require significant changes to some existing network must advertise these prefixes separately. This is because they routers (perhaps the deployment of new routers). The map- form part of the IP address, which is used in end-to-end state encap mechanism may impact existing applications, e.g. due (identity) for hosts – see Table I. It follows that the additional to MTU size issues, and use of tunnels. upstream routing state required for NP site prefixes with NI HIP, SHIM6 and ILNP are host-based ‘ID/Loc’ architec- upstream ISPs is O(NP .NI ). tures. These approaches push deployment costs mainly to Whilst we have used site multihoming in our example (as the end-user, though there may be impact to site networks, that is the more common case for IP today), a site would e.g. firewall configuration for new extension headers. Whilst need to support multihoming to allow individual hosts to be ILNP requires changes to the end-host stack, no shim layer multihomed, and the scalability analysis is the same. is required. It does not require additional IPv6 addresses for signalling its protocol state. ILNP does not use tunnelling. III. RELATED WORK IV. ILNPV6OVERVIEW Aexcellentsummaryofapproachestothe‘ID/Loc’split ILNP defines an ‘ID/Loc’ split architecture with experimen- is provided in RFC6115 [8]. These may be divided into two tal RFC status [9], [18]. It is specified for both IPv6 [19], [20] categories: network-based approaches which make the split and IPv4 [21]–[23] networks, i.e. ILNPv6 can be engineered as apropertyoftheroutinginfrastructure(leavingIPaddresses asetofextensionstoIPv6.Inthispaper,wediscussonlythose unchanged at hosts), and host-based approaches which make it aspects which apply to IPv6 hosts. As, architecturally, ILNP apropertyofhostaddressmanagement(possiblyintroducing is radically different from IP – there are no addresses in ILNP new namespaces or addresses). In line with the IETF’s current –ourimplementationconsiders(1)whatneedstochangein thinking regarding the ‘sunsetting’ of IPv4 [11], many of these current stack engineering in order to enable ILNPv6; and (2) consider only IPv6. So, we constrain ourselves here to consider what impact this could have on performance. This work has three proposals with similar intent and scope to those of ILNP. taken a dual-stack approach to implementation, as described The Host Identity Protocol (HIP) [12] supports multihoming further in RFC6740 [9] and RFC6741 [18]. and mobility. The ‘ID/Loc’ split is implemented using an Our implementation is based on FreeBSD 8.2, and is a asymmetric key crypto-system; Host Identifiers (HI) are public separate kernel module, ilnp6,withchangestotheexist- keys, Locators are IP addresses. Whilst a host can have many ing IPv6 stack.
Load more

Recommended publications
  • Performance Evaluation of TCP Multihoming for IPV6 Anycast Networks and Proxy Placement
    University of Central Florida STARS Electronic Theses and Dissertations, 2004-2019 2015 Performance Evaluation of TCP Multihoming for IPV6 Anycast Networks and Proxy Placement Raya Alsharfa University of Central Florida Part of the Electrical and Electronics Commons Find similar works at: https://stars.library.ucf.edu/etd University of Central Florida Libraries http://library.ucf.edu This Masters Thesis (Open Access) is brought to you for free and open access by STARS. It has been accepted for inclusion in Electronic Theses and Dissertations, 2004-2019 by an authorized administrator of STARS. For more information, please contact [email protected]. STARS Citation Alsharfa, Raya, "Performance Evaluation of TCP Multihoming for IPV6 Anycast Networks and Proxy Placement" (2015). Electronic Theses and Dissertations, 2004-2019. 1350. https://stars.library.ucf.edu/etd/1350 PERFORMANCE EVALUATION OF TCP MULTIHOMING FOR IPV6 ANYCAST NETWORKS AND PROXY PLACEMENT by RAYA MAJID ALSHARFA B.S. NAJAF TECHNICAL COLLEGE, 2010 A thesis submitted in partial fulfillment of the requirements for the degree of Master of Science in Electrical Engineering. in the Department of Electrical Engineering and Computer Science in the College of Engineering and Computer Science at the University of Central Florida Orlando, Florida Fall Term 2015 Major Professor: Mostafa Bassiouni © 2015 Raya Majid Alsharfa ii ABSTRACT In this thesis, the impact of multihomed clients and multihomed proxy servers on the performance of modern networks is investigated. The network model used in our investigation integrates three main components: the new one-to-any Anycast communication paradigm that facilitates server replication, the next generation Internet Protocol Version 6 (IPv6) that offers larger address space for packet switched networks, and the emerging multihoming trend of connecting devices and smart phones to more than one Internet service provider thereby acquiring more than one IP address.
    [Show full text]
  • Host Identity Protocol (HIP) •Overlays (I3 and Hi3) •Summary Introductionintroduction
    HostHost IdentityIdentity ProtocolProtocol Prof. Sasu Tarkoma 23.02.2009 Part of the material is based on lecture slides by Dr. Pekka Nikander (HIP) and Dmitrij Lagutin (PLA) ContentsContents •Introduction •Current state •Host Identity Protocol (HIP) •Overlays (i3 and Hi3) •Summary IntroductionIntroduction •Current Internet is increasingly data and content centric •The protocol stack may not offer best support for this •End-to-end principle is no longer followed – Firewalls and NAT boxes – Peer-to-peer and intermediaries •Ultimately, hosts are interested in receiving valid and relevant information and do not care about IP addresses or host names •This motivate the design and development of new data and content centric networking architectures – Related work includes ROFL, DONA, TRIAD, FARA, AIP, .. TheThe InternetInternet hashas ChangedChanged •A lot of the assumptions of the early Internet has changed – Trusted end-points – Stationary, publicly addressable addresses – End-to-End •We will have a look at these in the light of recent developments •End-to-end broken by NATs and firewalls HTTPS, S/MIME, PGP,WS-Security, Radius, Diameter, SAML 2.0 .. Application Application Transport TSL, SSH, .. Transport HIP, shim layers IPsec, PLA, PSIRP Network Network PAP, CHAP, WEP, .. Link Link Physical Physical CurrentCurrent StateState TransportTransport LayerLayer IP layer IP layer Observations IPsec End-to-end reachability is broken Routing Unwanted traffic is a problem Fragmentation Mobility and multi-homing are challenging Multicast is difficult
    [Show full text]
  • Host Identity Protocol
    Presentation outline Host Identity Protocol •Introduction: What and why? •Background •HIP in a Nutshell •Mobility and multi-homing (multi-addressing) •HIP infrastructure: Hi3 Pekka Nikander •Current status Ericsson Research Nomadiclab and •Summary Helsinki Institute for Information Technology http://www.hip4inter.net 2 What is HIP? Motivation •Not to standardise a solution to a problem •HIP = Host Identity Protocol •No explicit problem statement A proposal to separate identifier from locator at • Exploring the consequences of the id / loc split the network layer of the TCP/IP stack • •A new name space of public keys •Try it out in real life, in the live Internet •A protocol for discovering and authenticating •A different look at many problems bindings between public keys and IP addresses •Mobility, multi-homing, end-to-end security, •Secured using signatures and keyed hashes signalling, control/data plane separation, (hash in combination with a secret key) rendezvous, NAT traversal, firewall security, ... 3 4 Presentation outline Background •Introduction: What and why? •Background •HIP in a Nutshell •A brief history of HIP •Mobility and multi-homing (multi-addressing) •Architectural background •HIP infrastructure: Hi3 •Related IETF Working Groups •Current status •Summary 5 6 1 A Brief History of HIP Architectural background •1999 : idea discussed briefly at the IETF IP addresses serve the dual role of being •2001: two BoFs, no WG created at that time • End-point Identifiers •02-03: development at the corridors • •2004: WG and RG created
    [Show full text]
  • Primer on Host Identity Protocol
    whitepaper Primer on Host Identity Protocol A simpler, more secure approach to IP communications Creating a new standard for network security Host Identity Protocol (HIP) is an open standards-based network security protocol, approved by the leading Internet standards organization, the Internet Engineering Task Force, in 2015. That event crowned over 15 years of HIP development, testing and deployment in coordination with several large companies (such as Boeing, Ericsson, Nokia, Verizon, TeliaSonera) and standard bodies (Trusted Computing Group, IEEE 802). Recognized by the Internet Engineering Task Force (IETF) community as a fundamental improvement in secure IP architecture, HIP was first deployed within the defense and aerospace industry as a cost-efficient and scalable solution to address growing threat environments and the complexity of security policy management. The protocol has been in use for over 10 years in mission-critical environments of all scale and complexity, including applications where downtime costs exceeds $1 million per hour, and nation-state cyber-attacks occur on a regular basis. tempered.io 1 whitepaper | primer on Host Identity Protocol Timeline of internet transport technology Timeline of internet Tempered launches Airnet, transport technology a free HIP VPN 1969 1980 1983 1990 2006 2007 2015 2021 Arpanet starts using Early Arpanet Commercial Boeing Tempered First HIP precursor to TCP/IP converts internet deploys launches HIP RFC TCP/IP RFC to TCP/IP starts HIP implementation Tempered launches Airnet, a free HIP VPN 1969 1980 1983 1990 2006 2007 2015 2021 Arpanet Early Arpanet Commercial Boeing Tempered is TCP/IP converts internet First HIP deploys launches HIP launched RFC to TCP/IP starts RFC HIP implementation Tempered Networks now offers the leading, field-proven HIP implementation.
    [Show full text]
  • RFC 9063: Host Identity Protocol Architecture
    Stream: Internet Engineering Task Force (IETF) RFC: 9063 Obsoletes: 4423 Category: Informational Published: July 2021 ISSN: 2070-1721 Authors: R. Moskowitz, Ed. M. Komu HTT Consulting Ericsson RFC 9063 Host Identity Protocol Architecture Abstract This memo describes the Host Identity (HI) namespace, which provides a cryptographic namespace to applications, and the associated protocol layer, the Host Identity Protocol, located between the internetworking and transport layers, that supports end-host mobility, multihoming, and NAT traversal. Herein are presented the basics of the current namespaces, their strengths and weaknesses, and how a HI namespace will add completeness to them. The roles of the HI namespace in the protocols are defined. This document obsoletes RFC 4423 and addresses the concerns raised by the IESG, particularly that of crypto agility. The Security Considerations section also describes measures against flooding attacks, usage of identities in access control lists, weaker types of identifiers, and trust on first use. This document incorporates lessons learned from the implementations of RFC 7401 and goes further to explain how HIP works as a secure signaling channel. Status of This Memo This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9063.
    [Show full text]
  • A Holistic Survey of Network-Layer Multipath Junaid Qadir, Anwaar Ali, Kok-Lim Alvin Yau, Arjuna Sathiaseelan, Jon Crowcroft
    1 Exploiting the power of multiplicity: a holistic survey of network-layer multipath Junaid Qadir, Anwaar Ali, Kok-Lim Alvin Yau, Arjuna Sathiaseelan, Jon Crowcroft Abstract—The Internet is inherently a multipath network—for available on the Internet, traditional Internet technologies have an underlying network with only a single path connecting various focused mainly on single-path routing for the sake of its nodes would have been debilitatingly fragile. Unfortunately, simplicity and lower overhead. This has led to the artificial traditional Internet technologies have been designed around the restrictive assumption of a single working path between a source lockup of Internet’s capacity, lower fault tolerance and reli- and a destination. The lack of native multipath support constrains ability, and inflexible support for quality of service (QoS). network performance even as the underlying network is richly This is even in contrast to telephone networks, which have connected and has redundant multiple paths. Computer networks traditionally adopted multiple-path routing1 since it leads to can exploit the power of multiplicity—through which a diverse better reliability and greater customer satisfaction (due to the collection of paths is resource pooled as a single resource—to unlock the inherent redundancy of the Internet. This opens up lesser probability of call blocking) [2]. a new vista of opportunities promising increased throughput Notwithstanding the lack of native multipath support on (through concurrent usage of multiple paths) and increased the current Internet, there is a growing convergence in the reliability and fault-tolerance (through the use of multiple paths Internet community that multipath routing and forwarding, or in backup/ redundant arrangements).
    [Show full text]
  • Guidelines for the Secure Deployment of Ipv6
    Special Publication 800-119 Guidelines for the Secure Deployment of IPv6 Recommendations of the National Institute of Standards and Technology Sheila Frankel Richard Graveman John Pearce Mark Rooks NIST Special Publication 800-119 Guidelines for the Secure Deployment of IPv6 Recommendations of the National Institute of Standards and Technology Sheila Frankel Richard Graveman John Pearce Mark Rooks C O M P U T E R S E C U R I T Y Computer Security Division Information Technology Laboratory National Institute of Standards and Technology Gaithersburg, MD 20899-8930 December 2010 U.S. Department of Commerce Gary Locke, Secretary National Institute of Standards and Technology Dr. Patrick D. Gallagher, Director GUIDELINES FOR THE SECURE DEPLOYMENT OF IPV6 Reports on Computer Systems Technology The Information Technology Laboratory (ITL) at the National Institute of Standards and Technology (NIST) promotes the U.S. economy and public welfare by providing technical leadership for the nation’s measurement and standards infrastructure. ITL develops tests, test methods, reference data, proof of concept implementations, and technical analysis to advance the development and productive use of information technology. ITL’s responsibilities include the development of technical, physical, administrative, and management standards and guidelines for the cost-effective security and privacy of sensitive unclassified information in Federal computer systems. This Special Publication 800-series reports on ITL’s research, guidance, and outreach efforts in computer security and its collaborative activities with industry, government, and academic organizations. National Institute of Standards and Technology Special Publication 800-119 Natl. Inst. Stand. Technol. Spec. Publ. 800-119, 188 pages (Dec. 2010) Certain commercial entities, equipment, or materials may be identified in this document in order to describe an experimental procedure or concept adequately.
    [Show full text]
  • Multihoming Support in Mobile IP Networks: Progress, Challenges and Solutions
    International Journal of Innovative Technology and Exploring Engineering (IJITEE) ISSN: 2278-3075, Volume-9 Issue-5, March 2020 Multihoming Support in Mobile IP Networks: Progress, Challenges and Solutions Mohammad Alreshoodi easily attained not only in urban areas but also in remote Abstract: IP network mobility has already emerged as a key environments. Many Internet access options can be exposed domain of wireless IP networking. The network research to mobile IP devices and networks while being on the move. community has taken great interest and paid considerable Wi-Fi hotspots are becoming available in many urban attention to advance IP mobility applications. Accordingly, locations and cellular access can be reached in rural areas. different advanced networking mechanisms have been considered to optimize IP network mobility. One of these mechanisms is The wide availability of these and other access technologies network multi-homing which has been the focus of many IP provides mobile IP networks with a number of wireless mobility studies within the academic research and IETF connectivity alternatives. Multi-interfaced mobile IP devices communities. The combination of network mobility and and multi-gateways mobile IP networks can use all these multi-homing has turned into a conceivable approach to opportunities to establish more resilience Internet access. effectively deal with expanding system availability and improving In addition, multihoming paves the way to have support of the performance of mobile IP network. There are many studies more effective networking techniques in mobile IP networks. proposed during the recent years to realize network multi-homing These include seamless handover among homogeneous and for the Network Mobility Basic Support (NEMO BS) protocol, a leading IETF IP mobility protocol.
    [Show full text]
  • Evaluating 5G Multihoming Services in the Mobilityfirst Future Internet Architecture
    Evaluating 5G Multihoming Services in the MobilityFirst Future Internet Architecture Parishad Karimi, Michael Sherman, Francesco Bronzino Ivan Seskar, Dipankar Raychaudhuri Inria, Paris WINLAB, [email protected] Rutgers University Abhimanyu Gosain fparishad,msherman,seskar,[email protected] Raytheon BBN Technologies [email protected] Abstract—In the recent years it has become increasingly etc can be deployed and evaluated. In this paper we focus evident that the current end-to-end host-centric communication on the implementation of mobility services, namely device paradigm will not be capable of meeting the ongoing demand multihoming and its deployment in testbeds including 5G for massive data rates and ultra-low latency. With the advent of fifth generation of cellular architecture (5G) to support these technologies. In Sec. III the principal design elements of requirements on the wireless edge of the network, the need the Mobilityfirst architecture are described along with how for core network solutions to play a complementary role is Mobilityfirst enables 5G services (specifically multihoming). conspicuous. In this paper we present and tackle some of the Next in Sec. IV the details for the components employed in the challenges of deploying a Future Internet Architecture (FIA), implementation are elaborated on. In Sec. V the experimental called MobilityFirst (MF), specifically for 5G use case scenarios. We report our findings of the deployment based on a setup methodology and results are presented. We discuss large scale on a small-scale testbed (ORBIT) and a nation-wide distributed implementation of the experimental setup in Sec. VI and testbed (GENI), and illustrate some results for the use case of finally Sec.
    [Show full text]
  • Mobility Vs Multihoming
    Mobility vs Multihoming Naveen Gundu Helsinki University of Technology Telecommunications Software and Multimedia Laboratory [email protected] Abstract example, In multihoming user subscribes different ISPs and networks for different services. User views different options In current scenario, use of mobile and Internet has been like cost effective, secure, quality service from one ISP and increasing and the increasing number of users are coming others. forward to use new services like mobility and multihom- The analysis of this paper presents the idea behind the mo- ing. Roaming users are interested to stay connected with bility and multihoming. The solutions provided with mobile network while moving from one network to another net- IP and layer 4 for both services and how these protocol so- work with multiple network interfaces e.g. WLAN and lutions are trying to fulfill the requirements. It also gives GPRS.Problems which might arise when mobile host moves difference between them. from one network to another network. Some mobility so- lutions have been introduced to ensure connections between networks,e.g., Mobile IPv4 & IPv6. 2 Background This paper gives a brief functional description of multi- homing and mobility, given requirements, problems associ- Here gives an overview about mobility and multihoming at ated with them, related solution to fulfill each requirements end host and site point of view. And also discusses problems and finally comparison between them. and requirements for further discussion. KEYWORDS: Mobility, Mobile IP, Multihoming, Routing, Site Multihoming, Host Multihoming, Node/end-host, ISP. 2.1 Multihoming Multihoming refers to a situation where an end-host having several parallel communication paths that it can use [4].
    [Show full text]
  • A Security Framework for the Internet of Things in the Future Internet Architecture
    Article A Security Framework for the Internet of Things in the Future Internet Architecture Xiruo Liu 1, Meiyuan Zhao 2, Sugang Li 3, Feixiong Zhang 3 and Wade Trappe 3,* 1 Intel Labs, Hillsboro, OR 97124, USA; [email protected] 2 Google, Mountain View, CA 94043, USA; [email protected] 3 Department of Electrical and Computer Engineering, Rutgers University, Piscataway, NJ 08854, USA; [email protected] (S.L.); [email protected] (F.Z.) * Correspondence: [email protected]; Tel.: +1-848-932-0909 Academic Editors: Georgios Kambourakis and Constantinos Kolias Received: 5 June 2017; Accepted: 25 June 2017; Published: 28 June 2017 Abstract: The Internet of Things (IoT) is a recent trend that extends the boundary of the Internet to include a wide variety of computing devices. Connecting many stand-alone IoT systems through the Internet introduces many challenges, with security being front-and-center since much of the collected information will be exposed to a wide and often unknown audience. Unfortunately, due to the intrinsic capability limits of low-end IoT devices, which account for a majority of the IoT end hosts, many traditional security methods cannot be applied to secure IoT systems, which open a door for attacks and exploits directed both against IoT services and the broader Internet. This paper addresses this issue by introducing a unified IoT framework based on the MobilityFirst future Internet architecture that explicitly focuses on supporting security for the IoT. Our design integrates local IoT systems into the global Internet without losing usability, interoperability and security protection. Specifically, we introduced an IoT middleware layer that connects heterogeneous hardware in local IoT systems to the global MobilityFirst network.
    [Show full text]
  • Fast Authentication and Trust-Based Access Control in Heterogeneous Wireless Networks Maryna Komarova
    Fast authentication and trust-based access control in heterogeneous wireless networks Maryna Komarova To cite this version: Maryna Komarova. Fast authentication and trust-based access control in heterogeneous wireless net- works. domain_other. Télécom ParisTech, 2008. English. pastel-00003793 HAL Id: pastel-00003793 https://pastel.archives-ouvertes.fr/pastel-00003793 Submitted on 9 Jan 2009 HAL is a multi-disciplinary open access L’archive ouverte pluridisciplinaire HAL, est archive for the deposit and dissemination of sci- destinée au dépôt et à la diffusion de documents entific research documents, whether they are pub- scientifiques de niveau recherche, publiés ou non, lished or not. The documents may come from émanant des établissements d’enseignement et de teaching and research institutions in France or recherche français ou étrangers, des laboratoires abroad, or from public or private research centers. publics ou privés. Thèse Présenté pour obtenir le grade de docteur de Telecom-ParisTech Spécialité : Informatique et Réseaux par Maryna Komarova Sujet: AUTHENTIFICATION RAPIDE ET CONTROLE D’ACCES BASE SUR LA CONFIANCE DANS LES RESEAUX SANS FIL HETEROGENES Soutenue le 19 mai 2008 devant le jury composé de : Fabio Martinelli Istituto di Informatica e Telematica Rapporteur Isabelle Chrisment Université Henri Poincaré (Nancy 1) Rapporteur Xavier Lagrange TELECOM Bretagne Examinateur Jean Leneutre TELECOM ParisTech Examinateur Michel Riguidel TELECOM ParisTech Directeur de thèse PhD Thesis Presented to obtain the degree of PhD at the Computer
    [Show full text]