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

Versions: 00

INTERNET-DRAFT                                                T. Herbert
Intended Status: Informational                                Quantonium
Expires: April 2019

                                                        October 10, 2018

            Encoding Routing in Firewall and Service Tickets


   This document describes a method to encode routing information in
   Firewall and Service Tickets (FAST). Encoded routing information
   provides the local routing for packets sent in either the forward or
   return paths of a flow. FAST ticket reflection at peer hosts ensures
   that the routing information is attached to packets being sent in the
   return path. When a packet with a FAST ticket containing routing
   information enters the network in which the ticket was issued, the
   ticket is parsed to extract the routing information and is forwarded
   per the information. Routing in Firewall and Service Tickets has a
   number of use cases. It can be used as a type of source routing, used
   with identifier-locator protocols to provide a locator in the return
   path, and can be used to specify a backend instance in Layer 4 load
   balancing for processing connections to a virtual IP address.

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

   The list of Internet-Draft Shadow Directories can be accessed at

T. Herbert               Expires April 13, 2019                 [Page 1]

INTERNET DRAFT        draft-herbert-route-fast-00       October 10, 2018

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
   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 Problem statement  . . . . . . . . . . . . . . . . . . . . .  4
     2.2 Firewall and Service Tickets . . . . . . . . . . . . . . . .  4
     2.3  Similar efforts . . . . . . . . . . . . . . . . . . . . . .  5
       2.3.1 Segment routing  . . . . . . . . . . . . . . . . . . . .  5
       2.3.2 hICN mobility proposal . . . . . . . . . . . . . . . . .  5
     2.4 Use cases  . . . . . . . . . . . . . . . . . . . . . . . . .  6
       2.4.1 Identifier-locator protocols and virtualization  . . . .  6
       2.4.2 Segment routing  . . . . . . . . . . . . . . . . . . . .  6
       2.4.3 Layer 4 load balancing . . . . . . . . . . . . . . . . .  7
   3  Solution Overview . . . . . . . . . . . . . . . . . . . . . . .  8
     3.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . .  8
     3.2 Reference Topology . . . . . . . . . . . . . . . . . . . . .  9
     3.3 Basic packet flow  . . . . . . . . . . . . . . . . . . . . . 10
   4  Firewall and Service Tickets encoding . . . . . . . . . . . . . 11
     4.1 ILA locator encoding . . . . . . . . . . . . . . . . . . . . 12
     4.2 Locator index encoding . . . . . . . . . . . . . . . . . . . 12
   5  Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
     5.1 Ticket requests  . . . . . . . . . . . . . . . . . . . . . . 13
     5.2 Qualified locators . . . . . . . . . . . . . . . . . . . . . 13
       5.2.1 Fully qualified locators . . . . . . . . . . . . . . . . 14
       5.2.2 Unqualified locators . . . . . . . . . . . . . . . . . . 14
     5.3 First hop router processing  . . . . . . . . . . . . . . . . 14
     5.4 Transit to the peer  . . . . . . . . . . . . . . . . . . . . 14
     5.5 Ingress into the origin network  . . . . . . . . . . . . . . 15
     5.6 Network overlay termination  . . . . . . . . . . . . . . . . 15
     5.7 Fallback . . . . . . . . . . . . . . . . . . . . . . . . . . 16
     5.8 Mobile events  . . . . . . . . . . . . . . . . . . . . . . . 16
     5.9 Interaction with expired tickets . . . . . . . . . . . . . . 16

T. Herbert               Expires April 13, 2019                 [Page 2]

INTERNET DRAFT        draft-herbert-route-fast-00       October 10, 2018

   6  Security Considerations . . . . . . . . . . . . . . . . . . . . 17
   7  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 18
   8  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 18
   9  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 18
     9.1 Normative References . . . . . . . . . . . . . . . . . . . . 18
     9.2 Informative References . . . . . . . . . . . . . . . . . . . 18
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 18

T. Herbert               Expires April 13, 2019                 [Page 3]

INTERNET DRAFT        draft-herbert-route-fast-00       October 10, 2018

