Internet DRAFT - draft-herbert-ila-motivation

draft-herbert-ila-motivation



 



INTERNET-DRAFT                                                T. Herbert
Intended Status: Informational                                Quantonium
Expires: July 2018                                                      
                                                                        
                                                        January 22, 2018


Identifier Locator Addressing: Problem areas, Motivation, and Use Cases
                    draft-herbert-ila-motivation-00



Abstract

   This document describes the problems, motivation, and use cases for
   Identifier-Locator Addressing.

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as
   Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/1id-abstracts.html

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html


Copyright and License Notice

   Copyright (c) 2018 IETF Trust and the persons identified as the
   document authors. All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document. Please review these documents
 


T. Herbert               Expires July 26, 2018                  [Page 1]

INTERNET DRAFT        draft-herbert-ila-motivation                      


   carefully, as they describe your rights and restrictions with respect
   to this document. Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.


Table of Contents

   1  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2  Problem areas . . . . . . . . . . . . . . . . . . . . . . . . .  3
     2.1  Identifier/locator split  . . . . . . . . . . . . . . . . .  3
     2.2  Efficiency of network overlay techniques  . . . . . . . . .  3
     2.3  Ramifications of network tunneling  . . . . . . . . . . . .  4
     2.4  Networking hardware compatibility . . . . . . . . . . . . .  4
     2.5  Mobility  . . . . . . . . . . . . . . . . . . . . . . . . .  5
     2.6  Mapping systems . . . . . . . . . . . . . . . . . . . . . .  5
       2.6.1 Nodes with complete set of mappings  . . . . . . . . . .  5
       2.6.2 Mapping caches . . . . . . . . . . . . . . . . . . . . .  5
     2.7  Privacy . . . . . . . . . . . . . . . . . . . . . . . . . .  6
       2.7.1 Geo-location . . . . . . . . . . . . . . . . . . . . . .  6
       2.7.2 Privacy in addresses . . . . . . . . . . . . . . . . . .  7
     2.8  Address assignment  . . . . . . . . . . . . . . . . . . . .  8
     2.9  Scaling . . . . . . . . . . . . . . . . . . . . . . . . . .  9
     2.10 Security  . . . . . . . . . . . . . . . . . . . . . . . . . 10
       2.10.1 Mapping information . . . . . . . . . . . . . . . . . . 10
       2.10.2 Mapping protocols . . . . . . . . . . . . . . . . . . . 10
     2.12 ICMP  . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     2.13 Multicast . . . . . . . . . . . . . . . . . . . . . . . . . 11
   3  Motivation for ILA  . . . . . . . . . . . . . . . . . . . . . . 11
     3.1  Alternative network overlay technologies  . . . . . . . . . 11
       3.1.1 ILNP . . . . . . . . . . . . . . . . . . . . . . . . . . 11
       3.1.2 Encapsulation  . . . . . . . . . . . . . . . . . . . . . 12
       3.1.3 Segment routing  . . . . . . . . . . . . . . . . . . . . 13
       3.1.4 Network Address Translation  . . . . . . . . . . . . . . 13
       3.1.5 Transport layer mechanisms . . . . . . . . . . . . . . . 14
     3.2  Benefits of ILA . . . . . . . . . . . . . . . . . . . . . . 14
     3.3  Limitations and caveats of ILA  . . . . . . . . . . . . . . 16
   4  Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
     4.1  Mobility networks . . . . . . . . . . . . . . . . . . . . . 16
     4.2  Datacenter virtualization . . . . . . . . . . . . . . . . . 17
     4.3  Network virtualization  . . . . . . . . . . . . . . . . . . 17
   5  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 17
     5.1  Normative References  . . . . . . . . . . . . . . . . . . . 17
     5.2  Informative References  . . . . . . . . . . . . . . . . . . 17
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17


 


T. Herbert               Expires July 26, 2018                  [Page 2]

INTERNET DRAFT        draft-herbert-ila-motivation                      


1  Introduction

   Identifier-locator addressing (ILA) is a protocol based on
   identifier/locator split that provides network overlays without the
   use of encapsulation or extension headers. ILA operates at the
   network layer and is intended to be transparent to both applications
   and transport layer protocols.

   This document highlights problem areas, motivation, and use cases of
   ILA. Problem areas include protocol efficiency, scalability,
   mobility, privacy, and security for network overlays and
   identifier/locator split. The motivation for ILA is provided in terms
   of how ILA addresses the problems and its advantages over alternative
   approaches. The use cases of ILA include mobility, datacenter
   virtualization, and network virtualization; some details and
   considerations for these use cases are provided. 

