< draft-ietf-lisp-rfc6833bis-24.txt   draft-ietf-lisp-rfc6833bis-25.txt >
Network Working Group V. Fuller Network Working Group D. Farinacci
Internet-Draft D. Farinacci Internet-Draft lispers.net
Obsoletes: 6830, 6833 (if approved) Cisco Systems Obsoletes: 6830, 6833 (if approved) F. Maino
Intended status: Standards Track A. Cabellos (Ed.) Intended status: Standards Track Cisco Systems
Expires: August 8, 2019 UPC/BarcelonaTech Expires: December 18, 2019 V. Fuller
February 4, 2019 vaf.net Internet Consulting
A. Cabellos (Ed.)
UPC/BarcelonaTech
June 16, 2019
Locator/ID Separation Protocol (LISP) Control-Plane Locator/ID Separation Protocol (LISP) Control-Plane
draft-ietf-lisp-rfc6833bis-24 draft-ietf-lisp-rfc6833bis-25
Abstract Abstract
This document describes the Control-Plane and Mapping Service for the This document describes the Control-Plane and Mapping Service for the
Locator/ID Separation Protocol (LISP), implemented by two new types Locator/ID Separation Protocol (LISP), implemented by two new types
of LISP-speaking devices -- the LISP Map-Resolver and LISP Map-Server of LISP-speaking devices -- the LISP Map-Resolver and LISP Map-Server
-- that provides a simplified "front end" for one or more Endpoint ID -- that provides a simplified "front end" for one or more Endpoint ID
to Routing Locator mapping databases. to Routing Locator mapping databases.
By using this Control-Plane service interface and communicating with By using this Control-Plane service interface and communicating with
skipping to change at page 1, line 46 skipping to change at page 2, line 4
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 18, 2019.
This Internet-Draft will expire on August 8, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 26 skipping to change at page 2, line 27
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Scope of Applicability . . . . . . . . . . . . . . . . . 4 1.1. Scope of Applicability . . . . . . . . . . . . . . . . . 4
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 5 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 5
3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 5 3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 5
4. Basic Overview . . . . . . . . . . . . . . . . . . . . . . . 7 4. Basic Overview . . . . . . . . . . . . . . . . . . . . . . . 6
5. LISP IPv4 and IPv6 Control-Plane Packet Formats . . . . . . . 8 5. LISP IPv4 and IPv6 Control-Plane Packet Formats . . . . . . . 8
5.1. LISP Control Packet Type Allocations . . . . . . . . . . 11 5.1. LISP Control Packet Type Allocations . . . . . . . . . . 11
5.2. Map-Request Message Format . . . . . . . . . . . . . . . 12 5.2. Map-Request Message Format . . . . . . . . . . . . . . . 12
5.3. EID-to-RLOC UDP Map-Request Message . . . . . . . . . . . 15 5.3. EID-to-RLOC UDP Map-Request Message . . . . . . . . . . . 14
5.4. Map-Reply Message Format . . . . . . . . . . . . . . . . 17 5.4. Map-Reply Message Format . . . . . . . . . . . . . . . . 17
5.5. EID-to-RLOC UDP Map-Reply Message . . . . . . . . . . . . 21 5.5. EID-to-RLOC UDP Map-Reply Message . . . . . . . . . . . . 21
5.6. Map-Register Message Format . . . . . . . . . . . . . . . 24 5.6. Map-Register Message Format . . . . . . . . . . . . . . . 24
5.7. Map-Notify/Map-Notify-Ack Message Format . . . . . . . . 28 5.7. Map-Notify/Map-Notify-Ack Message Format . . . . . . . . 28
5.8. Encapsulated Control Message Format . . . . . . . . . . . 30 5.8. Encapsulated Control Message Format . . . . . . . . . . . 30
6. Changing the Contents of EID-to-RLOC Mappings . . . . . . . . 32 6. Changing the Contents of EID-to-RLOC Mappings . . . . . . . . 32
6.1. Solicit-Map-Request (SMR) . . . . . . . . . . . . . . . . 32 6.1. Solicit-Map-Request (SMR) . . . . . . . . . . . . . . . . 32
7. Routing Locator Reachability . . . . . . . . . . . . . . . . 33 7. Routing Locator Reachability . . . . . . . . . . . . . . . . 33
7.1. RLOC-Probing Algorithm . . . . . . . . . . . . . . . . . 35 7.1. RLOC-Probing Algorithm . . . . . . . . . . . . . . . . . 35
8. Interactions with Other LISP Components . . . . . . . . . . . 36 8. Interactions with Other LISP Components . . . . . . . . . . . 36
8.1. ITR EID-to-RLOC Mapping Resolution . . . . . . . . . . . 36 8.1. ITR EID-to-RLOC Mapping Resolution . . . . . . . . . . . 36
8.2. EID-Prefix Configuration and ETR Registration . . . . . . 37 8.2. EID-Prefix Configuration and ETR Registration . . . . . . 37
8.3. Map-Server Processing . . . . . . . . . . . . . . . . . . 39 8.3. Map-Server Processing . . . . . . . . . . . . . . . . . . 39
8.4. Map-Resolver Processing . . . . . . . . . . . . . . . . . 40 8.4. Map-Resolver Processing . . . . . . . . . . . . . . . . . 40
8.4.1. Anycast Operation . . . . . . . . . . . . . . . . . . 40 8.4.1. Anycast Operation . . . . . . . . . . . . . . . . . . 40
9. Security Considerations . . . . . . . . . . . . . . . . . . . 41 9. Security Considerations . . . . . . . . . . . . . . . . . . . 40
10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 42 10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 42
11. Changes since RFC 6833 . . . . . . . . . . . . . . . . . . . 43 11. Changes since RFC 6833 . . . . . . . . . . . . . . . . . . . 43
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43
12.1. LISP UDP Port Numbers . . . . . . . . . . . . . . . . . 44 12.1. LISP UDP Port Numbers . . . . . . . . . . . . . . . . . 44
12.2. LISP Packet Type Codes . . . . . . . . . . . . . . . . . 44 12.2. LISP Packet Type Codes . . . . . . . . . . . . . . . . . 44
12.3. LISP ACT and Flag Fields . . . . . . . . . . . . . . . . 44 12.3. LISP ACT and Flag Fields . . . . . . . . . . . . . . . . 44
12.4. LISP Address Type Codes . . . . . . . . . . . . . . . . 45 12.4. LISP Address Type Codes . . . . . . . . . . . . . . . . 45
12.5. LISP Algorithm ID Numbers . . . . . . . . . . . . . . . 46 12.5. LISP Algorithm ID Numbers . . . . . . . . . . . . . . . 45
12.6. LISP Bit Flags . . . . . . . . . . . . . . . . . . . . . 46 12.6. LISP Bit Flags . . . . . . . . . . . . . . . . . . . . . 46
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 49 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 49
13.1. Normative References . . . . . . . . . . . . . . . . . . 49 13.1. Normative References . . . . . . . . . . . . . . . . . . 49
13.2. Informative References . . . . . . . . . . . . . . . . . 50 13.2. Informative References . . . . . . . . . . . . . . . . . 50
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 55 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 55
Appendix B. Document Change Log . . . . . . . . . . . . . . . . 55 Appendix B. Document Change Log . . . . . . . . . . . . . . . . 55
B.1. Changes to draft-ietf-lisp-rfc6833bis-24 . . . . . . . . 55 B.1. Changes to draft-ietf-lisp-rfc6833bis-25 . . . . . . . . 55
B.2. Changes to draft-ietf-lisp-rfc6833bis-23 . . . . . . . . 55 B.2. Changes to draft-ietf-lisp-rfc6833bis-24 . . . . . . . . 55
B.3. Changes to draft-ietf-lisp-rfc6833bis-22 . . . . . . . . 56 B.3. Changes to draft-ietf-lisp-rfc6833bis-23 . . . . . . . . 56
B.4. Changes to draft-ietf-lisp-rfc6833bis-21 . . . . . . . . 56 B.4. Changes to draft-ietf-lisp-rfc6833bis-22 . . . . . . . . 56
B.5. Changes to draft-ietf-lisp-rfc6833bis-20 . . . . . . . . 56 B.5. Changes to draft-ietf-lisp-rfc6833bis-21 . . . . . . . . 56
B.6. Changes to draft-ietf-lisp-rfc6833bis-19 . . . . . . . . 56 B.6. Changes to draft-ietf-lisp-rfc6833bis-20 . . . . . . . . 56
B.7. Changes to draft-ietf-lisp-rfc6833bis-18 . . . . . . . . 56 B.7. Changes to draft-ietf-lisp-rfc6833bis-19 . . . . . . . . 56
B.8. Changes to draft-ietf-lisp-rfc6833bis-17 . . . . . . . . 56 B.8. Changes to draft-ietf-lisp-rfc6833bis-18 . . . . . . . . 57
B.9. Changes to draft-ietf-lisp-rfc6833bis-16 . . . . . . . . 57 B.9. Changes to draft-ietf-lisp-rfc6833bis-17 . . . . . . . . 57
B.10. Changes to draft-ietf-lisp-rfc6833bis-15 . . . . . . . . 57 B.10. Changes to draft-ietf-lisp-rfc6833bis-16 . . . . . . . . 57
B.11. Changes to draft-ietf-lisp-rfc6833bis-14 . . . . . . . . 57 B.11. Changes to draft-ietf-lisp-rfc6833bis-15 . . . . . . . . 57
B.12. Changes to draft-ietf-lisp-rfc6833bis-13 . . . . . . . . 57 B.12. Changes to draft-ietf-lisp-rfc6833bis-14 . . . . . . . . 57
B.13. Changes to draft-ietf-lisp-rfc6833bis-12 . . . . . . . . 57 B.13. Changes to draft-ietf-lisp-rfc6833bis-13 . . . . . . . . 58
B.14. Changes to draft-ietf-lisp-rfc6833bis-11 . . . . . . . . 58 B.14. Changes to draft-ietf-lisp-rfc6833bis-12 . . . . . . . . 58
B.15. Changes to draft-ietf-lisp-rfc6833bis-10 . . . . . . . . 58 B.15. Changes to draft-ietf-lisp-rfc6833bis-11 . . . . . . . . 58
B.16. Changes to draft-ietf-lisp-rfc6833bis-09 . . . . . . . . 58 B.16. Changes to draft-ietf-lisp-rfc6833bis-10 . . . . . . . . 58
B.17. Changes to draft-ietf-lisp-rfc6833bis-08 . . . . . . . . 58 B.17. Changes to draft-ietf-lisp-rfc6833bis-09 . . . . . . . . 58
B.18. Changes to draft-ietf-lisp-rfc6833bis-07 . . . . . . . . 58 B.18. Changes to draft-ietf-lisp-rfc6833bis-08 . . . . . . . . 58
B.19. Changes to draft-ietf-lisp-rfc6833bis-06 . . . . . . . . 59 B.19. Changes to draft-ietf-lisp-rfc6833bis-07 . . . . . . . . 59
B.20. Changes to draft-ietf-lisp-rfc6833bis-05 . . . . . . . . 59 B.20. Changes to draft-ietf-lisp-rfc6833bis-06 . . . . . . . . 59
B.21. Changes to draft-ietf-lisp-rfc6833bis-04 . . . . . . . . 59 B.21. Changes to draft-ietf-lisp-rfc6833bis-05 . . . . . . . . 60
B.22. Changes to draft-ietf-lisp-rfc6833bis-03 . . . . . . . . 60 B.22. Changes to draft-ietf-lisp-rfc6833bis-04 . . . . . . . . 60
B.23. Changes to draft-ietf-lisp-rfc6833bis-02 . . . . . . . . 60 B.23. Changes to draft-ietf-lisp-rfc6833bis-03 . . . . . . . . 60
B.24. Changes to draft-ietf-lisp-rfc6833bis-01 . . . . . . . . 60 B.24. Changes to draft-ietf-lisp-rfc6833bis-02 . . . . . . . . 60
B.25. Changes to draft-ietf-lisp-rfc6833bis-00 . . . . . . . . 60 B.25. Changes to draft-ietf-lisp-rfc6833bis-01 . . . . . . . . 60
B.26. Changes to draft-farinacci-lisp-rfc6833bis-00 . . . . . . 61 B.26. Changes to draft-ietf-lisp-rfc6833bis-00 . . . . . . . . 61
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 61 B.27. Changes to draft-farinacci-lisp-rfc6833bis-00 . . . . . . 61
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 62
1. Introduction 1. Introduction
The Locator/ID Separation Protocol [I-D.ietf-lisp-rfc6830bis] (see The Locator/ID Separation Protocol [I-D.ietf-lisp-rfc6830bis] (see
also [I-D.ietf-lisp-introduction]) specifies an architecture and also [I-D.ietf-lisp-introduction]) specifies an architecture and
mechanism for dynamic tunneling by logically separating the addresses mechanism for dynamic tunneling by logically separating the addresses
currently used by IP in two separate name spaces: Endpoint IDs currently used by IP in two separate name spaces: Endpoint IDs
(EIDs), used within sites; and Routing Locators (RLOCs), used on the (EIDs), used within sites; and Routing Locators (RLOCs), used on the
transit networks that make up the Internet infrastructure. To transit networks that make up the Internet infrastructure. To
achieve this separation, LISP defines protocol mechanisms for mapping achieve this separation, LISP defines protocol mechanisms for mapping
skipping to change at page 5, line 12 skipping to change at page 5, line 15
As such, the design and development of LISP has changed so as to As such, the design and development of LISP has changed so as to
focus on these use cases. The common property of these uses is a focus on these use cases. The common property of these uses is a
large set of cooperating entities seeking to communicate over the large set of cooperating entities seeking to communicate over the
public Internet or other large underlay IP infrastructures, while public Internet or other large underlay IP infrastructures, while
keeping the addressing and topology of the cooperating entities keeping the addressing and topology of the cooperating entities
separate from the underlay and Internet topology, routing, and separate from the underlay and Internet topology, routing, and
addressing. addressing.
2. Requirements Notation 2. Requirements Notation
In many IETF documents, several words, when they are in all capitals
as shown below, are used to signify the requirements in the
specification. These capitalized words can bring significant clarity
and consistency to documents because their meanings are well defined.
This document defines how those words are interpreted in IETF
documents when the words are in all capitals.
o These words can be used as defined here, but using them is not
required. Specifically, normative text does not require the use
of these key words. They are used for clarity and consistency
when that is what's wanted, but a lot of normative text does not
use them and is still normative.
o The words have the meanings specified herein only when they are in
all capitals.
o When these words are not capitalized, they have their normal
English meanings and are not affected by this document.
Authors who follow these guidelines should incorporate this phrase
near the beginning of their document:
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
3. Definition of Terms 3. Definition of Terms
Map-Server: A network infrastructure component that learns of EID- Map-Server: A network infrastructure component that learns of EID-
Prefix mapping entries from an ETR, via the registration mechanism Prefix mapping entries from an ETR, via the registration mechanism
skipping to change at page 9, line 51 skipping to change at page 9, line 51
sender and the destination UDP port number is set to 4342. When a sender and the destination UDP port number is set to 4342. When a
UDP Map-Reply, Map-Notify (when used as an acknowledgement to a Map- UDP Map-Reply, Map-Notify (when used as an acknowledgement to a Map-
Register), or Map-Notify-Ack are sent, the source UDP port number is Register), or Map-Notify-Ack are sent, the source UDP port number is
set to 4342 and the destination UDP port number is copied from the set to 4342 and the destination UDP port number is copied from the
source port of either the Map-Request or the invoking data packet. source port of either the Map-Request or the invoking data packet.
Implementations MUST be prepared to accept packets when either the Implementations MUST be prepared to accept packets when either the
source port or destination UDP port is set to 4342 due to NATs source port or destination UDP port is set to 4342 due to NATs
changing port number values. changing port number values.
The 'UDP Length' field will reflect the length of the UDP header and The 'UDP Length' field will reflect the length of the UDP header and
the LISP Message payload. Implementations should follow the the LISP Message payload. LISP is expected to be deployed by
procedures from [RFC8085] to determine the maximum size used for any cooperating entities communicating over underlays. Deployers are
LISP control message. expected to set the MTU according to the specific deployment
guidelines to prevent fragmentation of either the inner packet or the
outer encapsulated packet. For deployments not aware of the underlay
restrictions on path MTU, the message size MUST be limited to 576
bytes for IPv4 or 1280 bytes for IPv6 as outlined in [RFC8085].
The UDP checksum is computed and set to non-zero for all messages The UDP checksum is computed and set to non-zero for all messages
sent to or from port 4342. It MUST be checked on receipt, and if the sent to or from port 4342. It MUST be checked on receipt, and if the
checksum fails, the control message MUST be dropped [RFC1071]. checksum fails, the control message MUST be dropped [RFC1071].
The format of control messages includes the UDP header so the The format of control messages includes the UDP header so the
checksum and length fields can be used to protect and delimit message checksum and length fields can be used to protect and delimit message
boundaries. boundaries.
5.1. LISP Control Packet Type Allocations 5.1. LISP Control Packet Type Allocations
skipping to change at page 13, line 47 skipping to change at page 13, line 47
value of 0, there is 1 ITR-RLOC address encoded; for a value of 1, value of 0, there is 1 ITR-RLOC address encoded; for a value of 1,
there are 2 ITR-RLOC addresses encoded, and so on up to 31, which there are 2 ITR-RLOC addresses encoded, and so on up to 31, which
encodes a total of 32 ITR-RLOC addresses. encodes a total of 32 ITR-RLOC addresses.
Record Count: This is the number of records in this Map-Request Record Count: This is the number of records in this Map-Request
message. A record is comprised of the portion of the packet that message. A record is comprised of the portion of the packet that
is labeled 'Rec' above and occurs the number of times equal to is labeled 'Rec' above and occurs the number of times equal to
Record Count. For this version of the protocol, a receiver MUST Record Count. For this version of the protocol, a receiver MUST
accept and process Map-Requests that contain one or more records, accept and process Map-Requests that contain one or more records,
but a sender MUST only send Map-Requests containing one record. but a sender MUST only send Map-Requests containing one record.
Support for processing multiple EIDs in a single Map-Request
message will be specified in a future version of the protocol.
Nonce: This is an 8-octet random value created by the sender of the Nonce: This is an 8-octet random value created by the sender of the
Map-Request. This nonce will be returned in the Map-Reply. The Map-Request. This nonce will be returned in the Map-Reply. The
security of the LISP mapping protocol critically depends on the nonce is used as an index to identify the corresponding Map-
strength of the nonce in the Map-Request message. The nonce MUST Request when a Map-Reply message is received. The nonce MUST be
be generated by a properly seeded pseudo-random (or strong random) generated by a properly seeded pseudo-random (or strong random)
source. See [RFC4086] for advice on generating security-sensitive source. See [RFC4086] for advice on generating security-sensitive
random data. random data.
Source-EID-AFI: This is the address family of the 'Source EID Source-EID-AFI: This is the address family of the 'Source EID
Address' field. Address' field.
Source EID Address: This is the EID of the source host that Source EID Address: This is the EID of the source host that
originated the packet that caused the Map-Request. When Map- originated the packet that caused the Map-Request. When Map-
Requests are used for refreshing a Map-Cache entry or for RLOC- Requests are used for refreshing a Map-Cache entry or for RLOC-
Probing, an AFI value 0 is used and this field is of zero length. Probing, an AFI value 0 is used and this field is of zero length.
skipping to change at page 15, line 39 skipping to change at page 15, line 33
provides no ITR-RLOC addresses, the Map-Replier MUST drop the Map- provides no ITR-RLOC addresses, the Map-Replier MUST drop the Map-
Request. Request.
Map-Requests can also be LISP encapsulated using UDP destination Map-Requests can also be LISP encapsulated using UDP destination
port 4342 with a LISP Type value set to "Encapsulated Control port 4342 with a LISP Type value set to "Encapsulated Control
Message", when sent from an ITR to a Map-Resolver. Likewise, Map- Message", when sent from an ITR to a Map-Resolver. Likewise, Map-
Requests are LISP encapsulated the same way from a Map-Server to an Requests are LISP encapsulated the same way from a Map-Server to an
ETR. Details on Encapsulated Map-Requests and Map-Resolvers can be ETR. Details on Encapsulated Map-Requests and Map-Resolvers can be
found in Section 5.8. found in Section 5.8.
Map-Requests MUST be rate-limited. It is RECOMMENDED that a Map- Map-Requests MUST be rate-limited to 1 per second per EID-prefix.
Request for the same EID-Prefix be sent no more than once per second. After 10 retransmits without receiving the corresponding Map-Reply
However, recommendations from [RFC8085] SHOULD be considered. must wait 30 seconds.
An ITR that is configured with mapping database information (i.e., it An ITR that is configured with mapping database information (i.e., it
is also an ETR) MAY optionally include those mappings in a Map- is also an ETR) MAY optionally include those mappings in a Map-
Request. When an ETR configured to accept and verify such Request. When an ETR configured to accept and verify such
"piggybacked" mapping data receives such a Map-Request and it does "piggybacked" mapping data receives such a Map-Request and it does
not have this mapping in the Map-Cache, it MAY originate a "verifying not have this mapping in the Map-Cache, it MAY originate a "verifying
Map-Request", addressed to the map-requesting ITR and the ETR MAY add Map-Request", addressed to the map-requesting ITR and the ETR MAY add
a Map-Cache entry. If the ETR (when it is an xTR co-located as an a Map-Cache entry. If the ETR (when it is an xTR co-located as an
ITR) has a Map-Cache entry that matches the "piggybacked" EID and the ITR) has a Map-Cache entry that matches the "piggybacked" EID and the
RLOC is in the Locator-Set for the entry, then it MAY send the RLOC is in the Locator-Set for the entry, then it MAY send the
skipping to change at page 21, line 15 skipping to change at page 21, line 15
Note that the destination RLOC address of a LISP encapsulated Note that the destination RLOC address of a LISP encapsulated
packet MAY be an anycast address. A source RLOC of a LISP packet MAY be an anycast address. A source RLOC of a LISP
encapsulated packet can be an anycast address as well. The source encapsulated packet can be an anycast address as well. The source
or destination RLOC MUST NOT be the broadcast address or destination RLOC MUST NOT be the broadcast address
(255.255.255.255 or any subnet broadcast address known to the (255.255.255.255 or any subnet broadcast address known to the
router) and MUST NOT be a link-local multicast address. The router) and MUST NOT be a link-local multicast address. The
source RLOC MUST NOT be a multicast address. The destination RLOC source RLOC MUST NOT be a multicast address. The destination RLOC
SHOULD be a multicast address if it is being mapped from a SHOULD be a multicast address if it is being mapped from a
multicast destination EID. multicast destination EID.
Map-Reply MUST be rate-limited, it is RECOMMENDED that a Map-Reply
for the same destination RLOC be sent no more than one packets per 3
seconds.
The Record format, as defined here, is used both in the Map-Reply and
Map-Register messages, this includes all the field definitions.
5.5. EID-to-RLOC UDP Map-Reply Message 5.5. EID-to-RLOC UDP Map-Reply Message
A Map-Reply returns an EID-Prefix with a mask-length that is less A Map-Reply returns an EID-Prefix with a mask-length that is less
than or equal to the EID being requested. The EID being requested is than or equal to the EID being requested. The EID being requested is
either from the destination field of an IP header of a Data-Probe or either from the destination field of an IP header of a Data-Probe or
the EID record of a Map-Request. The RLOCs in the Map-Reply are the EID record of a Map-Request. The RLOCs in the Map-Reply are
routable IP addresses of all ETRs for the LISP site. Each RLOC routable IP addresses of all ETRs for the LISP site. Each RLOC
conveys status reachability but does not convey path reachability conveys status reachability but does not convey path reachability
from a requester's perspective. Separate testing of path from a requester's perspective. Separate testing of path
reachability is required. See RLOC-reachability Section 7.1 for reachability is required. See RLOC-reachability Section 7.1 for
skipping to change at page 22, line 30 skipping to change at page 22, line 37
value so they can all time out at the same time. When a more- value so they can all time out at the same time. When a more-
specific EID-Prefix is received later, its Time to Live value in the specific EID-Prefix is received later, its Time to Live value in the
Map-Reply record can be stored even when other less-specific entries Map-Reply record can be stored even when other less-specific entries
exist. When a less-specific EID-Prefix is received later, its Map- exist. When a less-specific EID-Prefix is received later, its Map-
Cache expiration time SHOULD be set to the minimum expiration time of Cache expiration time SHOULD be set to the minimum expiration time of
any more-specific EID-Prefix in the Map-Cache. This is done so the any more-specific EID-Prefix in the Map-Cache. This is done so the
integrity of the EID-Prefix set is wholly maintained and so no more- integrity of the EID-Prefix set is wholly maintained and so no more-
specific entries are removed from the Map-Cache while keeping less- specific entries are removed from the Map-Cache while keeping less-
specific entries. specific entries.
Map-Replies SHOULD be sent for an EID-Prefix no more often than once For scalability, it is expected that aggregation of EID addresses
per second to the same requesting router. For scalability, it is into EID-Prefixes will allow one Map-Reply to satisfy a mapping for
expected that aggregation of EID addresses into EID-Prefixes will the EID addresses in the prefix range, thereby reducing the number of
allow one Map-Reply to satisfy a mapping for the EID addresses in the Map-Request messages.
prefix range, thereby reducing the number of Map-Request messages.
Map-Reply records can have an empty Locator-Set. A Negative Map- Map-Reply records can have an empty Locator-Set. A Negative Map-
Reply is a Map-Reply with an empty Locator-Set. Negative Map-Replies Reply is a Map-Reply with an empty Locator-Set. Negative Map-Replies
convey special actions by the sender to the ITR or PITR that have convey special actions by the sender to the ITR or PITR that have
solicited the Map-Reply. There are two primary applications for solicited the Map-Reply. There are two primary applications for
Negative Map-Replies. The first is for a Map-Resolver to instruct an Negative Map-Replies. The first is for a Map-Resolver to instruct an
ITR or PITR when a destination is for a LISP site versus a non-LISP ITR or PITR when a destination is for a LISP site versus a non-LISP
site, and the other is to source quench Map-Requests that are sent site, and the other is to source quench Map-Requests that are sent
for non-allocated EIDs. for non-allocated EIDs.
skipping to change at page 26, line 12 skipping to change at page 26, line 12
Register message is sent. When a Map-Register acknowledgement is Register message is sent. When a Map-Register acknowledgement is
requested, the nonce is returned by Map-Servers in Map-Notify requested, the nonce is returned by Map-Servers in Map-Notify
messages. Since the entire Map-Register message is authenticated, messages. Since the entire Map-Register message is authenticated,
the 'Nonce' field serves to protect against Map-Register replay the 'Nonce' field serves to protect against Map-Register replay
attacks. An ETR that registers to the mapping system SHOULD store attacks. An ETR that registers to the mapping system SHOULD store
the last nonce sent in persistent storage so when it restarts it the last nonce sent in persistent storage so when it restarts it
can continue using an incrementing nonce. If the the ETR cannot can continue using an incrementing nonce. If the the ETR cannot
support saving the nonce, then when it restarts it MUST use a new support saving the nonce, then when it restarts it MUST use a new
authentication key to register to the mapping system. A Map- authentication key to register to the mapping system. A Map-
Server MUST track and save in persistent storage the last nonce Server MUST track and save in persistent storage the last nonce
received for each ETR xTR-ID that registers to it. If a Map- received for each ETR xTR-ID and key pair. If a Map-Register is
Register is received with a nonce value that is not greater than received with a nonce value that is not greater than the saved
the saved nonce, it drops the Map-Register message and logs the nonce, it drops the Map-Register message and logs the fact a
fact a replay attack could have occurred. replay attack could have occurred.
Key ID: This is a configured key-id value that corresponds to a Key ID: A key-id value that identifies a pre-shared secret between
shared-secret password that is used to authenticate the sender. an ETR and a Map-Server. Per-message keys are derived from the
Multiple shared-secrets can be used to roll over keys in a non- pre-shared secret to authenticate the origin and protect the
disruptive way. integrity of the Map-Register. The Key ID allows to rotate
between multiple pre-shared secrets in a non disruptive way. The
pre-shared secret MUST be unique per each LISP "Site-ID"
Algorithm ID: This is the configured Message Authentication Code Algorithm ID: This field identifies the Key Derivation Function
(MAC) algorithm value used for the authentication function. See (KDF) and Message Authentication Code (MAC) algorithms used to
Algorithm ID Numbers in the Section 12.5 for codepoint derive the key and to compute the Authentication Data of a Map-
assignments. Register. This 8-bit field identifies the KDF and MAC algorithm
pair. See Section 12.5 for codepoint assignments.
Authentication Data Length: This is the length in octets of the Authentication Data Length: This is the length in octets of the
'Authentication Data' field that follows this field. The length 'Authentication Data' field that follows this field. The length
of the 'Authentication Data' field is dependent on the MAC of the 'Authentication Data' field is dependent on the MAC
algorithm used. The length field allows a device that doesn't algorithm used. The length field allows a device that doesn't
know the MAC algorithm to correctly parse the packet. know the MAC algorithm to correctly parse the packet.
Authentication Data: This is the output of the MAC algorithm. The Authentication Data: This is the output of the MAC algorithm placed
entire Map-Register payload (from and including the LISP message in this field after the MAC computation. The MAC output is
type field through the end of the last RLOC record) is computed as follows:
authenticated with this field preset to 0. After the MAC is
computed, it is placed in this field. Implementations of this 1: The KDF algorithm is identified by the field 'Algorithm ID'
specification MUST include support for either HMAC-SHA-1-96 according to the table in Section 12.5. Implementations of
[RFC2404] and HMAC-SHA-256-128 [RFC4868] where the latter is this specification SHOULD include support for HMAC-SHA256-
RECOMMENDED. 128+HKDF-SHA256 [RFC4868].
2: The MAC algorithm is identified by the field 'Algorithm ID'
according to the table in Section 12.5.
3: The pre-shared secret used to derive the per-message key is
represented by PSK[Key ID], that is the pre-shared secret
identified by the 'Key ID'.
4: The derived per-message key is computed as: per-msg-
key=KDF(nonce+s+PSK[Key ID]). Where the nonce is the value in
the Nonce field of the Map-Register and 's' is a string equal
to "Map-Register Authentication".
5: The MAC output is computed using the MAC algorithm and the
per-msg-key over the entire Map-Register payload (from and
including the LISP message type field through the end of the
last RLOC record) with the authenticated data field preset to
0.
The definition of the rest of the Map-Register can be found in EID- The definition of the rest of the Map-Register can be found in EID-
record description in Section 5.4. When the I-bit is set, the record description in Section 5.4. When the I-bit is set, the
following fields are added to the end of thd Map-Register message: following fields are added to the end of the Map-Register message:
xTR-ID: xTR-ID is a 128 bit field at the end of the Map-Register xTR-ID: xTR-ID is a 128 bit field at the end of the Map-Register
message, starting after the final Record in the message. The xTR- message, starting after the final Record in the message. The xTR-
ID is used to uniquely identify a xTR. The same xTR-ID value MUST ID is used to uniquely identify a xTR. The same xTR-ID value MUST
NOT be used in two different xTRs. NOT be used in two different xTRs.
Site-ID: Site-ID is a 64 bit field at the end of the Map- Register Site-ID: Site-ID is a 64 bit field at the end of the Map- Register
message, following the xTR-ID. Site-ID is used to uniquely message, following the xTR-ID. Site-ID is used to uniquely
identify to which site the xTR that sent the message belongs. identify to which site the xTR that sent the message belongs.
skipping to change at page 28, line 50 skipping to change at page 28, line 50
Packet field descriptions: Packet field descriptions:
Type: 4/5 (Map-Notify/Map-Notify-Ack) Type: 4/5 (Map-Notify/Map-Notify-Ack)
The Map-Notify message has the same contents as a Map-Register The Map-Notify message has the same contents as a Map-Register
message. See the Map-Register section for field descriptions and the message. See the Map-Register section for field descriptions and the
Map-Reply section for EID-record and RLOC-record descriptions. Map-Reply section for EID-record and RLOC-record descriptions.
The fields of the Map-Notify are copied from the corresponding Map- The fields of the Map-Notify are copied from the corresponding Map-
Register to acknowledge its correct processing. For an unsolicited Register to acknowledge its correct processing. In the Map-Notfiy,
Map-Notify, the fields of a Map-Notify used for publish/subscribe are the 'Authentication Data' field is recomputed according to the
specified in [I-D.ietf-lisp-pubsub]]. procedure defined in the previous section. For an unsolicited Map-
Notify, the fields of a Map-Notify used for publish/subscribe are
specified in [I-D.ietf-lisp-pubsub].
After sending a Map-Register, if a Map-Notify is not received after 1
second the transmitter MUST re-transmit the original Map-Register
with an exponential backoff, the maximum backoff is 1 minute.
The Map-Notify-Ack message has the same contents as a Map-Notify The Map-Notify-Ack message has the same contents as a Map-Notify
message. It is used to acknowledge the receipt of a Map-Notify message. It is used to acknowledge the receipt of a Map-Notify
(solicited or unsolicited) and for the sender to stop retransmitting (solicited or unsolicited) and for the sender to stop retransmitting
a Map-Notify with the same nonce. The fields of the Map-Notify-Ack a Map-Notify with the same nonce. The fields of the Map-Notify-Ack
are copied from the corresponding Map-Notify message to acknowledge are copied from the corresponding Map-Notify message to acknowledge
its correct processing. its correct processing.
A Map-Server sends an unsolicited Map-Notify message (one that is not A Map-Server sends an unsolicited Map-Notify message (one that is not
used as an acknowledgment to a Map-Register message) that follows the used as an acknowledgment to a Map-Register message) that follows the
skipping to change at page 32, line 36 skipping to change at page 32, line 36
cached their mappings, they do not know which ITRs need to have their cached their mappings, they do not know which ITRs need to have their
mappings updated. As a result, an ETR will solicit Map-Requests mappings updated. As a result, an ETR will solicit Map-Requests
(called an SMR message) to those sites to which it has been sending (called an SMR message) to those sites to which it has been sending
LISP encapsulated data packets for the last minute. In particular, LISP encapsulated data packets for the last minute. In particular,
an ETR will send an SMR to an ITR to which it has recently sent an ETR will send an SMR to an ITR to which it has recently sent
encapsulated data. This can only occur when both ITR and ETR encapsulated data. This can only occur when both ITR and ETR
functionality reside in the same router. functionality reside in the same router.
An SMR message is simply a bit set in a Map-Request message. An ITR An SMR message is simply a bit set in a Map-Request message. An ITR
or PITR will send a Map-Request when they receive an SMR message. or PITR will send a Map-Request when they receive an SMR message.
Both the SMR sender and the Map-Request responder MUST rate-limit Both the SMR sender and the SMR responder MUST rate-limit these
these messages. Rate-limiting can be implemented as a global rate- messages. It is RECOMMENDED that the SMR sender rate-limits Map-
limiter or one rate-limiter per SMR destination. Request for the same destination RLOC to no more than one packet per
3 seconds. It is RECOMMENDED that the SMR responder rate-limits Map-
Request for the same EID-Prefix to no more than once per 3 seconds.
The following procedure shows how an SMR exchange occurs when a site The following procedure shows how an SMR exchange occurs when a site
is doing Locator-Set compaction for an EID-to-RLOC mapping: is doing Locator-Set compaction for an EID-to-RLOC mapping:
1. When the database mappings in an ETR change, the ETRs at the site 1. When the database mappings in an ETR change, the ETRs at the site
begin to send Map-Requests with the SMR bit set for each Locator begin to send Map-Requests with the SMR bit set for each Locator
in each Map-Cache entry the ETR (when it is an xTR co-located as in each Map-Cache entry the ETR (when it is an xTR co-located as
an ITR) caches. an ITR) caches.
2. A remote ITR that receives the SMR message will schedule sending 2. A remote ITR that receives the SMR message will schedule sending
skipping to change at page 33, line 17 skipping to change at page 33, line 19
accept the Map-Request. accept the Map-Request.
3. The remote ITR MUST rate-limit the Map-Request until it gets a 3. The remote ITR MUST rate-limit the Map-Request until it gets a
Map-Reply while continuing to use the cached mapping. When Map-Reply while continuing to use the cached mapping. When
Map-Versioning as described in [I-D.ietf-lisp-6834bis] is used, Map-Versioning as described in [I-D.ietf-lisp-6834bis] is used,
an SMR sender can detect if an ITR is using the most up-to-date an SMR sender can detect if an ITR is using the most up-to-date
database mapping. database mapping.
4. The site sending SMR messages will reply to the Map-Request with 4. The site sending SMR messages will reply to the Map-Request with
a Map-Reply message that has a nonce from the SMR-invoked Map- a Map-Reply message that has a nonce from the SMR-invoked Map-
Request. The Map-Reply messages MUST be rate-limited according Request. This is important to avoid Map-Reply implosion.
to procedures in [RFC8085]. This is important to avoid Map-Reply
implosion.
5. The ETRs at the site with the changed mapping record the fact 5. The ETRs at the site with the changed mapping record the fact
that the site that sent the Map-Request has received the new that the site that sent the Map-Request has received the new
mapping data in the Map-Cache entry for the remote site so the mapping data in the Map-Cache entry for the remote site so the
Locator-Status-Bits are reflective of the new mapping for packets Locator-Status-Bits are reflective of the new mapping for packets
going to the remote site. The ETR then stops sending SMR going to the remote site. The ETR then stops sending SMR
messages. messages.
For security reasons, an ITR MUST NOT process unsolicited Map- For security reasons, an ITR MUST NOT process unsolicited Map-
Replies. To avoid Map-Cache entry corruption by a third party, a Replies. To avoid Map-Cache entry corruption by a third party, a
skipping to change at page 36, line 44 skipping to change at page 36, line 44
the following: the following:
o An immediate Negative Map-Reply (with action code of "Natively- o An immediate Negative Map-Reply (with action code of "Natively-
Forward", 15-minute Time to Live (TTL)) from the Map-Resolver if Forward", 15-minute Time to Live (TTL)) from the Map-Resolver if
the Map-Resolver can determine that the requested EID does not the Map-Resolver can determine that the requested EID does not
exist. The ITR saves the EID-Prefix returned in the Map-Reply in exist. The ITR saves the EID-Prefix returned in the Map-Reply in
its cache, marks it as non-LISP-capable, and knows not to attempt its cache, marks it as non-LISP-capable, and knows not to attempt
LISP encapsulation for destinations matching it. LISP encapsulation for destinations matching it.
o A Negative Map-Reply, with action code of "Natively-Forward", from o A Negative Map-Reply, with action code of "Natively-Forward", from
a Map-Server that is authoritative for an EID-Prefix that matches a Map-Server that is authoritative (within the LISP deployment
the requested EID but that does not have an actively registered, Section 1.1) for an EID-Prefix that matches the requested EID but
more-specific ID-prefix. In this case, the requested EID is said that does not have an actively registered, more-specific EID-
to match a "hole" in the authoritative EID-Prefix. If the prefix. In this case, the requested EID is said to match a "hole"
requested EID matches a more-specific EID-Prefix that has been in the authoritative EID-Prefix. If the requested EID matches a
delegated by the Map-Server but for which no ETRs are currently more-specific EID-Prefix that has been delegated by the Map-Server
registered, a 1-minute TTL is returned. If the requested EID but for which no ETRs are currently registered, a 1-minute TTL is
matches a non-delegated part of the authoritative EID-Prefix, then returned. If the requested EID matches a non-delegated part of
it is not a LISP EID and a 15-minute TTL is returned. See the authoritative EID-Prefix, then it is not a LISP EID and a
Section 8.2 for discussion of aggregate EID-Prefixes and details 15-minute TTL is returned. See Section 8.2 for discussion of
of Map-Server EID-Prefix matching. aggregate EID-Prefixes and details of Map-Server EID-Prefix
matching.
o A LISP Map-Reply from the ETR that owns the EID-to-RLOC mapping or o A LISP Map-Reply from the ETR that owns the EID-to-RLOC mapping or
possibly from a Map-Server answering on behalf of the ETR. See possibly from a Map-Server answering on behalf of the ETR. See
Section 8.4 for more details on Map-Resolver message processing. Section 8.4 for more details on Map-Resolver message processing.
Note that an ITR may be configured to both use a Map-Resolver and to Note that an ITR may be configured to both use a Map-Resolver and to
participate in a LISP-ALT logical network. In such a situation, the participate in a LISP-ALT logical network. In such a situation, the
ITR SHOULD send Map-Requests through the ALT network for any EID- ITR SHOULD send Map-Requests through the ALT network for any EID-
Prefix learned via ALT BGP. Such a configuration is expected to be Prefix learned via ALT BGP. Such a configuration is expected to be
very rare, since there is little benefit to using a Map-Resolver if very rare, since there is little benefit to using a Map-Resolver if
skipping to change at page 37, line 28 skipping to change at page 37, line 29
need for such an ITR to send a Map-Request to a possibly non-existent need for such an ITR to send a Map-Request to a possibly non-existent
EID (and rely on Negative Map-Replies) if it can consult the ALT EID (and rely on Negative Map-Replies) if it can consult the ALT
database to verify that an EID-Prefix is present before sending that database to verify that an EID-Prefix is present before sending that
Map-Request. Map-Request.
8.2. EID-Prefix Configuration and ETR Registration 8.2. EID-Prefix Configuration and ETR Registration
An ETR publishes its EID-Prefixes on a Map-Server by sending LISP An ETR publishes its EID-Prefixes on a Map-Server by sending LISP
Map-Register messages. A Map-Register message includes Map-Register messages. A Map-Register message includes
authentication data, so prior to sending a Map-Register message, the authentication data, so prior to sending a Map-Register message, the
ETR and Map-Server SHOULD be configured with a shared secret or other ETR and Map-Server MUST be configured with a pre-shared secret used
relevant authentication information. A Map-Server's configuration to derive Map-Register authentication keys. A Map-Server's
SHOULD also include a list of the EID-Prefixes for which each ETR is configuration SHOULD also include a list of the EID-Prefixes for
authoritative. Upon receipt of a Map-Register from an ETR, a Map- which each ETR is authoritative. Upon receipt of a Map-Register from
Server accepts only EID-Prefixes that are configured for that ETR. an ETR, a Map-Server accepts only EID-Prefixes that are configured
Failure to implement such a check would leave the mapping system for that ETR. Failure to implement such a check would leave the
vulnerable to trivial EID-Prefix hijacking attacks. As developers mapping system vulnerable to trivial EID-Prefix hijacking attacks.
and operators gain experience with the mapping system, additional,
stronger security measures may be added to the registration process.
In addition to the set of EID-Prefixes defined for each ETR that may In addition to the set of EID-Prefixes defined for each ETR that may
register, a Map-Server is typically also configured with one or more register, a Map-Server is typically also configured with one or more
aggregate prefixes that define the part of the EID numbering space aggregate prefixes that define the part of the EID numbering space
assigned to it. When LISP-ALT is the database in use, aggregate EID- assigned to it. When LISP-ALT is the database in use, aggregate EID-
Prefixes are implemented as discard routes and advertised into ALT Prefixes are implemented as discard routes and advertised into ALT
BGP. The existence of aggregate EID-Prefixes in a Map-Server's BGP. The existence of aggregate EID-Prefixes in a Map-Server's
database means that it may receive Map Requests for EID-Prefixes that database means that it may receive Map Requests for EID-Prefixes that
match an aggregate but do not match a registered prefix; Section 8.3 match an aggregate but do not match a registered prefix; Section 8.3
describes how this is handled. describes how this is handled.
skipping to change at page 39, line 16 skipping to change at page 39, line 16
connecting to the mapping database (i.e., it could also connect to connecting to the mapping database (i.e., it could also connect to
the LISP-ALT network), but doing so doesn't seem particularly useful, the LISP-ALT network), but doing so doesn't seem particularly useful,
as the whole purpose of using a Map-Server is to avoid the complexity as the whole purpose of using a Map-Server is to avoid the complexity
of the mapping database protocols. of the mapping database protocols.
8.3. Map-Server Processing 8.3. Map-Server Processing
Once a Map-Server has EID-Prefixes registered by its client ETRs, it Once a Map-Server has EID-Prefixes registered by its client ETRs, it
can accept and process Map-Requests for them. can accept and process Map-Requests for them.
In response to a Map-Request (received over the ALT if LISP-ALT is in In response to a Map-Request, the Map-Server first checks to see if
use), the Map-Server first checks to see if the destination EID the destination EID matches a configured EID-Prefix. If there is no
matches a configured EID-Prefix. If there is no match, the Map- match, the Map-Server returns a Negative Map-Reply with action code
Server returns a Negative Map-Reply with action code "Natively- "Natively-Forward" and a 15-minute TTL. This can occur if a Map
Forward" and a 15-minute TTL. This can occur if a Map Request is Request is received for a configured aggregate EID-Prefix for which
received for a configured aggregate EID-Prefix for which no more- no more-specific EID-Prefix exists; it indicates the presence of a
specific EID-Prefix exists; it indicates the presence of a non-LISP non-LISP "hole" in the aggregate EID-Prefix.
"hole" in the aggregate EID-Prefix.
Next, the Map-Server checks to see if any ETRs have registered the Next, the Map-Server checks to see if any ETRs have registered the
matching EID-Prefix. If none are found, then the Map-Server returns matching EID-Prefix. If none are found, then the Map-Server returns
a Negative Map-Reply with action code "Natively-Forward" and a a Negative Map-Reply with action code "Natively-Forward" and a
1-minute TTL. 1-minute TTL.
If the EID-prefix is either registered or not registered to the If the EID-prefix is either registered or not registered to the
mapping system and there is a policy in the Map-Server to have the mapping system and there is a policy in the Map-Server to have the
requestor drop packets for the matching EID-prefix, then a Drop/ requestor drop packets for the matching EID-prefix, then a Drop/
Policy-Denied action is returned. If the EID-prefix is registered or Policy-Denied action is returned. If the EID-prefix is registered or
skipping to change at page 41, line 7 skipping to change at page 40, line 50
routing, to facilitate the use of a topologically close Map-Resolver routing, to facilitate the use of a topologically close Map-Resolver
by each ITR. by each ITR.
ETRs MAY have anycast RLOC addresses which are registered as part of ETRs MAY have anycast RLOC addresses which are registered as part of
their RLOC-set to the mapping system. However, registrations MUST their RLOC-set to the mapping system. However, registrations MUST
use their unique RLOC addresses or distinct authentication keys to use their unique RLOC addresses or distinct authentication keys to
identify security associations with the Map-Servers. identify security associations with the Map-Servers.
9. Security Considerations 9. Security Considerations
A complete LISP threat analysis can be found in [RFC7835]. In what A LISP threat analysis can be found in [RFC7835]. In what follows we
follows we highlight security considerations that apply when LISP is highlight security considerations that apply when LISP is deployed in
deployed in environments such as those specified in Section 1.1, environments such as those specified in Section 1.1, where the
where the following assumptions hold: following assumptions hold:
1. The Mapping System is secure and trusted, and for the purpose of 1. The Mapping System is secure and trusted, and for the purpose of
this security considerations the Mapping System is considered as this security considerations the Mapping System is considered as
one trusted element. one trusted element.
2. The ETRs have a pre-configured trust relationship with the 2. The ETRs have a pre-configured trust relationship with the
Mapping System, which includes some form of shared keys, and the Mapping System, which includes some form of shared secret, and
Mapping System is aware of which EIDs an ETR can advertise. How the Mapping System is aware of which EIDs an ETR can advertise.
those keys and mappings gets established is out of the scope of How those keys and mappings gets established is out of the scope
this document. of this document.
3. LISP-SEC [I-D.ietf-lisp-sec] MUST be implemented. Network 3. LISP-SEC [I-D.ietf-lisp-sec] MUST be implemented. Network
operartors should carefully weight how the LISP-SEC threat model operartors should carefully weight how the LISP-SEC threat model
applies to their particular use case or deployment. If they applies to their particular use case or deployment. If they
decide to ignore a particular recommendation, they should make decide to ignore a particular recommendation, they should make
sure the risk associated with the corresponding threats is well sure the risk associated with the corresponding threats is well
understood. understood.
The Map-Request/Map-Reply message exchange can be exploited by an The Map-Request/Map-Reply message exchange can be exploited by an
attacker to mount DoS and/or amplification attacks. Attackers can attacker to mount DoS and/or amplification attacks. Attackers can
send Map-Requests at high rates to overload LISP nodes and increase send Map-Requests at high rates to overload LISP nodes and increase
the state maintained by such nodes or consume CPU cycles. Such the state maintained by such nodes or consume CPU cycles. Such
threats can be mitigated by systematically applying filters and rate threats can be mitigated by systematically applying filters and rate
limiters. limiters.
The 2-way LISP control-plane header nonce exchange can be used to The Map-Request/Map-Reply message exchange to inject forged mappings
avoid ITR spoofing attacks, but active on-path attackers (e.g 'man-
in-the-middle') capable of intercepting the nonce can exploit the
Map-Request/Map-Reply message exchange to inject forged mappings
directly in the ITR EID-to-RLOC map-cache. This can lead to traffic directly in the ITR EID-to-RLOC map-cache. This can lead to traffic
being redirected to the attacker, see further details in [RFC7835]. being redirected to the attacker, see further details in [RFC7835].
In addition, valid ETRs in the system can perform overclaiming In addition, valid ETRs in the system can perform overclaiming
attacks. In this case, attackers can claim to own an EID-prefix that attacks. In this case, attackers can claim to own an EID-prefix that
is larger than the prefix owned by the ETR. Such attacks can be is larger than the prefix owned by the ETR. Such attacks can be
addressed by using LISP-SEC [I-D.ietf-lisp-sec]. The LISP-SEC addressed by using LISP-SEC [I-D.ietf-lisp-sec]. The LISP-SEC
protocol defines a mechanism for providing origin authentication, protocol defines a mechanism for providing origin authentication,
integrity, anti-replay, protection, and prevention of 'man-in-the- integrity, anti-replay, protection, and prevention of 'man-in-the-
middle' and 'prefix overclaiming' attacks on the Map-Request/Map- middle' and 'prefix overclaiming' attacks on the Map-Request/Map-
Reply exchange. In addition and while beyond the scope of securing Reply exchange. In addition and while beyond the scope of securing
an individual Map-Server or Map-Resolver, it should be noted that an individual Map-Server or Map-Resolver, it should be noted that
LISP-SEC can be complemented by additional security mechanisms LISP-SEC can be complemented by additional security mechanisms
defined by the Mapping System Infrastructure. For instance, BGP- defined by the Mapping System Infrastructure. For instance, BGP-
based LISP-ALT [RFC6836] can take advantage of standards work on based LISP-ALT [RFC6836] can take advantage of standards work on
adding security to BGP while LISP-DDT [RFC8111] defines its own adding security to BGP while LISP-DDT [RFC8111] defines its own
additional security mechanisms. additional security mechanisms.
To publish an authoritative EID-to-RLOC mapping with a Map-Server To publish an authoritative EID-to-RLOC mapping with a Map-Server
using the Map-Register message, an ETR includes authentication data using the Map-Register message, an ETR includes authentication data
that is a MAC of the entire message using a pair-wise shared key. An that is a MAC of the entire message using a key derived from the pre-
implementation MUST support use of HMAC-SHA-1-96 [RFC2104] and SHOULD shared secret. An implementation MUST support HMAC-SHA256-128+HKDF-
support use of HMAC-SHA-256-128 [RFC6234] (SHA-256 truncated to 128 SHA256 [RFC4868]. The Map-Register message includes protection for
bits). The Map-Register message is vulnerable to replay attacks by a replay attacks by a man-in-the-middle. However, a compromised ETR
man-in-the-middle. A compromised ETR can overclaim the prefix it can overclaim the prefix it owns and successfully register it on its
owns and successfully register it on its corresponding Map-Server. corresponding Map-Server. To mitigate this and as noted in
To mitigate this and as noted in Section 8.2, a Map-Server SHOULD Section 8.2, a Map-Server MUST verify that all EID-Prefixes
verify that all EID-Prefixes registered by an ETR match the registered by an ETR match the configuration stored on the Map-
configuration stored on the Map-Server. Server.
Deployments concerned about manipulations of Map-Request and Map- Deployments concerned about manipulations of Map-Request and Map-
Reply messages, and malicious ETR EID prefix overclaiming MUST drop Reply messages, and malicious ETR EID prefix overclaiming MUST drop
LISP Control Plane messages that do not contain LISP-SEC material LISP Control Plane messages that do not contain LISP-SEC material
(S-bit, EID-AD, OTK-AD, PKT-AD). (S-bit, EID-AD, OTK-AD, PKT-AD).
Encrypting control messages via DTLS [RFC6347] or LISP-crypto Encrypting control messages via DTLS [RFC6347] or LISP-crypto
[RFC8061] SHOULD be used to support privacy to prevent eavesdroping [RFC8061] SHOULD be used to support privacy to prevent eavesdroping
and packet tampering for messages exchanged between xTRs, xTRs and and packet tampering for messages exchanged between xTRs, xTRs and
the mapping system, and nodes that make up the mapping system. the mapping system, and nodes that make up the mapping system.
A complete LISP threat analysis has been published in [RFC7835].
Please refer to it for more detailed security related details.
10. Privacy Considerations 10. Privacy Considerations
As noted by [RFC6973] privacy is a complex issue that greatly depends As noted by [RFC6973] privacy is a complex issue that greatly depends
on the specific protocol use-case and deployment. As noted in on the specific protocol use-case and deployment. As noted in
section 1.1 of [I-D.ietf-lisp-rfc6830bis] LISP focuses on use-cases section 1.1 of [I-D.ietf-lisp-rfc6830bis] LISP focuses on use-cases
where entities communicate over the public Internet while keeping where entities communicate over the public Internet while keeping
separate addressing and topology. In what follows we detail the separate addressing and topology. In what follows we detail the
privacy threats introduced by the LISP Control Plane, the analysis is privacy threats introduced by the LISP Control Plane, the analysis is
based on the guidelines detailed in [RFC6973]. based on the guidelines detailed in [RFC6973].
skipping to change at page 46, line 14 skipping to change at page 46, line 8
12.5. LISP Algorithm ID Numbers 12.5. LISP Algorithm ID Numbers
In [RFC6830], a request for a "LISP Key ID Numbers" registry was In [RFC6830], a request for a "LISP Key ID Numbers" registry was
submitted. This document renames the registry to "LISP Algorithm ID submitted. This document renames the registry to "LISP Algorithm ID
Numbers" and requests the IANA to make the name change. Numbers" and requests the IANA to make the name change.
The following Algorithm ID values are defined by this specification The following Algorithm ID values are defined by this specification
as used in any packet type that references a 'Algorithm ID' field: as used in any packet type that references a 'Algorithm ID' field:
Name Number Defined in Name Number MAC KDF
----------------------------------------------- -------------------------------------------------------
None 0 RFC6833bis None 0 None None
HMAC-SHA-1-96 1 [RFC2404] HMAC-SHA-1-96-None 1 [RFC2404] None
HMAC-SHA-256-128 2 [RFC4868] HMAC-SHA-256-128-None 2 [RFC4868] None
HMAC-SHA256-128+HKDF-SHA2562 3 [RFC4868] [RFC4868]
Number values are in the range of 0 to 255. The allocation of values Number values are in the range of 0 to 255. The allocation of values
is on a first come first served basis. is on a first come first served basis.
12.6. LISP Bit Flags 12.6. LISP Bit Flags
This document asks IANA to create a registry for allocation of bits This document asks IANA to create a registry for allocation of bits
in several headers of the LISP control plane, namely in the Map- in several headers of the LISP control plane, namely in the Map-
Request, Map-Reply, Map-Register, Encapsulated Control Message (ECM) Request, Map-Reply, Map-Register, Encapsulated Control Message (ECM)
messages. Bit allocations are also requested for EID-records and messages. Bit allocations are also requested for EID-records and
skipping to change at page 49, line 28 skipping to change at page 49, line 28
LISP RLOC-Record Header Bits LISP RLOC-Record Header Bits
13. References 13. References
13.1. Normative References 13.1. Normative References
[I-D.ietf-lisp-6834bis] [I-D.ietf-lisp-6834bis]
Iannone, L., Saucez, D., and O. Bonaventure, "Locator/ID Iannone, L., Saucez, D., and O. Bonaventure, "Locator/ID
Separation Protocol (LISP) Map-Versioning", draft-ietf- Separation Protocol (LISP) Map-Versioning", draft-ietf-
lisp-6834bis-02 (work in progress), September 2018. lisp-6834bis-03 (work in progress), February 2019.
[I-D.ietf-lisp-rfc6830bis] [I-D.ietf-lisp-rfc6830bis]
Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A. Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A.
Cabellos-Aparicio, "The Locator/ID Separation Protocol Cabellos-Aparicio, "The Locator/ID Separation Protocol
(LISP)", draft-ietf-lisp-rfc6830bis-26 (work in progress), (LISP)", draft-ietf-lisp-rfc6830bis-26 (work in progress),
November 2018. November 2018.
[I-D.ietf-lisp-rfc8113bis] [I-D.ietf-lisp-rfc8113bis]
Boucadair, M. and C. Jacquenet, "Locator/ID Separation Boucadair, M. and C. Jacquenet, "Locator/ID Separation
Protocol (LISP): Shared Extension Message & IANA Registry Protocol (LISP): Shared Extension Message & IANA Registry
for Packet Type Allocations", draft-ietf-lisp- for Packet Type Allocations", draft-ietf-lisp-
rfc8113bis-03 (work in progress), January 2019. rfc8113bis-03 (work in progress), January 2019.
[I-D.ietf-lisp-sec] [I-D.ietf-lisp-sec]
Maino, F., Ermagan, V., Cabellos-Aparicio, A., and D. Maino, F., Ermagan, V., Cabellos-Aparicio, A., and D.
Saucez, "LISP-Security (LISP-SEC)", draft-ietf-lisp-sec-17 Saucez, "LISP-Security (LISP-SEC)", draft-ietf-lisp-sec-18
(work in progress), November 2018. (work in progress), June 2019.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within [RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within
ESP and AH", RFC 2404, DOI 10.17487/RFC2404, November ESP and AH", RFC 2404, DOI 10.17487/RFC2404, November
1998, <https://www.rfc-editor.org/info/rfc2404>. 1998, <https://www.rfc-editor.org/info/rfc2404>.
skipping to change at page 50, line 38 skipping to change at page 50, line 38
Writing an IANA Considerations Section in RFCs", BCP 26, Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>. <https://www.rfc-editor.org/info/rfc8126>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
13.2. Informative References 13.2. Informative References
[AFI] IANA, "Address Family Identifier (AFIs)", ADDRESS FAMILY [AFI] "Address Family Identifier (AFIs)", ADDRESS FAMILY
NUMBERS http://www.iana.org/assignments/address-family- NUMBERS http://www.iana.org/assignments/address-family-
numbers/address-family-numbers.xhtml?, Febuary 2007. numbers/address-family-numbers.xhtml?, Febuary 2007.
[GTP-3GPP] [GTP-3GPP]
3GPP, "General Packet Radio System (GPRS) Tunnelling "General Packet Radio System (GPRS) Tunnelling Protocol
Protocol User Plane (GTPv1-U)", TS.29.281 User Plane (GTPv1-U)", TS.29.281
https://portal.3gpp.org/desktopmodules/Specifications/ https://portal.3gpp.org/desktopmodules/Specifications/
SpecificationDetails.aspx?specificationId=1699, January SpecificationDetails.aspx?specificationId=1699, January
2015. 2015.
[I-D.herbert-intarea-ila] [I-D.herbert-intarea-ila]
Herbert, T. and P. Lapukhov, "Identifier-locator Herbert, T. and P. Lapukhov, "Identifier-locator
addressing for IPv6", draft-herbert-intarea-ila-01 (work addressing for IPv6", draft-herbert-intarea-ila-01 (work
in progress), March 2018. in progress), March 2018.
[I-D.ietf-lisp-ecdsa-auth] [I-D.ietf-lisp-ecdsa-auth]
Farinacci, D. and E. Nordmark, "LISP Control-Plane ECDSA Farinacci, D. and E. Nordmark, "LISP Control-Plane ECDSA
Authentication and Authorization", draft-ietf-lisp-ecdsa- Authentication and Authorization", draft-ietf-lisp-ecdsa-
auth-00 (work in progress), September 2018. auth-01 (work in progress), March 2019.
[I-D.ietf-lisp-eid-anonymity] [I-D.ietf-lisp-eid-anonymity]
Farinacci, D., Pillay-Esnault, P., and W. Haddad, "LISP Farinacci, D., Pillay-Esnault, P., and W. Haddad, "LISP
EID Anonymity", draft-ietf-lisp-eid-anonymity-04 (work in EID Anonymity", draft-ietf-lisp-eid-anonymity-06 (work in
progress), October 2018. progress), April 2019.
[I-D.ietf-lisp-eid-mobility] [I-D.ietf-lisp-eid-mobility]
Portoles-Comeras, M., Ashtaputre, V., Moreno, V., Maino, Portoles-Comeras, M., Ashtaputre, V., Moreno, V., Maino,
F., and D. Farinacci, "LISP L2/L3 EID Mobility Using a F., and D. Farinacci, "LISP L2/L3 EID Mobility Using a
Unified Control Plane", draft-ietf-lisp-eid-mobility-03 Unified Control Plane", draft-ietf-lisp-eid-mobility-04
(work in progress), November 2018. (work in progress), May 2019.
[I-D.ietf-lisp-gpe] [I-D.ietf-lisp-gpe]
Maino, F., Lemon, J., Agarwal, P., Lewis, D., and M. Maino, F., Lemon, J., Agarwal, P., Lewis, D., and M.
Smith, "LISP Generic Protocol Extension", draft-ietf-lisp- Smith, "LISP Generic Protocol Extension", draft-ietf-lisp-
gpe-06 (work in progress), September 2018. gpe-06 (work in progress), September 2018.
[I-D.ietf-lisp-introduction] [I-D.ietf-lisp-introduction]
Cabellos-Aparicio, A. and D. Saucez, "An Architectural Cabellos-Aparicio, A. and D. Saucez, "An Architectural
Introduction to the Locator/ID Separation Protocol Introduction to the Locator/ID Separation Protocol
(LISP)", draft-ietf-lisp-introduction-13 (work in (LISP)", draft-ietf-lisp-introduction-13 (work in
progress), April 2015. progress), April 2015.
[I-D.ietf-lisp-mn] [I-D.ietf-lisp-mn]
Farinacci, D., Lewis, D., Meyer, D., and C. White, "LISP Farinacci, D., Lewis, D., Meyer, D., and C. White, "LISP
Mobile Node", draft-ietf-lisp-mn-04 (work in progress), Mobile Node", draft-ietf-lisp-mn-05 (work in progress),
October 2018. March 2019.
[I-D.ietf-lisp-pubsub] [I-D.ietf-lisp-pubsub]
Rodriguez-Natal, A., Ermagan, V., Leong, J., Maino, F., Rodriguez-Natal, A., Ermagan, V., Leong, J., Maino, F.,
Cabellos-Aparicio, A., Barkai, S., Farinacci, D., Cabellos-Aparicio, A., Barkai, S., Farinacci, D.,
Boucadair, M., Jacquenet, C., and S. Secci, "Publish/ Boucadair, M., Jacquenet, C., and S. Secci, "Publish/
Subscribe Functionality for LISP", draft-ietf-lisp- Subscribe Functionality for LISP", draft-ietf-lisp-
pubsub-02 (work in progress), November 2018. pubsub-03 (work in progress), March 2019.
[I-D.ietf-nvo3-vxlan-gpe] [I-D.ietf-nvo3-vxlan-gpe]
Maino, F., Kreeger, L., and U. Elzur, "Generic Protocol Maino, F., Kreeger, L., and U. Elzur, "Generic Protocol
Extension for VXLAN", draft-ietf-nvo3-vxlan-gpe-06 (work Extension for VXLAN", draft-ietf-nvo3-vxlan-gpe-07 (work
in progress), April 2018. in progress), April 2019.
[I-D.ietf-opsec-icmp-filtering] [I-D.ietf-opsec-icmp-filtering]
Gont, F., Gont, G., and C. Pignataro, "Recommendations for Gont, F., Gont, G., and C. Pignataro, "Recommendations for
filtering ICMP messages", draft-ietf-opsec-icmp- filtering ICMP messages", draft-ietf-opsec-icmp-
filtering-04 (work in progress), July 2013. filtering-04 (work in progress), July 2013.
[I-D.meyer-loc-id-implications] [I-D.meyer-loc-id-implications]
Meyer, D. and D. Lewis, "Architectural Implications of Meyer, D. and D. Lewis, "Architectural Implications of
Locator/ID Separation", draft-meyer-loc-id-implications-01 Locator/ID Separation", draft-meyer-loc-id-implications-01
(work in progress), January 2009. (work in progress), January 2009.
skipping to change at page 55, line 30 skipping to change at page 55, line 30
Kaduk, Eric Rescorla, Alvaro Retana, Alexey Melnikov, Alissa Cooper, Kaduk, Eric Rescorla, Alvaro Retana, Alexey Melnikov, Alissa Cooper,
Suresh Krishnan, Alberto Rodriguez-Natal, Vina Ermagen, Mohamed Suresh Krishnan, Alberto Rodriguez-Natal, Vina Ermagen, Mohamed
Boucadair, Brian Trammell, Sabrina Tanamal, and John Drake. The Boucadair, Brian Trammell, Sabrina Tanamal, and John Drake. The
contributions they offered greatly added to the security, scale, and contributions they offered greatly added to the security, scale, and
robustness of the LISP architecture and protocols. robustness of the LISP architecture and protocols.
Appendix B. Document Change Log Appendix B. Document Change Log
[RFC Editor: Please delete this section on publication as RFC.] [RFC Editor: Please delete this section on publication as RFC.]
B.1. Changes to draft-ietf-lisp-rfc6833bis-24 B.1. Changes to draft-ietf-lisp-rfc6833bis-25
o Posted June 2019.
o Added change requested by Mirja describing Record Count in an EID-
record.
o Fixed Requirements Notation section per Pete.
o Added KDF for shared-secret
o Specified several rate-limiters for control messages
B.2. Changes to draft-ietf-lisp-rfc6833bis-24
o Posted February 2019. o Posted February 2019.
o Added suggested text from Albert that Benjamin Kaduk agreed with. o Added suggested text from Albert that Benjamin Kaduk agreed with.
o Added suggested editorial comments from Alvaro's rewview. o Added suggested editorial comments from Alvaro's rewview.
o Ran document through IDnits. Fixed bugs found. o Ran document through IDnits. Fixed bugs found.
B.2. Changes to draft-ietf-lisp-rfc6833bis-23 B.3. Changes to draft-ietf-lisp-rfc6833bis-23
o Posted December 2018. o Posted December 2018.
o Added to Security Considerations section that deployments that o Added to Security Considerations section that deployments that
care about prefix over claiming should use LISP-SEC. care about prefix over claiming should use LISP-SEC.
o Added to Security Considerations section that DTLS or LISP-crypto o Added to Security Considerations section that DTLS or LISP-crypto
be used for control-plane privacy. be used for control-plane privacy.
o Make LISP-SEC a normative reference. o Make LISP-SEC a normative reference.
o Make it more clear where field descriptions are spec'ed when o Make it more clear where field descriptions are spec'ed when
referencing to the same fields in other packet types. referencing to the same fields in other packet types.
B.3. Changes to draft-ietf-lisp-rfc6833bis-22 B.4. Changes to draft-ietf-lisp-rfc6833bis-22
o Posted week after IETF November 2018. o Posted week after IETF November 2018.
o No longer need to use IPSEC for replay attacks. o No longer need to use IPSEC for replay attacks.
B.4. Changes to draft-ietf-lisp-rfc6833bis-21 B.5. Changes to draft-ietf-lisp-rfc6833bis-21
o Posted early November 2018. o Posted early November 2018.
o Added I-bit back in because its necessary to use for Map-Register o Added I-bit back in because its necessary to use for Map-Register
replay attack scenarios. The Map-Server tracks the nonce per xTR- replay attack scenarios. The Map-Server tracks the nonce per xTR-
ID to detect duplicate or replayed Map-Register messages. ID to detect duplicate or replayed Map-Register messages.
B.5. Changes to draft-ietf-lisp-rfc6833bis-20 B.6. Changes to draft-ietf-lisp-rfc6833bis-20
o Posted late October 2018. o Posted late October 2018.
o Changed description about "reserved" bits to state "reserved and o Changed description about "reserved" bits to state "reserved and
unassigned". unassigned".
o Make it more clear how Map-Register nonce processing is performed o Make it more clear how Map-Register nonce processing is performed
in an ETR and Map-Server. in an ETR and Map-Server.
B.6. Changes to draft-ietf-lisp-rfc6833bis-19 B.7. Changes to draft-ietf-lisp-rfc6833bis-19
o Posted mid October 2018. o Posted mid October 2018.
o Added Fabio text to the Security Considerations section. o Added Fabio text to the Security Considerations section.
B.7. Changes to draft-ietf-lisp-rfc6833bis-18 B.8. Changes to draft-ietf-lisp-rfc6833bis-18
o Posted mid October 2018. o Posted mid October 2018.
o Fixed comments from Eric after more email clarity. o Fixed comments from Eric after more email clarity.
B.8. Changes to draft-ietf-lisp-rfc6833bis-17 B.9. Changes to draft-ietf-lisp-rfc6833bis-17
o Posted early October 2018. o Posted early October 2018.
o Changes to reflect comments from Sep 27th Telechat. o Changes to reflect comments from Sep 27th Telechat.
o Added all flag bit definitions as request for allocation in IANA o Added all flag bit definitions as request for allocation in IANA
Considersations section. Considersations section.
o Added an applicability statement in section 1 to address security o Added an applicability statement in section 1 to address security
concerns from Telechat. concerns from Telechat.
o Moved m-bit description and IANA request to draft-ietf-lisp-mn. o Moved m-bit description and IANA request to draft-ietf-lisp-mn.
o Moved I-bit description and IANA request to draft-ietf-lisp- o Moved I-bit description and IANA request to draft-ietf-lisp-
pubsub. pubsub.
B.9. Changes to draft-ietf-lisp-rfc6833bis-16 B.10. Changes to draft-ietf-lisp-rfc6833bis-16
o Posted Late-September 2018. o Posted Late-September 2018.
o Re-wrote Security Considerations section. Thanks Albert. o Re-wrote Security Considerations section. Thanks Albert.
o Added Alvaro text to be more clear about IANA actions. o Added Alvaro text to be more clear about IANA actions.
B.10. Changes to draft-ietf-lisp-rfc6833bis-15 B.11. Changes to draft-ietf-lisp-rfc6833bis-15
o Posted mid-September 2018. o Posted mid-September 2018.
o Changes to reflect comments from Colin and Mirja. o Changes to reflect comments from Colin and Mirja.
B.11. Changes to draft-ietf-lisp-rfc6833bis-14 B.12. Changes to draft-ietf-lisp-rfc6833bis-14
o Posted September 2018. o Posted September 2018.
o Changes to reflect comments from Genart, RTGarea, and Secdir o Changes to reflect comments from Genart, RTGarea, and Secdir
reviews. reviews.
B.12. Changes to draft-ietf-lisp-rfc6833bis-13 B.13. Changes to draft-ietf-lisp-rfc6833bis-13
o Posted August 2018. o Posted August 2018.
o Final editorial changes before RFC submission for Proposed o Final editorial changes before RFC submission for Proposed
Standard. Standard.
o Added section "Changes since RFC 6833" so implementators are o Added section "Changes since RFC 6833" so implementators are
informed of any changes since the last RFC publication. informed of any changes since the last RFC publication.
B.13. Changes to draft-ietf-lisp-rfc6833bis-12 B.14. Changes to draft-ietf-lisp-rfc6833bis-12
o Posted late July 2018. o Posted late July 2018.
o Moved RFC6830bis and RFC6834bis to Normative References. o Moved RFC6830bis and RFC6834bis to Normative References.
B.14. Changes to draft-ietf-lisp-rfc6833bis-11 B.15. Changes to draft-ietf-lisp-rfc6833bis-11
o Posted July 2018. o Posted July 2018.
o Fixed Luigi editorial comments to ready draft for RFC status and o Fixed Luigi editorial comments to ready draft for RFC status and
ran through IDNITs again. ran through IDNITs again.
B.15. Changes to draft-ietf-lisp-rfc6833bis-10 B.16. Changes to draft-ietf-lisp-rfc6833bis-10
o Posted after LISP WG at IETF week March. o Posted after LISP WG at IETF week March.
o Move AD field encoding after S-bit in the ECM packet format o Move AD field encoding after S-bit in the ECM packet format
description section. description section.
o Say more about when the new Drop actions should be sent. o Say more about when the new Drop actions should be sent.
B.16. Changes to draft-ietf-lisp-rfc6833bis-09 B.17. Changes to draft-ietf-lisp-rfc6833bis-09
o Posted March IETF week 2018. o Posted March IETF week 2018.
o Fixed editorial comments submitted by document shepherd Luigi o Fixed editorial comments submitted by document shepherd Luigi
Iannone. Iannone.
B.17. Changes to draft-ietf-lisp-rfc6833bis-08 B.18. Changes to draft-ietf-lisp-rfc6833bis-08
o Posted March 2018. o Posted March 2018.
o Added RLOC-probing algorithm. o Added RLOC-probing algorithm.
o Added Solicit-Map Request algorithm. o Added Solicit-Map Request algorithm.
o Added several mechanisms (from 6830bis) regarding Routing Locator o Added several mechanisms (from 6830bis) regarding Routing Locator
Reachability. Reachability.
o Added port 4342 to IANA Considerations section. o Added port 4342 to IANA Considerations section.
B.18. Changes to draft-ietf-lisp-rfc6833bis-07 B.19. Changes to draft-ietf-lisp-rfc6833bis-07
o Posted December 2017. o Posted December 2017.
o Make it more clear in a couple of places that RLOCs are used to o Make it more clear in a couple of places that RLOCs are used to
locate ETRs more so than for Map-Server Map-Request forwarding. locate ETRs more so than for Map-Server Map-Request forwarding.
o Make it clear that "encapsualted" for a control message is an ECM o Make it clear that "encapsualted" for a control message is an ECM
based message. based message.
o Make it more clear what messages use source-port 4342 and which o Make it more clear what messages use source-port 4342 and which
skipping to change at page 59, line 19 skipping to change at page 59, line 37
Can use othe AFIs then IPv4 and IPv6. Can use othe AFIs then IPv4 and IPv6.
o Many editorial changes to clarify text. o Many editorial changes to clarify text.
o Changed some "must", "should", and "may" to capitalized. o Changed some "must", "should", and "may" to capitalized.
o Added definitions for Map-Request and Map-Reply messages. o Added definitions for Map-Request and Map-Reply messages.
o Ran document through IDNITs. o Ran document through IDNITs.
B.19. Changes to draft-ietf-lisp-rfc6833bis-06 B.20. Changes to draft-ietf-lisp-rfc6833bis-06
o Posted October 2017. o Posted October 2017.
o Spec the I-bit to include the xTR-ID in a Map-Request message to o Spec the I-bit to include the xTR-ID in a Map-Request message to
be consistent with the Map-Register message and to anticipate the be consistent with the Map-Register message and to anticipate the
introduction of pubsub functionality to allow Map-Requests to introduction of pubsub functionality to allow Map-Requests to
subscribe to RLOC-set changes. subscribe to RLOC-set changes.
o Updated references for individual submissions that became working o Updated references for individual submissions that became working
group documents. group documents.
o Updated references for working group documents that became RFCs. o Updated references for working group documents that became RFCs.
B.20. Changes to draft-ietf-lisp-rfc6833bis-05 B.21. Changes to draft-ietf-lisp-rfc6833bis-05
o Posted May 2017. o Posted May 2017.
o Update IANA Considerations section based on new requests from this o Update IANA Considerations section based on new requests from this
document and changes from what was requested in [RFC6830]. document and changes from what was requested in [RFC6830].
B.21. Changes to draft-ietf-lisp-rfc6833bis-04 B.22. Changes to draft-ietf-lisp-rfc6833bis-04
o Posted May 2017. o Posted May 2017.
o Clarify how the Key-ID field is used in Map-Register and Map- o Clarify how the Key-ID field is used in Map-Register and Map-
Notify messages. Break the 16-bit field into a 8-bit Key-ID field Notify messages. Break the 16-bit field into a 8-bit Key-ID field
and a 8-bit Algorithm-ID field. and a 8-bit Algorithm-ID field.
o Move the Control-Plane codepoints from the IANA Considerations o Move the Control-Plane codepoints from the IANA Considerations
section of RFC6830bis to the IANA Considerations section of this section of RFC6830bis to the IANA Considerations section of this
document. document.
o In the "LISP Control Packet Type Allocations" section, indicate o In the "LISP Control Packet Type Allocations" section, indicate
how message Types are IANA allocated and how experimental RFC8113 how message Types are IANA allocated and how experimental RFC8113
sub-types should be requested. sub-types should be requested.
B.22. Changes to draft-ietf-lisp-rfc6833bis-03 B.23. Changes to draft-ietf-lisp-rfc6833bis-03
o Posted April 2017. o Posted April 2017.
o Add types 9-14 and specify they are not assigned. o Add types 9-14 and specify they are not assigned.
o Add the "LISP Shared Extension Message" type and point to RFC8113. o Add the "LISP Shared Extension Message" type and point to RFC8113.
B.23. Changes to draft-ietf-lisp-rfc6833bis-02 B.24. Changes to draft-ietf-lisp-rfc6833bis-02
o Posted April 2017. o Posted April 2017.
o Clarify that the LISP Control-Plane document defines how the LISP o Clarify that the LISP Control-Plane document defines how the LISP
Data-Plane uses Map-Requests with either the SMR-bit set or the Data-Plane uses Map-Requests with either the SMR-bit set or the
P-bit set supporting mapping updates and RLOC-probing. Indicating P-bit set supporting mapping updates and RLOC-probing. Indicating
that other Data-Planes can use the same mechanisms or their own that other Data-Planes can use the same mechanisms or their own
defined mechanisms to achieve the same functionality. defined mechanisms to achieve the same functionality.
B.24. Changes to draft-ietf-lisp-rfc6833bis-01 B.25. Changes to draft-ietf-lisp-rfc6833bis-01
o Posted March 2017. o Posted March 2017.
o Include references to new RFCs published. o Include references to new RFCs published.
o Remove references to self. o Remove references to self.
o Change references from RFC6830 to RFC6830bis. o Change references from RFC6830 to RFC6830bis.
o Add two new action/reasons to a Map-Reply has posted to the LISP o Add two new action/reasons to a Map-Reply has posted to the LISP
WG mailing list. WG mailing list.
o In intro section, add refernece to I-D.ietf-lisp-introduction. o In intro section, add refernece to I-D.ietf-lisp-introduction.
o Removed Open Issues section and references to "experimental". o Removed Open Issues section and references to "experimental".
B.25. Changes to draft-ietf-lisp-rfc6833bis-00 B.26. Changes to draft-ietf-lisp-rfc6833bis-00
o Posted December 2016. o Posted December 2016.
o Created working group document from draft-farinacci-lisp o Created working group document from draft-farinacci-lisp
-rfc6833-00 individual submission. No other changes made. -rfc6833-00 individual submission. No other changes made.
B.26. Changes to draft-farinacci-lisp-rfc6833bis-00 B.27. Changes to draft-farinacci-lisp-rfc6833bis-00
o Posted November 2016. o Posted November 2016.
o This is the initial draft to turn RFC 6833 into RFC 6833bis. o This is the initial draft to turn RFC 6833 into RFC 6833bis.
o The document name has changed from the "Locator/ID Separation o The document name has changed from the "Locator/ID Separation
Protocol (LISP) Map-Server Interface" to the "Locator/ID Protocol (LISP) Map-Server Interface" to the "Locator/ID
Separation Protocol (LISP) Control-Plane". Separation Protocol (LISP) Control-Plane".
o The fundamental change was to move the Control-Plane messages from o The fundamental change was to move the Control-Plane messages from
skipping to change at page 61, line 40 skipping to change at page 62, line 7
o Removed open issue about additional state in Map-Servers. With o Removed open issue about additional state in Map-Servers. With
[RFC8111], Map-Servers have the same registration state and can [RFC8111], Map-Servers have the same registration state and can
give Map-Resolvers complete information in ms-ack Map-Referral give Map-Resolvers complete information in ms-ack Map-Referral
messages. messages.
o Make reference to the LISP Threats Analysis RFC [RFC7835]. o Make reference to the LISP Threats Analysis RFC [RFC7835].
Authors' Addresses Authors' Addresses
Vince Fuller Dino Farinacci
Cisco Systems lispers.net
EMail: vaf@vaf.net EMail: farinacci@gmail.com
Dino Farinacci Fabio Maino
Cisco Systems Cisco Systems
EMail: farinacci@gmail.com EMail: fmaino@cisco.com
Vince Fuller
vaf.net Internet Consulting
EMail: vaf@vaf.net
Albert Cabellos Albert Cabellos
UPC/BarcelonaTech UPC/BarcelonaTech
Campus Nord, C. Jordi Girona 1-3 Campus Nord, C. Jordi Girona 1-3
Barcelona, Catalunya Barcelona, Catalunya
Spain Spain
EMail: acabello@ac.upc.edu EMail: acabello@ac.upc.edu
 End of changes. 73 change blocks. 
213 lines changed or deleted 241 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/