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]