2  Problem areas

   This section highlights some of the problems faced for use of
   identifier/locator split and network overlays.

2.1  Identifier/locator split

   Identifier/locator split is a technique that has long been discussed
   within IETF. This is the answer to the problem that IP addresses have
   traditionally been overloaded with two characteristics: they indicate
   both the identity of a node and its location. Identifier/locator
   split endeavors to separate these two notions. A node has identity
   and location, but they are separate elements in addressing. This
   disassociation of identity and location allows nodes to become
   "virtual" and mobile. This distinction has been made in network
   virtualization and mobility networks for some time, however demand
   for mobility and virtualization is continuously increasing so that in
   the future a majority of nodes might be virtualized and subject to
   identifier/locator split.

   Deployment of identifier/locator split in existing networks can raise
   a number of issues. Since addresses no longer contain location,
   routing needs to change and routing tables need to scale to include
   many more destinations. Logging and tools also need to change to take
   into account that location and identity may be separate notions in an
   address.

2.2  Efficiency of network overlay techniques

   With the emergence of applications such as AR, VR, machine learning,
   and road safety information, the demands for low latency, high
 


T. Herbert               Expires July 26, 2018                  [Page 3]

INTERNET DRAFT        draft-herbert-ila-motivation                      


   throughput, and highly reliable networking are only increasing. Low
   latency networking is no longer confined to the purview of
   specialized application centric networks, requirements for very low
   latency are being introduced into public access networking
   technologies such as 5G. As such, the efficiency and performance of
   network overlays becomes important. 

   Network overlays are a benefit since they facilitates node mobility
   and malleability in use of network resources. These benefits tend to
   be architectural in the network and not necessarily obvious to the
   users or applications in the network. For instance, network overlays
   facilitate mobility, however the cost of that capability to
   applications must be taken into a account. Mobility is likely a rare
   event, and there are many nodes that will never move during their
   lifetime. When a node is not moving, the cost incurred for having the
   capability to move should be near zero.

2.3  Ramifications of network tunneling

   The ramifications and issues with tunneling in the network have been
   well documented and discussed in IETF.

   If encapsulation is being used in the network to implement a tunnel
   then the packet size increases so exceeding the MTU is a concern;
   [RFC4459] discusses MTU and fragmentation considerations for network
   tunneling. [RFC2983] discusses the interactions of differentiated
   services with tunnels and procedures to translate diffserv for an
   inner packet to the outer one. [RFC6040] specifies handling of
   Explicit Congestion Notification in a tunnel. [RFC6935] and [RFC6936]
   discuss at length the requirements that must be meant for allowing a
   zero UDPv6 checksum to be used for tunnels.

   The upshot is that defining and correctly implementing tunnels in the
   network is a nontrivial exercise. 

2.4  Networking hardware compatibility

   The effects of deploying a protocol with existing network hardware
   implementation must be considered. Generally, hardware
   implementations (switches, router, NICs, etc.) are optimized for
   certain protocols and protocol features. Most devices implement
   optimizations for the two most common transport protocols, namely TCP
   and UDP. These optimizations include features like ECMP, checksum
   offload, and segmentation offload. As one moves away from use of
   commonly supported protocols, the benefits of optimizations and even
   feasibility of protocols or protocol features dwindles. For example,
   IPv6 extension headers have had a checkered history of being properly
   supported by intermediate nodes, and hence are considered precarious
 


T. Herbert               Expires July 26, 2018                  [Page 4]

INTERNET DRAFT        draft-herbert-ila-motivation                      


   for use on the Internet [RFC7872].

   Note that many new encapsulation protocols (GUE, GRE/UDP, LISP,
   Geneve, etc.) employ encapsulation in UDP. The use of UDP makes
   packets more palatable to network devices, albeit at the cost of UDP
   header overhead and additional processing overhead. 

2.5  Mobility

   For seamless mobility, a node retains its IP address and connections
   remain established across mobile events. If network mobility is
   handled in the network layer then moving should be transparent to the
   application with only the possibly that latency is increased for a
   few packets.

   Mobility is present in different use cases whenever a node changes
   its point of attachment in the network. When this happens the
   location of the node and hence its locator changes. A key attribute
   of an identifier/locator solution is how the network converges when a
   change occurs. During the convergence period, latency is expected to
   be bounded and packet loss is expected to be minimized or avoided
   entirely.

