idnits 2.17.1 draft-donley-behave-deterministic-cgn-02.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 18 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 24, 2012) is 4415 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-29) exists of draft-ietf-pcp-base-21 == Outdated reference: A later version (-06) exists of draft-shirasaki-nat444-05 == Outdated reference: A later version (-06) exists of draft-tsou-behave-natx4-log-reduction-02 Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Donley 3 Internet-Draft C. Grundemann 4 Intended status: Experimental V. Sarawat 5 Expires: September 25, 2012 K. Sundaresan 6 CableLabs 7 March 24, 2012 9 Deterministic Address Mapping to Reduce Logging in Carrier Grade NAT 10 Deployments 11 draft-donley-behave-deterministic-cgn-02 13 Abstract 15 Many Carrier Grade NAT solutions require per-connection logging. 16 Unfortunately, such logging is not scalable to many residential 17 broadband services. This document suggests a way to manage Carrier 18 Grade NAT translations in such a way as to significantly reduce the 19 amount of logging required while providing traceability for abuse 20 response. 22 Requirements Language 24 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 25 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 26 document are to be interpreted as described in RFC 2119 [RFC2119]. 28 Status of this Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on September 25, 2012. 45 Copyright Notice 47 Copyright (c) 2012 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Deterministic Port Ranges . . . . . . . . . . . . . . . . . . 4 64 2.1. Stability and Load-Balancing Considerations . . . . . . . 6 65 2.2. IPv4 Port Utilization Efficiency . . . . . . . . . . . . . 7 66 2.3. Planning & Dimensioning . . . . . . . . . . . . . . . . . 7 67 2.4. Deterministic CGN Example . . . . . . . . . . . . . . . . 7 68 3. Additional Logging Considerations . . . . . . . . . . . . . . 9 69 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 70 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 71 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 72 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 73 7.1. Normative References . . . . . . . . . . . . . . . . . . . 10 74 7.2. Informative References . . . . . . . . . . . . . . . . . . 10 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 77 1. Introduction 79 The world is rapidly running out of unallocated IPv4 addresses. To 80 ensure IPv4 service continuity under the growing demands from new 81 subscribers, devices, and service types, ISPs will be forced to share 82 a single public IPv4 address among multiple subscribers using 83 techniques such as Carrier Grade Network Address Translation (CGN) 84 [RFC6264] (e.g., NAT444 [I-D.shirasaki-nat444], DS-Lite [RFC6333], 85 etc.). However, address sharing poses additional challenges to ISPs 86 in responding to public safety requests or attack/abuse reports 87 [RFC6269]. In order to respond to such requests to identify a 88 specific user associated with an IP address, an ISP will need to map 89 a subscriber's internal source IP address and source port with the 90 global public IP address and source port provided by the CGN for 91 every connection initiated by the user. 93 CGN connection logging satisfies the need to identify attackers and 94 respond to abuse/public safety requests, but it imposes significant 95 operational challenges to ISPs. In lab testing, we have observed CGN 96 log messages to be approximately 150 bytes long for NAT444 97 [I-D.shirasaki-nat444], and 175 bytes for DS-Lite [RFC6333] 98 (individual log messages vary somewhat in size). Although we are not 99 aware of definitive studies of connection rates per subscriber, 100 reports from several ISPs in the US sets the average number of 101 connections per household per day at approximately 33,000 connections 102 per day. If each connection is individually logged, this translates 103 to a data volume of approximately 5 MB per subscriber per day, or 104 about 150 MB per subscriber per month; however, specific data volumes 105 may vary across different ISPs based on myriad factors. Based on 106 available data, a 1-million subscriber service provider will generate 107 approximately 150 terabytes of log data per month, or 1.8 petabytes 108 per year. 110 The volume of CGN logging can be reduced by assigning port ranges 111 instead of individual ports. Using this method, only the assignment 112 of a new port range is logged. This may massively reduce logging 113 volume. The log reduction may vary depending on the length of the 114 assigned port range, whether the port range is static or dynamic, 115 etc. This has been acknowledged in RFC6292 [RFC6269]: 117 "Address sharing solutions may mitigate these issues to some extent 118 by pre-allocating groups of ports. Then only the allocation of the 119 group needs to be recorded, and not the creation of every session 120 binding within that group. There are trade-offs to be made between 121 the sizes of these port groups, the ratio of public addresses to 122 subscribers, whether or not these groups timeout, and the impact on 123 logging requirements and port randomization security (RFC6056) 124 [RFC6056]." 125 For the greatest reduction in logging, CGNs could be designed and/or 126 configured to deterministically map internal addresses to {external 127 address + port range} in such a way as to be able to algorithmically 128 calculate the mapping. Only inputs and configuration of the 129 algorithm need to be logged. 131 This document describes a method for such CGN address mapping, 132 combined with block port reservations, that significantly reduces the 133 burden on ISPs while offering the ability to map a subscriber's 134 inside IP address with an outside address and external port number 135 observed on the Internet. 137 The activation of the proposed port range allocation scheme is 138 compliant with BEHAVE requirements such as the support of APP. 140 2. Deterministic Port Ranges 142 While a subscriber uses thousands of connections per day, most 143 subscribers use far fewer at any given time. When the compression 144 ratio (see Appendix B of RFC6269 [RFC6269]) is low (e.g., the ratio 145 of the number of subscribers to the number of public IPv4 addresses 146 allocated to a CGN is closer to 10:1 than 1000:1), each subscriber 147 could expect to have access to thousands of TCP/UDP ports at any 148 given time. Thus, as an alternative to logging each connection, CGNs 149 could deterministically map customer private addresses (received on 150 the customer-facing interface of the CGN, a.k.a., internal side) to 151 public addresses extended with port ranges (used on the Internet- 152 facing interface of the CGN, a.k.a., external side). This algorithm 153 allows an operator to identify a subscriber internal IP address when 154 provided the public side IP and port number without having to examine 155 the CGN translation logs. This prevents an operator from having to 156 transport and store massive amounts of session data from the CGN and 157 then process it to identify a subscriber. 159 The algorithmic mapping can be expressed as: 161 (External IP Address, Port Range) = function 1 (Internal IP Address) 163 Internal IP Address = function 2 (External IP Address, Port Number) 165 The CGN SHOULD provide a method for users to test both mapping 166 functions (e.g., enter an External IP Address + Port Number and 167 recieve the corrosponding Internal IP Address). 169 Deterministic Port Range allocation requires configuration of the 170 following variables: 172 o Inside IPv4/IPv6 address range (I); 174 o Outside IPv4 address range (O); 176 o Compression ratio (e.g. inside IP addresses I/outside IP addresses 177 O) (C); 179 o Dynamic address pool factor (D), to be added to the compression 180 ratio in order to create an overflow address pool; 182 o Maximum ports per user (M); and 184 o Reserved TCP/UDP port list 186 Note: The inside address range (I) will be an IPv4 range in NAT444 187 operation (NAT444 [I-D.shirasaki-nat444]) and an IPv6 range in DS- 188 Lite operation (DS-Lite [RFC6333]). 190 A subscriber is identified by an internal IPv4 address (e.g., NAT44) 191 or an IPv6 prefix (e.g., DS-Lite or NAT64). 193 The algorithm may be generalized to L2-aware NAT 194 [I-D.miles-behave-l2nat] but this requires the configuration of the 195 Internal interface identifiers (e.g., MAC addresses). 197 The algorithm is not designed to retrieve an internal host among 198 those sharing the same internal IP address (e.g., in a DS-Lite 199 context, only an IPv6 address/prefix can be retrieved using the 200 algorithm while the internal IPv4 address used for the encapsulated 201 IPv4 datagram is lost). 203 The assigned range of ports MAY also be used when translating ICMP 204 requests (when re-writing the Identifier field). 206 The CGN then reserves ports as follows: 208 1. The CGN removes reserved ports from the port candidate list 209 (e.g., 0-1023 for TCP and UDP). At a minimum, the CGN SHOULD 210 remove system ports (RFC6335) [RFC6335] from the port candidate 211 list reserved for deterministic assignment. 213 2. The CGN calculates the total compression ratio (C+D), and 214 allocates 1/(C+D) of the available ports to each internal IP 215 address. Any remaining ports are allocated to the dynamic pool. 216 Port allocation could be made sequentially (e.g. the first block 217 goes to address 1, the second block to address 2, etc.), 218 staggered (e.g. address 1 receives ports n*(C+D), address 2 219 receives ports 1+n*(C+D), etc.), or through some other 220 deterministic algorithm left to CGN implementation. Subscribers 221 could be restricted to ports from a single IPv4 address, or could 222 be allocated ports across all addresses in a pool, for example. 223 The range of ports can be contiguous or be randomly assigned 224 (e.g., using the random function defined in Section 2.2 of 225 RFC6431 [RFC6431]. 227 3. When a subscriber initiates a connection, the CGN creates a 228 translation mapping between the subscriber's inside local IP 229 address/port and the CGN outside global IP address/port. The CGN 230 MUST use one of the ports allocated in step 2 for the translation 231 as long as such ports are available. The CGN MUST use the 232 preallocated port range from step 2 for Port Control Protocol 233 (PCP, [I-D.ietf-pcp-base]) reservations as long as such ports are 234 available. While the CGN maintains its mapping table, it need 235 not generate a log entry for translation mappings created in this 236 step. 238 4. The CGN will have a pool of ports left for dynamic assignment. 239 If a subscriber uses more than the range of ports allocated in 240 step 2 (but fewer than the configured maximum ports M), the CGN 241 uses a port from the dynamic assignment range for such a 242 connection or for PCP reservations. The CGN MUST log dynamically 243 assigned ports to facilitate subscriber-to-address mapping. The 244 CGN SHOULD manage dynamic ports as described in 245 [I-D.tsou-behave-natx4-log-reduction]. 247 5. Configuration of reserved ports (e.g., system ports) is left to 248 operator configuration. 250 Thus, the CGN will maintain translation mapping information for all 251 connections within its internal translation tables; however, it only 252 needs to externally log translations for dynamically-assigned ports. 254 2.1. Stability and Load-Balancing Considerations 256 Using the procedure defined in this document assumes a deterministic 257 distribution of customers among deployed CGN devices. Balancing the 258 traffic among several CGNs based on their actual load may not be 259 supported because of the potential conflict of enforced algorithmic 260 mapping rule. When CGN redundancy group is used, the same mapping 261 rule, including in particular the external IP address, MUST be used. 262 Furthermore, traffic oscillation MUST be avoided (because, unless 263 state synchronization is used, the actual NAT state may not be 264 instantiated in the redundancy group). 266 2.2. IPv4 Port Utilization Efficiency 268 For Service Providers requiring an aggressive address sharing ration, 269 the use of the algorithmic mapping may impact the efficiency of the 270 address sharing. Using a dynamic port range scheme, dynamic port 271 assignment or a mix of static mapping and dynamic port assignment is 272 more suitable for those SPs. 274 2.3. Planning & Dimensioning 276 Unlike dynamic approaches, the use of the algorithmic mapping 277 requires more effort from operational teams to tweak the algorithm 278 (e.g., size of the port range, address sharing ratio, etc.). 279 Dedicated alarms SHOULD be configured when some port utilization 280 thresholds are fired so that the configuration can be refined. 282 2.4. Deterministic CGN Example 284 To illustrate the use of deterministic NAT, let's consider a simple 285 example. The operator configures an inside address range (I) of 286 192.168.0.0/28 and outside address (O) of 203.0.113.1. The dynamic 287 buffer factor is set to '2'. Thus, the total compression ratio is 288 1:(14+2) = 1:16. Only the system ports (e.g. ports < 1024) are 289 reserved. This configuration causes the CGN to preallocate ((65536- 290 1024)/16 =) 4032 TCP and 4032 UDP ports per inside IPv4 address. For 291 the purposes of this example, let's assume that they are allocated 292 sequentially, where 192.168.0.1 maps to 203.0.113.1 ports 1024-5055, 293 192.168.0.2 maps to 203.0.113.1 ports 5056-9087, etc. The dynamic 294 port range thus contains ports 57472-65535 (port allocation 295 illustrated in the table below). Finally, the maximum ports/ 296 subscriber is set to 5040. 298 +-----------------------+-------------------------+ 299 | Inside Address / Pool | Outside Address & Port | 300 +-----------------------+-------------------------+ 301 | Reserved | 203.0.113.1:0-1023 | 302 | 192.168.0.1 | 203.0.113.1:1024-5055 | 303 | 192.168.0.2 | 203.0.113.1:5056-9087 | 304 | 192.168.0.3 | 203.0.113.1:9088-13119 | 305 | 192.168.0.4 | 203.0.113.1:13120-17151 | 306 | 192.168.0.5 | 203.0.113.1:17151-21183 | 307 | 192.168.0.6 | 203.0.113.1:21184-25215 | 308 | 192.168.0.7 | 203.0.113.1:25216-29247 | 309 | 192.168.0.8 | 203.0.113.1:29248-33279 | 310 | 192.168.0.9 | 203.0.113.1:33280-37311 | 311 | 192.168.0.10 | 203.0.113.1:37312-41343 | 312 | 192.168.0.11 | 203.0.113.1:41344-45375 | 313 | 192.168.0.12 | 203.0.113.1:45376-49407 | 314 | 192.168.0.13 | 203.0.113.1:49408-53439 | 315 | 192.168.0.14 | 203.0.113.1:53440-57471 | 316 | Dynamic | 203.0.113.1:57472-65535 | 317 +-----------------------+-------------------------+ 319 When subscriber 1 using 192.168.0.1 initiates a low volume of 320 connections (e.g. < 4032 concurrent connections), the CGN maps the 321 outgoing source address/port to the preallocated range. These 322 translation mappings are not logged. 324 Subscriber 2 concurrently uses more than the allocated 4032 ports 325 (e.g. for peer-to-peer, mapping, video streaming, or other 326 connection-intensive traffic types), the CGN allocates up to an 327 additional 1008 ports using bulk port reservations. In this example, 328 subscriber 2 uses outside ports 5056-9087, and then 100-port blocks 329 between 58000-58999. Connections using ports 5056-9087 are not 330 logged, while 10 log entries are created for ports 58000-58099, 331 58100-58199, 58200-58299, ..., 58900-58999. 333 If a public safety agency reports abuse from 203.0.113.1, port 2001, 334 the operator can reverse the mapping algorithm to determine that the 335 internal IP address subscriber 1 has been assigned generated the 336 traffic without consulting CGN logs (by correlating the internal IP 337 address with DHCP/PPP lease connection records). If a second abuse 338 report comes in for 203.0.113.1, port 58204, the operator will 339 determine that port 58204 is within the dynamic pool range, consult 340 the log file, corrolate with connection records, and determine that 341 subscriber 2 generated the traffic (assuming that the public safety 342 timestamp matches the operator timestamp. As noted in RFC6292 343 [RFC6292], accurate time-keeping (e.g., use of NTP or Simple NTP) is 344 vital). 346 In this example, there are no log entries for the majority of 347 subscribers, who only use pre-allocated ports. Only minimal logging 348 would be needed for those few subscribers who exceed their pre- 349 allocated ports and obtain extra bulk port assignments from the 350 dynamic pool. Logging data for those users will include inside 351 address, outside address, outside port range, and timestamp. 353 3. Additional Logging Considerations 355 In order to be able to identify a subscriber based on observed 356 external IPv4 address, port, and timestamp, an operator needs to know 357 how the CGN was configured with regards to internal and external IP 358 addresses, dynamic address pool factor, maximum ports per user, and 359 reserved port range at any given time. Therefore, the CGN MUST 360 generate a log message any time such variables are changed. Also, 361 the CGN SHOULD generate such a log message once per day to facilitate 362 quick identification of the relevant configuration in the event of an 363 abuse notification. 365 Such a log message MUST, at minimum, include the timestamp, inside 366 prefix I, inside mask, outside prefix O, outside mask, D, M, and 367 reserved port range; for example: 369 [Wed Oct 11 14:32:52 2000]:192.168.0.0:28:203.0.113.0:32:2:5040:1- 370 1023,5004,5060. 372 4. IANA Considerations 374 This document makes no request of IANA. 376 5. Security Considerations 378 The security considerations applicable to NAT operation for various 379 protocols as documented in, for example, RFC 4787 [RFC4787] and RFC 380 5382 [RFC5382] also apply to this document. 382 6. Acknowledgements 384 TBD 386 7. References 387 7.1. Normative References 389 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 390 Requirement Levels", BCP 14, RFC 2119, March 1997. 392 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 393 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 394 RFC 4787, January 2007. 396 [RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. 397 Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, 398 RFC 5382, October 2008. 400 [RFC6264] Jiang, S., Guo, D., and B. Carpenter, "An Incremental 401 Carrier-Grade NAT (CGN) for IPv6 Transition", RFC 6264, 402 June 2011. 404 [RFC6269] Ford, M., Boucadair, M., Durand, A., Levis, P., and P. 405 Roberts, "Issues with IP Address Sharing", RFC 6269, 406 June 2011. 408 7.2. Informative References 410 [I-D.ietf-pcp-base] 411 Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. 412 Selkirk, "Port Control Protocol (PCP)", 413 draft-ietf-pcp-base-21 (work in progress), January 2012. 415 [I-D.miles-behave-l2nat] 416 Miles, D. and M. Townsley, "Layer2-Aware NAT", 417 draft-miles-behave-l2nat-00 (work in progress), 418 March 2009. 420 [I-D.shirasaki-nat444] 421 Yamagata, I., Shirasaki, Y., Nakagawa, A., Yamaguchi, J., 422 and H. Ashida, "NAT444", draft-shirasaki-nat444-05 (work 423 in progress), January 2012. 425 [I-D.tsou-behave-natx4-log-reduction] 426 ZOU), T., Li, W., and T. Taylor, "Port Management To 427 Reduce Logging In Large-Scale NATs", 428 draft-tsou-behave-natx4-log-reduction-02 (work in 429 progress), September 2010. 431 [RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport- 432 Protocol Port Randomization", BCP 156, RFC 6056, 433 January 2011. 435 [RFC6292] Hoffman, P., "Requirements for a Working Group Charter 436 Tool", RFC 6292, June 2011. 438 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 439 Stack Lite Broadband Deployments Following IPv4 440 Exhaustion", RFC 6333, August 2011. 442 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 443 Cheshire, "Internet Assigned Numbers Authority (IANA) 444 Procedures for the Management of the Service Name and 445 Transport Protocol Port Number Registry", BCP 165, 446 RFC 6335, August 2011. 448 [RFC6431] Boucadair, M., Levis, P., Bajko, G., Savolainen, T., and 449 T. Tsou, "Huawei Port Range Configuration Options for PPP 450 IP Control Protocol (IPCP)", RFC 6431, November 2011. 452 Authors' Addresses 454 Chris Donley 455 CableLabs 456 858 Coal Creek Cir 457 Louisville, CO 80027 458 US 460 Email: c.donley@cablelabs.com 462 Chris Grundemann 463 CableLabs 464 858 Coal Creek Cir 465 Louisville, CO 80027 466 US 468 Email: c.grundemann@cablelabs.com 470 Vikas Sarawat 471 CableLabs 472 858 Coal Creek Cir 473 Louisville, CO 80027 474 US 476 Email: v.sarawat@cablelabs.com 477 Karthik Sundaresan 478 CableLabs 479 858 Coal Creek Cir 480 Louisville, CO 80027 481 US 483 Email: k.sundaresan@cablelabs.com