[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

INTERNET-DRAFT                                                T. Herbert
Intended Status: Informational                                Quantonium
Expires: September 2018                                      K. Bogineni
                                                                 Verizon

                                                           March 6, 2018


          Identifier Locator Addressing for Mobile User-Plane
                      draft-herbert-ila-mobile-01



Abstract

   This document discusses the applicability of Identifier Locator
   Addressing (ILA) to the user-plane of mobile networks. ILA allows a
   means to implement network overlays without the overhead,
   complexities, or anchor points associated with encapsulation. This
   solution facilitates highly efficient packet forwarding and provides
   low latency and scalability in mobile networks. ILA can be used in
   conjunction with techniques such as network slices and Network
   Function Virtualization to achieve optimal service based forwarding.

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




T. Herbert             Expires September 6, 2018                [Page 1]


INTERNET DRAFT          draft-herbert-ila-mobile


   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
   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  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2  Conventions and Terminology . . . . . . . . . . . . . . . . . .  5
   3  Motivation  . . . . . . . . . . . . . . . . . . . . . . . . . .  5
   4  Reference topology  . . . . . . . . . . . . . . . . . . . . . .  6
     4.1 ILA routers (ILA-R)  . . . . . . . . . . . . . . . . . . . .  6
       4.1.1 Forwarding routers . . . . . . . . . . . . . . . . . . .  7
       4.1.2 Mapping resolution . . . . . . . . . . . . . . . . . . .  7
     4.2 ILA forwarding nodes (ILA-N) . . . . . . . . . . . . . . . .  7
       4.2.1 ILA to SIR address transformation  . . . . . . . . . . .  7
       4.2.2 ILA forwarding . . . . . . . . . . . . . . . . . . . . .  8
     4.3 ILA hosts (ILA-H)  . . . . . . . . . . . . . . . . . . . . .  8
     4.4 ILA management (ILA-M) . . . . . . . . . . . . . . . . . . .  9
   5 Data plane operation . . . . . . . . . . . . . . . . . . . . . .  9
     5.1 SIR to ILA transformation  . . . . . . . . . . . . . . . . . 10
     5.2 ILA to SIR transformation  . . . . . . . . . . . . . . . . . 11
     5.3 Data path efficiency . . . . . . . . . . . . . . . . . . . . 11
     5.4 Alternative data path use cases  . . . . . . . . . . . . . . 12
     5.5 Locator chaning  . . . . . . . . . . . . . . . . . . . . . . 12
     5.6 ICMP handling  . . . . . . . . . . . . . . . . . . . . . . . 12
   6  Control plane . . . . . . . . . . . . . . . . . . . . . . . . . 12
     6.1 ILA router mapping database  . . . . . . . . . . . . . . . . 13
       6.1.1 ILA with BGP . . . . . . . . . . . . . . . . . . . . . . 13
       6.1.2 Key/value store  . . . . . . . . . . . . . . . . . . . . 13
     6.2 ILA Mapping Protocol . . . . . . . . . . . . . . . . . . . . 13
     6.3  Address assignment  . . . . . . . . . . . . . . . . . . . . 14
       6.3.1 Singleton address assignment . . . . . . . . . . . . . . 14
       6.3.2 Network prefix assignment  . . . . . . . . . . . . . . . 14
   7  ILA in 5G networks  . . . . . . . . . . . . . . . . . . . . . . 15
     7.1 Architecture . . . . . . . . . . . . . . . . . . . . . . . . 15
     7.2 Protocol layering  . . . . . . . . . . . . . . . . . . . . . 16
     7.3 Control plane between ILA and network  . . . . . . . . . . . 16
     7.4 ILA and network slices . . . . . . . . . . . . . . . . . . . 17



T. Herbert             Expires September 6, 2018                [Page 2]


INTERNET DRAFT          draft-herbert-ila-mobile


   8  Security considerations . . . . . . . . . . . . . . . . . . . . 18
     8.1 Data plane security  . . . . . . . . . . . . . . . . . . . . 18
     8.2 Control plane security . . . . . . . . . . . . . . . . . . . 19
     8.3 Privacy in address assignment  . . . . . . . . . . . . . . . 20
   9  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 21
     9.1  Normative References  . . . . . . . . . . . . . . . . . . . 21
     9.2  Informative References  . . . . . . . . . . . . . . . . . . 22
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22











































T. Herbert             Expires September 6, 2018                [Page 3]


INTERNET DRAFT          draft-herbert-ila-mobile


1  Introduction

   In mobile networks, mobility management systems provide connectivity
   while mobile nodes move around.  A control-plane system signals
   movements of a mobile node, and a user-plane establishes tunnels
   between mobile nodes and anchor nodes over IP based backhaul and core
   networks.

   This document discusses the applicability of Identifier Locator
   Addressing (ILA) to those mobile networks. ILA is a form of
   identifier/locator split where identity and location of a node are
   disassociated in IP addresses. ILA nodes transform destination
   addresses of packets by overwriting part of the address with a
   locator. The locator provides the topological address for forwarding
   a packet towards its destination. Before a packet is delivered to the
   end destination, the destination address is reverted to its original
   value.

   An ILA mobile user-plane implementation needs both data plane and
   control plane components.

   The data plane includes the ILA transformation processing as well as
   handling to maintain conformance with IP protocols. The ILA data
   plane is described in [ILA].

   The control plane's primary function is to maintain a mapping
   database that is shared amongst ILA nodes. The mapping database
   contains entries for the mobile nodes in the network, and the number
   of mapping entries is expected scale into the billions. In order to
   scale, a two level hierarchy of ILA nodes is defined by ILA routers
   and ILA forwarding nodes.

   ILA routers maintain a full set of ILA mappings. Routers may be
   replicated for redundancy and load balancing. The mapping system may
   also be sharded, so that each router is responsible for a shard.
   Routers use a protocol to synchronize the mappings for each shard.

   ILA forwarding nodes perform a reverse ILA transformations to restore
   the destination address in packets before delivery. A forwarding node
   can also maintain a cache of ILA mappings to perform transformations
   on intra domain traffic as an optimization to avoid having to forward
   packets through ILA routers. Forwarding nodes are typically located
   close to the mobile nodes. The ILA Mapping Protocol [ILAMP] is used
   between forwarding nodes and ILA routers to manage the cache.







T. Herbert             Expires September 6, 2018                [Page 4]


INTERNET DRAFT          draft-herbert-ila-mobile


2  Conventions and Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

   ILA related terms are defined in [ILA].

3  Motivation

   Emerging applications such as VR, AR, and autonomous vehicle
   communication require very low latency, high bandwidth, and high
   reliability. For mobile devices, these requirements must not only be
   met when the device is stationary, but also across handover during
   mobile events. Mobility needs to be a seamless operation where IP
   addresses and connections are maintained. In a second dimension, the
   number of connected mobile devices, including a large contingent of
   IoT devices, is expected to grow by several orders of magnitude
   within a few years as enabling technologies such as 5G are deployed.

   The convergence of mobile networks and datacenter networks is also
   pertinent. Simple physics (i.e. speed of light) dictates that very
   low latency for applications (order of less than five milliseconds)
   can only be achieved by placing application servers in close
   proximity to clients and minimizing the number of network hops. An
   emerging trend is for providers to house datacenters within the
   network to run applications. For similar reasons, many providers are
   integrating multi-tenant cloud services directly in their mobile
   networks. The upshot is that mobile networks need to support the
   convergence of mobile devices, datacenter virtualization, and cloud.
   A single solution framework for all of this is desirable.

   Current mobile architecture is hitting the limits of scalability and
   performance. In particular, anchor points used in 3GPP have become
   single points of failure, bottlenecks, and lead to sub-optimal
   triangular routing. The anchor model is also inflexible in attempts
   to leverage services of the transport network such as network slices
   and Network Function Virtualization. The control plane to manage
   millions of GTP tunnels is complex and difficult to scale. GTP-U is
   narrowly defined for a particular use case, which makes it difficult
   to leverage for other use cases. The use of any in-network tunneling,
   including GTP, raises issues of overhead, MTU and fragmentation,
   security, and other complexities.

   ILA is a proposed alternative to GTP-U and encapsulation. It does not
   require anchors and simplifies both the data plane and control plane.
   ILA has zero wire overhead so there are no issues around MTU and
   fragmentation. Its use is transparent to the network, and it is



T. Herbert             Expires September 6, 2018                [Page 5]


INTERNET DRAFT          draft-herbert-ila-mobile


   compatible with existing hardware and commonly deployed protocol
   optimizations. ILA is a general network overlay protocol to meet the
   requirements of use cases in a converged network. User Plane
   Functions (UPF) with ILA are lightweight and stateless such that they
   can be brought up quickly as needed.

4  Reference topology

   Figure 1 shows an example topology of ILA in a mobile network.


        [MN]                    O---------------O
          |                     |   App Server  |
       ___v___                  |               |
      /  Radio \   o-------o    |   +--------+  |
     /  Access  \==| ILA-N |    |   | ILA-H  |  |
     \    NW    /  o-------o    |   +--------+  |     o-------o
      \________/         \      O---------------O     | ILA-M |
                          \            ||             o-------o
       [MN]                \     ______||__
         |                  \   /          \
      ___v___                \ /            \                 ________
     /  Radio \   o-------o   /              \   o-------o   /        \
    /  Access  \==| ILA-N |==/   IPv6-Only    \==| ILA-R |==/    DN    \
    \    NW    /  o-------o  \   Network      /  o-------o  \(Internet)/
     \________/               \              /               \________/
                               \            /
                                \__________/

                      Figure 1: Mobile User-plane with ILA


   There are four types of functional nodes in the ILA architecture:

      o ILA routers (ILA-R)

      o ILA forwarding nodes (ILA-N)

      o ILA hosts (ILA-H)

      o ILA managment (ILA-M)

4.1 ILA routers (ILA-R)

   ILA routers are deployed within the network infrastructure and
   collectively contain a mapping database of all identifier to locator
   mappings in an ILA domain. The database may be sharded across the
   identifier space by some number of ILA routers for scalability. ILA



T. Herbert             Expires September 6, 2018                [Page 6]


INTERNET DRAFT          draft-herbert-ila-mobile


   routers may also be replicated for scalability and availability.

   ILA routers provide two main functions: ILA forwarding and mapping
   resolution. An ILA router may perform one both of these functions at
   the same time. If a router performs both functions it may send ILA
   redirects.

4.1.1 Forwarding routers

   Forwarding routers perform ILA transformations when packets enter an
   ILA domain. A destination address of a packet that is a SIR address
   is transformed to an ILA address. The process is that the router
   performs a lookup on the destination address in a mapping table and a
   locator is returned. The locator is written into the destination
   address of the packet (typically the high order sixty-four bits are
   overwritten with a locator).

   In the case of a sharded database, the high order bits of the
   identifier indicate the shard number. This is included in a routing
   prefix so that the packet is routed to an ILA router that contains
   the database for the indicated shard.

4.1.2 Mapping resolution

   An ILA router that is performing mapping resolution will respond to
   mapping requests from ILA forwarding nodes or ILA hosts (these are
   described below). The mapping request protocol allows the caller to
   request the locator for an identifier address.

4.2 ILA forwarding nodes (ILA-N)

   ILA forwarding nodes are deployed in the network infrastructure
   towards the edges to provide ILA transformations for end devices. ILA
   forwarding nodes have two functions: ILA to SIR address
   transformation and ILA forwarding. As indicated in the reference
   topology, forwarding nodes may be deployed near the point of device
   attachment (e.g. base station, eNodeB) of mobile nodes.

4.2.1 ILA to SIR address transformation

   In the path towards the end devices, forwarding nodes perform ILA to
   SIR address transformation. That is, they perform a reverse ILA
   transformation in order to restore the original addresses in packet.
   Forwarding the packet on to the destination is done based on the SIR
   address. For instance, an eNodeB may map a SIR address to a layer 2
   address of the attached device that has the SIR address. Note that
   this functionality is required somewhere in the path between the ILA
   node that writes a locator into an address and the ultimate



T. Herbert             Expires September 6, 2018                [Page 7]


INTERNET DRAFT          draft-herbert-ila-mobile


   destination device (e.g. a UE). It is not recommended that this
   functionality is implemented on end user devices.

   When a node migrates its point of attachment from one ILA-N to
   another, the local mapping on the old ILA-N is removed. If an ILA
   addressed packet is received by an ILA-N for which there is no local
   mapping, then the packet is forwarded back into the network with a
   destination SIR address. The packet should be forwarded through an
   ILA router that can perform the tansformation for the new ILA-N. A
   "negative" mapping with timeout may also be set in an ILA-N to ensure
   that ILA-N is able to infer the SIR address (e.g. would be needed
   with non-local identifiers).

4.2.2 ILA forwarding

   A forwarding node may perform ILA transformation and forward packets
   directly to peer ILA nodes in the same domain. The mappings for this
   are maintained in a working set cache in each ILA-N. As a cache there
   must be methods to populate, evict, and timeout entries. A cache is
   considered an optimization, so the system should be functional
   without its use (e.g. if the cache has no entries). The possibility
   of Denial of Service attack (DOS) on a cache being populated by
   unmanaged outside events, in this case mobile devices sending packets
   to arbitrary destinations, must be considered in the cache design.

   If a packet is received by an ILA forwarding node from a downstream
   node that is destined to another node in the same ILA domain for
   which there is no existing cache entry, then:

      o The packet is forwarded by address. The SIR address plus shard
        identifier prefix will route the packet to a forwarding ILA
        router which will perform ILA transformation of the packet to
        reach its destination.

      o An ILA router may return an ILA redirect to inform the
        forwarding node of a direct ILA mapping.

      o If the forwarding node gets a mapping from an ILA router, then
        subsequent packets for the destination can be directly sent
        using the mapping. Note that a forwarding node does not hold
        packets that are pending mapping resolution.

4.3 ILA hosts (ILA-H)

   ILA host are forwarding nodes that are embedded in end servers to
   provide ILA transformation. Since an ILA host is integrated with the
   host stack sourcing packets, there are opportunities for optimizing
   processing.



T. Herbert             Expires September 6, 2018                [Page 8]


INTERNET DRAFT          draft-herbert-ila-mobile


   ILA is not recommended to run on end user devices, however there may
   be servers or other end devices that are in the provider network that
   might benefit from participating in ILA (this is illustrated in the
   reference topology above). A server that implements ILA forwarding
   can directly send to ILA peers in the same domain to avoid triangular
   routing.

4.4 ILA management (ILA-M)

   The ILA management node provides the interface between the ILA
   infrastructure and mobile management of a network. Similar to ILA-Rs
   there may be multiple ILA-Ms in the network and they can be
   replicated for redundancy and load distribution. Data managed by ILA-
   Ms needs to be synchronized across ILA-Ms. It is conceivable that the
   set of ILA-Ms could be split into shards serving different geographic
   area in order to localize data.  ILA-Ms may be co-located with ILA-Rs
   so that there is a fast path between them.

   The management nodes are responsible for:

      o Receiving notifications from the session management in the
        mobile network. Notifications of interest include: when mobile
        nodes attach to the network, are removed from the network, or
        change their point of attachment in the network (i.e. they
        move).

      o Managing identifier groups. Identifier groups are sets of
        identifiers (nodes) that share common properties [ILAGRPS]. In a
        mobile network, identifier groups are used to represent all the
        identifiers assigned to a mobile node. Each mobile node will
        have its own identifier group.

      o Writing identifier locator mappings into the ILA mapping
        database. The written content is based on the information
        provide by session management.

      o Changing the mapping table when a locator for an identifier,
        group, or mobile node changes. A locator for a device changes
        when its point of attachment changes.

      o Creating identifiers for attached devices. Identifiers may be
        persistent so that each time a device attaches it gets the same
        identifier.

      o Registering ILA-Rs, ILA-Ns and their locators. ILA-Ms coordinate
        the operation of ILA nodes in the network.

5 Data plane operation



T. Herbert             Expires September 6, 2018                [Page 9]


INTERNET DRAFT          draft-herbert-ila-mobile


   ILA performs transformations on IPv6 addresses of packets in flight.
   A SIR to ILA address transformation overwrites the destination
   address with a locator address for forwarding over a network. An ILA
   to SIR address transformation restores an IP address to its original
   contents. The transformations are always paired so that a SIR to ILA
   address transformation is always undone before delivery. End hosts
   and applications only see SIR addresses. Effectively, ILA is a
   mechanism to implement transparent network overlays. Note the process
   is specifically called a "transformation" as opposed to "translation"
   which distinguishes ILA from NAT. NAT translations are not undone
   before reception and NAT is not transparent to the end points.

5.1 SIR to ILA transformation

   SIR to ILA address transformations may be performed by ILA routers,
   ILA forwarding nodes, and ILA hosts.

   SIR to ILA transformation is done by a lookup on the destination
   address in a mapping table. On an ILA router this table contains all
   the entries for the shard the router serves. On a forwarding node or
   host, the table is a cache of entries. If a corresponding entry is
   found, then a locator is returned. The locator is written into the
   destination address.

   If checksum neutral mapping is being used to preserve transport layer
   checksums, then that is indicated in the mapping entry. Checksum
   neutral mangles the low order sixteen bits of the identifier portion
   of the address. The checksum difference between the SIR prefix and
   the locator is added into to the low order sixteen bits of the
   identifier.

   If an ILA router does not find a match on the destination address in
   its table then the packet is dropped as having no route to host.

   If an ILA forwarding node or host does not find a match on the
   destination address, then it forwards the packet unchanged. The
   packet may encounter an ILA router that performs the transformation.

   In response to forwarding a packet, a router might send an ILA
   redirect to an ILA forwarding node. A redirect informs a node of an
   ILA mapping that may be cached to avoid triangular routing when
   forwarding subsequent packets. The destination of a redirect is the
   upstream forwarding node of the source of packet. An ILA router can
   determine this by performing an ILA lookup on the source address of
   the packet being forwarded. This assumes that the source is a SIR
   address for the ILA domain and that the use of ILA is symmetric so
   that the lookup reveals the correct forwarding node; this needs to be
   accounted for in network design.



T. Herbert             Expires September 6, 2018               [Page 10]


INTERNET DRAFT          draft-herbert-ila-mobile


5.2 ILA to SIR transformation

   Transformed packets are forwarded to an ILA-N or ILA-H based on
   normal routing of the packet with a locator in the its destination
   address (upper sixty-four bits). When a node receives the packet it
   first performs performs an ILA to SIR address transformation by
   mapping the received locator (one local to the node) to a SIR
   address. If checksum neutral mapping has been done, the lower sixteen
   bits in the identifier must be fixed up. This is done by subtracting
   the checksum difference of the SIR address and locator from the low
   order bits of the identifier (the opposite operation of setting the
   checksum neutral bits).

   After transforming a destination back to SIR address, a lookup is
   performed on the identifier to determine if it is local (that is it
   refers to a node that is downstream of the ILA node). If the node is
   local, it is forwarded downstream using normal mechanisms of the
   network. If the node is not local, the SIR addressed packet is
   forwarded back into the network. The packet should traverse an ILA
   router that can transform its destination to the correct locator and
   possibly send a redirect towards the source.

5.3 Data path efficiency

   There basic operations of ILA address transformation, either SIR to
   ILA or ILA to SIR, are:

      1) Read destination address from a packet.

      2) Lookup all or are part of the destination address in table.
         This is a fixed length lookup.

      3) Overwrite all or part of the destination address with a locator
         value returned from the lookup.

      4) Fix the checksum neutral mapping bits in the identifier.

      5) Forward the resultant packet.

   The computationally intensive operations in this path are the lookup
   and checksum neutral processing.

   The lookup operation is on a fixed length key so a simple hash table
   can be used. It is also amenable for use with a hardware TCAM. On an
   ILA host, an ILA mapping may be cached with a connection context so
   that a lookup does not to be performed for every packet sent on the
   connection.




