RFC 10040: Locator/ID Separation Protocol (LISP) Geo-Coordinates

Abstract

This document describes how Geo-Coordinates can be used in the Locator/ID Separation Protocol (LISP) and defines a new LISP Canonical Address Format (LCAF) encoding for such Geo-Coordinates.¶

This document updates RFC 8060.¶

1. Introduction

The Locator/ID Separation Protocol (LISP) [RFC9300] introduces two new namespaces, Endpoint Identifiers (EIDs) and Routing Locators (RLOCs), which are intended to separate the semantics of identity and topological location from an IP address. To provide flexibility for current and future applications, these values can be encoded in LISP control messages using a general syntax that includes Address Family Identifiers (AFIs) [AFN].¶

This document defines a new LCAF encoding for Geo-Coordinates, which deviates from the structure defined in [RFC9179], because a more compact encoding was desired.¶

This document updates [RFC8060]. In particular, the use of the Geo-Coordinates encoding defined in Section 4.3 of [RFC8060] and identified by LCAF type 5 is deprecated. The LCAF type defined in this document is called "Geo-Location", and a new LCAF type has been allocated.¶

The Geo-Location LCAF type is used in EID-Records and RLOC-Records. See [RFC9301] for which LISP messages contain EID-Records and RLOC-Records.¶

This document is part of a development effort to include Geo-Coordinates in LISP. It is not part of an "experiment", as not all Experimental RFCs are necessarily part of an experiment. It is about the maturity level of the technology.¶

2. Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

3. Definition of Terms

Refer to [RFC9300] for authoritative definitions for the basic terms "EID", "RLOC", and "xTR". The terms defined in this section add to the canonical definitions to reflect the design considerations in this specification.¶

4. Geo-Points in RLOC-Records

Geo-Points MAY be present in an RLOC-Record to determine the physical location of an Egress Tunnel Router (ETR) or Re-encapsulating Tunneling Router (RTR). This can aid in determining geographical distance when topological distance is inaccurate or hidden. When Geo-Points are encoded in RLOC-Records with RLOC addresses, the LCAF AFI-List Type SHOULD be used.¶

Geo-Points MAY be used as the sole piece of information in an RLOC-Record when an EID maps to a Geo-Coordinate. If it is desirable to find the geographical location of any EID, this method can be convenient. For instance, let's say that an EID is assigned to a physical shipping package by a package delivery company and the EID is encoded as an IPv6 address where the tracking number is embedded in an IPv6 EID. The network has LISP nodes deployed in many locations that are configured with their respective Geo-Coordinates. As the package roams, the LISP node that discovers the EID registers it to the LISP Mapping Database System. The EID-to-RLOC mapping is EID=IPv6 and RLOC=geo-point. If someone does a Mapping Database System lookup on the IPv6 EID, the Geo-Coordinate is returned. As the EID roams, new registrations with different Geo-Coordinates are stored, allowing the physical tracking of the package.¶

6. Geo-Points and Geo-Prefixes Examples

6.1. Locating a Package

You could take a combination of mappings from the above examples to ask the question: "Is the package in San Francisco?" This could be done with two lookups to the Mapping Database System:¶

Contents of Mapping Database System:
 EID=<dist-name="san francisco">
 RLOC=<geo-prefix-of-60-mile-radius-of-sf>

 EID=<ipv6-package-tracking-number>
 RLOC=<geo-point-of-current-location>

 EID=<geo-prefix-of-60-mile-radius-of-sf>
 RLOC=<dist-name="san francisco">

Map-Request for package:
 EID=<ipv6-package-tracking-number>
Mapping Database System returns:
 RLOC=<geo-point-of-current-location>

Map-Request for Geo-Point:
 EID=<geo-point-of-current-location>
Mapping Database System longest-match lookup returns:
 EID=<geo-prefix-of-60-mile-radius-of-sf>
 RLOC=<dist-name="san francisco">

If the package is not in San Francisco, the second mapping table lookup would fail.¶

6.2. Wireless Connectivity

Another application is concentric rings of Wi-Fi access points (APs). The radius of each ring corresponds to the Wi-Fi signal strength. An EID could be located in any of the inner rings and possibly on the edge of a ring. A Wi-Fi AP RLOC can be selected to encapsulate packets because it will have a better signal to the current EID location. In addition, when there are intersecting spheres, a good time to transition radios to closer Wi-Fi APs or 3GPP Radio Access Network (RAN) base stations is when the EID is in the intersection of the spheres.¶

