--- 1/draft-ietf-lisp-sec-21.txt 2021-01-12 15:13:10.780929743 -0800 +++ 2/draft-ietf-lisp-sec-22.txt 2021-01-12 15:13:10.840931274 -0800 @@ -1,23 +1,23 @@ Network Working Group F. Maino Internet-Draft Cisco Systems Intended status: Standards Track V. Ermagan -Expires: January 8, 2021 Google +Expires: July 16, 2021 Google A. Cabellos Universitat Politecnica de Catalunya D. Saucez INRIA - July 7, 2020 + January 12, 2021 LISP-Security (LISP-SEC) - draft-ietf-lisp-sec-21 + draft-ietf-lisp-sec-22 Abstract This memo specifies LISP-SEC, a set of security mechanisms that provides origin authentication, integrity and anti-replay protection to LISP's EID-to-RLOC mapping data conveyed via mapping lookup process. LISP-SEC also enables verification of authorization on EID- prefix claims in Map-Reply messages. Requirements Language @@ -36,25 +36,25 @@ 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 January 8, 2021. + This Internet-Draft will expire on July 16, 2021. Copyright Notice - Copyright (c) 2020 IETF Trust and the persons identified as the + Copyright (c) 2021 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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as @@ -684,24 +684,24 @@ Processing of the Map-Request MUST proceed in the order described in the table below, applying the processing corresponding to the first rule that matches the conditions indicated in the first column: +----------------+--------------------------------------------------+ | Matching | Processing | | Condition | | +----------------+--------------------------------------------------+ | 1. At least | The Map-Server MUST generate a LISP-SEC | - | one of the | protected Map-Reply as specified in Section | - | ETRs | 5.7.2. The ETR-Cant-Sign E-bit in the EID | - | authoritative | Authentication Data (EID-AD) MUST be set to 0. | - | for the EID | | + | one of the | protected Map-Reply as specified in | + | ETRs | Section 5.7.2. The ETR-Cant-Sign E-bit in the | + | authoritative | EID Authentication Data (EID-AD) MUST be set to | + | for the EID | 0. | | prefix | | | included in | | | the Map- | | | Request | | | registered | | | with the P-bit | | | set to 1 | | | | | | 2. At least | The Map-Server MUST generate a LISP-SEC | | one of the | protected Encapsulated Map-Request (as specified | @@ -710,25 +710,25 @@ | for the EID | S-bit set to 1 (and the P-bit set to 0). If | | prefix | there is at least one ETR that registered with | | included in | the S-bit set to 0, the ETR-Cant-Sign E-bit of | | the Map- | the EID-AD MUST be set to 1 to signal the ITR | | Request | that a non LISP-SEC Map-Request might reach | | registered | additional ETRs that have LISP-SEC disabled. | | with the S-bit | | | set to 1 | | | | | | 3. All the | The Map-Server MUST send a Negative Map-Reply | - | ETRs | protected with LISP-SEC, as described in Section | - | authoritative | 5.7.2. The ETR-Cant-Sign E-bit MUST be set to 1 | - | for the EID | to signal the ITR that a non LISP-SEC Map- | - | prefix | Request might reach additional ETRs that have | - | included in | LISP-SEC disabled. | + | ETRs | protected with LISP-SEC, as described in | + | authoritative | Section 5.7.2. The ETR-Cant-Sign E-bit MUST be | + | for the EID | set to 1 to signal the ITR that a non LISP-SEC | + | prefix | Map-Request might reach additional ETRs that | + | included in | have LISP-SEC disabled. | | the Map- | | | Request | | | registered | | | with the S-bit | | | set to 0 | | +----------------+--------------------------------------------------+ In this way the ITR that sent a LISP-SEC protected Map-Request always receives a LISP-SEC protected Map-Reply. However, the ETR-Cant-Sign E-bit set to 1 specifies that a non LISP-SEC Map-Request might reach @@ -1130,22 +1130,22 @@ Noll for their valuable suggestions provided during the preparation of this document. 9. References 9.1. Normative References [I-D.ietf-lisp-rfc6833bis] Farinacci, D., Maino, F., Fuller, V., and A. Cabellos- Aparicio, "Locator/ID Separation Protocol (LISP) Control- - Plane", draft-ietf-lisp-rfc6833bis-27 (work in progress), - January 2020. + Plane", draft-ietf-lisp-rfc6833bis-30 (work in progress), + November 2020. [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- Hashing for Message Authentication", RFC 2104, DOI 10.17487/RFC2104, February 1997, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . @@ -1194,22 +1194,22 @@ [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 9.2. Informative References [I-D.ietf-lisp-rfc6830bis] Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A. Cabellos-Aparicio, "The Locator/ID Separation Protocol - (LISP)", draft-ietf-lisp-rfc6830bis-32 (work in progress), - March 2020. + (LISP)", draft-ietf-lisp-rfc6830bis-36 (work in progress), + November 2020. Authors' Addresses Fabio Maino Cisco Systems 170 Tasman Drive San Jose, California 95134 USA Email: fmaino@cisco.com