idnits 2.17.1 draft-ermagan-lisp-nat-traversal-05.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 24 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 285: '... nonce SHOULD be generated by a p...' RFC 2119 keyword, line 350: '...n xTR-ID or site-ID, it MUST set the I...' RFC 2119 keyword, line 364: '...-zero value), it MUST copy the XTR-ID ...' RFC 2119 keyword, line 405: '...). A Map-Server MUST set the I bit in...' RFC 2119 keyword, line 452: '...ementations of this specification MUST...' (1 more instance...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 13, 2014) is 3696 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'RFC2404' is mentioned on line 453, but not defined == Missing Reference: 'RFC6234' is mentioned on line 454, but not defined == Unused Reference: 'RFC1918' is defined on line 1073, but no explicit reference was found in the text == Unused Reference: 'RFC4632' is defined on line 1077, but no explicit reference was found in the text == Outdated reference: A later version (-22) exists of draft-ietf-lisp-lcaf-03 ** Obsolete normative reference: RFC 6833 (ref. 'LISP-MS') (Obsoleted by RFC 9301) ** Obsolete normative reference: RFC 6830 (ref. 'LISP') (Obsoleted by RFC 9300, RFC 9301) Summary: 3 errors (**), 0 flaws (~~), 8 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 Cisco Systems, Inc. 4 Intended status: Experimental D. Farinacci 5 Expires: August 17, 2014 lispers.net 6 D. Lewis 7 J. Skriver 8 F. Maino 9 Cisco Systems, Inc. 10 C. White 11 Logicalelegance, Inc. 12 February 13, 2014 14 NAT traversal for LISP 15 draft-ermagan-lisp-nat-traversal-05.txt 17 Abstract 19 This document describes a mechanism for IPv4 NAT traversal for LISP 20 tunnel routers (xTR) and LISP Mobile Nodes (LISP-MN) behind a NAT 21 device. A LISP device both detects the NAT and initializes its 22 state. Forwarding to the LISP device through a NAT is enabled by the 23 LISP Re-encapsulating Tunnel Router (RTR) network element, which acts 24 as an anchor point in the data plane, forwarding traffic from 25 unmodified LISP devices through the NAT. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on August 17, 2014. 44 Copyright Notice 46 Copyright (c) 2014 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 3 63 3. Basic Overview . . . . . . . . . . . . . . . . . . . . . . . 4 64 4. LISP RTR Message Details . . . . . . . . . . . . . . . . . . 5 65 4.1. Info-Request Message . . . . . . . . . . . . . . . . . . 5 66 4.2. LISP Info-Reply . . . . . . . . . . . . . . . . . . . . . 7 67 4.3. LISP Map-Register Message . . . . . . . . . . . . . . . . 9 68 4.4. LISP Map-Notify . . . . . . . . . . . . . . . . . . . . . 10 69 4.5. LISP Data-Map-Notify Message . . . . . . . . . . . . . . 11 70 5. Protocol Operations . . . . . . . . . . . . . . . . . . . . . 13 71 5.1. xTR Processing . . . . . . . . . . . . . . . . . . . . . 13 72 5.1.1. ETR Registration . . . . . . . . . . . . . . . . . . 14 73 5.1.2. Map-Request and Map-Reply Handling . . . . . . . . . 15 74 5.1.3. xTR Sending and Receiving Data . . . . . . . . . . . 16 75 5.2. Map-Server Processing . . . . . . . . . . . . . . . . . . 16 76 5.3. RTR Processing . . . . . . . . . . . . . . . . . . . . . 17 77 5.3.1. RTR Data Forwarding . . . . . . . . . . . . . . . . . 19 78 5.4. Example . . . . . . . . . . . . . . . . . . . . . . . . . 20 79 6. Security Considerations . . . . . . . . . . . . . . . . . . . 23 80 6.1. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 24 81 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 82 8. Normative References . . . . . . . . . . . . . . . . . . . . 24 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 85 1. Introduction 87 The Locator/ID Separation Protocol [LISP] defines a set of functions 88 for encapsulating routers to exchange information used to map from 89 Endpoint Identifiers (EIDs) to routable Routing Locators (RLOCs). 90 The assumption that the LISP Tunnel Routers are reachable at their 91 RLOC breaks when a LISP device is behind a NAT. LISP relies on the 92 xTR being able to receive traffic at its RLOC on destination port 93 4341. However nodes behind a NAT are only reachable through the 94 NAT's public address and in most cases only after the appropriate 95 mapping state is set up in the NAT. A NAT traversal mechanism is 96 needed to make the LISP device behind a NAT reachable. 98 This document introduces a NAT traversal mechanism for LISP. Two new 99 LISP control messages - LISP Info-Request and LISP Info-Reply - are 100 introduced in order to detect whether a LISP device is behind a NAT, 101 and discover the global IP address and global ephemeral port used by 102 the NAT to forward LISP packets sent by the LISP device. A new LISP 103 component, the LISP Re-encapsulating Tunnel Router (RTR), acts as a 104 re-encapsulating LISP tunnel router [LISP] to pass traffic through 105 the NAT, to and from the LISP device. A modification to how the LISP 106 Map-Register messages are sent allows LISP device to initialize NAT 107 state to use the RTR services. This mechanism addresses the scenario 108 where the LISP device is behind the NAT, but the associated Map- 109 Server [LISP-MS] is on the public side of the NAT. 111 2. Definition of Terms 113 LISP Info-Request: A LISP control message sent by a LISP device to 114 its Map-Server. 116 LISP Info-Reply: A LISP control message sent by a Map Server to a 117 LISP device in response to an Info-Request control message. 119 LISP Re-encapsulating Tunnel Router (RTR): An RTR is a re- 120 encapsulating LISP Router (see section 8 of the main LISP 121 specification) [LISP]. One function that an RTR provides is 122 enabling a LISP device to traverse NATs. 124 LISP Data-Map-Notify: A LISP Map-Notify message encapsulated in a 125 LISP data header. 127 LISP xTR-ID A 128-bit field that, together with a site-ID, can be 128 appended at the end of a Map-Register or Map-Notify message. An 129 xTR-ID is used as a unique identifier of the xTR that is sending 130 the Map-Register and is especially useful for identifying multiple 131 xTRs serving the same site/EID-prefix. A value of all zeros 132 indicate the xTR-ID is unspecified. 134 LISP site-ID A 64-bit field that, together with a xTR-ID, can be 135 appended at the end of a Map-Register or Map-Notify message. A 136 site-ID is used as a unique identifier of a group of xTRs 137 belonging to the same site. A value of 0 indicate the site-ID is 138 unspecified. 140 NAT: "Network Address Translation is a method by which IP addresses 141 are mapped from one address realm to another, providing 142 transparent routing to end hosts". "Traditional NAT would allow 143 hosts within a private network to transparently access hosts in 144 the external network, in most cases. In a traditional NAT, 145 sessions are uni-directional, outbound from the private network." 146 --RFC 2663 [NAT]. Basic NAT and NAPT are two varieties of 147 traditional NAT. 149 Basic NAT: "With Basic NAT, a block of external addresses are set 150 aside for translating addresses of hosts in a private domain as 151 they originate sessions to the external domain. For packets 152 outbound from the private network, the source IP address and 153 related fields such as IP, TCP, UDP and ICMP header checksums are 154 translated. For inbound packets, the destination IP address and 155 the checksums as listed above are translated." --RFC 2663[NAT]. 157 NAPT: "NAPT extends the notion of translation one step further by 158 also translating transport identifier (e.g., TCP and UDP port 159 numbers, ICMP query identifiers). This allows the transport 160 identifiers of a number of private hosts to be multiplexed into 161 the transport identifiers of a single external address. NAPT 162 allows a set of hosts to share a single external address. Note 163 that NAPT can be combined with Basic NAT so that a pool of 164 external addresses are used in conjunction with port translation." 165 --RFC 2663[NAT]. Transport identifiers of the destination hosts 166 are not modified by the NAPT. 168 In this document the general term NAT is used to refer to both Basic 169 NAT and NAPT. 171 While this document specifies LISP NAT Traversal for LISP tunnel 172 routers, a LISP-MN can also use the same procedure for NAT traversal. 173 The modifications attributed to a LISP-Device, xTR, ETR, and ITR must 174 be supported by a LISP-MN where applicable, in order to achieve NAT 175 traversal for such a LISP node. A NAT traversal mechanism for LISP- 176 MN is also proposed in [NAT-MN]. 178 For definitions of other terms, notably Map-Request, Map-Reply, 179 Ingress Tunnel Router (ITR), and Egress Tunnel Router (ETR), please 180 consult the LISP specification [LISP]. 182 3. Basic Overview 184 There are two attributes of a LISP device behind a typical NAT that 185 requires special consideration in LISP protocol behavior in order to 186 make the device reachable. First, the RLOC assigned to the device is 187 typically not globally unique nor globally routable. Second, the NAT 188 likely has a restrictive translation table and forwarding policy, 189 requiring outbound packets to create state before the NAT accepts 190 inbound packets. This section provides an overview of the LISP NAT 191 traversal mechanism which deals with these conditions. The following 192 sections specify the mechanism in more detail. 194 When a LISP device receives a new RLOC and wants to register it with 195 the mapping system, it needs to first discover whether it is behind a 196 NAT. To do this, an ETR queries its Map-Server to discover the ETR's 197 translated global RLOC and port via the two new LISP messages: Info- 198 Request and Info-Reply. Once an ETR detects that it is behind a NAT, 199 it uses a LISP Re-encapsulating Tunnel Router (RTR) entity as an 200 anchor point for sending and receiving data plane traffic through the 201 NAT device. The ETR registers the RTR RLOC(s) to its Map-Server 202 using the RTR as a proxy for the Map-Register message. The ETR 203 encapsulates the Map-Register message in a LISP ECM header destined 204 to the RTR's RLOC. The RTR strips the LISP ECM header, re-originates 205 the Map-Register message, and sends it to the Map-Server. This 206 initializes state in the NAT device so the ETR can receive traffic on 207 port 4341 from the RTR. The ETR also registers the RTR RLOC as the 208 RLOC where the ETR EID prefix is reachable. As a result, all packets 209 destined to the ETR's EID will go to its RTR. The RTR will then re- 210 encapsulate and forward the ETR's traffic via the existing NAT state 211 to the ETR. 213 Outbound LISP data traffic from the xTR is also encapsulated to the 214 RTR, where the RTR de-capsulates the LISP packets, and then re- 215 encapsulates them or forwards them natively depending on their 216 destination. 218 In the next sections these procedures are discussed in more detail. 220 4. LISP RTR Message Details 222 The main modifications in the LISP protocol to enable LISP NAT 223 traversal via an RTR include: (1) two new messages used for NAT 224 discovery (Info-Request and Info-Reply), and (2) encapsulation of two 225 LISP control messages (Map-Register and Map-Notify) between the xTR 226 and the RTR. Map-Register is encapsulated in an ECM header while 227 Map-Notify is encapsulated in a LISP data header (Data-Map-Notify). 228 This section describes the message formats and details of the Info- 229 Request, Info-Reply, and Data-Map-Notify messages, as well as 230 encapsulation details and minor changes to Map-Register and Map- 231 Notify messages. 233 4.1. Info-Request Message 235 An ETR sends an Info-Request message to its Map-Server in order to 237 1. detect whether there is a NAT on the path to its Map-Server 239 2. obtain a list of RTR RLOCs that can be used for LISP data plane 240 NAT traversal. 242 An Info-Request message is a LISP control message, its source port is 243 chosen by the xTR and its destination port is set to 4342. 245 0 1 2 3 246 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 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 |Type=7 |R| Reserved | 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 | Nonce . . . | 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 | . . . Nonce | 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 | Key ID | Authentication Data Length | 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 ~ Authentication Data ~ 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 | TTL | 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 | Reserved | EID mask-len | EID-prefix-AFI | 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 262 | EID-prefix | 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 | AFI = 0 | | 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 LISP Info-Request Message Format 269 Type: 7 (Info-Request) 271 R: R bit indicates this is a reply to an Info-Request (Info- 272 Reply). R bit is set to 0 in an Info-Request. When R bit is set 273 to 0, the AFI field (following the EID-prefix field) must be set 274 to 0. When R bit is set to 1, the packet contents follow the 275 format for an Info-Reply, as described below. 277 Reserved: Must be set to 0 on transmit and must be ignored on 278 receipt. 280 TTL: The time in minutes the recipient of the Info-Reply will 281 store the RTR Information. 283 Nonce: An 8-byte random value created by the sender of the Info- 284 Request. This nonce will be returned in the Info-Reply. The 285 nonce SHOULD be generated by a properly seeded pseudo-random (or 286 strong random) source. 288 Descriptions for other fields can be found in the Map-Register 289 section of the main LISP draft [LISP]. Field descriptions for the 290 LCAF AFI = 0 can be found in the LISP LCAF draft [LCAF] . 292 4.2. LISP Info-Reply 294 When a Map-Server receives an Info-Request message, it responds with 295 an Info-Reply message. The Info-Reply message source port is 4342, 296 and destination port is taken from the source port of the triggering 297 Info-Request. Map-Server fills the NAT LCAF (LCAF Type = 7) fields 298 according to their description. The Map-Server uses AFI=0 for the 299 Private ETR RLOC Address field in the NAT LCAF. 301 0 1 2 3 302 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 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 |Type=7 |R| Reserved | 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 | Nonce . . . | 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 308 | . . . Nonce | 309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 310 | Key ID | Authentication Data Length | 311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 312 ~ Authentication Data ~ 313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 314 | TTL | 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 | Reserved | EID mask-len | EID-prefix-AFI | 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 | EID-prefix | 319 +->+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 | | AFI = 16387 | Rsvd1 | Flags | 321 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 | | Type = 7 | Rsvd2 | 4 + n | 323 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 324 N | MS UDP Port Number | ETR UDP Port Number | 325 A +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 T | AFI = x | Global ETR RLOC Address ... | 327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 328 L | AFI = x | MS RLOC Address ... | 329 C +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 330 A | AFI = x | Private ETR RLOC Address ... | 331 F +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 | | AFI = x | RTR RLOC Address 1 ... | 333 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 334 | | AFI = x | RTR RLOC Address n ... | 335 +->+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 LISP Info-Reply Message Format 339 Type: 7 , R = 1, (Info-Reply) 341 The format is similar to the Info-Request message. See Info-Request 342 section for field descriptions. Field descriptions for the NAT LCAF 343 section can be found in the LISP LCAF draft [LCAF] . 345 4.3. LISP Map-Register Message 347 The third bit after the Type field in the Map-Register message is 348 allocated as "I" bit. I bit indicates that a 128 bit xTR-ID and a 64 349 bit site-ID field are present at the end of the Map-Register message. 350 If an xTR is configured with an xTR-ID or site-ID, it MUST set the I 351 bit to 1 and include its xTR-ID and site-ID in the Map-Register 352 messages it generates. If either the xTR-ID or site-ID is not 353 configured an unspecified value is encoded for whichever ID that is 354 not configured. 356 xTR-ID is a 128 bit field at the end of the Map-Register message, 357 starting after the final Record in the message. The xTR-ID is used 358 to identify the intended recipient xTR for a Map-Notify message, 359 especially in the case where a site has more than one xTR. A value 360 of all zeros indicate that an xTR-ID is not specified, though encoded 361 in the message. This is useful in the case where a site-ID is 362 specified, but no xTR-ID is configured. When a Map-Server receives a 363 Map-Register with an xTR-ID specified (I bit set and xTR-ID has a 364 non-zero value), it MUST copy the XTR-ID from the Map-Register to the 365 associated Map-Notify message. When a Map-Server is sending an 366 unsolicited Map-Notify to an xTR to notify the xTR of a change in 367 locators, the Map-Server must include the xTR-ID for the intended 368 recipient xTR, if it has one stored locally. 370 site-ID is a 64 bit field at the end of the Map-Register message, 371 following the xTR-ID. site-ID is used by the Map-Server receiving the 372 Map-Register message to identify which xTRs belong to the same site. 373 A value of 0 indicate that a site-ID is not specified, though encoded 374 in the message. When a Map-Server receives a Map-Register with a 375 site-ID specified (I bit set and site-ID has non-zero value), it must 376 copy the site-ID from the Map-Register to the associated Map-Notify 377 message. When a Map-Server is sending an unsolicited Map-Notify to 378 an xTR to notify the xTR of a change in locators, the Map-Server must 379 include the site-ID for the intended recipient xTR, if it has one 380 stored locally. 382 A LISP device that sends a Map-Register to an RTR must encapsulate 383 the Map-Register message using an Encapsulated Control Message (ECM) 384 [LISP]. The 6th bit in the ECM LISP header is allocated as the "R" 385 bit. The R bit indicates that the encapsulated Map-Register is to be 386 processed by an RTR. The 7th bit in the ECM header is allocated as 387 the "N" bit. The N bit indicates that this Map-REgister is being 388 relayed by an RTR. When an RTR relays the ECM-ed Map-Register to a 389 Map-Server, the N bit must be set to 1. 391 The outer header source RLOC of the ECM is set to the LISP device's 392 local RLOC, and the outer header source port is set to 4341. The 393 outer header destination RLOC and port are set to RTR RLOC and 4342 394 respectively. The inner header source RLOC is set to LISP device's 395 local RLOC, and the inner source port is picked at random. The inner 396 header destination RLOC is set to the xTR's Map-Server RLOC, and 397 inner header destination port is set to 4342. 399 4.4. LISP Map-Notify 401 The first bit after the Type field in a Map-Notify message is 402 allocated as the "I" bit. I bit indicates that a 128 bit xTR-ID and 403 64 bit site-ID field is present at the end of the Map-Notify message, 404 following the final Record in the Map-Notify (See Section 4.3 for 405 details on xTR-ID and site-ID). A Map-Server MUST set the I bit in a 406 Map-Notify and include the xTR-ID and/or site-ID of the intended 407 recipient xTR if the associated Map-Register has an xTR-ID and/or 408 site-ID specified, or when the Map-Server has previously cached an 409 xTR-ID and/or site-ID for the destination xTR. 411 A LISP device that sends a Map-Notify to an RTR must encapsulate the 412 Map-Notify message using an ECM. the 6th bit in the ECM LISP header, 413 allocated as the "R" bit, must be set when the encapsulated Map- 414 Notify is to be processed by an RTR. If the S bit is also set in the 415 Map-Notify ECM header, it indicates that additional MS-RTR 416 authentication data is included after the LISP header in the ECM. If 417 the I bit is also set in the Map-Notify, the xTR-ID and site-ID 418 fields are included in the Map-Notify. If a Map-Server receiving an 419 ECM-ed Map-Register has a shared key associated with the sending RTR, 420 it must generate a Map-Notify message with the S bit in the ECM 421 header set to 1, and with the additional MS-RTR authentication 422 related fields described below. 424 0 1 2 3 425 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 426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 427 |AD Type| Reserved | 428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 429 | MS-RTR Key ID | MS-RTR Auth. Data Length | 430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 431 ~ MS-RTR Authentication Data ~ 432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 434 Changes to LISP Map-Notify Message 436 AD Type: 2 (RTR Authentication Data) 438 MS-RTR Key ID: A configured ID to find the configured Message 439 Authentication Code (MAC) algorithm and key value used for the 440 authentication function. See [LISP] section 14.4 for code point 441 assignments. 443 MS-RTR Authentication Data Length: The length in bytes of the MS-RTR 444 Authentication Data field that follows this field. The length of the 445 Authentication Data field is dependent on the Message Authentication 446 Code (MAC) algorithm used. The length field allows a device that 447 doesn't know the MAC algorithm to correctly parse the packet. 449 MS-RTR Authentication Data: The message digest used from the output 450 of the Message Authentication Code (MAC) algorithm. The entire Map- 451 Notify payload is authenticated. After the MAC is computed, it is 452 placed in this field. Implementations of this specification MUST 453 support HMAC-SHA-1-96 [RFC2404] and SHOULD support HMAC-SHA-256-128 454 [RFC6234]. 456 For a full description of all fields in the Map-Notify message refer 457 to Map-Notify section in the main LISP draft [LISP]. 459 4.5. LISP Data-Map-Notify Message 461 When an RTR receives an ECM-ed Map-Notify message with R bit in the 462 ECM header set to 1, it has to relay the Map-Notify payload to the 463 registering LISP device. After removing the ECM header and 464 processing the Map-Notify message as described in Section 5.3, the 465 RTR encapsulates the Map-Notify in a LISP data header and sends it to 466 the associated LISP device. This Map-Notify inside a LISP data 467 header is referred to as a Data-Map-Notify message. 469 0 1 2 3 470 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 471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 472 / | IPv4 or IPv6 Header | 473 OH | (uses RLOC addresses) | 474 \ | | 475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 476 / | Source Port = 4342 | Dest Port = xxxx | 477 UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 478 \ | UDP Length | UDP Checksum | 479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 480 L | LISP Header ~ | 481 I \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 482 S / | ~ LISP Header | 483 P +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 484 / | IPv4 or IPv6 Header | 485 IH | (uses RLOC or EID addresses) | 486 \ | | 487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 488 / | Source Port = 4342 | Dest Port = 4342 | 489 UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 490 \ | UDP Length | UDP Checksum | 491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 492 LCM | LISP Map-Notify Message ~ 493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 495 LISP Data-Map-Notify Message 497 In a Data-Map-Notify, the outer header source RLOC is set to the 498 RTR's RLOC that was used in the associated Map-Register. This is 499 previously cached by the RTR. The outer header source port is set to 500 4342. The outer header destination RLOC and port are filled based on 501 the translated global RLOC and port of the registering LISP device 502 previously stored locally at the RTR. The inner header source 503 address is Map-Server's RLOC, and inner header source port is 4342. 504 The inner header destination address is set to the LISP device's 505 local RLOC also previously cached by the RTR (See Section 5.3 for 506 details.). The inner header destination port is 4342. 508 Since a Data-Map-Notify is a control message encapsulated in a LISP 509 data header, a special Instance ID is used as a signal for the xTR to 510 trigger processing of the control packet inside the data header. The 511 Instance ID value 0xFFFFFF is reserved for this purpose. The 512 Instance ID field in a Data-Map-Notify must be set to 0xFFFFFF. 514 5. Protocol Operations 516 There are two main steps in the NAT traversal procedure. First, the 517 ETR's translated global RLOC must be discovered. Second, the NAT 518 translation table must be primed to accept incoming connections. At 519 the same time, the Map-Server and the RTR must be informed of the 520 ETR's translated global RLOC including the translated ephemeral port 521 number(s) at which the Map-Server and RTR can reach the LISP device. 523 5.1. xTR Processing 525 Upon receiving a new local RLOC, an ETR first has to detect whether 526 the new RLOC is behind a NAT device. For this purpose the ETR sends 527 an Info-Request message to its Map-Server in order to discover the 528 ETR's translated global RLOC as it is visible to the Map-Server. The 529 ETR uses its new local RLOC as the source RLOC of the message. The 530 Map-Server, after authenticating the message, responds with an Info- 531 Reply message. The Map-Server includes the source RLOC and port from 532 the Info-Request message in the Global ETR RLOC Address and ETR UDP 533 Port Number fields of the Info-Reply. The Map Server also includes 534 the destination RLOC and port number of the Info-Request message in 535 the MS RLOC Address and MS UDP Port Number fields of the Info-Reply. 536 In addition, the Map-Server provides a list of RTR RLOCs that the ETR 537 may use in case it needs NAT traversal services. The source port of 538 the Info-Reply is set to 4342 and the destination port is copied from 539 the source port of the triggering Info-Request message. 541 Upon receiving the Info-Reply message, the ETR compares the source 542 RLOC and source port used for the Info-Request message with the 543 Global ETR RLOC Address and ETR UDP Port Number fields of the Info- 544 Reply message. If the two are not identical, the ETR concludes that 545 its new local RLOC is behind a NAT and that it requires an RTR for 546 NAT traversal services in order to be reachable at that RLOC. An ETR 547 behind other statefull devices (e.g. statefull firewalls) may also 548 use an RTR and the procedure specified here for traversing the 549 statefull device. Detecting existence of such devices are beyond 550 scope of this document. 552 In the case where an xTR has multiple RLOCs, info-Requests must be 553 sent per each RLOC and the state and processes described below must 554 be followed per each RLOC. The RLOCs included in Map-Register 555 messages in such cases will be the union of the locators resulting 556 from the process below per each RLOC of the xTR, according to the 557 specifics of that interface (whether it is behind the NAT or not). 559 If there is no NAT on the path identified by an info-Request and an 560 Info-Reply, the ETR registers the associated RLOC with its Map-Server 561 as described in the main LISP draft [LISP]. 563 5.1.1. ETR Registration 565 Once an ETR has detected that it is behind a NAT, based on local 566 policy the ETR selects one (or more) RTR(s) from the RTR RLOCs 567 provided in the Info-Reply and initializes state in the NAT device in 568 order to receive LISP data traffic on UDP port 4341 from the selected 569 RTR. To do so, the ETR sends a Map-Register encapsulated in an ECM 570 header to the selected RTR(s). The Map-Register message is created 571 as specified in [LISP]. More specifically, the source RLOC of the 572 Map-Register is set to ETR's local RLOC, while the destination RLOC 573 is set to the ETR's Map-Server RLOC, and destination port is set to 574 4342. The ETR sets the M bit in Map-Register to 1, and it includes 575 the selected RTR RLOC(s) as the locators in the Map-Register message. 576 The ETR can also include its local RLOCs as locators in the Map- 577 Register, including weight and priorities, while setting the R bit to 578 0 for each local RLOC. This can be used by the RTR for load 579 balancing when forwarding data to a multi-homed xTR behind a NAT. 580 The R bit is set to 1 for all RTR locators included in the Map- 581 Register. The ETR must also set the I bit in the Map-Register 582 message to 1 and include its xTR-ID in t he corresponding field. In 583 the ECM header of this Map-Register the source RLOC is set to ETR's 584 local RLOC and the source port is set to 4341, while the destination 585 RLOC is the RTR's RLOC and the destination port is set to LISP 586 control port 4342. The R bit in the ECM header is also set to 1, to 587 indicate that this EDCM-ed Map-Register is to be processed by an RTR. 589 This ECM-ed Map-Register is then sent to the RTR. The RTR removes 590 the EMC header, re-originates the Map-Register message, encapsulates 591 the new Map-Register in a new ECM header with R bit set to 0, and 592 sends it to the associated Map-Server. The RTR then encapsulates the 593 corresponding Map-Notify message in a LISP data header (Data-Map- 594 Notify) and sends it back to the xTR. 596 Upon receiving a Data-Map-Notify from the RTR, the ETR must strip the 597 outer LISP data header, and process the inner Map-Notify message as 598 described in [LISP]. Since outer header destination port in Data- 599 Map-Notify is set to LISP data port 4341, the Instance ID 0xFFFFFF in 600 the LISP header of the Data-Map-Notify is used by the ETR to detect 601 and process the Data-Map-Notify as a control message encapsulated in 602 a LISP data header. While processing the Data-Map-Notify, the xTR 603 also stores the RTR RLOC(s) as its data plane proxy, by storing a 604 default map-cache entry with the RTR RLOC(s) as its locator set. The 605 xTR may map the EID prefix 0/0 to this RTR RLOC(s). This results in 606 the xTR encapsulating all LISP data plane traffic to this RTR. At 607 this point the registration and state initialization is complete and 608 the xTR can use the RTR services. The state created in the NAT 609 device based on the ECM-ed Map-Register and corresponding Data-Map- 610 Notify is used by the xTR behind the NAT to send and receive LISP 611 control packets to/from the RTR, as well as for receiving LISP data 612 packets form the RTR. 614 If ETR receives a Data-Map-Notify with a xTR-ID specified, but the 615 xTR-ID is not equal to its local xTR-ID, it must log this as an 616 error. The ETR should discard such Data-Map-Notify message. 618 The ETR must periodically send ECM-ed Map-Register messages to its 619 RTR in order to both refresh its registration to the RTR and the Map- 620 Server, and as a keep alive in order to preserve the state in the NAT 621 device. RFC 2663 [NAT] points out that the period for sending the 622 keep alives can be set to default value of two minutes, however since 623 shorter timeouts may exist in some NAT deployments, the interval for 624 sending periodic ECM-ed Map-Registers must be configurable. 626 5.1.2. Map-Request and Map-Reply Handling 628 The ETR is in control of how to handle the Map-Requests and Map- 629 Replies. If the ETR wants the Map-Server to proxy-reply as described 630 in [LISP], it can register the RTR RLOC(s) as its locator via the 631 ECM-ed Map-Register message. In this case, if the proxy bit is set 632 in the Map-Register, the Map-Server will proxy reply with RTR's RLOC 633 to all Map-Requests for the ETR. As a result all traffic for the ETR 634 is encapsulated to its RTR(s). 636 If the proxy bit in the ECM-ed Map-Register message is not set, and 637 the ETR chooses to receive Map-Requests, the ETR must also initiate 638 and preserve state in the NAT device to receive LISP control packets 639 from its Map-Server. To do this, the ETR must periodically send 640 Info-Request messages to its Map-Server, and receive Info-Reply 641 messages from the Map-Server. As pointed in RFC 2663 [NAT] the 642 default assumption of two minute period for session lifetime can be 643 used, however since shorter timeouts may exist in some NAT 644 deployments, the interval for sending periodic Info-Requests must be 645 configurable. Furthermore, the ETR must also provide its Map-Server 646 with the ETR's translated global RLOC and port as visible to the Map- 647 Server. To do this, ETR includes a copy of the NAT LCAF section of 648 the Info-Reply message as one of the locators in its Map-Register 649 along with the RTR(s) RLOC(s). The ETR can set the priorities of RTR 650 RLOC(s) in this Map-Register to 255, resulting in the Map Server 651 encapsulating Map-Requests to the ETR's translated global RLOC and 652 port so it can receive them through the NAT device. 654 If an ETR behind a NAT chooses to receive Map-Requests from the Map- 655 Server, it must send Map-Replies to requesting ITRs. Note that this 656 configuration will result in excessive state in the NAT device and is 657 not recommended. ETR must include its RTR RLOC(s) as its locator set 658 in the Map-Reply in order to receive data through the NAT device. 660 When an ITR behind a NAT is encapsulating outbound LISP traffic, it 661 must use its RTR RLOC as the locator for all destination EIDs that it 662 wishes to send data to. As such, the ITR does not need to send Map- 663 Requests for the purpose of finding EID-to-RLOC mappings. For RLOC- 664 probing, the periodic ECM-ed Map-Register and Data-Map-Notify 665 messages between xTR and RTR can also serve the purpose of RLOC 666 probes. However, if RLOC-probing is used, no changes are required to 667 the RLOC-probing specification in [LISP], except that the LISP device 668 behind a NAT only needs to probe the RTR's RLOC. 670 5.1.3. xTR Sending and Receiving Data 672 When a Map-Request for a LISP device behind a NAT is received by its 673 Map-Server or the LISP device itself, the Map-Server, or the LISP 674 device (ETR), responds with a Map-Reply including RTR's RLOC as the 675 locator for the requested EID. As a result, all LISP data traffic 676 destined for the ETR's EID behind the NAT is encapsulated to its RTR. 677 The RTR re-encapsulates the LISP data packets to the ETR's translated 678 global RLOC and port number so the data can pass through the NAT 679 device and reach the ETR. As a result the ETR receives LISP data 680 traffic with outer header destination port set to 4341 as specified 681 in [LISP]. 683 For sending outbound LISP data, an ITR behind a NAT must use the RTR 684 RLOC as the locator for all EIDs that it wishes to send data to 685 according to the installed default map-cache entry. The ITR then 686 encapsulates the LISP traffic in a LISP data header with outer header 687 destination set to RTR RLOC and outer header destination port set to 688 4341. This may create a secondary state in the NAT device. ITR must 689 set the outer header source port in all egress LISP data packets to a 690 random but static port number in order to avoid creating excessive 691 state in the NAT device. 693 If the ITR and ETR of a site are not collocated, the RTR RLOC must be 694 configured in the ITR via an out-of-band mechanism. Other procedures 695 specified here would still apply. 697 5.2. Map-Server Processing 699 Upon receiving an Info-Request message a Map-Server first verifies 700 the authenticity of the message. Next the Map-Server creates an 701 Info-Reply message and copies the source RLOC and port number of the 702 Info-Request message to the Global ETR RLOC Address and ETR UDP Port 703 Number fields of the Info-Reply message. The Map-Server also 704 includes a list of RTR RLOCs that the ETR may use for NAT traversal 705 services. The Map-Server sends the Info-Reply message to the ETR, by 706 setting the destination RLOC and port of the Info-Reply to the source 707 RLOC and port of the triggering Info-Request. The Map-Server sets 708 the source port of the Info-Reply to 4342. 710 Upon receiving an ECM-ed Map-Register message with the N bit in the 711 ECM header set to 1, the Map-Server removes the ECM header and if the 712 M bit in the Map-Register is set, the Map-Server processes the Map- 713 Register message and generates the resulting Map-Notify as described 714 in [LISP]. The Map-Server encapsulates the Map-Notify in an ECM 715 header and sets the R bit in the ECM header to 1. This indicates 716 that the ECM-ed Map-Notify is to be processed by an RTR. If the Map- 717 Server has a shared secret configured with the RTR sending the Map- 718 Register, the Map-Server also sets the S bit in the ECM header of the 719 Map-Notify and includes the MS-RTR authentication data after the ECM 720 LISP header. See Security Considerations Section for more details. 721 If the I bit is set in the Map-Register message, the Map-Server also 722 locally stores the xTR-ID from the Map-Register, and sets the I bit 723 in the corresponding Map-Notify message and includes the same xTR-ID 724 in the Map-Notify. The ECM-ed Map-Notify is then sent to the RTR 725 sending the corresponding Map-Register. 727 If a Map-Server is forwarding Map-Requests to an ETR which has 728 registered its RLOC in a NAT LCAF, Map-Server must use the ETR Global 729 RLOC Address and ETR UDP Port as the destination RLOC and port for 730 outer header of the encapsulated Map-Requests. If more than one NAT 731 LCAF is registered for the same EID prefix, the Map-Server must use 732 the NAT LCAF corresponding to the RLOC of this Map-Server. 734 5.3. RTR Processing 736 Upon receiving an ECM-encapsulated Map-Register with the R bit set in 737 the ECM header, the RTR creates a map-cache entry for the EID-prefix 738 that was specified in the Map-Register message. The RTR stores the 739 outer header source RLOC and outer header source port, the outer 740 header destination RLOC (RTR's own RLOC), the inner header source 741 RLOC (xTR's local RLOC), the xTR-ID, the weight and priority 742 associated with the xTR's local RLOC that was used to send this Map- 743 Register if present, and the nonce field of the Map-Register in this 744 local map-cache entry. The RTR uses the inner header source address 745 to identify which xTR local RLOC (R bit =0) was used by the xTR to 746 send this Map-Register. The outer header source RLOC and outer 747 header source port is the ETR's translated global RLOC and port 748 number visible to the RTR. Once the registration process is 749 complete, this map-cache entry can be used to send LISP data traffic 750 to the ETR. The inner header source RLOC of the Map-Register is the 751 ETR's local RLOC behind the NAT, and the outer header destination 752 RLOC is the RTR's RLOC used by the ETR. The RTR can later use these 753 fields as the inner header destination RLOC and source RLOC 754 correspondingly, for sending data-encapsulated control messages 755 (Data-Map-Notify) back to the ETR. The nonce field is used for 756 security purposes and is matched with the nonce field in the 757 corresponding Map-Notify message. This map-cache entry is stored as 758 an "unverified" mapping, until the corresponding Map-Notify message 759 is received. 761 In the cases where the xTR has multiple RLOCs behind the NAT, and 762 requires the RTR to load balance the traffic across those interfaces, 763 the xTR must include the local RLOCs associated with each interface 764 behind the NAT with the R bit in the locator record set to 0 in the 765 ECM-ed Map-Register sent to the RTR. The RTR uses the weight and 766 priority policies of the RLOCs with R=0 in the Map-Register to load 767 balance the traffic from the RTR to the xTR behind the NAT. The RTR 768 compares the RLOCs with the R bit set to 0 in the Map-Register to the 769 inner header source address of the Map-Register to find the matching 770 RLOC that the xTR used to send the Map-Register from. The RTR 771 associates the weight and priority policies of this local RLOC with 772 the NAT-translated RLOC and xTR-ID for this map-cache entry. For all 773 other local RLOCs included in the Map-Register, that the Map-Register 774 is not originating from, the RTR only updates previously cached 775 weight and priority policies if it already has those local RLOCs 776 previously stored for that EID prefix and xTR-ID. In other words, 777 the RTR only adds new local RLOCs and their weight and priority 778 policies to its cache if the Map-Register is actually originating 779 from that RLOC. The TTL for every map-cache is also only updated 780 when a Map-Register is originating from the same RLOC. However, the 781 weight and priorities of all previously cached local RLOCs will be 782 updated by every Map-Register, whether it is originating from that 783 RLOC or not. The xTR-ID is used to define the Merge domain for these 784 RLOCs. In other words, a Map-Register originating from a unique xTR- 785 ID will always overwrite previously stored policies for that xTR-ID. 786 However it does not modify in any way the policies indicated by any 787 other xTR-ID serving the same EID prefix. As a result, in the case 788 of a renumbering or xTR reboot, the xTR uses its unique xTR-ID to 789 send a new Map-Register, overwriting the previously stored policies 790 for that xTR. Using this method the xTR can immediately remove any 791 RLOCs from the RTR cache that are no longer active. In order to 792 implement this, the RTR must compare the list of local RLOCs in the 793 Map-Register (R=0) with the ones it has previously cached associated 794 with the same xTR-ID. If there is any RLOC previously cached that 795 does not appear in the newly received Map-Register, the RTR must 796 remove that RLOC together with the associated translated RLOC and 797 associated policies, because removal of a local (behind-the-NAT) RLOC 798 also invalidates the NAT-ed address associated with it. . 800 After filling the local map-cache entry, the RTR strips the outer 801 header and extracts the Map-Register message, re-originates the 802 message by rewriting the source RLOC of the Map-Register to RTR's 803 RLOC, encapsulated in a new ECM header with the R bit set to 0, and N 804 bit set to 1, and sends the ECM-ed Map-Register to destination Map- 805 Server. 807 Map-Server responds with a ECM-ed Map-Notify message to the RTR. 809 Upon receiving an ECM-ed Map-Notify message with R bit set to 1 in 810 the ECM header, if the S bit in ECM header is set to 1, RTR uses the 811 MS-RTR Key ID to verify the MS-RTR Authentication Data included after 812 the ECM header. If the MS-RTR authentication fails, the RTR must 813 drop the packet. Once the authenticity of the message is verified, 814 RTR can confirm that the Map-Register message for the ETR with the 815 matching xTR-ID was accepted by the Map-Server. At this point the 816 RTR can change the state of the associated map-cache entry to 817 verified for the duration of the Map-Register TTL. 819 The RTR then uses the information in the associated map-cache entry 820 to create a Data-Map-Notify message according to the following 821 procedure: RTR rewrites the inner header destination RLOC of the Map- 822 Notify message to ETR's local RLOC. Inner header destination port is 823 4342. The RTR encapsulates the Map-Notify in a LISP data header, 824 where the outer header destination RLOC and port number are set to 825 the ETR's translated global RLOC and port number. If more than one 826 ETR translated RLOC and port exists in the map-cache entry for the 827 same EID prefix specified in the Map-Notify, the RTR can use the xTR- 828 ID from the Map-Notify to identify which ETR is the correct 829 destination for the Data-Map-Notify. The RTR sets the outer header 830 source RLOC to RTR's RLOC from the map-cache entry and the outer 831 header source port is set to 4342. The RTR also sets the Instance ID 832 field in the LISP header of the Data-Map-Notify to 0xFFFFFF. The RTR 833 then sends the Data-Map-Notify to the ETR. 835 If the S bit is set to 0 in the ECM header of the Map-Notify, and the 836 RTR has a shared key configured locally with the sending Map-Server, 837 the RTR must drop the packet. If the S bit is set to 0, and the RTR 838 does not have a shared key configured with the associated Map-Server, 839 according to local policy, the RTR may drop the packet. If the Map- 840 Notify with S bit set to 0 is processed, the RTR must match the nonce 841 field from this Map-Notify with the nonce stored in the local map- 842 cache entry with the matching xTR-ID. If the nonces do not match, 843 the RTR must drop the packet. 845 5.3.1. RTR Data Forwarding 847 For all LISP data packets encapsulated to RTR's RLOC and outer header 848 destination port 4341, the RTR first verifies whether the source or 849 destination EID is a previously registered EID. If so, the RTR must 850 process the packet according to the following. If the destination or 851 source EID is not a registered EID, the RTR can drop or process the 852 packets based on local policy. 854 In the case where the destination EID is a previously registered EID, 855 the RTR must strip the LISP data header and re-encapsulate the packet 856 in a new LISP data header. The outer header RLOCs and UDP ports are 857 then filled based on the matching map-cache entry for the associated 858 destination EID prefix. The RTR uses the RTR RLOC from the map-cache 859 entry as the outer header source RLOC. The outer header source port 860 is set to 4342. The RTR sets the outer header destination RLOC and 861 outer header destination port based on the ETR translated global RLOC 862 and port stored in the map-cache entry. Then the RTR forwards the 863 LISP data packet. 865 In the case where the source EID is a previously registered EID, the 866 RTR process the packet as if it is a Proxy ETR (PETR). The RTR must 867 strip the LISP data header, and process the packet based on its inner 868 header destination address. The packet may be forwarded natively, it 869 may be LISP encapsulated to the destination ETR, or it may trigger 870 the RTR to send a LISP Map-Request. 872 5.4. Example 874 What follows is an example of an ETR initiating a registration of a 875 new RLOC to its Map-Server, when there is a NAT device on the path 876 between the ETR and the Map-Server. 878 In this example, the ETR (site1-ETR) is configured with the local 879 RLOC of 192.168.1.2. The NAT's global (external) addresses are from 880 2.0.0.1/24 prefix. The Map-Server is at 3.0.0.1. And one potential 881 RTR has an IP address of 1.0.0.1. The site1-ETR has an EID Prefix of 882 128.1.0.0/16. 884 An example of the registration process follows: 886 1. The Site1-ETR receives the private IP address, 192.168.1.2 as 887 its RLOC via DHCP. 889 2. The Site1-ETR sends an Info-Request message with the destination 890 RLOC of the Map-Server, 3.0.0.1, and source RLOC of 192.168.1.2. 891 This packet has the destination port set to 4342 and the source 892 port is set to (for example) 5001. 894 3. The NAT device translates the source IP from 192.168.1.2 to 895 2.0.0.1, and source port to (for example) 20001 global ephemeral 896 source port. 898 4. The Map-Server receives and responds to this Info-Request with 899 an Info-Reply message. This Info-Reply has the destination 900 address set to ETR's translated address of 2.0.0.1 and the 901 source address is the Map-Server's RLOC, namely 3.0.0.1. The 902 destination port is 20001 and the source port is 4342. Map- 903 Server includes a copy of the source address and port of the 904 Info-Request message (2.0.0.1:20001), and a list of RTR RLOCs 905 including RTR RLOC 1.0.0.1 in the Info-Reply contents. 907 5. The NAT translates the Info-Reply packet's destination IP from 908 2.0.0.1 to 192.168.1.2, and translates the destination port from 909 20001 to 5001, and forwards the Info-Reply to site1-ETR at 910 192.168.1.2. 912 6. The Site1-ETR detects that it is behind a NAT by comparing its 913 local RLOC (192.168.1.2) with the Global ETR RLOC Address in the 914 Info-Reply (2.0.0.2) . Then site1-ETR picks the RTR 1.0.0.1 from 915 the list of RTR RLOCs in the Info-Reply. ETR stores the RTR 916 RLOC in a default map-cache entry to periodically send ECM-ed 917 Map-Registers to. 919 7. The ETR sends an ECM encapsulated Map-Register to RTR at 920 1.0.0.1. The outer header source RLOC of this Map-Register is 921 set to 192.168.1.2 and the outer header source port is set to 922 4341. The outer header destination RLOC and port are set to RTR 923 RLOC at 1.0.0.1 and 4342 respectively. The R bit in ECM header 924 is set to 1. The inner header destination RLOC is set to ETR's 925 Map-Server 3.0.0.1, and the inner header destination port is set 926 to 4342. The inner header source RLOC is set to ETR's local 927 RLOC 192.168.1.2. In the Map-Register message the RTR RLOC 928 1.0.0.1 appears as the locator set for the ETR's EID prefix 929 (128.1.0.0/16). In this example ETR also sets the Proxy bit in 930 the Map-Register to 1, and sets I bit to 1, and includes its 931 xTR-ID in the Map-Register. 933 8. The NAT translates the source RLOC in the ECM header of the Map- 934 Register, by changing it from 192.168.1.2 to 2.0.0.2, and 935 translates the source port in the ECM header from 4341 to (for 936 example) 20002, and forwards the Map-Register to RTR. 938 9. The RTR receives the Map-Register and creates a map-cache entry 939 with the ETR's xTR-ID, EID prefix, and the source RLOC and port 940 of the ECM header of the Map-Register as the locator (128.1.0.0/ 941 16 is mapped to 2.0.0.2:20002). RTR also caches the inner 942 header source RLOC of the Map-Register namely 192.168.1.2, and 943 the outer header destination RLOC of the ECM header in the Map- 944 Register (this would be RTR's RLOC 1.0.0.1 ) to use for sending 945 back a Data-Map-Notify. RTR then removes the outer header, re- 946 writes the source RLOC of the Map-Register message to its own 947 RLOC 1.0.0.1, adds a new ECM header with R=0, and N=1, and 948 forwards the Map-Register to the destination Map-Server. 950 10. The Map-Server receives the ECM-ed Map-Register with N bit set 951 to 1, removes the ECM header, and processes it according to 952 [LISP]. Since Map-Server has a shared secret with the sending 953 RTR, after registering the ETR, Map-Server responds with a ECM- 954 ed Map-Notify with the R bit and S bit both set to 1 in the ECM 955 header and including the MS-RTR authentication data. Since the 956 I bit is set in the Map-Register, the Map-Server also sets the I 957 bit in the Map-Notify and copies the xTR-ID from the Map- 958 Register to the Map-Notify. The source address of this Map- 959 Notify is set to 3.0.0.1. The destination is RTR 1.0.0.1, and 960 both source and destination ports are set to 4342. 962 11. The RTR receives the ECM-ed Map-Notify and verifies the MS-RTR 963 authentication data. The RTR data-encapsulates the Map-Notify 964 and sends the resulting Data-Map-Notify to site1-ETR with a 965 matching xTR-ID. The outer header source RLOC and port of the 966 Data-Map-Notify are set to 1.0.0.1:4342. The outer header 967 destination RLOC and port are retrieved from previously cached 968 map-cache entry in step 9 namely 2.0.0.2:20002. RTR also sets 969 the inner header destination address to site1-ETR's local 970 address namely 192.168.1.2. RTR sets the Instance ID in the 971 LISP header to 0xFFFFFF. At this point RTR marks ETR's EID 972 prefix as "Registered" status and forwards the Data-Map-Notify 973 to ETR. 975 12. The NAT device translates the destination RLOC and port of the 976 Data-Map-Notify to 192.168.1.2:4341 and forwards the packet to 977 ETR. 979 13. The Site1-ETR receives the packet with a destination port 4341, 980 and processes the packet as a control packet after observing the 981 Instance ID value 0xFFFFFF in the LISP header. At this point 982 ETR's registration to the RTR is complete. 984 Assume a requesting ITR in a second LISP (site2-ITR) site has an RLOC 985 of 74.0.0.1. The following is an example process of an EID behind 986 site2-ITR sending a data packet to an EID behind the site1-ETR: 988 1. The ITR sends a Map-Request which arrives via the LISP mapping 989 system to the ETR's Map Server. 991 2. The Map-Server sends a Map-Reply on behalf of the ETR, using the 992 RTR's RLOC (1.0.0.1) in the Map-Reply's Locator Set. 994 3. The ITR encapsulates a LISP data packet with ITR's local RLOC 995 (74.0.0.1) as the source RLOC and the RTR as the destination RLOC 996 (1.0.0.1) in the outer header. 998 4. The RTR decapsulates the packet, evaluates the inner header 999 against its map-cache and then re-encapsulates the packet. The 1000 new outer header's source RLOC is the RTR's RLOC 1.0.0.1 and the 1001 new outer header's destination RLOC is the Global NAT address 1002 2.0.0.2. The destination port of the packet is set to 20002 1003 (discovered above during the registration phase) and the source 1004 port is 4342. 1006 5. The NAT translates the LISP data packet's destination IP from to 1007 2.0.0.2 to 192.168.1.2, and translates the destination port from 1008 20002 to 4341, and forwards the LISP data packet to the ETR at 1009 192.168.1.2. 1011 6. For the reverse path the ITR uses its local map-cache entry with 1012 the RTR RLOC as the default locator and encapsulates the LISP 1013 data packets using RTR RLOC, and 4341 as destination RLOC and 1014 port. The ITR must pick a random source port to use for all 1015 outbound LISP data traffic in order to avoid creating excessive 1016 state in the NAT. 1018 6. Security Considerations 1020 By having the RTR relay the ECM-ed Map-Register message from an ETR 1021 to its Map-Server, the RTR can restrict access to the RTR services, 1022 only to those ETRs that are registered with a given Map-Server. To 1023 do so, the RTR and the Map-Server may be configured with a shared key 1024 that is used to authenticate the origin and to protect the integrity 1025 of the Map-Notify messages sent by the Map Server to the RTR. This 1026 prevents an on-path attacker from impersonating the Map-Server to the 1027 RTR, and allows the RTR to cryptographically verify that the ETR is 1028 properly registered with the Map-Server. 1030 Having the RTR re-encapsulate traffic only when the source or the 1031 destination are registered EIDs, protects against the adverse use of 1032 an RTR for EID spoofing. 1034 Upon receiving a Data-Map-Notify, an xTR can authenticate the origin 1035 of the Map-Notify message using the key that the ETR shares with the 1036 Map-Server. This enables the ETR to verify that the ECM-ed Map- 1037 Register was indeed forwarded by the RTR to the Map-Server, and was 1038 accepted by the Map-Server. 1040 6.1. Acknowledgments 1042 The authors would like to thank Noel Chiappa, Alberto Rodriguez 1043 Natal, Lorand Jakab, Albert Cabellos, Dominik Klein, Matthias 1044 Hartmann, and Michael Menth for their previous work, feedback and 1045 helpful suggestions. 1047 7. IANA Considerations 1049 This document does not request any IANA actions. 1051 8. Normative References 1053 [LCAF] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical 1054 Address Format (LCAF)", draft-ietf-lisp-lcaf-03 (work in 1055 progress), September 2013. 1057 [LISP-MS] Farinacci, D. and V. Fuller, "Locator/ID Separation 1058 Protocol (LISP) Map-Server Interface", RFC 6833, January 1059 2013. 1061 [LISP] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, 1062 "Locator/ID Separation Protocol (LISP)", RFC 6830, January 1063 2013. 1065 [NAT-MN] Klein, D., Hartmann, M., and M. Menth, "NAT traversal for 1066 LISP mobile node, In Proceedings of the Re-Architecting 1067 the Internet Workshop (ReARCH '10).", 2010. 1069 [NAT] Srisuresh, P. and M. Holdrege, "IP Network Address 1070 Translator (NAT) Terminology and Considerations", RFC 1071 2663, August 1999. 1073 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 1074 E. Lear, "Address Allocation for Private Internets", BCP 1075 5, RFC 1918, February 1996. 1077 [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing 1078 (CIDR): The Internet Address Assignment and Aggregation 1079 Plan", BCP 122, RFC 4632, August 2006. 1081 Authors' Addresses 1083 Vina Ermagan 1084 Cisco Systems, Inc. 1086 Email: vermagan@cisco.com 1087 Dino Farinacci 1088 lispers.net 1090 Email: farinacci@gmail.com 1092 Darrel Lewis 1093 Cisco Systems, Inc. 1095 Email: darlewis@cisco.com 1097 Jesper Skriver 1098 Cisco Systems, Inc. 1100 Email: jesper@cisco.com 1102 Fabio Maino 1103 Cisco Systems, Inc. 1105 Email: fmaino@cisco.com 1107 Chris White 1108 Logicalelegance, Inc. 1110 Email: chris@logicalelegance.com