6.3. Vehicular Networks

When assigning EIDs to vehicles [V2I-PROB], a Geo-Prefix could be used to create a "reachability set" of Roadside Units (RSUs). So an Ingress Tunnel Router (ITR) could encapsulate to multiple RLOCs in the Geo-Prefix to try to create connectivity to the vehicle while roaming. This makes use of predictive RLOCs [PRED-RLOCS] that can be used when the direction of the roaming EID is known (a train track or single direction road, but not a flight path of a plane).¶

 0 1 2 3
 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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | AFI = 16387 | Rsvd1 | Flags |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Type = 17 | Rsvd2 | Length |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |U|N|E|A|M|R|K| Reserved | Location Uncertainty |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Lat Degrees | Latitude Milliseconds |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Long Degrees | Longitude Milliseconds |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Altitude |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Radius | Reserved |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | AFI | Address ... |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

8. Backward-Compatibility Considerations

EID-Records encoded with the Geo-Location LCAF are supported only by LISP nodes that support them for registration and lookup purposes.¶

RLOC-Records encoded with the Geo-Location LCAF can be returned from the Mapping Database System lookups to LISP nodes that do not understand them. In such situations, the RLOC-Record is ignored.¶

9. Security Considerations

The use of Geo-Coordinates in any application must be considered carefully to not violate any privacy concerns about physical location. This document does take into consideration the applicability of BCP 160 [RFC6280] for location-based privacy protection.¶

In a LISP environment, Geo-Coordinates can be registered to the Mapping Database System. When this occurs, any Tunnel Router (xTR) is allowing its physical location to be known to queriers of the Mapping Database System as well as network components that make up the Mapping Database System. There are various sets of trust relationships that may exist.¶

When xTRs register their mappings with Geo-Coordinate information, a policy is associated about who can access the information. Typically, the policy is stored locally on the xTR and applied when the Mapping Service Provider (MSP) forwards Map-Requests to the xTRs of the LISP site. Conditionally, based on the requesting xTR, the responding xTR can apply the local policy to decide if a Map-Reply is sent with all RLOC-Records or, perhaps, the RLOC-Records that do not contain Geo-Coordinate information.¶

The MSP can also be requested by LISP site xTRs to proxy Map-Replies to Map-Requests. In this case, the MSP MUST apply the xTR policy so only authorized requesters get access to Geo-Coordinate information.¶

Note that once a requester is authorized, Map-Replies are returned directly to the requester and are signed as described in [RFC9303]. The Map-Replies not only authenticate the Map-Replier but can be encrypted by the Map-Replier so no eavesdropping of Geo-Coordinate information can occur.¶

In most deployment cases, there is no tracking of EID host-based systems since Geo-Coordinate assignment is typically registered for LISP xTR devices or other asset inventory. However, since Geo-Coordinate-encoded RLOCs can be associated with any EID, tracking of hosts can occur if such an EID is assigned to hosts.¶

10. Privacy Considerations

In addition to controlling where LISP Geo-Coordinate mapping records go and applying policies (see "Security Considerations" section) for who can access them, there are additional steps that can be taken to protect against threats.¶

The privacy guidelines in [RFC6973] can be implemented with existing LISP features, for example:¶

• Using signatures from [ECDSA-AUTH] can authenticate and authorize who can request such mapping records.¶

• Obfuscating a Geo-Point by using Geo-Prefixes uses data minimization techniques.¶

• Using short TTLs so the Geo-Coordinate mapping records are ephemeral reduces the attack window.¶

The typical applicability for the use of Geo-Coordinates is to describe the physical location of well-known public structures, places, and landmarks rather than people, vehicles, and equipment.¶

11. IANA Considerations

Following the guidelines of [RFC8126], IANA has assigned the following value in the "LISP Canonical Address Format (LCAF) Types" registry [RFC8060]:¶

In addition, IANA has marked LCAF type 5 (Geo-Coordinates) as deprecated in the "LISP Canonical Address Format (LCAF) Types" registry. This type was defined in [RFC8060], which this document updates.¶

12. References

12.1. Normative References

12.2. Informative References

Acknowledgments

The author would like to thank the LISP WG for their review and acceptance of this document and Kiran Makhijani for shepherding the document.¶

Special thanks goes to Chris Hopps, Enke Chen, Acee Lindem, and Naiming Shen for collaborating on a Geo-Location encoding format that is consistent with OSPF [OSPF-GEO], IS-IS [ISIS-GEO], and BGP [BGP-GEO].¶