T. Herbert             Expires September 6, 2018               [Page 11]


INTERNET DRAFT          draft-herbert-ila-mobile


   Checksum neutral processing entails 1's complement arithmetic over
   sixty-four or 128 bit values. In the case that the full 128 bit
   identifier address is a one-to-one mapping with a locator address,
   then the checksum computation is constant for a mapping and can be
   precomputed and saved with the mapping.

5.4 Alternative data path use cases

   ILA supports multicast encoding, virtual networking modes, and
   IPv4/IPv6 translation. These require different processing, and in the
   case of IPv4/IPv6 translation the size of the packet increases.
   However, these alternative cases should not fundamentally increase
   the cost of the lookups since instructions for alternative processing
   can be returned by a lookup.

5.5 Locator chaning

   ILA allows multiple locator transformations to effectively implement
   hop-by-hop source routing. This can be used to deliberately have a
   packet visit some set of nodes. This might also be used in the case
   where two domains are exchange ILA mappings, but only share locators
   that are ingress points in their network and not final locators of a
   node. This would be done to protect user location from being exposed.

5.6 ICMP handling

   A packet whose destination address is an ILA address may generate an
   ICMP error. In this case the ICMP data will contain an IPv6 header
   whose destination is an ILA address. If a sender receives an ICMP
   error with an ILA address as the destination of the original packet,
   it won't recognize the destination address as one that it sent to and
   this may leak information about internal nodes of the network. To
   prevent this from happening, upstream ILA-Ns of ILA-Hs of an end node
   can filter ICMP packets. When an ICMP packet is received by these
   nodes, an ILA destination address can be transformed back to a SIR
   address by performing a reverse lookup.

