idnits 2.17.1 draft-donley-behave-deterministic-cgn-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 4 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 (September 26, 2011) is 4595 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-13 == Outdated reference: A later version (-06) exists of draft-shirasaki-nat444-04 == 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: March 29, 2012 K. Sundaresan 6 CableLabs 7 September 26, 2011 9 Deterministic Address Mapping to Reduce Logging in Carrier Grade NATs 10 draft-donley-behave-deterministic-cgn-00 12 Abstract 14 Many Carrier Grade NAT solutions require per-connection logging. 15 Unfortunately, such logging is not scalable to many residential 16 broadband services. This document suggests a way to manage Carrier 17 Grade NAT translations in such a way as to significantly reduce the 18 amount of logging required while providing traceability for abuse 19 response. This method also provides a way of including geo-location 20 significance in such assignments. 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 March 29, 2012. 45 Copyright Notice 47 Copyright (c) 2011 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 NAT . . . . . . . . . . . . . . . . . . . . . . . 3 64 2.1. Geo-location Considerations . . . . . . . . . . . . . . . . 5 65 2.2. Deterministic NAT Example . . . . . . . . . . . . . . . . . 5 66 3. Additional Logging Considerations . . . . . . . . . . . . . . . 6 67 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 68 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 69 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 70 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 71 7.1. Normative References . . . . . . . . . . . . . . . . . . . 7 72 7.2. Informative References . . . . . . . . . . . . . . . . . . 8 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 75 1. Introduction 77 The world is rapidly running out of unallocated IPv4 addresses. To 78 meet the growing demand for Internet service from new subscribers, 79 devices, and service types, ISPs will be forced to share a single 80 public IPv4 address among multiple subscribers using a technology 81 such as Carrier Grade Network Address Translation (CGN) [RFC6264]. 82 However, address sharing poses additional challenges to ISPs in 83 responding to law enforcement requests or attack/abuse reports. In 84 order to respond to such requests to identify a specific user 85 associated with an IP address, an ISP will need to map a subscriber's 86 internal source IP address and source port with the global public IP 87 address and source port provided by the CGN for every connection 88 initiated by the user. 90 CGN connection logging satisfies the need to identify attackers and 91 respond to abuse/law enforcement requests, but it imposes significant 92 operational challenges to ISPs. In lab testing, we have observed CGN 93 log messages to be approximately 150 bytes long for NAT444 94 [I-D.shirasaki-nat444], and 175 bytes for DS-Lite [RFC6333] 95 (individual log messages vary somewhat in size). Although we are not 96 aware of definitive studies of connection rates per subscriber, 97 reports from several ISPs in the US sets the average number of 98 connections per household per day at approximately 33,000 connections 99 per day. If each connection is individually logged, this translates 100 to a data volume of approximately 5 MB per subscriber per day, or 101 about 150 MB per subscriber per month; however, specific data volumes 102 may vary across different ISPs based on myriad factors. Based on 103 available data, a 1-million subscriber service provider will generate 104 approximately 150 terabytes of log data per month, or 1.8 petabytes 105 per year. 107 As an alternative to per-connection logging, CGNs could 108 deterministically map internal addresses to external addresses in 109 such a way as to be able to algorithmically calculate the mapping 110 without relying on per connection logging. This document describes a 111 method for such CGN address mapping, combined with block port 112 reservations, that significantly reduces the burden on ISPs while 113 offering the ability to map a subscriber's inside IP address with an 114 outside address and port observed on the Internet. 116 2. Deterministic NAT 118 While a subscriber uses thousands of connections per day, most 119 subscribers use far fewer at any given time. When the compression 120 ratio is low (i.e., the ratio of the number of subscribers to the 121 number of public IPv4 addresses allocated to a CGN is closer to 10:1 122 than 1000:1), each subscriber could expect to have access to 123 thousands of TCP/UDP ports at any given time. Thus, as an 124 alternative to logging each connection, CGNs could deterministically 125 map customer private addresses on the inside of the CGN to public 126 addresses on the outside of the CGN. This algorithm will allow an 127 operator to identify a subscriber internal IP address when provided 128 the public side IP and port number without having to examine the CGN 129 translation logs. This prevents an operator from having to transport 130 and store massive amounts of session data from the CGN and then 131 process it to identify a subscriber. 133 Deterministic NAT requires configuration of the following variables: 135 o Inside IPv4/IPv6 address range (I); 137 o Outside IPv4 address range (O); 139 o Compression ratio (e.g. inside IP addresses I/outside IP addresses 140 O) (C); 142 o Dynamic address pool factor (D), to be added to the compression 143 ratio in order to create an overflow address pool; 145 o Maximum ports per user (M); and 147 o Reserved TCP/UDP port list 149 Note: The inside address range (I) will be an IPv4 range in NAT444 150 operation ([I-D.shirasaki-nat444]) and an IPv6 range in DS-Lite 151 operation ([RFC6333]). 153 The CGN then reserves ports as follows: 155 1. The CGN removes reserved ports from the port candidate list (e.g. 156 1-1023 for TCP and UDP). At a minimum, the CGN SHOULD remove 157 system ports [I-D.ietf-tsvwg-iana-ports] from the port candidate 158 list reserved for deterministic assignment. 160 2. The CGN calculates the total compression ratio (C+D), and 161 allocates 1/(C+D) of the available ports to each internal IP 162 address. Any remaining ports are allocated to the dynamic pool. 163 Port allocation could be made sequentially (e.g. the first block 164 goes to address 1, the second block to address 2, etc.), 165 staggered (e.g. address 1 receives ports n*(C+D), address 2 166 receives ports 1+n*(C+D), etc.), or through some other 167 deterministic algorithm left to CGN implementation. Subscribers 168 could be restricted to ports from a single IPv4 address, or could 169 be allocated ports across all addresses in a pool, for example. 171 3. When a subscriber initiates a connection, the CGN creates a 172 translation mapping between the subscriber's inside local IP 173 address/port and the CGN outside global IP address/port. The CGN 174 MUST use one of the ports allocated in step 2 for the translation 175 as long as such ports are available. The CGN MUST use the 176 preallocated port range from step 2 for port control protocol 177 (PCP) [I-D.ietf-pcp-base] reservations as long as such ports are 178 available. While the CGN maintains its mapping table, it need 179 not generate a log entry for translation mappings created in this 180 step. 182 4. The CGN will have a pool of ports left for dynamic assignment. 183 If a subscriber uses more than the range of ports allocated in 184 step 2 (but fewer than the configured maximum ports M), the CGN 185 uses a port from the dynamic assignment range for such a 186 connection or for PCP reservations. The CGN MUST log dynamically 187 assigned ports to facilitate subscriber-to-address mapping. The 188 CGN SHOULD manage dynamic ports as described in 189 [I-D.tsou-behave-natx4-log-reduction]. 191 5. Configuration of reserved ports (e.g. system ports) is left to 192 operator configuration. 194 Thus, the CGN will maintain translation mapping information for all 195 connections within its internal translation tables; however, it only 196 needs to externally log translations for dynamically-assigned ports. 198 2.1. Geo-location Considerations 200 As described in [RFC6269], CGN implementation can reduce the level of 201 confidence and level of granularity of geo-location information. 202 However, the level of confidence in geo-location data can be 203 increased, even in a centralized CGN deployment, by sub-dividing 204 inside and outside ranges. If I and O are subdivided such that I-1 205 corresponds to a particular headend or central office (CO), and I-2 206 corresponds with another headend/CO, etc., then geo-location data 207 tied to address ranges O-1 and O-2, etc. can be accurate down to the 208 headend/CO level, approximately the same level of granularity 209 available in residential broadband services without CGNs. This 210 information can help content providers enforce regional content 211 licensing restrictions, target advertising to local markets, and 212 assist with emergency services provisioning. 214 2.2. Deterministic NAT Example 216 To illustrate the use of deterministic NAT, let's consider a simple 217 example. The operator configures an inside address range (I) of 218 192.168.0.0/28 and outside address (O) of 203.0.113.1. The dynamic 219 buffer factor is set to '2'. Thus, the total compression ratio is 220 1:(14+2) = 1:16. Only the system ports (e.g. ports < 1024) are 221 reserved. This configuration causes the CGN to preallocate ((65536- 222 1024)/16 =) 4032 TCP and 4032 UDP ports per inside IPv4 address. For 223 the purposes of this example, let's assume that they are allocated 224 sequentially, where 192.168.0.1 maps to 203.0.113.1 ports 1024-5055, 225 192.168.0.2 maps to 203.0.113.1 ports 5056-9087, etc. The dynamic 226 port range thus contains ports 57472-65535. Finally, the maximum 227 ports/subscriber is set to 5040. 229 When subscriber 1 using 192.168.0.1 initiates a low volume of 230 connections (e.g. < 4032 concurrent connections), the CGN maps the 231 outgoing source address/port to the preallocated range. These 232 translation mappings are not logged. 234 Subscriber 2 concurrently uses more than the allocated 4032 ports 235 (e.g. for peer-to-peer, mapping, video streaming, or other 236 connection-intensive traffic types), the CGN allocates up to an 237 additional 1008 ports using bulk port reservations. In this example, 238 subscriber 2 uses outside ports 5056-9087, and then 100-port blocks 239 between 58000-58999. Connections using ports 5056-9087 are not 240 logged, while 10 log entries are created for ports 58000-58099, 241 58100-58199, 58200-58299, ..., 58900-58999. 243 If a law enforcement agency reports abuse from 203.0.113.1, port 244 2001, the operator can reverse the mapping algorithm to determine 245 that subscriber 1 generated the traffic without consulting logs. If 246 a second abuse report comes in for 203.0.113.1, port 58204, the 247 operator will determine that port 58204 is within the dynamic pool 248 range, consult the log file, and determine that subscriber 2 249 generated the traffic (assuming that the law enforcement timestamp 250 matches the operator timestamp). 252 In this example, there are no log entries for the majority of 253 subscribers, who only use pre-allocated ports. Only minimal logging 254 would be needed for those few subscribers who exceed their pre- 255 allocated ports and obtain extra bulk port assignments from the 256 dynamic pool. Logging data for those users will include inside 257 address, outside address, outside port range, and timestamp. 259 3. Additional Logging Considerations 261 In order to be able to identify a subscriber based on observed 262 external IPv4 address, port, and timestamp, an operator needs to know 263 how the CGN was configured with regards to internal and external IP 264 addresses, dynamic address pool factor, maximum ports per user, and 265 reserved port range at any given time. Therefore, the CGN MUST 266 generate a log message any time such variables are changed. Also, 267 the CGN SHOULD generate such a log message once per day to facilitate 268 quick identification of the relevant configuration in the event of an 269 abuse notification. 271 Such a log message MUST, at minimum, include the timestamp, inside 272 prefix I, inside mask, outside prefix O, outside mask, D, M, and 273 reserved port range; for example: 275 [Wed Oct 11 14:32:52 2000]:192.168.0.0:28:203.0.113.0:32:2:5040:1- 276 1023,5004,5060. 278 4. IANA Considerations 280 This document makes no request of IANA. 282 5. Security Considerations 284 The security considerations applicable to NAT operation for various 285 protocols as documented in, for example, RFC 4787 [RFC4787] and RFC 286 5382 [RFC5382] also apply to this document. 288 6. Acknowledgements 290 TBD 292 7. References 294 7.1. Normative References 296 [I-D.ietf-pcp-base] 297 Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. 298 Selkirk, "Port Control Protocol (PCP)", 299 draft-ietf-pcp-base-13 (work in progress), July 2011. 301 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 302 Requirement Levels", BCP 14, RFC 2119, March 1997. 304 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 305 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 306 RFC 4787, January 2007. 308 [RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. 309 Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, 310 RFC 5382, October 2008. 312 [RFC6264] Jiang, S., Guo, D., and B. Carpenter, "An Incremental 313 Carrier-Grade NAT (CGN) for IPv6 Transition", RFC 6264, 314 June 2011. 316 [RFC6269] Ford, M., Boucadair, M., Durand, A., Levis, P., and P. 317 Roberts, "Issues with IP Address Sharing", RFC 6269, 318 June 2011. 320 7.2. Informative References 322 [I-D.ietf-tsvwg-iana-ports] 323 Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 324 Cheshire, "Internet Assigned Numbers Authority (IANA) 325 Procedures for the Management of the Service Name and 326 Transport Protocol Port Number Registry", 327 draft-ietf-tsvwg-iana-ports-10 (work in progress), 328 February 2011. 330 [I-D.shirasaki-nat444] 331 Yamagata, I., Shirasaki, Y., Nakagawa, A., Yamaguchi, J., 332 and H. Ashida, "NAT444", draft-shirasaki-nat444-04 (work 333 in progress), July 2011. 335 [I-D.tsou-behave-natx4-log-reduction] 336 ZOU), T., Li, W., and T. Taylor, "Port Management To 337 Reduce Logging In Large-Scale NATs", 338 draft-tsou-behave-natx4-log-reduction-02 (work in 339 progress), September 2010. 341 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 342 Stack Lite Broadband Deployments Following IPv4 343 Exhaustion", RFC 6333, August 2011. 345 Authors' Addresses 347 Chris Donley 348 CableLabs 349 858 Coal Creek Cir 350 Louisville, CO 80027 351 US 353 Email: c.donley@cablelabs.com 354 Chris Grundemann 355 CableLabs 356 858 Coal Creek Cir 357 Louisville, CO 80027 358 US 360 Email: c.grundemann@cablelabs.com 362 Vikas Sarawat 363 CableLabs 364 858 Coal Creek Cir 365 Louisville, CO 80027 366 US 368 Email: v.sarawat@cablelabs.com 370 Karthik Sundaresan 371 CableLabs 372 858 Coal Creek Cir 373 Louisville, CO 80027 374 US 376 Email: k.sundaresan@cablelabs.com