1  Introduction

   This document specifies a method to encode routing information in
   Firewall and Service Tickets (FAST). FAST allows hosts to signal the
   network for services to be applied to packets in the form of tickets
   that are issued by the network and attached to packets. Tickets may
   encode information as to how the packet is to be routed in the local
   network. Tickets can be reflected by peer nodes for a connection, so
   that routing information can be applied in the reverse path of a
   flow. When a packet with an attached ticket containing routing
   information enters a network, the ticket is parsed and the encoded
   routing is applied to the packet. The routing information is
   arbitrary per the network's needs. For instance, it may indicate a
   tunnel to send the packets on, a segment routing list, a locator in
   identifier-locator protocols, or the IP address for a backend
   instance of a layer 4 load balancer.

2  Background and motivation

   This section provides background and motivation.

2.1 Problem statement

   A network may implement arbitrary complex routing of packets, mobile
   routing functions, or routing for service function chains. Often such
   functions require routing packets on a per flow basis or perhaps
   based on some awareness of application content.

   Typically, this advanced routing is done by an ingress router into a
   network. This router may need to perform Deep Packet Inspection (DPI)
   into the transport layer, may maintain state for every flow
   traversing it, or may maintain a mapping table of mobile or virtual
   addresses to their locators or physical nodes. The net effect is that
   intermediate nodes perform complex transport protocol specific
   functions that are difficult to to scale. In turn, the complexity in
   such nodes contributes to protocol ossification.

2.2 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,

T. Herbert               Expires April 13, 2019                 [Page 4]

INTERNET DRAFT        draft-herbert-route-fast-00       October 10, 2018

   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
   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.
   FAST is IPv6 specific and uses Hop-by-Hop options.

   This draft proposes to encode routing information into FAST tickets.
   The necessary information for routing packets is contained within the
   network layer headers of each packet. The encoded data obviates the
   need for DPI, flow state, or complex route lookups at ingress

2.3  Similar efforts

   This section highlights similar efforts that encode routing
   information in packets with the intent that intermediate nodes will
   consume the information.

2.3.1 Segment routing

   Segment routing [SPRING] is a type of source routing that employs a
   routing header. A segment routing header contains a list of segment
   identifiers (SIDs) that indicate the nodes to visit by their IPv6
   addresses. Segment routing is often deployed with IP encapsulation.
   When a packet enters a segment routing domain, a lookup is performed
   on the packet to retrieve the segment list. The packet is then
   encapsulated in IPv6 and a segment routing header is attached to the
   packet. The lookup may be stateless in simple cases, or may require a
   stateful lookup with full blown connection tracking.

   Segment routing is intended for use in a limited domain and not on
   the Internet. Use over the Internet would expose internal addresses
   in the route list, offers no security, and would have considerable
   overhead. Additionally, segment routing only describes routing in the
   the forward path to a destination, not the return path.

2.3.2 hICN mobility proposal

   hICN with anchorless mobility [HICN-AMM] is an alternative proposal
   to using a distributed mapping system with identifier locator

   [HICN-AMM] highlights some drawbacks of traditional mapping systems:

      o They entangle forwarding operations and changes to network

T. Herbert               Expires April 13, 2019                 [Page 5]

INTERNET DRAFT        draft-herbert-route-fast-00       October 10, 2018

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

   Similar to FAST, the hICN proposal adopts an in-line approach to
   convey routing 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.4 Use cases

   This section highlights some use cases of FAST to carry routing

2.4.1 Identifier-locator protocols and virtualization

   Identifier-locator protocols, such as ILA and LISP, rely on a
   distributed mapping system that maps identifiers to locators for
   transit across a network overlay. 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 packets to their mobile
   destination; this could be done by address transformation (like in
   ILA) or encapsulation (as done by LISP).

   This proposal suggests an alternative which is to encode locators in
   Firewall and Service Tickets. This method allows fast path anchorless
   mobility with identifier-locator protocols that eschews accessing a
   mapping database or mapping cache for every packet in the datapath.