6  Control plane

   This section describes the ILA control plane for the mobile user-
   plane.

   The ILA control plane is separate from the control plane of the
   mobile network. An interface between the session management of the
   network and the control plane is needed to get device information and
   point of attachment. The intent is that the interface is well
   compartmentalized to minimize the amount of specialization needed to
   adapt ILA for use in different access technologies.



T. Herbert             Expires September 6, 2018               [Page 12]


INTERNET DRAFT          draft-herbert-ila-mobile


6.1 ILA router mapping database

   There are a number of options to use for implementing the ILA mapping
   system and router protocol amongst ILA-Rs. The mapping database must
   be able to scale and provide fast converge when mobile nodes move
   within the network.

6.1.1 ILA with BGP

   A traditional routing protocol could be used for route dissemination.
   [BGPILA] defines multiprotocol extensions to BGP for distributing ILA
   mappings.

6.1.2 Key/value store

   A mapping database is logically a simple key/value store where the
   lookup key is fixed length (sixty-four or 128 bytes). This
   characteristic affords the possibility of using a key/value database
   in lieu of traditional routing protocols.

   The idea of the key/value database is that each shard is a
   distributed database instance with some number of replicas. When a
   write is done in the database, the change is propagated throughout
   all of the replicas for the shard using the standard database
   replication mechanisms. Mapping information is written to the
   database using common database API and requires authenticated write
   permissions. Each ILA router can read the database for the associated
   shard to perform its function.

   The database is assumed to be (mostly) persistent and recoverable if
   database nodes are lost. The selection of an ILA router shard and
   shard instance is idempotent and stateless per packet, so that shards
   and shard replicas can be dynamically added or removed.

