One document matched: draft-ietf-intarea-server-logging-recommendations-04.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" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced. 
An alternate method (rfc include) is described in the references. -->


<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC3022 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3022.xml">
<!ENTITY RFC5905 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5905.xml">
<!ENTITY I-D.ietf-behave-v6v4-xlate-stateful SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-behave-v6v4-xlate-stateful">
<!ENTITY I-D.ietf-intarea-shared-addressing-issues SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-intarea-shared-addressing-issues">
<!ENTITY I-D.ietf-softwire-dual-stack-lite SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-softwire-dual-stack-lite">


]>
<?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="bcp" docName="draft-ietf-intarea-server-logging-recommendations-04" ipr="trust200902">
<!-- category values: std, bcp, info, exp, and historic
ipr values: full3667, noModification3667, noDerivatives3667
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="Internet facing server logging">Logging recommendations for Internet facing servers</title>

<!-- add 'role="editor"' below for the editors if appropriate -->

<!-- Another author who claims to be an editor -->

<author fullname="Alain Durand" initials="A.D." surname="Durand">
<organization>Juniper Networks</organization>
<address>
<postal>
  <street>1194 North Mathilda Avenue</street>
  <!-- Reorder these if your country does things differently -->
  <city>Sunnyvale</city>
  <region>CA</region>
  <code>94089-1206</code>
  <country>USA</country>
</postal>
<email>adurand@juniper.net</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>

<author fullname="Igor Gashinsky" initials="I.G." surname="Gashinsky">
<organization>Yahoo! Inc.</organization>
<address>
<postal>
  <street>45 West 18th St.</street>
  <!-- Reorder these if your country does things differently -->
  <city>New York</city>
  <region>NY</region>
  <code>10011</code>
  <country>USA</country>
</postal>
<email>igor@yahoo-inc.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>

<author fullname="Donn Lee" initials="D.L." surname="Lee">
<organization>Facebook, Inc.</organization>
<address>
<postal>
  <street>1601 S. California Ave.</street>
  <!-- Reorder these if your country does things differently -->
  <city>Palo Alto</city>
  <region>CA</region>
  <code>94304</code>
  <country>USA</country>
</postal>
<email>donn@fb.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>

<author fullname="Scott Sheppard" initials="S.S." surname="Sheppard">
<organization>ATT Labs</organization>
<address>
<postal>
  <street>575 Morosgo Ave, 4d57</street>
  <!-- Reorder these if your country does things differently -->
  <city>Atlanta</city>
  <region>GA</region>
  <code>30324</code>
  <country>USA</country>
</postal>
<email>Scott.Sheppard@att.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>


<date year="2011" />

<!-- 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>General</area>

<workgroup>Internet Engineering Task Force</workgroup>

<!-- WG name at the upperleft corner of the doc,
 IETF is fine for individual submissions.  
 If this element is not present, the default is "Network Working Group",
 which is used by the RFC Editor as a nod to the history of the IETF. -->

<keyword>port 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>
In the wake of IPv4 exhaustion and deployment of IP address sharing techniques, this document recommends that Internet facing servers log port number and accurate timestamps in addition to the incoming IP address.
</t>
</abstract>
</front>

<middle>
<section title="Introduction">
<t>
The global IPv4 address free pool at IANA was exhausted in February 2011. Service providers will now have a hard time finding enough IPv4 global addresses to sustain product and subscriber growth.
Due to the huge global existing infrastructure, both hardware and software, vendors and service providers must continue to support IPv4 technologies for the foreseeable future. As legacy applications and hardware are retired the reliance on IPv4 will diminish but this is a years long perhaps decades long process.
</t>
<t>
To maintain legacy IPv4 address support, service providers will have little choice but to share IPv4 global addresses among multiple customers. Techniques to do so are outside of the scope of this document. All include some form of address translation/address sharing, being <xref target="RFC3022">NAT44</xref>, <xref target="I-D.ietf-behave-v6v4-xlate-stateful">NAT64</xref> or <xref target="I-D.ietf-softwire-dual-stack-lite">DS-Lite</xref>.
</t>
<t>
The effects on the Internet of the introduction of those address sharing techniques have been documented in <xref target="I-D.ietf-intarea-shared-addressing-issues"/>.
</t>
<t>
Address sharing techniques come with their own logging infrastructure to track the relation between which original IP address and source port(s) were associated with which user and external IPv4 address at any given point in time. In the past to support abuse mitigation or public safety requests, the knowledge of the external global IP address was enough to identify a subscriber of interest. With address sharing technologies, only providing information about the external public address associated with a session to a service provider is no longer sufficient information to unambiguously identify customers. 
</t>
<t>
Note: this document provides recommendations for Internet facing servers logging incoming connections. It does not provide any recommendations about logging on carrier-grade NAT or other address sharing tools.
</t>
</section>

