Internet DRAFT - draft-herbert-idloc-fast
draft-herbert-idloc-fast
INTERNET-DRAFT T. Herbert
Intended Status: Informational Quantonium
Expires: December 2018
June 26, 2018
Lightweight Identifier-Locator Mapping Using FAST
draft-herbert-idloc-fast-00
Abstract
This proposal provides a method to implement identifier to locator
mapping in the datapath without the need to access an in-network
mapping database or cache. Mappings are encoded in Firewall and
Service Tickets (FAST) tickets as locator information. When a packet
is sent by a mobile node, a ticket is attached that providers the
locator to use in the return path. Peer nodes receive packets with
these tickets, cache the tickets in a flow context, and then attach
them to packets they send as reflected tickets. When a packet with a
reflected ticket enters an identifier-locator domain, the ticket is
parsed to extract the locator. That locator is then used to send the
packet to the appropriate destination over a network overlay.
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 December 28, 2018 [Page 1]
INTERNET DRAFT draft-herbert-idloc-fast-00 June 26, 2018
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 Background and motivation . . . . . . . . . . . . . . . . . . . 4
2.1 Mapping Systems . . . . . . . . . . . . . . . . . . . . . . 4
2.2 hICN mobility proposal . . . . . . . . . . . . . . . . . . . 5
2.3 Firewall and Service Tickets . . . . . . . . . . . . . . . . 5
3 Solution Overview . . . . . . . . . . . . . . . . . . . . . . . 6
3.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . 6
3.2 Reference Topology . . . . . . . . . . . . . . . . . . . . . 7
3.3 Basic packet flow . . . . . . . . . . . . . . . . . . . . . 8
4 Firewall and Service Tickets encoding . . . . . . . . . . . . . 9
4.1 ILA locator encoding . . . . . . . . . . . . . . . . . . . . 10
4.2 Locator index encoding . . . . . . . . . . . . . . . . . . . 10
5 Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
5.1 Packet flow . . . . . . . . . . . . . . . . . . . . . . . . 11
5.1.1 Ticket requests . . . . . . . . . . . . . . . . . . . . 11
5.1.1.1 Fully qualified locators . . . . . . . . . . . . . . 12
5.1.1.2 Unqualified locators . . . . . . . . . . . . . . . . 12
5.1.2 First hop router processing . . . . . . . . . . . . . . 12
5.1.3 Transit to the peer . . . . . . . . . . . . . . . . . . 12
5.1.4 Peer reflection . . . . . . . . . . . . . . . . . . . . 12
5.1.5 Return path from peer . . . . . . . . . . . . . . . . . 13
5.1.6 Ingress into the origin network . . . . . . . . . . . . 13
5.1.7 Network overlay termination . . . . . . . . . . . . . . 13
5.1.8 Reception at origin of application . . . . . . . . . . . 14
5.2 Fallback . . . . . . . . . . . . . . . . . . . . . . . . . . 14
5.3 Mobile events . . . . . . . . . . . . . . . . . . . . . . . 14
5.4 Interaction with expired tickets . . . . . . . . . . . . . . 15
6 Security Considerations . . . . . . . . . . . . . . . . . . . . 15
7 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 16
8 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 16
9 References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
9.1 Normative References . . . . . . . . . . . . . . . . . . . 16
T. Herbert Expires December 28, 2018 [Page 2]
INTERNET DRAFT draft-herbert-idloc-fast-00 June 26, 2018
9.2 Informative References . . . . . . . . . . . . . . . . . . 16
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16
T. Herbert Expires December 28, 2018 [Page 3]
INTERNET DRAFT draft-herbert-idloc-fast-00 June 26, 2018
1 Introduction
Identifier-locator protocols, such as ILA and LISP, rely on a
distributed mapping system that maps identifiers to locators for
transmit across an overlay network. Typically, the set of mappings
are maintained in a distributed database or mapping cache. Border
routers of an identifier-locator domain access the database or cache
to map ingress packets to their appropriate locator. The router can
then use a network overlay method to deliver the packet to the mobile
destination; this could be done by address transformation (like in
ILA) or encapsulation (as done by LISP).
This proposal suggests and alternative method to do fast path
anchorless mobility with identifier-locator protocols that eschews
accessing a mapping database or mapping cache in the datapath.
2 Background and motivation
This section provides background and motivation.
2.1 Mapping Systems
Identifier-locator protocols, network virtualization, and mobility
share a common problem of resolving a mobile or virtual node to its
location in the network. In identifier-locator terminology this is
mapping an identifier to a locator. In virtualization, the process is
mapping a virtual address to a physical address, and in mobility it
is determining the current location of a host with a mobile address.
In a common overlay model, the mapping of identifier to locator is
done before sending a packet over a network overlay. The locator is
an underlay address for forwarding a packet across the network
overlay. There are several methods that can be used to implement the
network overlay, for instance encapsulation or address transformation
could be used, however the motivation and operation mapping
identifiers to locators are essentially the same in any case.
The set of identifier to locator mappings essentially is a
distributed database, and in fact some implementations implement a
mapping system using an "off the shelf" database. Identifiers don't
inherently allow aggregation, so the number of individual entries in
the mapping system maybe quite large (at most one entry for each
identifier). Even in a moderate size network the number of entries
will exceed the number that can be stored in memory of a singe device
so the mapping system must be sharded in some fashion.
One proposed method to scale a mapping system is to use mapping
caches. Border routers implement a mapping cache that contains a
T. Herbert Expires December 28, 2018 [Page 4]
INTERNET DRAFT draft-herbert-idloc-fast-00 June 26, 2018
working set of identifier to locator mappings for traffic currently
passing through the router. Caches are a dynamic optimization driven
by the traffic pattern, however their use in the network entails
potential issues of scaling and DOSability.
2.2 hICN mobility proposal
hICN with anchorless mobility [HICN-AMM] is an alternative proposal
to using a distributed mapping system with identifier locator
protocols.
[HICN-AMM] highlights some drawbacks of traditional mapping systems:
o They entangle forwarding operations and changes to network
location
o Mapping systems at large scale are difficult to manage
o Convergence time after a location change (handover in mobile
network terminology) may be excessive.
[HICN-AMM] and [HICN] describe a solution that eliminates the need
for a global mapping system by sending locator information in-line
with the data path. The locator information is embedded in a new
transport layer header ("Path Label" in transport header shown in
[HICN]). The transport layer header is parsed by routers in the path
and they use the information to create state for forwarding packets
in the return path.
The proposal described in this draft adopts the in-line approach to
convey locator information, however the protocol in the FAST method
is strictly confined to the network layer and there is no requirement
for transport state to be maintained by the network.
2.3 Firewall and Service Tickets
Firewall and Service Tickets (FAST) is a technique to allow an
application to signal to the network requests for admission and
services for a flow. A ticket is data that is attached to a packet by
the source that is inspected and validated by intermediate nodes in a
network. Tickets express a grant or right for packets to traverse a
network or have services applied to them. Tickets may also be
modified by intermediate nodes under certain circumstances.
In order to apply services to inbound packets for a communication,
remote peers reflect received tickets in packets they send without
interpreting them. Tickets are stateless within the network, however
they can be used to attain per flow semantics. Note that in lieu of
T. Herbert Expires December 28, 2018 [Page 5]
INTERNET DRAFT draft-herbert-idloc-fast-00 June 26, 2018
creating flow state in the network, state of interest to the network
can be cached at the endpoints and provided in data packets. Tickets
are encrypted and opaque to the end points for security and privacy.
This proposal uses FAST tickets to convey and reflect locator
information from a peer. FAST tickets employ IPv6 Destination or Hop-
by-Hop options.
3 Solution Overview
The central idea of using identifier locator protocols with FAST is
to put locator information in packets that can be used by network
nodes to achieve forwarding over a network overlay. In FAST, the
information is contained in a ticket and can be encrypted or
otherwise obfuscated so that only the nodes in the network that set
the information in the packet can parse it.
Transparent mobility can be achieved within the network layer, and
accordingly this solution and protocol are confined in the network
layer. Any signaling between applications and the network, or between
transport protocols and the network, is done via IPv6 Destination or
Hop-by-Hop options. This solution is specific to IPv6.
3.1 Requirements
This section lists some requirements for using FAST with identifier
locator protocols as a solution for fast and efficient mobility.
Requirements are:
- Solution works with any transport protocol or application
- Intermediate devices only process, inspect, or change network
layer headers as specified by RFC8200
- Communication for a flow is bidirectional (at least packets are
sent in both directions)
- Solution is an optimization for highly efficient fast path
anchorless mobile communications. The system must allow a slow
path fallback (for instance if extension headers are dropped for
some path)
- Client side supports FAST. Changes are described in [FAST]. This
should entail no kernel or protocol stack changes since FAST is
encoded in extension headers than can be set for flows using
existing APIs
T. Herbert Expires December 28, 2018 [Page 6]
INTERNET DRAFT draft-herbert-idloc-fast-00 June 26, 2018
- Server side supports ticket reflection as described in [FAST].
This is a generic change in the protocol stack that should be
transparent to applications.
- FAST routers need to be deployed. These are typically border
routers of a domain as described in [FAST]
- Other intermediate nodes need to properly forward packets with
FAST tickets (Hop-by-Hop or Destination options). Note that
RFC8200 relaxes the requirement that all nodes in a path process
Hop-by-Hop options
- Does not rely an transport state being maintained in the network
- Makes no assumptions that packets for a flow always follow the
same path, or that any part of the network path must symmetric
for both directions of a flow
- Maintain security and privacy. In particular, locators are only
visible in the network that implement an overlay that uses them
3.2 Reference Topology
The diagram below provides a reference topology for a simple mobile
network.
______
_________ ( )
+---------+ ( ) +---------+ ( ) +------+
| eNodeB1 +---( RAN )---+ BRouter +---( Internet )--+ Peer |
+---------+ (_________) +----+----+ ( ) +------+
| \ | (______)
+---------+ | \ |
| eNodeB2 +-------+ \ |
+---+-----+ +--------+--+
| | Anchor |
+---+-----+ +-----------+
| UE |
+---------+
Figure 1
The diagram shows a mobile network that contains two eNodeB's (points
of attachment) and one UE (end device) that is currently attached to
eNodeB2. The UE is mobile so it can move from one eNodeB to another
(for instance it may attach to eNodeB1 at some point). The externally
visible address of the UE is an identifier that does not change when
the UE moves in the network. In the diagram, UE may be communicating
with the "Peer" host in the Internet. The Peer only knows the UE by
T. Herbert Expires December 28, 2018 [Page 7]
INTERNET DRAFT draft-herbert-idloc-fast-00 June 26, 2018
its externally visible address. To achieve communications, packets
from the Peer to the UE are sent over some type of network overlay.
The packets of interest with respect to mobility are those destined
to the UE. The Peer might itself be mobile, but that case should be
symmetric and transparent. In this model, it is the local network of
a node that deals with mobility of devices in the network.
It is common for mobile communications to go through an anchor point
that has access to the complete mapping database and provides the
entry point to the network overlay. Anchors may be heavyweight and
force packets into a "long" path with respect to latency. There is
motivation to allow a fast path for critical latency sensitive
communications that bypass anchor points. In figure 1, this fast path
would be implemented in BRouter. That is instead of forwarding
packets through the Anchor, it performs identifier locator-mapping
and network overlay functions itself.
The typically proposed method to eliminate the anchor point is to
implement a mapping cache (in the diagram this would be to place a
cache at BRouter). The proposal described here is an alternative that
doesn't requires a cache.
3.3 Basic packet flow
To use identifier-locator protocols with FAST, an application running
on a host gets a ticket from the network. The ticket encodes
information about the current location of the host. When the
application sends packet, the ticket is attached (in an extension
header). Packets having the ticket are the forwarded to the peer
destination. At the peer, the ticket is saved in flow context, and
subsequently when it sends response packets back to the UE the ticket
is attached to packets as a reflected ticket.
When a packet with a ticket is received at a border router of an
identifier-locator domain, the router parses the reflected ticket and
checks if locator information is included. If it is, the border
router then uses it to send the packet to the proper destination for
the network overlay.
For example, if ILA is in use in the network topology show above, the
flow might be:
1) Application in UE requests ticket, a ticket agent in the
provider network provides a ticket with locator information
indicating that UEs location is at eNode2.
2) Application sends packets. A ticket containing locator
T. Herbert Expires December 28, 2018 [Page 8]
INTERNET DRAFT draft-herbert-idloc-fast-00 June 26, 2018
information for eNodeB2 is attached to each packet.
3) Packet traverse network and are received at Peer. The peer node
saves the receive ticket in a flow context for the application.
4) Peer sends responses. The saved ticket is attached to its
packets as reflected tickets.
5) When a packet is received from the peer at BRouter, the
attached ticket is parsed. The locator information is extracted
that indicates the locator for eNodeB2. BRouter transforms the
destination address to an ILA locator address and forwards the
packet.
6) eNodeB receives ILA packets and performs the reverse
transformation to restore the original destination address
(typical ILA-N processing).
7) Packets are forward to UE. They still contain a ticket which
can be validated by the UE.
4 Firewall and Service Tickets encoding
FAST tickets are encoded in Hop-by-Hop or Destination options. If an
option is modifiable then Hop-by-Hop options should be used.
The format of a FAST ticket in a Destination or Hop-byHop option is:
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Opt Data Len | Type | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
~ Ticket ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Tickets are not intended to be parsed outside of the origin network
domain that issues them. Therefore, the ticket format is arbitrary at
the discretion of the domain in which they are issued and
interpreted.
T. Herbert Expires December 28, 2018 [Page 9]
INTERNET DRAFT draft-herbert-idloc-fast-00 June 26, 2018
[FAST] suggests a simple and efficient encoding of a Service Profile
Index:
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Expiration time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Profile Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This format can be amended to include locator information. Below are
some example encodings. Note that tickets are potentially set in all
datapath packets so minimizing protocol overhead is a consideration.
4.1 ILA locator encoding
ILA locators are sixty-four bits, and they can be encoded in a FAST
ticket in straightforward fashion. A ticket with expiration time,
service profile and an ILA locator may have format:
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |Q| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Expiration time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Profile Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Locator +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Where the 'Q' bit indicates that an unqualified locator was
overwritten. See Section X.
A full 128 bit address could similarly be encoded.
4.2 Locator index encoding
A network may have a comparatively small number of potential
locators. For instance, a mobile provider might associate each eNodeB
with a locator and there may only be a few million of these. In this
case, the border routers might maintain a static table of locator
addresses that can simply be indexed by number in a much smaller
range. A locator index encoded in a ticket might look like this:
T. Herbert Expires December 28, 2018 [Page 10]
INTERNET DRAFT draft-herbert-idloc-fast-00 June 26, 2018
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |Q| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Expiration time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Profile Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Locator Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Where the 'Q' bit indicates that an unqualified locator was
overwritten.
5 Operation
This section describes the operation of identifier-locator protocols
using FAST.
5.1 Packet flow
This sections describes the details of packet flow using identifier
locator protocols with FAST.
5.1.1 Ticket requests
Applications request FAST tickets from a ticket agent in the network
local to the application. The ticket agent can return a ticket for
the application to use in its data packets. The ticket includes
information that is parsed by elements in the issuing network. The
ticket information may include a locator. In other words if the
application is on a mobile device, the network may provide a ticket
that has a locator indicating the current location of the device.
[FAST] describes the process of an application requesting tickets and
setting them in packets. An application will not normally need to
make any special requests for mobility, in this model mobility is
expected to be transparent to the application (the ticket may contain
information about mobility that is opaque to the application). An
issued ticket having locator information will be of type "origin
ticket to be reflected".
There are two possibilities for locator information in an issued
ticket:
1) The locator is fully qualified.
2) The locator is no qualified.
T. Herbert Expires December 28, 2018 [Page 11]
INTERNET DRAFT draft-herbert-idloc-fast-00 June 26, 2018
5.1.1.1 Fully qualified locators
If the locator is qualified then the issued ticket contains the
locator for the end node. If the locator changes, that is the node
moves, then a new ticket will need to be issued to the application.
5.1.1.2 Unqualified locators
If the locator is not qualified, then the locator information in the
issued ticket contains a "not set" value. For instance, in the case
the locator is expressed by a Locator Index as in section 2.2, the
"not set" value may be -1 (all ones). A upstream router of an end
node may write a qualified locator value into the locator
information; most often this would just be its own locator value in
cases where it is the first upstream hop of end devices that provides
location in the network. For instance, an eNodeB router acting as the
first hop for a UE may write its locator value in tickets of packets
it's forwarding from UEs. The implication is that this will be the
locator used in the network overlay on the return path to reach the
end node. Note that to write a locator into to a ticket requires that
the ticket is in a modifiable Hop-by-Hop option.
5.1.2 First hop router processing
Once an application has been issued a ticket with a locator it will
set the tickets in all packets sent to the peer node. The first hop
upstream router in the FAST domain parses the ticket; this may
typically be the first hop router in a provider network closest to
end customer node.
If the ticket contains a qualified locator, the first hop node may
validate it (as part of FAST ticket validation). If the ticket has
unqualified locator information, the first hop node may set it to a
qualified locator value in the packet. As described above, the
locator information written is likely to be that corresponding to the
locator of the first hop device.
5.1.3 Transit to the peer
Beyond the first hop router to the ultimate peer destination, no
processing of the locator information in a ticket should be needed.
Intervening networks and routers should deliver the ticket to the
destination host unchanged.
5.1.4 Peer reflection
At the peer host, the procedures described in [FAST] are followed to
save the received ticket in a flow context and to reflect it in
T. Herbert Expires December 28, 2018 [Page 12]
INTERNET DRAFT draft-herbert-idloc-fast-00 June 26, 2018
subsequent packets. As with other reflected tickets, one containing
locator information is treated as an opaque value that is not parsed
or modified by the peer or any network outside of the origin network.
5.1.5 Return path from peer
Packets sent by a peer will include reflected tickets for a flow. No
processing of the locator information in a ticket should be needed
until the packet reaches the origin network of the ticket.
Intervening networks and routers should deliver the ticket to the
destination origin network unchanged.
5.1.6 Ingress into the origin network
A the border router for the origin network, tickets are parsed and
the encoded services are applied. If the ticket contains locator
information then that can be used for forward the packet over the
overlay network.
The specific operation depends on the protocol used to provide the
overlay network functionality. For instance, if ILA is in use and the
locator information is just a sixty-four bit locator as described in
Section 4.1, then the given locator is written to the destination of
the packet and the packet is forwarded towards the locator following
the procedures of ILA. Similarly, if a locator index is contained in
the ticket as described in Section 4.2, then that value is used to
index the locator table to get a sixty-four bit locator that can be
written into the destination address. Procedures for use of the
locator information to do encapsulation, such as that done by LISP,
are similar.
Note that the service parameters contained in the ticket may provide
addition information about how the packet is to be sent over the
network overlay. For instance, the service parameters might indicate
the packet is encrypted or to use some extensions of an encapsulation
protocol.
5.1.7 Network overlay termination
When a packet is received at the terminating point of an overlay it
is restored to the original packet. That is, if the packet was
encpasulated then it's unencpasulated, or if the destination address
was transformed then the reverse transformation is done to restore
the original address.
If the ticket was modified by the network, for instance an
unqualified locator was overwritten (indicated by the 'Q' bit being
set as described in Section 4), then the original ticket needs to be
T. Herbert Expires December 28, 2018 [Page 13]
INTERNET DRAFT draft-herbert-idloc-fast-00 June 26, 2018
restored.
5.1.8 Reception at origin of application
At the end host, received reflected tickets are validated for
acceptance as described in [FAST]. This is done by comparing the
received ticket to that which was sent on the corresponding flow.
5.2 Fallback
The proposal described here is strictly a fast path optimization. It
should not be assumed that tickets can completely replace a mobile
infrastructure. In particular, this solution relies on several
parties to implement protocols correctly. For instance, the use of
extension headers requires that they can be successfully sent through
a network. As reported in [RFC7872], support for forwarding packets
with extension headers is not yet ubiquitous.
Therefore, a fallback infrastructure is required. In the simplest
case, this is just to fallback to forwarding through anchor points.
That path can be chosen independently of whether the fast path is
implemented. In the data path the selection of which path to take is
easily chosen, if a packet contains a valid ticket with valid locator
information then the fast path can be taken, else the slow path is
selected.
5.3 Mobile events
When a mobile node moves and its locator changes, it is desirable to
converge to using the new locator as a quickly as possible. With
tickets that contain locator information, a modified ticket needs to
be sent to a peer host.
If an application was issued a ticket with qualified locator
information then a new ticket needs to the be issued. This can be
done by the application receiving a signal that a mobile event has
occurred that causes it to make new ticket requests for established
flows.
If an application has a ticket with an unqualified locator then the
network should start writing the new locator information into packets
that are sent by the application after the mobile event. This should
be transparent to the application.
Note that in either case, in order to update the tickets that a peer
is reflecting, the application needs to send packets to the peer that
includes an updated ticket. There is no guarantee on when an
application may send packets, so there is the possibility of a window
T. Herbert Expires December 28, 2018 [Page 14]
INTERNET DRAFT draft-herbert-idloc-fast-00 June 26, 2018
where the peer node is sending reflected tickets with outdated
locator information. The window should be limited by the expiration
time of a ticket (see below), however it is recommended to implement
mechanisms to avoid communication blackholes. For instance, a "care
of address" mapping entry could be installed at the old locator
device to forward to the new one. Such solutions are also used to
mitigate database convergence time or update caches in other
solutions.
5.4 Interaction with expired tickets
FAST typically expects ticket to have an expiration time. If a ticket
is received within the expiration time and it is considered valid,
then the packet is forwarded per the services indicated by the
ticket. If a packet with a ticket is received that is expired, it
might still be accepted subject to rate limiting. Accepting expired
tickets is useful in the case that a connection goes idle and after
some time the remote peer starts to send.
For tickets that are expired and contain locator information, an
implementation should ignore the locator information and take the
fallback path. If the mobile application responds it can include a
fresh ticket so that the fast path is taken on subsequent packets.
Ignoring the locator information in expired tickets puts an upper
bound on the window that an outdated locator can be used (see section
5.3).
6 Security Considerations
Locator information can be highly sensitive data especially if it
could reveal physical location of individuals. Effort must be made to
safeguard this information. In particular, locators in plain text
should only be exposed within the origin network providing mobility.
This includes hiding locators from end hosts. [FAST] discusses
security of tickets including recommendations to encrypt them.
Tickets may be reused in packets for some period, and it is desirable
to prevent third parties from making an inferences based on the fact
the a ticket for a flow changed. For instance, it should not be
deducible that a node has moved on the basis of a new ticket being
used on a flow. To avoid this possibility tickets for a flow should
be changed randomly to avoid correlating ticket changes to events.
T. Herbert Expires December 28, 2018 [Page 15]
INTERNET DRAFT draft-herbert-idloc-fast-00 June 26, 2018
7 IANA Considerations
There are no IANA considerations in this document. [FAST] requests
numbers for Destination and Hop-by-Hop options that would be used by
this proposal.
8 Acknowledgments
9 References
9.1 Normative References
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200, DOI
10.17487/RFC8200, July 2017, <https://www.rfc-
editor.org/info/rfc8200>.
[FAST] Herbert, T., "Firewall and Service Tickets", draft-herbert-
fast-01, June 2018.
9.2 Informative References
[HICN] L. Muscariello, G. Carofiglio, J. Auge, and M. Papalini,
"Hybrid Information-Centric Networking", draft-muscariello-
intarea-hicn-00, June 2018
[HICN-AMM] Auge, J., Carofiglio, G., Muscariello, L., and M.
Papalini, "Anchorless mobility management through hICN
(hICN-AMM): Deployment options", draft-auge-dmm-hicn-
mobility-deployment-options-00 (work in progress), June
2018.
Author's Address
Tom Herbert
Quantonium
Santa Clara, CA
USA
Email: tom@quantonium.net
T. Herbert Expires December 28, 2018 [Page 16]