6.2 ILA Mapping Protocol

   The ILA Mapping Protocol [ILAMP] is used between ILA forwarding nodes
   and ILA mapping resolution routers. The purpose of the protocol is to
   populate and maintain the ILA mapping cache in forwarding nodes.

   ILA forwarding nodes can use a pull model (request/response), push
   model (pub/sub), or redirects to populate the mapping table. ILAMP
   runs over TCP which provides reliability, statefulness implied by
   established connections, allows use of HTTP and RESTful APIs, and
   standard security in the form of TLS.

   The protocol is composed of message primitives:




T. Herbert             Expires September 6, 2018               [Page 13]


INTERNET DRAFT          draft-herbert-ila-mobile


      o Map request: Sent by an ILA-N or ILA-H to an ILA-R to request
        mapping information for an IPv6 address.

      o Map information: Sent by an ILA-R to an ILA-N or ILA-H and
        provides mappings. A map information message can be sent in
        response to a map request, when mappings are pushed in pub/sub,
        or a mapping is being advertised by ILA redirect. The reason the
        mapping information was sent in included in a message.

      o Subscribe/unsubscribe: Sent by an ILA-N or ILA-H to an ILA-R.
        "Subscribe" requests mapping notifications for the listed
        identifiers. Notifications are sent when a mapping entry for an
        identifier changes. "Unsubscribe" requests that notifications
        for the listed identifiers stop.

      o Locator unreachable: sent by an ILA-R to an ILA-N or ILA-H to
        indicate that another ILA-N is no longer reachable so all cache
        entries using that ILA-N or ILA-H should be evicted.