2.6  Mapping systems

   Identifier/locator split solutions employ a mapping system that
   provides identifier to locator mappings. Similar to IP routing, there
   may be both nodes that maintain a full list of mappings (analogous to
   core routers) and nodes that maintain a cache of mappings (analogous
   to nodes with a neighbor discovery cache).

2.6.1 Nodes with complete set of mappings

   The complete set of mappings in a network might be sharded across
   some number of nodes. Each node maintains a complete list of mappings
   for their respective shard. Furthermore, each shard may be replicated
   on several nodes for redundancy and load balancing. All the nodes for
   a shard must synchronize information upon changes using a protocol
   amongst themselves. The time it takes for all nodes to converge when
   a change happens can correlate to perceived application latency. 

2.6.2 Mapping caches

   Anchorless mobility is a goal of identifier/locator split. For
   achieving low latency, direct routing is preferred. Forwarding nodes
   that contain a cache of mapping entries may be deployed at or near
   source hosts to optimize forwarding. These nodes maintain a cache of
   mapping entries used to directly forward packet to peers in the same
 


T. Herbert               Expires July 26, 2018                  [Page 5]

INTERNET DRAFT        draft-herbert-ila-motivation                      


   identifier/locator domain. The use of a cache avoids triangular
   routing through an intermediate device that has a complete list of
   mappings.

   Mapping caches may be populated either by "push" or "pull" model. In
   the push model, nodes are informed of changes to the mappings for
   nodes they are interested in. A node may register to get
   notifications of changes from authoritative nodes in the mapping
   system. This is the pub/sub model. In the pull model, a node queries
   an authoritative node to resolve a mapping for an identifier it is
   interested in; typically this is done on demand when a packet is
   being forwarded to a destination address whose mapping is yet not in
   the cache.

   Both the pull model and push model have their advantages and
   disadvantages. The push model (aka pub/sub) should result in faster
   and more accurate convergence, however may require more
   communications and be harder to scale than the pull model. The pull
   model may be more susceptible to Denial of Service attack.

   Secure redirects are hybrid of the push and pull model. A cache entry
   is populated by an authoritative node that is forwarding a packet.
   This "redirect" eliminates triangular routing from the source to the
   destination. Redirects must be secure since to prevent destination
   hijacking.

2.7  Privacy

   Identifier/locator split can benefit user privacy, particularly in
   what is exposed in IP addresses. The benefit is only viable if
   locators that imply geo-location and identities are not revealed to
   untrusted parties.

2.7.1 Geo-location

   An effect of identifier/locator split is that location is no longer
   an inherent component of IP addresses. This is a benefit to user
   privacy as it can reduce the inference of geo-location of a user
   based on IP addresses. However, strong privacy implies that locators,
   which could very well reveal geo-location, are only visible to
   trusted entities.

   Conceivably, an identifier-locator protocol could be run at the end
   user devices in a public network (e.g. UEs in a mobile network). This
   section provides a privacy argument against that.

   The major problem with running an identifier/locator protocol on end
   user devices is that the devices are not controlled by the network
 


T. Herbert               Expires July 26, 2018                  [Page 6]

INTERNET DRAFT        draft-herbert-ila-motivation                      


   infrastructure. User devices on a public network, such as Android
   devices, can easily be hacked to allow root access to the device.
   Once a user has root access they can install any program they wish on
   the device including those that could disable or circumvent security
   or accounting related to identifier/locator split protocol.

   If root access can be gained on an end user device, this leads to the
   stalker problem which would be a very easy means to track
   individuals. This exploit is described below:

      * Suppose that a user device participates in an identifier/locator
        split protocol such that they cache locators and use locators to
        directly send to peer devices.

      * A hacker might tap all packets sent or received on the network
        interfaces which makes locators visible to them. 

      * In order to be able to tap packets, a user needs root access to
        the device. There are instructions on the web to root an Android
        device. Similarly, jailbreaking can be done to circumvent
        restrictions on an iPhone to gain the equivalent of root access.

      * Once root access has been obtained, packets can be tapped using
        tcpdump or similar packet sniffer applications.

      * With the tap running and packet addresses being captured, the
        hacker just needs to drive around sendimg traffic between two
        devices in their car. They can observe the locators that are
        assigned to the their device, and from this can create a geo map
        of locators.

      * Given that one hacker can do this, then thousands will do it and
        web sites will spring up that provide locator geo maps. Efforts
        to obfuscate or rotate identifiers does not help much here.
        Obfuscation complicates routing in the network such that more
        transformations need to happen there. Locator rotation is
        defeated if there are enough devices to keep the maps up to date
        in a mashup.

      * The net effect is that this enables a stalker attack. An
        individual simply initiates a communication with their target.
        For instance, this could be a chat or phone call. If in doing
        this the locators for the device belonging to the target are
        made visible to the hacker, then the physical location of the
        target can be deduced using the locator geo maps described
        above.

