Internet DRAFT - draft-herbert-ila-motivation
draft-herbert-ila-motivation
INTERNET-DRAFT T. Herbert
Intended Status: Informational Quantonium
Expires: July 2018
January 22, 2018
Identifier Locator Addressing: Problem areas, Motivation, and Use Cases
draft-herbert-ila-motivation-00
Abstract
This document describes the problems, motivation, and use cases for
Identifier-Locator Addressing.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Copyright and License Notice
Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
T. Herbert Expires July 26, 2018 [Page 1]
INTERNET DRAFT draft-herbert-ila-motivation
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2 Problem areas . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1 Identifier/locator split . . . . . . . . . . . . . . . . . 3
2.2 Efficiency of network overlay techniques . . . . . . . . . 3
2.3 Ramifications of network tunneling . . . . . . . . . . . . 4
2.4 Networking hardware compatibility . . . . . . . . . . . . . 4
2.5 Mobility . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.6 Mapping systems . . . . . . . . . . . . . . . . . . . . . . 5
2.6.1 Nodes with complete set of mappings . . . . . . . . . . 5
2.6.2 Mapping caches . . . . . . . . . . . . . . . . . . . . . 5
2.7 Privacy . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.7.1 Geo-location . . . . . . . . . . . . . . . . . . . . . . 6
2.7.2 Privacy in addresses . . . . . . . . . . . . . . . . . . 7
2.8 Address assignment . . . . . . . . . . . . . . . . . . . . 8
2.9 Scaling . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.10 Security . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.10.1 Mapping information . . . . . . . . . . . . . . . . . . 10
2.10.2 Mapping protocols . . . . . . . . . . . . . . . . . . . 10
2.12 ICMP . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.13 Multicast . . . . . . . . . . . . . . . . . . . . . . . . . 11
3 Motivation for ILA . . . . . . . . . . . . . . . . . . . . . . 11
3.1 Alternative network overlay technologies . . . . . . . . . 11
3.1.1 ILNP . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.1.2 Encapsulation . . . . . . . . . . . . . . . . . . . . . 12
3.1.3 Segment routing . . . . . . . . . . . . . . . . . . . . 13
3.1.4 Network Address Translation . . . . . . . . . . . . . . 13
3.1.5 Transport layer mechanisms . . . . . . . . . . . . . . . 14
3.2 Benefits of ILA . . . . . . . . . . . . . . . . . . . . . . 14
3.3 Limitations and caveats of ILA . . . . . . . . . . . . . . 16
4 Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.1 Mobility networks . . . . . . . . . . . . . . . . . . . . . 16
4.2 Datacenter virtualization . . . . . . . . . . . . . . . . . 17
4.3 Network virtualization . . . . . . . . . . . . . . . . . . 17
5 References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
5.1 Normative References . . . . . . . . . . . . . . . . . . . 17
5.2 Informative References . . . . . . . . . . . . . . . . . . 17
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17
T. Herbert Expires July 26, 2018 [Page 2]
INTERNET DRAFT draft-herbert-ila-motivation
1 Introduction
Identifier-locator addressing (ILA) is a protocol based on
identifier/locator split that provides network overlays without the
use of encapsulation or extension headers. ILA operates at the
network layer and is intended to be transparent to both applications
and transport layer protocols.
This document highlights problem areas, motivation, and use cases of
ILA. Problem areas include protocol efficiency, scalability,
mobility, privacy, and security for network overlays and
identifier/locator split. The motivation for ILA is provided in terms
of how ILA addresses the problems and its advantages over alternative
approaches. The use cases of ILA include mobility, datacenter
virtualization, and network virtualization; some details and
considerations for these use cases are provided.
2 Problem areas
This section highlights some of the problems faced for use of
identifier/locator split and network overlays.
2.1 Identifier/locator split
Identifier/locator split is a technique that has long been discussed
within IETF. This is the answer to the problem that IP addresses have
traditionally been overloaded with two characteristics: they indicate
both the identity of a node and its location. Identifier/locator
split endeavors to separate these two notions. A node has identity
and location, but they are separate elements in addressing. This
disassociation of identity and location allows nodes to become
"virtual" and mobile. This distinction has been made in network
virtualization and mobility networks for some time, however demand
for mobility and virtualization is continuously increasing so that in
the future a majority of nodes might be virtualized and subject to
identifier/locator split.
Deployment of identifier/locator split in existing networks can raise
a number of issues. Since addresses no longer contain location,
routing needs to change and routing tables need to scale to include
many more destinations. Logging and tools also need to change to take
into account that location and identity may be separate notions in an
address.
2.2 Efficiency of network overlay techniques
With the emergence of applications such as AR, VR, machine learning,
and road safety information, the demands for low latency, high
T. Herbert Expires July 26, 2018 [Page 3]
INTERNET DRAFT draft-herbert-ila-motivation
throughput, and highly reliable networking are only increasing. Low
latency networking is no longer confined to the purview of
specialized application centric networks, requirements for very low
latency are being introduced into public access networking
technologies such as 5G. As such, the efficiency and performance of
network overlays becomes important.
Network overlays are a benefit since they facilitates node mobility
and malleability in use of network resources. These benefits tend to
be architectural in the network and not necessarily obvious to the
users or applications in the network. For instance, network overlays
facilitate mobility, however the cost of that capability to
applications must be taken into a account. Mobility is likely a rare
event, and there are many nodes that will never move during their
lifetime. When a node is not moving, the cost incurred for having the
capability to move should be near zero.
2.3 Ramifications of network tunneling
The ramifications and issues with tunneling in the network have been
well documented and discussed in IETF.
If encapsulation is being used in the network to implement a tunnel
then the packet size increases so exceeding the MTU is a concern;
[RFC4459] discusses MTU and fragmentation considerations for network
tunneling. [RFC2983] discusses the interactions of differentiated
services with tunnels and procedures to translate diffserv for an
inner packet to the outer one. [RFC6040] specifies handling of
Explicit Congestion Notification in a tunnel. [RFC6935] and [RFC6936]
discuss at length the requirements that must be meant for allowing a
zero UDPv6 checksum to be used for tunnels.
The upshot is that defining and correctly implementing tunnels in the
network is a nontrivial exercise.
2.4 Networking hardware compatibility
The effects of deploying a protocol with existing network hardware
implementation must be considered. Generally, hardware
implementations (switches, router, NICs, etc.) are optimized for
certain protocols and protocol features. Most devices implement
optimizations for the two most common transport protocols, namely TCP
and UDP. These optimizations include features like ECMP, checksum
offload, and segmentation offload. As one moves away from use of
commonly supported protocols, the benefits of optimizations and even
feasibility of protocols or protocol features dwindles. For example,
IPv6 extension headers have had a checkered history of being properly
supported by intermediate nodes, and hence are considered precarious
T. Herbert Expires July 26, 2018 [Page 4]
INTERNET DRAFT draft-herbert-ila-motivation
for use on the Internet [RFC7872].
Note that many new encapsulation protocols (GUE, GRE/UDP, LISP,
Geneve, etc.) employ encapsulation in UDP. The use of UDP makes
packets more palatable to network devices, albeit at the cost of UDP
header overhead and additional processing overhead.
2.5 Mobility
For seamless mobility, a node retains its IP address and connections
remain established across mobile events. If network mobility is
handled in the network layer then moving should be transparent to the
application with only the possibly that latency is increased for a
few packets.
Mobility is present in different use cases whenever a node changes
its point of attachment in the network. When this happens the
location of the node and hence its locator changes. A key attribute
of an identifier/locator solution is how the network converges when a
change occurs. During the convergence period, latency is expected to
be bounded and packet loss is expected to be minimized or avoided
entirely.
2.6 Mapping systems
Identifier/locator split solutions employ a mapping system that
provides identifier to locator mappings. Similar to IP routing, there
may be both nodes that maintain a full list of mappings (analogous to
core routers) and nodes that maintain a cache of mappings (analogous
to nodes with a neighbor discovery cache).
2.6.1 Nodes with complete set of mappings
The complete set of mappings in a network might be sharded across
some number of nodes. Each node maintains a complete list of mappings
for their respective shard. Furthermore, each shard may be replicated
on several nodes for redundancy and load balancing. All the nodes for
a shard must synchronize information upon changes using a protocol
amongst themselves. The time it takes for all nodes to converge when
a change happens can correlate to perceived application latency.
2.6.2 Mapping caches
Anchorless mobility is a goal of identifier/locator split. For
achieving low latency, direct routing is preferred. Forwarding nodes
that contain a cache of mapping entries may be deployed at or near
source hosts to optimize forwarding. These nodes maintain a cache of
mapping entries used to directly forward packet to peers in the same
T. Herbert Expires July 26, 2018 [Page 5]
INTERNET DRAFT draft-herbert-ila-motivation
identifier/locator domain. The use of a cache avoids triangular
routing through an intermediate device that has a complete list of
mappings.
Mapping caches may be populated either by "push" or "pull" model. In
the push model, nodes are informed of changes to the mappings for
nodes they are interested in. A node may register to get
notifications of changes from authoritative nodes in the mapping
system. This is the pub/sub model. In the pull model, a node queries
an authoritative node to resolve a mapping for an identifier it is
interested in; typically this is done on demand when a packet is
being forwarded to a destination address whose mapping is yet not in
the cache.
Both the pull model and push model have their advantages and
disadvantages. The push model (aka pub/sub) should result in faster
and more accurate convergence, however may require more
communications and be harder to scale than the pull model. The pull
model may be more susceptible to Denial of Service attack.
Secure redirects are hybrid of the push and pull model. A cache entry
is populated by an authoritative node that is forwarding a packet.
This "redirect" eliminates triangular routing from the source to the
destination. Redirects must be secure since to prevent destination
hijacking.
2.7 Privacy
Identifier/locator split can benefit user privacy, particularly in
what is exposed in IP addresses. The benefit is only viable if
locators that imply geo-location and identities are not revealed to
untrusted parties.
2.7.1 Geo-location
An effect of identifier/locator split is that location is no longer
an inherent component of IP addresses. This is a benefit to user
privacy as it can reduce the inference of geo-location of a user
based on IP addresses. However, strong privacy implies that locators,
which could very well reveal geo-location, are only visible to
trusted entities.
Conceivably, an identifier-locator protocol could be run at the end
user devices in a public network (e.g. UEs in a mobile network). This
section provides a privacy argument against that.
The major problem with running an identifier/locator protocol on end
user devices is that the devices are not controlled by the network
T. Herbert Expires July 26, 2018 [Page 6]
INTERNET DRAFT draft-herbert-ila-motivation
infrastructure. User devices on a public network, such as Android
devices, can easily be hacked to allow root access to the device.
Once a user has root access they can install any program they wish on
the device including those that could disable or circumvent security
or accounting related to identifier/locator split protocol.
If root access can be gained on an end user device, this leads to the
stalker problem which would be a very easy means to track
individuals. This exploit is described below:
* Suppose that a user device participates in an identifier/locator
split protocol such that they cache locators and use locators to
directly send to peer devices.
* A hacker might tap all packets sent or received on the network
interfaces which makes locators visible to them.
* In order to be able to tap packets, a user needs root access to
the device. There are instructions on the web to root an Android
device. Similarly, jailbreaking can be done to circumvent
restrictions on an iPhone to gain the equivalent of root access.
* Once root access has been obtained, packets can be tapped using
tcpdump or similar packet sniffer applications.
* With the tap running and packet addresses being captured, the
hacker just needs to drive around sendimg traffic between two
devices in their car. They can observe the locators that are
assigned to the their device, and from this can create a geo map
of locators.
* Given that one hacker can do this, then thousands will do it and
web sites will spring up that provide locator geo maps. Efforts
to obfuscate or rotate identifiers does not help much here.
Obfuscation complicates routing in the network such that more
transformations need to happen there. Locator rotation is
defeated if there are enough devices to keep the maps up to date
in a mashup.
* The net effect is that this enables a stalker attack. An
individual simply initiates a communication with their target.
For instance, this could be a chat or phone call. If in doing
this the locators for the device belonging to the target are
made visible to the hacker, then the physical location of the
target can be deduced using the locator geo maps described
above.
2.7.2 Privacy in addresses
T. Herbert Expires July 26, 2018 [Page 7]
INTERNET DRAFT draft-herbert-ila-motivation
A node may use multiple addresses to prevent inferences by third
parties that break privacy. Properties of addresses to maintain
strong privacy are:
* They are composed of a global routing prefix and a suffix that
is internal to an organization or provider. This is the same
property for IP addresses [RFC3513].
* The registry and organization of an address can be determined by
the network prefix. This is true for any global address.
* The organizational bits in the address should have minimal
hierarchy to prevent inference. It might be reasonable to have
an internal prefix that divides identifiers based on broad
geographic regions, but detailed information such as accurate
location, department in an enterprise, or device type should not
be encoded in a globally visible address.
* Given two addresses and no other information, the desired
properties of correlating them are:
* It can be inferred if they belong the same organization and
registry. This is true for any two global IP addresses.
* It may be inferred that they belong to the same broad
grouping, such as a geographic region, if the information is
encoded in the organizational bits of the address (e.g. are
in the same shard).
* No other correlation can be established. For example, it
cannot be inferred that the IP addresses address the same
node, the addressed nodes reside in the same subnet, rack, or
department, or that the nodes for the two addresses have any
geographic proximity to one another.
2.8 Address assignment
In an identifier/locator split protocol, end hosts are assigned
addresses that serve as identifiers. A device may be assigned a
network prefix or singleton addresses.
A end host may be assigned a /64 address via SLAAC as is common in
many provider networks. In this scenario, the low order sixty-four
bits contains IIDs arbitrarily assigned by devices for its purposes;
so these bits cannot be used as an identifier in identifier/locator
split. Effectively, the upper sixty-four bits is the identifier of
the node.
T. Herbert Expires July 26, 2018 [Page 8]
INTERNET DRAFT draft-herbert-ila-motivation
Ostensibly, assigning a /64 prefix to a node is good for security.
The end device can create its own random addresses in the low order
sixty-four bits which mitigates address scanning attacks. However,
the upper sixty for bits of the address become a static identifier
for the device which potentially allows DOS on the device as well as
correlating different addresses in the Internet as being sourced from
the same device.
[RFC4941] recommends rotating addresses to protect privacy. In the
case of sixty-four bit address assignments this would entail that a
new prefix for the device is periodically requested. There is no
recommendation for the frequency of address change and there is no
quantitative description of the effects of periodic address change.
The following exploit is proposed to defeat the privacy goal of
periodic address rotation:
* An attacker creates an "always connected" app that provides some
seemingly benign service so that users download the app.
* The app includes some sort of persistent identity. For instance,
this could be an account login.
* The backend server for the app logs the user identity and IP
address each time a user connects.
* When an address change happens, existing connections on the user
device are disconnected. The app will receive a notification and
immediately attempt to reconnect using the new source address.
* The backend server will see the new connection and log the new
IP address as being used by the user. Thus, the server has a
real-time record of users and the IP addresses they are using.
* The attacker gains access to packet traces taken at some point
in the Internet. The addresses in the captured packets can be
time correlated with the server database to deduce the identity
of the source of packets for communications completely unrelated
to the app.
This exploit would defeat address rotation with any frequency except
the for case that that a different source address is used for each
flow.
2.9 Scaling
Since identity is no longer associated with location, each node
becomes separately routable in the network. In identifier/locator
T. Herbert Expires July 26, 2018 [Page 9]
INTERNET DRAFT draft-herbert-ila-motivation
split, a table that maps identifiers to locators is maintained. Each
destination effectively becomes a host route, and hierarchical
routing is generally not usable. For instance, a VM may have a
virtual address and might be located anywhere in a network. The
mapping table would contain a mapping of the virtual address of the
VM to the physical address of the server where the VM is running.
The number of virtualized or mobile nodes in a network is expected to
grow into the billions. This need for scaling is similar in both
mobile networks as well as datacenter and multi-tenant virtual
networks. In mobile networks, the explosion of IoT devices drives
scaling growth. In the datacenter it is the desire to use fine
grained addresses for tasks or more generally addressable virtual
objects.
2.10 Security
2.10.1 Mapping information
An identifier/locator solution will contain sensitive information
that includes identity and location of nodes. In the case that there
is a one-to-one correspondence between a network node and user, for
instance the node is a smart phone owned by an individual, this
information is Personally Identifiable Information (PII). A mapping
system needs to ensure security of this information.
2.10.2 Mapping protocols
Mapping protocols have a couple of security ramifications.
A mapping protocol must be authenticated in order to prevent spoofing
of messages. In particular, an attacker cannot be able to hijack a
mapping entry to redirect packets to their own node.
A mapping protocol must also be resilient to DOS attack, especially
in a scenario where a cache of mappings is being employed. Such a
cache might be populated in response to the activities of a third
party (for instance an application sending packets to different
destinations). An attack on the cache whereby an attacker attempts to
fill the cache with entries to random destinations must be
mitigated.
2.12 ICMP
ICMP presents problems for network overlays as well as
identifier/locator split. Specifically, the problem is how to return
ICMP errors to the sender that were caused as a result of using a
network overlay. ICMP errors that are returned to the source may
T. Herbert Expires July 26, 2018 [Page 10]
INTERNET DRAFT draft-herbert-ila-motivation
require translation of address in the ICMP data or other
modifications. There may also be security ramifications with ICMP,
for instance filtering ICMP may be necessary to prevent locator
information from leaking out of a network.
2.13 Multicast
Multicast is problematic in identifier/locator split since the
routing depends on the source address of a packet. If using the
network layer multicast, the source address must be a locator not an
identifier.
3 Motivation for ILA
3.1 Alternative network overlay technologies
A number of solutions for network overlays have be been defined or
proposed in IETF. This section considers layer 3 network overlay
solutions, and a few related layer 4 solutions for comparison. An
overview of each is provided along with a description of how they
deal with the problems enumerated in section 2 and where they are
deficient.
3.1.1 ILNP
Identifier-Locator Network Protocol (ILNP) is similar to ILA and in
fact some of the concepts of ILA were adapted from ILNP.
ILNP explicitly replaces the use of IP Addresses with two distinct
name spaces, each having distinct and different semantics:
a) Identifier: a non-topological name for uniquely identifying a
node.
b) Locator: a topologically bound name for an IP subnetwork.
Characteristics of ILNP are:
* ILNP changes the meaning of IP addresses.
* ILNP requires changes to transport layer protocols. Transport
layer endpoints are no longer IP addresses they are identifier
values.
* The pseudo header for TCP and UDP checksum changes. This might
break intermediate nodes that perform checkusm calculation such
as NICs that provides checksum offload.
T. Herbert Expires July 26, 2018 [Page 11]
INTERNET DRAFT draft-herbert-ila-motivation
* ILNP is an end to end overlay mechanism. There is no prescribed
method to use ILNP in intermediate nodes.
* ILNP defines a Nonce in Destination Options extension header.
* ILNP requires applications to use fully qualified domain names.
Applications that use IP addresses presumably need to change.
3.1.2 Encapsulation
Various encapsulation techniques are used to achieve layer 3 network
overlays. These includes IPIP, LISP, GRE, VXLAN, GUE, GTP-U, Geneve,
etc. These encapsulation protocols provide the means to create
overlays over IP networks via IP over IP encapsulation. They differ
in format and extensibility. For instance, IPIP is the simplest
method that just encapsulates one IP packet in another. GUE is a UDP
based encapsulation that is both generic and extensible.
Characteristics of encapsulation are:
* While encapsulation has proven functional and useful, it incurs
significant on-the-wire overhead, require substantial
processing, and may be incompatible with transport layer
specific network optimizations for TCP and UDP
* Outer IP header overhead. Adoption of IPv6 exacerbates the
overhead of encapsulation. Where simple IPv4 over IPv4
encapsulation has an overhead of twenty bytes, IPv6 or IPv4 over
IPv6 incurs overhead of forty bytes.
* Possible additional header overhead if UDP is used or there is
an encapsulation header
* Can be used at intermediate nodes for tunneling, so all the
issues involving tunneling must be addressed.
* Compatibility with hardware is an issue. UDP based encapsulation
overcomes some of the issues, but in itself creates new ones.
* Checksum handling must be considered in various contexts.
Encapsulation may break checksum offload feature commonly
implemented in NICs. Some network devices are incapable of
computing checksums, so if UDPv6 is used the checksum is often
set to zero. Some protocols allow a non-zero UDP checksum to be
ignored during reception in violation of [RFC1122].
* Issues around tunneling within the network have to be addressed
(described in section 2.3). These include dealing with MTU, IPv6
T. Herbert Expires July 26, 2018 [Page 12]
INTERNET DRAFT draft-herbert-ila-motivation
checksum, traceroute, ECN, and how to translate diffserv from an
inner header to an outer header.
* Encapsulation can be used in the network or at end hosts and
doesn't require any changes to transport layer implementation.
3.1.3 Segment routing
Segment routing (SR) has been proposed as a method to provide
identifier/locator split for mobile networks. SR leverages the source
routing paradigm. A node steers a packet through an ordered list of
instructions, called segments. A segment can represent any
instruction, topological or service-based. A segment can have a
semantic local to an SR node or global within an SR domain
Characteristics of segment routing are:
* Requires use of extension headers, specifically a routing
header.
* [RFC820] prohibits extension header insertion at intermediate
nodes. Encapsulation is required at ingress intermediate node to
use segment routing.
* The segment header itself be significant overhead. A segment
routing header with just a single address would be twenty four
bytes of overhead.
* Transport layer checksum is not kept correct when destination
address is changed. This could break checksum offload.
* Transport layer checksum does not protect the segment routing
header, so additional overhead is needed to detect corruption of
the SR header.
* Extension headers are not transparent to intermediate nodes and
this may cause incompatibility with network hardware
implementation resulting in loss of optimizations or relegation
to slow path processing.
3.1.4 Network Address Translation
ILA is similar to NAT (address translation not port translation) in
that it operates by rewriting the destination address of packet en
route. However, the transformation by ILA is always undone before the
packet is delivered to its ultimate destination.
T. Herbert Expires July 26, 2018 [Page 13]
INTERNET DRAFT draft-herbert-ila-motivation
Characteristics of NAT:
* No additional header overhead. Checksum neutral mapping might be
used to maintain correct transport layer checksum.
* Not useful as an overlay mechanism since NAT translation is not
undone before reception at a receiver
3.1.5 Transport layer mechanisms
There are a number of techniques used in the transport layer or
applications to handle mobility. Strictly speaking, these are not
network overlay techniques, however they can be used to provide
similar effects in mobility.
The simplest way to deal with an address change is just to require an
application to reconnect when a connection is disconnected. This is
not transparent to an application, it must have a method to
checkpoint progress on the connection and implement the reconnect
logic (this could be handled in a library). The latency to detect
that a connection is dead, reconnect, and then recover to a
checkpoint is likely much greater than that of a transparent network
layer solution.
Alternatively, a transport protocol may employ subflows to construct
a logical flow. This is the technique used by MPTCP and QUIC. These
techniques are transport layer specific, tend to be driven by one
sided, and require network layer information.
Proxies can also provide network overlay semantics. However, they
require statefulness in the network that creates single point of
failure and a potential bottleneck.
3.2 Benefits of ILA
This section enumerates the benefits of ILA and highlights how the
problems described in section 3 are addressed.
* ILA has zero on-the-wire overhead.
* Processing for ILA is efficient. A basic ILA transformation is
done by reading the destination address in a packet, performing
a fixed length lookup, and writing the destination address with
found locator.
* ILA does not employing tunneling so considerations for network
tunneling are not a concern.
T. Herbert Expires July 26, 2018 [Page 14]
INTERNET DRAFT draft-herbert-ila-motivation
* The ILA domain is effectively a virtual link layer or an
underlay network for the traffic being carried between hosts
outside of the ILA domain. As long as the ILA domain is
perfectly transparent to the overlay network and its hosts, then
what ever happens within the ILA domain doesn't matter, similar
to how link layer compression, as long as fully and perfectly
reversed, also doesn't matter.
* ILA maintains a correct transport layer checksum via checksum
neutral mapping.
* ILA can be deployed either in the network or on end hosts. When
deployed at end hosts, certain optimizations are available since
ILA is integrated into the host stack
* ILA is implemented at network layer. It requires no changes to
either applications or transport layer implementations.
* ILA is transparent to intermediate nodes so that it is
compatible with existing networking hardware and protocol
optimizations. A TCP/IP packet is still a TCP/IP packet after
being transformed by ILA.
* ILA enables singleton address assignment for privacy. It also
supports /64 address assignment.
* It is recommended that ILA be contained within an ILA domain
that is one network under administrative control. Locators are
not shared with parties outside of the domain.
* ILA espouses the use of secure redirects as the primary means to
populate a mapping cache. Push and pull models can be used,
however secure redirects should be effective in mitigating DOS
attacks and scalable.
* ILA allows alternative address representations for
identifier/locator split other than the canonical 64/64 split.
Non-local identifiers are defined as a method to use identifiers
to map to 128 bit IP addresses that might not be local to a
network.
* ILA defines optional addressing schemas for IPv4 to IPv6
translation, network virtualization with an embedded virtual
networking identifier, and encoding of IP multicast addresses.
* ILA defines identifier groups as a convenient way to group
identifiers together that have common characteristics.
Identifier groups should reduce the number of operations needed
T. Herbert Expires July 26, 2018 [Page 15]
INTERNET DRAFT draft-herbert-ila-motivation
on the mapping system.
* A reference datapath implementation is supported in stock Linux
since version 4.15. A userspace control path implementation will
be open sourced.
3.3 Limitations and caveats of ILA
This section describes limitations and caveats of ILA.
* While ILA has much less overhead than encapsulation or extension
headers, this does limit the amount of information that can be
expressed. ILA is not extensible like some encapsulations so
there is no means to associate ancillary information with ILA.
* /64 address assignment is feasible in ILA, however requires a
level of indirection in addressing.
* ILA operates by transforming destination IP addresses in
packets. Source addresses are not transformed. This works very
well for unicast traffic, but creates some complexity for
multicast in using the network layer multicast with ILA.
* If the network generates an ICMP error for a packet whose
destination contains a transformed address with a locator, the
embedded packet in ICMP data contains a destination address with
a locator. Before delivery to the original source host this
address should be converted back to the original destination
address.
* Firewalls should filter addresses in packets before ILA
translation. The typical scenario is that when a packet is
forwarded to a network ingress point, the firewall inspects the
packet before ILA is applied. An firewall internal to the
network may see ILA addresses as destinations; this should be
taken into account.
* Logging and tools need to be adapted since they may be operating
on ILA addresses. Logged addresses can be mapped to standard
identifier representation either by a fixed mapping or by
reverse mapping the address by a lookup in the mapping table.
The latter would be needed in the case of non-local identifier
addresses.
4 Use cases
4.1 Mobility networks
T. Herbert Expires July 26, 2018 [Page 16]
INTERNET DRAFT draft-herbert-ila-motivation
4.2 Datacenter virtualization
4.3 Network virtualization
5 References
5.1 Normative References
5.2 Informative References
Author's Address
Tom Herbert
Quantonium
Santa Clara, CA
USA
Email: tom@quantonium.net
T. Herbert Expires July 26, 2018 [Page 17]
