idnits 2.17.1 draft-ietf-nat-hnat-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-03-28) 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 the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == It seems as if not all pages are separated by form feeds - found 0 form feeds but 14 pages 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. ** There are 143 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** There are 21 instances of lines with control characters in the document. == There are 2 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. Miscellaneous warnings: ---------------------------------------------------------------------------- == Unrecognized Status in 'Category: Informational ', assuming Proposed Standard (Expected one of 'Standards Track', 'Full Standard', 'Draft Standard', 'Proposed Standard', 'Best Current Practice', 'Informational', 'Experimental', 'Informational', 'Historic'.) -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' Summary: 9 errors (**), 0 flaws (~~), 3 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 NAT Working Group NEC USA 2 INTERNET-DRAFT Jeffrey Lo 3 Category: Informational K.Taniguchi 4 Expire in six months November,1998 6 IP Host Network Address (and Port) Translation 7 9 Status of this Memo 11 This document is an Internet-Draft. Internet-Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its 13 areas, and its working groups. Note that other groups may also 14 distribute working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six 17 months and may be updated, replaced, or obsoleted by other 18 documents at any time. It is inappropriate to use Internet- 19 Drafts as reference material or to cite them other than as 20 "work in progress." 22 To view the entire list of current Internet-Drafts, please check 23 the "1id-abstracts.txt" listing contained in the Internet-Drafts 24 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 25 (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au 26 (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu 27 (US West Coast). 29 Abstract 31 Network Address Translation has become a popular technique that 32 allows private addresses unregistered with Internet Assigned Number 33 Authority (IANA) to be used by organizations within a private routing 34 realm. These private addresses must not be advertised in the public 35 Internet. Hence network address translator (NAT) are placed at the 36 private routing realm border to translate private addresses to globally 37 unique addresses and vice versa before packets are exchanged between 38 the disparate routing realms. These modifications of the packet header 39 by the NAT cause problems with the use of end-to-end security protocols 40 such as IPSec and DNSSEC because network address translation does 41 exactly what the security protocols are trying to prevent. 43 Host Network Address Translation (HNAT) and Host Network Address Port 44 Translation (NAPT), on the other hand, enable end hosts to carry out 45 address (and port) translations before applying security algorithms. To 46 make dynamic HNAT and HNAPT possible, three conditions are essential. 47 First, there must exist a way for end hosts to discover the IP address 48 of Host-NA(P)T-Server. Second, there must be a way for externally 49 destined packets to be routed in the private domain between the Host 50 -NA(P)T-Client and Host-NA(P)T-Server. Lastly, Host-NA(P)T-Client must 51 be able to obtain an address (and port) binding from the Host-NA(P)T 52 -Server dynamically. This draft aims to address these issues to a 53 considerable extent. Methods suggested are by no means exhaustive in 54 coverage and implementation specifics may vary from vendor to vendor. 56 1. Introduction 58 NAT itself takes several flavors, including traditional NAT (basic NAT 59 and Network Address Port Translation (NAPT)), Two-way NAT, Twin NAT, 60 Host NAT and Host NAPT [1]. Traditional NAT only allows outbound 61 session from private to public domains. While basic NAT uses one to one 62 mapping at the private domain border, NAPT allows many private addresses 63 to one global address mapping by utilizing transport level port 64 information, e.g. TCP port and UDP port [2]. In addition to outbound 65 session, two-way NAT also enables inbound session from public to private 66 network. Twin NAT are used in cases when there is an overlap of address 67 assignment between the disparate domains by changing both the source and 68 destination fields. Host NAT and NAPT allow network address (and port) 69 translation to be done by the Host-NA(P)T-Client hence eliminating the 70 traditional NAT limitation of having to do the translation at the 71 border of the private realm. 73 By using host NAT and NAPT, communicating host are able to exercise end 74 to end security by doing the address (and port) translation before 75 applying security mechanism. This solves the problem of using security 76 mechanisms such as IPSec and DNSSEC in NAT environment. Applications 77 relaying IPv4 addresses and port information in the payload of their 78 messages may find HNAT a valuable alternative to having application 79 specific application-level-gateway (ALG) on the NAT. 81 In a static HNAT and HNAPT environment, each host-NA(P)T-client needing 82 to establish end-to-end sessions with an entity outside the private 83 routing realm are statically assigned global addresses (and port). 84 After performing the necessary address (and port) translation, packets 85 are tunneled to the Host-NA(P)T-Server by encapsulating it within an 86 internally addressed header. Host-NA(P)T-Server removes the tunneling 87 header before forwarding the packet to the external realm. 89 In a dynamic environment, in addition to the requirement of routing 90 externally destined packets within the private domain which could be 91 handled by tunneling as proposed in [1], Host-NA(P)T-Client must be able 92 to discover IP addresses of Host-NA(P)T-Servers attached to the private 93 realm. This information could be manually or automatically configured. A 94 scheme has to be devised for automatic configuration to be possible. 95 Host-NA(P)T-Client must also be able to obtain an address (and port) 96 binding from the Host-NA(P)T-Server dynamically through a light weight 97 protocol that enables not only address but port negotiation. We propose 98 Dynamic Bindings Acquisition Protocol (DBAP) to serve this purpose. 100 2. Terminology 102 Address Manager 103 An entity responsible for global address and port assignment to Host- 104 NAT-Client. The address manager also maintains a private-global address 105 and port mapping of all bindings and other related parameters such as 106 maximum leased time of the binds. 108 External Entity 109 An entity physically located within a globally unique routing realm. 111 Global Address 112 A globally unique address assigned by Internet Assigned Number Authority 113 (IANA). 115 Private Address 116 Addresses used in a private routing realm which are not registered with 117 IANA. Typically but not necessarily, these addresses are within the 118 Range 10.0/8, 172.16/12 and 192.168/16 assigned by IANA. If addresses 119 Other than the range above were used, twin NAT would have to be deployed 120 at the border. 122 Host-NAT-Client 123 A host in private network that adopts an address in external realm when 124 connecting to hosts in that realm to pursue end-to-end communication 126 Host-NAPT-Client 127 A host in private network that adopts an address in the external realm 128 and port assigned by the address manager when connecting to hosts in 129 that realm to pursue end-to-end communication 131 Host-NAT-Server 132 A node that is resident on both private and external realms that can 133 facilitate routing of external realm packets within private realm. 135 Host-NAPT-Server 136 A node that is resident on both private and external realms that can 137 facilitate routing of external packets within private realm. In 138 addition, Host-NAPT-Server does one to many mapping of a global address 139 to multiple private address by manipulating transport layer port 140 information. 142 Inbound Session 143 A communication session initiated by an external entity. 145 Outbound Session 146 A communication session initiated by a Host-NAT-Client. 148 3. Overview of Dynamic HNAT 150 In a HNAT environment where global addresses are dynamically assigned, 151 host-NAT-clients obtain global address assignment from the 152 address manager when communication needs to be establish with an 153 external entity. This address manager may or may not reside on the host 154 -NAT-server. Such a mechanism for dynamically obtaining private to 155 global address binding is discussed in Section 5. After obtaining a 156 global address assignment, all communications between the two entity use 157 globally unique addresses and would requires no translation by 158 intermediary process. 160 Certain routing mechanism would be required to route the end-to-end 161 packets within private realm. Such a routing is usually facilitated by 162 the Host-NAT-Server. Two approaches are defined in [1] which are 163 repeated here. One approach would be to embed the packet within an IP 164 packet such that the outer packet is addressed between the Host-NAT 165 -Client's private address and the external peer. Hence NAT router in 166 between could provide transparent routing of the outer packet by 167 translating the outer IP header en-route. A second approach would be to 168 embed the end-to-end packet inside a tunnel while traversing in the 169 private network, such that the tunnel is addressed between Host-NAT 170 -Client's private address and a router resident on both realms. 172 A Host-NAT-Client has the following characteristics. 174 1. Aware of the realm to which its peer nodes belong. 176 2. Assumes an address from external realm when communicating with hosts 177 in that realm. Such an address may be assigned statically or in the 178 case of dynamic HNAT, obtained dynamically from the address manager. 180 3. Route packets to external hosts using an approach amenable to 181 Host-NAT-Server. In all cases, Host-NAT-Client will likely need to 182 act as a tunnel end-point, capable of encapsulating end-to-end 183 packets while forwarding and decapsulating in the return path. 185 A Host-NAT-Server has the following characteristics. 187 1. May be configured with address manager to assign address from 188 external realm to Host-NAT-Client either statically or dynamically. 190 2. Must be a router resident on both the private and external routing 191 realms. 193 3. Must be able to provide a mechanism to route external realm packets 194 within private realm. Of the two approaches described, the first 195 approach requires Host-NAT-Server to be a NAT router providing 196 transparent routing for the outer header. This approach requires the 197 external peer to be a tunnel end point. 199 With the second approach, a Host-NAT-Server could be any router that 200 can be a tunnel end-point with Host-NAT-Clients. It would detunnel 201 end-to-end packets outbound from Host-NAT-Clients and forward to 202 external hosts. On the return path, it would locate Host-NAT-Client 203 tunnel, based on the destination address of the end-to-end packet and 204 encapsulate the packet in a tunnel to forward to Host-NAT-Client. 206 4. Overview of HNAPT 208 HNAPT is similar to HNAT by allowing Host-NAPT-Client to do network and 209 port translation on behalf of Host-NAPT-Server. Many to one mapping is 210 possible by allowing multiple private addresses to share a single global 211 address, multiplexed base on transport identifiers such as TCP/UDP port 212 numbers and ICMP Query Ids. 214 Host-NAPT-Clients are identified by a tuple of both address and port 215 assignment. Methods discussed in the previous section could be used to 216 route HNAPT packets within the private routing realm. Since a 217 combination of destination address and transport identifier are used by 218 Host-NAPT-Server to identify Host-NAPT-Client, confidentiality provided 219 by security mechanisms that hide the transport identifier cannot be 220 permitted to work with HNAPT, although authentication and integrity can 221 be attained. Host-NAPT-Client would need to be able to acquire a port or 222 range of port binding from the Host-NAPT-Server. Such requirement could 223 be satisfied by DBAP discussed in section 5. 225 5. Dynamic Binding Acquisition Protocol (DBAP) 227 Dynamic Binding Acquisition Protocol (DBAP) provides a way for Host- 228 NA(P)T-Client to dynamically acquire a private address to global address 229 (and port) binding from the address manager. While Port Distribution 230 Protocol (PDP) proposed in [4] solves the issue of dynamic port 231 assignment, the scheme focuses mainly on small-scale implementation 232 of NAT where only a single global unique address is managed by the NAT 233 device. This IP address is also assumed to be static or not to change 234 frequently. Hence there is no way to resolve unique address assignment 235 using PEP, which is fundamental when more than one global address is 236 managed by the address manager. Hence DBAP is introduced as a more 237 generic protocol that enables both dynamic address and port assignment. 238 DBAP request and response could be carried as ICMP type or over TCP or 239 UDP. Six message types are defined at this moment. More message types 240 and functionality will be introduced as the scheme progresses toward a 241 more mature stage of development. 243 Extension of DBAP to Twin NAT environment will be studied and added in 244 Later version of Internet Draft. 246 The table below describes the direction of the message : 248 Message Type Direction 250 Assign Request Host-NAT-Client -> Host-NAT-Server 251 Assign Response Host-NAT-Server -> Host-NAT-Client 252 Free Request Host-NAT-Client -> Host-NAT-Server 253 Free Response Host-NAT-Server -> Host-NAT-Client 254 ERROR Response Host-NAT-Server -> Host-NAT-Client 255 End Notification Host-NAT-Server -> Host-NAT-Client 256 5.1 ASSIGN REQUEST 258 Assign Request is used by Host-NA(P)T-Client for requesting a global 259 address (and port) assignments from the Address Manager. In cases when 260 multiple global addresses are required, multiple assign request each 261 with a different BindID [5] must be sent. If an ASSIGN RESPONSE 262 corresponding to an ASSIGN REQUEST is not received from the 263 Host-NA(P)T-Server, Host-NA(P)T-Client may issue another ASSIGN REQUEST 264 with the same BindID after a default timeout, the ASSIGN-WAIT time. 265 Host-NA(P)T-Server receiving more than one successful ASSIGN REQUEST 266 with the same BINDID should discard the subsequent requests and response 267 with ASSIGN RESPONSE. Format of the message is shown below. 269 0 1 2 3 270 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 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 | Type | Code | Checksum | 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 | BindID | 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 | Num. of Ports | Lowest Port | 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 | Global IP Address Assigned | 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 | Max. Lease Time | Unused | 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 283 ASSIGN REQUEST Format 285 Type : to be defined 286 Code : 0 287 Checksum : 16-bit 1's complement of the 1's complement sum of the entire 288 request. The checksum itself is set to 0 during computation. 289 BindID : A randomly generated value in the range 0x1 to 0xFFFFFFFF by 290 Host-NA(P)T-Client during first ASSIGN REQUEST pertaining to a 291 BIND. This value should be included in every DBAP exchanged 292 pertaining to that BIND and would be maintained by the Host 293 -NAT-Server as a binding identifier. 294 Num. of Port : Number of port requested. This field is 0 when no port 295 Translation is used. 296 Lowest Port : Must be set to 0 297 Global IP Address Assigned : Must be set to 0 298 MaxLeaseTime : Maximum time interval in second that Host-NAT-Client 299 wishes the Host-NAT-Server to reserve the BIND. This 300 value should be 0 if it is not used. 301 Unused : Must be set to 0. 303 5.2 ASSIGN RESPONSE 305 ASSIGN RESPONSE is used to inform requesting Host-NA(P)T-Client of 306 the newly assigned global address, port and other parameters related to 307 the assignment. 309 0 1 2 3 310 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 311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 312 | Type | Code | Checksum | 313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 314 | BindID | 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 | Num. of Ports | Lowest Port | 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 | Global IP Address Assigned | 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 | Max. Lease Time | Unused | 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 ASSIGN RESPONSE Format 325 Type : to be defined 326 Code : 1 327 Checksum : 16-bit 1's complement of the 1's complement sum of the entire 328 request. The checksum itself is set to 0 during computation. 329 BindID : BINDID of the ASSIGN REQUEST that this response corresponds to. 330 Num. of Ports : Total number of ports allocated to the host, when no 331 port translation is used, this field must be zero. 332 Lowest Port : Lowest port number allocated in the block, when no port 333 translation is used, this field must be zero. 334 Global IP Address Assigned : This field contains the global IP address 335 assigned by the NAT device. Even if only 336 one global address is managed by the Host 337 -NA(P)T-Server, this field must be filled 338 with that address. 339 MaxLeaseTime : Maximum time interval Host-NAT-Server allocates for this 340 BIND. This value should be 0 if it is not used. 341 Unused : Must be 0 343 In case of port translation, Address manager is free to allocate a 344 number of port less than that requested by Host-NAT-Client. At the same 345 time, Host-NAT-Server is free to allocate a smaller lease time than that 346 requested. 348 5.3 FREE REQUEST 350 FREE REQUEST is used by Host-NAT-Client to free an address or port 351 assignment. If a FREE RESPONSE corresponding to a FREE REQUEST is not 352 received from the Host-NA(P)T-Server, Host-NA(P)T-Client may issue 353 another FREE REQUEST with the same BindID, address and port information 354 after a default timeout, the FREE-WAIT time. Host-NA(P)T-Server 355 receiving a valid FREE REQUEST for a bind should convert the bind to 356 FIN-WAIT state and wait for a FIN-WAIT time interval before releasing 357 the bind. Host-NA(P)T-Server receiving more than one FREE REQUEST with 358 the same BINDID, address and port information during the FIN-WAIT 359 interval should discard the subsequent requests and reply with FREE 360 RESPONSE. FIN-WAIT interval should be greater than FREE-WAIT interval. 362 Host-NAPT-Clients are able to free a subset of the port range reserved. 363 Port ranges not freed should be freed by subsequent FREE REQUEST or 364 would be deleted when Maximum Lease Time elapses. If Host-NAT-Clients 365 try to free a port range that exceeds the range of the bind, Host-NAT 366 -Server must return ERROR RESPONSE with error code Incorrect Port Range 367 and keeps the bind intact. Although BDAP does support subset port range 368 release, we do not recommend this practice since it would greatly 369 complicate Host-NAT-Server side implementations. 371 0 1 2 3 372 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 373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 374 | Type | Code | Checksum | 375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 376 | BindID | 377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 378 | Num. of Ports | Lowest Port | 379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 380 | Global IP Address Assigned | 381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 383 FREE REQUEST Format 385 Type : to be defined 386 Code : 2 387 Checksum : 16-bit 1's complement of the 1's complement sum of the entire 388 request. The checksum itself is set to 0 during computation. 389 BindID : BINDID of the ASSIGN REQUEST that this request corresponds to. 390 Num. of Ports : Total number of ports in the block to be freed, when no 391 port translation is used, this field must be zero. 392 Lowest Port : Lowest port number in the block to be freed, when no port 393 translation is used, this field must be zero. 394 Global IP Address Assigned : Global address to be freed 396 5.4 FREE RESPONSE 398 FREE RESPONSE must be sent by Host-NA(P)T-Server for every valid FREE 399 REQUEST processed. 401 0 1 2 3 402 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 403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 404 | Type | Code | Checksum | 405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 406 | BindID | 407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 408 | Num. of Ports | Lowest Port | 409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 410 | Global IP Address Assigned | 411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 413 FREE RESPONSE Format 415 Type : to be defined 416 Code : 3 417 Checksum : 16-bit 1's complement of the 1's complement sum of the entire 418 request. The checksum itself is set to 0 during computation. 419 BindID : BINDID of the ASSIGN REQUEST that this response corresponds to. 420 Num. of Ports : Total number of ports in the block freed, when no port 421 translation is used, this field must be zero. 422 Lowest Port : Lowest port number in the block freed, when no port 423 translation is used, this field must be zero. 424 Global IP Address Assigned : Global address freed by Host-NA(P)T-Server. 426 5.5 ERROR RESPONSE 428 ERROR RESPONSE are sent by Host-NA(P)T-Server to Host-NA(P)T-Client in 429 response to any error conditions that my arise. 431 0 1 2 3 432 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 433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 434 | Type | Code | Checksum | 435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 436 | BindID | 437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 438 | Error Code | Unused | 439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 441 ERROR RESPONSE Format 443 Type : to be defined 444 Code : 4 445 Checksum : 16-bit 1's complement of the 1's complement sum of the entire 446 request. The checksum itself is set to 0 during computation. 447 BindID : BINDID of the ASSIGN REQUEST that this response corresponds to. 448 Error Code : Reason for the Error. Vendor specific error codes could be 449 introduced. 451 Error Codes Error 452 0x01 Bad Request 453 0x02 BindID Not Found 454 0x03 Wrong BindID 455 0x04 Out of Port 456 0x05 Out of Address 457 0x06 Unauthorized 458 0x07 Incorrect Port Range 459 0x08 Incorrect Address 460 Unused : Must be 0. 462 Bad Request 463 Request format not understood by Host-NA(P)T-Server 465 BindID Not Found 466 BindID in the DBAP message is not found on Host-NA(P)T-Server record. 468 Wrong BindID 469 Bind record on Host-NA(P)T-Server specified by BindID on message does 470 not belong to this Host-NA(P)T-Client. 472 Out of Port 473 This error code is used in response to ASSIGN REQUEST. Host-NAPT-Server 474 is temporary out of unassigned port range 476 Out of Address 477 This error code is used in response to ASSIGN REQUEST. Host-NAT-Server 478 is temporary out of unassigned global address 480 Unauthorized 481 This error code is used in response ASSIGN REQUEST. Host-NA(P)T-Client 482 is not authorized to obtain bindings with this Host-NA(P)T-Server. This 483 error response could be return after checking with a policy module. 485 Incorrect Port Range 486 This error code is used in response to FREE REQUEST. Port range in the 487 FREE REQUEST is not correct for the bind record on Host-NAPT-server. 489 Incorrect Address 490 This error code is used in response to FREE REQUEST. Address contained 491 in the FREE REQUEST is not correct for the bind record on 492 Host-NA(P)T-server. 494 5.6 END Notification 496 END Notification is sent by Host-NA(P)T-Server for informing Host 497 -NA(P)T-Client of the expiration of a particular bind. Again, 498 Host-NA(P)T-Server must wait for FIN-WAIT interval before releasing the 499 bind. 501 0 1 2 3 502 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 503 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 504 | Type | Code | Checksum | 505 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 506 | BindID | 507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 508 | Num. of Ports | Lowest Port | 509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 510 | Global IP Address Assigned | 511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 513 END Notification Format 515 Type : to be defined 516 Code : 5 517 Checksum : 16-bit 1's complement of the 1's complement sum of the entire 518 request. The checksum itself is set to 0 during computation. 519 BindID : BINDID of the ASSIGN REQUEST that this notification corresponds 520 to. 521 Num. of Ports : Total number of ports in the block to be ended, when no 522 port translation is used, this field must be zero. 523 Lowest Port : Lowest port number in the block to be ended, when no port 524 translation is used, this field must be zero. 525 Global IP Address Assigned : Global IP address this notification refers 526 to . 528 Host-NA(P)T-Clients are not expected to acknowledge receipt of this 529 notification. After FIN-WAIT interval elapsed, data packets received 530 pertaining to this bind will be responded with an ICMP host unreachable 531 response. 533 6. Scenarios 535 The scenarios quoted are common examples of how HNAT and DBAP could be 536 exploited in real life. In scenarios pertaining to DNS lookup DNSSEC is 537 assumed to be implemented on all DNS servers. Although the mechanism 538 could be extended to all end-to-end security mechanism, IPsec is used in 539 the examples due to its popularity today. Private routing realms are 540 assumed to have global routing capabilities, that is, addresses from 541 external domains are advertised by the NAT router in the private domain 542 but not the other way round. At least one DNS server within the private 543 realm is responsible in handling queries from external entity and, for 544 simplicity, such DNS servers are assumed to be statically assigned a 545 global address each. Security Association (SA) negotiation using 546 Internet Security Association and Key Exchange Protocol (ISAKMP) in NAT 547 Environment is outside the scope of this document. This issue may be 548 addressed in the work-in-progress Internet Draft [6]. Hence for 549 simplicity, end hosts are assume to have the security association (SA) 550 negotiation completed using ISAKMP and details of ISAKMP negotiation, 551 particularly ISAKMP SA establishment and Internet Key Exchange (IKE), 552 are omitted. These scenarios illustrate address translation without 553 port translation, cases of port translation could be extended without 554 too much effort. 556 6.1 Outbound Data Session with End-to-End Security (IPSEC) 558 Here we consider the outbound data stream of a session between an 559 External entity X and an internal host A with IP security. IP tunneling 560 is used to route the packet in private realm. 562 1. First of all, host A request a global address from Host-NAT-Server 563 using DBAP. It sends a DBAP ASSIGN REQUEST with a randomly generated 564 BINDID field and "Lowest Port", "Num. of Port" and "Assigned address" 565 fields filled with 0s. It may optionally include a maximum lease time 566 value. When this DBAP request reaches the Host-NAT-Server, a global 567 address, say U, is pulled from the address pool and assigned to A. 568 The binding timer is started and Host-NAT-Server replies to host A 569 with DBAP ASSIGN RESPONSE with "Lowest Port" and "Num. of Port" 570 fields set to zero, and "Assigned Global Address" field set to U. 571 2. Host A then computes the cryptographic algorithm using address of X 572 as destination address and this assigned global address U as the 573 source address. Before sending the packet out to the private network, 574 host A encapsulates the packet with an internally addressed IP header 575 and tunnel it to the Host-NAT-Server. 576 3. When the packet reaches the Host-NAT-Server, it is decapsulated and 577 routed in the external realm to X. 579 6.2 Inbound DNS Name Lookup Query with DNSSEC 581 In this scenario, we say that an external entity X wishes to perform a 582 name lookup for an internal host A. DNSSEC is applied to all DNS 583 servers. These are the sequence of events. 585 1. Host X does a DNS query to its local DNS server 586 2. DNS of X.external.com queries the root DNS server 587 3. Root DNS server replies with a referral to DNS server of the private 588 network 589 4. DNS server of X.external.com sends a query to DNS server of private 590 network 591 5. When the query reaches DNS server of private network, it does a 592 lookup on "A.private.com" and find A's local address, say 10.0.0.1. 593 6. DNS then obtains a global address for A using DBAP. It sends a DBAP 594 ASSIGN REQUEST with "Lowest Port", "Num. of Port fields" and 595 "Assigned Global Address" fields filled with 0s and a randomly 596 generated BINDID. When this DBAP request reaches the Host-NAT-Server, 597 a global address, say U, is pulled from the address pool and assigned 598 to 10.0.0.1. The bind timer is started and Host-NAT-Server replies to 599 DNS with DBAP ASSIGN RESPONSE with "Lowest Port" and "Num. of Port" 600 fields set to zero, and "Assigned Global Address" field set to U. 601 DNS of private network then encrypt U in DNS response payload and 602 sends it back to DNS of X.external.com. The response traverse the 603 Host-NAT-Server unchanged. No DNS-ALG [3] is required at the NAT. 604 7. DNS of X.external.com replies Host X with address U assigned to Host 605 A by NAT router. 607 7. Architectural Enhancement on Host-NAT-Server and Host-NAT-Client 609 To be discussed in later drafts. 611 8. Impact on Application and Application Level Gateway 613 To be discussed in later drafts. 615 9. Security Considerations 617 To be discussed in later drafts. 619 10. Acknowledgement 621 We wish to acknowledge Dr. Takeshi Nishida for his valuable comments 622 that had been very helpful in the writing of this draft. 624 11. References 626 [1] P. Srisuresh, Matt holdrege, "NAT : Terminology and Considerations" 627 , Work-in-progress 629 [2] P.Srisuresh, K. Egevang, "Traditional IP Network Address Translator" 630 , Work-in-progress 632 [3] P.Srisuresh, G.Tsirtsis, P.Akkiraju, A. Heffernan, 633 "DNS extensions to Network Address Translators (DNS_ALG)" 634 , Work-in-progress 636 [4] M.Borella, David Grabelsky, Ikhlaq Shdhu, Brian Petry, 637 "Distributed Network Address Translation" 638 , Work-in-progress 640 [5] P.Srisuresh, "IP Network Address Translator Application Programming 641 Interface" , Work-in-progress 643 [6] P.Srisuresh "Security for IP Network Address Translator (NAT) 644 Domains" , Work-in-progress 646 12. Authors' Address 648 Jeffrey Lo 649 NEC USA, Inc. 650 110 Rio Robles 651 San Jose, California 95134 652 Voice : (408) 943 3033 653 Fax : (408) 943 3099 654 Email : jlo@ccrl.sj.nec.com 656 Kunihiro Taniguchi 657 NEC USA, Inc. 658 110 Rio Robles 659 San Jose, California 95134 660 Voice : (408) 943 3031 661 Fax : (408) 943 3099 662 Email : taniguti@ccrl.sj.nec.com