idnits 2.17.1 draft-ermagan-lisp-nat-traversal-18.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 23 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 10 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. ** 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 375: '... nonce SHOULD be generated by a p...' RFC 2119 keyword, line 441: '...n xTR-ID or site-ID, it MUST set the I...' RFC 2119 keyword, line 455: '...-zero value), it MUST copy the XTR-ID ...' RFC 2119 keyword, line 496: '...). A Map-Server MUST set the I bit in...' RFC 2119 keyword, line 543: '...ementations of this specification MUST...' (4 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 2, 2020) is 1265 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'RFC2404' is mentioned on line 544, but not defined == Missing Reference: 'RFC6234' is mentioned on line 545, but not defined == Outdated reference: A later version (-13) exists of draft-ietf-lisp-eid-mobility-06 == Outdated reference: A later version (-15) exists of draft-ietf-lisp-pubsub-06 == Outdated reference: A later version (-38) exists of draft-ietf-lisp-rfc6830bis-35 == Outdated reference: A later version (-31) exists of draft-ietf-lisp-rfc6833bis-29 ** Obsolete normative reference: RFC 5245 (ref. 'ICE') (Obsoleted by RFC 8445, RFC 8839) ** Obsolete normative reference: RFC 5389 (ref. 'STUN') (Obsoleted by RFC 8489) ** Obsolete normative reference: RFC 5766 (ref. 'TURN') (Obsoleted by RFC 8656) Summary: 4 errors (**), 0 flaws (~~), 9 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group V. Ermagan 3 Internet-Draft Google 4 Intended status: Experimental D. Farinacci 5 Expires: May 6, 2021 lispers.net 6 D. Lewis 7 F. Maino 8 M. Portoles 9 Cisco Systems, Inc. 10 J. Skriver 11 Arista 12 C. White 13 Logicalelegance, Inc. 14 A. Lopez 15 A. Cabellos 16 UPC/BarcelonaTech 17 November 2, 2020 19 NAT traversal for LISP 20 draft-ermagan-lisp-nat-traversal-18 22 Abstract 24 This document describes a mechanism for IPv4 NAT traversal for LISP 25 tunnel routers (xTR) and LISP Mobile Nodes (LISP-MN) behind a NAT 26 device. A LISP device both detects the NAT and initializes its 27 state. Forwarding to the LISP device through a NAT is enabled by the 28 LISP Re-encapsulating Tunnel Router (RTR) network element, which acts 29 as an anchor point in the data plane, forwarding traffic from 30 unmodified LISP devices through the NAT. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at https://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on May 6, 2021. 49 Copyright Notice 51 Copyright (c) 2020 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (https://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 67 2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 3 68 3. Basic Overview . . . . . . . . . . . . . . . . . . . . . . . 5 69 3.1. LISP NAT Traversal Overview . . . . . . . . . . . . . . . 6 70 4. LISP RTR Message Details . . . . . . . . . . . . . . . . . . 7 71 4.1. Info-Request Message . . . . . . . . . . . . . . . . . . 7 72 4.2. LISP Info-Reply . . . . . . . . . . . . . . . . . . . . . 9 73 4.3. LISP Map-Register Message . . . . . . . . . . . . . . . . 11 74 4.4. LISP Map-Notify . . . . . . . . . . . . . . . . . . . . . 12 75 4.5. LISP Data-Map-Notify Message . . . . . . . . . . . . . . 13 76 5. Protocol Operations . . . . . . . . . . . . . . . . . . . . . 15 77 5.1. xTR Processing . . . . . . . . . . . . . . . . . . . . . 15 78 5.1.1. ETR Registration . . . . . . . . . . . . . . . . . . 16 79 5.1.2. Map-Request and Map-Reply Handling . . . . . . . . . 17 80 5.1.3. xTR Sending and Receiving Data . . . . . . . . . . . 18 81 5.2. Map-Server Processing . . . . . . . . . . . . . . . . . . 18 82 5.3. RTR Processing . . . . . . . . . . . . . . . . . . . . . 19 83 5.3.1. RTR Data Forwarding . . . . . . . . . . . . . . . . . 21 84 5.4. Multi-homed xTRs . . . . . . . . . . . . . . . . . . . . 22 85 5.5. Updating contents of EID-to-RLOC Mappings . . . . . . . . 23 86 5.6. Example . . . . . . . . . . . . . . . . . . . . . . . . . 24 87 6. Security Considerations . . . . . . . . . . . . . . . . . . . 27 88 6.1. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 27 89 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 90 8. Normative References . . . . . . . . . . . . . . . . . . . . 27 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 93 1. Introduction 95 The Locator/ID Separation Protocol [I-D.ietf-lisp-rfc6830bis] 96 [I-D.ietf-lisp-rfc6833bis]defines a set of functions for 97 encapsulating routers to exchange information used to map from 98 Endpoint Identifiers (EIDs) to routable Routing Locators (RLOCs). 99 The assumption that the LISP Tunnel Routers are reachable at their 100 RLOC breaks when a LISP device is behind a NAT. LISP relies on the 101 xTR being able to receive traffic at its RLOC on destination port 102 4341. However nodes behind a NAT are only reachable through the 103 NAT's public address and in most cases only after the appropriate 104 mapping state is set up in the NAT. Depending on the type of the NAT 105 device, this mapping state may be address and port dependent. In 106 other words, the mapping state in the NAT device may be associated 107 with the 5 tuple that forms a specific flow, preventing incoming 108 traffic from any LISP router other than the one associated with the 5 109 tuple. A NAT traversal mechanism is needed to make the LISP device 110 behind a NAT reachable. 112 This document briefly discusses available NAT traversal options, and 113 then it introduces in detail a NAT traversal mechanism for LISP. Two 114 new LISP control messages - LISP Info-Request and LISP Info-Reply - 115 are introduced in order to detect whether a LISP device is behind a 116 NAT, and discover the global IP address and global ephemeral port 117 used by the NAT to forward LISP packets sent by the LISP device. A 118 new LISP component, the LISP Re-encapsulating Tunnel Router (RTR), 119 acts as a re-encapsulating LISP tunnel router 120 [I-D.ietf-lisp-rfc6830bis] to pass traffic through the NAT, to and 121 from the LISP device. A modification to how the LISP Map-Register 122 messages are sent allows LISP device to initialize NAT state to use 123 the RTR services. This mechanism addresses the scenario where the 124 LISP device is behind the NAT, but the associated Map-Server 125 [I-D.ietf-lisp-rfc6833bis] is on the public side of the NAT. 127 2. Definition of Terms 129 LISP Info-Request: A LISP control message sent by a LISP device to 130 its Map-Server. 132 LISP Info-Reply: A LISP control message sent by a Map Server to a 133 LISP device in response to an Info-Request control message. 135 LISP Re-encapsulating Tunnel Router (RTR): An RTR is a re- 136 encapsulating LISP Router (see [I-D.ietf-lisp-rfc6830bis]). One 137 function that an RTR provides is enabling a LISP device to 138 traverse NATs. 140 LISP Data-Map-Notify: A LISP Map-Notify message encapsulated in a 141 LISP data header. 143 LISP xTR-ID A 128-bit field that, together with a site-ID, can be 144 appended at the end of a Map-Register or Map-Notify message. An 145 xTR-ID is used as a unique identifier of the xTR that is sending 146 the Map-Register and is especially useful for identifying multiple 147 xTRs serving the same site/EID-prefix. A value of all zeros 148 indicate the xTR-ID is unspecified. 150 LISP site-ID A 64-bit field that, together with a xTR-ID, can be 151 appended at the end of a Map-Register or Map-Notify message. A 152 site-ID is used as a unique identifier of a group of xTRs 153 belonging to the same site. A value of 0 indicate the site-ID is 154 unspecified. 156 NAT: "Network Address Translation is a method by which IP addresses 157 are mapped from one address realm to another, providing 158 transparent routing to end hosts". "Traditional NAT would allow 159 hosts within a private network to transparently access hosts in 160 the external network, in most cases. In a traditional NAT, 161 sessions are uni-directional, outbound from the private network." 162 --RFC 2663 [NAT]. Basic NAT and NAPT are two varieties of 163 traditional NAT. 165 Basic NAT: "With Basic NAT, a block of external addresses are set 166 aside for translating addresses of hosts in a private domain as 167 they originate sessions to the external domain. For packets 168 outbound from the private network, the source IP address and 169 related fields such as IP, TCP, UDP and ICMP header checksums are 170 translated. For inbound packets, the destination IP address and 171 the checksums as listed above are translated." --RFC 2663[NAT]. 173 NAPT: "NAPT extends the notion of translation one step further by 174 also translating transport identifier (e.g., TCP and UDP port 175 numbers, ICMP query identifiers). This allows the transport 176 identifiers of a number of private hosts to be multiplexed into 177 the transport identifiers of a single external address. NAPT 178 allows a set of hosts to share a single external address. Note 179 that NAPT can be combined with Basic NAT so that a pool of 180 external addresses are used in conjunction with port translation." 181 --RFC 2663[NAT]. Transport identifiers of the destination hosts 182 are not modified by the NAPT. 184 In this document the general term NAT is used to refer to both Basic 185 NAT and NAPT. 187 While this document specifies LISP NAT Traversal for LISP tunnel 188 routers, a LISP-MN can also use the same procedure for NAT traversal. 189 The modifications attributed to a LISP-Device, xTR, ETR, and ITR must 190 be supported by a LISP-MN where applicable, in order to achieve NAT 191 traversal for such a LISP node. A NAT traversal mechanism for LISP- 192 MN is also proposed in [NAT-MN]. 194 For definitions of other terms, notably Map-Request, Map-Reply, 195 Ingress Tunnel Router (ITR), and Egress Tunnel Router (ETR), please 196 consult the LISP specification [I-D.ietf-lisp-rfc6833bis]. 198 3. Basic Overview 200 There are a variety of NAT devices and a variety of network 201 topologies utilizing NAT devices in deployments. Most NAT devices 202 deployed today are designed primarily around the client/server 203 paradigm, where client machines inside a private network initiate 204 connections to public servers with public IP addresses. As such, any 205 protocol requiring a device or host in a private network behind a NAT 206 to receive packets or accept sessions from destinations without first 207 initiating a session or sending packets towards those destinations, 208 will be challenged by deployed NAT devices. 210 NAT devices are loosely classified based on how restrictive they are. 211 These classifications are essentially identifying the type of mapping 212 state that the NAT device is requiring to allow incoming traffic. 213 For instance, the mapping state may be end-point independent: once 214 device A inside the private network sends traffic to a destination 215 outside, a mapping state in the NAT is created that only includes 216 information about device A, namely its IP address and perhaps its 217 port number. Once this mapping is established in the NAT device, any 218 external device with any IP address could send packets to device A. 219 More restrictive NAT devices could include the 5 tuple information of 220 the flow as part of the mapping state, in other words, the mapping 221 state in the NAT is dependent upon Source IP and Port, as well as 222 destination IP and port (symmetric NAT or Endpoint-dependent NAT). 223 Such a NAT only allows traffic from the specified destination IP and 224 port to reach the specified source device on the specified source 225 port. Traffic with a different 5 tuple signature will not be allowed 226 to pass. In general, in the case of less restrictive NATs it may be 227 possible to eventually establish direct peer-to-peer connections, by 228 means of various hole punching techniques and initial rendezvous 229 servers. However, in the case of symmetric NATs or NATs with 230 endpoint-address-and-port-dependent mappings, direct connection may 231 prove impossible. In such cases a relay device is required that is 232 in the public Network and can relay packets between the two 233 endpoints. 235 Various methods have been designed to address NAT traversal 236 challenges, mostly in the context of peer-to-peer applications and 237 protocols. Among these, the Interactive Connectivity Establishment 238 (ICE) [ICE] seems the most comprehensive, which defines a protocol 239 that leverages other protocols such as Session Traversal Utilities 240 for NAT(STUN) [STUN] and Traversal Using Relays around NAT (TURN) 241 [TURN], as well as a rendezvous server to identify and exchange a 242 list of potential transport (IP and Port) addresses between the two 243 endpoints. All possible pairs of transport addresses are 244 exhaustively tested to find the best possible option for 245 communication, preferring direct connection to connections using a 246 relay. In the case of most restrictive NATs, ICE leads to use of 247 TURN servers as relay for the traffic. TURN requires a list of 248 allowed peer IP addresses defined as permissions, before allowing a 249 peer to use the relay server to reach a TURN client. 251 Common NAT traversal techniques such as ICE generally assume bi- 252 directional traffic with the same 5 tuple. LISP, however, requires 253 traffic to use destination UDP port 4341, without specifying the 254 source port. As a result, LISP traffic is generally uni-directional. 255 This means that, in the case of symmetric or endpoint-address-and- 256 port-dependent mapping NATs, even when an outgoing mapping is 257 established, still incoming traffic may not match the established 258 mapping and will not be allowed to pass. As a result, while ICE may 259 be used to traverse less restrictive NATs, use of standard TURN 260 servers as relays to traverse symmetric NATs for LISP protocol is not 261 possible. The rest of this document specifies a NAT traversal 262 technique for the LISP protocol that enables LISP protocol to 263 traverse multiple types of NATs including symmetric NATs. 265 3.1. LISP NAT Traversal Overview 267 There are two attributes of a LISP device behind a typical NAT that 268 requires special consideration in LISP protocol behavior in order to 269 make the device reachable. First, the RLOC assigned to the device is 270 typically not globally unique nor globally routable. The NAT likely 271 has a restrictive translation table and forwarding policy, requiring 272 outbound packets to create state before the NAT accepts inbound 273 packets. Second, LISP protocol requires an xTR to receive traffic on 274 a specific UDP port 4341, so the random UDP port allocated by the NAT 275 on its public side to associate with a xTR behind the NAT can not be 276 used by other xTRs to send LISP traffic to. This section provides an 277 overview of the LISP NAT traversal mechanism which deals with these 278 conditions. The following sections specify the mechanism in more 279 detail. 281 When a LISP device receives a new RLOC and wants to register it with 282 the mapping system, it needs to first discover whether it is behind a 283 NAT. To do this, an ETR queries its Map-Server to discover the ETR's 284 translated global RLOC and port via the two new LISP messages: Info- 285 Request and Info-Reply. Once an ETR detects that it is behind a NAT, 286 it uses a LISP Re-encapsulating Tunnel Router (RTR) entity as an 287 anchor point for sending and receiving data plane traffic through the 288 NAT device. The ETR registers the RTR RLOC(s) to its Map-Server 289 using the RTR as a proxy for the Map-Register message. The ETR 290 encapsulates the Map-Register message in a LISP ECM header destined 291 to the RTR's RLOC. The RTR strips the LISP ECM header and sends it 292 to the Map-Server. This initializes state in the NAT device so the 293 ETR can receive traffic on port 4341 from the RTR. The ETR also 294 registers the RTR RLOC as the RLOC where the ETR EID prefix is 295 reachable. As a result, all packets destined to the ETR's EID will 296 go to its RTR. The RTR will then re-encapsulate and forward the 297 ETR's traffic via the existing NAT state to the ETR. 299 Outbound LISP data traffic from the xTR should also be encapsulated 300 to the RTR, where the RTR de-capsulates the LISP packets, and then 301 re-encapsulates them or forwards them natively depending on their 302 destination. 304 In the next sections these procedures are discussed in more detail. 306 This document does not support different xTR-ID registering the same 307 EID prefix and using the same set of RTRs. Future versions of this 308 spec will explore this use-case. 310 4. LISP RTR Message Details 312 The main modifications in the LISP protocol to enable LISP NAT 313 traversal via an RTR include: (1) two new messages used for NAT 314 discovery (Info-Request and Info-Reply), and (2) encapsulation of two 315 LISP control messages (Map-Register and Map-Notify) between the xTR 316 and the RTR. Map-Register is encapsulated in an ECM header while 317 Map-Notify is encapsulated in a LISP data header (Data-Map-Notify). 318 This section describes the message formats and details of the Info- 319 Request, Info-Reply, and Data-Map-Notify messages, as well as 320 encapsulation details and minor changes to Map-Register and Map- 321 Notify messages. 323 4.1. Info-Request Message 325 An ETR sends an Info-Request message to its Map-Server in order to 327 1. detect whether there is a NAT on the path to its Map-Server 329 2. obtain a list of RTR RLOCs that can be used for LISP data plane 330 NAT traversal. 332 An Info-Request message is a LISP control message, its source port is 333 chosen by the xTR and its destination port is set to 4342. 335 0 1 2 3 336 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 337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 338 |Type=7 |R| Reserved | 339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 340 | Nonce . . . | 341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 342 | . . . Nonce | 343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 344 | Key ID | Authentication Data Length | 345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 346 ~ Authentication Data ~ 347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 348 | TTL | 349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 350 | Reserved | EID mask-len | EID-prefix-AFI | 351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 352 | EID-prefix | 353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 354 | AFI = 0 | | 355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 LISP Info-Request Message Format 359 Type: 7 (Info-Request) 361 R: R bit indicates this is a reply to an Info-Request (Info- 362 Reply). R bit is set to 0 in an Info-Request. When R bit is set 363 to 0, the AFI field (following the EID-prefix field) must be set 364 to 0. When R bit is set to 1, the packet contents follow the 365 format for an Info-Reply, as described below. 367 Reserved: Must be set to 0 on transmit and must be ignored on 368 receipt. 370 TTL: The time in minutes the recipient of the Info-Reply will 371 store the RTR Information. 373 Nonce: An 8-byte random value created by the sender of the Info- 374 Request. This nonce will be returned in the Info-Reply. The 375 nonce SHOULD be generated by a properly seeded pseudo-random (or 376 strong random) source. Future version of this document will 377 discuss anti-replay mitigation mechanisms 379 Descriptions for other fields can be found in the Map-Register 380 section of [I-D.ietf-lisp-rfc6833bis]. Field descriptions for the 381 LCAF AFI = 0 can be found in the LISP LCAF RFC [LCAF] . 383 4.2. LISP Info-Reply 385 When a Map-Server receives an Info-Request message, it responds with 386 an Info-Reply message. The Info-Reply message source port is 4342, 387 and destination port is taken from the source port of the triggering 388 Info-Request. Map-Server fills the NAT LCAF (LCAF Type = 7) fields 389 according to their description. The Map-Server uses AFI=0 for the 390 Private ETR RLOC Address field in the NAT LCAF. 392 0 1 2 3 393 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 394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 395 |Type=7 |R| Reserved | 396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 397 | Nonce . . . | 398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 399 | . . . Nonce | 400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 401 | Key ID | Authentication Data Length | 402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 403 ~ Authentication Data ~ 404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 405 | TTL | 406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 407 | Reserved | EID mask-len | EID-prefix-AFI | 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 409 | EID-prefix | 410 +->+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 411 | | AFI = 16387 | Rsvd1 | Flags | 412 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 413 | | Type = 7 | Rsvd2 | 4 + n | 414 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 N | MS UDP Port Number | ETR UDP Port Number | 416 A +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 T | AFI = x | Global ETR RLOC Address ... | 418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 419 L | AFI = x | MS RLOC Address ... | 420 C +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 A | AFI = x | Private ETR RLOC Address ... | 422 F +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 423 | | AFI = x | RTR RLOC Address 1 ... | 424 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 425 | | AFI = x | RTR RLOC Address n ... | 426 +->+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 428 LISP Info-Reply Message Format 430 Type: 7 , R = 1, (Info-Reply) 432 The format is similar to the Info-Request message. See Info-Request 433 section for field descriptions. Field descriptions for the NAT LCAF 434 section can be found in the LISP LCAF RFC [LCAF] . 436 4.3. LISP Map-Register Message 438 The third bit after the Type field in the Map-Register message is 439 allocated as "I" bit. I bit indicates that a 128 bit xTR-ID and a 64 440 bit site-ID field are present at the end of the Map-Register message. 441 If an xTR is configured with an xTR-ID or site-ID, it MUST set the I 442 bit to 1 and include its xTR-ID and site-ID in the Map-Register 443 messages it generates. If either the xTR-ID or site-ID is not 444 configured an all zeros value is encoded for whichever ID that is not 445 configured. 447 xTR-ID is a 128 bit field at the end of the Map-Register message, 448 starting after the final Record in the message. The xTR-ID is used 449 to identify the intended recipient xTR for a Map-Notify message, 450 especially in the case where a site has more than one xTR. A value 451 of all zeros indicate that an xTR-ID is not specified, though encoded 452 in the message. This is useful in the case where a site-ID is 453 specified, but no xTR-ID is configured. When a Map-Server receives a 454 Map-Register with an xTR-ID specified (I bit set and xTR-ID has a 455 non-zero value), it MUST copy the XTR-ID from the Map-Register to the 456 associated Map-Notify message. When a Map-Server is sending an 457 unsolicited Map-Notify to an xTR to notify the xTR of a change in 458 locators, the Map-Server must include the xTR-ID for the intended 459 recipient xTR, if it has one stored locally. 461 site-ID is a 64 bit field at the end of the Map-Register message, 462 following the xTR-ID. site-ID is used by the Map-Server receiving the 463 Map-Register message to identify which xTRs belong to the same site. 464 A value of 0 indicate that a site-ID is not specified, though encoded 465 in the message. When a Map-Server receives a Map-Register with a 466 site-ID specified (I bit set and site-ID has non-zero value), it must 467 copy the site-ID from the Map-Register to the associated Map-Notify 468 message. When a Map-Server is sending an unsolicited Map-Notify to 469 an xTR to notify the xTR of a change in locators, the Map-Server must 470 include the site-ID for the intended recipient xTR, if it has one 471 stored locally. 473 A LISP device that sends a Map-Register to an RTR must encapsulate 474 the Map-Register message using an Encapsulated Control Message (ECM) 475 [I-D.ietf-lisp-rfc6833bis]. The 6th bit in the ECM LISP header is 476 allocated as the "R" bit. The R bit indicates that the encapsulated 477 Map-Register is to be processed by an RTR. The 7th bit in the ECM 478 header is allocated as the "N" bit. The N bit indicates that this 479 Map-Register is being relayed by an RTR. When an RTR relays the ECM- 480 ed Map-Register to a Map-Server, the N bit must be set to 1. 482 The outer header source RLOC of the ECM is set to the LISP device's 483 local RLOC, and the outer header source port is set to 4341. The 484 outer header destination RLOC and port are set to RTR RLOC and 4342 485 respectively. The inner header source RLOC is set to LISP device's 486 local RLOC, and the inner source port is picked at random. The inner 487 header destination RLOC is set to the xTR's Map-Server RLOC, and 488 inner header destination port is set to 4342. 490 4.4. LISP Map-Notify 492 The first bit after the Type field in a Map-Notify message is 493 allocated as the "I" bit. I bit indicates that a 128 bit xTR-ID and 494 64 bit site-ID field is present at the end of the Map-Notify message, 495 following the final Record in the Map-Notify (See Section 4.3 for 496 details on xTR-ID and site-ID). A Map-Server MUST set the I bit in a 497 Map-Notify and include the xTR-ID and/or site-ID of the intended 498 recipient xTR if the associated Map-Register has an xTR-ID and/or 499 site-ID specified, or when the Map-Server has previously cached an 500 xTR-ID and/or site-ID for the destination xTR. 502 A LISP device that sends a Map-Notify to an RTR must encapsulate the 503 Map-Notify message using an ECM. The 6th bit in the ECM LISP header, 504 allocated as the "R" bit, must be set when the encapsulated Map- 505 Notify is to be processed by an RTR. If the S bit is also set in the 506 Map-Notify ECM header, it indicates that additional MS-RTR 507 authentication data is included after the LISP header in the ECM. If 508 the I bit is also set in the Map-Notify, the xTR-ID and site-ID 509 fields are included in the Map-Notify. If a Map-Server receiving an 510 ECM-ed Map-Register has a shared key associated with the sending RTR, 511 it must generate a Map-Notify message with the S bit in the ECM 512 header set to 1, and with the additional MS-RTR authentication 513 related fields described below. 515 0 1 2 3 516 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 517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 518 | AD Type | Reserved | 519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 520 | MS-RTR Key ID | MS-RTR Auth. Data Length | 521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 522 ~ MS-RTR Authentication Data ~ 523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 525 Changes to LISP Map-Notify Message 527 AD Type: 2 (RTR Authentication Data) 529 MS-RTR Key ID: A configured ID to find the configured Message 530 Authentication Code (MAC) algorithm and key value used for the 531 authentication function. See [I-D.ietf-lisp-rfc6833bis] section 12.5 532 for code point assignments. 534 MS-RTR Authentication Data Length: The length in bytes of the MS-RTR 535 Authentication Data field that follows this field. The length of the 536 Authentication Data field is dependent on the Message Authentication 537 Code (MAC) algorithm used. The length field allows a device that 538 doesn't know the MAC algorithm to correctly parse the packet. 540 MS-RTR Authentication Data: The message digest used from the output 541 of the Message Authentication Code (MAC) algorithm. The entire Map- 542 Notify payload is authenticated. After the MAC is computed, it is 543 placed in this field. Implementations of this specification MUST 544 support HMAC-SHA-1-96 [RFC2404] and SHOULD support HMAC-SHA-256-128 545 [RFC6234]. 547 For a full description of all fields in the Map-Notify message refer 548 to Map-Notify section in [I-D.ietf-lisp-rfc6833bis]. 550 The outer header source RLOC of the ECM is set to the xTR's Map- 551 Server RLOC, and the outer header source port is set to 4342. The 552 outer header destination RLOC and port are set to RTR's RLOC and 4342 553 respectively. The inner header source RLOC is set to the xTR's Map- 554 Server RLOC, and the inner source port is set to 4342. The inner 555 header destination RLOC is set to the LISP device's local RLOC copied 556 from the Map-Register, and inner header destination port is set to 557 4342. 559 4.5. LISP Data-Map-Notify Message 561 When an RTR receives an ECM-ed Map-Notify message with R bit in the 562 ECM header set to 1, it has to relay the Map-Notify payload to the 563 registering LISP device. After removing the ECM header and 564 processing the Map-Notify message as described in Section 5.3, the 565 RTR encapsulates the Map-Notify in a LISP data header and sends it to 566 the associated LISP device. This Map-Notify inside a LISP data 567 header is referred to as a Data-Map-Notify message. 569 0 1 2 3 570 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 571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 572 / | IPv4 or IPv6 Header | 573 OH | (uses RLOC addresses) | 574 \ | | 575 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 576 / | Source Port = 4342 | Dest Port = xxxx | 577 UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 578 \ | UDP Length | UDP Checksum | 579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 580 L | LISP Header ~ | 581 I \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 582 S / | ~ LISP Header | 583 P +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 584 / | IPv4 or IPv6 Header | 585 IH | (uses RLOC or EID addresses) | 586 \ | | 587 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 588 / | Source Port = 4342 | Dest Port = 4342 | 589 UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 590 \ | UDP Length | UDP Checksum | 591 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 592 LCM | LISP Map-Notify Message ~ 593 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 595 LISP Data-Map-Notify Message 597 In a Data-Map-Notify, the outer header source RLOC is set to the 598 RTR's RLOC that was used in the associated Map-Register. This is 599 previously cached by the RTR. The outer header source port is set to 600 4342. The outer header destination RLOC and port are filled based on 601 the translated global RLOC and port of the registering LISP device 602 previously stored locally at the RTR. The inner header source 603 address is Map-Server's RLOC, and inner header source port is 4342. 604 The inner header destination address is the LISP device's local RLOC. 605 The inner header destination port is 4342. 607 Since a Data-Map-Notify is a control message encapsulated in a LISP 608 data header, a special Instance ID is used as a signal for the xTR to 609 trigger processing of the control packet inside the data header. The 610 Instance ID value 0xFFFFFF is reserved for this purpose. The 611 Instance ID field in a Data-Map-Notify must be set to 0xFFFFFF. 613 5. Protocol Operations 615 There are two main steps in the NAT traversal procedure. First, the 616 ETR's translated global RLOC must be discovered. Second, the NAT 617 translation table must be primed to accept incoming connections. At 618 the same time, the RTR must be informed of the ETR's translated 619 global RLOC including the translated ephemeral port number(s) at 620 which the RTR can reach the LISP device. 622 5.1. xTR Processing 624 Upon receiving a new local RLOC, an ETR first has to detect whether 625 the new RLOC is behind a NAT device. For this purpose the ETR sends 626 an Info-Request message to its Map-Server in order to discover the 627 ETR's translated global RLOC as it is visible to the Map-Server. The 628 ETR uses its new local RLOC as the source RLOC of the message. The 629 Map-Server, after authenticating the message, responds with an Info- 630 Reply message. The Map-Server includes the source RLOC and port from 631 the Info-Request message in the Global ETR RLOC Address and ETR UDP 632 Port Number fields of the Info-Reply. The Map Server also includes 633 the destination RLOC and port number of the Info-Request message in 634 the MS RLOC Address and MS UDP Port Number fields of the Info-Reply. 635 In addition, the Map-Server provides a list of RTR RLOCs that the ETR 636 may use in case it needs NAT traversal services. The source port of 637 the Info-Reply is set to 4342 and the destination port is copied from 638 the source port of the triggering Info-Request message. 640 Upon receiving the Info-Reply message, the ETR compares the source 641 RLOC and source port used for the Info-Request message with the 642 Global ETR RLOC Address and ETR UDP Port Number fields of the Info- 643 Reply message. If the two are not identical, the ETR concludes that 644 its new local RLOC is behind a NAT and that it requires an RTR for 645 NAT traversal services in order to be reachable at that RLOC. An ETR 646 behind other statefull devices (e.g. statefull firewalls) may also 647 use an RTR and the procedure specified here for traversing the 648 statefull device. Detecting existence of such devices are beyond 649 scope of this document. 651 It is worth noting that a STUN server can also be used to do NAT 652 detection and to discover the NAT-translated public IP address and 653 port number for the ETR behind NAT. If a STUN server is used, list 654 of RTR devices that can be used by the xTR for NAT traversal must be 655 provisioned to the xTR via other means which are outside the scope of 656 this document. 658 If there is no NAT on the path identified by an info-Request and an 659 Info-Reply, the ETR registers the associated RLOC with its Map-Server 660 as described in [I-D.ietf-lisp-rfc6833bis]. 662 A device that is not behind a NAT can still choose to use RTR as an 663 anchor point. In some deployments, devices can roam from NATed 664 connections to non-NATed connections. In such scenarios, the 665 deployer may choose to always use an RTR, thus avoiding frequent 666 notifications of RLOC changes. The main disadvantage of this policy 667 is that RTRs may increase path length. 669 5.1.1. ETR Registration 671 Once an ETR has detected that it is behind a NAT, based on local 672 policy the ETR selects one (or more) RTR(s) from the RTR RLOCs 673 provided in the Info-Reply and initializes state in the NAT device in 674 order to receive LISP data traffic on UDP port 4341 from the selected 675 RTR. To do so, the ETR sends a Map-Register encapsulated in an ECM 676 header to the selected RTR(s). The Map-Register message is created 677 as specified in [I-D.ietf-lisp-rfc6833bis]. More specifically, the 678 source RLOC of the Map-Register is set to ETR's local RLOC, while the 679 destination RLOC is set to the ETR's Map-Server RLOC, and destination 680 port is set to 4342. The ETR sets the P bit (proxy Map-Reply) and 681 the M bit (want-Map-Notify) in Map-Register to 1, and it includes the 682 selected RTR RLOC(s) as the locators in the Map-Register message. 683 The ETR can also include its local RLOCs as locators in the Map- 684 Register, including weight and priorities, while setting the R bit to 685 0 for each local RLOC. This can be used by the RTR for load 686 balancing when forwarding data to a multi-homed xTR behind a NAT. 687 The R bit is set to 1 for all RTR locators included in the Map- 688 Register. The ETR must also set the I bit in the Map-Register 689 message to 1 and include its xTR-ID and site-ID in the corresponding 690 field. In the ECM header of this Map-Register the source RLOC is set 691 to ETR's local RLOC and the source port is set to 4341, while the 692 destination RLOC is the RTR's RLOC and the destination port is set to 693 LISP control port 4342. The R bit in the ECM header is also set to 694 1, to indicate that this EDCM-ed Map-Register is to be processed by 695 an RTR. 697 This ECM-ed Map-Register is then sent to the RTR. The RTR removes 698 the ECM header, encapsulates the new Map-Register in a new ECM header 699 with R bit set to 0, and sends it to the associated Map-Server. The 700 RTR then encapsulates the corresponding Map-Notify message in a LISP 701 data header (Data-Map-Notify) and sends it back to the xTR. 703 Upon receiving a Data-Map-Notify from the RTR, the ETR must strip the 704 outer LISP data header, and process the inner Map-Notify message as 705 described in [I-D.ietf-lisp-rfc6833bis]. Since outer header 706 destination port in Data-Map-Notify is set to LISP data port 4341, 707 the Instance ID 0xFFFFFF in the LISP header of the Data-Map-Notify is 708 used by the ETR to detect and process the Data-Map-Notify as a 709 control message encapsulated in a LISP data header. While processing 710 the Data-Map-Notify, the xTR also stores the RTR RLOC(s) as its data 711 plane proxy for the interface/RLOC behind the NAT. 713 If the xTR is not multi-homed, or if all its interfaces are behind 714 the NAT and will use the same RTR, then the xTR should map the EID 715 prefix 0/0 to this RTR RLOC(s) in its map-cache. This results in the 716 xTR encapsulating all LISP data plane traffic to this RTR, reducing 717 the state created in the NAT. Note that not installing the default 718 map-cache entry will lead to normal Map-Request and Map-Reply 719 messages for EID mapping lookups which is only supported if the xTR 720 has interfaces not behind NAT. If outgoing traffic is sent directly 721 to destinations without passing through the RTR, this will result in 722 additional state to be created in the NAT device. 724 At this point the registration and state initialization is complete 725 and the xTR can use the RTR services. The state created in the NAT 726 device based on the ECM-ed Map-Register and corresponding Data-Map- 727 Notify is used by the xTR behind the NAT to send and receive LISP 728 control packets to/from the RTR, as well as for receiving LISP data 729 packets form the RTR. 731 If ETR receives a Data-Map-Notify with a xTR-ID specified, but the 732 xTR-ID is not equal to its local xTR-ID, it must log this as an 733 error. The ETR should discard such Data-Map-Notify message. 735 The ETR must periodically send ECM-ed Map-Register messages to its 736 RTR in order to both refresh its registration to the RTR and the Map- 737 Server, and as a keep alive in order to preserve the state in the NAT 738 device. RFC 2663 [NAT] points out that the period for sending the 739 keep alives can be set to default value of two minutes, however since 740 shorter timeouts may exist in some NAT deployments, the interval for 741 sending periodic ECM-ed Map-Registers must be configurable. 743 5.1.2. Map-Request and Map-Reply Handling 745 To avoid the creation of extra status in the NAT devices due to the 746 Map-Replies send to requesting ITRs, the ETR set the proxy-bit of the 747 Map-Register to one in order the Map-Server proxy-reply the ETR as 748 described in [I-D.ietf-lisp-rfc6833bis] 750 When an ITR behind a NAT is encapsulating outbound LISP traffic, it 751 can use its RTR RLOC as the locator for all destination EIDs that it 752 wishes to send data to. As such, the ITR does not need to send Map- 753 Requests for finding EID-to-RLOC mappings. However, if the ITR is 754 multihomed and has at least one interface not behind NAT, it can 755 choose to send Map-Requests. For this, the ITR specifies in the ITR- 756 RLOC field of the Map-Request the list of RLOCs that are not behind 757 NAT to receive the Map-Reply messages. It should be noted that 758 sending packets directly to destination RLOCs through the interface 759 behind NAT will result in creating additional state in the NAT 760 device. Also, it should be noted that outgoing packets use a direct 761 path while the incoming packets are forwarded through an RTR. 763 For RLOC-probing, the periodic ECM-ed Map-Register and Data-Map- 764 Notify messages between xTR and RTR can also serve the purpose of 765 RLOC probes. However, if RLOC-probing is used, no changes are 766 required to the RLOC-probing specification in 767 [I-D.ietf-lisp-rfc6833bis], except that the LISP device behind a NAT 768 only needs to probe the RTR's RLOC. 770 5.1.3. xTR Sending and Receiving Data 772 When a Map-Request for a LISP device behind a NAT is received by its 773 Map-Server, the Map-Server responds with a Map-Reply including RTR's 774 RLOC as the locator for the requested EID. As a result, all LISP 775 data traffic destined for the ETR's EID behind the NAT is 776 encapsulated to its RTR. The RTR re-encapsulates the LISP data 777 packets to the ETR's translated global RLOC and port number so the 778 data can pass through the NAT device and reach the ETR. As a result 779 the ETR receives LISP data traffic with outer header destination port 780 set to 4341 as specified in [I-D.ietf-lisp-rfc6830bis]. 782 For sending outbound LISP data, an ITR behind a NAT SHOULD use the 783 RTR RLOC as the locator for all EIDs that it wishes to send data to 784 via the interface behind the NAT. The ITR then encapsulates the LISP 785 traffic in a LISP data header with outer header destination set to 786 RTR RLOC and outer header destination port set to 4341. This may 787 create a secondary state in the NAT device. ITR SHOULD set the outer 788 header source port in all egress LISP data packets to a random but 789 static port number in order to avoid creating excessive state in the 790 NAT device. 792 If the ITR and ETR of a site are not collocated, the RTR RLOC must be 793 configured in the ITR via an out-of-band mechanism. Other procedures 794 specified here would still apply. 796 5.2. Map-Server Processing 798 Upon receiving an Info-Request message a Map-Server first verifies 799 the authenticity of the message. Next the Map-Server creates an 800 Info-Reply message and copies the source RLOC and port number of the 801 Info-Request message to the Global ETR RLOC Address and ETR UDP Port 802 Number fields of the Info-Reply message. The Map-Server also 803 includes a list of RTR RLOCs that the ETR may use for NAT traversal 804 services. The Map-Server sends the Info-Reply message to the ETR, by 805 setting the destination RLOC and port of the Info-Reply to the source 806 RLOC and port of the triggering Info-Request. The Map-Server sets 807 the source port of the Info-Reply to 4342. 809 Upon receiving an ECM-ed Map-Register message with the N bit in the 810 ECM header set to 1, the Map-Server removes the ECM header and if the 811 M bit in the Map-Register is set, the Map-Server processes the Map- 812 Register message and generates the resulting Map-Notify as described 813 in [I-D.ietf-lisp-rfc6833bis]. The Map-Server encapsulates the Map- 814 Notify in an ECM header and sets the R bit in the ECM header to 1. 815 This indicates that the ECM-ed Map-Notify is to be processed by an 816 RTR. If the Map-Server has a shared secret configured with the RTR 817 sending the Map-Register, the Map-Server also sets the S bit in the 818 ECM header of the Map-Notify and includes the MS-RTR authentication 819 data after the ECM LISP header. See Security Considerations 820 Section for more details. If the I bit is set in the Map-Register 821 message, the Map-Server also locally stores the xTR-ID and site-ID 822 from the Map-Register, and sets the I bit in the corresponding Map- 823 Notify message and includes the same xTR-ID and site-ID in the Map- 824 Notify. The ECM-ed Map-Notify is then sent to the RTR sending the 825 corresponding Map-Register. 827 5.3. RTR Processing 829 Upon receiving an ECM-encapsulated Map-Register with the R bit set in 830 the ECM header, the RTR creates a map-cache entry for the EID-prefix 831 that was specified in the Map-Register message. The RTR stores the 832 outer header source RLOC and outer header source port, the outer 833 header destination RLOC (RTR's own RLOC), the inner header source 834 RLOC (xTR's local RLOC), the xTR-ID, the weight and priority 835 associated with the xTR's local RLOC that was used to send this Map- 836 Register if present, and the nonce field of the Map-Register in this 837 local map-cache entry. The RTR uses the inner header source address 838 to identify which xTR local RLOC (R bit =0) was used by the xTR to 839 send this Map-Register. The outer header source RLOC and outer 840 header source port is the ETR's translated global RLOC and port 841 number visible to the RTR. Once the registration process is 842 complete, this map-cache entry can be used to send LISP data traffic 843 to the ETR. The outer header destination RLOC is the RTR's RLOC used 844 by the ETR. The RTR can later use these fields as the source RLOC 845 for sending data-encapsulated control messages (Data-Map-Notify) back 846 to the ETR. The nonce field is used for security purposes and is 847 matched with the nonce field in the corresponding Map-Notify message. 848 This map-cache entry is stored as an "unverified" mapping, until the 849 corresponding Map-Notify message is received. 851 In the cases where the xTR has multiple RLOCs behind the NAT, and 852 requires the RTR to load balance the traffic across those interfaces, 853 the xTR must include the local RLOCs associated with each interface 854 behind the NAT with the R bit in the locator record set to 0 in the 855 ECM-ed Map-Register sent to the RTR. The RTR uses the weight and 856 priority policies of the RLOCs with R=0 in the Map-Register to load 857 balance the traffic from the RTR to the xTR behind the NAT. The RTR 858 compares the RLOCs with the R bit set to 0 in the Map-Register to the 859 inner header source address of the Map-Register to find the matching 860 RLOC that the xTR used to send the Map-Register from. The RTR 861 associates the weight and priority policies of this local RLOC with 862 the NAT-translated RLOC and xTR-ID for this map-cache entry. For all 863 other local RLOCs included in the Map-Register, that the Map-Register 864 is not originating from, the RTR only updates previously cached 865 weight and priority policies if it already has those local RLOCs 866 previously stored for that EID prefix and xTR-ID. In other words, 867 the RTR only adds new local RLOCs and their weight and priority 868 policies to its cache if the Map-Register is actually originating 869 from that RLOC. The TTL for every map-cache is also only updated 870 when a Map-Register is originating from the same RLOC. However, the 871 weight and priorities of all previously cached local RLOCs will be 872 updated by every Map-Register, whether it is originating from that 873 RLOC or not. The xTR-ID is used to define the Merge domain for these 874 RLOCs. In other words, a Map-Register originating from a unique xTR- 875 ID will always overwrite previously stored policies for that xTR-ID. 876 However it does not modify in any way the policies indicated by any 877 other xTR-ID serving the same EID prefix. As a result, in the case 878 of a renumbering or xTR reboot, the xTR uses its unique xTR-ID to 879 send a new Map-Register, overwriting the previously stored policies 880 for that xTR. Using this method the xTR can immediately remove any 881 RLOCs from the RTR cache that are no longer active. In order to 882 implement this, the RTR must compare the list of local RLOCs in the 883 Map-Register (R=0) with the ones it has previously cached associated 884 with the same xTR-ID. If there is any RLOC previously cached that 885 does not appear in the newly received Map-Register, the RTR must 886 remove that RLOC together with the associated translated RLOC and 887 associated policies, because removal of a local (behind-the-NAT) RLOC 888 also invalidates the NAT-ed address associated with it. . 890 After filling the local map-cache entry, the RTR strips the outer 891 header and extracts the Map-Register message, encapsulated in a new 892 ECM header with the R bit set to 0, and N bit set to 1, and sends the 893 ECM-ed Map-Register to destination Map-Server. 895 Map-Server responds with a ECM-ed Map-Notify message to the RTR. 897 Upon receiving an ECM-ed Map-Notify message with R bit set to 1 in 898 the ECM header, if the S bit in ECM header is set to 1, RTR uses the 899 MS-RTR Key ID to verify the MS-RTR Authentication Data included after 900 the ECM header. If the MS-RTR authentication fails, the RTR must 901 drop the packet. Once the authenticity of the message is verified, 902 RTR can confirm that the Map-Register message for the ETR with the 903 matching xTR-ID was accepted by the Map-Server. At this point the 904 RTR can change the state of the associated map-cache entry to 905 verified for the duration of the Map-Register TTL. 907 The RTR then uses the information in the associated map-cache entry 908 to create a Data-Map-Notify message according to the following 909 procedure: The RTR encapsulates the Map-Notify in a LISP data header, 910 where the outer header destination RLOC and port number are set to 911 the ETR's translated global RLOC and port number. If more than one 912 ETR translated RLOC and port exists in the map-cache entry for the 913 same EID prefix specified in the Map-Notify, the RTR can use the xTR- 914 ID from the Map-Notify to identify which ETR is the correct 915 destination for the Data-Map-Notify. The RTR sets the outer header 916 source RLOC to RTR's RLOC from the map-cache entry and the outer 917 header source port is set to 4342. The RTR also sets the Instance ID 918 field in the LISP header of the Data-Map-Notify to 0xFFFFFF. The RTR 919 then sends the Data-Map-Notify to the ETR. 921 If the S bit is set to 0 in the ECM header of the Map-Notify, and the 922 RTR has a shared key configured locally with the sending Map-Server, 923 the RTR must drop the packet. If the S bit is set to 0, and the RTR 924 does not have a shared key configured with the associated Map-Server, 925 according to local policy, the RTR may drop the packet. If the Map- 926 Notify with S bit set to 0 is processed, the RTR must match the nonce 927 field from this Map-Notify with the nonce stored in the local map- 928 cache entry with the matching xTR-ID. If the nonces do not match, 929 the RTR must drop the packet. 931 An RTR receiving an unsolicited Map-Notify for a registered EID 932 should check if any of the RTR's RLOCs is present in the received 933 record. If it does, the RTR rewrites the inner header destination 934 RLOC of the Map-Notify message to ETR's local RLOC obtained from the 935 associated map-cache entry of the EID. Then the RTR encapsulates and 936 forwards the Map-Notify in a LISP data packet as explained above. If 937 the record of the received Map-Notify doesn't contain any locator of 938 the RTR it should drop it and request the new mapping to the mapping 939 system. If the map reply record doesn't contain any RTR's locator, 940 the map-cache entry for the EID is replaced otherwise, the Map-Reply 941 is silently dropped. 943 5.3.1. RTR Data Forwarding 945 For all LISP data packets encapsulated to RTR's RLOC and outer header 946 destination port 4341, the RTR first verifies whether the source or 947 destination EID is a previously registered EID. If so, the RTR must 948 process the packet according to the following. If the destination or 949 source EID is not a registered EID, the RTR can drop or process the 950 packets based on local policy. 952 In the case where the destination EID is a previously registered EID, 953 the RTR must strip the LISP data header and re-encapsulate the packet 954 in a new LISP data header. The outer header RLOCs and UDP ports are 955 then filled based on the matching map-cache entry for the associated 956 destination EID prefix. The RTR uses the RTR RLOC from the map-cache 957 entry as the outer header source RLOC. The outer header source port 958 is set to 4342. The RTR sets the outer header destination RLOC and 959 outer header destination port based on the ETR translated global RLOC 960 and port stored in the map-cache entry. Then the RTR forwards the 961 LISP data packet. 963 In the case where the source EID is a previously registered EID, the 964 RTR process the packet as if it is a Proxy ETR (PETR). The RTR must 965 strip the LISP data header, and process the packet based on its inner 966 header destination address. The packet may be forwarded natively, it 967 may be LISP encapsulated to the destination ETR, or it may trigger 968 the RTR to send a LISP Map-Request. 970 5.4. Multi-homed xTRs 972 In the case where an xTR has multiple interfaces and RLOCs, info- 973 Requests can be sent per each interface and NAT discovery is done per 974 each interface. NAT traversal is accomplished by following state and 975 processes described above per each interface/RLOC. In other words, 976 if multiple interfaces of an xTR are behind a NAT, the ECM-ed Map- 977 Register messages should be sent via each xTR interface behind NAT if 978 the xTR desires to receive traffic via that interface. This is 979 required to establish the state in the NAT device for that interface. 980 The M bit (want Map-Notify) must be set in ECM-ed Map-Register 981 messages sent from at least one of xTR interfaces behind the NAT. If 982 additional interfaces behind the NAT are using the same RTR for NAT 983 traversal, no Map-Notify processing is required for such interfaces 984 and M bit in Map-Register can be set to 0 for these to reduce 985 processing on the RTR and the Map-Server. 987 The RLOCs included in Map-Register messages when the xTR has multiple 988 interfaces SHOULD be the union of the locators (behind NAT or not) 989 resulting from the process defined above per each RLOC of the xTR, 990 according to the specifics of that interface (whether it is behind 991 the NAT or not). 993 In cases where some xTR interfaces are behind NAT while others are 994 not, ECM-ed Map-Register messages should be sent via interfaces 995 behind the NAT through the selected RTRs. xTR can receive traffic via 996 both types of interfaces by including the associated RLOCs (as well 997 as the RTR RLOCs) in its ECM-ed Map-Register messages. The xTR can 998 choose to store RTR RLOCs in a default map-cache entry to forward all 999 the traffic through the RTR. If the xTR decides to populate its map- 1000 cache, the xTR may configure the RTR as a proxy of the interface 1001 behind NAT instead of sending the traffic directly to avoid generate 1002 new state in the NAT device. 1004 5.5. Updating contents of EID-to-RLOC Mappings 1006 When an interface of a LISP device is configured with a new RLOC, it 1007 needs to discover whether it is behind NAT by sending an Info-Request 1008 message. If the modified interface was previously behind NAT and the 1009 new RLOC is also behind NAT using the same RTRs association, the 1010 cache of the RTR is updated through the ECM-ed Map-Register send by 1011 the ETR. Otherwise, the change of the EID-to-RLOC mapping needs to 1012 be notified to remote ITRs/PiTRs. 1014 LISP defines several mechanisms to update mappings in the Data-Plane 1015 [I-D.ietf-lisp-rfc6830bis] and in the control plane 1016 [I-D.ietf-lisp-rfc6833bis]. Also an additional Control-Plane 1017 mechanism based on the Publish/subscribe paradigm is specified in 1018 [I-D.ietf-lisp-pubsub]. It is recommended to use 1019 [I-D.ietf-lisp-pubsub] to notify mapping changes as it is a faster 1020 mechanism and it avoids the temporal increase of the path length 1021 associated with an ETR desassociating of an RTR. 1023 In the case of Solicit-Map-Request mechanism, when an RTR receives a 1024 Soliciting Map-Request for a cached EID-Prefix, the RTR should 1025 request for the new mapping to the mapping system. If the Map-Reply 1026 record contains any RTR's locator, the RTR silently discards the Map- 1027 Reply; otherwise, the status of the map-cache entry used to punch the 1028 NAT of the EID-Prefix would be lost. If the Map-Reply record doesn't 1029 contain any RTR's locator, the RTR must update the cache entry. 1031 A Map-Server receiving a new registration for an EID should send 1032 unsolicited Map-Notify to the departure ETRs as specified in section 1033 4.2.3 of [I-D.ietf-lisp-eid-mobility]. An RTR receiving an 1034 unsolicited Map-Notify for a registered EID should process it as 1035 described in Section 5.3. 1037 An RTR that replace a registered cache entry through a Map-Request / 1038 Map-Reply must forward traffic to the EID as described in 1039 [I-D.ietf-lisp-rfc6833bis] until the map-cache entry expires. 1040 Optionally, the RTR can send Data Driven SMRs to ITRs sending traffic 1041 to the removed EID through the RTR as described in section 4.2.4 of 1042 [I-D.ietf-lisp-eid-mobility]. 1044 5.6. Example 1046 What follows is an example of an ETR initiating a registration of a 1047 new RLOC to its Map-Server, when there is a NAT device on the path 1048 between the ETR and the Map-Server. 1050 In this example, the ETR (site1-ETR) is configured with the local 1051 RLOC of 192.168.1.2. The NAT's global (external) addresses are from 1052 2.0.0.1/24 prefix. The Map-Server is at 3.0.0.1. And one potential 1053 RTR has an IP address of 1.0.0.1. The site1-ETR has an EID Prefix of 1054 128.1.0.0/16. 1056 An example of the registration process follows: 1058 1. The Site1-ETR receives the private IP address, 192.168.1.2 as 1059 its RLOC via DHCP. 1061 2. The Site1-ETR sends an Info-Request message with the destination 1062 RLOC of the Map-Server, 3.0.0.1, and source RLOC of 192.168.1.2. 1063 This packet has the destination port set to 4342 and the source 1064 port is set to (for example) 5001. 1066 3. The NAT device translates the source IP from 192.168.1.2 to 1067 2.0.0.1, and source port to (for example) 20001 global ephemeral 1068 source port. 1070 4. The Map-Server receives and responds to this Info-Request with 1071 an Info-Reply message. This Info-Reply has the destination 1072 address set to ETR's translated address of 2.0.0.1 and the 1073 source address is the Map-Server's RLOC, namely 3.0.0.1. The 1074 destination port is 20001 and the source port is 4342. Map- 1075 Server includes a copy of the source address and port of the 1076 Info-Request message (2.0.0.1:20001), and a list of RTR RLOCs 1077 including RTR RLOC 1.0.0.1 in the Info-Reply contents. 1079 5. The NAT translates the Info-Reply packet's destination IP from 1080 2.0.0.1 to 192.168.1.2, and translates the destination port from 1081 20001 to 5001, and forwards the Info-Reply to site1-ETR at 1082 192.168.1.2. 1084 6. The Site1-ETR detects that it is behind a NAT by comparing its 1085 local RLOC (192.168.1.2) with the Global ETR RLOC Address in the 1086 Info-Reply (2.0.0.2) . Then site1-ETR picks the RTR 1.0.0.1 from 1087 the list of RTR RLOCs in the Info-Reply. ETR stores the RTR 1088 RLOC in a default map-cache entry to periodically send ECM-ed 1089 Map-Registers to. 1091 7. The ETR sends an ECM encapsulated Map-Register to RTR at 1092 1.0.0.1. The outer header source RLOC of this Map-Register is 1093 set to 192.168.1.2 and the outer header source port is set to 1094 4341. The outer header destination RLOC and port are set to RTR 1095 RLOC at 1.0.0.1 and 4342 respectively. The R bit in ECM header 1096 is set to 1. The inner header destination RLOC is set to ETR's 1097 Map-Server 3.0.0.1, and the inner header destination port is set 1098 to 4342. The inner header source RLOC is set to ETR's local 1099 RLOC 192.168.1.2 and the source port is set to (for example) 1100 5002. In the Map-Register message the RTR RLOC 1.0.0.1 appears 1101 as the locator set for the ETR's EID prefix (128.1.0.0/16). In 1102 this example ETR also sets the Proxy bit in the Map-Register to 1103 1, and sets I bit to 1, and includes its xTR-ID and site-ID in 1104 the Map-Register. 1106 8. The NAT translates the source RLOC in the ECM header of the Map- 1107 Register, by changing it from 192.168.1.2 to 2.0.0.2, and 1108 translates the source port in the ECM header from 4341 to (for 1109 example) 20002, and forwards the Map-Register to RTR. 1111 9. The RTR receives the Map-Register and creates a map-cache entry 1112 with the ETR's xTR-ID, EID prefix, and the source RLOC and port 1113 of the ECM header of the Map-Register as the locator 1114 (128.1.0.0/16 is mapped to 2.0.0.2:20002). RTR also caches the 1115 inner header source RLOC of the Map-Register namely 192.168.1.2, 1116 and the outer header destination RLOC of the ECM header in the 1117 Map-Register (this would be RTR's RLOC 1.0.0.1 ) to use for 1118 sending back a Data-Map-Notify. RTR then removes the outer 1119 header, adds a new ECM header with R=0, and N=1, and forwards 1120 the Map-Register to the destination Map-Server. 1122 10. The Map-Server receives the ECM-ed Map-Register with N bit set 1123 to 1, removes the ECM header, and processes it according to 1124 [I-D.ietf-lisp-rfc6833bis]. Since Map-Server has a shared 1125 secret with the sending RTR, after registering the ETR, Map- 1126 Server responds with a ECM-ed Map-Notify with the R bit and S 1127 bit both set to 1 in the ECM header and including the MS-RTR 1128 authentication data. Since the I bit is set in the Map- 1129 Register, the Map-Server also sets the I bit in the Map-Notify 1130 and copies the xTR-ID and site-ID from the Map-Register to the 1131 Map-Notify. The source address of this Map-Notify is set to 1132 3.0.0.1. The destination is copied from the local source 1133 address of the Map Register (192.168.1.2), and both source and 1134 destination ports are set to 4342. 1136 11. The RTR receives the ECM-ed Map-Notify and verifies the MS-RTR 1137 authentication data. The RTR data-encapsulates the Map-Notify 1138 and sends the resulting Data-Map-Notify to site1-ETR with a 1139 matching xTR-ID. The outer header source RLOC and port of the 1140 Data-Map-Notify are set to 1.0.0.1:4342. The outer header 1141 destination RLOC and port are retrieved from previously cached 1142 map-cache entry in step 9 namely 2.0.0.2:20002. RTR sets the 1143 Instance ID in the LISP header to 0xFFFFFF. At this point RTR 1144 marks ETR's EID prefix as "Registered" status and forwards the 1145 Data-Map-Notify to ETR. 1147 12. The NAT device translates the destination RLOC and port of the 1148 Data-Map-Notify to 192.168.1.2:4341 and forwards the packet to 1149 ETR. 1151 13. The Site1-ETR receives the packet with a destination port 4341, 1152 and processes the packet as a control packet after observing the 1153 Instance ID value 0xFFFFFF in the LISP header. At this point 1154 ETR's registration to the RTR is complete. 1156 Assume a requesting ITR in a second LISP (site2-ITR) site has an RLOC 1157 of 74.0.0.1. The following is an example process of an EID behind 1158 site2-ITR sending a data packet to an EID behind the site1-ETR: 1160 1. The ITR sends a Map-Request which arrives via the LISP mapping 1161 system to the ETR's Map Server. 1163 2. The Map-Server sends a Map-Reply on behalf of the ETR, using the 1164 RTR's RLOC (1.0.0.1) in the Map-Reply's Locator Set. 1166 3. The ITR encapsulates a LISP data packet with ITR's local RLOC 1167 (74.0.0.1) as the source RLOC and the RTR as the destination RLOC 1168 (1.0.0.1) in the outer header. 1170 4. The RTR decapsulates the packet, evaluates the inner header 1171 against its map-cache and then re-encapsulates the packet. The 1172 new outer header's source RLOC is the RTR's RLOC 1.0.0.1 and the 1173 new outer header's destination RLOC is the Global NAT address 1174 2.0.0.2. The destination port of the packet is set to 20002 1175 (discovered above during the registration phase) and the source 1176 port is 4342. 1178 5. The NAT translates the LISP data packet's destination IP from to 1179 2.0.0.2 to 192.168.1.2, and translates the destination port from 1180 20002 to 4341, and forwards the LISP data packet to the ETR at 1181 192.168.1.2. 1183 6. For the reverse path the ITR uses its local map-cache entry with 1184 the RTR RLOC as the default locator and encapsulates the LISP 1185 data packets using RTR RLOC, and 4341 as destination RLOC and 1186 port. The ITR must pick a random source port to use for all 1187 outbound LISP data traffic in order to avoid creating excessive 1188 state in the NAT. 1190 6. Security Considerations 1192 By having the RTR relay the ECM-ed Map-Register message from an ETR 1193 to its Map-Server, the RTR can restrict access to the RTR services, 1194 only to those ETRs that are registered with a given Map-Server. To 1195 do so, the RTR and the Map-Server may be configured with a shared key 1196 that is used to authenticate the origin and to protect the integrity 1197 of the Map-Notify messages sent by the Map Server to the RTR. This 1198 prevents an on-path attacker from impersonating the Map-Server to the 1199 RTR, and allows the RTR to cryptographically verify that the ETR is 1200 properly registered with the Map-Server. 1202 Having the RTR re-encapsulate traffic only when the source or the 1203 destination are registered EIDs, protects against the adverse use of 1204 an RTR for EID spoofing. 1206 Upon receiving a Data-Map-Notify, an xTR can authenticate the origin 1207 of the Map-Notify message using the key that the ETR shares with the 1208 Map-Server. This enables the ETR to verify that the ECM-ed Map- 1209 Register was indeed forwarded by the RTR to the Map-Server, and was 1210 accepted by the Map-Server. 1212 6.1. Acknowledgments 1214 The authors would like to thank Noel Chiappa, Alberto Rodriguez 1215 Natal, Lorand Jakab, Albert Cabellos, Dominik Klein, Matthias 1216 Hartmann, and Michael Menth for their previous work, feedback and 1217 helpful suggestions. 1219 7. IANA Considerations 1221 This document does not request any IANA actions. 1223 8. Normative References 1225 [I-D.ietf-lisp-eid-mobility] 1226 Portoles-Comeras, M., Ashtaputre, V., Moreno, V., Maino, 1227 F., and D. Farinacci, "LISP L2/L3 EID Mobility Using a 1228 Unified Control Plane", draft-ietf-lisp-eid-mobility-06 1229 (work in progress), May 2020. 1231 [I-D.ietf-lisp-pubsub] 1232 Rodriguez-Natal, A., Ermagan, V., Cabellos-Aparicio, A., 1233 Barkai, S., and M. Boucadair, "Publish/Subscribe 1234 Functionality for LISP", draft-ietf-lisp-pubsub-06 (work 1235 in progress), July 2020. 1237 [I-D.ietf-lisp-rfc6830bis] 1238 Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A. 1239 Cabellos-Aparicio, "The Locator/ID Separation Protocol 1240 (LISP)", draft-ietf-lisp-rfc6830bis-35 (work in progress), 1241 September 2020. 1243 [I-D.ietf-lisp-rfc6833bis] 1244 Farinacci, D., Maino, F., Fuller, V., and A. Cabellos- 1245 Aparicio, "Locator/ID Separation Protocol (LISP) Control- 1246 Plane", draft-ietf-lisp-rfc6833bis-29 (work in progress), 1247 September 2020. 1249 [ICE] Rosenberg, J., "Interactive Connectivity Establishment 1250 (ICE)", RFC rfc5245, October 2008. 1252 [LCAF] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical 1253 Address Format (LCAF)", RFC 8060, December 2015. 1255 [NAT] Srisuresh, P. and M. Holdrege, "IP Network Address 1256 Translator (NAT) Terminology and Considerations", RFC 1257 2663, August 1999. 1259 [NAT-MN] Klein, D., Hartmann, M., and M. Menth, "NAT traversal for 1260 LISP mobile node, In Proceedings of the Re-Architecting 1261 the Internet Workshop (ReARCH '10).", 2010. 1263 [STUN] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 1264 "Session Traversal Utilities for NAT (STUN)", RFC rfc5389, 1265 October 2008. 1267 [TURN] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using 1268 Relays around NAT (TURN)", RFC rfc5766, April 2010. 1270 Authors' Addresses 1272 Vina Ermagan 1273 Google 1275 Email: ermagan@gmail.com 1276 Dino Farinacci 1277 lispers.net 1279 Email: farinacci@gmail.com 1281 Darrel Lewis 1282 Cisco Systems, Inc. 1284 Email: darlewis@cisco.com 1286 Fabio Maino 1287 Cisco Systems, Inc. 1289 Email: fmaino@cisco.com 1291 Marc Portoles Comeras 1292 Cisco Systems, Inc. 1294 Email: mportole@cisco.com 1296 Jesper Skriver 1297 Arista 1299 Email: jesper@skriver.dk 1301 Chris White 1302 Logicalelegance, Inc. 1304 Email: chris@logicalelegance.com 1306 Albert Lopez 1307 UPC/BarcelonaTech 1309 Email: alopez@ac.upc.edu 1311 Albert Cabellos 1312 UPC/BarcelonaTech 1314 Email: acabello@ac.upc.edu