2.7.2 Privacy in addresses
 


T. Herbert               Expires July 26, 2018                  [Page 7]

INTERNET DRAFT        draft-herbert-ila-motivation                      


   A node may use multiple addresses to prevent inferences by third
   parties that break privacy. Properties of addresses to maintain
   strong privacy are:

      * They are composed of a global routing prefix and a suffix that
        is internal to an organization or provider. This is the same
        property for IP addresses [RFC3513].

      * The registry and organization of an address can be determined by
        the network prefix. This is true for any global address.

      * The organizational bits in the address should have minimal
        hierarchy to prevent inference. It might be reasonable to have
        an internal prefix that divides identifiers based on broad
        geographic regions, but detailed information such as accurate
        location, department in an enterprise, or device type should not
        be encoded in a globally visible address.

      * Given two addresses and no other information, the desired
        properties of correlating them are:

         * It can be inferred if they belong the same organization and
           registry. This is true for any two global IP addresses.

         * It may be inferred that they belong to the same broad
           grouping, such as a geographic region, if the information is
           encoded in the organizational bits of the address (e.g. are
           in the same shard).

         * No other correlation can be established. For example, it
           cannot be inferred that the IP addresses address the same
           node, the addressed nodes reside in the same subnet, rack, or
           department, or that the nodes for the two addresses have any
           geographic proximity to one another.

2.8  Address assignment

   In an identifier/locator split protocol, end hosts are assigned
   addresses that serve as identifiers. A device may be assigned a
   network prefix or singleton addresses.

   A end host may be assigned a /64 address via SLAAC as is common in
   many provider networks. In this scenario, the low order sixty-four
   bits contains IIDs arbitrarily assigned by devices for its purposes;
   so these bits cannot be used as an identifier in identifier/locator
   split. Effectively, the upper sixty-four bits is the identifier of
   the node.

 


T. Herbert               Expires July 26, 2018                  [Page 8]

INTERNET DRAFT        draft-herbert-ila-motivation                      


   Ostensibly, assigning a /64 prefix to a node is good for security.
   The end device can create its own random addresses in the low order
   sixty-four bits which mitigates address scanning attacks. However,
   the upper sixty for bits of the address become a static identifier
   for the device which potentially allows DOS on the device as well as
   correlating different addresses in the Internet as being sourced from
   the same device.

   [RFC4941] recommends rotating addresses to protect privacy. In the
   case of sixty-four bit address assignments this would entail that a
   new prefix for the device is periodically requested. There is no
   recommendation for the frequency of address change and there is no
   quantitative description of the effects of periodic address change.

   The following exploit is proposed to defeat the privacy goal of
   periodic address rotation:

      * An attacker creates an "always connected" app that provides some
        seemingly benign service so that users download the app.

      * The app includes some sort of persistent identity. For instance,
        this could be an account login.

      * The backend server for the app logs the user identity and IP
        address each time a user connects.

      * When an address change happens, existing connections on the user
        device are disconnected. The app will receive a notification and
        immediately attempt to reconnect using the new source address.

      * The backend server will see the new connection and log the new
        IP address as being used by the user. Thus, the server has a
        real-time record of users and the IP addresses they are using.

      * The attacker gains access to packet traces taken at some point
        in the Internet. The addresses in the captured packets can be
        time correlated with the server database to deduce the identity
        of the source of packets for communications completely unrelated
        to the app.

   This exploit would defeat address rotation with any frequency except
   the for case that that a different source address is used for each
   flow.

2.9  Scaling

   Since identity is no longer associated with location, each node
   becomes separately routable in the network. In identifier/locator
 