<section title="Recommendations">
<t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref
target="RFC2119">RFC 2119</xref>.
</t>

<t>
It is RECOMMENDED as best current practice that Internet facing servers logging incoming IP addresses from inbound IP traffic also log:
<list style="symbols">
<t>
The source port number.
</t>
<t>
A timestamp, RECOMMENDED in UTC, accurate to the second, from a traceable time source (e.g., <xref target="RFC5905">NTP</xref>).
</t>
<t>
The transport protocol (usually TCP or UDP) and destination port number,
when the server application is defined to use multiple transports or multiple ports.
</t>
</list>
</t>
<t>
Discussion: Carrier-grade NATs may have different policies to recycle ports, some
implementations may decide to reuse ports almost immediately, some may wait several minutes
before marking the port ready for reuse. As a result, servers have no idea how fast the ports will be reused and, thus, should log timestamps using a reasonably accurate clock.
At this point the RECOMMENDED accuracy for timestamps is to the second or better. Representation of timestamps in UTC is prefered to localtime with UTC-offset or time zone as this extra information can be lost in the reporting chain.
</t>
<t>
Examples of Internet facing servers include, but are not limited to, web servers and email servers.
</t>
<t>
Although the deployment of address sharing techniques is not foreseen in IPv6, the above recommendations apply to both IPv4 and IPv6, if only for consistency and code simplification reasons.
</t>
<t>
Discussions about data retention policies are out of scope for this document. Server security and
transport security is important for the protection of logs for Internet facing systems.
The operator of the Internet facing server must consider the risks,
including the data and services on the server to determine the appropriate
measures. The protection of logs is critical in incident investigations.  If logs are
tampered with, evidence could be destroyed.
</t>
<t>
The above recommendations also apply to devices such as load-balancers logging incoming connections on behalf of actual servers.
</t>
<t>
The above recommendations apply to current
logging practices. They do not require any changes
in the way logging is performed; e.g., which packets are
examined and logged.
</t>
</section>



<section anchor="ISP" title="ISP Considerations">
<t>
ISP deploying IP address sharing techniques should also deploy a corresponding logging architecture to maintain records of the relation between a customer's identity and IP/port resources utilized.
 However, recommendations on this topic are out of scope for this document.
</t>
</section>

<section anchor="IANA" title="IANA Considerations">

<t>
None.
</t>
</section>

<section anchor="Security" title="Security Considerations">
<t>
In the absence of source port number and accurate timestamp, operators deploying any address sharing techniques will not be able to identify unambiguously customers when dealing with abuse or public safety queries.
</t>

</section>


</middle>

<!--  *****BACK MATTER ***** -->

<back>
<!-- References split into informative and normative -->

<!-- There are 2 ways to insert reference entries from the citation libraries:
1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
(for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")

Both are cited textually in the same manner: by using xref elements.
If you use the PI option, xml2rfc will, by default, try to find included files in the same
directory as the including file. You can also define the XML_LIBRARY environment variable
with a value containing a set of directories to search.  These can be either in the local
filing system or remote ones accessed by http (http://domain/dir/... ).-->

<references title="Normative references">
<!--?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?-->
&RFC2119;
</references>

<references title="Informative references">
&I-D.ietf-intarea-shared-addressing-issues;
&RFC3022;
&I-D.ietf-behave-v6v4-xlate-stateful;
&I-D.ietf-softwire-dual-stack-lite;
&RFC5905;
</references>



</back>
</rfc>