One document matched: draft-ietf-behave-syslog-nat-logging-00.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 "reference.RFC.2119.xml">
  <!ENTITY RFC5424 SYSTEM "reference.RFC.5424.xml">
  <!ENTITY RFC5425 SYSTEM "reference.RFC.5425.xml">
  <!ENTITY RFC5848 SYSTEM "reference.RFC.5848.xml">
  <!ENTITY RFC5952 SYSTEM "reference.RFC.5952.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="std" docName="draft-ietf-behave-syslog-nat-logging-00" ipr="trust200902">
  <!-- category values: std, bcp, info, exp, and historic
     ipr values: trust200902, noModificationTrust200902, noDerivativesTrust200902
     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>Syslog Format for NAT Logging</title>

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

    <!-- Another author who claims to be an editor -->
     <author fullname="Zhonghua Chen" initials="Z."  surname="Chen">
      <organization>China Telecom</organization>
      <address>
        <postal>
          <street></street>
          <city></city>
          <code></code>
          <country>P.R. China</country>
        </postal>
        <phone></phone>
        <email>18918588897@189.cn</email>
      </address>
    </author>

    <author fullname="Cathy Zhou" initials="C."  surname="Zhou">
      <organization>Huawei Technologies</organization>
      <address>
        <postal>
          <street>Bantian, Longgang District</street>
          <city>Shenzhen</city>
          <code>518129</code>
          <country>P.R. China</country>
        </postal>
        <phone></phone>
        <email>cathy.zhou@huawei.com</email>
      </address>
    </author>
    
    <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 initials="T." surname="Taylor" fullname="T. Taylor">
  <organization>Huawei Technologies</organization>
  <address>
    <postal>
      <street></street>
      <city>Ottawa</city>
      <region></region>
      <code></code>
      <country>Canada</country>
    </postal>
    <phone></phone>
    <email>tom.taylor.stds@gmail.com</email>
  </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>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. -->

    <abstract>

      <t>Under some circumstances operators will need to maintain a dynamic
      record of external address and port assignments made by a NAT device (e.g.,Carrier
      Grade NAT (CGN)), and will find it feasible and convenient to create
      such records using SYSLOG (RFC 5424). The present document standardizes
      a SYSLOG format to meet that recording requirement. It specifies a
      number of fields that could be a part of the log report, leaving it up
      to operators to select the fields needed for their specific
      circumstances.</t>
      
      <t>[*** Subject to discussion*** The log format presented here may
      also be used by PCP server implementations to log the mappings they
      implement.]</t>
      
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
    
      <t> Operators already need to record the addresses assigned to
      subscribers at any point in time, for operational and regulatory
      reasons. When operators introduce NAT devices which support address 
      sharing (e.g.,Carrier Grade NATs (CGNs)) into their
      network, both addresses and ports on the external side of the NAT devices are
      shared amongst subscribers. To trace back from an external address and
      port observed at a given point in time to a specific subscriber
      requires additional information: a record of which subscriber was
      assigned that address and port by the NAT.</t>
      
      <t> Address-port assignment strategies present a tradeoff between the
      efficiency with which available external addresses are used, the cost
      of maintaining a trace back capability, and the need to make port
      assignments unpredictable to counter the threat of session hijacking.
      At one extreme, the operator could make a one-time assignment of an
      external address and a set of ports to each subscriber. Traceback
      would then be a matter of retrieving configuration information from
      the NAT. Even in this situation, it is possible that a request for
      legal interception is placed against a specific subscriber, such that
      each session involving that subscriber is recorded. </t>
      
      <t>At the opposite extreme, a carrier could assign external addresses
      and ports to subscribers on demand, in totally random fashion. Such a
      strategy is not really practical, both because of the volume of
      records that would be required to support a traceback capability, and
      because the apparent gain in efficiency with which address-port
      combinations would be utilized would be attenuated by the need to
      leave address-port assignments idle for some minimum amount of time
      after last observed use to make sure they weren't still being used.
      </t>
      
      <t>Between these extremes, operators may choose to assign specific
      addresses and specific blocks of ports to subscribers when they log on
      to the network, releasing the assignments when they drop off. Such a
      strategy could be desirable in networks with mobile subscribers, in
      particular. Compared with the fully dynamic strategy, this strategy
      reduces the number of times that assignments have to be recorded by
      orders of magnitude.  </t>
      
      <t>The point just made is that under some circumstances operators
      need to record allocations of external address-port combinations in
      the NAT dynamically, and the volume of information contained in those
      records is manageable. Various means are available to create such
      records. This document assumes that for some operators, the most
      convenient mechanism to do so will be event logging using SYSLOG 
      <xref target="RFC5424"/>, where the SYSLOG records are generated
      either by the NAT itself or by an off-line device. </t>
      
      <t>The next section specifies a SYSLOG record format for logging of
      NAT address and port assignments and the format of fields that could
      be used within such a record. It is up to individual operators to
      choose the fields that match their specific operating procedures.</t>
   
      <section title="Terminology">
      
        <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">
        "Key words for use in RFCs to Indicate Requirement Levels"</xref>.</t>
        
      </section>

    </section>  <!-- Introduction -->
    
    <section anchor="recFMT" title="SYSLOG Record Format For NAT Logging">

      <t>This section describes the SYSLOG record format for NAT logging in
      terms of the field names used in <xref target="RFC5424"/> and
      specified in Section 6 of that document. In particular,
      this section specifies values for the APP-NAME and MSGID fields in the
      record header, the SD-ID identifying the STRUCTURED-DATA section, and
      the PARAM-NAMEs and PARAM-VALUE types for the individual possible
      parameters within that section.</t>
      
      <section anchor="hdrFMT" title="SYSLOG HEADER Fields">

        <t>Within the HEADER portion of the SYSLOG record, the priority (PRI)
        level is subject to local policy, but a default value of 86 is
        suggested, representing a Facility value of 10
        (security/authorization) and a Severity level of 6 (informational).
        Depending on where the SYSLOG record is generated, the HOSTNAME field
        may identify the NAT or an offline logging device. In the latter case,
        it may be desirable to identify the NAT using the NID field in the
        STRUCTURED-DATA section (see below). The value of the HOSTNAME field
        is subject to the preferences given in Section 6.2.4 of 
        <xref target="RFC5424"/>.</t>

        <t> The values of the APP-NAME and MSGID fields in the record header
        determine the semantics of the record. The RECOMMENDED APP-NAME value
        "NAT" indicates that the record relates to an assignment made
        autonomously by the NAT itself. [*** Subject to discussion*** The
        RECOMMENDED APP-NAME "PCP" indicates that the assignment to which the
        record refers was the result of a Port Control Protocol (PCP) 
        [I-D.PCP-Base] command.] The RECOMMENDED MSGID value
        "ADD" indicates that the assignment took effect at the time
        indicated by the record timestamp. The RECOMMENDED MSGID value "DEL"
        indicates that the assignment was deleted at the time indicated
        by the record timestamp.</t>
        
      </section>  <!-- hdrFMT -->
      
      <section anchor="data" title="STRUCTURED-DATA Fields">

        <t>This document specifies a value of "asgn" (short for "assignment")
        for the SD-ID field identifying the STRUCTURED-DATA section of the
        record. In addition it specifies the following parameters for use
        within that section. All of these parameters are OPTIONAL. All values
        that are IP addresses are written as a text string in dotted-decimal
        form (IPv4) or as recommended by <xref target="RFC5952"/> (IPv6). </t>
        
        <section anchor="isAddr" title="Incoming IP Source Address Parameter">

          <t>PARAM-NAME: iSA. PARAM-VALUE: the incoming IP source address of the
          packet(s) to which the assignment described by this record applies.</t>

        </section>  <!-- isAddr -->

        <section anchor="osAddr" title="Outgoing IP Source Address Parameter">

          <t>PARAM-NAME: oSA. PARAM-VALUE: the outgoing IP source address of the
          packet(s) to the assignment described by which this record applies.</t>

        </section>  <!-- osAddr -->

        <section anchor="isPort" title="Incoming Source Port Parameter">

          <t>PARAM-NAME: iSP. PARAM-VALUE: the incoming IP source port of the
          packet(s) to the assignment described by which this record applies.</t>

        </section>  <!-- isPort -->

        <section anchor="osPort" title="Outgoing Source Port Parameter">

          <t>PARAM-NAME: oSP. PARAM-VALUE: the outgoing IP source port of the
          packet(s) to which the assignment described by this record applies. If
          the record pertains to the assignment of a range of ports, this
          parameter gives the lowest port number in the range. In the case of a
          range, either parameter oSPct or parameter oSPmx SHOULD also be
          present in the log record.</t>

        </section>  <!-- osPort -->
        
        <section anchor="ctosp" title="Number of Port Numbers Parameter">

          <t>PARAM-NAME: oSPct. PARAM-VALUE: used when the record pertains to
          the assignment of a range of ports (either consecutive or generated by
          a known algorithm). This parameter gives the number of port numbers in
          the range.</t>

        </section>  <!-- ctosp -->
        
        <section anchor="mxosp" title="Highest Outgoing Port Number Parameter">

          <t>PARAM-NAME: oSPmx. PARAM-VALUE: used when the record pertains to
          the assignment of a range of ports (either consecutive or generated by
          a known algorithm). This parameter gives the highest port number in the
          range.</t>

        </section>  <!-- mxosp -->
        
        <section anchor="Prot" title="Protocol Parameter">

          <t>PARAM-NAME: Pr. PARAM-VALUE: an integer indicating the value of
          the Protocol header field (IPv4) or Next Header field (IPv6) in the
          incoming packet(s) to which the assignment described by this record
          applies.</t>

        </section>  <!-- Prot -->
        
        <section anchor="subID" title="Subscriber Identifier Parameter">

          <t>PARAM-NAME: SID. PARAM-VALUE: an arbitrary UTF-8 string identifying
          the subscriber to which this assignment applies. This is intended to
          provide flexibility when the incoming source address will not be
          unique. The value could be a tunnel identifier, layer 2 address, or
          any other value that is convenient to the operator and associated with
          incoming packets.  </t>

        </section>  <!-- subID -->
        
        <section anchor="NATid" title="NAT Identifier Parameter">

          <t>PARAM-NAME: NID. PARAM-VALUE: an arbitrary UTF-8 string identifying
          the NAT making the assignment to which this record applies. Needed
          only if the necessary identification is not provided by the HOSTNAME
          parameter in the log record header.</t>

        </section>  <!-- NATid -->

      </section>  <!-- data -->

    </section>  <!-- recFMT -->
    

    <section anchor="IANA" title="IANA Considerations">
    
      <t>This document requests IANA to make the following assignments to
      the SYSLOG Structured Data ID Values registry. RFCxxxx refers to the
      present document when approved.</t>
      
      <texttable anchor="iana" title="">
        <ttcol align="left">Structured Data ID</ttcol>
        <ttcol align="left">Structured Data Parameter</ttcol>
        <ttcol align="left">Required or Optional</ttcol>
        <ttcol align="left">Reference</ttcol>
        
        <c>asgn</c>
        <c></c>
        <c>OPTIONAL</c>
        <c>RFCxxxx</c>
        
        <c></c>
        <c>iSA</c>
        <c>OPTIONAL</c>
        <c>RFCxxxx</c>
        
        <c></c>
        <c>oSA</c>
        <c>OPTIONAL</c>
        <c>RFCxxxx</c>
        
        <c></c>
        <c>iSP</c>
        <c>OPTIONAL</c>
        <c>RFCxxxx</c>
        
        <c></c>
        <c>oSP</c>
        <c>OPTIONAL</c>
        <c>RFCxxxx</c>
        
        <c></c>
        <c>oSPct</c>
        <c>OPTIONAL</c>
        <c>RFCxxxx</c>
        
        <c></c>
        <c>oSPmx</c>
        <c>OPTIONAL</c>
        <c>RFCxxxx</c>
        
        <c></c>
        <c>Pr</c>
        <c>OPTIONAL</c>
        <c>RFCxxxx</c>
        
        <c></c>
        <c>SID</c>
        <c>OPTIONAL</c>
        <c>RFCxxxx</c>
        
        <c></c>
        <c>NID</c>
        <c>OPTIONAL</c>
        <c>RFCxxxx</c>
      </texttable>

    </section>
    
    <section anchor="Security" title="Security Considerations">
    
      <t>When logs are being recorded for regulatory reasons, preservation
      of their integrity and authentication of their origin is essential. To
      achieve this result, it is RECOMMENDED that the operator deploy 
      <xref target="RFC5848"/>. </t>
      
      <t>Access to the logs defined here while the reported assignments are
      in force could improve an attacker's chance of hijacking a session
      through port-guessing. Even after an assignment has expired, the
      information in the logs SHOULD be treated as confidential, since, if
      revealed, it could help an attacker trace sessions back to a
      particular subscriber or subscriber location. It is therefore
      RECOMMENDED that these logs be transported securely, using <xref
      target="RFC5425"/>, for example, and that they be stored securely at
      the collector.</t>
    </section>
  </middle>

 <back>
    <references title="Normative References">
     &RFC5424;
     &RFC5425;
     &RFC5848;
     &RFC5952;
     &RFC2119;
</references>

</back>
</rfc>