idnits 2.17.1 draft-farinacci-lisp-decent-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 5 characters in excess of 72. == There are 16 instances of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 221: '... An ITR SHOULD lookup its peer-group...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 2, 2018) is 2125 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 6830 (Obsoleted by RFC 9300, RFC 9301) ** Obsolete normative reference: RFC 6833 (Obsoleted by RFC 9301) == Outdated reference: A later version (-03) exists of draft-farinacci-lisp-ecdsa-auth-02 == Outdated reference: A later version (-31) exists of draft-ietf-lisp-rfc6833bis-10 == Outdated reference: A later version (-29) exists of draft-ietf-lisp-sec-15 Summary: 4 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Farinacci 3 Internet-Draft lispers.net 4 Intended status: Experimental C. Cantrell 5 Expires: January 3, 2019 Nexus 6 July 2, 2018 8 A Decent LISP Mapping System (LISP-Decent) 9 draft-farinacci-lisp-decent-01 11 Abstract 13 This draft describes how the LISP mapping system designed to be 14 distributed for scale can also be decentralized for management and 15 trust. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at https://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on January 3, 2019. 34 Copyright Notice 36 Copyright (c) 2018 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (https://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 2 53 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 4. Components of a LISP-Decent xTR . . . . . . . . . . . . . . . 5 55 5. No LISP Protocol Changes . . . . . . . . . . . . . . . . . . 6 56 6. Configuration and Authentication . . . . . . . . . . . . . . 6 57 7. Core Peer-Group . . . . . . . . . . . . . . . . . . . . . . . 6 58 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 59 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 60 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 61 10.1. Normative References . . . . . . . . . . . . . . . . . . 8 62 10.2. Informative References . . . . . . . . . . . . . . . . . 9 63 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 10 64 Appendix B. Document Change Log . . . . . . . . . . . . . . . . 10 65 B.1. Changes to draft-farinacci-lisp-decent-01 . . . . . . . . 10 66 B.2. Changes to draft-farinacci-lisp-decent-00 . . . . . . . . 10 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 69 1. Introduction 71 The LISP architecture and protocols [RFC6830] introduces two new 72 numbering spaces, Endpoint Identifiers (EIDs) and Routing Locators 73 (RLOCs) which is intended to provide overlay network functionality. 74 To map from EID to a set or RLOCs, a control-plane mapping system are 75 used [RFC6836] [RFC8111]. These mapping systems are distributed in 76 nature in their deployment for scalability but are centrally managed 77 by a third- party entity, namely a Mapping System Provider (MSP). 78 The entities that use the mapping system, such as data-plane xTRs, 79 depend on and trust the MSP. They do not participate in the mapping 80 system other than to register and retrieve information to/from the 81 mapping system [RFC6833]. 83 This document introduces a Decentralized Mapping System (DMS) so the 84 xTRs can participate in the mapping system as well as use it. They 85 can trust each other rather than rely on third-party infrastructure. 86 The xTRs act as Map-Servers to maintain distributed state for scale 87 and reducing attack surface. 89 2. Definition of Terms 91 Decentralized Mapping System (DMS): is a mapping system entity that 92 is not third-party to the xTR nodes that use it. The xTRs 93 themselves are part of the mapping system. The state of the 94 mapping system is fully distributed, decentralized, and the trust 95 relies on the xTRs that use and participate in their own mapping 96 system. 98 Mapping System Provider (MSP): is an infrastructure service that 99 deploys LISP Map-Resolvers and Map-Servers [RFC6833] and possibly 100 ALT-nodes [RFC6836] or DDT-nodes [RFC8111]. The MSP can be 101 managed by a separate organization other than the one that manages 102 xTRs. This model provides a business separation between who 103 manages and is responsible for the control-plane versus who 104 manages the data-plane overlay service. 106 Peer-Group: is a set of Map-Servers which are joined to the same 107 multicast group that send and receive Map-Register messages 108 addressed to the multicast group. Map-Resolvers can use the peer- 109 group to resolve mappings by sending Map-Requests to the multicast 110 group or to any member of the peer-group. Map-Resolvers can do a 111 mapping system lookup for the peer-group multicast address to 112 obtain members of the peer-group. 114 Core Peer-Group: is a set of Map-Servers and Map-Resolvers who are 115 joined to a multicast group to bootstrap a multi-layer 116 decentralized mapping system. 118 Replication List Entry (RLE): is an RLOC-record format that contains 119 a list of RLOCs that an ITR replicates multicast packets on a 120 multicast overlay. The RLE format is specified in [RFC8060]. 122 Group Address EID: is an EID-record format that contains IPv4 123 (0.0.0.0/0, G) or IPv6 (0::/0, G) state. This state is encoded as 124 a Multicast Info Type LCAF specified in [RFC8060]. Members of a 125 peer-group send Map-Registers for (0.0.0.0/0, G) or (0::/0, G) 126 with an RLOC-record that RLE encodes its RLOC address. Details 127 are specified in [I-D.ietf-lisp-signal-free-multicast]. 129 3. Overview 131 The clients of the Decentralized Mapping System (DMS) are also the 132 providers of mapping state. Clients are typically ETRs that Map- 133 Register EID-to-RLOC mapping state to the mapping database system. 134 ITRs are clients in that they send Map-Requests to the mapping 135 database system to obtain EID-to-RLOC mappings that are cached for 136 data-plane use. When xTRs participate in a DMS, they are also acting 137 as Map-Resolvers and Map-Servers using the protocol machinery defined 138 in LISP control-plane specifications [RFC6833], [I-D.ietf-lisp-sec], 139 and [I-D.farinacci-lisp-ecdsa-auth]. The xTRs are not required to 140 run the database mapping transport system protocols specified in 141 [RFC6836] or [RFC8111]. 143 The xTRs are organized in a peer-group. The peer-group is identified 144 by an IPv4 or IPv6 multicast group address. The xTRs join the same 145 multicast group and receive LISP control-plane messages addressed to 146 the group. Messages sent to the multicast group are distributed when 147 the underlay network supports IP multicast [RFC6831] or is achieved 148 with the overlay multicast mechanism described in 149 [I-D.ietf-lisp-signal-free-multicast]. When overlay multicast is 150 used and LISP Map-Register messages are sent to a peer-group, they 151 are LISP data encapsulated with a instance-ID set to 0xffffff in the 152 LISP header. The inner header of the encapsulated packet has the 153 destination address set to the peer-group multicast group address and 154 the outer header that is prepended has the destination address set to 155 the RLOC of peer-group member. The members of the peer-group are 156 kept in the LISP data-plane map-cache so packets for the peer-group 157 can be replicated to each member RLOC. 159 All xTRs in a peer-group will store the same registered mappings and 160 maintain the state as Map-Servers normally do. The peer-group 161 members are not only receivers of the multicast group but also send 162 packets to the group. 164 4. Components of a LISP-Decent xTR 166 When an xTR is configured to be a LISP-Decent xTR (or PxTR 167 [RFC6832]), it runs the ITR, ETR, Map-Resolver, and Map-Server LISP 168 network functions. 170 The following diagram shows 3 LISP-Decent xTRs joined to peer-group 171 224.1.1.1. When the ETR function of xTR1 originates a Map-Register, 172 it is sent to all xTRs (including itself) synchronizing all 3 Map- 173 Servers in xTR1, xTR2, and xTR3. The ITR function can populate its 174 map-cache by sending a Map-Request locally to its Map-Resolver so it 175 can replicate packets to each RLOC for EID 224.1.1.1. 177 xTR1 178 Map-Request +--------------------+ 179 (always local) | +-----+ +-----+ | 180 +---------------| ITR | | ETR |-------------+ 181 | | +-----+ +-----+ | | 182 | | | | Map-Register to EID 183 | | +-------+ | | 224.1.1.1 encapsulated to 184 +------------------>| MR/MS |<---------------+ RLOCs xTR1, xTR2, and xTR3 185 | +-------+ | | 186 +--------------------+ | 187 | 188 +--------------------+------------+ 189 | | 190 | | 191 +----------v---------+ +----------v---------+ 192 | +--------+ | | +--------+ | 193 | | MR/MS | | | | MR/MS | | 194 | +--------+ | | +--------+ | 195 | +-----+ +-----+ | | +-----+ +-----+ | 196 | | ITR | | ETR | | | | ITR | | ETR | | 197 | +-----+ +-----+ | | +-----+ +-----+ | 198 +--------------------+ +--------------------+ 199 xTR2 xTR3 201 Note if any external xTR would like to use a Map-Resolver from the 202 peer-group, it only needs to have one of the LISP-Decent Map- 203 Resolvers configured. By doing a looking to this Map-Resolver for 204 EID 224.1.1,1, the external xTR could get the complete list of 205 members for the peer-group. 207 For future study, an external xTR could multicast the Map-Request to 208 224.1.1.1 and either one of the LISP-Decent Map-Resolvers would 209 return a Map-Reply or the external xTR is prepared to receive 210 multiple Map-Replies. 212 5. No LISP Protocol Changes 214 There are no LISP protocol changes required to support this LISP- 215 Decent specification. However, an implementation that sends Map- 216 Register messages to a multicast group versus a specific Map-Server 217 unicast address must change to call the data-plane component so the 218 ITR functionality in the node can encapsulate the Map-Register as a 219 unicast packet to each member of the peer-group. 221 An ITR SHOULD lookup its peer-group address periodically to determine 222 if the membership has changed. The ITR can also use the pubsub 223 capability documented in [I-D.rodrigueznatal-lisp-pubsub] to be 224 notified when a new member joins or leaves the peer-group. 226 6. Configuration and Authentication 228 When xTRs are joined to a multicast peer-group, they must have their 229 site registration configuration consistent. Any policy or 230 authentication key material must be configured correctly and 231 consistently among all members. When [I-D.farinacci-lisp-ecdsa-auth] 232 is used to sign Map-Register messages, public-keys can be registered 233 to the peer-group using the site authentication key mentioned above 234 or using a different authentication key from the one used for 235 registering EID records. 237 7. Core Peer-Group 239 A core peer-group multicast address can be preconfigured to bootstrap 240 the decentralized mapping system. The group address (or DNS name 241 that maps to a group address) can be explicitly configured in a few 242 xTRs to start building up the mappings. Then as other xTRs come 243 online, they can add themselves to the core peer-group by joining the 244 peer-group multicast group. 246 Alternatively or additionally, new xTRs can join a new peer-group 247 multicast group to form another layer of a decentralized mapping 248 system. The group address and members of this new layer peer-group 249 would be registered to the core peer-group address and stored in the 250 core peer-group mapping system. Note each mapping system layer could 251 have a specific function or a specific circle of trust. 253 This multi-layer mapping system can be illustrated: 255 __________ --------- 256 / core \ 224.2.2.2 / layer-1 \ 257 | peer-group | --------> | I | 258 | 224.1.1.1 | | / \ | 259 \__________/ | J---K | 260 | \_________/ 261 | 224.3.3.3 262 | 263 v 264 --------- 265 / layer-2 \ 266 | X | 267 | / \ | 268 | Y---Z | 269 \_________/ 271 Configured in xTRs A, B, and C (they make up the core peer-group): 272 224.1.1.1 -> RLE: A, B, C 274 core peer-group DMS, mapping state in A, B, and C: 275 224.2.2.2 -> RLE: I, J, K 276 224.3.3.3 -> RLE: X, Y, Z 278 layer-1 peer-group DMS (inter-continental), mapping state in I, J, K: 279 EID1 -> RLOCs: i(1), j(2) 280 ... 281 EIDn -> RLOCs: i(n), j(n) 283 layer-2 peer-group DMS (intra-continental), mapping sate in X, Y, Z:: 284 EIDa -> RLOCs: x(1), y(2) 285 ... 286 EIDz -> RLOCs: x(n), y(n) 288 The core peer-group multicast address 224.1.1.1 is configured in xTRs 289 A, B and C so when each of them send Map-Register messages, they 290 would all be able to maintain synchronized mapping state. Any EID 291 can be registered to this DMS but in this example, peer-group 292 multicast group EIDs are being registered only to find other peer- 293 groups. 295 For example, lets say that xTR I boots up and it wants to find its 296 other peers in its peer-group 224.2.2.2. Group address 224.2.2.2 is 297 configured so xTR I knows what group to join for its peer-group. But 298 xTR I needs a mapping system to register to, so the core peer-group 299 is used and available to receive Map-Registers. The other xTRs J and 300 K in the peer-group do the same so when any of I, J or K needs to 301 register EIDs, they can now send their Map-Register messages to group 302 224.2.2.2. Examples of EIDs being register are EID1 through EIDn 303 shown above. 305 When Map-Registers are sent to group 224.2.2.2, they are encapsulated 306 by the LISP data-plane by looking up EID 224.2.2.2 in the core peer- 307 group mapping system. For the map-cache entry to be populated for 308 224.2.2.2, the data-plane must send a Map-Request so the RLOCs I, J, 309 and K are cached for replication. To use the core peer-group mapping 310 system, the data-plane must know of at least one of the RLOCs A, B, 311 and/or C. 313 8. Security Considerations 315 Refer to the Security Considerations section of 316 [I-D.ietf-lisp-rfc6833bis] for a complete list of security mechanisms 317 as well as pointers to threat analysis drafts. 319 9. IANA Considerations 321 At this time there are no specific requests for IANA. 323 10. References 325 10.1. Normative References 327 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 328 Locator/ID Separation Protocol (LISP)", RFC 6830, 329 DOI 10.17487/RFC6830, January 2013, 330 . 332 [RFC6831] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, "The 333 Locator/ID Separation Protocol (LISP) for Multicast 334 Environments", RFC 6831, DOI 10.17487/RFC6831, January 335 2013, . 337 [RFC6832] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller, 338 "Interworking between Locator/ID Separation Protocol 339 (LISP) and Non-LISP Sites", RFC 6832, 340 DOI 10.17487/RFC6832, January 2013, 341 . 343 [RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation 344 Protocol (LISP) Map-Server Interface", RFC 6833, 345 DOI 10.17487/RFC6833, January 2013, 346 . 348 [RFC6836] Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, 349 "Locator/ID Separation Protocol Alternative Logical 350 Topology (LISP+ALT)", RFC 6836, DOI 10.17487/RFC6836, 351 January 2013, . 353 [RFC8060] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical 354 Address Format (LCAF)", RFC 8060, DOI 10.17487/RFC8060, 355 February 2017, . 357 [RFC8111] Fuller, V., Lewis, D., Ermagan, V., Jain, A., and A. 358 Smirnov, "Locator/ID Separation Protocol Delegated 359 Database Tree (LISP-DDT)", RFC 8111, DOI 10.17487/RFC8111, 360 May 2017, . 362 10.2. Informative References 364 [I-D.farinacci-lisp-ecdsa-auth] 365 Farinacci, D. and E. Nordmark, "LISP Control-Plane ECDSA 366 Authentication and Authorization", draft-farinacci-lisp- 367 ecdsa-auth-02 (work in progress), April 2018. 369 [I-D.ietf-lisp-rfc6833bis] 370 Fuller, V., Farinacci, D., and A. Cabellos-Aparicio, 371 "Locator/ID Separation Protocol (LISP) Control-Plane", 372 draft-ietf-lisp-rfc6833bis-10 (work in progress), March 373 2018. 375 [I-D.ietf-lisp-sec] 376 Maino, F., Ermagan, V., Cabellos-Aparicio, A., and D. 377 Saucez, "LISP-Security (LISP-SEC)", draft-ietf-lisp-sec-15 378 (work in progress), April 2018. 380 [I-D.ietf-lisp-signal-free-multicast] 381 Moreno, V. and D. Farinacci, "Signal-Free LISP Multicast", 382 draft-ietf-lisp-signal-free-multicast-09 (work in 383 progress), March 2018. 385 [I-D.rodrigueznatal-lisp-pubsub] 386 Rodriguez-Natal, A., Ermagan, V., Leong, J., Maino, F., 387 Cabellos-Aparicio, A., Barkai, S., Farinacci, D., 388 Boucadair, M., Jacquenet, C., and S. Secci, "Publish/ 389 Subscribe Functionality for LISP", draft-rodrigueznatal- 390 lisp-pubsub-02 (work in progress), March 2018. 392 Appendix A. Acknowledgments 394 The authors would like to thank the LISP WG for their review and 395 acceptance of this draft. 397 The authors would also like to give a special thanks to Roman 398 Shaposhnik for several discussions that occured before the first 399 draft was published. 401 Appendix B. Document Change Log 403 [RFC Editor: Please delete this section on publication as RFC.] 405 B.1. Changes to draft-farinacci-lisp-decent-01 407 o Posted July 2018. 409 o Document timer and reference update. 411 B.2. Changes to draft-farinacci-lisp-decent-00 413 o Initial draft posted January 2018. 415 Authors' Addresses 417 Dino Farinacci 418 lispers.net 419 San Jose, CA 420 USA 422 Email: farinacci@gmail.com 424 Colin Cantrell 425 Nexus 426 Scottsdale, AZ 427 USA 429 Email: colin@nexus.io