6.3  Address assignment

   Mobile nodes are assigned addresses that serve as identifiers. A node
   may be assigned singleton addresses or a network prefix. Privacy is
   an important consideration in address assignment.

6.3.1 Singleton address assignment

   DHCPv6 or static address configuration can be used to assign
   singleton addresses to a node. These addresses have no topological
   component and are not meaningfully aggregable for routing, so an
   entry in the ILA mapping table would be created for each address.
   Nodes may be assigned thousand of addresses or even millions of IPv6
   addresses. Given the large IPv6 address space there are few concerns
   about address depletion, however to the mapping system each address
   is represented in a identifier to locator mapping. Scaling this needs
   to be carefully considered. Sharding, replication, and caching on
   forwarding nodes are meant to provide scalability.

6.3.2 Network prefix assignment

   A node 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 a device for its own purposes;
   these bits cannot be used as an identifier in identifier/locator
   split.

   To support /64 prefix assignment with ILA, the ILA identifier can be
   encoded in the the upper sixty-four bits of an address and the lower



T. Herbert             Expires September 6, 2018               [Page 14]


INTERNET DRAFT          draft-herbert-ila-mobile


   sixty-four bits are ignored by ILA. Since only a subset of bits are
   available, a level of indirection can be used so that ILA transforms
   the upper sixty four bits to contain both a locator and an index into
   a locator (ILA-N) specific table. The entry in the table provides the
   original sixty-four bit prefix so that ILA to SIR address
   transformation can be done.

