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