idnits 2.17.1 draft-montenegro-aatn-nar-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-24) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The "Author's Address" (or "Authors' Addresses") section title is misspelled. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 1, 1998) is 9490 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '9' on line 100 == Missing Reference: 'GRE' is mentioned on line 326, but not defined == Missing Reference: 'Section 6' is mentioned on line 813, but not defined == Unused Reference: 'ISAKMP' is defined on line 858, but no explicit reference was found in the text == Unused Reference: 'Kent98c' is defined on line 876, but no explicit reference was found in the text == Unused Reference: 'MoGu97' is defined on line 887, but no explicit reference was found in the text == Unused Reference: 'NET66' is defined on line 900, but no explicit reference was found in the text -- Possible downref: Normative reference to a draft: ref. 'BYPASS' ** Downref: Normative reference to an Informational RFC: RFC 1702 (ref. 'Hanks94') == Outdated reference: A later version (-09) exists of draft-iab-nat-implications-00 ** Downref: Normative reference to an Informational draft: draft-iab-nat-implications (ref. 'IABNAT') ** Downref: Normative reference to an Historic draft: draft-ietf-ipsec-isakmp (ref. 'ISAKMP') ** Downref: Normative reference to an Historic draft: draft-ietf-ipsec-isakmp-oakley (ref. 'IKE') == Outdated reference: A later version (-05) exists of draft-ietf-ipsec-esp-v2-04 == Outdated reference: A later version (-06) exists of draft-ietf-ipsec-auth-header-05 == Outdated reference: A later version (-06) exists of draft-ietf-ipsec-arch-sec-04 ** Obsolete normative reference: RFC 2002 (ref. 'MIP') (Obsoleted by RFC 3220) ** Downref: Normative reference to an Informational draft: draft-montenegro-firewall-sup (ref. 'MoGu97') -- Possible downref: Normative reference to a draft: ref. 'NAPT' -- Possible downref: Non-RFC (?) normative reference: ref. 'NATMODEL' -- Possible downref: Normative reference to a draft: ref. 'NET66' -- Possible downref: Non-RFC (?) normative reference: ref. 'SOCKS' -- Possible downref: Normative reference to a draft: ref. 'TEP' Summary: 14 errors (**), 0 flaws (~~), 12 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force G. Montenegro 3 INTERNET DRAFT Sun Microsystems, Inc. 4 May 1, 1998 6 Negotiated Address Reuse (NAR) 7 draft-montenegro-aatn-nar-00.txt 9 Status of This Memo 11 This document is an individual submission to the Internet 12 Engineering Task Force (IETF). Comments should be submitted to the 13 author, or to the Alternative to Address Translation in Networks 14 (AATN) mailing list at aatn@alpha.zk3.dec.com. 16 Distribution of this memo is unlimited. 18 This document is an Internet-Draft. Internet-Drafts are working 19 documents of the Internet Engineering Task Force (IETF), its areas, 20 and its working groups. Note that other groups may also distribute 21 working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six 24 months and may be updated, replaced, or obsoleted by other documents 25 at any time. It is inappropriate to use Internet- Drafts as 26 reference material or to cite them other than as ``work in 27 progress.'' 29 To view the entire list of current Internet-Drafts, please check 30 the "1id-abstracts.txt" listing contained in the Internet-Drafts 31 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 32 (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au 33 (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu 34 (US West Coast). 36 Abstract 38 Network address (and port) translation is a useful technology. 39 However, several shortcomings have been identified (Mobile IP, IPSEC 40 and QOS flows). In these cases, NAT may be complemented by the use 41 of NAR (Negotiated Address Reuse). The negotiation phase in NAR is 42 based on SOCKS. 44 Table of Contents 46 1. Introduction ................................................... 3 47 1.1. Terminology ............................................... 3 48 1.2. Objectives and Assumptions ................................ 3 49 1.3. Applicability and Benefits ................................ 4 50 1.4. Assumptions ............................................... 4 51 2. Overview of the Solution ....................................... 5 52 2.1 Model ...................................................... 5 53 2.2 Negotiation ................................................ 6 54 2.3 End-to-end NAR Mappings .................................... 7 55 2.4 Translated NAR Mappings .................................... 7 56 2.5 Packet Delivery between NAR Client and Server .............. 8 57 2.6 Protocol Handling and Demultiplexing at the NAR server ..... 8 58 2.6.1 TCP, UDP and ICMP Handling and Demultiplexing ......... 9 59 2.6.2 IPSEC Handling and Demultiplexing ..................... 10 60 2.6.3 Mobile IP and TEP Handling and Demultiplexing ......... 11 61 3. SOCKS-based Negotiation ........................................ 14 62 3.1 NAR-MODE Command ........................................... 15 63 3.2 ICMP Negotiation ........................................... 16 64 3.3 IPSEC Negotiation .......................................... 17 65 3.4 Tunneling Negotiation ...................................... 18 66 4. Security Considerations ........................................ 19 67 5. Acknowledgements ............................................... 19 68 References ........................................................ 19 69 Author address .................................................... 21 70 1. Introduction 72 Network Address (and port) translation [NAPT] (henceforth called 73 "NAT" in this document) is a very useful technology. Nevertheless, 74 it is raising concerns [IABNAT] not only because of its 75 architectural impurity, but also due to its limitations. This 76 document proposes Negotiated Address Reuse (NAR) as a complement to 77 NAT. The negotiation phase is based on the SOCKS protocol [SOCKS]. 78 However, once this is over and data transfer begins NAR server and 79 client behave considerably different from a SOCKS server and 80 client. 82 The idea is to use NAT by default due to its transparency, and 83 resort to NAR when necessary (or dictated by policy). At the AATN 84 BOF held at the 41st IETF meeting (Los Angeles, 4/1/98), the 85 applications that require a NAT alternative were initially 86 identified as end-to-end: 88 - IPSEC 89 - Mobile IP 90 - QOS flows 92 This document specifies how NAR enables IPSEC and Mobile IP. QOS 93 will be addressed in a future revision. 95 1.1. Terminology 97 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 98 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 99 this document are to be interpreted as described in RFC 2119 [9]. 101 1.2. Objectives and Assumptions 103 Given that NAT does solve a large number of problems, it makes sense 104 to continue using it. Instead of replacing the NAT box, its 105 capabilities are augmented by NAR. This is, by far, the most 106 practical alternative. Nevertheless, NAR does not require NAT. 108 A primary objective of NAR is to enable SOHO (small office home 109 office) applications, in which the NAT/NAR box only has one public 110 IP address (perhaps assigned dynamically by its ISP). This single 111 public IP address hides all other systems within the private SOHO 112 net. This is perhaps the single most common application scenario 113 for NAT. 115 Finally, legacy systems outside the "local" or "private" network 116 MUST be supported. In the context of the model introduced in Section 117 2.1, this means that no changes are visible outside address space 118 A. 120 1.3. Applicability and Benefits 122 Since TCP, UDP and ICMP are satisfactorily handled by NAT, there 123 does not seem to be a compelling reason to use NAR for them. 124 Nevertheless, even in this case there still are some benefits: 126 - NAR obviates the need to explicitly handle protocols like FTP 127 or ICMP that embed address and port information in its payload 128 [NAPT]. 130 - NAR derives the benefits of using SOCKS: authenticating the 131 user before granting service, and fine-grained authorization. 133 1.4. Assumptions 135 NAR can operate under the following assumption: 137 Mutual Non-Routability Assumption: 139 Both address spaces are mutually non-routable (see section 140 2.1, "Model"), that is, the routing fabric in one address 141 space does not recognize or handle the address ranges used in 142 the other. 144 On the other hand, NAT cannot operate under this assumption. 145 Instead, it requires the: 147 Partial Routability Assumption: 149 One of the address spaces is routable within the other. In 150 the examples that use the model below (section 2.1), address 151 space B is routable within address space A, but the inverse 152 is not true. Default routing is a straightforward way to 153 guarantee this. 155 In some of the example scenarios below NAR is used to complement 156 NAT. In these cases, the latter assumption is implicitly imposed. 158 NAT works by establishing mappings between tuples in both address 159 spaces. These mappings may be established [NAPT]: 161 - statically (at startup time by virtue of manual configuration), 162 or 164 - dynamically (at protocol session initiation time). 166 Static mappings are difficult to maintain and prone to operator 167 error. Only dynamic mappings offer the transparency benefits of 168 NAT, but they require that the NAT box be able to establish the 169 mapping that applies in the reverse direction (into the NAT box), by 170 examining the packet flow in the forward direction (out of the NAT 171 box). 173 Thus, NAT only works for network protocols that satisfy the: 175 Inferrable Mapping Assumption 177 A sufficient and correct mapping for inbound traffic is 178 inferred by examining outbound traffic. 180 There are two reasons why this assumption may not apply: 182 - The protocol does not include the necessary information in 183 outgoing packets (that is, outgoing packets never initiate 184 sessions). This may be true because another protocol is used to 185 establish sessions. For example, the mapping for incoming IPSEC 186 packets (incoming SPI) is not evident from outgoing IPSEC 187 packets (outgoing SPI). This session indicator is negotiated 188 out-of-band, by using manual keying or IKE [IKE]. Hence, the 189 only mechanism guaranteed to work is to use NAR to explictly 190 establish a negotiated mapping. 192 - No outgoing traffic is guaranteed. This may happen if the 193 incoming traffic is destined for a server. Typically, this has 194 been accomodated in NAT by static configuration. NAR provides a 195 negotiated mechanism to programatically establish these 196 "server" mappings. 198 Because NAR adds negotiated mappings, it does not require the 199 Inferrable Mapping Assumption. 201 2. Overview of the Solution 203 2.1 Model 205 The model we will use is [NATMODEL]: 207 Host NAT/NAR box Host 209 Xa Na Nb Yb 210 [X]------( Addr sp. A )----[N]-----( Addr sp. B )-------[Y] 211 ( Network ) ( Network ) 213 Hosts X and Y belong to different address spaces A and B, 214 respectively, and N is a NAT/NAR box. N has two addresses: Na on 215 address space A, and Nb on address space B. In [BYPASS], the 216 assumption is that N has several addresses in address space B, 217 different from Nb, that it can dynamically assign to or lend to X. 218 These addresses are not shown above, but they can be denoted as Nb1, 219 Nb2, Nb3, and so on. NAR allows that model, but also allows X (and 220 any other hosts on address space A) to reuse Nb. 222 This is applicable to the very common SOHO scenario in which address 223 space B is the internet, address space A is a private SOHO network, 224 and N has exactly one address per address space: Na and Nb. 225 Presumably, Nb is the single address assigned to it (perhaps 226 dynamically) by the ISP through which N connects to the internet. 228 From the point of view of NAR, N is a NAR server and X is a 229 NAR client. 231 2.2 Negotiation 233 Hosts X and Y wish to exchange traffic. Furthermore, the protocol 234 they are exchanging does not satisfy the "Inferrable Mapping 235 Assumption" from section 1.4. 237 As specified in section 3 ("SOCKS-based Negotiation"), X uses a 238 derivative of the SOCKS [SOCKS] protocol with N to obtain an IP 239 address on address space B. As a result of the negotiation, N lends 240 X one of its available addresses. Frequently, this will be the same 241 address that N uses on address space B, namely, Nb. In what follows, 242 this is the case. 244 The NAR client also negotiates the values of protocol-dependent 245 fields which will enable the NAR server, N, to demultiplex the 246 incoming traffic (section 2.6). At the end of the negotiation 247 phase, N establishes a negotiated mapping so incoming replies will 248 be processed correctly. 250 Each mapping operates in either of two modes: (1) End-to-end mode 251 (the default), or (2) Translated mode. These are explained in the 252 subsequent sections. 254 2.3 End-to-end NAR Mappings 256 If we impose the "Mutual Non-Routability Assumption" from section 257 1.4, then the sequence continues as follows: 259 From that point on, X assumes address Nb as its own, and uses it 260 as the source IP address of its outgoing packets. 262 X then delivers those packets to N by using a tunneling mechanism 263 as specified in section 4 ("Delivery between NAR server and NAR 264 client"). 266 Packets flowing from Y to X MUST include the negotiated values so 267 N can demultiplex them properly, and deliver them to X. As will 268 be seen below, this does not imply any NAR support in Y. This 269 constitutes a reuse of address Nb, because in addition to N 270 itself, all its NAR clients are also using Nb as their address. 271 Nb is the source IP address of packets created by N (naturally) 272 as well as by its NAR clients (for example, X). Packets sent by Y 273 and other correspondent hosts are sent to address Nb. 275 Other than the fact that X is aware of and actively uses Nb as 276 its address when talking to Y, this is very similar to NAT 277 [NAPT]. The difference in N's role is it simply shuttles packets 278 between X and Y. Since there is no translation involved, packets 279 prepared by X arrive unmodified at Y (except for fields that 280 change during the course of normal routing operations, as 281 specified in Section 3.3.3.1.1.1 of [Kent98b]), and viceversa. 283 In this mode of operation, the NAR client in effect establishes a 284 virtual presence at the NAR server. Datagrams are exchanged between 285 the peer Y and the X's virtual presence within NAR server N. 287 The above mode of operation is "End-to-end NAR." 289 2.4 Translated NAR Mappings 291 It is also possible to mix NAR with the benefits of translation. For 292 example, if we impose the "Partial Routability Assumption" from 293 section 1.4, the sequence might proceed as follows: 295 X continues using address Xa as its own, and uses it as the 296 source IP address of its outgoing packets. 298 X then delivers those packets to the routing infrastructure in 299 address space A. Eventually, N receives the packets from X to Y, 300 and processes them according to NAT rules (this may imply new 301 extensions for NAT): by changing the source IP address of the 302 packets from Xa to Nb before injecting them out into address 303 space B on their way to Y. In Y's replies the destination IP 304 address is set to Nb. 306 In this case, NAR is only used to establish the mapping, after 307 which NAT (perhaps extended to handle the specific protocol being 308 exchanged) takes over. 310 The translation undergone by the packet is, of course, protocol 311 dependent and if defined in [NAPT], follows those directives exactly 312 (for example: UDP, TCP, ICMP, FTP, and so on). Translations for 313 other protocols like IPSEC, and tunneling are defined below. 315 The above mode of operation is "Translated NAR." 317 2.5 Packet Delivery between NAR Client and Server 319 In Translated NAR, packets between X and N flow as in the regular 320 NAT case, that is, direct delivery without recourse to tunneling 321 MUST be used. This is the default mode unless explicitly overriden 322 by End-to-end NAR during the negotiation phase. 324 When operating in the End-to-end mode, the NAR client and server 325 MUST tunnel packets to each other. If tunneling, IP in IP [IPIP] 326 MUST be used, unless GRE [GRE] is explicitly agreed upon by NAR 327 client and server during the negotiation phase. 329 2.6 Protocol Handling and Demultiplexing at the NAR server 331 Upon receiving a packet addressed to Nb, the NAR server N must 332 determine if it is destined for one of its own processes, or for a 333 process on one of its NAR clients. This determination depends on the 334 protocol, and, in general, uses a "tuple" or set of fields in the 335 packet. By establishing a mapping between a tuple and the 336 corresponding NAR client, the NAR server unequivocally identifies 337 the destination of matching packets. 339 Given that the NAR clients may reuse the NAR server's single IP 340 address on address space B, namely, Nb, this is the value that will 341 appear in the destination IP address field of incoming packets from 342 Y. This means that the destination IP address cannot be relied on 343 to identify the destination of a packet. Instead, the NAR server 344 uses a field within the IP payload for demultiplexing purposes. The 345 destination IP address is still checked to make sure that it matches 346 what was negotiated (frequently, Nb). The SOCKS-based negotiation 347 phase produces the required and unique tuples. They are mapped to 348 the client in the SOCKS-based negotiation. 350 The sections below explains processing at the NAR box for the 351 following protocols: 353 - TCP or UDP 355 - ICMP 357 - IPSEC 359 - Layer 3 tunneling (Mobile IP, TEP) 361 The explanations below assume that the NAR server N is examining a 362 packet sent by Y, destined for X. 364 2.6.1 TCP, UDP and ICMP Handling and Demultiplexing 366 TCP, UDP and ICMP demultiplexing is done based on the same tuples as 367 NAT [NAPT]. 369 When N receives a TCP packet, it demultiplexes it based on the 370 following tuple: 372 - source IP address 374 - source TCP port 376 - destination TCP port 378 - destination IP address 380 The NAR server looks for a match in its mappings table and tunnels 381 the packet to the corresponding NAR client. 383 UDP packets are demultiplexed based on this tuple: 385 - source UDP port 387 - destination UDP port 389 - destination IP address 391 The source IP address in an incoming UDP reply is ignored because in 392 a multihomed host it may not match the destination IP address of the 393 original request (RFC 1123). 395 ICMP is demultiplexed based on the following tuple: 397 - source IP address 399 - ICMP identifier 401 - destination IP address 403 If operating on an End-to-end NAR mapping, the NAR server need not 404 modify further the encapsulated IP packet within the ICMP payload as 405 required by NAT [NAPT]. 407 Even though NAR does support TCP, UDP and ICMP, it may be simpler to 408 allow NAT or Translated NAR to handle these cases. Translated NAR is 409 useful, for example, to negotiate programatically a mapping for a 410 server process. Once that is done, the actual translation (if in 411 Translated NAR mode) is exactly as specified in [NAPT]. 413 2.6.2 IPSEC Handling and Demultiplexing 415 IPSEC packets (protocols 51 and 50 for AH and ESP, respectively) 416 [Kent98a,Kent98b] from Y destined for X arrive at NAR server N. They 417 are demultiplexed based on the following tuple: 419 - protocol (50 or 51) 421 - SPI 423 - destination IP address 425 During negotiation, the NAR client X and server N arrive at an SPI 426 value to denote the incoming security association from Y to X. Once 427 N and X make sure that the SPI is unique within both of their SPI 428 spaces, X communicates its value to Y as part of the IPSEC security 429 association establishment process, namely, Quick Mode in IKE [IKE] 430 or manual assignment. 432 Given that Y sends packets to address Nb using the negotiated SPI, N 433 is able to find a matching mapping and either: 435 - tunnel the packet to X (at address Xa), or, 437 - overwrite the destination IP address on the packet with Xa 438 instead of Nb. 440 N MUST deliver packets to X by tunneling if: 442 - operating under the "Mutually Non-Routable Assumption". Not 443 doing so may prevent successful delivery of the packet within 444 address space A (perhaps because of ingress filtering within 445 the routing fabric of address space A), given that the source 446 and destination IP addresses belong to address space B (Yb and 447 Nb, respectively). 449 - the packet being forwarded includes an AH header [Kent98b] 450 (protocol 51) immediately following the IP header. Since AH 451 renders the address fields in the preceding IP header 452 immutable, NAT is out of the question, and tunneling is the 453 only alternative. 455 Given that NAR establishes the appropriate mapping with the expected 456 SPI, translation (by NAT) of the destination IP address on incoming 457 packets from Y is possible, but only if the packet includes an ESP 458 header [Kent98a] (protocol 50) immediately following the IP header. 459 In this case, traditional NAT has been said to "break" IPSEC, not 460 because the IP address fields are immutable and therefore preclude 461 NAT, but because there has been no way to establish the required 462 mapping. In other words, the ESP protocol does not satisfy the 463 "Inferrable Mapping Assumption." 465 One problem still remains: how does Y know that it is supposed to 466 send packets to X via Nb? Y is not NAR-aware, but it is definitely 467 ISAKMP-aware. Y sees ISAKMP packets coming from address Nb, 468 regardless of whether X is operating in End-to-end or Translated NAR 469 mode. To prevent Y from deriving the identity of its ISAKMP peer 470 based on the source address of the packets (Nb), X MUST exchange 471 client identifiers with Y during Quick Mode (Phase 2). ISAKMP 472 traffic is simply UDP (port 500) so it is certainly handled 473 correctly by NAT. The proper use of identifiers (IDii and IDir) 474 during Phase 1 allow the clear separation between those identities 475 and the source IP address of the packets. 477 2.6.3 Mobile IP and TEP Handling and Demultiplexing 479 Suppose NAR client X sets up a layer 3 tunnel with host Y in address 480 space B, perhaps because X and Y implement Mobile IP [MIP] or TEP 481 [TEP]. X could be a foreign agent, or a co-located mobile node, and 482 Y is the home agent. Suppose Xb is the mobile node's home address. 484 Similar to IPSEC, Mobile IP and TEP has two distinct phases: 486 - tunnel setup via a UDP-based protocol (registration protocol), 487 and 489 - data transfer via tunneled packets. 491 Let's examine first the data transfer phase. 493 Say the incoming packet looks like this: 495 INCOMING IP IN IP TUNNELED PACKET FROM Y TO N 496 +-----------------+ 497 | +-------+| 498 | Yb->Nb | CN->Xb|| 499 | +-------+| 500 +--------+--------+ 502 Here, the original packet is sent by a correspondent node at IP 503 address CN to the mobile node at address Xb. The packet was 504 intercepted by the home agent at Yb and sent towards the mobile node 505 via address Nb. 507 Once the packet reaches N (via address Nb), the NAR server must 508 identify which of its NAR clients is the ultimate destination for 509 the internal packet. In order to do so, it needs a tuple guaranteed 510 to be unique among all of its NAR clients. 512 The unique tuple sufficient for demultiplexing IP in IP packets 513 [IPIP] (protocol 4) is: 515 - destination IP address of the encapsulated (internal) header 517 This is mobile node X's home address (Xb in the above 518 example). In tunneling applications other than Mobile IP, it 519 is simply another address for X, significant within address 520 space B. At first glance, it seems like this is unique among 521 all NAR clients. However, Xb could be a private address in use 522 within address space B. Another mobile node roaming from 523 another address space, say, address space C could also be using 524 the same address. So Xb by itself is not unique, but the 525 combination with the remote tunnel endpoint is (see next 526 item). 528 - source IP address of the external header 530 This, the remote end of the tunnel, is Yb in the above 531 example. Its combination with the previous item is guaranteed 532 to be unique among all of N's NAR clients. 534 - destination IP address of the external header 535 This, the local end of the tunnel, is Nb in the above example, 536 and, given that it is frequently used by N and all of its NAR 537 client, is usually not unique. 539 Once N identifies the ultimate destination of the packet, Xa, it 540 must deliver the internal packet there. From section 2.5, there are 541 two means to do so: tunneling (if using End-to-end NAR) and direct 542 delivery as in regular NAT (if using Translated NAR). As end-to-end 543 mode adds yet another IP header, whenever possible, Translated mode 544 is preferred. In this case, the packet that arrives at Xa is: 546 DELIVERING IP IN IP PACKET FROM N TO X IN TRANSLATED MODE 547 +-----------------+ 548 | +-------+| 549 | Na->Xa | CN->Xb|| 550 | +-------+| 551 +--------+--------+ 553 If using End-to-end mode, the packet that arrives at Xa is: 555 DELIVERING IP IN IP PACKET FROM N TO X IN END-TO-END MODE 556 +---------------------------+ 557 | +-----------------+| 558 | | +-------+|| 559 | Na->Xa | Yb->Nb | CN->Xb||| 560 | | +-------+|| 561 | +--------+--------+| 562 +---------------------------+ 564 GRE packets [Hanks94] (protocol 47) without a Key field are only 565 handled if their Protocol Type field has a value of 0x800 (other 566 values are outside the scope of this document), and are 567 demultiplexed based on the same tuple as IP in IP packets. In GRE 568 terminology, the tuple is: 570 - destination IP address of the payload (internal) packet 572 - source IP address of the delivery (external) packet 574 - destination IP address of the delivery (external) packet 576 GRE packets with a Key field could be demultiplexed based on the 577 tunnel identifier [TEP], but it is simpler to just use the above 578 tuple in all GRE cases. 580 GRE packets with a Routing field are outside the scope of this 581 document. 583 Keeping in mind that Y cannot address X directly, how does the 584 latter guarantee that the former send tunneled packets to it via N? 585 It must do without requiring any new functionality at node Y (that 586 is, Y is unaware of NAR or NAT processing at N). Accordingly, this 587 tunnel must be configured using the Registration Protocol as defined 588 in [MIP]. 590 Given that Mobile IP registration protocol is UDP (port 434) 591 traffic, it, in fact, works over NAT. If mobile node X is 592 registering with home agent Y, it must use Nb as the care-of address 593 of home address Xb. This guarantees that Y sends packets to X via 594 Nb, after which the negotiated mapping takes over such that N 595 delivers packets to Xa, as outlined above. 597 It is possible to shield the mobile node X from any knowledge of NAR 598 by integrating Mobile IP into the NAR server. All the NAR server 599 needs is to be able to create the mapping between the above tuple 600 and the mobile node. This informtion is available from the 601 Registration protocol itself, so an explicit SOCKS-based negotiation 602 phase is not required. For this to work, the mobile node must learn 603 the care-of address it must use, namely, Nb from the agent 604 advertisements instead of relying on the SOCKS-based negotiation to 605 produce this value. If the mobile node has acquired a co-located 606 address, the foreign agent issuing agent advertisements (perhaps the 607 NAR server itself) must use the 'R' bit to force the mobile node's 608 Registration Request to go through it. 610 3. SOCKS-based Negotiation 612 In the negotiation phase, both NAR server and NAR client must agree 613 on values used in different protocols fields. Example values are: 615 - IPv4 addresses used as tunnel endpoints or as externally 616 visible addresses 618 - ports for TCP or UDP 620 - SPI values for IPSEC 622 The negotiation used by NAR is based on SOCKS [SOCKS] messages, and, 623 where possible, reuses the exact same formats. However, the behavior 624 of the entities involved, namely, the NAR client and NAR server, is 625 very different from that between a SOCKS client and server: instead 626 of setting up an application layer gateway, the objective is to 627 establish a mapping that (1) enables NAT (Translated NAR), or (2) 628 allows the client to acquire a virtual presence at the server 629 (End-to-end NAR). 631 The sequence of the SOCKS negotiation is altered slightly in order 632 to allow for NAR mode to be set after the authentication phase 633 (Section 3 of [SOCKS]), and before the SOCKS commands are issued 634 (Section 4 of [SOCKS]). In addition to SOCKS commands (formatted 635 according to Section 4 of [SOCKS], this document defines NAR 636 commands. However, these MUST NOT be exchanged before the 637 negotiation enters NAR mode, as specified in section 3.1, below. 639 Finally, the objective of NAR negotiations is not to establish a 640 relay for outgoing packets (as these simply rely on usual routing in 641 order to be delivered to the end system), but for incoming packets 642 from the "outside" end system to the NAR client. 644 Negotiations for UDP and TCP are defined in [SOCKS]. 646 3.1 NAR-MODE Command 648 NAR-MODE is a new SOCKS command, with an identifier of TBD, used by 649 the NAR client to advise the server that all subsequent exchanges 650 are to be interpreted as a NAR, not a SOCKS negotiation. NAR-MODE 651 is formatted according to Section 4 of [SOCKS]. Servers which do not 652 support the NAR-MODE command should respond with the "Command not 653 supported" error. 655 The client MUST set DST.PORT to a port number of 0. and DST.ADDR to 656 the address of the target address (Yb, in the examples above). 658 The NAR-MODE command implies a persistent connection, because the 659 client is requesting the server to treat all subsequent negotiations 660 as NAR, not SOCKS negotiations. Accordingly, the server MUST hold 661 the connection after the NAR-MODE command is completed to perform 662 another SOCKS5 command. Unless otherwise specified, command syntax 663 follows SOCKS. The semantics, however, are dictated by NAR. 665 The reply to the command is also formatted as a standard reply 666 [SOCKS, sec 6.]. The address returned in BND.ADDR MUST be the IPv4 667 address offered by the NAR server for reuse by the NAR client (Nb, 668 in the examples above). 670 Flag bits in the request and reply are defined as follows: 672 TUNNELED-DELIVERY X'01' 673 GRE X'02' 675 NAR mode uses the direct delivery method by default (Section 2.5). 676 If the client wishes to use the tunneled delivery method (End-to-end 677 NAR) it sets the TUNNELED-DELIVERY in the FLAG field of the 678 request. Furthermore, the client may petition the use of GRE by 679 setting that bit in the FLAG field of the request. 681 The server grants the above requests by setting the corresponding 682 bits in the FLAG field of its reply to the client. The server MAY 683 also impose any of the options above by setting the corresponding 684 bit(s) in the FLAG field of its reply, regardless of what the client 685 requested. The client MUST conform to what the server requests. The 686 server MAY ignore non-conforming clients. 688 3.2 ICMP Negotiation 690 The objective of the ICMP negotiation is to establish a mapping 691 between the ICMP tuple in section 2.6.1 and the IPv4 address of the 692 NAR client. The NAR server derives the latter from the TCP 693 connection in use for the NAR negotiation (on TCP port 1080). It 694 knows the value of the remote IP endpoint from the value of DST.ADDR 695 in the NAR-MODE command, and the value of the local IP endpoint from 696 the value of BND.ADDR in the reply to the NAR-MODE command. All 697 that is needed is a command to negotiate the value of the remaining 698 element of the tuple: ICMP identifier. 700 The ICMP-ASSOCIATE request is a new NAR command used to establish an 701 association within the NAR relay process to handle ICMP datagrams: 703 +----+-----+-------------+ 704 |VER | CMD | ICMP.ID | 705 +----+-----+-------------+ 706 | 1 | 1 | 2 | 707 +----+-----+-------------+ 709 The fields in the ICMP-ASSOCIATE packet are (with values in network 710 octet order): 712 o VER protocol version: X'01' 713 o CMD 714 o ICMP-ASSOCIATE TBD 715 o ICMP.ID Value to be used in the Identifier field of the 716 ICMP packet by the client. It MAY be set by the 717 client in the request, and MUST be confirmed or 718 overriden by the server in the reply. 720 The reply to the command is also formatted as shown above. The CMD 721 field is used as a reply field in the response, with reply values as 722 specified in [SOCKS, Section 6]. 724 3.3 IPSEC Negotiation 726 The objective of the IPSEC negotiation is to establish a mapping 727 between the tuple in section 2.6.2 and the IPv4 address of the NAR 728 client. The NAR server derives the latter from the TCP connection in 729 use for the NAR negotiation (on TCP port 1080). It knows the value 730 of the reused IP address (same value as BND.ADDR in the reply to the 731 NAR-MODE command). All that is needed is a command to negotiate the 732 remaining values of the tuple: the incoming SPI and protocol. 734 The IPSEC-ASSOCIATE request is a new NAR command used to establish 735 an association within the NAR relay process to handle IPSEC 736 datagrams: 738 +----+-----+-------------+--------+ 739 |VER | CMD | IN.PROTOCOL | IN.SPI | 740 +----+-----+-------------+--------+ 741 | 1 | 1 | 1 | 4 | 742 +----+-----+-------------+--------+ 744 The fields in the IPSEC-ASSOCIATE packet are (with values in network 745 octet order): 747 o VER protocol version: X'01' 748 o CMD 749 o IPSEC-ASSOCIATE TBD 750 o IN.PROTOCOL D'50' (X'32') for ESP, D'51' (X'33') for AH. 751 o IN.SPI SPI that the remote node uses when sending 752 datagrams to the NAR client (incoming SPI). 753 Typically not set by the client on the request, 754 but by the server on the reply. It must then be 755 communicated to the remote node via IKE or 756 manual key exchange. 758 The IN.SPI field contains the SPI for incoming IPSEC datagrams. If 759 the client is not in possesion of this information at the time of 760 the IPSEC-ASSOCIATE, the client MUST use an SPI number of all 761 zeros. 763 The reply to the command is also formatted as shown above. The CMD 764 field is used as a reply field in the response, with reply values as 765 specified in [SOCKS, Section 6]. The SPI returned is assigned by 766 the NAR server for the NAR client to use as its own and overrides 767 whatever value the client may have used in the request. 769 3.4 Tunneling Negotiation 771 The objective of the TUNNEL negotiation is to establish a mapping 772 between the tuple in section 2.6.3 and the IPv4 address of the NAR 773 client. The NAR server derives the latter from the TCP connection in 774 use for the NAR negotiation (on TCP port 1080). It knows the 775 value of the remote tunnel endpoint from the value of DST.ADDR in 776 the NAR-MODE command, and the value of the local tunnel endpoint 777 from the value of BND.ADDR in the reply to the NAR-MODE command. 778 All that is needed is a command to negotiate the value of the 779 remaining elements of the tuple: tunneling protocol, and the 780 internal tunnel address on the local side. 782 The TUNNEL-ASSOCIATE request is a new NAR command used to establish 783 an association within the NAR relay process to handle tunneled 784 datagrams: 786 +----+-----+------+-----------+-------------+ 787 |VER | CMD | ATYP | LTUN.ADDR | TUN.PROTOCOL| 788 +----+-----+------+-----------+-------------+ 789 | 1 | 1 | 1 | Variable | 1 | 790 +----+-----+------+-----------+-------------+ 792 The fields in the TUNNEL-ASSOCIATE packet are (with values in 793 network octet order): 795 o VER protocol version: X'01' 796 o CMD 797 o TUNNEL-ASSOCIATE TBD 798 o ATYP address type of following address 799 o IP V4 address: X'01' 800 o DOMAINNAME: X'03' 801 o IP V6 address: X'04' 802 o LTUN.ADDR Internal Address of the tunnel on the local 803 side. In Mobile IP, this corresponds to the 804 value of the NAR client's home address (Xb in 805 the example above). MUST be set by the client 806 on the request, confirmed by the server on the 807 reply. 808 o TUN.PROTOCOL D'4' (X'4') for IP in IP, D'47' (X'2F') for 809 GRE. 811 The reply to the command is also formatted as shown above. The CMD 812 field is used as a reply field in the response, with reply values as 813 specified in [SOCKS, Section 6]. 815 4. Security Considerations 817 This document does not add any security issues to those already 818 posed by NAT, or normal routing operations. Routing decisions are 819 based on a tuple with typically one element: destination IP 820 address. This document just adds more elements to the tuple. 821 Furthermore, by allowing an End-to-end mode of operation and by 822 introducing a negotiation phase to address reuse, the mechanisms 823 described here are more secure and less arbitrary than NAT. 825 A word of caution is in order: SPI values are meant to be random, 826 and, thus serve also as cookies to reduce off-the-path 827 denial-of-service attacks. However, NAR support for IPSEC, renders 828 the SPI a negotiated item: in addition to being a unique value at 829 the receiver X, it must also be unique at the NAR box, N. Limiting 830 the range of the SPI values available to the NAR clients reduces 831 their entropy slightly, thus (slightly) weakening their 832 effectiveness as an anti-clogging token. 834 5. Acknowledgements 836 Many thanks to Pat Calhoun, Michael Speer and Vipul Gupta for 837 helpful discussion and ideas. The latter's [NATMODEL] proved 838 invaluable in composing this document. 840 Some text in section 3 was taken (with slight modifications) from 841 [SOCKS] and draft-ietf-aft-socks-ext-00. 843 References 845 [BYPASS] G. Tsirtsis and A. O'Neill, "NAT Bypass for End 2 846 End 'sensitive' applications" -- work in progress, 847 draft-tsirtsis-nat-bypass-00.txt, January 1998. 849 [Hanks94] Hanks, S., Li, R., Farinacci, D., and P. Traina, 850 "Generic Routing Encapsulation (GRE)", RFC 1701, and 851 "Generic Routing Encapsulation over IPv4 networks", 852 RFC 1702, October 1994. 854 [IABNAT] T. Hain, "Architectural Implications of NAT" -- work 855 in progress, draft-iab-nat-implications-00.txt, 856 March 1998. 858 [ISAKMP] Maughhan, D., Schertler, M., Schneider, M., and 859 Turner, J., "Internet Security Association and Key 860 Management Protocol (ISAKMP)", 861 draft-ietf-ipsec-isakmp-09.{ps,txt}, March 1998. 863 [IKE] Harkins, D., Carrel, D., "The Internet Key Exchange 864 (IKE)", draft-ietf-ipsec-isakmp-oakley-07.txt, March 865 1998. 867 [Kent98a] S. Kent, R. Atkinson, "IP Encapsulating Payload" -- 868 work in progress, draft-ietf-ipsec-esp-v2-04.txt, 869 March 1998 (obsoletes RFC 1827, August 1995). 871 [Kent98b] S. Kent, R. Atkinson, "IP Authentication Header" -- 872 work in progress, 873 draft-ietf-ipsec-auth-header-05.txt, March 1998 874 (obsoletes RFC 1826, August 1995). 876 [Kent98c] S. Kent, R. Atkinson, "Security Architecture for the 877 Internet Protocol" -- work in progress, 878 draft-ietf-ipsec-arch-sec-04.txt, March 1998 879 (obsoletes RFC 1827, August 1995). 881 [IPIP] C. Perkins, Editor. IP Encapsulation within IP. RFC 882 2003, October 1996. 884 [MIP] C. Perkins, Editor. IP Mobility Support. RFC 885 2002, October 1996. 887 [MoGu97] G. Montenegro and V. Gupta, "Firewall Support for 888 Mobile IP" -- work in progress, 889 draft-montenegro-firewall-sup-03.txt, January 1998. 891 [NAPT] P. Srisuresh and K. Egevang, "The IP Network Address 892 Translator (NAT)" -- work in progress, 893 draft-rfced-info-srisuresh-05.txt, February 1998. 895 [NATMODEL] V. Gupta, message to the AATN mailing list, 896 Message-Id: 897 , February 898 12, 1998. 900 [NET66] R. G. Moskowitz, "Network Address Translation issues 901 with IPsec" -- work in progress, 902 draft-moskowitz-net66-vpn-00.txt, February 1998. 904 [SOCKS] M. Leech, M. Ganis, Y. Lee, R. Kuris, D. Koblas, L. 906 Jones, "SOCKS Protocol Version 5", RFC 1928, March 907 1996. 909 [TEP] P. Calhoun, G. Montenegro, C. Perkins, "Tunnel 910 Establishment Protocol" -- work in progress, 911 draft-ietf-mobileip-calhoun-tep-01.txt, March 1998. 913 Author address 915 Questions about this document may be directed at: 917 Gabriel E. Montenegro 918 Sun Microsystems, Inc. 919 901 San Antonio Road 920 Mailstop UMPK 15-214 921 Mountain View, California 94303 923 Voice: +1-415-786-6288 924 Fax: +1-415-786-6445 926 E-Mail: gabriel.montenegro@eng.sun.com