idnits 2.17.1 draft-tsou-behave-natx4-log-reduction-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 : ---------------------------------------------------------------------------- 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 (September 30, 2010) is 4957 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 information found for draft-softwire-dual-stack-lite - is the name correct? Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Behavior Engineering for Hindrance T. Tsou, Ed. 3 Avoidance Huawei Technologies 4 Internet-Draft W. Li, Ed. 5 Intended status: Informational China Telecom 6 Expires: April 3, 2011 T. Taylor 7 Huawei Technologies 8 September 30, 2010 10 Port Management To Reduce Logging In Large-Scale NATs 11 draft-tsou-behave-natx4-log-reduction-02 13 Abstract 15 Various IPv6 transition strategies require the introduction of large 16 -scale NATs (e.g. AFTR, NAT64) to share the limited supply of IPv4 17 addresses available in the network until transition is complete. 18 There has recently been debate over how to manage the sharing of 19 ports between different subscribers sharing the same IPv4 address. 20 One factor in the discussion is the operational requirement to log 21 the assignment of transport addresses to subscribers. It has been 22 argued that dynamic assignment of individual ports between 23 subscribers requires the generation of an excessive volume of logs. 24 This document suggests a way to achieve dynamic port sharing while 25 keeping log volumes low. 27 Status of this Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on April 3, 2011. 44 Copyright Notice 46 Copyright (c) 2010 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 63 2. A Suggested Solution . . . . . . . . . . . . . . . . . . . . . 3 64 3. Issues Of Traceability . . . . . . . . . . . . . . . . . . . . 5 65 4. Other Considerations . . . . . . . . . . . . . . . . . . . . . 7 66 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 67 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 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. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 76 9.1. Normative References . . . . . . . . . . . . . . . . . . . 9 77 9.2. Informative References . . . . . . . . . . . . . . . . . . 9 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 80 1. Introduction 82 During the IPv6 transition period, some large-scale NAT devices may 83 be introduced, e.g. DS-Lite AFTR, NAT64. When a NAT device needs to 84 set up a new connection for a given internal address behind the NAT, 85 it needs to create a new mapping entry for the new connection, which 86 will contain source IP address, source port, converted source IP 87 address, converted source port, protocol (TCP/UDP), etc. If the 88 connection is ICMP, a mapping entry may include source IP address, 89 converted source IP address, source identifier, converted source 90 identifier, etc. 92 For the purpose of troubleshooting, and also as required by 93 regulations, operators must keep logs of network NAT mapping entries 94 for a period of time, e.g. 6 months or one year 95 [I-D.ietf-intarea-shared-addressing-issues], so the NAT device needs 96 to generate logs for mapping entries in addition to other 97 information. A traditional method is to generate a log for each 98 mapping entry. When a connection expires, the mapping entry will be 99 deleted, and the corresponding log is stored locally or sent to a log 100 storage server. 102 Some high performance NAT devices may need to create a large amount 103 of new sessions per second. If logs are generated for each mapping 104 entry, the log traffic could reach tens of megabytes per second or 105 more, which would be a problem for log generation, transmission and 106 storage. 108 To reduce the cost of log storage, [I-D.nishitani-cgn] proposes to 109 fix the port range for each user/CPE, and only one log will be 110 generated for each user. But this would significantly reduce the 111 number of subscribers that could share a public IP address, as 112 discussed in [I-D.softwire-dual-stack-lite]. 114 1.1. Requirements Language 116 This draft includes no requirements language. 118 2. A Suggested Solution 120 We propose a solution that allows dynamic sharing of port ranges 121 between users while minimizing the number of logs that have to be 122 generated. Briefly, ports are allocated to the user in blocks. Logs 123 are generated only when blocks are allocated or deallocated. This 124 provides the necessary traceability while reducing log generation by 125 a factor equal to the block size, as compared with fully dynamic port 126 allocation. 128 Here is how the proposal would work in greater detail. When the user 129 sends out the first packet, a port resource pool is allocated for the 130 user, e.g. assign ports 2001~2300 of a public IP address to the 131 user's resource pool. Only one log should be generated for this port 132 block. When the NAT needs to set up a new mapping entry for the 133 user, it can use a port in the user's resource pool and the 134 corresponding public IP address. If the user needs more port 135 resources, the NAT can allocate another port block, ports 3501~3800, 136 to the user's resource pool. Again , just one log needs to be 137 generated for this port block. A log may contain the following 138 information: source IP address, converted source IP address, port 139 range, start time, end time, and some other necessary information. 141 There is an alternative way of allocating port blocks 142 [I-D.bajko-pripaddrassign]. The ports in a block do not have to be 143 contiguous. Due to security concerns, the port numbers could be 144 worked out using some random algorithm along with some initial 145 parameters. The randomization algorithm would be applied at the NAT 146 when it generates a new mapping. The algorithm and initial 147 parameters together are required to define a discrete subset of the 148 entire available port range (1024 to 65335), such that it is possible 149 to assign the complete range to different internal addresses as 150 required by varying the initial parameters. When generating a log 151 message, these parameters instead of the upper and lower bounds of a 152 port range would be included in the log. 154 Suppose now that a given internal address has been assigned more than 155 one block of ports. Regardless of whether the ports within a block 156 are specified by a simple range or a random algorithm, it is clear 157 that the overall preference for port randomization will be better 158 achieved by spreading out new port assignments over all of the blocks 159 assigned to that internal address. That means that the NAT should 160 first select one of the assigned blocks pseudo-randomly before 161 applying any randomization algorithm within the block. Further 162 discussion of this point occurs below as part of the discussion of 163 block deallocation. 165 The individual sessions using ports within a port block will start 166 and end at different times. If no ports in some port block are used 167 for some configurable time, the NAT can remove the port block from 168 the resource pool allocated to a given internal address, and make it 169 available for other users. The deallocation may be logged when it 170 occurs, although some would view such logging as redundant. 172 The deallocation procedure presents a number of difficulties in 173 practice. The first problem is the choice of timeout value for the 174 block. If idle timers are applied for the individual mappings 175 (sessions) within the block, and these conform to the recommendations 176 for NAT behaviour for the protocol concerned, then the additional 177 time that might be configured as a guard for the block as a whole 178 need not be more than a few minutes. The block timer in this case 179 serves only as a slightly more conservative extension of the 180 individual session idle timers. If, instead, a single idle timer is 181 used for the whole block, it must itself conform to the 182 recommendations for the protocol with which that block of ports is 183 associated. For example, REQ-5 of [RFC5382] requires an idle timer 184 expiry duration of at least 2 hours and 4 minutes. 186 The next issue with port block deallocation is the conflict between 187 the desire to randomize port allocation and the desire to make unused 188 resources available to other internal addresses. As mentioned above, 189 ideally port selection will take place over the entire set of blocks 190 allocated to the internal address. However, taken to its fullest 191 extent, such a policy will minimize the probability that all ports in 192 any given block are idle long enough for it to be released. As an 193 alternative, it is suggested that when choosing which block to select 194 a port from, the NAT should omit from its range of choice the block 195 that has been idle the longest, unless no ports are available in any 196 of the other blocks. The expression "block that has been idle the 197 longest" designates the block in which the time since the last packet 198 was observed in any of its sessions, in either direction, is earlier 199 than the corresponding time in any of the other blocks assigned to 200 that internal address. As 201 [I-D.ietf-intarea-shared-addressing-issues] points out, port 202 randomization is just one security measure of several, and the loss 203 of randomness incurred by the suggested procedure is justified by the 204 increased utilization of port resources it allows. 206 3. Issues Of Traceability 208 The whole point of this proposal is to allow the NAT to support 209 regulatory requirements for traceability of usage. So it is only 210 right to verify that these requirements can be met with the proposal 211 made in the previous section. There are two cases: 213 1. the investigating authority requires a complete record of the 214 activities of a target individual; 216 2. the investigating authority is concerned with tracking down the 217 user responsible for wrongful behaviour at a specific end point 218 (e.g., server, individual user, enterpise network). 220 Assuming that per-sesssion logging at the NAT is to be avoided in 221 general (the whole point of this draft), the first requirement can 222 only be met by identifying a target device in advance and enabling 223 per-session logging for the internal address assigned to that device 224 (... and variations for multi-address situations). This case is 225 basically out of scope of the draft. 227 Section 11 of [I-D.ietf-intarea-shared-addressing-issues] provides a 228 good discussion of the traceability issue. Complete traceability 229 given the NAT logging practices proposed in this draft requires that 230 the remote destination record the source port of a request along with 231 the source address (and presumably protocol, if not implicit). In 232 addition, the logs at each end must be timestamped, and the clocks 233 must be synchronized within a certain degree of accuracy. Here is 234 one reason for the guard timing on block release, to increase the 235 tolerable level of clock skew between the two ends. 237 The ability to configure various server applications to record source 238 ports has been investigated, with the following results: 240 o Source port recording can be configured in Apache, Postfix, 241 sendmail and sshd. Please refer to the appendix for configuration 242 guide. 244 o Source port recording is not supported by IIS, Cyrus IMAP and UW 245 IMAP. But it should not be too difficult to get Cyrus IMAP and UW 246 IMAP to support it by modifying the source code. 248 Where source port logging can be enabled, this memo strongly urges 249 the operators to do so. Similarly, intrusion detection systems 250 should capture source port as well as source address of suspect 251 packets. 253 In some cases [I-D.ietf-intarea-shared-addressing-issues], a server 254 may not record the source port of a connection. To allow 255 traceability, the NAT device needs to record the destination IP 256 address of a connection. As 257 [I-D.ietf-intarea-shared-addressing-issues] points out, this will 258 provide an incomplete solution to the issue of traceability because 259 multiple users of the same shared public IP address may access the 260 service at the same time. From the point of view of this draft, in 261 such situations the game is lost, so to speak, and port allocation at 262 the NAT might as well be completely dynamic. 264 The final possibility to consider is where the NAT does not do per- 265 session logging even given the possibility that the remote end is 266 failing to capture source ports. In that case, the port allocation 267 policy proposed in this draft can be used. The impact on 268 traceability is that the investigating authority would be able to 269 collect only the list of all internal addresses mapped to a given 270 public address during the period of time concerned. This has an 271 impact on privacy as well as traceability, depending on the follow-up 272 actions taken by the investigating authority to achieve its 273 objectives. 275 4. Other Considerations 277 [I-D.ietf-intarea-shared-addressing-issues] notes several issues 278 introduced by the use of dynamic as opposed to static port 279 assignment. For example, Section 12.2 of that document notes the 280 effect on authentication procedures. These issues must be resolved, 281 but are not specific to the port allocation policy described in this 282 document. 284 5. IANA Considerations 286 This memo includes no request to IANA. 288 6. Security Considerations 290 The security considerations applicable to NAT operation for various 291 protocols as documented in, for example, [RFC4787] and [RFC5382] also 292 apply to this proposal. 294 7. Acknowledgements 296 Mohamed Boucadair reviewed the initial document and provided useful 297 comments to improve it. Reinaldo Penno, Joel Jaegli, and Dan Wing 298 provided comments on the subsequent version that resulted in major 299 revisions. 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 Detail 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 326 macro[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 supports logging the client IP address and client port when a 340 client starts connection since version 1.2.2, here is the source code 341 in sshd.c: 343 ... 344 verbose("Connection from %.500s port %d", remote_ip, remote_port); 345 ... 347 sshd supports logging the client IP address when a client disconnect 348 from version 1.2.2 to version 5.0. since version 5.1 sshd supports 349 logging the client IP address and source port. Here is the source 350 code in sshd.c: 352 ... 353 /* from version 1.2.2 to 5.0*/ 354 verbose("Closing connection to %.100s", remote_ip); 355 ... 357 /* since version 5.1*/ 358 verbose("Closing connection to %.500s port %d", 359 remote_ip, remote_port); 360 In order to log the source port, the LogLevel should be set to 361 VERBOSE [SSHD_LOG_CONFIG] in the configuration file: 363 LogLevel VERBOSE 365 8.5. Cyrus IMAP and UW IMAP 367 Cyrus IMAP and UW IMAP do not support logging the source port for the 368 time being. Both software use syslog to create logs; it should not 369 be too difficult to get it supported by adding some new code. 371 9. References 373 9.1. Normative References 375 [I-D.bajko-pripaddrassign] 376 Bajko, G., Savolainen, T., Boucadair, M., and P. Levis, 377 "Port Restricted IP Address Assignment (Work in 378 progress)", October 2009. 380 [I-D.ietf-intarea-shared-addressing-issues] 381 Ford, M., Boucadair, M., Durand, A., Levis, P., and P. 382 Roberts, "Issues with IP Address Sharing (Work in 383 progress)", June 2010. 385 9.2. Informative References 387 [APACHE_LOG_CONFIG] 388 "http://httpd.apache.org/docs/2.1/mod/ 389 mod_log_config.html". 391 [I-D.nishitani-cgn] 392 Yamagata, I., Miyakawa, S., Nakagawa, A., and H. Ashida, 393 "Common requirements for IP address sharing schemes (Work 394 in progress)", July 2010. 396 [I-D.softwire-dual-stack-lite] 397 Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 398 Stack Lite Broadband Deployments Following IPv4 Exhaustion 399 (Work in progress)", July 2010. 401 [POSTFIX_LOG_CONFIG] 402 "http://www.postfix.org/postconf.5.html". 404 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 405 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 406 RFC 4787, January 2007. 408 [RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. 409 Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, 410 RFC 5382, October 2008. 412 [SENDMAIL_LOG_CONFIG] 413 O'Reilly, "Sendmail, 3rd Edition, Page 798", 414 December 2002. 416 [SSHD_LOG_CONFIG] 417 "http://www.openbsd.org/cgi-bin/ 418 man.cgi?query=sshd_config&sektion=5". 420 Authors' Addresses 422 Tina Tsou (editor) 423 Huawei Technologies 424 Bantian, Longgang District 425 Shenzhen 518129 426 P.R. China 428 Phone: 429 Email: tena@huawei.com 431 Weibo Li (editor) 432 China Telecom 433 109, Zhongshan Ave. West, Tianhe District 434 Guangzhou 510630 435 P.R. China 437 Phone: 438 Email: mweiboli@gmail.com 440 Tom Taylor 441 Huawei Technologies 442 1852 Lorraine Ave. 443 Ottawa K1H 6Z8 444 Canada 446 Phone: 447 Email: tom111.taylor@bell.net