idnits 2.17.1 draft-gang-sunset4-nat64-port-allocation-00.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 15, 2015) is 3297 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 6145 (Obsoleted by RFC 7915) -- No information found for draft-ietf-v6ops-siit-dc - is the name correct? -- Obsolete informational reference (is this intentional?): RFC 1323 (Obsoleted by RFC 7323) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group G. Chen 3 Internet-Draft China Mobile 4 Intended status: Informational W. Li 5 Expires: October 17, 2015 China Telecom 6 T. Tsou 7 J. Huang 8 Huawei Technologies 9 T. Taylor 10 PT Taylor Consulting 11 April 15, 2015 13 Analysis of NAT64 Port Allocation Methods for Shared IPv4 Addresses 14 draft-gang-sunset4-nat64-port-allocation-00 16 Abstract 18 This document enumerates methods of port assignment in Carrier Grade 19 NATs (CGNs), focused particularly on NAT64 environments. A 20 theoretical framework of different NAT port allocation methods is 21 described. The memo is intended to clarify and focus the port 22 allocation discussion and propose an integrated view of the 23 considerations for selection of the port allocation mechanism in a 24 given deployment. 26 Status of this Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on October 17, 2015. 43 Copyright Notice 45 Copyright (c) 2015 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Considerations for the Choice of Port Allocation Methods . . . 3 62 2.1. Port Consumption on NAT64 . . . . . . . . . . . . . . . . 3 63 2.2. Classification of Port Allocation Models . . . . . . . . . 4 64 2.2.1. Stateful vs. Stateless . . . . . . . . . . . . . . . . 4 65 2.2.2. Dynamic vs. Static . . . . . . . . . . . . . . . . . . 5 66 2.2.3. Centralized vs. Distributed . . . . . . . . . . . . . 6 67 2.3. Port Allocation Solutions . . . . . . . . . . . . . . . . 7 68 2.3.1. Other Transition Technologies . . . . . . . . . . . . 7 69 2.3.2. Stateless Transition Technologies . . . . . . . . . . 7 70 2.3.3. Port Control Protocol (PCP) . . . . . . . . . . . . . 8 71 2.4. Specific Considerations . . . . . . . . . . . . . . . . . 8 72 2.4.1. Log Volume Optimization . . . . . . . . . . . . . . . 8 73 2.4.2. Connectivity State Optimization . . . . . . . . . . . 10 74 2.4.3. Port Randomization . . . . . . . . . . . . . . . . . . 10 75 3. Considerations for the Dynamic Assignment of Port-Ranges . . . 11 76 3.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 11 77 3.2. Implementation Issues -- Port Randomization and 78 Port-Range Deallocation . . . . . . . . . . . . . . . . . 11 79 3.3. Issues Of Traceability . . . . . . . . . . . . . . . . . . 13 80 3.4. Other Considerations . . . . . . . . . . . . . . . . . . . 14 81 4. Security Considerations . . . . . . . . . . . . . . . . . . . 14 82 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 83 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 84 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 85 7.1. Normative References . . . . . . . . . . . . . . . . . . . 16 86 7.2. Informative References . . . . . . . . . . . . . . . . . . 16 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 89 1. Introduction 91 As a result of the depletion of public IPv4 addresses, Carrier Grade 92 NAT (CGN) has been adopted by ISPs to share the available IPv4 93 resources. Overall, a CGN function maps IP addresses from one 94 address realm to another, relying upon a mechanism of multiplexing 95 multiple subscribers' connections over a number of shared IPv4 96 addresses to provide connectivity services to end hosts. A network- 97 based NAT is implied by several approaches to IPv4 service continuity 98 over an IPv6 network including DS-Lite [RFC6333], NAT64 ([RFC6145] 99 and [RFC6146]), etc. 101 Section 2) focusses on the topic of IPv6 migration. When NAPT is 102 involved, Section 2 elaborates on the considerations for address 103 sharing and particularly port assignment in the NAT64 environment. 105 Section 3 looks more closely at dynamic bulk assignment of ports to 106 individual subscriber sites, particularly as a means to reduce the 107 volume of log files. The proposals made in this section are 108 applicable to the CGN environment in general, independently of the 109 particular flavor of translation being used. 111 2. Considerations for the Choice of Port Allocation Methods 113 For port allocations on NAT64, several aspects may have to be 114 considered when selecting a suitable method. Here is a list of the 115 potential considerations, which are covered in more detail below. 117 o specific features of port usage in a NAT64 environment; 119 o classification of different port allocation methods; 121 o port allocation to improve connectivity; 123 o port allocation to optimize log volume; 125 o port allocation to enhance security. 127 Both analysis and relevant experimental results are presented in the 128 sub-sections that follow. 130 2.1. Port Consumption on NAT64 132 China Mobile did a test comparison of port consumption on NAT64 and 133 NAT44. Top100 websites (referring to Alexa statistics) were assessed 134 to evaluate status of port usage on NAT44 and NAT64 respectively. 135 China Mobile observed that the port consumption per session on NAT64 136 is roughly only half that on NAT44. 43 percent of top100 websites 137 have AAAA records, therefore the NAT64 didn't have to assign ports to 138 the traffic going to those websites. The results may be different if 139 more services (e.g. game, web-mail, etc) are considered. But it is 140 apparent that the effects of port saving on NAT64 will be amplified 141 by increasing native IPv6 support. 143 Apart from the above observation, port allocation can be tuned 144 according to the phase of IPv6 migration. As more content providers 145 and services become available over IPv6, the utilization of NAT64 146 goes down since fewer destinations require translation progressing. 147 Thus as IPv6 migration proceeds, it will be possible to relax the 148 multiplexing ratio of IPv4 address sharing (see Appendix B of 149 [RFC6269]). 151 2.2. Classification of Port Allocation Models 153 This section lists several models to allocate the port information in 154 NAT64. It also describes example cases for each allocation model. 156 2.2.1. Stateful vs. Stateless 158 o Stateful 160 The stateful NAT can be implemented either by static address 161 translation or dynamic address translation. 163 In the case of static address assignment, a one-to-one address 164 mapping for hosts between a IPv6 network address and an IPv4 165 network address is pre-configured on the NAT operation. This case 166 normally occurs when a server is deployed in an IPv6 domain. The 167 static configuration ensures stable inbound connectivity. 169 Dynamic address assignment would periodically free the binding so 170 that the global address could be recycled for later use. This 171 increases the efficiency of usage of IPv4 resources. 173 o Stateless 175 Stateless NAT is performed in compliance with [RFC6145]. The 176 public IPv4 address is required to be embedded in the IPv6 177 address. Thus the NAT64 can directly extract the address and has 178 no need to record mapping states. 180 A promising usage of stateless NAT may appear in the data centre 181 environment where IPv6 server pools receive inbound connections from 182 IPv4 users externally [I-D.ietf-v6ops-siit-dc]. NAT usage in other 183 cases may be controversial. First off, the static one-to-one mapping 184 does not address the issue of IPv4 depletion. Secondly, it 185 introduces a dependency between IPv4 and IPv6 addressing. That 186 creates other limitations since a change of IPv4 address will cause 187 renumbering of IPv6 addresses. 189 2.2.2. Dynamic vs. Static 191 Port assignments can be dynamic (ports allocated on demand) or static 192 (ports allocated as part of the configuration process). 194 o Dynamic assignment 196 NAT64 uses dynamic assignment, since this achieves higher port 197 utilization. Port allocations can be made with per-session or 198 per-customer granularity. Per-session assignment is configured on 199 the NAT64 by default since it maximizes port utilization. 200 However, if only individual port numbers are assigned, this can 201 result in a heavy log volume that may have to be recorded for 202 legal data retention systems. To mitigate that concern, the NAT64 203 may dynamically allocate a port range for each connected 204 subscriber or upon receipt of a first outgoing packet from an IPv6 205 host. This will significantly reduce log volume. 207 A proper port-range configuration may have to take into account 208 two considerations: 210 A. The number of session initiations for each subscriber. A 211 subscriber normally uses multiple applications simultaneously, 212 e.g. maps applications, online video or game. The number of 213 concurrent sessions is essential to determine the number of 214 ports the subscriber needs. The China Mobile study mentioned 215 earlier observed that the average number of sessions consumed 216 by one user's device was around 200 to 300 ports. Several 217 devices may appear behind a CPE. Based on this observation, 218 1000 ports per subscriber household will provide enough room 219 for multiple active users. Administrators should monitor 220 usage to adjust this number if users are being limited by this 221 number, or if usage is so low that fewer ports would be 222 sufficient. 224 B. Impacts on NAT64 capacity. Preassigned port ranges occupy 225 memory even when there are unused ports. Therefore, the 226 operator should be cautious about the impact of port-range 227 reservation on the capacity for attempted concurrent sessions, 228 especially in the case of a centralized NAT64 serving numerous 229 subscribers. 231 o Static assignment 233 Static assignment makes port reservations in bulk for each 234 internal address before subscriber connection. The assigned ports 235 can be in either a contiguous port range or a non-contiguous port 236 range for the sake of defense against port-guessing attacks (see 237 Section 3.2). Log recording for each port assignment may not be 238 necessary due to the stable mapping relations. Considerations of 239 the interaction between port-range allocation and capacity impact 240 are also applicable in the case of static assignment. [RFC7422] 241 describes a deterministic algorithm to assign a port range for an 242 internal IP address pool in a sequence. 244 2.2.3. Centralized vs. Distributed 246 There is an increasing need to connect NAT64 with downstream NAT46- 247 capable devices to support IPv4 users/applications on an IPv6-only 248 path. Several solutions have been proposed in this area, e.g., 249 464xlat [RFC6877], MAP-T [I-D.ietf-softwire-map-t] and 4rd 250 [I-D.ietf-softwire-4rd]. Port allocation can be categorized as a 251 centralized assignment on NAT64 or as a port delegation distributed 252 to downstream devices (e.g, Customer Edge connected with NAT64). 254 o Centralized Assignment 256 A centralized method makes port assignments once IP flows come to 257 the NAT64. The allocation policy is enforced on a centralized 258 point. Either a dynamic or static port assignment is made for 259 received sessions. 261 o Distributed Assignment 263 NAT64 can also delegate the pre-allocated port range to customer 264 edge devices. That can be achieved through additional out-of-band 265 provisioning signals (e.g., [I-D.ietf-pcp-port-set], 266 [I-D.ietf-softwire-map-dhcp]). The distributed model normally is 267 performed A+P style [RFC6346] for static port assignment. The 268 NAT64 should also hold the corresponding mapping in order to 269 validate port usage in the outgoing direction and route inbound 270 packets. Delegated port ranges shift NAT64 port computations/ 271 states into downstream devices. The detailed benefits of this 272 approach are documented in 273 [I-D.ietf-softwire-stateless-4v6-motivation]. 275 2.3. Port Allocation Solutions 277 2.3.1. Other Transition Technologies 279 [RFC6146] describes a process where the dynamic binding is created by 280 an outgoing packet, but it may also be created by other means such as 281 a Port Control Protocol request (see Section 2.3.3). Lookin beyond 282 NAT64 for the moment, DS-Lite [RFC6333] refers to the cautions in 283 [RFC6269] but does not specify any port allocation method. Both 284 techniques DS-Lite and NAT64 assume a centralized model. 286 The specifications for both transition methods thus allow 287 implementations to use the proposals made in Section 3 (and 288 [RFC7422]). 290 2.3.2. Stateless Transition Technologies 292 The port allocation solutions that are being specified at the time of 293 writing of this document are all variations on the static distributed 294 model, to minimize the amount of state that has to be held in the 295 network. The proposals made in Section 3 do not apply to the current 296 work in progress because that work has gone in another direction. 297 That work includes: 299 o Light-weight 4over6 (LW4o6 [I_D.ietf-softwire-lw4over6]), which 300 requires the CPE to be configured explicitly with the shared IPv4 301 address and port set it will use on the WAN side of its NAT44 302 function. The border router is configured with the same 303 information, reducing the state it must hold from per-session to 304 per-subscriber amounts. 306 o Mapping of Address and Port with Encapsulation (MAP-E 307 [I-D.ietf-softwire-map]) and the experimental specifications 308 Mapping of Address and Port with Translation (MAP-T 309 [I-D.ietf-softwire-map-t]) and 4rd [I-D.ietf-softwire-4rd], 310 already mentioned. These rely on an algorithmic embedding of WAN- 311 side IPv4 address and assigned port set within the IPv6 prefix 312 assigned to each CPE. Both the CPE and the border router must be 313 configured with this information. However, the algorithm is 314 designed to aggregate routing information such that the amount of 315 state carried by the border router is of a lower order of 316 magnitude than even the per-subscriber level. 318 All A+P variants support a 1-1 mapping mode, where the IPv4 and IPv6 319 addresses assigned to a CPE are independent. This can be helpful in 320 transition, but, as with LW4o6, raises the amount of state in the 321 network back to the per-subscriber level. 323 For a packet destined to a host outside the MAP domain from which the 324 packet originated: MAP-E and 4rd treat the packet as an IPv4 over 325 IPv6 tunnel via the border router. 327 MAP-T uses stateless mapping in the sense of Section 2.2.1 by 328 embedding the destination IPv4 address within the IPv6 address of the 329 packet sent to the border router. 331 2.3.3. Port Control Protocol (PCP) 333 The Port Control Protocol (PCP, [RFC6887]) can be used to reserve a 334 single port or a port set [I-D.ietf-pcp-port-set] for applications. 335 It requires that the NAT be controlled by a PCP server function. PCP 336 provides an out-of-band signalling mechanism for coordinating dynamic 337 allocation of ports between hosts and the border router, removes the 338 need for ALGs, allows for successful incoming connections, etc. 340 2.4. Specific Considerations 342 2.4.1. Log Volume Optimization 344 [RFC6269] provides a thoughtful analysis on the issues of IP address 345 sharing. It points out that IP address sharing may impact law 346 enforcement since source address information will be lost during the 347 translation. Network administrators have to log the mapping status 348 for each connection in order to identify a specific user associated 349 with an IP address in a particular time slot. The storage of log 350 information may pose a challenge to operators, since it requires 351 additional resources and data inspection processes to identify users. 352 For concrete details of what should be logged, see Section 3.1 of 353 [I-D.ietf-behave-syslog-nat-logging]. The actual logging may use 354 either IPFIX [RFC7011] or Syslog [RFC5424] depending on the 355 operator's requirements. 357 It is desirable to reduce the volume of the logged information. 358 Referring to the classification of port allocation methods given 359 above, dynamic assignments can be managed on either a per-session or 360 per-customer granularity. The coarser granularity will lead to lower 361 log volume storage. A test was made by recording the log information 362 from 200,000 subscribers in the Chinese network for 60 days. The 363 volume of recorded information reached up to 42.5 terabytes with per- 364 session logging in the raw format. The volume could be reduced to 365 10.6 terabytes with gzip format. Compared with that, it only 366 occupied 40.6 gigabytes, three orders of magnitude smaller volume, 367 with per-customer logging in the raw format. With static allocation, 368 of course, no logs for port assignment are required, but a record of 369 the configuration change is still required. 371 On the other hand, the lower logging volumes are associated with 372 lower efficiency of port utilization. A port allocation based on 373 per-customer granularity has to retain vacant ports in order to avoid 374 traffic overflow. The efficiency can be evaluated by port 375 utilization rate, and will be even lower if the static port 376 allocation method is used. Inactive users may also impact the 377 efficiency. 379 Table 1 summarizes the test results using Syslog. The ports were 380 pre-allocated to customers regardless of online or offline status. 382 +--------------------+--------------+----------------+--------------+ 383 | Port Allocation | Log | Estimated Log | Port | 384 | Method | Granularity | Volume | Utilization | 385 +--------------------+--------------+----------------+--------------+ 386 | Dynamic NAPT | Per-session | 42.5 terabytes | 100% | 387 | Dynamic port-range | Per-customer | 40.6 Gigabytes | 75% | 388 | Deterministic NAT, | None | None | (60% * 75%) | 389 | MAP-T, 4rd | | | = 45% | 390 +--------------------+--------------+----------------+--------------+ 392 Table 1: Estimated Log Volumes For 200,000 Users Over 60 Days 394 Note: 75% is the estimated port utilization ratio per active 395 subscriber. 60% is the estimated ratio of active subscribers to the 396 total number of subscribers. 398 The data shown in Table 1 roughly demonstrates the tradeoff between 399 port utilization and log volume reduction. Administrators may 400 consider the following factors to make their design choice that would 401 meet their deployment requirements: 403 o average connectivity per customer per day; 405 o peak connectivity per day; 407 o the number of public IPv4 addresses available to the NAT64; 409 o application demands for specific ports; 411 o processing capabilities of the NAT64; 413 o tolerable log volume. 415 2.4.2. Connectivity State Optimization 417 It has been observed that port consumption is significantly increased 418 once subscribers land on a web page for video on demand, an online 419 game, or map services. In those cases, multiple TCP connections may 420 be initiated to optimize the performance of data transmissions for 421 video download and message exchange. Given the video traffic growth 422 trend, this likely presents a challenge for network operators who 423 need to optimize connectivity states and avoid port depletion. Those 424 optimizations may even affect the method of port-range allocation, 425 because a subscriber is only allowed to use a pre-configured port 426 resource. 428 Two optimizations may be considered: 430 o Reducing the TIME-WAIT state. The user's behavior normally 431 correlates with system performance. It is rather common that 432 users change video channels often. Investigations have shown that 433 60% of videos are watched for less than 20% of their duration. 434 The user's access patterns may leave a number of the TIME-WAIT 435 states. Therefore, acceleration of TIME-WAIT state transitions 436 could increase the efficiency of port utilization. [RFC6191] 437 defines a mechanism for reducing TIME-WAIT state by proposing TCP 438 timestamps and sequence numbers. 440 [I-D.penno-behave-rfc4787-5382-5508-bis] recommended applying 441 [RFC6191] and PAWS (Protect Against Wrapped Sequence numbers, 442 described in [RFC1323]) to NAT. This may also be a way to improve 443 port utilization. 445 o Another possibility is to use Address-Dependent Mapping or Address 446 and Port-Dependent Mapping [RFC4787] to increase port utilization. 447 This feature has already been implemented on a vendor-specific 448 basis. However, it should be noted that REQ-7 and REQ-12 in 449 [RFC6888] may reduce the incentive to use anything but the 450 Address-Independent Mapping behaviour recommended by [RFC4787]. 452 2.4.3. Port Randomization 454 Port randomization is a feature to enhance the defense against 455 hijacking of flows. [RFC6056] specifies that: 457 "A NAPT that does not implement port preservation ([RFC4787], 458 [RFC5382]) should obfuscate selection of the ephemeral port of a 459 packet when it is changed during translation of that packet." 461 A NAPT based on per-session allocation normally follows this 462 recommendation. 464 See Section 4 for a fuller discussion of port randomization. 466 3. Considerations for the Dynamic Assignment of Port-Ranges 468 3.1. Motivation 470 During the IPv6 transition period, large-scale NAT devices may be 471 introduced, e.g. DS-Lite AFTR, NAT64. When a NAT device needs to 472 set up a new connection for a given internal address behind the NAT, 473 it needs to create a new mapping entry for the new connection, which 474 will contain source IP address, source port or ICMP identifier, 475 converted source IP address, converted source port, protocol (TCP/ 476 UDP), etc. 478 For various reasons it is necessary to log these mappings. Some high 479 performance NAT devices may need to create a large amount of new 480 sessions per second. As discussed in Section 2.4.1, if the logs are 481 generated for each mapping entry, the log traffic could reach tens of 482 megabytes per second or more, which would be a problem for log 483 generation, transmission and storage. (The per-session volumes in 484 Table 1 amount to 42 bytes per served subscriber per second. The 485 volumes reported in the introduction to [RFC7422] for U.S. users are 486 even higher, around 58 bytes per second per subscriber served.) 488 [RFC6888], REQ-13, REQ-14, and REQ-15 deal explicitly with port 489 allocation schemes and logging. However, it is recognized that these 490 are conflicting requirements, requiring a tradeoff between the 491 efficiency with which ports are used and the rate of generation of 492 log records. 494 Allocating a range of N ports at once reduces the log volume by a 495 factor of N, while also reducing port utilization by a factor which 496 varies with the address sharing ratio and other configuration 497 parameters. This provides a clear motivation to use dynamic 498 allocation of port-ranges rather than individual ports when it is 499 possible to do so while maintaining a satisfactory level of port 500 utilization (and by implication, shared global IPv4 address 501 utilization). 503 Dynamic allocation of port ranges may be used either as the sole 504 strategy for port allocation on the NAPT, or as a supplement to an 505 initial static allocation. 507 3.2. Implementation Issues -- Port Randomization and Port-Range 508 Deallocation 510 When the user sends out the first packet, a port resource pool is 511 allocated for the user, e.g., assigning ports 2001~2300 of a public 512 IP address to the user's resource pool. Only one log should be 513 generated for this port block. When the NAT needs to set up a new 514 mapping entry for the user, it can use a port in the user's resource 515 pool and the corresponding public IP address. If the user needs more 516 port resources, the NAT can allocate another port block, e.g., ports 517 3501~3800, to the user's resource pool. Again, just one log needs to 518 be generated for this port block. 520 Cryptographically random port assignment is discussed in Section 2.2 521 of [RFC6431]. Indeed, [RFC6431] takes this idea further by 522 allocating non-contiguous sets of ports using a pseudorandom 523 function. Scattering the allocated ports in this way provides a 524 modest barrier to port guessing attacks. The use of randomization is 525 discussed further in Section 4. 527 Suppose now that a given internal address has been assigned more than 528 one block of ports. The individual sessions using ports within a 529 port block will start and end at different times. If no ports in 530 some port block are used for some configurable time, the NAT can 531 remove the port block from the resource pool allocated to a given 532 internal address, and make it available for other users. In theory, 533 it is unnecessary to log deallocations of blocks of ports, because 534 the ports in deallocated blocks will not be used again until the 535 blocks are reallocated. However, the deallocation may be logged when 536 it occurs to add robustness to troubleshooting or other procedures. 538 The deallocation procedure presents a number of difficulties in 539 practice. The first problem is the choice of timeout value for the 540 block. If idle timers are applied for the individual mappings 541 (sessions) within the block, and these conform to the recommendations 542 for NAT behaviour for the protocol concerned, then the additional 543 time that might be configured as a guard for the block as a whole 544 need not be more than a few minutes. The block timer in this case 545 serves only as a slightly more conservative extension of the 546 individual session idle timers. If, instead, a single idle timer is 547 used for the whole block, it must itself conform to the 548 recommendations for the protocol with which that block of ports is 549 associated. For example, REQ-5 of [RFC5382] requires an idle timer 550 expiry duration of at least 2 hours and 4 minutes for TCP. The 551 suggestions made in Section 2.4.2 may be considered for reducing this 552 time. 554 The next issue with port block deallocation is the conflict between 555 the desire to randomize port allocation and the desire to make unused 556 resources available to other internal addresses. As mentioned above, 557 ideally port selection will take place over the entire set of blocks 558 allocated to the internal address. However, taken to its fullest 559 extent, such a policy will minimize the probability that all ports in 560 any given block are idle long enough for it to be released. 562 As an alternative, it is suggested that when choosing which block to 563 select a port from, the NAT should omit from its range of choice the 564 block that has been idle the longest, unless no ports are available 565 in any of the other blocks. The expression "block that has been idle 566 the longest" designates the block in which the time since the last 567 packet was observed in any of its sessions, in either direction, is 568 earlier than the corresponding time in any of the other blocks 569 assigned to that internal address. As [RFC6269] points out, port 570 randomization is just one security measure of several, and the loss 571 of randomness incurred by the suggested procedure is justified by the 572 increased utilization of port resources it allows. 574 3.3. Issues Of Traceability 576 Section 12 of [RFC6269] provides a good discussion of the 577 traceability issue. Complete traceability given the NAT logging 578 practices proposed in this draft requires that the remote destination 579 record the source port of a request along with the source address 580 (and presumably protocol, if not implicit) [RFC6302]. In addition, 581 the logs at each end must be timestamped, and the clocks must be 582 synchronized within a certain degree of accuracy. Here is one reason 583 for the guard timing on block release, to increase the tolerable 584 level of clock skew between the two ends. 586 Where source port logging can be enabled, this memo strongly urges 587 the operators to do so. Similarly, intrusion detection systems 588 should capture source port as well as source address of suspect 589 packets. 591 In some cases [RFC6269], a server may not record the source port of a 592 connection. To allow traceability, the NAT device needs to record 593 the destination IP address of a connection. As [RFC6269] points out, 594 this will provide an incomplete solution to the issue of traceability 595 because multiple users of the same shared public IP address may 596 access the service at the same time. From the point of view of this 597 draft, in such situations the game is lost, so to speak, and port 598 allocation at the NAT might as well be completely dynamic. 600 The final possibility to consider is where the NAT does not do per- 601 session logging even given the possibility that the remote end is 602 failing to capture source ports. In that case, the port allocation 603 strategy proposed in this section can be used. The impact on 604 traceability is that analysis of the logs would yield only the list 605 of all internal addresses mapped to a given public address during the 606 period of time concerned. This has an impact on privacy as well as 607 traceability, depending on the follow-up actions taken. 609 3.4. Other Considerations 611 [RFC6269] notes several issues introduced by the use of dynamic as 612 opposed to static port assignment. For example, Section 12.2 of that 613 document notes the effect on authentication procedures. These issues 614 must be resolved, but are not specific to the dynamic port-range 615 allocation strategy. 617 4. Security Considerations 619 The discussion which follows addresses an issue that is particularly 620 relevant to the strategies described in Section 3 of this document. 621 The security considerations applicable to NAT operation for various 622 protocols as documented in, for example, [RFC4787] and [RFC5382] also 623 apply to this proposal. 625 [RFC6056] summarizes the TCP port-guessing attack, by means of which 626 an attacker can hijack one end of a TCP connection. One mitigating 627 measure is to make the source port number used for a TCP connection 628 less predictable. [RFC6056] provides various algorithms for this 629 purpose. 631 As Section 3.1 of that RFC notes: "...provided adequate algorithms 632 are in use, the larger the range from which ephemeral ports are 633 selected, the smaller the chances of an attacker are to guess the 634 selected port number." Conversely, the reduced range sizes proposed 635 by the present document increase the attacker's chances of guessing 636 correctly. This result cannot be totally avoided. However, 637 mitigating measures to improve this situation can be taken both at 638 port block assignment time and when selecting individual ports from 639 the blocks that have been allocated to a given user. 641 At assignment time, one possibility is to assign ports as non- 642 contiguous sets of values as proposed in [RFC6431]. However, this 643 approach creates a lot of complexity for operations, and the pseudo 644 randomization can create uncertainty when the accuracy of logs is 645 important to protect someone's life or liberty. 647 Alternatively, the NAT can assign blocks of contiguous ports. 648 However, at assignment time the NAT could attempt to randomize its 649 choice of which of the available idle blocks it would assign to a 650 given user. This strategy has to be traded off against the 651 desirability of minimizing the chance of conflict between what 652 [RFC6056] calls "transport protocol instances" by assigning the most- 653 idle block, as suggested in Section 3. A compromise policy might be 654 to assign blocks only if they have been idle for a certain amount of 655 time whenever possible, and select pseudorandomly between the blocks 656 available according to this criterion. In this case it is suggested 657 that the time value used be greater than the guard timing mentioned 658 in Section 3, and that no block should ever be reassigned until it 659 has been idle at least for the duration given by the guard timer. 661 Note that with the possible exception of cryptographically-based port 662 allocations, attackers could reverse-engineer algorithmically-derived 663 port allocations to either target a specific subscriber or to spoof 664 traffic to make it appear to have been generated by a specific 665 subscriber. However, this is exactly the same level of security that 666 the subscriber would experience in the absence of CGN. CGN is not 667 intended to provide additional security by obscurity. 669 While the block assignment strategy can provide some mitigation of 670 the port guessing attack, the largest contribution will come from 671 pseudo-randomization at port selection time. [RFC6056] provides a 672 number of algoriths for achieving this pseudo-randomization. When 673 the available ports are contained in blocks which are not in general 674 consecutive, the algorithms clearly need some adaptation. The task 675 is complicated by the fact that the number of blocks allocated to the 676 user may vary over time. Adaptation is left as an exercise for the 677 implementor. 679 5. IANA Considerations 681 This document makes no request of IANA. 683 6. Acknowledgements 685 This document is the result of a merger of the original 686 draft-chen-sunset4-cgn-port-allocation and 687 draft-tsou-behave-natx4-log-reduction. Version -02 of draft-chen 688 contains the following acknowledgements: 690 The author would like to thank Lee Howard and Simon Perreault for 691 their helpful comments. 693 Many thanks to Wesley George and Marc Blanchet encourage the 694 author to continue this work. 696 The authors of draft-tsou-behave-natx4-log-reduction have their own 697 thanks to give. Mohamed Boucadair reviewed the initial document and 698 provided useful comments to improve it. Reinaldo Penno, Joel 699 Jaeggli, and Dan Wing provided comments on the subsequent version 700 that resulted in major revisions. Serafim Petsis provided 701 encouragement to publication after a hiatus of two years. 703 The present version of the document benefited from further comments 704 by Lee Howard and Mohamed Boucadair. 706 7. References 708 7.1. Normative References 710 [RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport- 711 Protocol Port Randomization", BCP 156, RFC 6056, 712 January 2011. 714 [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation 715 Algorithm", RFC 6145, April 2011. 717 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 718 NAT64: Network Address and Protocol Translation from IPv6 719 Clients to IPv4 Servers", RFC 6146, April 2011. 721 [RFC6269] Ford, M., Boucadair, M., Durand, A., Levis, P., and P. 722 Roberts, "Issues with IP Address Sharing", RFC 6269, 723 June 2011. 725 7.2. Informative References 727 [I-D.ietf-behave-syslog-nat-logging] 728 Chen, Z., Zhou, C., Tsou, T., and T. Taylor, "Syslog 729 Format for NAT Logging (Work in Progress)", January 2014. 731 [I-D.ietf-pcp-port-set] 732 Sun, Q., Boucadair, M., Sivakumar, S., Zhou, C., Tsou, T., 733 and S. Perrault, "Port Control Protocol (PCP) Extension 734 for Port Set Allocation (Work in Progress)", 735 November 2014. 737 [I-D.ietf-softwire-4rd] 738 Despres, R., Jiang, S., Penno, R., Lee, Y., Chen, G., and 739 M. Chen, "IPv4 Residual Deployment via IPv6 - a Stateless 740 Solution (4rd) (Work in Progress)", December 2014. 742 [I-D.ietf-softwire-map] 743 Troan, O., Dec, W., Li, X., Bao, C., Matsushima, S., 744 Murakami, T., and T. Taylor, "Mapping of Address and Port 745 with Encapsulation (MAP) (Work in Progress)", March 2015. 747 [I-D.ietf-softwire-map-dhcp] 748 Mrugalski, T., Troan, O., Dec, W., Farrer, I., Perrault, 749 S., Bao, C., Yeh, L., and X. Deng, "DHCPv6 Options for 750 configuration of Softwire Address and Port Mapped Clients 751 (Work in Progress)", March 2015. 753 [I-D.ietf-softwire-map-t] 754 Li, X., Bao, C., Dec, W., Troan, O., Matsushima, S., and 755 T. Murakami, "Mapping of Address and Port using 756 Translation (MAP-T) (Work in progress)", December 2014. 758 [I-D.ietf-softwire-stateless-4v6-motivation] 759 Boucadair, M., Matsushima, S., Lee, Y., Bonness, O., 760 Borges, I., and G. Chen, "Motivations for Carrier-side 761 Stateless IPv4 over IPv6 Migration Solutions (Expired work 762 in Progress)", November 2012. 764 [I-D.ietf-v6ops-siit-dc] 765 Anderson, T., "SIIT-DC: Stateless IP/ICMP Translation for 766 IPv6 Data Centre Environments (Work in progress)", 767 December 2014. 769 [I-D.penno-behave-rfc4787-5382-5508-bis] 770 Penno, R., Perrault, S., Kamiset, S., Boucadair, M., and 771 K. Naito, "Network Address Translation (NAT) Behavioral 772 Requirements Updates (expired Work in Progress)", 773 January 2013. 775 [I_D.ietf-softwire-lw4over6] 776 Cui, Y., Sun, Q., Boucadair, M., Tsou, T., Lee, Y., and I. 777 Farrer, "Lightweight 4over6: An Extension to the DS-Lite 778 Architecture (Work in Progress)", November 2014. 780 [RFC1323] Jacobson, V., Braden, B., and D. Borman, "TCP Extensions 781 for High Performance", RFC 1323, May 1992. 783 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 784 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 785 RFC 4787, January 2007. 787 [RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. 788 Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, 789 RFC 5382, October 2008. 791 [RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, March 2009. 793 [RFC6191] Gont, F., "Reducing the TIME-WAIT State Using TCP 794 Timestamps", BCP 159, RFC 6191, April 2011. 796 [RFC6302] Durand, A., Gashinsky, I., Lee, D., and S. Sheppard, 797 "Logging Recommendations for Internet-Facing Servers", 798 BCP 162, RFC 6302, June 2011. 800 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 801 Stack Lite Broadband Deployments Following IPv4 802 Exhaustion", RFC 6333, August 2011. 804 [RFC6346] Bush, R., "The Address plus Port (A+P) Approach to the 805 IPv4 Address Shortage", RFC 6346, August 2011. 807 [RFC6431] Boucadair, M., Levis, P., Bajko, G., Savolainen, T., and 808 T. Tsou, "Huawei Port Range Configuration Options for PPP 809 IP Control Protocol (IPCP)", RFC 6431, November 2011. 811 [RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: 812 Combination of Stateful and Stateless Translation", 813 RFC 6877, April 2013. 815 [RFC6887] Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. 816 Selkirk, "Port Control Protocol (PCP)", RFC 6887, 817 April 2013. 819 [RFC6888] Perreault, S., Yamagata, I., Miyakawa, S., Nakagawa, A., 820 and H. Ashida, "Common Requirements for Carrier-Grade NATs 821 (CGNs)", BCP 127, RFC 6888, April 2013. 823 [RFC7011] Claise, B., Trammell, B., and P. Aitken, "Specification of 824 the IP Flow Information Export (IPFIX) Protocol for the 825 Exchange of Flow Information", STD 77, RFC 7011, 826 September 2013. 828 [RFC7422] Donley, C., Grundemann, C., Sarawat, V., Sundaresan, K., 829 and O. Vautrin, "Deterministic Address Mapping to Reduce 830 Logging in Carrier-Grade NAT Deployments", RFC 7422, 831 December 2014. 833 Authors' Addresses 835 Gang Chen 836 China Mobile 837 53A,Xibianmennei Ave., 838 Xuanwu District, 839 Beijing 100053 840 P.R. China 842 Email: phdgang@gmail.com 844 Weibo Li 845 China Telecom 846 109, Zhongshan Ave. West, Tianhe District 847 Guangzhou, 510630 848 P.R. China 850 Phone: 851 Email: mweiboli@gmail.com 853 Tina Tsou 854 Huawei Technologies 855 Bantian, Longgang District 856 Shenzhen 518129 857 P.R. China 859 Phone: 860 Email: tina.tsou.zouting@huawei.com 862 James Huang 863 Huawei Technologies 864 Bantian, Longgang District 865 Shenzhen 518129 866 P.R. China 868 Phone: 869 Email: James.huang@huawei.com 870 Tom Taylor 871 PT Taylor Consulting 872 Ottawa, Ontario 873 Canada 875 Phone: 876 Email: tom.taylor.stds@gmail.com