idnits 2.17.1 draft-chen-sunset4-cgn-port-allocation-04.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 : ---------------------------------------------------------------------------- == There are 19 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 10, 2014) is 3666 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 6145 (Obsoleted by RFC 7915) -- No information found for draft-anderson-siit-dc - is the name correct? -- No information found for draft-bajko-pripaddrassign - is the name correct? -- No information found for draft-ietf-behave-syslog-nat-logging - is the name correct? -- Obsolete informational reference (is this intentional?): RFC 1323 (Obsoleted by RFC 7323) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 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 T. Tsou 5 Expires: October 12, 2014 Huawei Technologies 6 C. Donley 7 CableLabs 8 T. Taylor 9 PT Taylor Consulting 10 April 10, 2014 12 Analysis of NAT64 Port Allocation Methods for Shared IPv4 Addresses 13 draft-chen-sunset4-cgn-port-allocation-04 15 Abstract 17 This document enumerates methods of port assignment in Carrier Grade 18 NATs (CGNs), focused particularly on NAT64 environments. A 19 theoretical framework of different NAT port allocation methods is 20 described. The memo is intended to clarify and focus the port 21 allocation discussion and propose an integrated view of the 22 considerations for selection of the port allocation mechanism in a 23 given deployment. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on October 12, 2014. 42 Copyright Notice 44 Copyright (c) 2014 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Considerations For the Choice of Port Allocation Methods . . 3 61 2.1. Port Consumption on NAT64 . . . . . . . . . . . . . . . . 4 62 2.2. Classification of Port Allocation Models . . . . . . . . 5 63 2.2.1. Stateful vs. Stateless . . . . . . . . . . . . . . . 5 64 2.2.2. Dynamic vs. Static . . . . . . . . . . . . . . . . . 5 65 2.2.3. Centralized vs. Distributed . . . . . . . . . . . . . 6 66 2.3. Port Allocation Solutions . . . . . . . . . . . . . . . . 7 67 2.3.1. Older Transition Technologies . . . . . . . . . . . . 7 68 2.3.2. Current Work On Stateless Transition Technologies . . 7 69 2.3.3. Port Control Protocol (PCP) . . . . . . . . . . . . . 8 70 2.4. Specific Considerations . . . . . . . . . . . . . . . . . 8 71 2.4.1. Log Volume Optimization . . . . . . . . . . . . . . . 8 72 2.4.2. Connectivity State Optimization . . . . . . . . . . . 10 73 2.4.3. Port Randomization . . . . . . . . . . . . . . . . . 11 74 3. Considerations For the Dynamic Assignment of Port-Ranges . . 11 75 3.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 11 76 3.2. Implementation Issues -- Port Randomization and Port- 77 Range Deallocation . . . . . . . . . . . . . . . . . . . 12 78 3.3. Issues Of Traceability . . . . . . . . . . . . . . . . . 13 79 3.4. Other Considerations . . . . . . . . . . . . . . . . . . 14 80 4. Deterministic Port Allocation . . . . . . . . . . . . . . . . 14 81 4.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 14 82 4.2. Deterministic Port Ranges . . . . . . . . . . . . . . . . 16 83 4.2.1. IPv4 Port Utilization Efficiency . . . . . . . . . . 19 84 4.2.2. Planning and Dimensioning . . . . . . . . . . . . . . 19 85 4.2.3. Deterministic CGN Example . . . . . . . . . . . . . . 20 86 4.2.4. Additional Management Considerations . . . . . . . . 21 87 4.3. Failover Considerations . . . . . . . . . . . . . . . . . 22 88 4.4. Impact On IPv6 Transition . . . . . . . . . . . . . . . . 22 89 5. Security Considerations . . . . . . . . . . . . . . . . . . . 22 90 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 91 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 24 92 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24 93 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 94 9.1. Normative References . . . . . . . . . . . . . . . . . . 24 95 9.2. Informative References . . . . . . . . . . . . . . . . . 25 96 Appendix A. Configuration of Server Software to Log Source 97 Port . . . . . . . . . . . . . . . . . . . . . . . . 28 98 A.1. Apache . . . . . . . . . . . . . . . . . . . . . . . . . 28 99 A.2. Postfix . . . . . . . . . . . . . . . . . . . . . . . . . 28 100 A.3. Sendmail . . . . . . . . . . . . . . . . . . . . . . . . 28 101 A.4. sshd . . . . . . . . . . . . . . . . . . . . . . . . . . 29 102 A.5. Cyrus IMAP and UW IMAP . . . . . . . . . . . . . . . . . 30 103 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 105 1. Introduction 107 With the depletion of IPv4 addresses, Carrier Grade NAT (CGN) has 108 been adopted by ISPs to expand IPv4 spaces. CGN maps IP addresses 109 from one address realm to another, relying upon the mechanism of 110 multiplexing multiple subscribers' connections over a smaller number 111 of shared IPv4 addresses to provide transparent routing to end hosts. 112 [RFC6888] specifies a number of CGN requirements. A network-based 113 NAT is implied by several approaches to IPv6 transition including DS- 114 Lite [RFC6333], NAT64 ([RFC6145] and [RFC6146]), and NAT444. All of 115 these would likely fall within the scope of the CGN requirements 116 document [RFC6888]. 118 The first part of this memo (Section 2) focusses on the topic of IPv6 119 migration. The CGN may not do Network Address Port Translation 120 (NAPT), but only Network Address Translation (NAT) [RFC3022]. In 121 this scenario, there is no concern about port assignment. When NAPT 122 is involved, Section 2 elaborates on the considerations for address 123 sharing and particularly port assignment in the NAT64 environment, 124 where IPv6-only nodes are connected to external dual-stack or IPv4 125 networks. 127 Section 3 looks more closely at dynamic bulk assignment of ports to 128 individual subscriber sites, particularly as a means of log volume 129 reduction. The proposals made in this section are applicable to the 130 CGN environment in general, independently of the particular flavour 131 of translation being used. 133 Finally, Section 4 looks at a scheme for assignment of ports using a 134 deterministic algorithm that has the potential to simplify 135 operations. 137 2. Considerations For the Choice of Port Allocation Methods 139 For port allocations on NAT64, several aspects may have to be 140 considered when selecting a suitable method. Here is a list of the 141 potential considerations, which are covered in more detail below. 143 o specific features of port usage in a NAT64 environment; 144 o classification of different port allocation methods; 146 o port allocation to improve connectivity; 148 o port allocation to optimize log volume; 150 o port allocation to enhance security. 152 Both analysis and relevant experimental results are presented in the 153 sub-sections that follow. 155 2.1. Port Consumption on NAT64 157 Thanks to its simplicity and efficiency, NAT64 will likely be 158 deployed widely. In a typical scenario, NAT64 will enable internal 159 IPv6-only hosts to connect to external dual-stack or IPv4 networks. 160 Compared with NAT44, fewer ports per subscriber are consumed on 161 NAT64, because only flows between different address families require 162 ports to be assigned. That is, a NAT44 will be deployed in an 163 IPv4-only environment. Since all traffic will have to traverse the 164 NAT, all flows will need ports. Conversely, NAT64 only requires a 165 port when one end is IPv4-only. Therefore, the more hosts support 166 IPv6, the fewer ports are needed on the NAT64. 168 One of the authors did a test comparison of port consumption on NAT64 169 and NAT44. Top100 websites (referring to Alexa statistics) were 170 assessed to evaluate status of port usage on NAT44 and NAT64 171 respectively. It was observed that the port consumption per session 172 on NAT64 is roughly only half that on NAT44. 43 percent of top100 173 websites have AAAA records, therefore the NAT64 didn't have to assign 174 ports to the traffic going to those websites. The results may be 175 different if more services (e.g. game, web-mail, etc) are considered. 176 But it is apparent that the effects of port saving on NAT64 will be 177 amplified by increasing native IPv6 support. 179 Apart from the above observation, port allocation can be tuned 180 according to the phase of IPv6 migration. The use of NAT64 will 181 advance IPv6 deployment, because it provides everyone with incentives 182 to use IPv6, and eventually the result is an end-to-end IPv6-only 183 network with no need for port allocations. As more content providers 184 and services become available over IPv6, the utilization of NAT64 185 goes down since fewer destinations require translation progressing. 186 Thus as IPv6 migration proceeds, it will be possible to relax the 187 multiplexing ratio of IPv4 address sharing. 189 2.2. Classification of Port Allocation Models 191 This section lists several models to allocate the port information in 192 NAT64 equipment. It also describes example cases for each allocation 193 model. 195 2.2.1. Stateful vs. Stateless 197 o Stateful 199 The stateful NAT can be implemented either by static address 200 translation or dynamic address translation. 202 In the case of static address assignment, a one-to-one address 203 mapping for hosts between a IPv6 network address and an IPv4 204 network address is pre-configured on the NAT operation. This case 205 normally occurs when a server is deployed in a IPv6 domain. The 206 static configuration ensures stable inbound connectivity. 208 Dynamic address assignment would periodically free the binding so 209 that the global address could be recycled for later use. This 210 increases the efficiency of usage of IPv4 addresses. 212 o Stateless 214 Stateless NAT is performed in compliance with [RFC6145]. The 215 public IPv4 address is required to be embedded in the IPv6 216 address. Thus the NAT64 can directly extract the address and has 217 no need to record mapping states. 219 A promising usage of stateless NAT may appear in the data centre 220 environment where IPv6 server pools receive inbound connections from 221 IPv4 users externally [I-D.anderson-siit-dc]. NAT usage in other 222 cases may be controversial. First off, the static one-to-one mapping 223 does not address the issue of IPv4 depletion. Secondly, it 224 introduces a dependency between IPv4 and IPv6 addressing. That 225 creates new limitations since a change of IPv4 address will cause 226 renumbering of IPv6 addresses. 228 2.2.2. Dynamic vs. Static 230 Port assignment can be dynamic (ports allocated on demand) or static 231 (ports allocated as part of the configuration process). 233 o Dynamic assignment 235 NAT64 normally uses dynamic assignment, since this achieves higher 236 port utilization. Port allocations can be made with per-session 237 or per-customer granularity. Per-session assignment is configured 238 on the NAT64 by default since it maximizes port utilization. 239 However, this can result in a heavy log volume that may have to be 240 recorded for lawful interception systems. To mitigate that 241 concern, the NAT64 may dynamically allocate a port range for each 242 connected subscriber. This will significantly reduce log volume. 244 A proper port-range configuration may have to take into account 245 two considerations: 247 A. The number of session initiations for each subscriber. A 248 subscriber normally uses multiple applications simultaneously, 249 e.g. map, online video or game. The number of concurrent 250 sessions is essential to determine the number of ports the 251 subscriber needs. It has been learned from subscribers' 252 behaviors that the average number of sessions consumed by one 253 user's device is around 200 to 300 ports. Several devices may 254 appear behind a CPE. Administrators may configure a range 255 with 1000 ports to each CPE in fixed networks. 257 B. Impacts on NAT64 capacity. Preassigned port ranges occupy 258 memory even when there are unused ports. Therefore, the 259 operator should be cautious about the impact of port-range 260 reservation on the capacity for attempted concurrent sessions, 261 especially in the case of a centralized NAT64 CGN serving 262 numerous subscribers. 264 o Static assignment 266 Static assignment makes port reservations in bulk for each 267 internal address before subscriber connection. The assigned ports 268 can be in either a contiguous or non-contiguous port range for the 269 sake of attack defense. Log recording may not be necessary due to 270 the stable mapping relations. Considerations of the interaction 271 between port-range allocation and capacity impact are also 272 applicable in the case of static assignment. Section 4 describes 273 a deterministic algorithm to assign a port range for an internal 274 IP address pool in a sequence. 276 2.2.3. Centralized vs. Distributed 278 There is an increasing need to connect NAT64 with downstream 279 NAT46-capable devices to support IPv4 users/applications on an 280 IPv6-only path. Several solutions have been proposed in this area, 281 e.g., 464xlat [RFC6877], MAP-T [I-D.ietf-softwire-map-t] and 4rd 282 [I-D.ietf-softwire-4rd]. Port allocation can be categorized as a 283 centralized assignment on NAT64 or as a port delegation distributed 284 to downstream devices (e.g, Customer Edge connected with NAT64). 286 o Centralized Assignment 288 A centralized method makes port assignments once IP flows come to 289 the NAT64. The allocation policy is enforced on a centralized 290 point. Either a dynamic or static port assignment is made for 291 received sessions. 293 o Distributed Assignment 295 NAT64 can also delegate the pre-allocated port range to customer 296 edge devices. That can be achieved through additional out-of-band 297 provisioning signals (e.g., [I-D.ietf-pcp-port-set], 298 [I-D.ietf-softwire-map-dhcp]). The distributed model normally is 299 performed A+P style for static port assignment. The NAT64 should 300 also hold the corresponding mapping in order to validate port 301 usage in the outgoing direction and route inbound packets. 302 Delegated port ranges shift NAT64 port computations/states into 303 downstream devices. The detailed benefits of this approach are 304 documented in [I-D.ietf-softwire-stateless-4v6-motivation]. 306 2.3. Port Allocation Solutions 308 2.3.1. Older Transition Technologies 310 In older work, stateful NAT64 [RFC6146] uses bindings between IPv4 311 and IPv6 addresses that may be either static or dynamic. [RFC6146] 312 describes a process where the dynamic binding is created by an 313 outgoing packet, but it may also be created by other means such as a 314 Port Control Protocol request (see Section 2.3.3). Stepping outside 315 the boundaries of NAT64 for the moment, DS-Lite [RFC6333] refers to 316 the cautions in [RFC6269] but does not specify any port allocation 317 method. Both technologies assume a centralized model. 319 The specifications for both transition methods thus allow 320 implementations to use the proposals made in Section 3 and Section 4. 322 2.3.2. Current Work On Stateless Transition Technologies 324 The port allocation solutions that are being specified at the time of 325 writing of this document are all variations on the static distributed 326 model, to minimize the amount of state that has to be held in the 327 network. The proposals made in Section 3 and Section 4 do not apply 328 to the current work in progress because that work has gone in another 329 direction. That work includes: 331 o Light-weight 4over6 (LW4o6 [I_D.ietf-softwire-lw4over6]), which 332 requires the CPE to be configured explicitly with the shared IPv4 333 address and port set it will use on the WAN side of its NAT44 334 function. The border router is configured with the same 335 information, reducing the state it must hold from per-session to 336 per-subscriber amounts. 338 o Mapping of Address and Port with Encapsulation (MAP-E 339 [I-D.ietf-softwire-map]) and the experimental specifications 340 Mapping of Address and Port with Translation (MAP-T 341 [I-D.ietf-softwire-map-t]) and 4rd [I-D.ietf-softwire-4rd], 342 already mentioned. These rely on an algorithmic embedding of WAN- 343 side IPv4 address and assigned port set within the IPv6 prefix 344 assigned to each CPE. Both the CPE and the border router must be 345 configured with this information. However, the algorithm is 346 designed to aggregate routing information such that the amount of 347 state carried by the border router is of a lower order of 348 magnitude than even the per-subscriber level. 350 MAP-E also supports a 1-1 mapping mode, where the IPv4 and IPv6 351 addresses assigned to a CPE are independent. This can be helpful in 352 transition, but, as with LW4o6, raises the amount of state in the 353 network back to the per-subscriber level. 355 For a packet destined to a host outside the MAP domain from which the 356 packet originated: MAP-E and 4rd treat the packet as an IPv4 over 357 IPv6 tunnel via the border router. 359 MAP-T uses stateless mapping in the sense of Section 2.2.1 by 360 embedding the destination IPv4 address within the IPv6 address of the 361 packet sent to the border router. 363 2.3.3. Port Control Protocol (PCP) 365 The Port Control Protocol (PCP, [RFC6887]) can be used to reserve a 366 single port or a port set [I-D.ietf-pcp-port-set] for applications. 367 It requires that the NAT be collocated with a PCP server function. 368 PCP provides an out-of-band signalling mechanism for coordinating 369 dynamic allocation of ports between hosts and the border router. 371 2.4. Specific Considerations 373 2.4.1. Log Volume Optimization 375 [RFC6269] has provided a thoughtful analysis on the issues of IP 376 sharing. It points out that IP sharing may impact law enforcement 377 since source address information will be lost during the translation. 378 Network administrators have to log the mapping status for each 379 connection in order to identify a specific user associated with an IP 380 address in a particular time slot. The storage of log information 381 may post a challenge to operators, since it requires additional 382 resources and data inspection processes to identify users. For 383 concrete details of what should be logged, see Section 3.1 of 384 [I-D.ietf-behave-syslog-nat-logging]. The actual logging may use 385 either IPFIX [RFC7011] or Syslog [RFC5424] depending on the 386 operator's requirements. 388 It is desirable to reduce the volume of the logged information. 389 Referring to the classification of port allocation methods given 390 above, dynamic assignments can be managed on either a per-session or 391 per-customer granularity. The coarser granularity will lead to lower 392 log volume storage. A test was made by recording the log information 393 from 200,000 subscribers in the Chinese network for 60 days. The 394 volume of recorded information reached up to 42.5 terabytes with per- 395 session logging in the raw format. The volume could be reduced to 396 10.6 terabytes with gzip format. Compared with that, it only 397 occupied 40.6 gigabytes, three orders of magnitude smaller volume, 398 with per-customer logging in the raw format. With static allocation, 399 of course, no logs at all are required. 401 On the other hand, the lower logging volumes are associated with 402 lower efficiency of port utilization. A port allocation based on 403 per-customer granularity has to retain vacant ports in order to avoid 404 traffic overflow. The efficiency can be evaluated by port 405 utilization rate, and will be even lower if the static port 406 allocation method is used. Inactive users may also impact the 407 efficiency. 409 Table 1 summarizes the test results using Syslog. The ports were 410 pre-allocated to customers regardless of online or offline status. 412 +--------------------+--------------+----------------+--------------+ 413 | Port Allocation | Log | Estimated Log | Port | 414 | Method | Granularity | Volume | Utilization | 415 +--------------------+--------------+----------------+--------------+ 416 | Dynamic NAPT | Per-session | 42.5 terabytes | 100% | 417 | Dynamic port-range | Per-customer | 40.6 Gigabytes | 75% | 418 | Deterministic NAT, | None | None | (60% * 75%) | 419 | MAP-T, 4rd | | | = 45% | 420 +--------------------+--------------+----------------+--------------+ 422 Table 1: Estimated Log Volumes For 200,000 Users Over 60 Days 424 Note: 75% is the estimated port utilization ratio per active 425 subscriber. 60% is the estimated ratio of active subscribers to the 426 total number of subscribers. 428 The data shown in Table 1 roughly demonstrates the tradeoff between 429 port utilization and log volume reduction. Administrators may 430 consider the following factors to determine their own solution: 432 o average connectivity per customer per day; 434 o peak connectivity per day; 436 o the number of public IPv4 addresses available to the NAT64; 438 o application demands for specific ports; 440 o processing capabilities of the NAT64; 442 o tolerable log volume. 444 2.4.2. Connectivity State Optimization 446 It has been observed that port consumption is significantly increased 447 once subscribers land on a web page for video on demand, an online 448 game, or map services. In those cases, multiple TCP connections may 449 be initiated to optimize the performance of data transmissions for 450 video download and message exchange. Given the video traffic growth 451 trend, this likely presents a challenge for network operators who 452 need to optimize connectivity states and avoid port depletion. Those 453 optimizations may even affect the method of port-range allocation, 454 because a subscriber is only allowed to use a pre-configured port 455 resource. 457 Two optimizations may be considered: 459 o Reducing the TIME-WAIT state. The user's behavior normally 460 correlates with system performance. It is rather common that 461 users change video channels often. Investigations have shown that 462 60% of videos are watched for less than 20% of their duration. 463 The user's access patterns may leave a number of the TIME-WAIT 464 states. Therefore, acceleration of TIME-WAIT state transitions 465 could increase the efficiency of port utilization. [RFC6191] 466 defines a mechanism for reducing TIME-WAIT state by proposing TCP 467 timestamps and sequence numbers. 469 [I-D.penno-behave-rfc4787-5382-5508-bis] recommended applying 470 [RFC6191] and PAWS (Protect Against Wrapped Sequence numbers, 471 described in [RFC1323]) to NAT. This may also be a way to improve 472 port utilization. 474 o Another possibility is to use Address-Dependent Mapping or Address 475 and Port-Dependent Mapping [RFC4787] to increase port utilization. 477 This feature has already been implemented on a vendor-specific 478 basis. However, it should be noted that REQ-7 and REQ-12 in 479 [RFC6888] may reduce the incentive to use anything but the 480 Address-Independent Mapping behaviour recommended by [RFC4787]. 482 2.4.3. Port Randomization 484 Port randomization is a feature to enhance the defense against 485 hijacking of flows. [RFC6056] specifies that: 487 "A NAPT that does not implement port preservation ([RFC4787], 488 [RFC5382]) should obfuscate selection of the ephemeral port of a 489 packet when it is changed during translation of that packet." 491 A NAPT based on per-session alllocation normally follows this 492 recommendation. However, a simple algorithm for port assignment is 493 generally desirable for a deterministic NAT even if it increases 494 hijack vulnerability. 496 See Section 5 for a fuller discussion of port randomization. 498 3. Considerations For the Dynamic Assignment of Port-Ranges 500 3.1. Motivation 502 During the IPv6 transition period, large-scale NAT devices may be 503 introduced, e.g. DS-Lite AFTR, NAT64. When a NAT device needs to set 504 up a new connection for a given internal address behind the NAT, it 505 needs to create a new mapping entry for the new connection, which 506 will contain source IP address, source port or ICMP identifier, 507 converted source IP address, converted source port, protocol (TCP/ 508 UDP), etc. 510 For various reasons it is necessary to log these mappings. Some high 511 performance NAT devices may need to create a large amount of new 512 sessions per second. As seen in Section 2.4.1, if the logs are 513 generated for each mapping entry, the log traffic could reach tens of 514 megabytes per second or more, which would be a problem for log 515 generation, transmission and storage. (The per-session volumes in 516 Table 1 amount to 42 bytes per served subscriber per second. The 517 volumes reported in Section 2.4.2 for US users are even higher, 518 around 58 bytes per second per subscriber served.) 520 [RFC6888], REQ-13, REQ-14, and REQ-15 deal explicitly with port 521 allocation schemes and logging. However, it is recognized that these 522 are conflicting requirements, requiring a tradeoff between the 523 efficiency with which ports are used and the rate of generation of 524 log records. 526 Allocating a range of N ports at once reduces the log volume by a 527 factor of N, while also reducing port utilization by a factor which 528 varies with the address sharing ratio and other configuration 529 parameters. This provides a clear motivation to use dynamic 530 allocation of port-ranges rather than individual ports when it is 531 possible to do so while maintaining a satisfactory level of port 532 utilization (and by implication, shared global IPv4 address 533 utilization). 535 Dynamic allocation of port ranges may be used either as the sole 536 strategy for port allocation on the NAPT, or as a supplement to an 537 initial static allocation. 539 3.2. Implementation Issues -- Port Randomization and Port-Range 540 Deallocation 542 Here is how dynamic allocation of port-ranges would work in greater 543 detail. When the user sends out the first packet, a port resource 544 pool is allocated for the user, e.g., assigning ports 2001~2300 of a 545 public IP address to the user's resource pool. Only one log should 546 be generated for this port block. When the NAT needs to set up a new 547 mapping entry for the user, it can use a port in the user's resource 548 pool and the corresponding public IP address. If the user needs more 549 port resources, the NAT can allocate another port block, e.g., ports 550 3501~3800, to the user's resource pool. Again, just one log needs to 551 be generated for this port block. 553 [I-D.bajko-pripaddrassign] takes this idea further by allocating non- 554 contiguous sets of ports using a pseudorandom function. Scattering 555 the allocated ports in this way provides a modest barrier to port 556 guessing attacks. The use of randomization is discussed further in 557 Section 5. 559 Suppose now that a given internal address has been assigned more than 560 one block of ports. The individual sessions using ports within a 561 port block will start and end at different times. If no ports in 562 some port block are used for some configurable time, the NAT can 563 remove the port block from the resource pool allocated to a given 564 internal address, and make it available for other users. In theory, 565 it is unnecessary to log deallocations of blocks of ports, because 566 the ports in deallocated blocks will not be used again until the 567 blocks are reallocated. However, the deallocation may be logged when 568 it occurs to add robustness to troubleshooting or other procedures. 570 The deallocation procedure presents a number of difficulties in 571 practice. The first problem is the choice of timeout value for the 572 block. If idle timers are applied for the individual mappings 573 (sessions) within the block, and these conform to the recommendations 574 for NAT behaviour for the protocol concerned, then the additional 575 time that might be configured as a guard for the block as a whole 576 need not be more than a few minutes. The block timer in this case 577 serves only as a slightly more conservative extension of the 578 individual session idle timers. If, instead, a single idle timer is 579 used for the whole block, it must itself conform to the 580 recommendations for the protocol with which that block of ports is 581 associated. For example, REQ-5 of [RFC5382] requires an idle timer 582 expiry duration of at least 2 hours and 4 minutes for TCP. The 583 suggestions made in Section 2.4.2 may be considered for reducing this 584 time. 586 The next issue with port block deallocation is the conflict between 587 the desire to randomize port allocation and the desire to make unused 588 resources available to other internal addresses. As mentioned above, 589 ideally port selection will take place over the entire set of blocks 590 allocated to the internal address. However, taken to its fullest 591 extent, such a policy will minimize the probability that all ports in 592 any given block are idle long enough for it to be released. 594 As an alternative, it is suggested that when choosing which block to 595 select a port from, the NAT should omit from its range of choice the 596 block that has been idle the longest, unless no ports are available 597 in any of the other blocks. The expression "block that has been idle 598 the longest" designates the block in which the time since the last 599 packet was observed in any of its sessions, in either direction, is 600 earlier than the corresponding time in any of the other blocks 601 assigned to that internal address. As [RFC6269] points out, port 602 randomization is just one security measure of several, and the loss 603 of randomness incurred by the suggested procedure is justified by the 604 increased utilization of port resources it allows. 606 3.3. Issues Of Traceability 608 Section 11 of [RFC6269] provides a good discussion of the 609 traceability issue. Complete traceability given the NAT logging 610 practices proposed in this draft requires that the remote destination 611 record the source port of a request along with the source address 612 (and presumably protocol, if not implicit). In addition, the logs at 613 each end must be timestamped, and the clocks must be synchronized 614 within a certain degree of accuracy. Here is one reason for the 615 guard timing on block release, to increase the tolerable level of 616 clock skew between the two ends. 618 The ability to configure various server applications to record source 619 ports has been investigated, with the following results: 621 o Source port recording can be configured in Apache, Postfix, 622 sendmail and sshd. Please refer to the appendix for a 623 configuration guide. 625 o Source port recording is not supported by IIS, Cyrus IMAP and UW 626 IMAP. But it should not be too difficult to get Cyrus IMAP and UW 627 IMAP to support it by modifying the source code. 629 Where source port logging can be enabled, this memo strongly urges 630 the operators to do so. Similarly, intrusion detection systems 631 should capture source port as well as source address of suspect 632 packets. 634 In some cases [RFC6269], a server may not record the source port of a 635 connection. To allow traceability, the NAT device needs to record 636 the destination IP address of a connection. As [RFC6269] points out, 637 this will provide an incomplete solution to the issue of traceability 638 because multiple users of the same shared public IP address may 639 access the service at the same time. From the point of view of this 640 draft, in such situations the game is lost, so to speak, and port 641 allocation at the NAT might as well be completely dynamic. 643 The final possibility to consider is where the NAT does not do per- 644 session logging even given the possibility that the remote end is 645 failing to capture source ports. In that case, the port allocation 646 strategy proposed in this section can be used. The impact on 647 traceability is that analysis of the logs would yield only the list 648 of all internal addresses mapped to a given public address during the 649 period of time concerned. This has an impact on privacy as well as 650 traceability, depending on the follow-up actions taken. 652 3.4. Other Considerations 654 [RFC6269] notes several issues introduced by the use of dynamic as 655 opposed to static port assignment. For example, Section 12.2 of that 656 document notes the effect on authentication procedures. These issues 657 must be resolved, but are not specific to the dynamic port-range 658 allocation strategy. 660 4. Deterministic Port Allocation 662 4.1. Motivation 664 CGN connection logging satisfies the need to identify attackers and 665 respond to abuse/public safety requests, but it imposes significant 666 operational challenges to operators. In lab testing, CGN log 667 messages were observed to be approximately 150 bytes long for NAT444 668 [I-D.shirasaki-nat444], and 175 bytes for DS-Lite [RFC6333] 669 (individual log messages vary somewhat in size). Although the 670 authors are not aware of definitive studies of connection rates per 671 subscriber, reports from several operators in the US set the average 672 number of connections per household at approximately 33,000 673 connections per day. If each connection is individually logged, this 674 translates to a data volume of approximately 5 MB per subscriber per 675 day, or about 150 MB per subscriber per month; however, specific data 676 volumes may vary across different operators based on myriad factors. 677 Based on available data, a 1-million subscriber service provider will 678 generate approximately 150 terabytes of log data per month, or 1.8 679 petabytes per year. 681 The volume of log data poses a problem for both operators and the 682 public safety community. On the operator side, it requires a 683 significant infrastructure investment by operators implementing CGN. 684 It also requires updated operational practices to maintain the 685 logging infrastructure, and requires approximately 23 Mbps of 686 bandwidth between the CGN devices and the logging infrastructure per 687 50,000 users. On the public safety side, it increases the time 688 required for an operator to search the logs in response to an abuse 689 report, and could delay investigations. Accordingly, an 690 international group of operators and public safety officials 691 approached some of the authors and contributors to this document to 692 identify a way to reduce this impact while improving abuse response. 694 As noted in Section 3.1, the volume of CGN logging can be reduced by 695 assigning port ranges instead of individual ports. Using this 696 method, only the assignment of a new port range is logged. This may 697 massively reduce logging volume. The log reduction may vary 698 depending on the length of the assigned port range, whether the port 699 range is static or dynamic, etc. This has been acknowledged in 700 [RFC6269] and Section 5.6.10 of [I-D.ietf-behave-ipfix-nat-logging]. 701 Per [RFC6269]: 703 "Address sharing solutions may mitigate these issues to some 704 extent by pre-allocating groups of ports. Then only the 705 allocation of the group needs to be recorded, and not the creation 706 of every session binding within that group. There are trade-offs 707 to be made between the sizes of these port groups, the ratio of 708 public addresses to subscribers, whether or not these groups 709 timeout, and the impact on logging requirements and port 710 randomization security ([RFC6056])." 712 However, the existing solution still poses an impact on operators and 713 public safety officials for logging and searching. Instead, CGNs 714 could be designed and/or configured to deterministically map internal 715 addresses to {external address + port range} in such a way as to be 716 able to algorithmically calculate the mapping. Only inputs and 717 configuration of the algorithm need to be logged. This approach 718 reduces both logging volume and subscriber identification times. In 719 some cases, when full deterministic allocation is used, this approach 720 can eliminate the need for translation logging. 722 This section describes a method for such CGN address mapping, 723 combined with block port reservations, that significantly reduces the 724 burden on operators while offering the ability to map a subscriber's 725 inside IP address with an outside address and external port number 726 observed on the Internet. 728 The activation of the proposed port range allocation scheme is 729 compliant with BEHAVE requirements such as the support of APP. [What 730 is APP? Reference for the complied-with requirements? Or can this 731 para be removed?] 733 4.2. Deterministic Port Ranges 735 While a subscriber uses thousands of connections per day, most 736 subscribers use far fewer resources at any given time. 738 Appendix B of [RFC6269] introduces the term "address space 739 multiplicative factor" to denote the number of subscribers sharing 740 the same public IPv4 address, and goes on to qualify how this value 741 should be calculated. When the address space multiplicative factor 742 is low (e.g., the ratio of the number of subscribers to the number of 743 public IPv4 addresses allocated to a CGN is closer to 10:1 than 744 1000:1), each subscriber could have access to thousands of TCP/UDP 745 ports at any given time. Thus, as an alternative to logging each 746 connection, CGNs can deterministically map customer private addresses 747 (received on the customer-facing interface of the CGN, a.k.a., 748 internal side) to public addresses extended with port ranges (used on 749 the Internet-facing interface of the CGN, a.k.a., external side). 751 The mapping algorithm allows an operator to identify a subscriber 752 internal IP address when provided the public side IP and port number 753 without having to examine the CGN translation logs, and avoids having 754 to transport and store massive amounts of session data from the CGN 755 and then process it to identify a subscriber. It can be classified 756 as a static centralized port allocation strategy. 758 The algorithmic mapping can be expressed as: 760 (External IP Address, Port Range) = function 1 (Internal IP 761 Address) 763 Internal IP Address = function 2 (External IP Address, Port 764 Number) 766 Deterministic Port Range allocation requires configuration of the 767 following variables: 769 o The set of inside IPv4/IPv6 addresses ; 771 o the set of outside IPv4 addresses ; 773 o the address space multiplicative factor (F), i.e., ratio of number 774 of inside IP addresses to outside IP addresses; 776 o dynamic address pool factor (D), to be added to the compression 777 ratio in order to create an overflow address pool; 779 o maximum ports per user (M); 781 o address assignment algorithm (A) (see below); and 783 o number of reserved TCP/UDP ports (R). 785 Note: The inside address set will consist of IPv4 addresses in 786 NAT444 operation (NAT444 [I-D.shirasaki-nat444]) and of IPv6 787 addresses in DS-Lite [RFC6333] operation. 789 A subscriber may be identified by an internal IPv4 address (e.g., 790 NAT44) or an IPv6 prefix (e.g., DS-Lite or NAT64). For a fuller 791 discussion of subscriber identification, see Section 2.4 of 792 [I-D.ietf-behave-syslog-nat-logging]. 794 The algorithm is not designed to retrieve an internal host among 795 those sharing the same internal IP address (e.g., in a DS-Lite 796 context, only an IPv6 address/prefix can be retrieved using the 797 algorithm while the internal IPv4 address used for the encapsulated 798 IPv4 datagram is lost). 800 Several address assignment algorithms are possible. Using predefined 801 algorithms, such as those that follow, simplifies the process of 802 reversing the algorithm when needed. However, the CGN may support 803 additional algorithms, and may not support all algorithms described 804 below. Subscribers could be restricted to ports from a single IPv4 805 address, or could be allocated ports across all addresses in a pool, 806 for example. The following algorithms and corresponding values of A 807 are suggested as a starting set: 809 A = 0: Sequential (e.g. the first block goes to address 1, the 810 second block to address 2, etc.) 812 A = 1: Staggered (e.g. for every n between 0 and ((65536-R)/(F+D))-1 813 , address 1 receives ports n*F+R, address 2 receives ports 814 (1+n)*F+R, etc.) 816 A = 2: Round robin (e.g. the subscriber receives the same port 817 number across a pool of external IP addresses. If the subscriber 818 is to be assigned more ports than there are in the external IP 819 pool, the subscriber receives the next highest port across the IP 820 pool, and so on. Thus, if there are 10 IP addresses in a pool and 821 a subscriber is assigned 1000 ports, the subscriber would receive 822 a range such as ports 2000-2099 across all 10 external IP 823 addresses). 825 A = 3: Interlaced horizontally (e.g. each address receives every Cth 826 port spread across a pool of external IP addresses). 828 A = 4: Cryptographically random port assignment (Section 2.2 of 829 [RFC6431]). If this algorithm is used, the Service Provider needs 830 to retain the keying material and specific cryptographic function 831 to support reversibility. 833 The assigned range of ports can also be used when translating ICMP 834 requests (when re-writing the Identifier field). 836 The CGN then reserves ports as follows: 838 1. The CGN removes reserved ports (R) from the port candidate list 839 (e.g., 0-1023 for TCP and UDP). At a minimum, it is likely that 840 the operator will prefer the CGN to remove system ports [RFC6335] 841 from the port candidate list reserved for deterministic 842 assignment. 844 2. The CGN calculates the total address space multiplicative factor 845 (F+D), and allocates 1/(F+D) of the available ports to each 846 internal IP address. Specific port allocation is determined by 847 the algorithm (A) configured on the CGN. Any remaining ports are 848 allocated to the dynamic pool. 850 Note: Setting D to 0 disables the dynamic pool. This option 851 eliminates the need for per-subscriber logging at the expense of 852 limiting the number of concurrent connections that 'power users' 853 can initiate. 855 3. When a subscriber initiates a connection, the CGN creates a 856 translation mapping between the subscriber's inside local IP 857 address/port and the CGN outside global IP address/port. The CGN 858 uses one of the ports allocated in step 2 for the translation as 859 long as such ports are available. The CGN allocates ports 860 randomly within the port range assigned by the deterministic 861 algorithm. This is to increase subscriber privacy. The CGN must 862 also use the preallocated port range from step 2 for Port Control 863 Protocol (PCP, [RFC6887]) reservations as long as such ports are 864 available. While the CGN maintains its mapping table, it need 865 not generate a log entry for translation mappings created in this 866 step. 868 4. If D>0, the CGN will have a pool of ports left for dynamic 869 assignment. If a subscriber uses more than the range of ports 870 allocated in step 2 (but fewer than the configured maximum ports 871 M), the CGN assigns a block of ports from the dynamic assignment 872 range for such a connection or for PCP reservations. The CGN 873 logs dynamically assigned port blocks to facilitate subscriber- 874 to-address mapping. The CGN should manage dynamic ports as 875 described in Section 3. 877 5. Configuration of reserved ports (e.g., system ports) is left to 878 the operator. 880 Thus, the CGN will maintain translation mapping information for all 881 connections within its internal translation tables; however, it only 882 needs to externally log translations for dynamically-assigned ports. 884 4.2.1. IPv4 Port Utilization Efficiency 886 For Service Providers requiring an aggressive address space 887 multiplicative factor, the use of the algorithmic mapping may impact 888 the efficiency of the address sharing. A dynamic port range 889 allocation assignment is more suitable in those cases. 891 4.2.2. Planning and Dimensioning 893 Unlike dynamic approaches, the use of the algorithmic mapping 894 requires more effort from operational teams to tweak the algorithm 895 (e.g., size of the port range, address space multiplicative factor, 896 etc.). Operators should configure dedicated alarms triggered by port 897 utilization threshold crossings so that the configuration can be 898 refined. 900 The use of algorithmic mapping also affects geolocation. Changes to 901 the inside and outside address ranges (e.g. due to growth, address 902 allocation planning, etc.) will require external geolocation 903 providers to recalibrate their mappings. 905 4.2.3. Deterministic CGN Example 907 To illustrate the use of deterministic NAT, let us consider a simple 908 example. The operator configures an inside address range (I) of 909 100.64.0.0/28 [RFC6598] and outside address (O) of 203.0.113.1. The 910 dynamic address pool factor (D) is set to '2'. Thus, the total 911 compression ratio is 1:(14+2) = 1:16. Only the system ports (e.g. 912 ports < 1024) are reserved (R). This configuration causes the CGN to 913 preallocate (65536-1024)/16 = 4032 TCP and 4032 UDP ports per inside 914 IPv4 address. For the purposes of this example, let's assume that 915 they are allocated sequentially, where 100.64.0.1 maps to 203.0.113.1 916 ports 1024-5055, 100.64.0.2 maps to 203.0.113.1 ports 5056-9087, etc. 917 The dynamic port range thus contains ports 57472-65535 (port 918 allocation illustrated in Table 2). Finally, the maximum ports/ 919 subscriber is set to 5040. 921 +-----------------------+-------------------------+ 922 | Inside Address / Pool | Outside Address & Port | 923 +-----------------------+-------------------------+ 924 | Reserved | 203.0.113.1:0-1023 | 925 | 100.64.0.1 | 203.0.113.1:1024-5055 | 926 | 100.64.0.2 | 203.0.113.1:5056-9087 | 927 | 100.64.0.3 | 203.0.113.1:9088-13119 | 928 | 100.64.0.4 | 203.0.113.1:13120-17151 | 929 | 100.64.0.5 | 203.0.113.1:17152-21183 | 930 | 100.64.0.6 | 203.0.113.1:21184-25215 | 931 | 100.64.0.7 | 203.0.113.1:25216-29247 | 932 | 100.64.0.8 | 203.0.113.1:29248-33279 | 933 | 100.64.0.9 | 203.0.113.1:33280-37311 | 934 | 100.64.0.10 | 203.0.113.1:37312-41343 | 935 | 100.64.0.11 | 203.0.113.1:41344-45375 | 936 | 100.64.0.12 | 203.0.113.1:45376-49407 | 937 | 100.64.0.13 | 203.0.113.1:49408-53439 | 938 | 100.64.0.14 | 203.0.113.1:53440-57471 | 939 | Dynamic | 203.0.113.1:57472-65535 | 940 +-----------------------+-------------------------+ 942 Table 2: Port Allocation For Deterministic NAT Example 944 When subscriber 1 using 100.64.0.1 initiates a low volume of 945 connections (e.g. < 4032 concurrent connections), the CGN maps the 946 outgoing source address/port to the preallocated range. These 947 translation mappings are not logged. 949 Subscriber 2 concurrently uses more than the allocated 4032 ports 950 (e.g. for peer-to-peer, mapping, video streaming, or other 951 connection- intensive traffic types), the CGN allocates up to an 952 additional 1008 ports using bulk port reservations. In this example, 953 subscriber 2 uses outside ports 5056-9087, and then 100-port blocks 954 between 58000- 58999. Connections using ports 5056-9087 are not 955 logged, while 10 log entries are created for ports 58000-58099, 956 58100-58199, 58200-58299, ..., 58900-58999. 958 In order to identify a subscriber behind a CGN (regardless of port 959 allocation method), public safety agencies need to collect source 960 address and port information from content provider log files. Thus, 961 content providers are advised to log source address, source port, and 962 timestamp for all log entries, per [RFC6302]. If a public safety 963 agency collects such information from a content provider and reports 964 abuse from 203.0.113.1, port 2001, the operator can reverse the 965 mapping algorithm to determine that the internal IP address 966 subscriber 1 has been assigned generated the traffic without 967 consulting CGN logs (by correlating the internal IP address with DHCP 968 /PPP lease connection records). If a second abuse report comes in 969 for 203.0.113.1, port 58204, the operator will determine that port 970 correlate with connection records, and determine that subscriber 2 971 generated the traffic (assuming that the public safety timestamp 972 matches the operator timestamp. As noted in [RFC6269], accurate 973 time-keeping (e.g., use of NTP or Simple NTP) is vital). 975 In this example, there are no log entries for the majority of 976 subscribers, who only use pre-allocated ports. Only minimal logging 977 would be needed for those few subscribers who exceed their pre- 978 allocated ports and obtain extra bulk port assignments from the 979 dynamic pool. Logging data for those users will include inside 980 address, outside address, outside port range, and timestamp. See 981 [I-D.ietf-behave-syslog-nat-logging] Section 3.1.4 for a detailed 982 specification of the information required. 984 4.2.4. Additional Management Considerations 986 The CGN should provide a method for administrators to test the 987 mapping function in both directions, i.e., enter an External IP 988 Address + Port Number and receive the corresponding Internal IP 989 Address and vice versa. 991 In order to be able to identify a subscriber based on observed 992 external IPv4 address, port, and timestamp, an operator needs to know 993 how the CGN was configured with regards to internal and external IP 994 addresses, dynamic address pool factor, maximum ports per user, and 995 reserved port range at any given time. Therefore, the operator needs 996 to keep a record of the current configuration and changes to it. The 997 record itself may be generated by the CGN, or may be retrieved from a 998 router configuration management system. For auditing purposes, such 999 records should be generated on a daily basis and checked for 1000 unauthorized or unintended changes. 1002 4.3. Failover Considerations 1004 Due to the deterministic nature of algorithmically-assigned 1005 translations, no additional logging is required during failover 1006 conditions provided that inside address ranges are unique within a 1007 given failover domain. Even when directed to a different CGN server, 1008 translations within the deterministic port range on either the 1009 primary or secondary server can be algorithmically reversed, provided 1010 the algorithm is known. Thus, if 100.64.0.1 port 3456 maps to 1011 203.0.113.1 port 1000 on CGN 1 and 198.51.100.1 port 1000 on Failover 1012 CGN 2, an operator can identify the subscriber based on outside 1013 source address and port information. 1015 Similarly, assignments made from the dynamic overflow pool need to be 1016 logged as described above, whether translations are performed on the 1017 primary or failover CGN. 1019 4.4. Impact On IPv6 Transition 1021 The solution described in this section is applicable to Carrier Grade 1022 NAT transition technologies (e.g. NAT444, DS-Lite, and NAT64). 1023 Native IPv6 will offer subscribers a better experience than CGN. 1024 However, many CPE devices only support IPv4. Likewise, as of July 1025 2012, only approximately 4% of the top 1 million websites were 1026 available using IPv6. Accordingly, deterministic CGN should in no 1027 way be understood as making CGN a replacement for IPv6 service. The 1028 authors encourage [RFC6540] device manufacturers to consider and 1029 include IPv6 support. In the interim, however, CGN has already been 1030 deployed in some operator networks. Deterministic CGN will provide 1031 operators with the ability to quickly respond to public safety 1032 requests without requiring excessive infrastructure, operations, and 1033 bandwidth to support per-connection logging. 1035 5. Security Considerations 1037 The discussion which follows addresses an issue that is particularly 1038 relevant to the strategies described in Section 3 and Section 4 of 1039 this document. The security considerations applicable to NAT 1040 operation for various protocols as documented in, for example, 1041 [RFC4787] and [RFC5382] also apply to this proposal. 1043 [RFC6056] summarizes the TCP port-guessing attack, by means of which 1044 an attacker can hijack one end of a TCP connection. One mitigating 1045 measure is to make the source port number used for a TCP connection 1046 less predictable. [RFC6056] provides various algorithms for this 1047 purpose. 1049 As Section 3.1 of that RFC notes: "...provided adequate algorithms 1050 are in use, the larger the range from which ephemeral ports are 1051 selected, the smaller the chances of an attacker are to guess the 1052 selected port number." Conversely, the reduced range sizes proposed 1053 by the present document increase the attacker's chances of guessing 1054 correctly. This result cannot be totally avoided. However, 1055 mitigating measures to improve this situation can be taken both at 1056 port block assignment time and when selecting individual ports from 1057 the blocks that have been allocated to a given user. 1059 At assignment time, one possibility is to assign ports as non- 1060 contiguous sets of values as proposed in [I-D.bajko-pripaddrassign]. 1061 However, this approach creates a lot of complexity for operations, 1062 and the pseudo randomization can create uncertainty when the accuracy 1063 of logs is important to protect someone's life or liberty. 1065 Alternatively, the NAT can assign blocks of contiguous ports. 1066 However, at assignment time the NAT could attempt to randomize its 1067 choice of which of the available idle blocks it would assign to a 1068 given user. This strategy has to be traded off against the 1069 desirability of minimizing the chance of conflict between what 1070 [RFC6056] calls "transport protocol instances" by assigning the most- 1071 idle block, as suggested in Section 3. A compromise policy might be 1072 to assign blocks only if they have been idle for a certain amount of 1073 time whenever possible, and select pseudorandomly between the blocks 1074 available according to this criterion. In this case it is suggested 1075 that the time value used be greater than the guard timing mentioned 1076 in Section 3, and that no block should ever be reassigned until it 1077 has been idle at least for the duration given by the guard timer. 1079 Note that with the possible exception of cryptographically-based port 1080 allocations, attackers could reverse-engineer algorithmically-derived 1081 port allocations to either target a specific subscriber or to spoof 1082 traffic to make it appear to have been generated by a specific 1083 subscriber. However, this is exactly the same level of security that 1084 the subscriber would experience in the absence of CGN. CGN is not 1085 intended to provide additional security by obscurity. 1087 While the block assignment strategy can provide some mitigation of 1088 the port guessing attack, the largest contribution will come from 1089 pseudo-randomization at port selection time. [RFC6056] provides a 1090 number of algoriths for achieving this pseudo-randomization. When 1091 the available ports are contained in blocks which are not in general 1092 consecutive, the algorithms clearly need some adaptation. The task 1093 is complicated by the fact that the number of blocks allocated to the 1094 user may vary over time. Adaptation is left as an exercise for the 1095 implementor. 1097 6. IANA Considerations 1099 This document makes no request of IANA. 1101 7. Contributors 1103 This document is the result of merging three separate Internet 1104 Drafts: the original Chen document (version -03), draft-tsou-behave- 1105 natx4-log-reduction-04, and draft-donley-behave-deterministic-cgn-07. 1106 Aside from the authors listed on the front of the present document, 1107 the following co-authors of the other two original drafts deserve 1108 credit for their contributions: 1110 o Weibo Li (China Telecom) and James Huang (Huawei) for their work 1111 on draft-tsou-behave-natx4-log-reduction, and 1113 o Chris Grundemann (Internet Society), Vikas Sarawat and Karthik 1114 Sundaresan (CableLabs), and Olivier Vautrin (Juniper) for their 1115 work on draft-donley-behave-deterministic-cgn. 1117 8. Acknowledgements 1119 The authors of draft-donley-behave-deterministic-cgn would like to 1120 thank the following people for their suggestions and feedback: Bobby 1121 Flaim, Lee Howard, Wes George, Jean-Francois Tremblay, Mohammed 1122 Boucadair, Alain Durand, David Miles, Andy Anchev, Victor Kuarsingh, 1123 Miguel Cros Cecilia, and Reinaldo Penno. 1125 The authors of draft-tsou-behave-natx4-log-reduction have their own 1126 thanks to give. Mohamed Boucadair reviewed the initial document and 1127 provided useful comments to improve it. Reinaldo Penno, Joel 1128 Jaeggli, and Dan Wing provided comments on the subsequent version 1129 that resulted in major revisions. Serafim Petsis provided 1130 encouragement to publication after a hiatus of two years. 1132 9. References 1134 9.1. Normative References 1136 [RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport- 1137 Protocol Port Randomization", BCP 156, RFC 6056, January 1138 2011. 1140 [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation 1141 Algorithm", RFC 6145, April 2011. 1143 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 1144 NAT64: Network Address and Protocol Translation from IPv6 1145 Clients to IPv4 Servers", RFC 6146, April 2011. 1147 [RFC6269] Ford, M., Boucadair, M., Durand, A., Levis, P., and P. 1148 Roberts, "Issues with IP Address Sharing", RFC 6269, June 1149 2011. 1151 [RFC6888] Perreault, S., Yamagata, I., Miyakawa, S., Nakagawa, A., 1152 and H. Ashida, "Common Requirements for Carrier-Grade NATs 1153 (CGNs)", BCP 127, RFC 6888, April 2013. 1155 9.2. Informative References 1157 [APACHE_LOG_CONFIG] 1158 The Apache Software Foundation, "http://httpd.apache.org/ 1159 docs/2.4/mod/mod_log_config.html", 2013. 1161 [I-D.anderson-siit-dc] 1162 Anderson, T., "Stateless IP/ICMP Translation in IPv6 Data 1163 Centre Environments (expired work in progress)", November 1164 2012. 1166 [I-D.bajko-pripaddrassign] 1167 Bajko, G., Savolainen, T., Boucadair, M., and P. Levis, 1168 "Port Restricted IP Address Assignment (expired Work in 1169 Progress)", March 2012. 1171 [I-D.ietf-behave-ipfix-nat-logging] 1172 Sivakumar, S. and R. Penno, "IPFIX Information Elements 1173 for Logging NAT Events (Work in Progress)", February 2014. 1175 [I-D.ietf-behave-syslog-nat-logging] 1176 Chen, Z., Zhou, C., Tsou, T., and T. Taylor, "Syslog 1177 Format for NAT Logging (Work in Progress)", January 2014. 1179 [I-D.ietf-pcp-port-set] 1180 Sun, Q., Boucadair, M., Sivakumar, S., Zhou, C., Tsou, T., 1181 and S. Perrault, "Port Control Protocol (PCP) Extension 1182 for Port Set Allocation (Work in Progress)", November 1183 2013. 1185 [I-D.ietf-softwire-4rd] 1186 Despres, R., Jiang, S., Penno, R., Lee, Y., Chen, G., and 1187 M. Chen, "IPv4 Residual Deployment via IPv6 - a Stateless 1188 Solution (4rd) (Work in Progress)", October 2013. 1190 [I-D.ietf-softwire-map-dhcp] 1191 Mrugalski, T., Troan, O., Dec, W., Farrer, I., Perrault, 1192 S., Bao, C., Yeh, L., and X. Deng, "DHCPv6 Options for 1193 configuration of Softwire Address and Port Mapped Clients 1194 (Work in Progress)", March 2014. 1196 [I-D.ietf-softwire-map-t] 1197 Li, X., Bao, C., Dec, W., Troan, O., Matsushima, S., and 1198 T. Murakami, "Mapping of Address and Port using 1199 Translation (MAP-T) (Work in progress)", February 2014. 1201 [I-D.ietf-softwire-map] 1202 Troan, O., Dec, W., Li, X., Bao, C., Matsushima, S., 1203 Murakami, T., and T. Taylor, "Mapping of Address and Port 1204 with Encapsulation (MAP) (Work in Progress)", January 1205 2014. 1207 [I-D.ietf-softwire-stateless-4v6-motivation] 1208 Boucadair, M., Matsushima, S., Lee, Y., Bonness, O., 1209 Borges, I., and G. Chen, "Motivations for Carrier-side 1210 Stateless IPv4 over IPv6 Migration Solutions (Work in 1211 Progress)", November 2012. 1213 [I-D.penno-behave-rfc4787-5382-5508-bis] 1214 Penno, R., Perrault, S., Kamiset, S., Boucadair, M., and 1215 K. Naito, "Network Address Translation (NAT) Behavioral 1216 Requirements Updates (expired Work in Progress)", January 1217 2013. 1219 [I-D.shirasaki-nat444] 1220 Yamagata, I., Shirasaki, Y., Nakagawa, A., Yamaguchi, J., 1221 and H. Ashida, "NAT444 (expired Work in Progress)", July 1222 2012. 1224 [I_D.ietf-softwire-lw4over6] 1225 Cui, Y., Sun, Q., Boucadair, M., Tsou, T., Lee, Y., and I. 1226 Farrer, "Lightweight 4over6: An Extension to the DS-Lite 1227 Architecture (Work in Progress)", March 2014. 1229 [POSTFIX_LOG_CONFIG] 1230 "http://www.postfix.org/postconf.5.html", 2013. 1232 [RFC1323] Jacobson, V., Braden, B., and D. Borman, "TCP Extensions 1233 for High Performance", RFC 1323, May 1992. 1235 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 1236 Address Translator (Traditional NAT)", RFC 3022, January 1237 2001. 1239 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 1240 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 1241 RFC 4787, January 2007. 1243 [RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. 1244 Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, 1245 RFC 5382, October 2008. 1247 [RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, March 2009. 1249 [RFC6191] Gont, F., "Reducing the TIME-WAIT State Using TCP 1250 Timestamps", BCP 159, RFC 6191, April 2011. 1252 [RFC6269.e46ua] 1253 Ford, M., Boucadair, M., Durand, A., Levis, P., and P. 1254 Roberts, "Issues with IP Address Sharing", RFC 6269, June 1255 2011. 1257 [RFC6302] Durand, A., Gashinsky, I., Lee, D., and S. Sheppard, 1258 "Logging Recommendations for Internet-Facing Servers", BCP 1259 162, RFC 6302, June 2011. 1261 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 1262 Stack Lite Broadband Deployments Following IPv4 1263 Exhaustion", RFC 6333, August 2011. 1265 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 1266 Cheshire, "Internet Assigned Numbers Authority (IANA) 1267 Procedures for the Management of the Service Name and 1268 Transport Protocol Port Number Registry", BCP 165, RFC 1269 6335, August 2011. 1271 [RFC6431] Boucadair, M., Levis, P., Bajko, G., Savolainen, T., and 1272 T. Tsou, "Huawei Port Range Configuration Options for PPP 1273 IP Control Protocol (IPCP)", RFC 6431, November 2011. 1275 [RFC6540] George, W., Donley, C., Liljenstolpe, C., and L. Howard, 1276 "IPv6 Support Required for All IP-Capable Nodes", BCP 177, 1277 RFC 6540, April 2012. 1279 [RFC6598] Weil, J., Kuarsingh, V., Donley, C., Liljenstolpe, C., and 1280 M. Azinger, "IANA-Reserved IPv4 Prefix for Shared Address 1281 Space", BCP 153, RFC 6598, April 2012. 1283 [RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: 1284 Combination of Stateful and Stateless Translation", RFC 1285 6877, April 2013. 1287 [RFC6887] Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. 1288 Selkirk, "Port Control Protocol (PCP)", RFC 6887, April 1289 2013. 1291 [RFC7011] Claise, B., Trammell, B., and P. Aitken, "Specification of 1292 the IP Flow Information Export (IPFIX) Protocol for the 1293 Exchange of Flow Information", STD 77, RFC 7011, September 1294 2013. 1296 [SENDMAIL_LOG_CONFIG] 1297 O'Reilly, "Sendmail, 3rd Edition, Page 798", December 1298 2002. 1300 [SSHD_LOG_CONFIG] 1301 "http://www.openbsd.org/cgi- bin/ 1302 man.cgi?query=sshd_config&sektion=5", April 2013. 1304 Appendix A. Configuration of Server Software to Log Source Port 1306 A.1. Apache 1308 The user can use LogFormat command to define a customized log format 1309 and use CustomLog command to apply that log format. "%a" and 1310 "%{remote}p" can be used in the format string to require logging the 1311 client's IP address and source port respectively. This feature is 1312 available since Apache version 2.1. 1314 A detailed configuration guide can be found at [APACHE_LOG_CONFIG]. 1316 A.2. Postfix 1318 In order to log the client source port, macro 1319 smtpd_client_port_logging should be set to "yes" in the configuration 1320 file. See [POSTFIX_LOG_CONFIG]. 1322 This feature has been available since Postfix version 2.5. 1324 A.3. Sendmail 1326 Sendmail has a macro ${client_port} storing the client port. To log 1327 the source port, the user can define some check rules. Here is an 1328 example which should be in the .mc configuration macro 1329 [SENDMAIL_LOG_CONFIG]: 1331 LOCAL_CONFIG 1332 Klog syslog 1334 LOCAL_RULESETS 1335 SLocal_check_mail 1336 R $* $@ $(log Port_Stat $&{client_addr} $&{client_port} $) 1338 This feature has been available since version 8.10. 1340 A.4. sshd 1342 SSHD_CONFIG(5) OpenBSD Programmer's Manual SSHD_CONFIG(5) NAME 1343 sshd_config - OpenSSH SSH daemon configuration file LogLevel Gives 1344 the verbosity level that is used when logging messages from sshd(8). 1345 The possible values are: QUIET, FATAL, ERROR, INFO, VERBOSE, DEBUG, 1346 DEBUG1, DEBUG2, and DEBUG3. The default is INFO. DEBUG and DEBUG1 1347 are equivalent. DEBUG2 and DEBUG3 each specify higher levels of 1348 debugging output. Logging with a DEBUG level violates the privacy of 1349 users and is not recommended. SyslogFacility Gives the facility code 1350 that is used when logging messages from sshd(8). The possible values 1351 are: DAEMON, USER, AUTH, LOCAL0, LOCAL1, LOCAL2, LOCAL3, LOCAL4, 1352 LOCAL5, LOCAL6, LOCAL7. The default is AUTH. 1354 sshd supports logging the client IP address and client port when a 1355 client starts connection since version 1.2.2, here is the source code 1356 in sshd.c: 1358 ... 1359 verbose("Connection from %.500s port %d", remote_ip, remote_port); 1360 ... 1362 sshd supports logging the client IP address when a client 1363 disconnects, from version 1.2.2 to version 5.0. Since version 5.1 1364 sshd supports logging the client IP address and source port. Here is 1365 the source code in sshd.c: 1367 ... 1368 /* from version 1.2.2 to 5.0*/ 1369 verbose("Closing connection to %.100s", remote_ip); 1370 ... 1372 /* since version 5.1*/ 1373 verbose("Closing connection to %.500s port %d", 1374 remote_ip, remote_port); 1376 In order to log the source port, the LogLevel should be set to 1377 VERBOSE [SSHD_LOG_CONFIG] in the configuration file: 1379 LogLevel VERBOSE 1381 A.5. Cyrus IMAP and UW IMAP 1383 Cyrus IMAP and UW IMAP do not support logging the source port for the 1384 time being. Both software packages use syslog to create logs; it 1385 should not be too difficult to get source port logging supported by 1386 adding some new code. 1388 Authors' Addresses 1390 Gang Chen 1391 China Mobile 1392 53A,Xibianmennei Ave., 1393 Xuanwu District, 1394 Beijing 100053 1395 China 1397 Email: phdgang@gmail.com 1399 Tina Tsou 1400 Huawei Technologies 1401 Bantian, Longgang District 1402 Shenzhen 518129 1403 P.R. China 1405 Email: tina.tsou.zouting@huawei.com 1407 Chris Donley 1408 CableLabs 1409 858 Coal Creek Cir 1410 Louisville, CO 80027 1411 USA 1413 Email: c.donley@cablelabs.com 1415 Tom Taylor 1416 PT Taylor Consulting 1417 Ottawa, Ontario 1418 Canada 1420 Email: tom.taylor.stds@gmail.com