2.4.2 Segment routing

   A FAST ticket could encode bits that network nodes interpret and
   expand into a segment routing list. When a ticket with such an
   encoding enters a network, or segment routing domain in this case, it
   is parsed and the information is expanded to the full segment list.
   The packet is encapsulated, the segment list is attached in a routing
   header, and the packet is forwarded towards the destination. The

T. Herbert               Expires April 13, 2019                 [Page 6]

INTERNET DRAFT        draft-herbert-route-fast-00       October 10, 2018

   encoded information might have some compressed form such as an index
   into a table or a bit map of nodes or services that are needed. FAST
   tickets are encrypted or obfuscated so that they are opaque to the
   Internet, they are also reflected so that segment routing can be
   applied to the reverse path of flow.

2.4.3 Layer 4 load balancing

   Layer 4 load balancers route packets addressed to virtual IP
   addresses (VIPs). A virtual IP address is shared amongst some number
   of backend servers. Routing to backend servers is done on a per flow
   basis so that the targeted backend is the one that terminates the
   flow. Routing must be consistent for the lifetime of the flow lest
   packets are received on the wrong backend (in which case packets are
   dropped and the connection might be disconnected.

   Consistent routing is accomplished in two ways: 1) a consistent hash
   of the 5-tuple is used to load balance flows across the backend
   servers, and 2) connection tracking is used to map a flow to its
   assigned backend server. The number of backend servers may be dynamic
   and connections may be migrated between servers. The goal of routing
   by a load balancer is to minimize black holes and connection drops.
   The Maglev load balancer [MAGLEV] implements an efficient algorithm
   employing a hybrid of these two techniques, however it does not
   entirely eliminate the possibility of connections being dropped.

   Both tuple hashing and connection tracking have some disadvantages.
   Consistent hashing in the presence of dynamic number servers is a
   hard problem. Connection tracking entails network state which is
   difficult to scale and can be susceptible to Denial of Service (DOS)

   FAST can be applied to provide a stateless and robust solution for
   load balancing. When a server backend server receives a connection
   request it creates a ticket that encodes its instance identity (for
   example the backend IP address). The ticket is attached to packets
   for the connection that are sent back the client. The client in turn
   will reflect the tickets in subsequent packets it sends. When the
   load balancer receives a packet with a reflected ticket, it decodes
   the ticket and extracts the identity of the assigned backend server.
   The load balancer then forwards the packet to the address for the
   indicated backend. If received packets don't have a ticket attached
   (the first packet on the connection or the peer doesn't reflect
   tickets) then tuple hashing can be used as a fallback.

   Using FAST to encode the backend server instance is impervious to
   changes to the number of backend servers and requires no flow state
   in the network. If a connection migrates, the server simply creates a

T. Herbert               Expires April 13, 2019                 [Page 7]

INTERNET DRAFT        draft-herbert-route-fast-00       October 10, 2018

   new ticket that indicates the new backend server for the flow. Once
   the server sends packets with the updated ticket, the client will
   reflect it and the load balancer will properly route packets for the
   flow to the correct backend.

3  Solution Overview

   The central idea of this design is that arbitrary routing information
   is attached to packets and is interpreted by network nodes to achieve
   expedited forwarding. In FAST, routing information is encoded in
   tickets and can be encrypted or otherwise obfuscated. Only the nodes
   in the origin network of the information are able to parse and
   interpret it. Since the information is secured it can safely be
   contained in packets sent on the open Internet.

   Since packets contain the information needed to route them, route
   lookups and per flow state maintained in the network to hold routing
   information is obviated. Packets can effectively be source routed in
   both the forward and return paths. FAST operates at the network layer
   and doesn't require network nodes to perform Deep Packet Inspection
   (DPI) into the transport layer. Any signaling between applications
   and the network, or between transport protocols and the network, is
   done via Hop-by-Hop options. This solution is specific to IPv6.