7  ILA in 5G networks

   The section describes applying ILA for use in a 5G network. ILA is
   instantiated as a function in the 5G services architecture described
   in [3GPPTS].

7.1 Architecture

   Figures 2 and 3 depict two architectural options for the use of ILA
   in a 5G architecture. ILA is logically a network function and ILA
   interfaces to the 5G control plane via service based interfaces. In
   this architecture, ILA replaces GTP use over the N9 interface.
   Identifier address to locator address transformations in the downlink
   from the data network are done by an ILA-R. Transformations for intra
   domain traffic can be done by an ILA-N close to the gNB or by an ILA-
   R in the case of a cache miss. Locator address to identifier address
   transformation happen at ILA-Ns. ILA could be supported on a gNB. In
   this case, an ILA-N would be co- resident at a gNB and ILA is used
   over N3 interface in lieu GTP-U.

                        Service Based Interfaces
    ----+-----+-----+----+----+----+----+--------+-----+--------
        |     |     |    |    |    |    |        |     |
    +---+---+ |  +--+--+ | +--+--+ | +--+--+  +--+--+  |
    | NSSF+ | |  | NRF | | | DSF | | | UDM |  | NEF |  |
    +-------+ |  +-----+ | +-----+ | +-----+  +-----+  |
              |          |         |                   |
          +---+----+  +--+--+  +---+--+  +-------------+--+
          |  AMF   |  | PCF |  | AUSF |  |     ILA-M      |   ^
          +---+--+-+  +-----+  +------+  +-+-----------+--+   |
   +-------+  |  |                         |           |    ILARP
   | 5G UE |--+  |                         | <-ILAMP-> |      |
   +---+---+     | N2                +-----+----+  +---+---+  V   +----+
       |         |      +------------|  ILA-N   |--| ILA-R |------| DN |
       |         |      |    N3      +-+---+--+-+  +-+-----+      +----+
       |         |      |                |   |  |      |
       |     +---+------+-+              +---+  +------+
       +-----|    gNB     |               N9       N9
             +------------+

                 Figure 2: ILA in 5G architecture - Option 1



T. Herbert             Expires September 6, 2018               [Page 15]


INTERNET DRAFT          draft-herbert-ila-mobile


                        Service Based Interfaces
   ----+-----+-----+----+----+----+------+----+----+----+--------+--
       |     |     |    |    |    |      |    |    |    |        |
   +---+---+ |  +--+--+ | +--+--+ |      |    |    | +--+--+  +--+--+
   | NSSF  | |  | NRF | | | DSF | |      |    |    | | UDM |  | NEF |
   +-------+ |  +-----+ | +-----+ |      |    |    | +-----+  +-----+
             |          |         |      |    |    |
         +---+----+  +--+--+  +---+--+   | +--+--+ |
         |  AMF   |  | PCF |  | AUSF |   | |ILA-M| |
         +---+--+-+  +-----+  +------+   | +--+--+ |
     +-------+  |  |                     |         |
     | 5G UE |--+  |                     |         |
     +---+---+     | N2             +----+--+  +---+---+      +----+
         |         |      +---------| ILA-N |--| ILA-R |------| DN |
         |         |      |    N3   ++--+-+-+  +-+-----+      +----+
         |         |      |          |  | |      |
         |     +---+------+-+        +--+ +------+
         +-----|    gNB     |            N9     N9
               +------------+

                Figure 3: ILA in 5G architecture - Option 2

7.2 Protocol layering

   Figure 3 illustrates the protocol layers of packets packets sent over
   various data plane interfaces in the downlink direction of data
   network to a mobile node. Note that this assumes the topology shown
   in Figure 2 where GTP-U is used over N3 and ILA is used on N9.

                 --->             --->            --->
    DN to ILA-R      ILA-R to ILA-N   ILA-N to gNB     gNB to UE
   +------------+   +------------+   +------------+   +------------+
   | Application|   | Application|   | Application|   | Application|
   +------------+   +------------+   +------------+   +------------+
   |     L4     |   |     L4     |   |     L4     |   |     L4     |
   +------------+   +------------+   +------------+   +------------+
   |    IPv6    |   | IPv6 (ILA) |   |    IPv6    |   |  PDU Layer |
   +------------+ | +------------+ | +------------+   +------------+
   |     L2     | | |     L2     | | |   GTP-U    |   | AN Protocol|
   +------------+ | +------------+ | +------------+   |   Layers   |
                  |                | |   UDP/IP   |   |            |
                 N6   <--N9 -->   N3 +------------+   +------------+
                                     |    L2      |
                                     +------------+

                          Figure 3: ILA and protocol layer in 5G

