Internet DRAFT - draft-herbert-ila-mobile
draft-herbert-ila-mobile
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]