3.1 Requirements

   This section lists some requirements for encoding routing in FAST.

   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

      - Solution is an optimization for fast path routing. The system
        must allow a slow path fallback (for instance, if extension
        headers are dropped for some path)

      - Client side supports FAST. Necessary support is 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

      - Server side supports ticket reflection as described in [FAST].
        This is a generic change in the protocol stack that should be

T. Herbert               Expires April 13, 2019                 [Page 8]

INTERNET DRAFT        draft-herbert-route-fast-00       October 10, 2018

        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 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 be
        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
                     __________                     (      )
     +---------+    ( Provider )    +---------+    (        )   +------+
     | eNodeB1 +---(  network   )---+ 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 host device) that is 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
   its externally visible address. To achieve communications, packets
   from the Peer to the UE are sent over some type of network overlay
   when transiting the provider network.

T. Herbert               Expires April 13, 2019                 [Page 9]

INTERNET DRAFT        draft-herbert-route-fast-00       October 10, 2018

   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 mobile 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 require a cache.

3.3 Basic packet flow

   To use routing with FAST, an application running on a host gets a
   ticket from the network. The ticket encodes the routing information
   of interest to the network. When the application sends a packet, the
   ticket is attached (in an extension header). Packets with the ticket
   are the forwarded to the peer destination. At the peer, the ticket is
   saved in a flow context. Subsequently, when an application sends
   response packets back to its peer the ticket is attached to packets
   as a reflected ticket.

   When a packet with a ticket is received at a border router of the
   domain that issued the ticket, the router parses the reflected ticket
   and verifies it. If it is valid, the border router applies the
   encoded routing information to forward the packet on to its

   For example, if ILA is in use in the network topology show above, the
   flow might be:

      1) Application in UE requests a ticket. A ticket agent in the
         provider network provides a ticket with locator information
         indicating that UE's location is at eNode2.

      2) Application sends packets. The ticket containing locator
         information for eNodeB2 is attached to each packet.

      3) Packets traverse network and are received at Peer. The peer

T. Herbert               Expires April 13, 2019                [Page 10]

INTERNET DRAFT        draft-herbert-route-fast-00       October 10, 2018

         node saves the receive ticket in a flow context for the

      4) Peer sends responses. The saved ticket is attached to 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

      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 options. The format of a FAST
   ticket in a Hop-by-Hop 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 | Prop  |  Rsvd |     Type      |
      |                                                               |
      ~                            Ticket                             ~
      |                                                               |

   Tickets are not intended to be parsed outside of the origin network
   domain that issues them. Therefore, the format is arbitrary per the
   discretion of the domain in which they are issued.

   [FAST] suggests a simple and efficient encoding of a Service Profile

       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
                                      | Prop  |  Rsvd |    Type       |
      |                      Expiration time                          |
      |                  Service Profile Index                        |

T. Herbert               Expires April 13, 2019                [Page 11]

INTERNET DRAFT        draft-herbert-route-fast-00       October 10, 2018

   This format can be amended to include routing 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 a 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
                                      | Prop  |  Rsvd |    Type     |Q|
      |                      Expiration time                          |
      |                  Service Profile Index                        |
      |                                                               |
      +                           Locator                             +
      |                                                               |

   Where the 'Q' bit indicates that an unqualified locator was
   overwritten. See Section 5.2.

   A full 128 bit address could similarly be encoded for use with LISP
   or other encapsulation protocols.

4.2 Locator index encoding

   A network may have a comparatively small number of 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 small range. Similarly, the
   backend server in the layer 4 load balancing case might also be
   indicated by an index into a table of backend servers.

T. Herbert               Expires April 13, 2019                [Page 12]

INTERNET DRAFT        draft-herbert-route-fast-00       October 10, 2018

   A locator index encoded in a ticket might look like this:

       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
                                      | Prop  |  Rsvd |    Type     |Q|
      |                      Expiration time                          |
      |                  Service Profile Index                        |
      |                      Locator Index                            |

   Where the 'Q' bit indicates that an unqualified locator was
   overwritten. See section 5.2.

5  Operation

   This section describes the operation of encoding routing information
   in FAST tickets.

