Map and Encapsulation

This subsection details proposals that implement the locator-identifier split paradigm through mapping and encapsulation mechanisms.

2.8 Hybrid Multihoming

2.8.4.1 LISP Mobile Node

LISP-Mobile Node [Farinacci et al., 2012] is a version of LISP that targets mobile nodes. Some of the functionalities of Ingress and Egress Tunnel routers of LISP are placed on the mobile node. As such, the node has capabilities of handling mobility without the assistance of servers in the network. LISP Mobile nodes behave as a LISP site, up- dating locators in the associated mapping system when performing handovers. The identifiers (EID), also employed in LISP, do not change and are used in all the connec- tions of the LISP Mobile Node.

ISP2 ISP1 1 2 3 4 src S dst D

1 - new RLOC {RLOC2}

2 - Solicit-Map-Request {EID_S,RLOC2} 3 - Map-Request {EID_S,RLOC2} 4 - Map-Reply {EID_S,RLOC2}

EID - Endpoint Identifier RLOC - Routing Locator SMR - Solicit Map Request

Figure 2.8: LISP Mobile Node handover

As pictured in Figure 2.8, LISP Mobile Node (node S), receives a new Routing Lo- cator (RLOC), when connecting to ISP2. Afterwards, the respective mappings need to be updated. For such, the MN sends a solicit-map-request message, which is inter- cepted by next-hop LISP routers which, in turn, forward the message as map-request to the mapping server, which replies with a map-reply message. Nodes must be com- pliant with the LISP Mobile node specification, nevertheless, a mapping server can be employed to allow the communication with non LISP nodes. Moreover, the proposal has an implementation available [Farinacci et al., 2013].

2.8.4.2 Unmanaged Internet Architecture

Unmanaged Internet Architecture (UIA) [Ford, 2008] is compatible with current IP architecture and can be incrementally deployed. UIA targets personal devices and specifies a transport protocol - the structure stream transport to enable efficient trans- port of streams. This transport protocol has the advantage of supportting transactions like HTTP, nevertheless it does not have multihoming features like SCTP does (e.g. primary-backup model). UIA integrates a routing architecture that enables peer de-

vices to communicate in an ad-hoc way. Moreover, security and privacy are included natively. Distributed hash tables are employed to hold the mappings of locators and identifiers.

2.8.4.3 Delegation Oriented Approach

Delegation Oriented Approach (DOA) [Walfish et al., 2004] focuses on the specifica- tion on middleboxes (e.g. NAT, firewalls) to eliminate their side-effects (e.g. alter or hinder end-to-end communication between peers) and to facilitate implementation. DOA provides identifiers to hosts and means to end-nodes to perform delegation (if packets should be/or not sent off-path boxes). The Endpoint IDentifier (EID) identi- fies the end-node, while the IP address is employed as a locator. EIDs, acting as global identifiers, are generated with public keys and are placed into each packet. Mappings can be in the tuple EID, IP address or EID to a list of EIDs. The latter one reflects the nodes on which the packet goes through the delegated nodes before reaching desti- nation. DOA implements security mechanisms, since EIDs can only be modified by the respective end-nodes. Nevertheless, it does not include mechanisms to update locators in mobility events [Paul et al., 2009].

2.8.4.4 Six/One Router

Six/One router [Vogt, 2008] introduces the translation between provider-independent and provider-dependent addresses. Six/One router has some similarities with SHIM6 as it uses one of the locators for the node identity during the session and only targets IPv6 networks. The translation of addresses is assured by specific hardware that per- forms translation of network source and destination addresses. If the mapping holds records for source and destination addresses, Six/One can support multihoming and mobility, nevertheless mapping must be assured by an external specification such as DNS. One major advantage of Six/One is communicating with non Six/One routers [Clevenger, 2010] and the reduced size of the routing table and the update frequency. Flow diversity is enabled in Six/One with the extended proposal [Paul et al., 2010a] that adds monitoring features and inform upper layers (e.g. TCP) on the best perfor- mant paths.

2.8.4.5 Old and non-standard proposals

The Internet Indirection Infrastruture (I3) [Stoica et al., 2004] is among the first Loc/ID split approaches, where packets contain data and identifiers. A server holds the role

2.8 Hybrid Multihoming

