[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits] [IPR]

Versions: 00 01 02 03 04 05 06 RFC 7768

Behavior Engineering for Hindrance                          T. Tsou, Ed.
Avoidance                                            Huawei Technologies
Internet-Draft                                                W. Li, Ed.
Intended status: Informational                             China Telecom
Expires: April 3, 2011                                         T. Taylor
                                                     Huawei Technologies
                                                      September 30, 2010


         Port Management To Reduce Logging In Large-Scale NATs
                draft-tsou-behave-natx4-log-reduction-02

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 April 3, 2011.

Copyright Notice

   Copyright (c) 2010 IETF Trust and the persons identified as the
   document authors.  All rights reserved.




Tsou, et al.              Expires April 3, 2011                 [Page 1]


Internet-Draft             NATx4 Log Reduction            September 2010


   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 . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Requirements Language  . . . . . . . . . . . . . . . . . .  3
   2.  A Suggested Solution . . . . . . . . . . . . . . . . . . . . .  3
   3.  Issues Of Traceability . . . . . . . . . . . . . . . . . . . .  5
   4.  Other Considerations . . . . . . . . . . . . . . . . . . . . .  7
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  7
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . .  7
   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  7
   8.  Appendix A: Configure Server Software to Log Source Port . . .  7
     8.1.  Apache . . . . . . . . . . . . . . . . . . . . . . . . . .  7
     8.2.  Postfix  . . . . . . . . . . . . . . . . . . . . . . . . .  8
     8.3.  Sendmail . . . . . . . . . . . . . . . . . . . . . . . . .  8
     8.4.  sshd . . . . . . . . . . . . . . . . . . . . . . . . . . .  8
     8.5.  Cyrus IMAP and UW IMAP . . . . . . . . . . . . . . . . . .  9
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  9
     9.1.  Normative References . . . . . . . . . . . . . . . . . . .  9
     9.2.  Informative References . . . . . . . . . . . . . . . . . .  9
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10




















Tsou, et al.              Expires April 3, 2011                 [Page 2]


Internet-Draft             NATx4 Log Reduction            September 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 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
   [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, et al.              Expires April 3, 2011                 [Page 3]


Internet-Draft             NATx4 Log Reduction            September 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 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



Tsou, et al.              Expires April 3, 2011                 [Page 4]


Internet-Draft             NATx4 Log Reduction            September 2010


   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.

   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
   [I-D.ietf-intarea-shared-addressing-issues] 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.


3.  Issues Of Traceability

   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:

   1.  the investigating authority requires a complete record of the
       activities of a target individual;

   2.  the investigating authority is concerned with tracking down the
       user responsible for wrongful behaviour at a specific end point
       (e.g., server, individual user, enterpise network).

   Assuming that per-sesssion logging at the NAT is to be avoided in
   general (the whole point of this draft), the first requirement can
   only be met by identifying a target device in advance and enabling



Tsou, et al.              Expires April 3, 2011                 [Page 5]


Internet-Draft             NATx4 Log Reduction            September 2010


   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 the draft.

   Section 11 of [I-D.ietf-intarea-shared-addressing-issues] 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:

   o  Source port recording can be configured in Apache, Postfix,
      sendmail and sshd.  Please refer to the appendix for configuration
      guide.

   o  Source port recording is not supported by IIS, Cyrus IMAP and UW
      IMAP.  But it should not be too difficult to get Cyrus IMAP and UW
      IMAP to support it by modifying the source code.

   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 [I-D.ietf-intarea-shared-addressing-issues], 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
   [I-D.ietf-intarea-shared-addressing-issues] 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



Tsou, et al.              Expires April 3, 2011                 [Page 6]


Internet-Draft             NATx4 Log Reduction            September 2010


   impact on privacy as well as traceability, depending on the follow-up
   actions taken by the investigating authority to achieve its
   objectives.


4.  Other Considerations

   [I-D.ietf-intarea-shared-addressing-issues] 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.


5.  IANA Considerations

   This memo includes no request to IANA.


6.  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.


7.  Acknowledgements

   Mohamed Boucadair reviewed the initial document and provided useful
   comments to improve it.  Reinaldo Penno, Joel Jaegli, and Dan Wing
   provided comments on the subsequent version that resulted in major
   revisions.


8.  Appendix A: Configure Server Software to Log Source Port

8.1.  Apache

   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.

   Detail configuration guide can be found at [APACHE_LOG_CONFIG].





Tsou, et al.              Expires April 3, 2011                 [Page 7]


Internet-Draft             NATx4 Log Reduction            September 2010


8.2.  Postfix

   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.

8.3.  Sendmail

   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.

8.4.  sshd

   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 disconnect
   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);




Tsou, et al.              Expires April 3, 2011                 [Page 8]


Internet-Draft             NATx4 Log Reduction            September 2010


   In order to log the source port, the LogLevel should be set to
   VERBOSE [SSHD_LOG_CONFIG] in the configuration file:

   LogLevel    VERBOSE

8.5.  Cyrus IMAP and UW IMAP

   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.


9.  References

9.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.

9.2.  Informative References

   [APACHE_LOG_CONFIG]
              "http://httpd.apache.org/docs/2.1/mod/
              mod_log_config.html".

   [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.

   [POSTFIX_LOG_CONFIG]
              "http://www.postfix.org/postconf.5.html".

   [RFC4787]  Audet, F. and C. Jennings, "Network Address Translation
              (NAT) Behavioral Requirements for Unicast UDP", BCP 127,
              RFC 4787, January 2007.



Tsou, et al.              Expires April 3, 2011                 [Page 9]


Internet-Draft             NATx4 Log Reduction            September 2010


   [RFC5382]  Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P.
              Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142,
              RFC 5382, October 2008.

   [SENDMAIL_LOG_CONFIG]
              O'Reilly, "Sendmail, 3rd Edition, Page 798",
              December 2002.

   [SSHD_LOG_CONFIG]
              "http://www.openbsd.org/cgi-bin/
              man.cgi?query=sshd_config&sektion=5".


Authors' Addresses

   Tina Tsou (editor)
   Huawei Technologies
   Bantian, Longgang District
   Shenzhen  518129
   P.R. China

   Phone:
   Email: tena@huawei.com


   Weibo Li (editor)
   China Telecom
   109, Zhongshan Ave. West, Tianhe District
   Guangzhou  510630
   P.R. China

   Phone:
   Email: mweiboli@gmail.com


   Tom Taylor
   Huawei Technologies
   1852 Lorraine Ave.
   Ottawa  K1H 6Z8
   Canada

   Phone:
   Email: tom111.taylor@bell.net








Tsou, et al.              Expires April 3, 2011                [Page 10]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/