5.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 routing information. For example, if
   the application is on a mobile device, the network may provide a
   ticket that has a locator indicating the current location of the

   [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 routing information and the use of
   routing information is expected to be transparent to the application.

5.2 Qualified locators

   There are two possibilities for locator information in an issued

      1) The locator is fully qualified.

      2) The locator is not qualified.

T. Herbert               Expires April 13, 2019                [Page 13]

INTERNET DRAFT        draft-herbert-route-fast-00       October 10, 2018

5.2.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.2.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 4.2, the
   "not set" value may be -1 (all ones). A upstream router of an end
   node may write a locator value into the locator information to make
   it qualified; 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 is 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.3 First hop router processing

   Once an application has been issued a ticket with routing information
   it will set the ticket 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 user nodes.

   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.4 Transit to the peer

   Beyond the first hop router to the ultimate peer destination, no
   processing of routing information in a ticket should be needed.
   Intervening networks and routers should deliver the ticket to the
   destination host unchanged.

   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
   subsequent packets. As with other reflected tickets, one containing
   routing information is treated as an opaque value that is not parsed

T. Herbert               Expires April 13, 2019                [Page 14]

INTERNET DRAFT        draft-herbert-route-fast-00       October 10, 2018

   or modified by the peer or any network outside of the origin network.

   Packets sent by a peer will include reflected tickets for a flow. No
   processing of reflected routing 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.5 Ingress into the origin network

   At the border router for the origin network, tickets are parsed and
   the encoded services are applied. If a ticket contains routing
   information then that can be used to forward the packet over an
   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 to the locator address
   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
   additional 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

5.6 Network overlay termination

   When a packet is received at the terminating point of an overlay it
   is restored to the original packet. 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.

   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.

T. Herbert               Expires April 13, 2019                [Page 15]

INTERNET DRAFT        draft-herbert-route-fast-00       October 10, 2018

5.7 Fallback

   The proposal described here is considered an optimization. Routing
   information in FAST tickets is not intended to completely replace a
   routing 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], Internet support for
   forwarding packets with extension headers is not yet ubiquitous.

   Therefore, a fallback is required when encoding routing information
   in FAST is not viable for a flow. In the mobile case, the fallback
   might be to forward through anchor points. In the layer 4 load
   balancer case, the fallback may be to use the tuple hash.

5.8 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 be issued. This can be done by
   the application receiving a signal that a mobile event has occurred
   causing 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 when an application
   may send packets, so there is the possibility of a window 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 cache synchronization time.

5.9 Interaction with expired tickets

   FAST typically expects ticket to have an expiration time. If a ticket
   is received before the expiration time and it is otherwise valid,

T. Herbert               Expires April 13, 2019                [Page 16]

INTERNET DRAFT        draft-herbert-route-fast-00       October 10, 2018

   then the packet is forwarded per the services indicated by the
   ticket. If a packet is received with an expired ticket, 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 routing information, an
   implementation should ignore the routing information and take the
   fallback path. When an application sends new packets, it can include
   a fresh ticket so that the fast path is taken on subsequent packets.
   Ignoring the routing information in expired tickets puts an upper
   bound on the window that outdated information can be used.

6  Security Considerations

   Routing information can be highly sensitive data especially if it
   could reveal the physical location or identity 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 inferences based on the fact
   that 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.

   Per [FAST], tickets are expected to be encrypted or obfuscated to
   prevent nodes outside the origin network from interpreting them. The
   only information an external node should be able to deduce is that a
   packet contains a ticket. Accordingly, routing information encoded in
   tickets is hidden from external nodes. This allows securely sending
   packets with encoded local routing information over the Internet.

T. Herbert               Expires April 13, 2019                [Page 17]

INTERNET DRAFT        draft-herbert-route-fast-00       October 10, 2018

7  IANA Considerations

   There are no IANA considerations in this document. [FAST] requests
   numbers for 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-

   [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

Author's Address

   Tom Herbert
   Santa Clara, CA

   Email: tom@herbertland.com

T. Herbert               Expires April 13, 2019                [Page 18]

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