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