T. Herbert               Expires July 26, 2018                  [Page 9]

INTERNET DRAFT        draft-herbert-ila-motivation                      


   split, a table that maps identifiers to locators is maintained. Each
   destination effectively becomes a host route, and hierarchical
   routing is generally not usable. For instance, a VM may have a
   virtual address and might be located anywhere in a network. The
   mapping table would contain a mapping of the virtual address of the
   VM to the physical address of the server where the VM is running.

   The number of virtualized or mobile nodes in a network is expected to
   grow into the billions. This need for scaling is similar in both
   mobile networks as well as datacenter and multi-tenant virtual
   networks. In mobile networks, the explosion of IoT devices drives
   scaling growth. In the datacenter it is the desire to use fine
   grained addresses for tasks or more generally addressable virtual
   objects.

2.10 Security

2.10.1 Mapping information

   An identifier/locator solution will contain sensitive information
   that includes identity and location of nodes. In the case that there
   is a one-to-one correspondence between a network node and user, for
   instance the node is a smart phone owned by an individual, this
   information is Personally Identifiable Information (PII). A mapping
   system needs to ensure security of this information.

2.10.2 Mapping protocols

   Mapping protocols have a couple of security ramifications.

   A mapping protocol must be authenticated in order to prevent spoofing
   of messages. In particular, an attacker cannot be able to hijack a
   mapping entry to redirect packets to their own node.

   A mapping protocol must also be resilient to DOS attack, especially
   in a scenario where a cache of mappings is being employed. Such a
   cache might be populated in response to the activities of a third
   party (for instance an application sending packets to different
   destinations). An attack on the cache whereby an attacker attempts to
   fill the cache with entries to random destinations must be
   mitigated.

2.12 ICMP

   ICMP presents problems for network overlays as well as
   identifier/locator split. Specifically, the problem is how to return
   ICMP errors to the sender that were caused as a result of using a
   network overlay. ICMP errors that are returned to the source may
 


T. Herbert               Expires July 26, 2018                 [Page 10]

INTERNET DRAFT        draft-herbert-ila-motivation                      


   require translation of address in the ICMP data or other
   modifications. There may also be security ramifications with ICMP,
   for instance filtering ICMP may be necessary to prevent locator
   information from leaking out of a network.

2.13 Multicast

   Multicast is problematic in identifier/locator split since the
   routing depends on the source address of a packet. If using the
   network layer multicast, the source address must be a locator not an
   identifier.

3  Motivation for ILA

3.1  Alternative network overlay technologies

   A number of solutions for network overlays have be been defined or
   proposed in IETF. This section considers layer 3 network overlay
   solutions, and a few related layer 4 solutions for comparison. An
   overview of each is provided along with a description of how they
   deal with the problems enumerated in section 2 and where they are
   deficient.

3.1.1 ILNP

   Identifier-Locator Network Protocol (ILNP) is similar to ILA and in
   fact some of the concepts of ILA were adapted from ILNP.

   ILNP explicitly replaces the use of IP Addresses with two distinct
   name spaces, each having distinct and different semantics:

      a) Identifier: a non-topological name for uniquely identifying a
         node.

      b) Locator: a topologically bound name for an IP subnetwork.

   Characteristics of ILNP are:

      * ILNP changes the meaning of IP addresses. 

      * ILNP requires changes to transport layer protocols. Transport
        layer endpoints are no longer IP addresses they are identifier
        values.

      * The pseudo header for TCP and UDP checksum changes. This might
        break intermediate nodes that perform checkusm calculation such
        as NICs that provides checksum offload.

 


T. Herbert               Expires July 26, 2018                 [Page 11]

INTERNET DRAFT        draft-herbert-ila-motivation                      


      * ILNP is an end to end overlay mechanism. There is no prescribed
        method to use ILNP in intermediate nodes.

      * ILNP defines a Nonce in Destination Options extension header.

      * ILNP requires applications to use fully qualified domain names.
        Applications that use IP addresses presumably need to change.

