doc: Add RFC documents

1 files changed, 283 insertions, 0 deletions

diff --git a/doc/rfc/rfc6302.txt b/doc/rfc/rfc6302.txt
new file mode 100644
index 0000000..4775203
--- /dev/null
+++ b/doc/rfc/rfc6302.txt
@@ -0,0 +1,283 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                         A. Durand
+Request for Comments: 6302                              Juniper Networks
+BCP: 162                                                    I. Gashinsky
+Category: Best Current Practice                              Yahoo! Inc.
+ISSN: 2070-1721                                                   D. Lee
+                                                          Facebook, Inc.
+                                                             S. Sheppard
+                                                                ATT Labs
+                                                               June 2011
+
+
+          Logging Recommendations for Internet-Facing Servers
+
+Abstract
+
+   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.
+
+Status of This Memo
+
+   This memo documents an Internet Best Current Practice.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   BCPs is available in Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc6302.
+
+Copyright Notice
+
+   Copyright (c) 2011 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
+   (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.
+
+
+
+Durand, et al.            Best Current Practice                 [Page 1]
+
+RFC 6302             Internet-Facing Server Logging            June 2011
+
+
+Table of Contents
+
+   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 2
+   2.  Recommendations . . . . . . . . . . . . . . . . . . . . . . . . 3
+   3.  ISP Considerations  . . . . . . . . . . . . . . . . . . . . . . 4
+   4.  Security Considerations . . . . . . . . . . . . . . . . . . . . 4
+   5.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 4
+     5.1.  Normative references  . . . . . . . . . . . . . . . . . . . 4
+     5.2.  Informative references  . . . . . . . . . . . . . . . . . . 4
+
+1.  Introduction
+
+   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 existing global 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;
+   however, this is a process that will take years, perhaps decades.
+
+   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 NAT44 [RFC3022], NAT64 [RFC6146] or DS-Lite [DS-LITE].
+
+   The effects on the Internet of the introduction of those address
+   sharing techniques have been documented in [RFC6269].
+
+   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.
+
+   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.
+
+
+
+
+
+
+Durand, et al.            Best Current Practice                 [Page 2]
+
+RFC 6302             Internet-Facing Server Logging            June 2011
+
+
+2.  Recommendations
+
+   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 RFC 2119 [RFC2119].
+
+   It is RECOMMENDED as best current practice that Internet-facing
+   servers logging incoming IP addresses from inbound IP traffic also
+   log:
+
+   o  The source port number.
+
+   o  A timestamp, RECOMMENDED in UTC, accurate to the second, from a
+      traceable time source (e.g., NTP [RFC5905]).
+
+   o  The transport protocol (usually TCP or UDP) and destination port
+      number, when the server application is defined to use multiple
+      transports or multiple ports.
+
+   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 preferred to local time with UTC-offset or time
+   zone, as this extra information can be lost in the reporting chain.
+
+   Examples of Internet-facing servers include, but are not limited to,
+   web servers and email servers.
+
+   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.
+
+   Discussions about data-retention policies are out of scope for this
+   document.  Server security and transport security are 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.
+
+   The above recommendations also apply to devices such as load-
+   balancers logging incoming connections on behalf of actual servers.
+
+
+
+
+Durand, et al.            Best Current Practice                 [Page 3]
+
+RFC 6302             Internet-Facing Server Logging            June 2011
+
+
+   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.
+
+3.  ISP Considerations
+
+   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.
+
+4.  Security Considerations
+
+   In the absence of the source port number and accurate timestamp
+   information, operators deploying any address sharing techniques will
+   not be able to identify unambiguously customers when dealing with
+   abuse or public safety queries.
+
+5.  References
+
+5.1.  Normative references
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+5.2.  Informative references
+
+   [DS-LITE]  Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-
+              Stack Lite Broadband Deployments Following IPv4
+              Exhaustion", Work in Progress, May 2011.
+
+   [RFC3022]  Srisuresh, P. and K. Egevang, "Traditional IP Network
+              Address Translator (Traditional NAT)", RFC 3022,
+              January 2001.
+
+   [RFC5905]  Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network
+              Time Protocol Version 4: Protocol and Algorithms
+              Specification", RFC 5905, June 2010.
+
+   [RFC6146]  Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful
+              NAT64: Network Address and Protocol Translation from IPv6
+              Clients to IPv4 Servers", RFC 6146, April 2011.
+
+   [RFC6269]  Ford, M., Ed., Boucadair, M., Durand, A., Levis, P., and
+              P. Roberts, "Issues with IP Address Sharing", RFC 6269,
+              June 2011.
+
+
+
+
+Durand, et al.            Best Current Practice                 [Page 4]
+
+RFC 6302             Internet-Facing Server Logging            June 2011
+
+
+Authors' Addresses
+
+   Alain Durand
+   Juniper Networks
+   1194 North Mathilda Avenue
+   Sunnyvale, CA  94089-1206
+   USA
+
+   EMail: adurand@juniper.net
+
+
+   Igor Gashinsky
+   Yahoo! Inc.
+   45 West 18th St.
+   New York, NY  10011
+   USA
+
+   EMail: igor@yahoo-inc.com
+
+
+   Donn Lee
+   Facebook, Inc.
+   1601 S. California Ave.
+   Palo Alto, CA  94304
+   USA
+
+   EMail: donn@fb.com
+
+
+   Scott Sheppard
+   ATT Labs
+   575 Morosgo Ave, 4d57
+   Atlanta, GA  30324
+   USA
+
+   EMail: Scott.Sheppard@att.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Durand, et al.            Best Current Practice                 [Page 5]
+