Behavior Engineering for Hindrance T. Tsou, Ed. Avoidance T. Taylor Internet-Draft Huawei Technologies Intended status: Informational August 27, 2010 Expires: February 28, 2011 Port Management To Reduce Logging In Large-Scale NATs draft-tsou-behave-natx4-log-reduction-01 Abstract 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. Status of this Memo 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 February 28, 2011. Copyright Notice Copyright (c) 2010 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 Tsou & Taylor Expires February 28, 2011 [Page 1] Internet-Draft NATx4 Log Reduction August 2010 (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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 3 2. A Suggested Solution . . . . . . . . . . . . . . . . . . . . . 3 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 6.1. Normative References . . . . . . . . . . . . . . . . . . . 5 6.2. Informative References . . . . . . . . . . . . . . . . . . 5 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 5 Tsou & Taylor Expires February 28, 2011 [Page 2] Internet-Draft NATx4 Log Reduction August 2010 1. Introduction 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 the user 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, couverted source IP address, source identifier, converted source identifier, etc For the purpose of troubleshooting, and also required by regulations, operators must keep logs of network NAT mapping entries for a period of time, e.g. 6 months or one year [I-D.ietf-intarea-shared-addressing-issues], 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. To reduce the cost of log storage, [I-D.nishitani-cgn] proposes to fix the port range for each user/CPE, and only one log will be generated for each user. But this would significantly reduce the number of subscribers that could share a public IP address, as discussed in [I-D.softwire-dual-stack-lite]. 1.1. Requirements Language This draft includes no requirements language. 2. A Suggested Solution 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. Tsou & Taylor Expires February 28, 2011 [Page 3] Internet-Draft NATx4 Log Reduction August 2010 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 2000~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 3000~3050, 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 continuous, due to security concerns; the port numbers could be worked out using some random algorithm along with some initial parameters. When generating a log message, these parameters instead of the port range would be included in the log. If some port block is not used for some configurable time, e.g. TBD minutes, after initial allocation or after the mapping timer has expired for every port in the block, the NAT can remove the port block from the user's resource pool, and make it available for other users. The deallocation is logged when it occurs. This solution can reduce the number of logs significantly and also make good use of the public IP address resource. In some case [I-D.ietf-intarea-shared-addressing-issues], a server may not record the source port of a connection, and NAT device needs to record the destination IP address of a connection. In such a case, the suggested solution is not applicable. But a reasonable solution is still for the server to record the source port. 3. IANA Considerations This memo includes no request to IANA. 4. Security Considerations The security considerations applicable to NAT operation for various protocols as documented in, for example, [RFC4787] and [RFC5382] also apply to this proposal. Tsou & Taylor Expires February 28, 2011 [Page 4] Internet-Draft NATx4 Log Reduction August 2010 5. Acknowledgements Mohamed Boucadair reviewed the document and provided useful comments to improve it. 6. References 6.1. Normative References [I-D.bajko-pripaddrassign] Bajko, G., Savolainen, T., Boucadair, M., and P. Levis, "Port Restricted IP Address Assignment (Work in progress)", October 2009. [I-D.ietf-intarea-shared-addressing-issues] Ford, M., Boucadair, M., Durand, A., Levis, P., and P. Roberts, "Issues with IP Address Sharing (Work in progress)", June 2010. 6.2. Informative References [I-D.nishitani-cgn] Yamagata, I., Miyakawa, S., Nakagawa, A., and H. Ashida, "Common requirements for IP address sharing schemes (Work in progress)", July 2010. [I-D.softwire-dual-stack-lite] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- Stack Lite Broadband Deployments Following IPv4 Exhaustion (Work in progress)", July 2010. [RFC4787] Audet, F. and C. Jennings, "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP", BCP 127, RFC 4787, January 2007. [RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, RFC 5382, October 2008. Tsou & Taylor Expires February 28, 2011 [Page 5] Internet-Draft NATx4 Log Reduction August 2010 Authors' Addresses Tina Tsou (editor) Huawei Technologies Bantian, Longgang District Shenzhen 518129 P.R. China Phone: Email: tena@huawei.com Tom Taylor Huawei Technologies 1852 Lorraine Ave. Ottawa K1H 6Z8 Canada Phone: Email: tom111.taylor@bell.net Tsou & Taylor Expires February 28, 2011 [Page 6]