idnits 2.17.1 draft-tsou-behave-natx4-log-reduction-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 2, 2015) is 3098 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 ---------------------------------------------------------------------------- == Outdated reference: A later version (-02) exists of draft-ietf-sunset4-nat64-port-allocation-01 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Behavior Engineering for Hindrance T. Tsou 3 Avoidance Huawei Technologies (USA) 4 Internet-Draft W. Li 5 Intended status: Informational China Telecom 6 Expires: May 5, 2016 T. Taylor 7 J. Huang 8 Huawei Technologies 9 November 2, 2015 11 Port Management To Reduce Logging In Large-Scale NATs 12 draft-tsou-behave-natx4-log-reduction-06 14 Abstract 16 Various IPv6 transition strategies require the introduction of large- 17 scale NATs (e.g. AFTR, NAT64) to share the limited supply of IPv4 18 addresses available in the network until transition is complete. 19 There has recently been debate over how to manage the sharing of 20 ports between different subscribers sharing the same IPv4 address. 21 One factor in the discussion is the operational requirement to log 22 the assignment of transport addresses to subscribers. It has been 23 argued that dynamic assignment of individual ports between 24 subscribers requires the generation of an excessive volume of logs. 25 This document suggests a way to achieve dynamic port sharing while 26 keeping log volumes low. 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 May 5, 2016. 45 Copyright Notice 47 Copyright (c) 2015 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. A Suggested Solution . . . . . . . . . . . . . . . . . . . . . 3 64 3. Issues Of Traceability . . . . . . . . . . . . . . . . . . . . 5 65 4. Other Considerations . . . . . . . . . . . . . . . . . . . . . 6 66 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 67 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 68 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 69 8. Appendix A: Configure Server Software to Log Source Port . . . 7 70 8.1. Apache . . . . . . . . . . . . . . . . . . . . . . . . . . 7 71 8.2. Postfix . . . . . . . . . . . . . . . . . . . . . . . . . 8 72 8.3. Sendmail . . . . . . . . . . . . . . . . . . . . . . . . . 8 73 8.4. sshd . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 74 8.5. Cyrus IMAP and UW IMAP . . . . . . . . . . . . . . . . . . 9 75 9. Informative References . . . . . . . . . . . . . . . . . . . . 9 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 78 1. Introduction 80 During the IPv6 transition period, some large-scale NAT devices may 81 be introduced, e.g. DS-Lite AFTR, NAT64. When a NAT device needs to 82 set up a new connection for a given internal address behind the NAT, 83 it needs to create a new mapping entry for the new connection, which 84 will contain source IP address, source port or ICMP identifier, 85 converted source IP address, converted source port, protocol (TCP/ 86 UDP), etc. 88 Due to legislation and law enforcement requirement, sometimes it is 89 necessary to log these mapping for a period of time, such as 6 90 months. The mapping information is highly privacy sensitive, if 91 possible, it should be deleted as soon as possible. Some high 92 performance NAT devices may need to create a large amount of new 93 sessions per second. If logs are generated for each mapping entry, 94 the log traffic could reach tens of megabytes per second or more, 95 which would be a problem for log generation, transmission and 96 storage. According to a test done by 97 [I-D.ietf-sunset4-nat64-port-allocation], in a network with 20, 000 98 subscribers, over 60 days period, the raw log size can reach 42.5TB 99 if it is based on per-session log, while the log size will be 40.6 GB 100 if it is based on port blocks. Alghough compression technologies can 101 be used before the log storage, the log size is still big. 103 [RFC6888], REQ-13 suggest "maximize port utilization", REQ-14 suggest 104 "minimize log volume". However, it is difficult to achieve both, 105 there will be a tradeoff between the efficiency with which ports are 106 used and the rate of generation of log records. 108 2. A Suggested Solution 110 This document proposes a solution that allows dynamic sharing of port 111 ranges between users while minimizing the number of logs that have to 112 be generated. Briefly, ports are allocated to the user in blocks. 113 Logs are generated only when blocks are allocated or deallocated. 114 This provides the necessary traceability while reducing log 115 generation by a factor equal to the block size, as compared with 116 fully dynamic port allocation. 118 Here is how the proposal would work in greater detail. When the user 119 sends out the first packet, a port resource pool is allocated for the 120 user, e.g., assigning ports 2001~2300 of a public IP address to the 121 user's resource pool. Only one log should be generated for this port 122 block. When the NAT needs to set up a new mapping entry for the 123 user, it can use a port in the user's resource pool and the 124 corresponding public IP address. If the user needs more port 125 resources, the NAT can allocate another port block, e.g., ports 126 3501~3800, to the user's resource pool. Again, just one log needs to 127 be generated for this port block. 129 [RFC6431] takes this idea further by allocating non-contiguous sets 130 of ports using a pseudorandom function. Scattering the allocated 131 ports in this way provides a modest barrier to port guessing attacks. 132 The use of randomization is discussed further in Section 6. 134 Suppose now that a given internal address has been assigned more than 135 one block of ports. The individual sessions using ports within a 136 port block will start and end at different times. If no ports in 137 some port block are used for some configurable time, the NAT can 138 remove the port block from the resource pool allocated to a given 139 internal address, and make it available for other users. In theory, 140 it is unnecessary to log deallocations of blocks of ports, because 141 the ports in deallocated blocks will not be used again until the 142 blocks are reallocated. However, the deallocation may be logged when 143 it occurs add robustness to troubleshooting or other procedures. 145 The deallocation procedure presents a number of difficulties in 146 practice. The first problem is the choice of timeout value for the 147 block. If idle timers are applied for the individual mappings 148 (sessions) within the block, and these conform to the recommendations 149 for NAT behaviour for the protocol concerned, then the additional 150 time that might be configured as a guard for the block as a whole 151 need not be more than a few minutes. The block timer in this case 152 serves only as a slightly more conservative extension of the 153 individual session idle timers. If, instead, a single idle timer is 154 used for the whole block, it must itself conform to the 155 recommendations for the protocol with which that block of ports is 156 associated. For example, REQ-5 of [RFC5382] requires an idle timer 157 expiry duration of at least 2 hours and 4 minutes for TCP. 159 The next issue with port block deallocation is the conflict between 160 the desire to randomize port allocation and the desire to make unused 161 resources available to other internal addresses. As mentioned above, 162 ideally port selection will take place over the entire set of blocks 163 allocated to the internal address. However, taken to its fullest 164 extent, such a policy will minimize the probability that all ports in 165 any given block are idle long enough for it to be released. 167 As an alternative, it is suggested that when choosing which block to 168 select a port from, the NAT should omit from its range of choice the 169 block that has been idle the longest, unless no ports are available 170 in any of the other blocks. The expression "block that has been idle 171 the longest" designates the block in which the time since the last 172 packet was observed in any of its sessions, in either direction, is 173 earlier than the corresponding time in any of the other blocks 174 assigned to that internal address. 176 3. Issues Of Traceability 178 Section 11 of [RFC6269] provides a good discussion of the 179 traceability issue. Complete traceability given the NAT logging 180 practices proposed in this draft requires that the remote destination 181 record the source port of a request along with the source address 182 (and presumably protocol, if not implicit). In addition, the logs at 183 each end must be timestamped, and the clocks must be synchronized 184 within a certain degree of accuracy. Here is one reason for the 185 guard timing on block release, to increase the tolerable level of 186 clock skew between the two ends. 188 The ability to configure various server applications to record source 189 ports has been investigated, with the following results: 191 o Source port recording can be configured in Apache, Postfix, 192 sendmail and sshd. Please refer to the appendix for configuration 193 guide. 195 o Source port recording is not supported by IIS, Cyrus IMAP and UW 196 IMAP. But it should not be too difficult to get Cyrus IMAP and UW 197 IMAP to support it by modifying the source code. 199 Where source port logging can be enabled, this memo strongly urges 200 the operators to do so. Similarly, intrusion detection systems 201 should capture source port as well as source address of suspect 202 packets. 204 In some cases [RFC6269], a server may not record the source port of a 205 connection. To allow traceability, the NAT device needs to record 206 the destination IP address of a connection. As [RFC6269] points out, 207 this will provide an incomplete solution to the issue of traceability 208 because multiple users of the same shared public IP address may 209 access the service at the same time. From the point of view of this 210 draft, in such situations the game is lost, so to speak, and port 211 allocation at the NAT might as well be completely dynamic. 213 The final possibility to consider is where the NAT does not do per- 214 session logging even given the possibility that the remote end is 215 failing to capture source ports. In that case, the port allocation 216 policy proposed in this draft can be used. The impact on 217 traceability is that analysis of the logs would yield only the list 218 of all internal addresses mapped to a given public address during the 219 period of time concerned. This has an impact on privacy as well as 220 traceability, depending on the follow-up actions taken. 222 4. Other Considerations 224 [RFC6269] notes several issues introduced by the use of dynamic as 225 opposed to static port assignment. For example, Section 12.2 of that 226 document notes the effect on authentication procedures. These issues 227 must be resolved, but are not specific to the port allocation policy 228 described in this document. 230 5. IANA Considerations 232 This memo includes no request to IANA. 234 6. Security Considerations 236 The discussion which follows addresses an issue that is particularly 237 relevant to the proposal made in this document. The security 238 considerations applicable to NAT operation for various protocols as 239 documented in, for example, [RFC4787] and [RFC5382] also apply to 240 this proposal. 242 [RFC6056] summarizes the TCP port-guessing attack, by means of which 243 an attacker can hijack one end of a TCP connection. One mitigating 244 measure is to make the source port number used for a TCP connection 245 less predictable. [RFC6056] provides various algorithms for this 246 purpose. 248 As Section 3.1 of that RFC notes: "...provided adequate algorithms 249 are in use, the larger the range from which ephemeral ports are 250 selected, the smaller the chances of an attacker are to guess the 251 selected port number." Conversely, the reduced range sizes proposed 252 by the present document increase the attacker's chances of guessing 253 correctly. This result cannot be totally avoided. However, 254 mitigating measures to improve this situation can be taken both at 255 port block assignment time and when selecting individual ports from 256 the blocks that have been allocated to a given user. 258 At assignment time, one possibility is to assign ports as non- 259 contiguous sets of values as proposed in [RFC6431]. However, this 260 approach creates a lot of complexity for operations, and the pseudo 261 randomization can create uncertainty when the accuracy of logs is 262 important to protect someone's life or liberty. 264 Alternatively, the NAT can assign blocks of contiguous ports. 266 However, at assignment time the NAT could attempt to randomize its 267 choice of which of the available idle blocks it would assign to a 268 given user. This strategy has to be traded off against the 269 desirability of minimizing the chance of conflict between what 270 [RFC6056] calls "transport protocol instances" by assigning the most- 271 idle block, as suggested in Section 2. A compromise policy might be 272 to assign blocks only if they have been idle for a certain amount of 273 time whenever possible, and select pseudorandomly between the blocks 274 available according to this criterion. In this case it is suggested 275 that the time value used be greater than the guard timing mentioned 276 in Section 2, and that no block should ever be reassigned until it 277 has been idle at least for the duration given by the guard timer. 279 While the block assignment strategy can provide some mitigation of 280 the port guessing attack, the largest contribution will come from 281 pseudo randomization at port selection time. [RFC6056] provides a 282 number of algoriths for achieving this pseudorandomization. When the 283 available ports are contained in blocks which are not in general 284 consecutive, the algorithms clearly need some adaptation. The task 285 is complicated by the fact that the number of blocks allocated to the 286 user may vary over time. Adaptation is left as an exercise for the 287 implementor. 289 7. Acknowledgements 291 Mohamed Boucadair reviewed the initial document and provided useful 292 comments to improve it. Reinaldo Penno, Joel Jaeggli, and Dan Wing 293 provided comments on the subsequent version that resulted in major 294 revisions. Serafim Petsis provided encouragement to publication 295 after a hiatus of two years. 297 The authors are grateful to Dan Wing for his help in moving this 298 document forward, and in particular for his helpful comments on its 299 content. 301 8. Appendix A: Configure Server Software to Log Source Port 303 8.1. Apache 305 The user can use LogFormat command to define a customized log format 306 and use CustomLog command to apply that log format. "%a" and 307 "%{remote}p" can be used in the format string to require logging the 308 client's IP address and source port respectively. This feature is 309 available since Apache version 2.1. 311 A detailed configuration guide can be found at [APACHE_LOG_CONFIG]. 313 8.2. Postfix 315 In order to log the client source port, macro 316 smtpd_client_port_logging should be set to "yes" in the configuration 317 file. [POSTFIX_LOG_CONFIG] 319 This feature is available since Postfix version 2.5. 321 8.3. Sendmail 323 Sendmail has a macro ${client_port} storing the client port. To log 324 the source port, the user can define some check rules. Here is an 325 example which should be in the .mc configuration macro 326 [SENDMAIL_LOG_CONFIG]: 328 LOCAL_CONFIG 329 Klog syslog 331 LOCAL_RULESETS 332 SLocal_check_mail 333 R $* $@ $(log Port_Stat $&{client_addr} $&{client_port} $) 335 This feature is available since version 8.10. 337 8.4. sshd 339 SSHD_CONFIG(5) OpenBSD Programmer's Manual SSHD_CONFIG(5) NAME 340 sshd_config - OpenSSH SSH daemon configuration file LogLevel Gives 341 the verbosity level that is used when logging messages from sshd(8). 342 The possible values are: QUIET, FATAL, ERROR, INFO, VERBOSE, DEBUG, 343 DEBUG1, DEBUG2, and DEBUG3. The default is INFO. DEBUG and DEBUG1 344 are equivalent. DEBUG2 and DEBUG3 each specify higher levels of 345 debugging output. Logging with a DEBUG level violates the privacy of 346 users and is not recommended. SyslogFacility Gives the facility code 347 that is used when logging messages from sshd(8). The possible values 348 are: DAEMON, USER, AUTH, LOCAL0, LOCAL1, LOCAL2, LOCAL3, LOCAL4, 349 LOCAL5, LOCAL6, LOCAL7. The default is AUTH. 351 sshd supports logging the client IP address and client port when a 352 client starts connection since version 1.2.2, here is the source code 353 in sshd.c: 355 ... 356 verbose("Connection from %.500s port %d", remote_ip, remote_port); 357 ... 359 sshd supports logging the client IP address when a client 360 disconnects, from version 1.2.2 to version 5.0. Since version 5.1 361 sshd supports logging the client IP address and source port. Here is 362 the source code in sshd.c: 364 ... 365 /* from version 1.2.2 to 5.0*/ 366 verbose("Closing connection to %.100s", remote_ip); 367 ... 369 /* since version 5.1*/ 370 verbose("Closing connection to %.500s port %d", 371 remote_ip, remote_port); 373 In order to log the source port, the LogLevel should be set to 374 VERBOSE [SSHD_LOG_CONFIG] in the configuration file: 376 LogLevel VERBOSE 378 8.5. Cyrus IMAP and UW IMAP 380 Cyrus IMAP and UW IMAP do not support logging the source port for the 381 time being. Both software use syslog to create logs; it should not 382 be too difficult to get it supported by adding some new code. 384 9. Informative References 386 [APACHE_LOG_CONFIG] 387 The Apache Software Foundation, 388 "http://httpd.apache.org/docs/2.4/mod/ 389 mod_log_config.html", 2013. 391 [I-D.ietf-sunset4-nat64-port-allocation] 392 Chen, G., Li, W., Tsou, T., Huang, J., Taylor, T., and J. 393 Tremblay, "Analysis of NAT64 Port Allocation Methods for 394 Shared IPv4 Addresses", 395 draft-ietf-sunset4-nat64-port-allocation-01 (work in 396 progress), July 2015. 398 [POSTFIX_LOG_CONFIG] 399 "http://www.postfix.org/postconf.5.html", 2013. 401 [RFC4787] Audet, F., Ed. and C. Jennings, "Network Address 402 Translation (NAT) Behavioral Requirements for Unicast 403 UDP", BCP 127, RFC 4787, DOI 10.17487/RFC4787, 404 January 2007, . 406 [RFC5382] Guha, S., Ed., Biswas, K., Ford, B., Sivakumar, S., and P. 407 Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, 408 RFC 5382, DOI 10.17487/RFC5382, October 2008, 409 . 411 [RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport- 412 Protocol Port Randomization", BCP 156, RFC 6056, 413 DOI 10.17487/RFC6056, January 2011, 414 . 416 [RFC6269] Ford, M., Ed., Boucadair, M., Durand, A., Levis, P., and 417 P. Roberts, "Issues with IP Address Sharing", RFC 6269, 418 DOI 10.17487/RFC6269, June 2011, 419 . 421 [RFC6431] Boucadair, M., Levis, P., Bajko, G., Savolainen, T., and 422 T. Tsou, "Huawei Port Range Configuration Options for PPP 423 IP Control Protocol (IPCP)", RFC 6431, DOI 10.17487/ 424 RFC6431, November 2011, 425 . 427 [RFC6888] Perreault, S., Ed., Yamagata, I., Miyakawa, S., Nakagawa, 428 A., and H. Ashida, "Common Requirements for Carrier-Grade 429 NATs (CGNs)", BCP 127, RFC 6888, DOI 10.17487/RFC6888, 430 April 2013, . 432 [SENDMAIL_LOG_CONFIG] 433 O'Reilly, "Sendmail, 3rd Edition, Page 798", 434 December 2002. 436 [SSHD_LOG_CONFIG] 437 "http://www.openbsd.org/cgi-bin/ 438 man.cgi?query=sshd_config&sektion=5", April 2013. 440 Authors' Addresses 442 Tina Tsou 443 Huawei Technologies (USA) 444 2330 Central Expressway 445 Santa Clara, CA 95050 446 USA 448 Phone: +1 408 330 4424 449 Email: tina.tsou.zouting@huawei.com 450 Weibo Li 451 China Telecom 452 109, Zhongshan Ave. West, Tianhe District 453 Guangzhou 510630 454 P.R. China 456 Phone: 457 Email: mweiboli@gmail.com 459 Tom Taylor 460 Huawei Technologies 461 Ottawa 462 Canada 464 Phone: 465 Email: tom.taylor.stds@gmail.com 467 James Huang 468 Huawei Technologies 469 Bantian, Longgang District 470 Shenzhen 518129 471 P.R. China 473 Phone: 474 Email: James.huang@huawei.com