| Behavior Engineering for Hindrance Avoidance | T. Tsou |
| Internet-Draft | Huawei Technologies (USA) |
| Intended status: Informational | W. Li |
| Expires: November 11, 2013 | China Telecom |
| T. Taylor | |
| Huawei Technologies | |
| May 10, 2013 |
Port Management To Reduce Logging In Large-Scale NATs
draft-tsou-behave-natx4-log-reduction-03
Various IPv6 transition strategies require the introduction of large-scale NATs (e.g. AFTR, NAT64) to share the limited supply of IPv4 addresses available in the network until transition is complete. There has recently been debate over how to manage the sharing of ports between different subscribers sharing the same IPv4 address. One factor in the discussion is the operational requirement to log the assignment of transport addresses to subscribers. It has been argued that dynamic assignment of individual ports between subscribers requires the generation of an excessive volume of logs. This document suggests a way to achieve dynamic port sharing while keeping log volumes low.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 11, 2013.
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
During the IPv6 transition period, some large-scale NAT devices may be introduced, e.g. DS-Lite AFTR, NAT64. When a NAT device needs to set up a new connection for a given internal address behind the NAT, it needs to create a new mapping entry for the new connection, which will contain source IP address, source port, converted source IP address, converted source port, protocol (TCP/UDP), etc. If the connection is ICMP, a mapping entry may include source IP address, converted source IP address, source identifier, converted source identifier, etc.
For the purpose of troubleshooting, and also as required by regulations, operators must keep logs of network NAT mapping entries for a period of time, e.g. 6 months or one year [RFC6269], so the NAT device needs to generate logs for mapping entries in addition to other information. A traditional method is to generate a log for each mapping entry. When a connection expires, the mapping entry will be deleted, and the corresponding log is stored locally or sent to a log storage server.
Some high performance NAT devices may need to create a large amount of new sessions per second. If logs are generated for each mapping entry, the log traffic could reach tens of megabytes per second or more, which would be a problem for log generation, transmission and storage.
[I-D.behave-lsn-requirements], REQ-13, REQ-14, and REQ-15 deal explicitly with port allocation schemes. However, it is recognized that these are conflicting requirements, requiring a tradeoff between the efficiency with which ports are used and the rate of generation of log records.
This draft includes no requirements language.
We propose a solution that allows dynamic sharing of port ranges between users while minimizing the number of logs that have to be generated. Briefly, ports are allocated to the user in blocks. Logs are generated only when blocks are allocated or deallocated. This provides the necessary traceability while reducing log generation by a factor equal to the block size, as compared with fully dynamic port allocation.
Here is how the proposal would work in greater detail. When the user sends out the first packet, a port resource pool is allocated for the user, e.g. assign ports 2001~2300 of a public IP address to the user's resource pool. Only one log should be generated for this port block. When the NAT needs to set up a new mapping entry for the user, it can use a port in the user's resource pool and the corresponding public IP address. If the user needs more port resources, the NAT can allocate another port block, ports 3501~3800, to the user's resource pool. Again , just one log needs to be generated for this port block. A log may contain the following information: source IP address, converted source IP address, port range, start time, end time, and some other necessary information.
There is an alternative way of allocating port blocks [I-D.bajko-pripaddrassign]. The ports in a block do not have to be contiguous. Due to security concerns, the port numbers could be worked out using some random algorithm along with some initial parameters. The randomization algorithm would be applied at the NAT when it generates a new mapping. The algorithm and initial parameters together are required to define a discrete subset of the entire available port range (1024 to 65335), such that it is possible to assign the complete range to different internal addresses as required by varying the initial parameters. When generating a log message, these parameters instead of the upper and lower bounds of a port range would be included in the log.
Suppose now that a given internal address has been assigned more than one block of ports. Regardless of whether the ports within a block are specified by a simple range or a random algorithm, it is clear that the overall preference for port randomization will be better achieved by spreading out new port assignments over all of the blocks assigned to that internal address. That means that the NAT should first select one of the assigned blocks pseudo-randomly before applying any randomization algorithm within the block. Further discussion of this point occurs below as part of the discussion of block deallocation.
The individual sessions using ports within a port block will start and end at different times. If no ports in some port block are used for some configurable time, the NAT can remove the port block from the resource pool allocated to a given internal address, and make it available for other users. The deallocation may be logged when it occurs, although some would view such logging as redundant.
The deallocation procedure presents a number of difficulties in practice. The first problem is the choice of timeout value for the block. If idle timers are applied for the individual mappings (sessions) within the block, and these conform to the recommendations for NAT behaviour for the protocol concerned, then the additional time that might be configured as a guard for the block as a whole need not be more than a few minutes. The block timer in this case serves only as a slightly more conservative extension of the individual session idle timers. If, instead, a single idle timer is used for the whole block, it must itself conform to the recommendations for the protocol with which that block of ports is associated. For example, REQ-5 of [RFC5382] requires an idle timer expiry duration of at least 2 hours and 4 minutes for TCP.
The next issue with port block deallocation is the conflict between the desire to randomize port allocation and the desire to make unused resources available to other internal addresses. As mentioned above, ideally port selection will take place over the entire set of blocks allocated to the internal address. However, taken to its fullest extent, such a policy will minimize the probability that all ports in any given block are idle long enough for it to be released.
As an alternative, it is suggested that when choosing which block to select a port from, the NAT should omit from its range of choice the block that has been idle the longest, unless no ports are available in any of the other blocks. The expression "block that has been idle the longest" designates the block in which the time since the last packet was observed in any of its sessions, in either direction, is earlier than the corresponding time in any of the other blocks assigned to that internal address. As [RFC6269] points out, port randomization is just one security measure of several, and the loss of randomness incurred by the suggested procedure is justified by the increased utilization of port resources it allows.
The whole point of this proposal is to allow the NAT to support regulatory requirements for traceability of usage. So it is only right to verify that these requirements can be met with the proposal made in the previous section. There are two cases:
Assuming that per-session logging at the NAT is to be avoided in general (the whole point of this document), the first requirement can only be met by identifying a target device in advance and enabling per-session logging for the internal address assigned to that device (... and variations for multi-address situations). This case is basically out of scope of this document.
Section 11 of [RFC6269] provides a good discussion of the traceability issue. Complete traceability given the NAT logging practices proposed in this draft requires that the remote destination record the source port of a request along with the source address (and presumably protocol, if not implicit). In addition, the logs at each end must be timestamped, and the clocks must be synchronized within a certain degree of accuracy. Here is one reason for the guard timing on block release, to increase the tolerable level of clock skew between the two ends.
The ability to configure various server applications to record source ports has been investigated, with the following results:
Where source port logging can be enabled, this memo strongly urges the operators to do so. Similarly, intrusion detection systems should capture source port as well as source address of suspect packets.
In some cases [RFC6269], a server may not record the source port of a connection. To allow traceability, the NAT device needs to record the destination IP address of a connection. As [RFC6269] points out, this will provide an incomplete solution to the issue of traceability because multiple users of the same shared public IP address may access the service at the same time. From the point of view of this draft, in such situations the game is lost, so to speak, and port allocation at the NAT might as well be completely dynamic.
The final possibility to consider is where the NAT does not do per- session logging even given the possibility that the remote end is failing to capture source ports. In that case, the port allocation policy proposed in this draft can be used. The impact on traceability is that the investigating authority would be able to collect only the list of all internal addresses mapped to a given public address during the period of time concerned. This has an impact on privacy as well as traceability, depending on the follow-up actions taken by the investigating authority to achieve its objectives.
[RFC6269] notes several issues introduced by the use of dynamic as opposed to static port assignment. For example, Section 12.2 of that document notes the effect on authentication procedures. These issues must be resolved, but are not specific to the port allocation policy described in this document.
This memo includes no request to IANA.
The security considerations applicable to NAT operation for various protocols as documented in, for example, [RFC4787] and [RFC5382] also apply to this proposal.
Mohamed Boucadair reviewed the initial document and provided useful comments to improve it. Reinaldo Penno, Joel Jaeggli, and Dan Wing provided comments on the subsequent version that resulted in major revisions. James Huang performed the research contributed in the Appendix. Serafim Petsis provided encouragement to publication after a hiatus of two years.
The user can use LogFormat command to define a customized log format and use CustomLog command to apply that log format. "%a" and "%{remote}p" can be used in the format string to require logging the client's IP address and source port respectively. This feature is available since Apache version 2.1.
A detailed configuration guide can be found at [APACHE_LOG_CONFIG].
In order to log the client source port, macro smtpd_client_port_logging should be set to "yes" in the configuration file. [POSTFIX_LOG_CONFIG]
This feature is available since Postfix version 2.5.
Sendmail has a macro ${client_port} storing the client port. To log the source port, the user can define some check rules. Here is an example which should be in the .mc configuration macro [SENDMAIL_LOG_CONFIG]:
LOCAL_CONFIG
Klog syslog
LOCAL_RULESETS
SLocal_check_mail
R $* $@ $(log Port_Stat $&{client_addr} $&{client_port} $)
This feature is available since version 8.10.
SSHD_CONFIG(5) OpenBSD Programmer's Manual SSHD_CONFIG(5) NAME sshd_config - OpenSSH SSH daemon configuration file LogLevel Gives the verbosity level that is used when logging messages from sshd(8). The possible values are: QUIET, FATAL, ERROR, INFO, VERBOSE, DEBUG, DEBUG1, DEBUG2, and DEBUG3. The default is INFO. DEBUG and DEBUG1 are equivalent. DEBUG2 and DEBUG3 each specify higher levels of debugging output. Logging with a DEBUG level violates the privacy of users and is not recommended. SyslogFacility Gives the facility code that is used when logging messages from sshd(8). The possible values are: DAEMON, USER, AUTH, LOCAL0, LOCAL1, LOCAL2, LOCAL3, LOCAL4, LOCAL5, LOCAL6, LOCAL7. The default is AUTH.
sshd supports logging the client IP address and client port when a client starts connection since version 1.2.2, here is the source code in sshd.c:
...
verbose("Connection from %.500s port %d", remote_ip, remote_port);
...
sshd supports logging the client IP address when a client disconnects, from version 1.2.2 to version 5.0. Since version 5.1 sshd supports logging the client IP address and source port. Here is the source code in sshd.c:
...
/* from version 1.2.2 to 5.0*/
verbose("Closing connection to %.100s", remote_ip);
...
/* since version 5.1*/
verbose("Closing connection to %.500s port %d",
remote_ip, remote_port);
In order to log the source port, the LogLevel should be set to VERBOSE [SSHD_LOG_CONFIG] in the configuration file:
LogLevel VERBOSE
Cyrus IMAP and UW IMAP do not support logging the source port for the time being. Both software use syslog to create logs; it should not be too difficult to get it supported by adding some new code.
| [RFC6269] | Ford, M., Boucadair, M., Durand, A., Levis, P. and P. Roberts, "Issues with IP Address Sharing", RFC 6269, June 2011. |