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