RFC 9299 An Architectural Introduction to the Locator/ID Separation Protocol (LISP)

IETFThis document describes the architecture of the Locator/ID Separation Protocol (LISP), making it easier to read the rest of the LISP specifications and providing a basis for discussion about the details of the LISP protocols. This document is used for introductory purposes; more details can be found in the protocol specifications, RFCs 9300 and 9301

A novel security protocol for resolving addresses in the location/ID split architecture

The Locator/ID Separation Protocol (LISP) is a routing architecture that provides new semantics for IP addressing. In order to simplify routing operations and improve scalability in future Internet, the LISP uses two different numbering spaces to separate the device identifier from its location. In other words, the LISP separates the 'where' and the 'who' in networking and uses a mapping system to couple the location and identifier. This paper analyses the security and functionality of the LISP mapping procedure using a formal methods approach based on Casper/FDR tool. The analysis points out several security issues in the protocol such as the lack of data confidentiality and mutual authentication. The paper addresses these issues and proposes changes that are compatible with the implementation of the LISP

Securing address registration in location/ID split protocol using ID-based cryptography

The Locator/ID Separation Protocol (LISP) is a routing architecture that provides new semantics for IP addressing. In order to simplify routing operations and improve scalability in future Internet, the LISP separates the device identity from its location using two different numbering spaces. The LISP also, introduces a mapping system to match the two spaces. In the initial stage, each LISP-capable router needs to register with a Map Server, this is known as the Registration stage. However, this stage is vulnerable to masquerading and content poisoning attacks. Therefore, a new security method for protecting the LISP Registration stage is presented in this paper. The proposed method uses the ID-Based Cryptography (IBC) which allows the mapping system to authenticate the source of the data. The proposal has been verified using formal methods approach based on the well-developed Casper/FDR tool

Programmable overlays via OpenOverlayRouter

Among the different options to instantiate overlays, the Locator/ID Separation Protocol (LISP) [7] has gained significant traction among industry and academia [5], [6], [8]–[11], [14], [15]. Interestingly, LISP offers a standard, inter-domain, and dynamic overlay that enables low capital expenditure (CAPEX) innovation at the network layer [8]. LISP follows a map-and-encap approach where overlay identifiers are mapped to underlay locators. Overlay traffic is encapsulated into locator-based packets and routed through the underlay. LISP leverages a public database to store overlay-to-underlay mappings and on a pull mechanism to retrieve those mappings on demand from the data plane. Therefore, LISP effectively decouples the control and data planes, since control plane policies are pushed to the database rather than to the data plane. Forwarding elements reflect control policies on the data plane by pulling them from the database. In that sense, LISP can be used as an SDN southbound protocol to enable programmable overlay networks [5].Peer ReviewedPostprint (published version

RFC 9302 Locator/ID Separation Protocol (LISP) Map-Versioning

IETFThis document describes the Locator/ID Separation Protocol (LISP) Map-Versioning mechanism, which provides in-packet information about Endpoint-ID-to-Routing-Locator (EID-to-RLOC) mappings used to encapsulate LISP data packets. This approach is based on associating a version number to EID-to-RLOC mappings and transporting such a version number in the LISP-specific header of LISP-encapsulated packets. LISP Map-Versioning is particularly useful to inform communicating Ingress Tunnel Routers (ITRs) and Egress Tunnel Routers (ETRs) about modifications of the mappings used to encapsulate packets. The mechanism is optional and transparent to implementations not supporting this feature, since in the LISP-specific header and in the Map Records, bits used for Map-Versioning can be safely ignored by ITRs and ETRs that do not support or do not want to use the mechanism. This document obsoletes RFC 6834, which is the initial experimental specifications of the mechanisms updated by this document