of mapping identifiers to locators. The namespace is based on DHTs, and I3 employs the concept of triggers to announce services (e.g. web-service). Nonetheless, I3 is prone to security issues, namely, denial-of-service attacks. With this in mind, secure- I3 [Adkins et al., 2003] has been proposed, with the principle of hiding end-node ad- dresses. Host identity indirection infrastructure (Hi3) [Gurtov et al., 2008] combines secure-I3 and HIP and introduces better multihoming support by introducing identi- fier layers for service and hosts. Dynamic Recursive Unified Internet Design (DRUID) [Touch et al., 2011] is an architecture where the data, control, management and se- curity planes are unified, so that different planes can act coordinated in the presence of events (attacks, failures, etc). Another proposal with enhanced security support but with limited multihoming capabilities is the Split Naming/Forwarding (SNF) ar- chitecture [Jonsson et al., 2003] that includes three namespaces: the FQDN acting as identifiers, locators based on IP addresses, and Ephemeral Correspondent Identifier (ECI) used to identify packets, which avoid sending identifiers. SNF, in comparison to DRUID, supports mobility but has no resilience built-in mechanism. Some proposals, like the HIP Mobile Router (HIP-MR) [Ylitalo et al., 2008] extend protocols to enable hybrid multihoming support. For instance, in HIP-MR the mobile router maintains bindings of the mobile nodes, so that on mobility events peers can be updated with the location of mobile nodes. Nonetheless, this type of solution is limited to nodes supporting the extended protocol, in the case of HIP-MR, HIP nodes. General In- ternet Signaling Transport (GIST) Overlay Networking Extension, or GONE [Fu and Crowcroft, 2006], also combines multiple protocols such as GIST, SCTP and HIP to en- able support for multihoming and resilience against failures and DoS attacks. GONE, in comparison to HIP-MR, supports all multihoming goals, but has the disadvantage of introducing signalling overhead. Some proposals focus on supporting multiple technologies. For instance, Spontaneous Virtual Networks (SpotVNet) [Roland Bless and Waldhorst, 2011] supports Bluetooth and others by employing cross-layer mech- anisms. However, such characteristic does not enhance multihoming support.

Hybrid multihoming proposals can follow a map and encapsulation approach as summarized in Table 2.12. LISP-MN [Farinacci et al., 2012] extends LISP [Dave, 2008] to enhance mobile nodes capabilities, regarding mobility and multihoming sup- port. HIP Mobile Router [Ylitalo et al., 2008] extends HIP to support end-site mul- tihoming. Proposals like Six/One router [Vogt, 2008] are limited as they only apply to IPv6. DRUID [Touch et al., 2011] presents a unified coordination in the presence of events. Despite following Loc/ID split paradigm, DRUID fails to be a complete specification (e.g. mapping system details). Tailored for events, I3 [Stoica et al., 2004]

Table 2.12: Hybrid multihoming proposals with map and encapsulation approach.

MH-Multihoming, OS-Operating Systems.

Protocol MH Goals Strengths Flaws Implementation

R U L F OS

LISP-MN √ √ X X Mobility No Load

sharing

LISPMoba

HIP MR √ √ X X Security Only

HIP-aware nodes Linuxb DRUID √ X X X Includes trustiness. No mobility support – I3 √ √ X X Multicast/ anycast services. Security issues Linuxc

DOA √ X X X Security No mobility –

Six/One Router √ √ √ √ Flow distribution support

Only for IPv6 –

SNF X √ X X Security Limited resilience support – SpotVNet √ √ X X Incremental deployment Limited multihoming. – GONE √ √ √ √ Multihoming support Signaling overhead Linuxd a_{[Farinacci et al., 2013]} b _{[OpenHIP, 2012]} c_{[Adkins, 2006]} d_{[Demter and Fu, 2006]}

introduces the concept of triggers, which end-hosts must use to indicate their interest in certain data (e.g. web-service). I3 but has been extended by secure-I3 [Adkins et al., 2003] and Hi3 [Gurtov et al., 2008] to improve security. SNF [Jonsson et al., 2003] intro- duces translation gateways to enable communication between domains, and supports security but, similarly to Delegation Oriented Approach (DOA) [Walfish et al., 2004], it does not support mobility. Some proposals aim to allow incremental deployments, as such, for example, SpotVNet [Roland Bless and Waldhorst, 2011]. Unfortunately, multihoming support for current architectures is not very advanced. For instance,

2.8 Hybrid Multihoming

resilience and flow distribution are not supported. Other proposals, like GONE [Fu and Crowcroft, 2006], combine several protocols for an efficient multihoming support , which however may introduce significant signalling overhead.