7.3 Control plane between ILA and network



T. Herbert             Expires September 6, 2018               [Page 16]


INTERNET DRAFT          draft-herbert-ila-mobile


   ILA is a consumer of several 5G network services. The service
   operations of interest to ILA are:

      o Nudm (Unified Data Management): Provides subscriber information.

      o Nsmf (Service Managment Function): Provides information about
        PDU sessions.

      o Namf (Core Access and Mobility Function): Provides notifications
        of mobility events.

   ILA-M subscribes to notifications from network services. These
   notifications drive changes in the ILA mapping table. The service
   interfaces reference a UE by UE ID (SUPI or IMSI-Group Identifier),
   this is used as the key in the ILA identifier database to map UEs to
   addresses and identifier groups. Point of attachment is given by gNB
   ID, this is used as the key in the ILA locator database to map a gNB
   to an ILA-N and its locator.

7.4 ILA and network slices

   Figure 4 illustrates the use of network slices with ILA.

    ----+-------------------------------------+--------------------
        |                                     |
   +-------------------------+   +----------------------------+
   |  +--------+       Slice |   |  +-------------+     Slice |
   |  |  SMF   |-----+    #1 |   |  |  ILA-M      |----+   #2 |
   |  +---+----+     |       |   |  +-----------+-+    |      |
   |  N4  |          | N4    |   |        |     |      |      |
   |  +---+--+    +--+----+  |   |  +--------+  |  +--+----+  |   +----+
   |  |  UPF  |   | UPF   |  |   |  | ILA-N  |  |  | ILA-R |  |---| DN |
   |  +-------+   +-------+  |   |  +--------+  |  +-------+  |   +----+
   +-------------------------+   +--------------|-------------+
                      |                         |
                   +--+-+          +------------|-------------+
                   | DN |          |            |       Slice |
                   +----+          |     +------+----+     #3 |
                                   |     |           |        |
                                   | +-------+     +-------+  |   +----+
                        +-----+    | | ILA-H |     | ILA-R |  |---| DN |
                        | MEC |----| +-------+     +-------+  |   +----+
                        +-----+    +--------------------------+

                      Figure 4: ILA and network slices in 5G


   In this figure, slice #1 illustrates legacy use of UPFs without ILA



T. Herbert             Expires September 6, 2018               [Page 17]


INTERNET DRAFT          draft-herbert-ila-mobile


   in a slice. ILA can be deployed incrementally or in parts of the
   network. As demonstrated, the use of network slices can provide
   domain isolation for this.

   Slice #2 supports ILA. Some number of ILA-Ns and ILA-Rs are deployed.
   ILA transformations are performed over the N9 interface. ILA-Rs would
   be deployed at the N6 interface to perform transformations on packets
   received from a data network. ILA-Ns will be deployed deeper in the
   network at one side of the N3 interface. ILA-Ns may be supplemented
   by ILA-Rs that are deployed in the network. ILA-M manages the ILA
   nodes and mapping database within the slice.

   Slice #3 shows another slice that supports ILA. In this scenario, the
   slice is for Mobile Edge Computing. The slice contains ILA-Rs and
   ILA-Ns, and as illustrated, it may also contain ILA_Hs that run
   directly on edge computing servers. Note in this example, one ILA-M,
   and hence one ILA domain, is shared between slice #2 and slice #3.
   Alternatively, the two slices could each have their own ILA-M and
   define separate ILA domains.

8  Security considerations

   A mobile public infrastructure has many considerations in security as
   well as privacy. Fundamentally, a system must protect against
   misdirection for the purposes of hijacking traffic, spoofing,
   revealing user identities, exposing accurate geo-location, and Denial
   of Service attacks on the infrastructure. Security must be considered
   for both the data and control planes.

8.1 Data plane security

   The ILA data plane must protect against spoofing, inadvertent leakage
   of sensitive information, and Denial of Service attack.

   Locator addresses must be contained within an ILA domain. ILA to SIR
   transformations MUST be performed before allowing a packet to egress
   an ILA domain.

   Nodes outside of an ILA domain MUST NOT be permitted to send packets
   into the domain that have an ILA address in either the source or
   destination. A stateless firewall at the domain boundary can be used
   to drop such packets. Note that in the ILA protocol, ILA addresses
   are not used in source addresses.

   Section 5.6 describes the handling of ICMP with ILA to avoid leaking
   locators outside the ILA domain.

   When a cache is employed that is populated by events from an outside



T. Herbert             Expires September 6, 2018               [Page 18]


