idnits 2.17.1 draft-ietf-sunset4-nat64-port-allocation-01.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 (July 22, 2015) is 3201 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 6145 (Obsoleted by RFC 7915) -- Obsolete informational reference (is this intentional?): RFC 1323 (Obsoleted by RFC 7323) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 2 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: January 23, 2016 China Telecom 6 T. Tsou 7 J. Huang 8 Huawei Technologies 9 T. Taylor 10 PT Taylor Consulting 11 JF. Tremblay 12 Viagenie 13 July 22, 2015 15 Analysis of NAT64 Port Allocation Methods for Shared IPv4 Addresses 16 draft-ietf-sunset4-nat64-port-allocation-01 18 Abstract 20 This document enumerates methods of port assignment in Carrier Grade 21 NATs (CGNs), focused particularly on NAT64 environments. Different 22 NAT port allocation methods have been categorized and described. A 23 series of port allocation design principles has been proposed to 24 facilitate the implementations and 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 January 23, 2016. 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Description of Port Allocation Methods . . . . . . . . . . . 3 62 2.1. Specific Feature of NAT64 Port Consumption . . . . . . . 3 63 2.2. Classification of Port Allocation Models . . . . . . . . 3 64 2.2.1. Stateful vs. Stateless . . . . . . . . . . . . . . . 3 65 2.2.2. Dynamic vs. Static . . . . . . . . . . . . . . . . . 4 66 2.2.3. Centralized vs. Distributed . . . . . . . . . . . . . 5 67 2.3. Port Allocation Solutions . . . . . . . . . . . . . . . . 6 68 2.3.1. Stateful Technologies . . . . . . . . . . . . . . . . 6 69 2.3.2. Stateless Technologies . . . . . . . . . . . . . . . 6 70 2.3.3. Port Control Protocol (PCP) . . . . . . . . . . . . . 7 71 3. Port Allocation Design Principles . . . . . . . . . . . . . . 7 72 3.1. Log Volume Optimization . . . . . . . . . . . . . . . . . 7 73 3.2. Connectivity State Optimization . . . . . . . . . . . . . 9 74 3.3. Port Randomization . . . . . . . . . . . . . . . . . . . 9 75 3.4. Port-range Implementation Recommendation . . . . . . . . 10 76 3.4.1. Port Randomization and Port-Range Deallocation . . . 10 77 3.4.2. Issues Of Traceability . . . . . . . . . . . . . . . 11 78 3.4.3. Other Considerations . . . . . . . . . . . . . . . . 12 79 4. Security Considerations . . . . . . . . . . . . . . . . . . . 12 80 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 81 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 82 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 83 7.1. Normative References . . . . . . . . . . . . . . . . . . 14 84 7.2. Informative References . . . . . . . . . . . . . . . . . 15 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 87 1. Introduction 89 As a result of the depletion of public IPv4 addresses, Carrier Grade 90 NAT (CGN) has been adopted by ISPs to share the available IPv4 91 resources. Overall, a CGN function maps IP addresses from one 92 address realm to another, relying upon a mechanism of multiplexing 93 multiple subscribers' connections over a number of shared IPv4 94 addresses to provide connectivity services to end hosts. A network- 95 based NAT is implied by several approaches to IPv4 service continuity 96 over an IPv6 network including DS-Lite [RFC6333], NAT64 ([RFC6145] 97 and [RFC6146]), etc. 99 In this memo, Section 2 has described the category of port allocation 100 mechnism and relevant solutions. Section 3 looks more closely at 101 different port allocation design principles, including log volume 102 consideration, connectivity state optimization, Port-range 103 implementation and port randomization. The proposals made in this 104 section are applicable to the CGN environment in general, 105 independently of the particular flavor of translation being used. 107 2. Description of Port Allocation Methods 109 2.1. Specific Feature of NAT64 Port Consumption 111 There was a test comparison of port consumption [RFC7269] on NAT64 112 and NAT44. Top100 websites (referring to Alexa statistics) were 113 assessed to evaluate status of port usage on NAT44 and NAT64 114 respectively. It has been observed that the port consumption per 115 session on NAT64 is roughly only half that on NAT44. 43 percent of 116 top100 websites have AAAA records, therefore the NAT64 didn't have to 117 assign ports to the traffic going to those websites. The results may 118 be different if more services (e.g. game, web-mail, etc) are 119 considered. But it is apparent that the effects of port saving on 120 NAT64 will be amplified by increasing native IPv6 support. 122 Apart from the above observation, port allocation can be tuned 123 according to the phase of IPv6 migration. As more content providers 124 and services become available over IPv6, the utilization of NAT64 125 goes down since fewer destinations require translation progressing. 126 Thus as IPv6 migration proceeds, it will be possible to relax the 127 multiplexing ratio of IPv4 address sharing (see Appendix B of 128 [RFC6269]). 130 2.2. Classification of Port Allocation Models 132 This section lists several categories to allocate the port 133 information in NAT64. It also describes example cases for each 134 allocation model. 136 2.2.1. Stateful vs. Stateless 138 o Stateful 140 The stateful NAT can be implemented either by static address 141 translation or dynamic address translation. 143 In the case of static address assignment, a one-to-one address 144 mapping for hosts between a IPv6 network address and an IPv4 145 network address is pre-configured on the NAT operation. This case 146 normally occurs when a server is deployed in an IPv6 domain. The 147 static configuration ensures stable inbound connectivity. 149 Dynamic address assignment would periodically free the binding so 150 that the global address could be recycled for later use. This 151 increases the efficiency of usage of IPv4 resources. 153 o Stateless 155 Stateless NAT is performed in compliance with [RFC6145]. The 156 public IPv4 address is required to be embedded in the IPv6 157 address. Thus the NAT64 can directly extract the address and has 158 no need to record mapping states. 160 A promising usage of stateless NAT may appear in the data centre 161 environment where IPv6 server pools receive inbound connections from 162 IPv4 users externally [I-D.ietf-v6ops-siit-dc]. NAT usage in other 163 cases may be controversial. First off, the static one-to-one mapping 164 does not address the issue of IPv4 depletion. Secondly, it 165 introduces a dependency between IPv4 and IPv6 addressing. That 166 creates other limitations since a change of IPv4 address will cause 167 renumbering of IPv6 addresses. 169 2.2.2. Dynamic vs. Static 171 Port assignments can be dynamic (ports allocated on demand) or static 172 (ports allocated as part of the configuration process). 174 o Dynamic assignment 176 NAT64 uses dynamic assignment, since this achieves higher port 177 utilization. Port allocations can be made with per-session or 178 per-customer granularity. Per-session assignment is configured on 179 the NAT64 by default since it maximizes port utilization. 180 However, if only individual port numbers are assigned, this can 181 result in a heavy log volume that may have to be recorded for 182 legal data retention systems. To mitigate that concern, the NAT64 183 may dynamically allocate a port range for each connected 184 subscriber or upon receipt of a first outgoing packet from an IPv6 185 host. This will significantly reduce log volume. 187 A proper port-range configuration should take user experiences 188 into the considerations. A subscriber normally uses multiple 189 applications simultaneously, e.g. maps applications, online video 190 or game. The number of concurrent sessions is essential to 191 determine the number of ports the subscriber needs. A study from 192 China Mobile has revealed that the average number of sessions 193 consumed by one user's device was around 200 to 300 ports. 194 Several devices may appear behind a CPE. Based on this 195 observation, 1000 ports per subscriber household will provide 196 enough room for multiple active users. Administrators should 197 monitor usage to adjust this number if users are being limited by 198 this number, or if usage is so low that fewer ports would be 199 sufficient. 201 o Static assignment 203 Static assignment makes port reservations in bulk for each 204 internal address before subscriber connection. The assigned ports 205 can be in either a contiguous port range or a non-contiguous port 206 range for the sake of defense against port-guessing attacks (see 207 Section 3.4.1). Log recording for each port assignment may not be 208 necessary due to the stable mapping relations. Considerations of 209 the interaction between port-range allocation and capacity impact 210 are also applicable in the case of static assignment. [RFC7422] 211 describes a deterministic algorithm to assign a port range for an 212 internal IP address pool in a sequence. 214 2.2.3. Centralized vs. Distributed 216 There is an increasing need to connect NAT64 with downstream 217 NAT46-capable devices to support IPv4 users/applications on an 218 IPv6-only path. Several solutions have been proposed in this area, 219 e.g., 464xlat [RFC6877], MAP-T [I-D.ietf-softwire-map-t] and 4rd 220 [I-D.ietf-softwire-4rd]. Port allocation can be categorized as a 221 centralized assignment on NAT64 or as a port delegation distributed 222 to downstream devices (e.g, Customer Edge connected with NAT64). 224 o Centralized Assignment 226 A centralized method makes port assignments once IP flows come to 227 the NAT64. The allocation policy is enforced on a centralized 228 point. Either a dynamic or static port assignment is made for 229 received sessions. 231 o Distributed Assignment 233 NAT64 can also delegate the pre-allocated port range to customer 234 edge devices. That can be achieved through additional out-of-band 235 provisioning signals (e.g., [I-D.ietf-pcp-port-set], 236 [I-D.ietf-softwire-map-dhcp]). The distributed model normally is 237 performed A+P style [RFC6346] for static port assignment. The 238 NAT64 should also hold the corresponding mapping in order to 239 validate port usage in the outgoing direction and route inbound 240 packets. Delegated port ranges shift NAT64 port computations/ 241 states into downstream devices. The detailed benefits of this 242 approach are documented in 243 [I-D.ietf-softwire-stateless-4v6-motivation]. 245 2.3. Port Allocation Solutions 247 2.3.1. Stateful Technologies 249 [RFC6146] describes a process where the dynamic binding is created by 250 an outgoing packet, but it may also be created by other means such as 251 a Port Control Protocol request (see Section 2.3.3). Looking beyond 252 NAT64 for the moment, DS-Lite [RFC6333] refers to the cautions in 253 [RFC6269] but does not specify any port allocation method. Both 254 techniques DS-Lite and NAT64 assume a centralized model. 256 The specifications for both transition methods thus allow 257 implementations to use the proposals made in individual port 258 allocation and port range allocation 260 2.3.2. Stateless Technologies 262 The port allocation solutions that are being specified at the time of 263 writing of this document are all variations on the static distributed 264 model, to minimize the amount of state that has to be held in the 265 network. That work includes: 267 o Light-weight 4over6 (LW4o6 [I_D.ietf-softwire-lw4over6]), which 268 requires the CPE to be configured explicitly with the shared IPv4 269 address and port set it will use on the WAN side of its NAT44 270 function. The border router is configured with the same 271 information, reducing the state it must hold from per-session to 272 per-subscriber amounts. 274 o Mapping of Address and Port with Encapsulation (MAP-E 275 [I-D.ietf-softwire-map]) and the experimental specifications 276 Mapping of Address and Port with Translation (MAP-T 277 [I-D.ietf-softwire-map-t]) and 4rd [I-D.ietf-softwire-4rd], 278 already mentioned. These rely on an algorithmic embedding of WAN- 279 side IPv4 address and assigned port set within the IPv6 prefix 280 assigned to each CPE. Both the CPE and the border router must be 281 configured with this information. However, the algorithm is 282 designed to aggregate routing information such that the amount of 283 state carried by the border router is of a lower order of 284 magnitude than even the per-subscriber level. 286 All A+P variants support a 1-1 mapping mode, where the IPv4 and IPv6 287 addresses assigned to a CPE are independent. This can be helpful in 288 transition, but, as with LW4o6, raises the amount of state in the 289 network back to the per-subscriber level. 291 For a packet destined to a host outside the MAP domain from which the 292 packet originated: MAP-E and 4rd treat the packet as an IPv4 over 293 IPv6 tunnel via the border router. 295 MAP-T uses stateless mapping in the sense of Section 2.2.1 by 296 embedding the destination IPv4 address within the IPv6 address of the 297 packet sent to the border router. 299 2.3.3. Port Control Protocol (PCP) 301 The Port Control Protocol (PCP, [RFC6887]) can be used to reserve a 302 single port or a port set [I-D.ietf-pcp-port-set] for applications. 303 It requires that the NAT be controlled by a PCP server function. PCP 304 provides an out-of-band signalling mechanism for coordinating dynamic 305 allocation of ports between hosts and the border router, removes the 306 need for ALGs, allows for successful incoming connections, etc. 308 3. Port Allocation Design Principles 310 3.1. Log Volume Optimization 312 [RFC6269] provides a thoughtful analysis on the issues of IP address 313 sharing. It points out that IP address sharing may impact law 314 enforcement since source address information will be lost during the 315 translation.In order to identify a specific user associated with an 316 IP address in a particular time slot, network administrators have to 317 log the mapping status for each connection in a dedicated logging 318 server. The storage of log information may pose a challenge to 319 operators, since it requires additional resources and data inspection 320 processes to identify users. For concrete details of what should be 321 logged, see Section 3.1 of [I-D.ietf-behave-syslog-nat-logging]. The 322 actual logging may use either IPFIX [RFC7011] or Syslog [RFC5424] 323 depending on the operator's requirements. 325 It is desirable to reduce the volume of the logged information. 326 Referring to the classification of port allocation methods given 327 above, dynamic assignments can be managed on either a per-session or 328 per-customer granularity. The coarser granularity will lead to lower 329 log volume storage. A test was made by recording the log information 330 from 200,000 subscribers in the Chinese network for 60 days. The 331 volume of recorded information reached up to 42.5 terabytes with per- 332 session logging in the raw format. The volume could be reduced to 333 10.6 terabytes with gzip format. Compared with that, it only 334 occupied 40.6 gigabytes, three orders of magnitude smaller volume, 335 with per-customer logging in the raw format (A port range sized by 336 1000 ports have been used). With static allocation, of course, no 337 logs for port assignment are required, but a record of the 338 configuration change is still required. 340 On the other hand, the lower logging volumes are associated with 341 lower efficiency of port utilization. A port allocation based on 342 per-customer granularity has to retain vacant ports in order to avoid 343 traffic overflow. The efficiency can be evaluated by port 344 utilization rate, and will be even lower if the static port 345 allocation method is used. Inactive users may also impact the 346 efficiency. 348 Table 1 summarizes the test results using Syslog. The ports were 349 pre-allocated to customers regardless of online or offline status. 351 +--------------------+--------------+----------------+--------------+ 352 | Port Allocation | Log | Estimated Log | Port | 353 | Method | Granularity | Volume | Utilization | 354 +--------------------+--------------+----------------+--------------+ 355 | Dynamic NAPT | Per-session | 42.5 terabytes | 100% | 356 | Dynamic port-range | Per-customer | 40.6 Gigabytes | 75% | 357 | Deterministic NAT, | None | None | (60% * 75%) | 358 | MAP-T, 4rd | | | = 45% | 359 +--------------------+--------------+----------------+--------------+ 361 Table 1: Estimated Log Volumes For 200,000 Users Over 60 Days 363 Note: 75% is the estimated port utilization ratio per active 364 subscriber. 60% is the estimated ratio of active subscribers to the 365 total number of subscribers. 367 The data shown in Table 1 roughly demonstrates the tradeoff between 368 port utilization and log volume reduction. Administrators may 369 consider the following factors to make their design choice that would 370 meet their deployment requirements: 372 o average connectivity per customer per day; 374 o peak connectivity per day; 376 o the number of public IPv4 addresses available to the NAT64; 378 o application demands for specific ports; 380 o processing capabilities of the NAT64; 381 o tolerable log volume. 383 3.2. Connectivity State Optimization 385 It has been observed that port consumption is significantly increased 386 once subscribers land on a web page for video on demand, an online 387 game, or map services. In those cases, multiple TCP connections may 388 be initiated to optimize the performance of data transmissions for 389 video download and message exchange. Given the video traffic growth 390 trend, this likely presents a challenge for network operators who 391 need to optimize connectivity states and avoid port depletion. Those 392 optimizations may even affect the method of port-range allocation, 393 because a subscriber is only allowed to use a pre-configured port 394 resource. 396 Two optimizations may be considered: 398 o Reducing the TIME-WAIT state. It is rather common that users 399 change video channels often. Investigations have shown that 60% 400 of videos are watched for less than 20% of their duration. The 401 user's access patterns may leave a number of the TIME-WAIT states. 402 Therefore, acceleration of TIME-WAIT state transitions could 403 increase the efficiency of port utilization. [RFC6191] defines a 404 mechanism for reducing TIME-WAIT state by proposing TCP timestamps 405 and sequence numbers. 407 [I-D.penno-behave-rfc4787-5382-5508-bis] recommended applying 408 [RFC6191] and PAWS (Protect Against Wrapped Sequence numbers, 409 described in [RFC1323]) to NAT. This may also be a way to improve 410 port utilization. 412 o Another possibility is to use Address-Dependent Mapping or Address 413 and Port-Dependent Mapping [RFC4787] to increase port utilization. 414 This feature has already been implemented on a vendor-specific 415 basis. However, it should be noted that REQ-7 and REQ-12 in 416 [RFC6888] may reduce the incentive to use anything but the 417 Address-Independent Mapping behaviour recommended by [RFC4787]. 419 3.3. Port Randomization 421 Port randomization is a feature to enhance the defense against 422 hijacking of flows. [RFC6056] specifies that: 424 "A NAPT that does not implement port preservation ([RFC4787], 425 [RFC5382]) should obfuscate selection of the ephemeral port of a 426 packet when it is changed during translation of that packet." 428 A NAPT based on per-session allocation normally follows this 429 recommendation. 431 See Section 4 for a fuller discussion of port randomization. 433 3.4. Port-range Implementation Recommendation 435 Allocating a range of N ports at once reduces the log volume by a 436 factor of N, while also reducing port utilization by a factor which 437 varies with the address sharing ratio and other configuration 438 parameters. This provides a clear motivation to use dynamic 439 allocation of port-ranges rather than individual ports when it is 440 possible to do so while maintaining a satisfactory level of port 441 utilization (and by implication, shared global IPv4 address 442 utilization). Dynamic allocation of port ranges may be used either 443 as the sole strategy for port allocation on the NAPT, or as a 444 supplement to an initial static allocation. This section will 445 provide specific consideration to the implementation. 447 3.4.1. Port Randomization and Port-Range Deallocation 449 When the user sends out the first packet, a port resource pool is 450 allocated for the user, e.g., assigning ports 2001~2300 of a public 451 IP address to the user's resource pool. Only one log should be 452 generated for this port block. When the NAT needs to set up a new 453 mapping entry for the user, it can use a port in the user's resource 454 pool and the corresponding public IP address. If the user needs more 455 port resources, the NAT can allocate another port block, e.g., ports 456 3501~3800, to the user's resource pool. Again, just one log needs to 457 be generated for this port block. 459 Cryptographically random port assignment is discussed in Section 2.2 460 of [RFC6431]. Indeed, [RFC6431] takes this idea further by 461 allocating non-contiguous sets of ports using a pseudorandom 462 function. Scattering the allocated ports in this way provides a 463 modest barrier to port guessing attacks. The use of randomization is 464 discussed further in Section 4. 466 Suppose now that a given internal address has been assigned more than 467 one block of ports. The individual sessions using ports within a 468 port block will start and end at different times. If no ports in 469 some port block are used for some configurable time, the NAT can 470 remove the port block from the resource pool allocated to a given 471 internal address, and make it available for other users. In theory, 472 it is unnecessary to log deallocations of blocks of ports, because 473 the ports in deallocated blocks will not be used again until the 474 blocks are reallocated. However, the deallocation may be logged when 475 it occurs to add robustness to troubleshooting or other procedures. 477 The deallocation procedure presents a number of difficulties in 478 practice. The first problem is the choice of timeout value for the 479 block. If idle timers are applied for the individual mappings 480 (sessions) within the block, and these conform to the recommendations 481 for NAT behaviour for the protocol concerned, then the additional 482 time that might be configured as a guard for the block as a whole 483 need not be more than a few minutes. The block timer in this case 484 serves only as a slightly more conservative extension of the 485 individual session idle timers. If, instead, a single idle timer is 486 used for the whole block, it must itself conform to the 487 recommendations for the protocol with which that block of ports is 488 associated. For example, REQ-5 of [RFC5382] requires an idle timer 489 expiry duration of at least 2 hours and 4 minutes for TCP. The 490 suggestions made in Section 3.2 may be considered for reducing this 491 time. 493 The next issue with port block deallocation is the conflict between 494 the desire to randomize port allocation and the desire to make unused 495 resources available to other internal addresses. As mentioned above, 496 ideally port selection will take place over the entire set of blocks 497 allocated to the internal address. However, taken to its fullest 498 extent, such a policy will minimize the probability that all ports in 499 any given block are idle long enough for it to be released. 501 As an alternative, it is suggested that when choosing which block to 502 select a port from, the NAT should omit from its range of choice the 503 block that has been idle the longest, unless no ports are available 504 in any of the other blocks. The expression "block that has been idle 505 the longest" designates the block in which the time since the last 506 packet was observed in any of its sessions, in either direction, is 507 earlier than the corresponding time in any of the other blocks 508 assigned to that internal address. As [RFC6269] points out, port 509 randomization is just one security measure of several, and the loss 510 of randomness incurred by the suggested procedure is justified by the 511 increased utilization of port resources it allows. 513 3.4.2. Issues Of Traceability 515 Section 12 of [RFC6269] provides a good discussion of the 516 traceability issue. Complete traceability given the NAT logging 517 practices proposed in this draft requires that the remote destination 518 record the source port of a request along with the source address 519 (and presumably protocol, if not implicit) [RFC6302]. In addition, 520 the logs at each end must be timestamped, and the clocks must be 521 synchronized within a certain degree of accuracy. Here is one reason 522 for the guard timing on block release, to increase the tolerable 523 level of clock skew between the two ends. 525 Where source port logging can be enabled, this memo strongly urges 526 the operators to do so. Similarly, intrusion detection systems 527 should capture source port as well as source address of suspect 528 packets. 530 In some cases [RFC6269], a server may not record the source port of a 531 connection. To allow traceability, the NAT device needs to record 532 the destination IP address of a connection. As [RFC6269] points out, 533 this will provide an incomplete solution to the issue of traceability 534 because multiple users of the same shared public IP address may 535 access the service at the same time. From the point of view of this 536 draft, in such situations the game is lost, so to speak, and port 537 allocation at the NAT might as well be completely dynamic. 539 The final possibility to consider is where the NAT does not do per- 540 session logging even given the possibility that the remote end is 541 failing to capture source ports. In that case, the port allocation 542 strategy proposed in this section can be used. The impact on 543 traceability is that analysis of the logs would yield only the list 544 of all internal addresses mapped to a given public address during the 545 period of time concerned. This has an impact on privacy as well as 546 traceability, depending on the follow-up actions taken. 548 3.4.3. Other Considerations 550 [RFC6269] notes several issues introduced by the use of dynamic as 551 opposed to static port assignment. For example, Section 12.2 of that 552 document notes the effect on authentication procedures. These issues 553 must be resolved, but are not specific to the dynamic port-range 554 allocation strategy. 556 4. Security Considerations 558 The discussion which follows addresses an issue that is particularly 559 relevant to the strategies described in Section 3 of this document. 560 The security considerations applicable to NAT operation for various 561 protocols as documented in, for example, [RFC4787] and [RFC5382] also 562 apply to this proposal. 564 [RFC6056] summarizes the TCP port-guessing attack, by means of which 565 an attacker can hijack one end of a TCP connection. One mitigating 566 measure is to make the source port number used for a TCP connection 567 less predictable. [RFC6056] provides various algorithms for this 568 purpose. 570 As Section 3.1 of that RFC notes: "...provided adequate algorithms 571 are in use, the larger the range from which ephemeral ports are 572 selected, the smaller the chances of an attacker are to guess the 573 selected port number." Conversely, the reduced range sizes proposed 574 by the present document increase the attacker's chances of guessing 575 correctly. This result cannot be totally avoided. However, 576 mitigating measures to improve this situation can be taken both at 577 port block assignment time and when selecting individual ports from 578 the blocks that have been allocated to a given user. 580 At assignment time, one possibility is to assign ports as non- 581 contiguous sets of values as proposed in [RFC6431]. However, this 582 approach creates a lot of complexity for operations, and the pseudo 583 randomization can create uncertainty when the accuracy of logs is 584 important to protect someone's life or liberty. 586 Alternatively, the NAT can assign blocks of contiguous ports. 587 However, at assignment time the NAT could attempt to randomize its 588 choice of which of the available idle blocks it would assign to a 589 given user. This strategy has to be traded off against the 590 desirability of minimizing the chance of conflict between what 591 [RFC6056] calls "transport protocol instances" by assigning the most- 592 idle block, as suggested in Section 3. A compromise policy might be 593 to assign blocks only if they have been idle for a certain amount of 594 time whenever possible, and select pseudorandomly between the blocks 595 available according to this criterion. In this case it is suggested 596 that the time value used be greater than the guard timing mentioned 597 in Section 3, and that no block should ever be reassigned until it 598 has been idle at least for the duration given by the guard timer. 600 Note that with the possible exception of cryptographically-based port 601 allocations, attackers could reverse-engineer algorithmically-derived 602 port allocations to either target a specific subscriber or to spoof 603 traffic to make it appear to have been generated by a specific 604 subscriber. However, this is exactly the same level of security that 605 the subscriber would experience in the absence of CGN. CGN is not 606 intended to provide additional security by obscurity. 608 While the block assignment strategy can provide some mitigation of 609 the port guessing attack, the largest contribution will come from 610 pseudo-randomization at port selection time. [RFC6056] provides a 611 number of algoriths for achieving this pseudo-randomization. When 612 the available ports are contained in blocks which are not in general 613 consecutive, the algorithms clearly need some adaptation. The task 614 is complicated by the fact that the number of blocks allocated to the 615 user may vary over time. Adaptation is left as an exercise for the 616 implementor. 618 5. IANA Considerations 620 This document makes no request of IANA. 622 6. Acknowledgements 624 This document is the result of a merger of the original draft-chen- 625 sunset4-cgn-port-allocation and draft-tsou-behave-natx4-log- 626 reduction. Version -02 of draft-chen contains the following 627 acknowledgements: 629 The author would like to thank Lee Howard and Simon Perreault for 630 their helpful comments. 632 Many thanks to Wesley George and Marc Blanchet encourage the 633 author to continue this work. 635 The authors of draft-tsou-behave-natx4-log-reduction have their own 636 thanks to give. Mohamed Boucadair reviewed the initial document and 637 provided useful comments to improve it. Reinaldo Penno, Joel 638 Jaeggli, and Dan Wing provided comments on the subsequent version 639 that resulted in major revisions. Serafim Petsis provided 640 encouragement to publication after a hiatus of two years. 642 The present version of the document benefited from further comments 643 by Lee Howard and Mohamed Boucadair. 645 7. References 647 7.1. Normative References 649 [RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport- 650 Protocol Port Randomization", BCP 156, RFC 6056, 651 DOI 10.17487/RFC6056, January 2011, 652 . 654 [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation 655 Algorithm", RFC 6145, DOI 10.17487/RFC6145, April 2011, 656 . 658 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 659 NAT64: Network Address and Protocol Translation from IPv6 660 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, 661 April 2011, . 663 [RFC6269] Ford, M., Ed., Boucadair, M., Durand, A., Levis, P., and 664 P. Roberts, "Issues with IP Address Sharing", RFC 6269, 665 DOI 10.17487/RFC6269, June 2011, 666 . 668 7.2. Informative References 670 [I-D.ietf-behave-syslog-nat-logging] 671 Chen, Z., Zhou, C., Tsou, T., and T. Taylor, "Syslog 672 Format for NAT Logging (Work in Progress)", January 2014. 674 [I-D.ietf-pcp-port-set] 675 Sun, Q., Boucadair, M., Sivakumar, S., Zhou, C., Tsou, T., 676 and S. Perrault, "Port Control Protocol (PCP) Extension 677 for Port Set Allocation (Work in Progress)", November 678 2014. 680 [I-D.ietf-softwire-4rd] 681 Despres, R., Jiang, S., Penno, R., Lee, Y., Chen, G., and 682 M. Chen, "IPv4 Residual Deployment via IPv6 - a Stateless 683 Solution (4rd) (Work in Progress)", December 2014. 685 [I-D.ietf-softwire-map] 686 Troan, O., Dec, W., Li, X., Bao, C., Matsushima, S., 687 Murakami, T., and T. Taylor, "Mapping of Address and Port 688 with Encapsulation (MAP) (Work in Progress)", March 2015. 690 [I-D.ietf-softwire-map-dhcp] 691 Mrugalski, T., Troan, O., Dec, W., Farrer, I., Perrault, 692 S., Bao, C., Yeh, L., and X. Deng, "DHCPv6 Options for 693 configuration of Softwire Address and Port Mapped Clients 694 (Work in Progress)", March 2015. 696 [I-D.ietf-softwire-map-t] 697 Li, X., Bao, C., Dec, W., Troan, O., Matsushima, S., and 698 T. Murakami, "Mapping of Address and Port using 699 Translation (MAP-T) (Work in progress)", December 2014. 701 [I-D.ietf-softwire-stateless-4v6-motivation] 702 Boucadair, M., Matsushima, S., Lee, Y., Bonness, O., 703 Borges, I., and G. Chen, "Motivations for Carrier-side 704 Stateless IPv4 over IPv6 Migration Solutions (Expired work 705 in Progress)", November 2012. 707 [I-D.ietf-v6ops-siit-dc] 708 Anderson, T., "SIIT-DC: Stateless IP/ICMP Translation for 709 IPv6 Data Centre Environments (Work in progress)", 710 December 2014. 712 [I-D.penno-behave-rfc4787-5382-5508-bis] 713 Penno, R., Perrault, S., Kamiset, S., Boucadair, M., and 714 K. Naito, "Network Address Translation (NAT) Behavioral 715 Requirements Updates (expired Work in Progress)", January 716 2013. 718 [I_D.ietf-softwire-lw4over6] 719 Cui, Y., Sun, Q., Boucadair, M., Tsou, T., Lee, Y., and I. 720 Farrer, "Lightweight 4over6: An Extension to the DS-Lite 721 Architecture (Work in Progress)", November 2014. 723 [RFC1323] Jacobson, V., Braden, R., and D. Borman, "TCP Extensions 724 for High Performance", RFC 1323, DOI 10.17487/RFC1323, May 725 1992, . 727 [RFC4787] Audet, F., Ed. and C. Jennings, "Network Address 728 Translation (NAT) Behavioral Requirements for Unicast 729 UDP", BCP 127, RFC 4787, DOI 10.17487/RFC4787, January 730 2007, . 732 [RFC5382] Guha, S., Ed., Biswas, K., Ford, B., Sivakumar, S., and P. 733 Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, 734 RFC 5382, DOI 10.17487/RFC5382, October 2008, 735 . 737 [RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, 738 DOI 10.17487/RFC5424, March 2009, 739 . 741 [RFC6191] Gont, F., "Reducing the TIME-WAIT State Using TCP 742 Timestamps", BCP 159, RFC 6191, DOI 10.17487/RFC6191, 743 April 2011, . 745 [RFC6302] Durand, A., Gashinsky, I., Lee, D., and S. Sheppard, 746 "Logging Recommendations for Internet-Facing Servers", 747 BCP 162, RFC 6302, DOI 10.17487/RFC6302, June 2011, 748 . 750 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 751 Stack Lite Broadband Deployments Following IPv4 752 Exhaustion", RFC 6333, DOI 10.17487/RFC6333, August 2011, 753 . 755 [RFC6346] Bush, R., Ed., "The Address plus Port (A+P) Approach to 756 the IPv4 Address Shortage", RFC 6346, 757 DOI 10.17487/RFC6346, August 2011, 758 . 760 [RFC6431] Boucadair, M., Levis, P., Bajko, G., Savolainen, T., and 761 T. Tsou, "Huawei Port Range Configuration Options for PPP 762 IP Control Protocol (IPCP)", RFC 6431, 763 DOI 10.17487/RFC6431, November 2011, 764 . 766 [RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: 767 Combination of Stateful and Stateless Translation", 768 RFC 6877, DOI 10.17487/RFC6877, April 2013, 769 . 771 [RFC6887] Wing, D., Ed., Cheshire, S., Boucadair, M., Penno, R., and 772 P. Selkirk, "Port Control Protocol (PCP)", RFC 6887, 773 DOI 10.17487/RFC6887, April 2013, 774 . 776 [RFC6888] Perreault, S., Ed., Yamagata, I., Miyakawa, S., Nakagawa, 777 A., and H. Ashida, "Common Requirements for Carrier-Grade 778 NATs (CGNs)", BCP 127, RFC 6888, DOI 10.17487/RFC6888, 779 April 2013, . 781 [RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken, 782 "Specification of the IP Flow Information Export (IPFIX) 783 Protocol for the Exchange of Flow Information", STD 77, 784 RFC 7011, DOI 10.17487/RFC7011, September 2013, 785 . 787 [RFC7269] Chen, G., Cao, Z., Xie, C., and D. Binet, "NAT64 788 Deployment Options and Experience", RFC 7269, 789 DOI 10.17487/RFC7269, June 2014, 790 . 792 [RFC7422] Donley, C., Grundemann, C., Sarawat, V., Sundaresan, K., 793 and O. Vautrin, "Deterministic Address Mapping to Reduce 794 Logging in Carrier-Grade NAT Deployments", RFC 7422, 795 DOI 10.17487/RFC7422, December 2014, 796 . 798 Authors' Addresses 800 Gang Chen 801 China Mobile 802 53A,Xibianmennei Ave., 803 Xuanwu District, 804 Beijing 100053 805 P.R. China 807 Email: phdgang@gmail.com 808 Weibo Li 809 China Telecom 810 109, Zhongshan Ave. West, Tianhe District 811 Guangzhou 510630 812 P.R. China 814 Email: mweiboli@gmail.com 816 Tina Tsou 817 Huawei Technologies 818 Bantian, Longgang District 819 Shenzhen 518129 820 P.R. China 822 Email: tina.tsou.zouting@huawei.com 824 James Huang 825 Huawei Technologies 826 Bantian, Longgang District 827 Shenzhen 518129 828 P.R. China 830 Email: James.huang@huawei.com 832 Tom Taylor 833 PT Taylor Consulting 834 Ottawa, Ontario 835 Canada 837 Email: tom.taylor.stds@gmail.com 839 Jean-Francois Tremblay 840 Viagenie 841 246 Aberdeen 842 Quebec, QC G1R 2E1 843 Canada 845 Phone: +1 418 656 9254 846 Email: jean-francois.tremblay@viagenie.ca 847 URI: http://viagenie.ca