idnits 2.17.1 draft-tsou-behave-natx4-log-reduction-03.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 (May 10, 2013) is 4002 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-behave-lsn-requirements - 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 Avoidance T. Tsou 3 Internet-Draft Huawei Technologies (USA) 4 Intended status: Informational W. Li 5 Expires: November 11, 2013 China Telecom 6 T. Taylor 7 Huawei Technologies 8 May 10, 2013 10 Port Management To Reduce Logging In Large-Scale NATs 11 draft-tsou-behave-natx4-log-reduction-03 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 November 11, 2013. 44 Copyright Notice 46 Copyright (c) 2013 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 62 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . . . . . 7 72 8.3. Sendmail . . . . . . . . . . . . . . . . . . . . . . . . 7 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 [RFC6269], so the 95 NAT device needs to generate logs for mapping entries in addition to 96 other information. A traditional method is to generate a log for 97 each mapping entry. When a connection expires, the mapping entry 98 will be deleted, and the corresponding log is stored locally or sent 99 to a log storage server. 101 Some high performance NAT devices may need to create a large amount 102 of new sessions per second. If logs are generated for each mapping 103 entry, the log traffic could reach tens of megabytes per second or 104 more, which would be a problem for log generation, transmission and 105 storage. 107 [I-D.behave-lsn-requirements], REQ-13, REQ-14, and REQ-15 deal 108 explicitly with port allocation schemes. However, it is recognized 109 that these are conflicting requirements, requiring a tradeoff between 110 the efficiency with which ports are used and the rate of generation 111 of log records. 113 1.1. Requirements Language 115 This draft includes no requirements language. 117 2. A Suggested Solution 119 We propose a solution that allows dynamic sharing of port ranges 120 between users while minimizing the number of logs that have to be 121 generated. Briefly, ports are allocated to the user in blocks. Logs 122 are generated only when blocks are allocated or deallocated. This 123 provides the necessary traceability while reducing log generation by 124 a factor equal to the block size, as compared with fully dynamic port 125 allocation. 127 Here is how the proposal would work in greater detail. When the user 128 sends out the first packet, a port resource pool is allocated for the 129 user, e.g. assign ports 2001~2300 of a public IP address to the 130 user's resource pool. Only one log should be generated for this port 131 block. When the NAT needs to set up a new mapping entry for the 132 user, it can use a port in the user's resource pool and the 133 corresponding public IP address. If the user needs more port 134 resources, the NAT can allocate another port block, ports 3501~3800, 135 to the user's resource pool. Again , just one log needs to be 136 generated for this port block. A log may contain the following 137 information: source IP address, converted source IP address, port 138 range, start time, end time, and some other necessary information. 140 There is an alternative way of allocating port blocks 141 [I-D.bajko-pripaddrassign]. The ports in a block do not have to be 142 contiguous. Due to security concerns, the port numbers could be 143 worked out using some random algorithm along with some initial 144 parameters. The randomization algorithm would be applied at the NAT 145 when it generates a new mapping. The algorithm and initial 146 parameters together are required to define a discrete subset of the 147 entire available port range (1024 to 65335), such that it is possible 148 to assign the complete range to different internal addresses as 149 required by varying the initial parameters. When generating a log 150 message, these parameters instead of the upper and lower bounds of a 151 port range would be included in the log. 153 Suppose now that a given internal address has been assigned more than 154 one block of ports. Regardless of whether the ports within a block 155 are specified by a simple range or a random algorithm, it is clear 156 that the overall preference for port randomization will be better 157 achieved by spreading out new port assignments over all of the blocks 158 assigned to that internal address. That means that the NAT should 159 first select one of the assigned blocks pseudo-randomly before 160 applying any randomization algorithm within the block. Further 161 discussion of this point occurs below as part of the discussion of 162 block deallocation. 164 The individual sessions using ports within a port block will start 165 and end at different times. If no ports in some port block are used 166 for some configurable time, the NAT can remove the port block from 167 the resource pool allocated to a given internal address, and make it 168 available for other users. The deallocation may be logged when it 169 occurs, although some would view such logging as redundant. 171 The deallocation procedure presents a number of difficulties in 172 practice. The first problem is the choice of timeout value for the 173 block. If idle timers are applied for the individual mappings 174 (sessions) within the block, and these conform to the recommendations 175 for NAT behaviour for the protocol concerned, then the additional 176 time that might be configured as a guard for the block as a whole 177 need not be more than a few minutes. The block timer in this case 178 serves only as a slightly more conservative extension of the 179 individual session idle timers. If, instead, a single idle timer is 180 used for the whole block, it must itself conform to the 181 recommendations for the protocol with which that block of ports is 182 associated. For example, REQ-5 of [RFC5382] requires an idle timer 183 expiry duration of at least 2 hours and 4 minutes for TCP. 185 The next issue with port block deallocation is the conflict between 186 the desire to randomize port allocation and the desire to make unused 187 resources available to other internal addresses. As mentioned above, 188 ideally port selection will take place over the entire set of blocks 189 allocated to the internal address. However, taken to its fullest 190 extent, such a policy will minimize the probability that all ports in 191 any given block are idle long enough for it to be released. 193 As an alternative, it is suggested that when choosing which block to 194 select a port from, the NAT should omit from its range of choice the 195 block that has been idle the longest, unless no ports are available 196 in any of the other blocks. The expression "block that has been idle 197 the longest" designates the block in which the time since the last 198 packet was observed in any of its sessions, in either direction, is 199 earlier than the corresponding time in any of the other blocks 200 assigned to that internal address. As [RFC6269] points out, port 201 randomization is just one security measure of several, and the loss 202 of randomness incurred by the suggested procedure is justified by the 203 increased utilization of port resources it allows. 205 3. Issues Of Traceability 207 The whole point of this proposal is to allow the NAT to support 208 regulatory requirements for traceability of usage. So it is only 209 right to verify that these requirements can be met with the proposal 210 made in the previous section. There are two cases: 212 1. the investigating authority requires a complete record of the 213 activities of a target individual; 215 2. the investigating authority is concerned with tracking down the 216 user responsible for wrongful behaviour at a specific end point 217 (e.g., server, individual user, enterprise network). 219 Assuming that per-session logging at the NAT is to be avoided in 220 general (the whole point of this document), the first requirement can 221 only be met by identifying a target device in advance and enabling 222 per-session logging for the internal address assigned to that device 223 (... and variations for multi-address situations). This case is 224 basically out of scope of this document. 226 Section 11 of [RFC6269] provides a good discussion of the 227 traceability issue. Complete traceability given the NAT logging 228 practices proposed in this draft requires that the remote destination 229 record the source port of a request along with the source address 230 (and presumably protocol, if not implicit). In addition, the logs at 231 each end must be timestamped, and the clocks must be synchronized 232 within a certain degree of accuracy. Here is one reason for the 233 guard timing on block release, to increase the tolerable level of 234 clock skew between the two ends. 236 The ability to configure various server applications to record source 237 ports has been investigated, with the following results: 239 o Source port recording can be configured in Apache, Postfix, 240 sendmail and sshd. Please refer to the appendix for configuration 241 guide. 243 o Source port recording is not supported by IIS, Cyrus IMAP and UW 244 IMAP. But it should not be too difficult to get Cyrus IMAP and UW 245 IMAP to support it by modifying the source code. 247 Where source port logging can be enabled, this memo strongly urges 248 the operators to do so. Similarly, intrusion detection systems 249 should capture source port as well as source address of suspect 250 packets. 252 In some cases [RFC6269], a server may not record the source port of a 253 connection. To allow traceability, the NAT device needs to record 254 the destination IP address of a connection. As [RFC6269] points out, 255 this will provide an incomplete solution to the issue of traceability 256 because multiple users of the same shared public IP address may 257 access the service at the same time. From the point of view of this 258 draft, in such situations the game is lost, so to speak, and port 259 allocation at the NAT might as well be completely dynamic. 261 The final possibility to consider is where the NAT does not do per- 262 session logging even given the possibility that the remote end is 263 failing to capture source ports. In that case, the port allocation 264 policy proposed in this draft can be used. The impact on 265 traceability is that the investigating authority would be able to 266 collect only the list of all internal addresses mapped to a given 267 public address during the period of time concerned. This has an 268 impact on privacy as well as traceability, depending on the follow-up 269 actions taken by the investigating authority to achieve its 270 objectives. 272 4. Other Considerations 274 [RFC6269] notes several issues introduced by the use of dynamic as 275 opposed to static port assignment. For example, Section 12.2 of that 276 document notes the effect on authentication procedures. These issues 277 must be resolved, but are not specific to the port allocation policy 278 described in this document. 280 5. IANA Considerations 282 This memo includes no request to IANA. 284 6. Security Considerations 286 The security considerations applicable to NAT operation for various 287 protocols as documented in, for example, [RFC4787] and [RFC5382] also 288 apply to this proposal. 290 7. Acknowledgements 292 Mohamed Boucadair reviewed the initial document and provided useful 293 comments to improve it. Reinaldo Penno, Joel Jaeggli, and Dan Wing 294 provided comments on the subsequent version that resulted in major 295 revisions. James Huang performed the research contributed in the 296 Appendix. Serafim Petsis provided encouragement to publication after 297 a hiatus of two years. 299 8. Appendix A: Configure Server Software to Log Source Port 301 8.1. Apache 303 The user can use LogFormat command to define a customized log format 304 and use CustomLog command to apply that log format. "%a" and 305 "%{remote}p" can be used in the format string to require logging the 306 client's IP address and source port respectively. This feature is 307 available since Apache version 2.1. 309 A detailed configuration guide can be found at [APACHE_LOG_CONFIG]. 311 8.2. Postfix 313 In order to log the client source port, macro 314 smtpd_client_port_logging should be set to "yes" in the configuration 315 file. [POSTFIX_LOG_CONFIG] 317 This feature is available since Postfix version 2.5. 319 8.3. Sendmail 321 Sendmail has a macro ${client_port} storing the client port. To log 322 the source port, the user can define some check rules. Here is an 323 example which should be in the .mc configuration macro 324 [SENDMAIL_LOG_CONFIG]: 326 LOCAL_CONFIG 327 Klog syslog 329 LOCAL_RULESETS 330 SLocal_check_mail 331 R $* $@ $(log Port_Stat $&{client_addr} $&{client_port} $) 333 This feature is available since version 8.10. 335 8.4. sshd 337 SSHD_CONFIG(5) OpenBSD Programmer's Manual SSHD_CONFIG(5) NAME 338 sshd_config - OpenSSH SSH daemon configuration file LogLevel Gives 339 the verbosity level that is used when logging messages from sshd(8). 340 The possible values are: QUIET, FATAL, ERROR, INFO, VERBOSE, DEBUG, 341 DEBUG1, DEBUG2, and DEBUG3. The default is INFO. DEBUG and DEBUG1 342 are equivalent. DEBUG2 and DEBUG3 each specify higher levels of 343 debugging output. Logging with a DEBUG level violates the privacy of 344 users and is not recommended. SyslogFacility Gives the facility code 345 that is used when logging messages from sshd(8). The possible values 346 are: DAEMON, USER, AUTH, LOCAL0, LOCAL1, LOCAL2, LOCAL3, LOCAL4, 347 LOCAL5, LOCAL6, LOCAL7. The default is AUTH. 349 sshd supports logging the client IP address and client port when a 350 client starts connection since version 1.2.2, here is the source code 351 in sshd.c: 353 ... 354 verbose("Connection from %.500s port %d", remote_ip, remote_port); 355 ... 357 sshd supports logging the client IP address when a client 358 disconnects, from version 1.2.2 to version 5.0. Since version 5.1 359 sshd supports logging the client IP address and source port. Here is 360 the source code in sshd.c: 362 ... 363 /* from version 1.2.2 to 5.0*/ 364 verbose("Closing connection to %.100s", remote_ip); 365 ... 367 /* since version 5.1*/ 368 verbose("Closing connection to %.500s port %d", 369 remote_ip, remote_port); 370 In order to log the source port, the LogLevel should be set to 371 VERBOSE [SSHD_LOG_CONFIG] in the configuration file: 373 LogLevel VERBOSE 375 8.5. Cyrus IMAP and UW IMAP 377 Cyrus IMAP and UW IMAP do not support logging the source port for the 378 time being. Both software use syslog to create logs; it should not 379 be too difficult to get it supported by adding some new code. 381 9. References 383 9.1. Normative References 385 [RFC6269] Ford, M., Boucadair, M., Durand, A., Levis, P., and P. 386 Roberts, "Issues with IP Address Sharing", RFC 6269, June 387 2011. 389 9.2. Informative References 391 [APACHE_LOG_CONFIG] 392 The Apache Software Foundation, 393 "http://httpd.apache.org/docs/2.4/mod/mod_log_config.html 394 ", 2013. 396 [I-D.bajko-pripaddrassign] 397 Bajko, G., Savolainen, T., Boucadair, M., and P. Levis, 398 "Port Restricted IP Address Assignment (Work in 399 progress)", April 2012. 401 [I-D.behave-lsn-requirements] 402 Perrault, S., Yamagata, I., Miyakawa, S., Nakagawa, A., 403 and H. Ashida, "Common requirements for Carrier Grade NATs 404 (CGNs) (Work in progress)", December 2012. 406 [POSTFIX_LOG_CONFIG] 407 , "http://www.postfix.org/postconf.5.html ", 2013. 409 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 410 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 411 RFC 4787, January 2007. 413 [RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. 414 Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, 415 RFC 5382, October 2008. 417 [SENDMAIL_LOG_CONFIG] 418 O'Reilly, "Sendmail, 3rd Edition, Page 798", December 419 2002. 421 [SSHD_LOG_CONFIG] 422 , "http://www.openbsd.org/cgi-bin/ 423 man.cgi?query=sshd_config&sektion=5", April 2013. 425 Authors' Addresses 427 Tina Tsou 428 Huawei Technologies (USA) 429 2330 Central Expressway 430 Santa Clara, CA 95050 431 USA 433 Phone: +1 408 330 4424 434 Email: tina.tsou.zouting@huawei.com 436 Weibo Li 437 China Telecom 438 109, Zhongshan Ave. West, Tianhe District 439 Guangzhou 510630 440 P.R. China 442 Email: mweiboli@gmail.com 444 Tom Taylor 445 Huawei Technologies 446 Ottawa 447 Canada 449 Email: tom.taylor.stds@gmail.com