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 March 1, 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 (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
    1.1.  Requirements Language
2.  A Suggested Solution
3.  IANA Considerations
4.  Security Considerations
5.  Acknowledgements
6.  References
    6.1.  Normative References
    6.2.  Informative References
§  Authors' Addresses

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] (Ford, M., Boucadair, M., Durand, A., Levis, P., and P. Roberts, “Issues with IP Address Sharing (Work in progress),” June 2010.), 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] (Yamagata, I., Miyakawa, S., Nakagawa, A., and H. Ashida, “Common requirements for IP address sharing schemes (Work in progress),” July 2010.) 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] (Durand, A., Droms, R., Woodyatt, J., and Y. Lee, “Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion (Work in progress),” July 2010.).

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.

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] (Bajko, G., Savolainen, T., Boucadair, M., and P. Levis, “Port Restricted IP Address Assignment (Work in progress),” October 2009.). 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] (Ford, M., Boucadair, M., Durand, A., Levis, P., and P. Roberts, “Issues with IP Address Sharing (Work in progress),” June 2010.), 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] (Audet, F. and C. Jennings, “Network Address Translation (NAT) Behavioral Requirements for Unicast UDP,” January 2007.) and [RFC5382] (Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. Srisuresh, “NAT Behavioral Requirements for TCP,” October 2008.) also apply to this proposal.

5.  Acknowledgements

Mohamed Boucadair reviewed the document and provided useful comments to improve it.

6.  References

6.1. Normative References

6.2. Informative References

Authors' Addresses