One document matched: draft-tsou-behave-natx4-log-reduction-03.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC4787 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4787.xml">
<!ENTITY RFC5382 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5382.xml">
<!ENTITY RFC6269 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6269.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-
Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="info" docName="draft-tsou-behave-natx4-log-reduction-03"
ipr="trust200902">
<!-- category values: std, bcp, info, exp, and historic
ipr values: trust200902, noModificationTrust200902,
noDerivativesTrust200902,
or pre5378Trust200902
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** -->
<front>
<!-- The abbreviated title is used in the page header - it is only
necessary if the
full title is longer than 39 characters -->
<title abbrev="NATx4 Log Reduction">Port Management To Reduce Logging In
Large-Scale NATs</title>
<author fullname="Tina Tsou" initials="T." surname="Tsou">
<organization>Huawei Technologies (USA)</organization>
<address>
<postal>
<street>2330 Central Expressway</street>
<city>Santa Clara</city>
<region>CA</region>
<code>95050</code>
<country>USA</country>
</postal>
<phone>+1 408 330 4424</phone>
<email>tina.tsou.zouting@huawei.com</email>
</address>
</author>
<author fullname="Weibo Li" initials="W." surname="Li">
<organization>China Telecom</organization>
<address>
<postal>
<street>109, Zhongshan Ave. West, Tianhe District</street>
<!-- Reorder these if your country does things differently -->
<city>Guangzhou</city>
<code>510630</code>
<country>P.R. China</country>
</postal>
<phone></phone>
<email>mweiboli@gmail.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Tom Taylor" initials="T." surname="Taylor">
<organization>Huawei Technologies</organization>
<address>
<postal>
<street></street>
<!-- Reorder these if your country does things differently -->
<city>Ottawa</city>
<code></code>
<country>Canada</country>
</postal>
<phone></phone>
<email>tom.taylor.stds@gmail.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<date year="2013" />
<!-- If the month and year are both specified and are the current ones,
xml2rfc will fill in the current day for you. If only the current year is
specified, xml2rfc will fill in the current day and month for you. If the year
is not the current one, it is necessary to specify at least a month (xml2rfc
assumes day="1" if not specified for the purpose of calculating the expiry
date). With drafts it is normally sufficient to specify just the year. -->
<!-- Meta-data Declarations -->
<area>Transport</area>
<workgroup>Behavior Engineering for Hindrance Avoidance</workgroup>
<keyword>NAT logging</keyword>
<!-- Keywords will be incorporated into HTML output
files in a meta tag but they have no effect on text or nroff
output. If you submit your draft to the RFC Editor, the
keywords will be used for the search engine. -->
<abstract>
<t>
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.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
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.
</t>
<t>
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 <xref target="RFC6269"/>,
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.
</t>
<t>
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.
</t>
<t>
<xref target="I-D.behave-lsn-requirements"/>, REQ-13, REQ-14, and
REQ-15 deal explicitly with port allocation schemes. However, it is
recognized that these are conflicting requirements, requiring a
tradeoff between the efficiency with which ports are used and the rate
of generation of log records.
</t>
<section title="Requirements Language">
<t>This draft includes no requirements language.</t>
</section>
</section>
<section anchor="proposal" title="A Suggested Solution">
<t>
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.
</t>
<t>
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.
</t>
<t>
There is an alternative way of allocating port blocks
<xref target="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.
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
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
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
<xref target="RFC5382" /> requires an idle timer expiry duration of at
least 2 hours and 4 minutes for TCP.
</t>
<t>
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.
</t>
<t>
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 <xref target="RFC6269"/> 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.
</t>
</section><!-- proposal -->
<section anchor="trac" title="Issues Of Traceability">
<t>
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:
<list style="numbers">
<t> the investigating authority requires a complete record of the
activities of a target individual; </t>
<t> the investigating authority is concerned with tracking down the
user responsible for wrongful behaviour at a specific end point (e.g.,
server, individual user, enterprise network). </t>
</list>
</t>
<t>
Assuming that per-session logging at the NAT is to be avoided in
general (the whole point of this document), the first requirement can
only be met by identifying a target device in advance and enabling
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 this document.
</t>
<t>
Section 11 of <xref target="RFC6269"/> 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.
</t>
<t> The ability to configure various server applications to record
source ports has been investigated, with the following results:
<list style="symbols">
<t> Source port recording can be configured in Apache, Postfix,
sendmail and sshd. Please refer to the appendix for configuration
guide.</t>
<t> 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.</t>
</list>
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.
</t>
<t>
In some cases <xref target="RFC6269"/>, 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 <xref
target="RFC6269"/> 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.
</t>
<t>
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 impact on privacy as well as
traceability, depending on the follow-up actions taken by the
investigating authority to achieve its objectives.
</t>
</section><!-- trac -->
<section title="Other Considerations">
<t>
<xref target="RFC6269"/> 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.
</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This memo includes no request to IANA.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>
The security considerations applicable to NAT operation for various
protocols as documented in, for example, <xref target="RFC4787"/> and
<xref target="RFC5382"/> also apply to this proposal.
</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>
Mohamed Boucadair reviewed the initial document and provided useful
comments to improve it. Reinaldo Penno, Joel Jaeggli, and Dan Wing
provided comments on the subsequent version that resulted in major
revisions. James Huang performed the research contributed in the
Appendix. Serafim Petsis provided encouragement to publication after
a hiatus of two years.
</t>
</section>
<section title="Appendix A: Configure Server Software to Log Source Port">
<section title="Apache">
<t>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.</t>
<t>A detailed configuration guide can be found at <xref
target="APACHE_LOG_CONFIG"/>.</t>
</section>
<section title="Postfix">
<t> In order to log the client source port, macro
smtpd_client_port_logging should be set to "yes" in the configuration
file. <xref target="POSTFIX_LOG_CONFIG"/></t>
<t>This feature is available since Postfix version 2.5.</t>
</section>
<section title="Sendmail">
<t> 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 <xref
target="SENDMAIL_LOG_CONFIG"/>:</t>
<figure>
<artwork>
LOCAL_CONFIG
Klog syslog
LOCAL_RULESETS
SLocal_check_mail
R $* $@ $(log Port_Stat $&{client_addr} $&{client_port} $)
</artwork>
</figure>
<t>This feature is available since version 8.10.</t>
</section>
<section title="sshd">
<t>SSHD_CONFIG(5) OpenBSD Programmer's Manual SSHD_CONFIG(5)
NAME
sshd_config - OpenSSH SSH daemon configuration file
LogLevel
Gives the verbosity level that is used when logging messages from
sshd(8). The possible values are: QUIET, FATAL, ERROR, INFO,
VERBOSE, DEBUG, DEBUG1, DEBUG2, and DEBUG3. The default is INFO.
DEBUG and DEBUG1 are equivalent. DEBUG2 and DEBUG3 each specify
higher levels of debugging output. Logging with a DEBUG level
violates the privacy of users and is not recommended.
SyslogFacility
Gives the facility code that is used when logging messages from
sshd(8). The possible values are: DAEMON, USER, AUTH, LOCAL0,
LOCAL1, LOCAL2, LOCAL3, LOCAL4, LOCAL5, LOCAL6, LOCAL7. The
default is AUTH.
</t>
<t>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:</t>
<figure>
<artwork>
...
verbose("Connection from %.500s port %d", remote_ip, remote_port);
...
</artwork>
</figure>
<t>sshd supports logging the client IP address when a client
disconnects, 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:</t>
<figure>
<artwork>
...
/* 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);
</artwork>
</figure>
<t> In order to log the source port, the LogLevel should be set to VERBOSE
<xref target="SSHD_LOG_CONFIG"/>
in the configuration file:</t>
<figure>
<artwork>
LogLevel VERBOSE
</artwork>
</figure>
</section>
<section title="Cyrus IMAP and UW IMAP">
<t>
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.
</t>
</section>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<references title="Normative References">
&RFC6269;
</references>
<references title="Informative References">
&RFC4787;
&RFC5382;
<reference anchor="I-D.bajko-pripaddrassign">
<front>
<title>Port Restricted IP Address Assignment (Work in progress)</title>
<author initials="G." surname="Bajko">
<organization>Nokia</organization>
</author>
<author initials="T." surname="Savolainen">
<organization>Nokia</organization>
</author>
<author initials="M." surname="Boucadair">
<organization>France Telecom</organization>
</author>
<author initials="P." surname="Levis">
<organization>France Telecom</organization>
</author>
<date month="April" year="2012" />
</front>
</reference>
<reference anchor="I-D.behave-lsn-requirements">
<front>
<title>Common requirements for Carrier Grade NATs (CGNs) (Work in progress)</title>
<author initials="S." surname="Perrault">
<organization>Viagenie</organization>
</author>
<author initials="I." surname="Yamagata">
<organization>NTT Communications</organization>
</author>
<author initials="S." surname="Miyakawa">
<organization>NTT Communications</organization>
</author>
<author initials="A." surname="Nakagawa">
<organization>Japan Internet Exchange (JPIX)</organization>
</author>
<author initials="H." surname="Ashida">
<organization>IS Consulting G.K.</organization>
</author>
<date month="December" year="2012" />
</front>
</reference>
<reference anchor="APACHE_LOG_CONFIG">
<front>
<title> http://httpd.apache.org/docs/2.4/mod/mod_log_config.html </title>
<author><organization>The Apache Software Foundation</organization></author>
<date year="2013"/>
</front>
</reference>
<reference anchor="POSTFIX_LOG_CONFIG">
<front>
<title> http://www.postfix.org/postconf.5.html </title>
<author><organization></organization></author>
<date year="2013"/>
</front>
</reference>
<reference anchor="SENDMAIL_LOG_CONFIG">
<front>
<title> Sendmail, 3rd Edition, Page 798</title>
<author fullname="Bryan Costales">
<organization>O'Reilly</organization>
</author>
<date month="December" year="2002"/>
</front>
</reference>
<reference anchor="SSHD_LOG_CONFIG">
<front>
<title>http://www.openbsd.org/cgi-bin/man.cgi?query=sshd_config&sektion=5</title>
<author><organization></organization></author>
<date month="April" year="2013"/>
</front>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 04:39:01 |