| Internet-Draft | LISP Geo-Coordinate Use-Cases | June 2024 |
| Farinacci | Expires 8 December 2024 | [Page] |
This document describes how Geo-Coordinates can be used in the LISP Architecture and Protocols. The functionality proposes a new LCAF encoding for such Geo-Coordinates, which is compatible with the GPS encodings used by other routing protocols.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
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."¶
This Internet-Draft will expire on 8 December 2024.¶
Copyright (c) 2024 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 (https://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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
The LISP architecture and protocols [RFC9300] introduce 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 Identifier (AFI) [RFC1700].¶
This document proposes a new LCAF encoding for Geo-Coordinates, which is compatible with the one used in other routing protocols, namely OSPF [I-D.acee-ospf-geo-location], IS-IS [I-D.shen-isis-geo-coordinates], and BGP [I-D.chen-idr-geo-coordinates] protocols¶
This document updates [RFC8060]. In particular, the use of Geo-Coordinates encoding defined in Section 4.3 of [RFC8060] and identified by LCAF type 5 is deprecated.¶
The Geo-Coordinates LCAF type is used in EID-records and RLOC-records. See [RFC9301] for what LISP messages contain EID-records and RLOC-records.¶
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.¶
Geo-Points can accompany an RLOC-record to determine the physical location of an ETR or 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 can 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.¶
Here is a high-level use-case where an EID can map to a Geo- Coordinate RLOC. Lets 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 system. The EID-to-RLOC mapping is EID=IPv6 and RLOC=Geo-Coordinate. If someone does a mapping database lookup on the IPv6 EID, what is returned is the Geo-Coordinate. As the EID roams, new registrations with different Geo-Coordinates are stored, allowing the physical tracking of the package.¶
The encoding format is consistent with the encoding used in other routing protocols, namely OSPF [I-D.acee-ospf-geo-location], IS-IS [I-D.shen-isis-geo-coordinates], and BGP [I-D.chen-idr-geo-coordinates].¶
A Geo-Prefix is defined to be a Geo-Coordinate point and a Radius. This allows a circle to be drawn on a geographic map. The Geo-Prefix can describe a coarse physical location for an RLOC when encoded in an RLOC-record. So an RLOC could be registered in the mapping database indicating it is in a city or country versus the exact location where a Geo-Point would locate it.¶
A Geo-Prefix could allow a Distinguished-Name [I-D.ietf-lisp-name-encoding] to be registered as an EID with an RLOC that contains a Geo-Prefix. For example EID="San Francisco", with RLOC=geo-prefix could be stored in the mapping system.¶
A Geo-Prefix, when encoded in an EID-record, could be registered as an EID-prefix and when a Geo-Point is used as an EID lookup key, a sort of longest match could be looked up. If the Geo-Point is in the Circle described by the Geo-Prefix, an entry is returned to the Map-Requestor.¶
When a Geo-Point EID is looked up in the mapping system, what is returned is the longest prefix match. In this context, what is returned is the Geo-Prefix with the largest radius value, which corresponds to the largest physical area. If the Geo-Point supplied in a Map-Request has a mask-length/radius which is smaller than what is registered for any matching Geo-Prefix in the mapping system, then all Geo-Prefixes are returned. This uses the same overlapping lookup semantics defined in [RFC9301] for IP address EIDs.¶
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 system:¶
Contents of Mapping Database: 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 system returns: RLOC=<geo-point-of-current-location> Map-Request for geo-point: EID=<geo-point-of-current-location> Mapping system longest-match lookup returns: EID=<geo-prefix-of-60-mile-radius-of-sf> RLOC=<dist-name="san francisco">¶
If the package was not in San Francisco, the second mapping table lookup would fail.¶
Another application is concentric rings of WiFi access-points. The radius of each ring corresponds to the Wifi signal strength. An EID could be located in any of the inner rings but possibly on the edge of a ring. A WiFi access-point RLOC can be selected to encapsulate packets to because it will have better signal to the current EID location. And when there are intersecting circles, it can be determined that when the EID is in the intersection of the circles, it would be a good time to transition radios to closer APs or base stations.¶
When assigning EIDs to vehicles [I-D.jeong-its-v2i-problem-statement], a Geo-Prefix could be used to create a "reachability set" of Road-Side-Units (RSUs). So an 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 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).¶
When a Geo-Prefix or a Geo-Point are encoded in an EID-record, it is encoded solely with the Geo-Location LCAF Type format when VPNs are not in use. When VPNs are used, the Geo-Location LCAF Type is encoded in the AFI field of the Instance-ID LCAF Type.¶
This document has no provision to validate the Geo-Location values.¶
The new Geo-Location format is:¶
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 ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1 - Geo-Location LCAF Encoding Format
¶
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 system lookups to LISP nodes that do not understand them. In such situations, the RLOC-record is ignored.¶
The use of Geo-Coordinates in any application must be considered carefully to not violate any privacy concerns about physical location. This draft does take into consideration the applicability of BCP160 [RFC6280] for location-based privacy protection.¶
In a LISP environment, Geo-Coordinates can be registered to the Mapping Database System. When this occurs, an xTR is allowing its physical location to be known to queriers of the mapping system as well as network components that make up the mapping system. There are various sets of trust relationships that may exist.¶
An xTR at a LISP site already has a business and trust relationship with its Mapping Service Provider (MSP). When xTRs register their mappings with Geo-Coordinate information, a policy is agreed upon about who can access the information. Typically, the policy is stored locally and processed by the xTR when the 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-Reply 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 with [RFC9303]. The Map-Replies not only authenticates the Map-Replier but can be encrypted by the Map-Replier so no eavesdropping of Geo-Coordinate information can occur.¶
In addition to controlling where LISP Geo-Coordinate mapping records go and applying policies [Section 7] for who can access them, there are additional steps that can be taken to protect threats.¶
The suggestions from [RFC6973] can be implemented by existing LISP features, such as:¶
Using signatures from [I-D.ietf-lisp-ecdsa-auth] can authenticate and authorize who can request such mapping records.¶
Obfuscating a geo-point by using geo-prefixes instead uses data minimization techniques.¶
Using short TTLs so the Geo-Coordinate mapping records are ephemeral reduces the attack window.¶
Encrypting mapping records with either shared keys or using PKI [I-D.ietf-lisp-ecdsa-auth] so data is confidential both in transit to/from and at rest in the mapping system. Implementations exist which do encryption for various contract-tracing (virus-related) applications.¶
The typical applicability for the use of Geo-Coordinates will be to describe physical location for well known public structures, places, and landmarks versus people, vehicles, and equipment.¶
Following the guidelines of [RFC8126], IANA is asked to assign a value (17 is suggested) for the Geo-Coordinates LCAF from the "LISP Canonical Address Format (LCAF) Types" registry (defined in [RFC8060] as follows:¶
+=========+=====================+============================+
| Value # | LISP LCAF Type Name | Reference |
+=========+=====================+============================+
| 17 | Geo-Location | [This Document], Section 5 |
+---------+---------------------+----------------------------+
Table 1: Geo-Location LCAF Type Assignment
¶
The author would like to thank the LISP WG for their review and acceptance of this draft.¶
A special thanks goes to Enke Chen, Acee Lindem, and Naiming Shen for collaboarting on a consistent geo-location encoding format with OSPF [I-D.acee-ospf-geo-location], IS-IS [I-D.shen-isis-geo-coordinates], and BGP [I-D.chen-idr-geo-coordinates] protocols.¶
[RFC Editor: Please delete this section on publication as RFC.]¶
Posted October 2016.¶
Clarify that the Geo-Coordinates LCAF type should be encoded inside an Instance-ID LCAF type when VPNs are used.¶
Indicate what the value of the Altitude field is when not included in a message. Since this draft shortens the field, a new value is specified in this draft for not conveying an Altitude value in a message.¶
Initial draft posted April 2016.¶