3.1.2 Encapsulation

   Various encapsulation techniques are used to achieve layer 3 network
   overlays. These includes IPIP, LISP, GRE, VXLAN, GUE, GTP-U, Geneve,
   etc. These encapsulation protocols provide the means to create
   overlays over IP networks via IP over IP encapsulation. They differ
   in format and extensibility. For instance, IPIP is the simplest
   method that just encapsulates one IP packet in another. GUE is a UDP
   based encapsulation that is both generic and extensible.

   Characteristics of encapsulation are:

      * While encapsulation has proven functional and useful, it incurs
        significant on-the-wire overhead, require substantial
        processing, and may be incompatible with transport layer
        specific network optimizations for TCP and UDP

      * Outer IP header overhead. Adoption of IPv6 exacerbates the
        overhead of encapsulation. Where simple IPv4 over IPv4
        encapsulation has an overhead of twenty bytes, IPv6 or IPv4 over
        IPv6 incurs overhead of forty bytes.

      * Possible additional header overhead if UDP is used or there is
        an encapsulation header

      * Can be used at intermediate nodes for tunneling, so all the
        issues involving tunneling must be addressed.

      * Compatibility with hardware is an issue. UDP based encapsulation
        overcomes some of the issues, but in itself creates new ones.

      * Checksum handling must be considered in various contexts.
        Encapsulation may break checksum offload feature commonly
        implemented in NICs. Some network devices are incapable of
        computing checksums, so if UDPv6 is used the checksum is often
        set to zero. Some protocols allow a non-zero UDP checksum to be
        ignored during reception in violation of [RFC1122].

      * Issues around tunneling within the network have to be addressed
        (described in section 2.3). These include dealing with MTU, IPv6
 


T. Herbert               Expires July 26, 2018                 [Page 12]

INTERNET DRAFT        draft-herbert-ila-motivation                      


        checksum, traceroute, ECN, and how to translate diffserv from an
        inner header to an outer header.

      * Encapsulation can be used in the network or at end hosts and
        doesn't require any changes to transport layer implementation.

3.1.3 Segment routing

   Segment routing (SR) has been proposed as a method to provide
   identifier/locator split for mobile networks. SR leverages the source
   routing paradigm.  A node steers a packet through an ordered list of
   instructions, called segments.  A segment can represent any
   instruction, topological or service-based.  A segment can have a
   semantic local to an SR node or global within an SR domain

   Characteristics of segment routing are:

      * Requires use of extension headers, specifically a routing
        header.

      * [RFC820] prohibits extension header insertion at intermediate
        nodes. Encapsulation is required at ingress intermediate node to
        use segment routing.

      * The segment header itself be significant overhead. A segment
        routing header with just a single address would be twenty four
        bytes of overhead.

      * Transport layer checksum is not kept correct when destination
        address is changed. This could break checksum offload. 

      * Transport layer checksum does not protect the segment routing
        header, so additional overhead is needed to detect corruption of
        the SR header.

      * Extension headers are not transparent to intermediate nodes and
        this may cause incompatibility with network hardware
        implementation resulting in loss of optimizations or relegation
        to slow path processing.


3.1.4 Network Address Translation

   ILA is similar to NAT (address translation not port translation) in
   that it operates by rewriting the destination address of packet en
   route. However, the transformation by ILA is always undone before the
   packet is delivered to its ultimate destination.

 


T. Herbert               Expires July 26, 2018                 [Page 13]

INTERNET DRAFT        draft-herbert-ila-motivation                      


   Characteristics of NAT:

      * No additional header overhead. Checksum neutral mapping might be
        used to maintain correct transport layer checksum.

      * Not useful as an overlay mechanism since NAT translation is not
        undone before reception at a receiver

3.1.5 Transport layer mechanisms

   There are a number of techniques used in the transport layer or
   applications to handle mobility. Strictly speaking, these are not
   network overlay techniques, however they can be used to provide
   similar effects in mobility.

   The simplest way to deal with an address change is just to require an
   application to reconnect when a connection is disconnected. This is
   not transparent to an application, it must have a method to
   checkpoint progress on the connection and implement the reconnect
   logic (this could be handled in a library). The latency to detect
   that a connection is dead, reconnect, and then recover to a
   checkpoint is likely much greater than that of a transparent network
   layer solution.

   Alternatively, a transport protocol may employ subflows to construct
   a logical flow. This is the technique used by MPTCP and QUIC. These
   techniques are transport layer specific, tend to be driven by one
   sided, and require network layer information.

   Proxies can also provide network overlay semantics. However, they
   require statefulness in the network that creates single point of
   failure and a potential bottleneck.

