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