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]