INTERNET DRAFT          draft-herbert-ila-mobile


   party there is the possibility of Denial of Service attack. A
   conceptual attack on ILA-N would be for an attacker will flood its
   link with packets destined to random SIR addresses. The intent is to
   exhaust the cache memory so that legitimate traffic is blocked from
   using the cache and hence needs to take sub-optimal routing. The
   attack can also generate vast numbers of control messages to DOS the
   infrastructure.

   It is recommended that ILA redirects, as opposed to query model or
   pub/sub, is used to mitigate attacks. The reasoning is:

      o On a cache miss the packet is forwarded and might encounter a
        router that sends a redirect. The packet itself implies a
        request for a mapping so no additional control message are
        needed.

      o An ILA router will send a redirect only if there is a mapping to
        the destination. It doesn't sent negative information. In
        particular, if the identifier space is reasonably sparse a
        random address attack will not be very effective.

      o A cache entry is created only when a valid redirect is received.
        This can be contrasted with a query mechanism that might create
        state for pending resolutions.

      o An inactivity timeout can used to evict cache entries. Given the
        incoming packet rate and a preferred inactivity timeout, a cache
        can be sized to absorb an attack.

      o An ILA router may apply its knowledge to rate limit, prioritize,
        and shape the use of redirects to manage caches. For instance,
        an ILA router might identify "hot nodes" in the network that
        receive a lot of traffic and provide the most benefit when
        cached in forwarding nodes.

8.2 Control plane security

   A mapping system contains sensitive privacy information that could be
   used to make inferences about user's identity or their geo-location.
   This information needs to be protected.

   Mapping protocols must be secured to prevent an attacker from
   injecting mapping entries to redirect traffic to their own devices.
   To this end, mapping protocols for ILA are intended to use TCP. The
   statefulness of TCP deters spoofing of messages and allows for
   privacy and identity verification in the form of X.509 certificates.
   The control protocol includes "secure" redirects that must be
   authenticated to originate from a legitimate ILA router.



T. Herbert             Expires September 6, 2018               [Page 19]


INTERNET DRAFT          draft-herbert-ila-mobile


   Mapping protocols 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.
   The recommendation of ILA is to use "secure redirects" as a scalable
   and secure means to populate a forwarding cache.

   Write access to the ILA mapping database must be strictly controlled.
   In the ILA architecture only ILA-Ms write to the mapping database.
   Write access to the database should require strong credentials,
   validation of each operation, and encryption and authentication of
   operations being sent over the network.

   Read access the ILA routing database should also be controlled.
   Devices should only access data on a "need to know" basis. For
   instance, ILA routers might need identifier to group mappings to
   perform forwarding, but they should not need to retrieve all the
   identifiers for a group. The latter information can be contained in
   the ILA-Ms.

8.3 Privacy in address assignment

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

      o 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].

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

      o 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.

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

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




T. Herbert             Expires September 6, 2018               [Page 20]


INTERNET DRAFT          draft-herbert-ila-mobile


         o 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).

         o 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.

   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 node that potentially allows DOS on the device, as well as
   third party correlations on addresses that deduce that different
   flows are sourced from the same user.

   [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.

   For maximum privacy, a different address could be used for each
   connection. If this were done for every connection in the network, it
   would create network state for each connection (note that is sort of
   thing already exists with stateful NAT). Scaling the mapping system
   to accommodate this is challenging. One alternative to be
   investigated is use a reversible cryptographic hash to aggregate
   identifiers and reduce the number of mappings needed.

9  References

9.1  Normative References

   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
             Requirement Levels", BCP 14, RFC 2119, DOI
             10.17487/RFC2119, March 1997, <https://www.rfc-
             editor.org/info/rfc2119>.

   [ILA]     Herbert, T., and Lapukhov, P., "Identifier Locator
             Addressing for IPv6" draft-herbert-intarea-ila-00

   [ILAMP]   Herbert, T., "Identifier Locator Addressing Mapping
             Protocol" draft-herbert-ila-ilamp-00




T. Herbert             Expires September 6, 2018               [Page 21]


INTERNET DRAFT          draft-herbert-ila-mobile


9.2  Informative References

   [RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6
             (IPv6) Addressing Architecture", RFC 3513, DOI
             10.17487/RFC3513, April 2003, <https://www.rfc-
             editor.org/info/rfc3513>.

   [RFC4941] Kolkman, O. and R. Gieben, "DNSSEC Operational Practices",
             RFC 4641, DOI 10.17487/RFC4641, September 2006,
             <https://www.rfc-editor.org/info/rfc4641>.

   [ILAGRPS] Herbert, T., "Identifier Groups in ILA", To be published

   [BGPILA]  Lapukhov, P., "Use of BGP for dissemination of ILA mapping
             information" draft-lapukhov-bgp-ila-afi-02

   [3GPPTS]  3rd Generation Partnership Project (3GPP), "3GPP TS
             23.502", http://www.3gpp.org/DynaReport/23-series.htm



Authors' Addresses

   Tom Herbert
   Quantonium
   Santa Clara, CA
   USA

   Email: tom@quantonium.net


   Kalyani Bogineni
   Verizon
   One Verizon Way, Basking Ridge, NJ 07920
   USA

   Email: kalyani.bogineni@verizon.com














T. Herbert             Expires September 6, 2018               [Page 22]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/