idnits 2.17.1 draft-tsou-behave-natx4-log-reduction-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 03, 2013) is 3949 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 ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Behavior Engineering for Hindrance Avoidance T. Tsou 3 Internet-Draft Huawei Technologies (USA) 4 Intended status: Informational W. Li 5 Expires: January 04, 2014 China Telecom 6 T. Taylor 7 J. Huang 8 Huawei Technologies 9 July 03, 2013 11 Port Management To Reduce Logging In Large-Scale NATs 12 draft-tsou-behave-natx4-log-reduction-04 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 January 04, 2014. 45 Copyright Notice 47 Copyright (c) 2013 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 63 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 64 2. A Suggested Solution . . . . . . . . . . . . . . . . . . . . 3 65 3. Issues Of Traceability . . . . . . . . . . . . . . . . . . . 4 66 4. Other Considerations . . . . . . . . . . . . . . . . . . . . 5 67 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 68 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 69 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 70 8. Appendix A: Configure Server Software to Log Source Port . . 7 71 8.1. Apache . . . . . . . . . . . . . . . . . . . . . . . . . 7 72 8.2. Postfix . . . . . . . . . . . . . . . . . . . . . . . . . 7 73 8.3. Sendmail . . . . . . . . . . . . . . . . . . . . . . . . 7 74 8.4. sshd . . . . . . . . . . . . . . . . . . . . . . . . . . 8 75 8.5. Cyrus IMAP and UW IMAP . . . . . . . . . . . . . . . . . 9 76 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 77 9.1. Normative References . . . . . . . . . . . . . . . . . . 9 78 9.2. Informative References . . . . . . . . . . . . . . . . . 9 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 81 1. Introduction 83 During the IPv6 transition period, some large-scale NAT devices may 84 be introduced, e.g. DS-Lite AFTR, NAT64. When a NAT device needs to 85 set up a new connection for a given internal address behind the NAT, 86 it needs to create a new mapping entry for the new connection, which 87 will contain source IP address, source port or ICMP identifier, 88 converted source IP address, converted source port, protocol (TCP/ 89 UDP), etc. 91 For various reasons it is necessary to log these mappings. 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. 98 [RFC6888], REQ-13, REQ-14, and REQ-15 deal explicitly with port 99 allocation schemes. However, it is recognized that these are 100 conflicting requirements, requiring a tradeoff between the efficiency 101 with which ports are used and the rate of generation of log records. 103 1.1. Requirements Language 105 This draft includes no requirements language. 107 2. A Suggested Solution 109 This document proposes a solution that allows dynamic sharing of port 110 ranges between users while minimizing the number of logs that have to 111 be generated. Briefly, ports are allocated to the user in blocks. 112 Logs are generated only when blocks are allocated or deallocated. 113 This provides the necessary traceability while reducing log 114 generation by a factor equal to the block size, as compared with 115 fully dynamic port allocation. 117 Here is how the proposal would work in greater detail. When the user 118 sends out the first packet, a port resource pool is allocated for the 119 user, e.g., assigning ports 2001~2300 of a public IP address to the 120 user's resource pool. Only one log should be generated for this port 121 block. When the NAT needs to set up a new mapping entry for the 122 user, it can use a port in the user's resource pool and the 123 corresponding public IP address. If the user needs more port 124 resources, the NAT can allocate another port block, e.g., ports 125 3501~3800, to the user's resource pool. Again, just one log needs to 126 be generated for this port block. 128 [I-D.bajko-pripaddrassign] takes this idea further by allocating non- 129 contiguous sets of ports using a pseudorandom function. Scattering 130 the allocated ports in this way provides a modest barrier to port 131 guessing attacks. The use of randomization is discussed further in 132 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. As [RFC6269] points out, port 175 randomization is just one security measure of several, and the loss 176 of randomness incurred by the suggested procedure is justified by the 177 increased utilization of port resources it allows. 179 3. Issues Of Traceability 181 Section 11 of [RFC6269] provides a good discussion of the 182 traceability issue. Complete traceability given the NAT logging 183 practices proposed in this draft requires that the remote destination 184 record the source port of a request along with the source address 185 (and presumably protocol, if not implicit). In addition, the logs at 186 each end must be timestamped, and the clocks must be synchronized 187 within a certain degree of accuracy. Here is one reason for the 188 guard timing on block release, to increase the tolerable level of 189 clock skew between the two ends. 191 The ability to configure various server applications to record source 192 ports has been investigated, with the following results: 194 o Source port recording can be configured in Apache, Postfix, 195 sendmail and sshd. Please refer to the appendix for configuration 196 guide. 198 o Source port recording is not supported by IIS, Cyrus IMAP and UW 199 IMAP. But it should not be too difficult to get Cyrus IMAP and UW 200 IMAP to support it by modifying the source code. 202 Where source port logging can be enabled, this memo strongly urges 203 the operators to do so. Similarly, intrusion detection systems 204 should capture source port as well as source address of suspect 205 packets. 207 In some cases [RFC6269], a server may not record the source port of a 208 connection. To allow traceability, the NAT device needs to record 209 the destination IP address of a connection. As [RFC6269] points out, 210 this will provide an incomplete solution to the issue of traceability 211 because multiple users of the same shared public IP address may 212 access the service at the same time. From the point of view of this 213 draft, in such situations the game is lost, so to speak, and port 214 allocation at the NAT might as well be completely dynamic. 216 The final possibility to consider is where the NAT does not do per- 217 session logging even given the possibility that the remote end is 218 failing to capture source ports. In that case, the port allocation 219 policy proposed in this draft can be used. The impact on 220 traceability is that analysis of the logs would yield only the list 221 of all internal addresses mapped to a given public address during the 222 period of time concerned. This has an impact on privacy as well as 223 traceability, depending on the follow-up actions taken. 225 4. Other Considerations 227 [RFC6269] notes several issues introduced by the use of dynamic as 228 opposed to static port assignment. For example, Section 12.2 of that 229 document notes the effect on authentication procedures. These issues 230 must be resolved, but are not specific to the port allocation policy 231 described in this document. 233 5. IANA Considerations 235 This memo includes no request to IANA. 237 6. Security Considerations 239 The discussion which follows addresses an issue that is particularly 240 relevant to the proposal made in this document. The security 241 considerations applicable to NAT operation for various protocols as 242 documented in, for example, [RFC4787] and [RFC5382] also apply to 243 this proposal. 245 [RFC6056] summarizes the TCP port-guessing attack, by means of which 246 an attacker can hijack one end of a TCP connection. One mitigating 247 measure is to make the source port number used for a TCP connection 248 less predictable. [RFC6056] provides various algorithms for this 249 purpose. 251 As Section 3.1 of that RFC notes: "...provided adequate algorithms 252 are in use, the larger the range from which ephemeral ports are 253 selected, the smaller the chances of an attacker are to guess the 254 selected port number." Conversely, the reduced range sizes proposed 255 by the present document increase the attacker's chances of guessing 256 correctly. This result cannot be totally avoided. However, 257 mitigating measures to improve this situation can be taken both at 258 port block assignment time and when selecting individual ports from 259 the blocks that have been allocated to a given user. 261 At assignment time, one possibility is to assign ports as non- 262 contiguous sets of values as proposed in [I-D.bajko-pripaddrassign]. 263 However, this approach creates a lot of complexity for operations, 264 and the pseudo randomization can create uncertainty when the accuracy 265 of logs is important to protect someone's life or liberty. 267 Alternatively, the NAT can assign blocks of contiguous ports. 268 However, at assignment time the NAT could attempt to randomize its 269 choice of which of the available idle blocks it would assign to a 270 given user. This strategy has to be traded off against the 271 desirability of minimizing the chance of conflict between what 272 [RFC6056] calls "transport protocol instances" by assigning the most- 273 idle block, as suggested in Section 2. A compromise policy might be 274 to assign blocks only if they have been idle for a certain amount of 275 time whenever possible, and select pseudorandomly between the blocks 276 available according to this criterion. In this case it is suggested 277 that the time value used be greater than the guard timing mentioned 278 in Section 2, and that no block should ever be reassigned until it 279 has been idle at least for the duration given by the guard timer. 281 While the block assignment strategy can provide some mitigation of 282 the port guessing attack, the largest contribution will come from 283 pseudo randomization at port selection time. [RFC6056] provides a 284 number of algoriths for achieving this pseudorandomization. When the 285 available ports are contained in blocks which are not in general 286 consecutive, the algorithms clearly need some adaptation. The task 287 is complicated by the fact that the number of blocks allocated to the 288 user may vary over time. Adaptation is left as an exercise for the 289 implementor. 291 7. Acknowledgements 293 Mohamed Boucadair reviewed the initial document and provided useful 294 comments to improve it. Reinaldo Penno, Joel Jaeggli, and Dan Wing 295 provided comments on the subsequent version that resulted in major 296 revisions. Serafim Petsis provided encouragement to publication 297 after a hiatus of two years. 299 The authors are grateful to Dan Wing for his help in moving this 300 document forward, and in particular for his helpful comments on its 301 content. 303 8. Appendix A: Configure Server Software to Log Source Port 305 8.1. Apache 307 The user can use LogFormat command to define a customized log format 308 and use CustomLog command to apply that log format. "%a" and 309 "%{remote}p" can be used in the format string to require logging the 310 client's IP address and source port respectively. This feature is 311 available since Apache version 2.1. 313 A detailed configuration guide can be found at [APACHE_LOG_CONFIG]. 315 8.2. Postfix 317 In order to log the client source port, macro 318 smtpd_client_port_logging should be set to "yes" in the configuration 319 file. [POSTFIX_LOG_CONFIG] 321 This feature is available since Postfix version 2.5. 323 8.3. Sendmail 325 Sendmail has a macro ${client_port} storing the client port. To log 326 the source port, the user can define some check rules. Here is an 327 example which should be in the .mc configuration macro 328 [SENDMAIL_LOG_CONFIG]: 330 LOCAL_CONFIG 331 Klog syslog 332 LOCAL_RULESETS 333 SLocal_check_mail 334 R $* $@ $(log Port_Stat $&{client_addr} $&{client_port} $) 336 This feature is available since version 8.10. 338 8.4. sshd 340 SSHD_CONFIG(5) OpenBSD Programmer's Manual SSHD_CONFIG(5) NAME 341 sshd_config - OpenSSH SSH daemon configuration file LogLevel Gives 342 the verbosity level that is used when logging messages from sshd(8). 343 The possible values are: QUIET, FATAL, ERROR, INFO, VERBOSE, DEBUG, 344 DEBUG1, DEBUG2, and DEBUG3. The default is INFO. DEBUG and DEBUG1 345 are equivalent. DEBUG2 and DEBUG3 each specify higher levels of 346 debugging output. Logging with a DEBUG level violates the privacy of 347 users and is not recommended. SyslogFacility Gives the facility code 348 that is used when logging messages from sshd(8). The possible values 349 are: DAEMON, USER, AUTH, LOCAL0, LOCAL1, LOCAL2, LOCAL3, LOCAL4, 350 LOCAL5, LOCAL6, LOCAL7. The default is AUTH. 352 sshd supports logging the client IP address and client port when a 353 client starts connection since version 1.2.2, here is the source code 354 in sshd.c: 356 ... 357 verbose("Connection from %.500s port %d", remote_ip, remote_port); 358 ... 360 sshd supports logging the client IP address when a client 361 disconnects, from version 1.2.2 to version 5.0. Since version 5.1 362 sshd supports logging the client IP address and source port. Here is 363 the source code in sshd.c: 365 ... 366 /* from version 1.2.2 to 5.0*/ 367 verbose("Closing connection to %.100s", remote_ip); 368 ... 370 /* since version 5.1*/ 371 verbose("Closing connection to %.500s port %d", 372 remote_ip, remote_port); 374 In order to log the source port, the LogLevel should be set to 375 VERBOSE [SSHD_LOG_CONFIG] in the configuration file: 377 LogLevel VERBOSE 379 8.5. Cyrus IMAP and UW IMAP 381 Cyrus IMAP and UW IMAP do not support logging the source port for the 382 time being. Both software use syslog to create logs; it should not 383 be too difficult to get it supported by adding some new code. 385 9. References 387 9.1. Normative References 389 [RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport- 390 Protocol Port Randomization", BCP 156, RFC 6056, January 391 2011. 393 [RFC6269] Ford, M., Boucadair, M., Durand, A., Levis, P., and P. 394 Roberts, "Issues with IP Address Sharing", RFC 6269, June 395 2011. 397 9.2. Informative References 399 [APACHE_LOG_CONFIG] 400 The Apache Software Foundation, 401 "http://httpd.apache.org/docs/2.4/mod/mod_log_config.html 402 ", 2013. 404 [I-D.bajko-pripaddrassign] 405 Bajko, G., Savolainen, T., Boucadair, M., and P. Levis, 406 "Port Restricted IP Address Assignment (Work in 407 progress)", April 2012. 409 [POSTFIX_LOG_CONFIG] 410 , "http://www.postfix.org/postconf.5.html ", 2013. 412 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 413 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 414 RFC 4787, January 2007. 416 [RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. 417 Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, 418 RFC 5382, October 2008. 420 [RFC6888] Perreault, S., Yamagata, I., Miyakawa, S., Nakagawa, A., 421 and H. Ashida, "Common Requirements for Carrier-Grade NATs 422 (CGNs)", BCP 127, RFC 6888, April 2013. 424 [SENDMAIL_LOG_CONFIG] 425 O'Reilly, "Sendmail, 3rd Edition, Page 798", December 426 2002. 428 [SSHD_LOG_CONFIG] 429 , "http://www.openbsd.org/cgi-bin/ 430 man.cgi?query=sshd_config&sektion=5", April 2013. 432 Authors' Addresses 434 Tina Tsou 435 Huawei Technologies (USA) 436 2330 Central Expressway 437 Santa Clara, CA 95050 438 USA 440 Phone: +1 408 330 4424 441 Email: tina.tsou.zouting@huawei.com 443 Weibo Li 444 China Telecom 445 109, Zhongshan Ave. West, Tianhe District 446 Guangzhou 510630 447 P.R. China 449 Email: mweiboli@gmail.com 451 Tom Taylor 452 Huawei Technologies 453 Ottawa 454 Canada 456 Email: tom.taylor.stds@gmail.com 458 James Huang 459 Huawei Technologies 460 Bantian, Longgang District 461 Shenzhen 518129 462 P.R. China 464 Email: James.huang@huawei.com