draft-ietf-lisp-rfc6833bis-26.txt   draft-ietf-lisp-rfc6833bis-27.txt 
Network Working Group D. Farinacci Network Working Group D. Farinacci
Internet-Draft lispers.net Internet-Draft lispers.net
Obsoletes: 6830, 6833 (if approved) F. Maino Obsoletes: 6830, 6833 (if approved) F. Maino
Intended status: Standards Track Cisco Systems Intended status: Standards Track Cisco Systems
Expires: May 20, 2020 V. Fuller Expires: July 12, 2020 V. Fuller
vaf.net Internet Consulting vaf.net Internet Consulting
A. Cabellos (Ed.) A. Cabellos (Ed.)
UPC/BarcelonaTech UPC/BarcelonaTech
November 17, 2019 January 9, 2020
Locator/ID Separation Protocol (LISP) Control-Plane Locator/ID Separation Protocol (LISP) Control-Plane
draft-ietf-lisp-rfc6833bis-26 draft-ietf-lisp-rfc6833bis-27
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 types of Locator/ID Separation Protocol (LISP), implemented by two types of
LISP-speaking devices -- the LISP Map-Resolver and LISP Map-Server -- LISP-speaking devices -- the LISP Map-Resolver and LISP Map-Server --
that provides a simplified "front end" for one or more Endpoint ID to that provides a simplified "front end" for one or more Endpoint ID to
Routing Locator mapping databases. 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 2, line 4 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 May 20, 2020. This Internet-Draft will expire on July 12, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2020 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
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
skipping to change at page 14, line 23 skipping to change at page 14, line 23
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.
ITR-RLOC-AFI: This is the address family of the 'ITR-RLOC Address' ITR-RLOC-AFI: This is the address family of the 'ITR-RLOC Address'
field that follows this field. field that follows this field.
ITR-RLOC Address: This is used to give the ETR the option of ITR-RLOC Address: This is used to give the ETR the option of
selecting the destination address from any address family for the selecting the destination address from any address family for the
Map-Reply message. This address MUST be a routable RLOC address Map-Reply message. This address MUST be a routable RLOC address
of the sender of the Map-Request message. of the sender of the Map-Request message.
EID mask-len: This is the mask length for the EID-Prefix in decimal. EID mask-len: This is the mask length for the EID-Prefix.
EID-Prefix-AFI: This is the address family of the EID-Prefix EID-Prefix-AFI: This is the address family of the EID-Prefix
according to [AFI] and [RFC8060]. according to [AFI] and [RFC8060].
EID-Prefix: This prefix address length is 4 octets for an IPv4 EID-Prefix: This prefix address length is 4 octets for an IPv4
address family and 16 octets for an IPv6 address family when the address family and 16 octets for an IPv6 address family when the
EID-Prefix-AFI is 1 or 2, respectively. For other AFIs [AFI], the EID-Prefix-AFI is 1 or 2, respectively. For other AFIs [AFI], the
address length varies and for the LCAF AFI the format is defined address length varies and for the LCAF AFI the format is defined
in [RFC8060]. When a Map-Request is sent by an ITR because a data in [RFC8060]. When a Map-Request is sent by an ITR because a data
packet is received for a destination where there is no mapping packet is received for a destination where there is no mapping
skipping to change at page 18, line 32 skipping to change at page 18, line 32
Record TTL: This is the time in minutes the recipient of the Map- Record TTL: This is the time in minutes the recipient of the Map-
Reply can store the mapping. If the TTL is 0, the entry MUST be Reply can store the mapping. If the TTL is 0, the entry MUST be
removed from the cache immediately. If the value is 0xffffffff, removed from the cache immediately. If the value is 0xffffffff,
the recipient can decide locally how long to store the mapping. the recipient can decide locally how long to store the mapping.
Locator Count: This is the number of Locator entries in the given Locator Count: This is the number of Locator entries in the given
Record. A Locator entry comprises what is labeled above as 'Loc'. Record. A Locator entry comprises what is labeled above as 'Loc'.
The Locator count can be 0, indicating that there are no Locators The Locator count can be 0, indicating that there are no Locators
for the EID-Prefix. for the EID-Prefix.
EID mask-len: This is the mask length for the EID-Prefix in decimal. EID mask-len: This is the mask length for the EID-Prefix.
ACT: This 3-bit field describes Negative Map-Reply actions. In any ACT: This 3-bit field describes Negative Map-Reply actions. In any
other message type, these bits are set to 0 and ignored on other message type, these bits are set to 0 and ignored on
receipt. These bits are used only when the 'Locator Count' field receipt. These bits are used only when the 'Locator Count' field
is set to 0. The action bits are encoded only in Map-Reply is set to 0. The action bits are encoded only in Map-Reply
messages. They are used to tell an ITR or PITR why a empty messages. They are used to tell an ITR or PITR why a empty
locator-set was returned from the mapping system and how it stores locator-set was returned from the mapping system and how it stores
the map-cache entry. See Section 12.3 for additional information. the map-cache entry. See Section 12.3 for additional information.
(0) No-Action: The Map-Cache is kept alive, and no packet (0) No-Action: The Map-Cache is kept alive, and no packet
skipping to change at page 25, line 8 skipping to change at page 25, line 8
Type: 3 (Map-Register) Type: 3 (Map-Register)
P: This is the proxy Map-Reply bit. When set to 1, the ETR sending P: This is the proxy Map-Reply bit. When set to 1, the ETR sending
the Map-Register message is requesting the Map-Server to proxy a the Map-Register message is requesting the Map-Server to proxy a
Map-Reply. The Map-Server will send non-authoritative Map-Replies Map-Reply. The Map-Server will send non-authoritative Map-Replies
on behalf of the ETR. on behalf of the ETR.
S: This is the security-capable bit. When set, the procedures from S: This is the security-capable bit. When set, the procedures from
[I-D.ietf-lisp-sec] are supported. [I-D.ietf-lisp-sec] are supported.
I: This bit is set to 1 to indicate that a 128 bit xTR-ID and a 64 I: This is the ID-present bit. This bit is set to 1 to indicate that
bit Site-ID fields are present at the end of the Map-Register a 128 bit xTR-ID and a 64 bit Site-ID fields are present at the
message. If an xTR is configured with an xTR-ID and Site-ID, it end of the Map-Register message. If an xTR is configured with an
MUST set the I bit to 1 and include its xTR-ID and Site-ID in the xTR-ID and Site-ID, it MUST set the I bit to 1 and include its
Map-Register messages it generates. The combination of Site-ID xTR-ID and Site-ID in the Map-Register messages it generates. The
plus xTR-ID uniquely identifies an xTR in a LISP domain and serves combination of Site-ID plus xTR-ID uniquely identifies an xTR in a
to track its last seen nonce. LISP domain and serves to track its last seen nonce.
Reserved: This unassigned field MUST be set to 0 on transmit and Reserved: This unassigned field MUST be set to 0 on transmit and
MUST be ignored on receipt. MUST be ignored on receipt.
E: This is the Map-Register EID-notify bit. This is used by a First- E: This is the Map-Register EID-notify bit. This is used by a First-
Hop-Router (FHR) which discovers a dynamic-EID. This EID-notify Hop-Router (FHR) which discovers a dynamic-EID. This EID-notify
based Map-Register is sent by the FHR to the same site xTR that based Map-Register is sent by the FHR to the same site xTR that
propogates the Map-Register to the mapping system. The site xTR propogates the Map-Register to the mapping system. The site xTR
keeps state to later Map-Notify the FHR after the EID has moves keeps state to later Map-Notify the FHR after the EID has moves
away. See [I-D.ietf-lisp-eid-mobility] for a detailed use-case. away. See [I-D.ietf-lisp-eid-mobility] for a detailed use-case.
skipping to change at page 26, line 42 skipping to change at page 26, line 42
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 placed Authentication Data: This is the output of the MAC algorithm placed
in this field after the MAC computation. The MAC output is in this field after the MAC computation. The MAC output is
computed as follows: computed as follows:
1: The KDF algorithm is identified by the field 'Algorithm ID' 1: The KDF algorithm is identified by the field 'Algorithm ID'
according to the table in Section 12.5. Implementations of according to the table in Section 12.5. Implementations of
this specification SHOULD include support for HMAC-SHA256- this specification MUST implement HMAC-SHA-256-128 and SHOULD
128+HKDF-SHA256 [RFC4868]. implement HMAC-SHA256-128+HKDF-SHA256 [RFC4868].
2: The MAC algorithm is identified by the field 'Algorithm ID' 2: The MAC algorithm is identified by the field 'Algorithm ID'
according to the table in Section 12.5. according to the table in Section 12.5.
3: The pre-shared secret used to derive the per-message key is 3: The pre-shared secret used to derive the per-message key is
represented by PSK[Key ID], that is the pre-shared secret represented by PSK[Key ID], that is the pre-shared secret
identified by the 'Key ID'. identified by the 'Key ID'.
4: The derived per-message key is computed as: per-msg- 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 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 the Nonce field of the Map-Register and 's' is a string equal
to "Map-Register Authentication". to "Map-Register Authentication". For those Algorithm IDs
defined in section Section 12.5 that specify a 'none' KDF, the
per-message key is computed as: per-msg-key = PSK[Key ID].
This means that the same key is used across multiple protocol
messages.
5: The MAC output is computed using the MAC algorithm and the 5: The MAC output is computed using the MAC algorithm and the
per-msg-key over the entire Map-Register payload (from and per-msg-key over the entire Map-Register payload (from and
including the LISP message type field through the end of the including the LISP message type field through the end of the
last RLOC record) with the authenticated data field preset to last RLOC record) with the authenticated data field preset to
0. 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 the Map-Register message: following fields are added to the end of the Map-Register message:
skipping to change at page 29, line 15 skipping to change at page 29, line 15
specified in [I-D.ietf-lisp-pubsub]. specified in [I-D.ietf-lisp-pubsub].
After sending a Map-Register, if a Map-Notify is not received after 1 After sending a Map-Register, if a Map-Notify is not received after 1
second the transmitter MUST re-transmit the original Map-Register second the transmitter MUST re-transmit the original Map-Register
with an exponential backoff (base of 2, that is, the next backoff with an exponential backoff (base of 2, that is, the next backoff
timeout interval is doubled), the maximum backoff is 1 minute. timeout interval is doubled), 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 and message. It is used to acknowledge the receipt of a Map-Notify and
for the sender to stop retransmitting a Map-Notify with the same for the sender to stop retransmitting a Map-Notify with the same
nonce. The fields of the Map-Notify-Ack are copied from the nonce and the authentication data validates. The fields of the Map-
corresponding Map-Notify message to acknowledge its correct Notify-Ack are copied from the corresponding Map-Notify message to
processing. The 'Authentication Data' field is recomputed according acknowledge its correct processing. The 'Authentication Data' field
to the procedure defined in the previous section. is recomputed according to the procedure defined in the previous
section.
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) in only
Congestion Control And Relability Guideline sections of [RFC8085]. A conformance the Congestion Control And Relability Guideline sections
Map-Notify is retransmitted until a Map-Notify-Ack is received by the of [RFC8085]. A Map-Notify is retransmitted until a Map-Notify-Ack
Map-Server with the same nonce used in the Map-Notify message. If a is received by the Map-Server with the same nonce used in the Map-
Map-Notify-Ack is never received by the Map-Server, it issues a log Notify message. If a Map-Notify-Ack is never received by the Map-
message. An implementation SHOULD retransmit up to 3 times at 3 Server, it issues a log message. An implementation SHOULD retransmit
second retransmission intervals, after which time the retransmission up to 3 times at 3 second retransmission intervals, after which time
interval is exponentially backed-off (base of 2, that is, the next the retransmission interval is exponentially backed-off (base of 2,
backoff timeout interval is doubled) for another 3 retransmission that is, the next backoff timeout interval is doubled) for another 3
attempts. retransmission attempts.
Upon reception of Map-Register, Map-Notify or Map-Notifiy-Ack, the Upon reception of Map-Register, Map-Notify or Map-Notifiy-Ack, the
receiver verifies the authentication data. receiver verifies the authentication data.
5.8. Encapsulated Control Message Format 5.8. Encapsulated Control Message Format
An Encapsulated Control Message (ECM) is used to encapsulate control An Encapsulated Control Message (ECM) is used to encapsulate control
packets sent between xTRs and the mapping database system. packets sent between xTRs and the mapping database system or internal
to the mapping database system.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | IPv4 or IPv6 Header | / | IPv4 or IPv6 Header |
OH | (uses RLOC addresses) | OH | (uses RLOC addresses) |
\ | | \ | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | Source Port = xxxx | Dest Port = 4342 | / | Source Port = xxxx | Dest Port = 4342 |
UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ | UDP Length | UDP Checksum | \ | UDP Length | UDP Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
LISP |Type=8 |S|D|E|M| Reserved | LISP |Type=8 |S|D|R|R| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | IPv4 or IPv6 Header | / | IPv4 or IPv6 Header |
IH | (uses RLOC or EID addresses) | IH | (uses RLOC or EID addresses) |
\ | | \ | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | Source Port = xxxx | Dest Port = yyyy | / | Source Port = xxxx | Dest Port = yyyy |
UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ | UDP Length | UDP Checksum | \ | UDP Length | UDP Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
LCM | LISP Control Message | LCM | LISP Control Message |
skipping to change at page 31, line 15 skipping to change at page 31, line 15
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AD Type | Authentication Data Content . . . | | AD Type | Authentication Data Content . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
D: This is the DDT-bit. When set to 1, the sender is requesting a D: This is the DDT-bit. When set to 1, the sender is requesting a
Map-Referral message to be returned. The details of this Map-Referral message to be returned. The details of this
procedure are described in [RFC8111]. procedure are described in [RFC8111].
E: This is the to-ETR bit. When set to 1, the Map-Server's R: This reserved and unassigned bit MUST be set to 0 on transmit
intention is to forward the ECM to an authoritative ETR. and MUST be ignored on receipt.
M: This is the to-MS bit. When set to 1, a Map-Request is being
sent to a co-located Map-Resolver and Map-Server where the
message can be processed directly by the Map-Server versus the
Map-Resolver using the LISP-DDT procedures in [RFC8111].
IH: The inner IPv4 or IPv6 header, which can use either RLOC or EID IH: The inner IPv4 or IPv6 header, which can use either RLOC or EID
addresses in the header address fields. When a Map-Request is addresses in the header address fields. When a Map-Request is
encapsulated in this packet format, the destination address in encapsulated in this packet format, the destination address in
this header is an EID. this header is an EID.
UDP: The inner UDP header, where the port assignments depend on the UDP: The inner UDP header, where the port assignments depend on the
control packet being encapsulated. When the control packet is control packet being encapsulated. When the control packet is
a Map-Request or Map-Register, the source port is selected by a Map-Request or Map-Register, the source port is selected by
the ITR/PITR and the destination port is 4342. When the the ITR/PITR and the destination port is 4342. When the
skipping to change at page 32, line 43 skipping to change at page 32, line 43
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 SMR responder MUST rate-limit these Both the SMR sender and the SMR responder MUST rate-limit these
messages. It is RECOMMENDED that the SMR sender rate-limits Map- messages. It is RECOMMENDED that the SMR sender rate-limits Map-
Request for the same destination RLOC to no more than one packet per 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- 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. Request for the same EID-Prefix to no more than once per 3 seconds.
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
sender of an SMR-based Map-Request MUST be verified. If an ITR sender of an SMR message MUST be verified. If an ITR receives an SMR
receives an SMR-based Map-Request and the source is not in the message and the source is not in the Locator-Set for the stored Map-
Locator-Set for the stored Map-Cache entry, then the responding Map- Cache entry, then the responding Map-Request MUST be sent with an EID
Request MUST be sent with an EID destination to the mapping database destination to the mapping database system. Since the mapping
system. Since the mapping database system is a more secure way to database system is a more secure way to reach an authoritative ETR,
reach an authoritative ETR, it will deliver the Map-Request to the it will deliver the Map-Request to the authoritative source of the
authoritative source of the mapping data. Please note that this mapping data. Please note that this procedure does not result in
procedure does not result in cryptographic or strongly authenticated cryptographic or strongly authenticated verification.
verification.
When an ITR receives an SMR-based Map-Request for which it does not When an ITR receives an SMR-based Map-Request for which it does not
have a cached mapping for the EID in the SMR message, it SHOULD NOT have a cached mapping for the EID in the SMR message, it SHOULD NOT
send an SMR-invoked Map-Request. This scenario can occur when an ETR send an SMR-invoked Map-Request. This scenario can occur when an ETR
sends SMR messages to all Locators in the Locator-Set it has stored sends SMR messages to all Locators in the Locator-Set it has stored
in its Map-Cache but the remote ITRs that receive the SMR may not be in its Map-Cache but the remote ITRs that receive the SMR may not be
sending packets to the site. There is no point in updating the ITRs sending packets to the site. There is no point in updating the ITRs
until they need to send, in which case they will send Map-Requests to until they need to send, in which case they will send Map-Requests to
obtain a Map-Cache entry. obtain a Map-Cache entry.
skipping to change at page 40, line 44 skipping to change at page 40, line 44
limiters. limiters.
The Map-Request/Map-Reply message exchange to inject forged mappings 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, protection, and prevention of 'man-in-the-middle' and
middle' and 'prefix overclaiming' attacks on the Map-Request/Map- 'prefix overclaiming' attacks on the Map-Request/Map-Reply exchange.
Reply exchange. In addition and while beyond the scope of securing In addition and while beyond the scope of securing an individual Map-
an individual Map-Server or Map-Resolver, it should be noted that Server or Map-Resolver, it should be noted that LISP-SEC can be
LISP-SEC can be complemented by additional security mechanisms complemented by additional security mechanisms defined by the Mapping
defined by the Mapping System Infrastructure. For instance, BGP- System Infrastructure. For instance, BGP-based LISP-ALT [RFC6836]
based LISP-ALT [RFC6836] can take advantage of standards work on can take advantage of standards work on adding security to BGP while
adding security to BGP while LISP-DDT [RFC8111] defines its own 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 key derived from the pre- that is a MAC of the entire message using a key derived from the pre-
shared secret. An implementation MUST support HMAC-SHA256-128+HKDF- shared secret. An implementation MUST support HMAC-SHA256-128+HKDF-
SHA256 [RFC4868]. The Map-Register message includes protection for SHA256 [RFC4868]. The Map-Register message includes protection for
replay attacks by a man-in-the-middle. However, a compromised ETR replay attacks by a man-in-the-middle. However, a compromised ETR
can overclaim the prefix it owns and successfully register it on its can overclaim the prefix it owns and successfully register it on its
corresponding Map-Server. To mitigate this and as noted in corresponding Map-Server. To mitigate this and as noted in
Section 8.2, a Map-Server MUST verify that all EID-Prefixes Section 8.2, a Map-Server MUST verify that all EID-Prefixes
skipping to change at page 48, line 33 skipping to change at page 48, line 33
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-04 (work in progress), August 2019. lisp-6834bis-04 (work in progress), August 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-27 (work in progress), (LISP)", draft-ietf-lisp-rfc6830bis-28 (work in progress),
June 2019. November 2019.
[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-19 Saucez, "LISP-Security (LISP-SEC)", draft-ietf-lisp-sec-19
skipping to change at page 50, line 18 skipping to change at page 50, line 18
auth-02 (work in progress), September 2019. auth-02 (work in progress), September 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-07 (work in EID Anonymity", draft-ietf-lisp-eid-anonymity-07 (work in
progress), October 2019. progress), October 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-04 Unified Control Plane", draft-ietf-lisp-eid-mobility-05
(work in progress), May 2019. (work in progress), November 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-09 (work in progress), October 2019. gpe-14 (work in progress), January 2020.
[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-06 (work in progress), Mobile Node", draft-ietf-lisp-mn-06 (work in progress),
skipping to change at page 50, line 46 skipping to change at page 50, line 46
[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-04 (work in progress), September 2019. pubsub-04 (work in progress), September 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-08 (work Extension for VXLAN", draft-ietf-nvo3-vxlan-gpe-09 (work
in progress), October 2019. in progress), December 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.
 End of changes. 21 change blocks. 
65 lines changed or deleted 64 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/