3.2  Benefits of ILA

   This section enumerates the benefits of ILA and highlights how the
   problems described in section 3 are addressed.

      * ILA has zero on-the-wire overhead.

      * Processing for ILA is efficient. A basic ILA transformation is
        done by reading the destination address in a packet, performing
        a fixed length lookup, and writing the destination address with
        found locator.

      * ILA does not employing tunneling so considerations for network
        tunneling are not a concern.

 


T. Herbert               Expires July 26, 2018                 [Page 14]

INTERNET DRAFT        draft-herbert-ila-motivation                      


      * The ILA domain is effectively a virtual link layer or an
        underlay network for the traffic being carried between hosts
        outside of the ILA domain. As long as the ILA domain is
        perfectly transparent to the overlay network and its hosts, then
        what ever happens within the ILA domain doesn't matter, similar
        to how link layer compression, as long as fully and perfectly
        reversed, also doesn't matter.

      * ILA maintains a correct transport layer checksum via checksum
        neutral mapping.

      * ILA can be deployed either in the network or on end hosts. When
        deployed at end hosts, certain optimizations are available since
        ILA is integrated into the host stack

      * ILA is implemented at network layer. It requires no changes to
        either applications or transport layer implementations.

      * ILA is transparent to intermediate nodes so that it is
        compatible with existing networking hardware and protocol
        optimizations. A TCP/IP packet is still a TCP/IP packet after
        being transformed by ILA.

      * ILA enables singleton address assignment for privacy. It also
        supports /64 address assignment.

      * It is recommended that ILA be contained within an ILA domain
        that is one network under administrative control. Locators are
        not shared with parties outside of the domain.

      * ILA espouses the use of secure redirects as the primary means to
        populate a mapping cache. Push and pull models can be used,
        however secure redirects should be effective in mitigating DOS
        attacks and scalable.

      * ILA allows alternative address representations for
        identifier/locator split other than the canonical 64/64 split.
        Non-local identifiers are defined as a method to use identifiers
        to map to 128 bit IP addresses that might not be local to a
        network.

      * ILA defines optional addressing schemas for IPv4 to IPv6
        translation, network virtualization with an embedded virtual
        networking identifier, and encoding of IP multicast addresses.

      * ILA defines identifier groups as a convenient way to group
        identifiers together that have common characteristics.
        Identifier groups should reduce the number of operations needed
 


T. Herbert               Expires July 26, 2018                 [Page 15]

INTERNET DRAFT        draft-herbert-ila-motivation                      


        on the mapping system.

      * A reference datapath implementation is supported in stock Linux
        since version 4.15. A userspace control path implementation will
        be open sourced.


3.3  Limitations and caveats of ILA

   This section describes limitations and caveats of ILA.

      * While ILA has much less overhead than encapsulation or extension
        headers, this does limit the amount of information that can be
        expressed. ILA is not extensible like some encapsulations so
        there is no means to associate ancillary information with ILA.

      * /64 address assignment is feasible in ILA, however requires a
        level of indirection in addressing.

      * ILA operates by transforming destination IP addresses in
        packets. Source addresses are not transformed. This works very
        well for unicast traffic, but creates some complexity for
        multicast in using the network layer multicast with ILA.

      * If the network generates an ICMP error for a packet whose
        destination contains a transformed address with a locator, the
        embedded packet in ICMP data contains a destination address with
        a locator. Before delivery to the original source host this
        address should be converted back to the original destination
        address.

      * Firewalls should filter addresses in packets before ILA
        translation. The typical scenario is that when a packet is
        forwarded to a network ingress point, the firewall inspects the
        packet before ILA is applied. An firewall internal to the
        network may see ILA addresses as destinations; this should be
        taken into account.

      * Logging and tools need to be adapted since they may be operating
        on ILA addresses. Logged addresses can be mapped to standard
        identifier representation either by a fixed mapping or by
        reverse mapping the address by a lookup in the mapping table.
        The latter would be needed in the case of non-local identifier
        addresses.

4  Use cases

4.1  Mobility networks
 


T. Herbert               Expires July 26, 2018                 [Page 16]

INTERNET DRAFT        draft-herbert-ila-motivation                      


4.2  Datacenter virtualization

4.3  Network virtualization

5  References

5.1  Normative References

5.2  Informative References


Author's Address

   Tom Herbert
   Quantonium
   Santa Clara, CA
   USA


   Email: tom@quantonium.net































T. Herbert               Expires July 26, 2018                 [Page 17]