One document matched: draft-ietf-behave-lsn-requirements-01.xml

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [

<!ENTITY RFC2827 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2827.xml">
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!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 RFC5508 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5508.xml">
<!ENTITY RFC6056 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6056.xml">
<!ENTITY I-D.shirasaki-nat444-isp-shared-addr SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.shirasaki-nat444-isp-shared-addr.xml">
<!ENTITY I-D.ymbk-aplusp SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ymbk-aplusp.xml">
<!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">
<!ENTITY I-D.ford-shared-addressing-issues SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ford-shared-addressing-issues.xml">
<!ENTITY I-D.ietf-intarea-server-logging-recommendations SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-intarea-server-logging-recommendations.xml">

]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc strict="yes" ?>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="no" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<rfc category="bcp" docName="draft-ietf-behave-lsn-requirements-01" ipr="trust200902">

 <!-- ***** FRONT MATTER ***** -->

 <front>
   <title abbrev="CGN Requirements">
Common requirements for IP address sharing schemes
   </title>

   <author fullname="Simon Perreault" initials="S." surname="Perreault"
     role="editor">
     <organization>Viagénie</organization>
     <address>
       <postal>
         <street>2875 boul. Laurier, suite D2-630</street>
         <city>Québec</city>
         <region>QC</region>
         <code>G1V 2M2</code>
         <country>Canada</country>
       </postal>
       <phone>+1 418 656 9254</phone>
       <email>simon.perreault@viagenie.ca</email>
       <uri>http://www.viagenie.ca</uri>
     </address>
   </author>

  <author fullname="Ikuhei Yamagata" initials="I." surname="Yamagata">
     <organization abbrev="NTT Communications">
     NTT Communications Corporation</organization>
     <address>
       <postal>
         <street>Gran Park Tower 17F, 3-4-1 Shibaura, Minato-ku</street>
         <city>Tokyo</city>
         <code>108-8118</code>
         <country>Japan</country>
       </postal>
       <phone>+81 50 3812 4704</phone>
       <email>ikuhei@nttv6.jp</email>
     </address>
   </author>

    <author fullname="Shin Miyakawa" initials="S." surname="Miyakawa">
     <organization abbrev="NTT Communications">
     NTT Communications Corporation</organization>
     <address>
       <postal>
         <street>Gran Park Tower 17F, 3-4-1 Shibaura, Minato-ku</street>
         <city>Tokyo</city>
         <code>108-8118</code>
         <country>Japan</country>
       </postal>
       <phone>+81 50 3812 4695</phone>
       <email>miyakawa@nttv6.jp</email>
     </address>
   </author>

   <author fullname="Akira Nakagawa" initials="A." surname="Nakagawa">
     <organization abbrev="Japan Internet Exchange (JPIX)">
	 Japan Internet Exchange Co., Ltd. (JPIX)</organization>
     <address>
       <postal>
         <street>Otemachi Building 21F, 1-8-1 Otemachi, Chiyoda-ku</street>
         <city>Tokyo</city>
         <code>100-0004</code>
         <country>Japan</country>
       </postal>
       <phone>+81 90 9242 2717</phone>
       <email>a-nakagawa@jpix.ad.jp</email>
     </address>
   </author>

    <author fullname="Hiroyuki Ashida" initials="H." surname="Ashida">
     <organization abbrev="iTSCOM">
     its communications Inc.</organization>
     <address>
       <postal>
         <street>541-1 Ichigao-cho Aoba-ku</street>
         <city>Yokohama</city>
         <code>225-0024</code>
         <country>Japan</country>
       </postal>
       <email>ashida@itscom.ad.jp</email>
     </address>
   </author>


   <date month="March" year="2011" />

   <!-- Meta-data Declarations -->

   <area>Transport</area>
   <workgroup>Internet Engineering Task Force</workgroup>
   <keyword>CGN, NAT</keyword>

   <abstract>
     <t>This document defines common requirements for Carrier-Grade NAT (CGN)
       devices.</t>
   </abstract>
 </front>

 <middle>
   <section title="Introduction">
     <t>With the shortage of IPv4 addresses, it is expected that more ISPs may
       want to provide a service where a public IPv4 address would be shared by
       many subscribers (also known as NAT444 <xref
         target="I-D.shirasaki-nat444-isp-shared-addr"/>).  Each subscriber is
       assigned a private address, and a NAT device situated in the ISPs network
       translates between private and public addresses.</t>

     <t>This is not to be considered a solution to the shortage of IPv4
       addresses. It is a service that can conceivably be offered alongside
       others, such as IPv6 services or regular, un-NATed IPv4 service. Some
       ISPs started offering such a service long before there was a shortage of
       IPv4 addresses, showing that there are driving forces other than the
       shortage of IPv4 addresses.</t>

     <t>This document describes behavioural requirements that are to be expected
       of those ISP-controlled NAT devices. Meeting this set of requirements
       will greatly increase the likelihood that subscribers' applications will
       function properly.</t>

     <t>Readers should be aware of potential issues that may arise when sharing
       public address between many subscribers. See <xref
         target="I-D.ford-shared-addressing-issues"/> for details.</t>

     <t>This document builds upon previous works describing requirements for
       generic NAT devices.<xref target="RFC4787"/><xref target="RFC5382"/><xref
         target="RFC5508"/>. These documents still apply in this context. What
       follows are additional requirements, to be satisfied on top of previous
       ones.</t>
   </section>

   <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" />.
	</t>

  <t>
    Readers are expected to be familiar with <xref target="RFC4787" /> and the 
    terms defined there. The following term is used in this document:


    <list style='hanging'>
      <t hangText="Carrier-Grade NAT (CGN):">NAT device placed between a
        subscriber and the Internet in an ISP's network. A CGN translates IP
        addresses and transport-protocol port numbers in the packets that it
        forwards across the border between the internal and external realms.
        <list style="empty">
          <t>Note that the term "carrier-grade" has nothing to do with the
            quality of the NAT device; that is left to discretion of
            implementors. Rather, it is to be understood as a topological
            qualifier: the NAT device is placed in an ISP's network and
            translates the traffic of potentially many subscribers. Those have
            limited or no control over the CGN, whereas they typically have full
            control over a NAT placed on their premises.</t>
        </list>
      </t>
    </list>
  </t>

  <t><xref target="topology"/> summarises the network topology in which CGN
    devices operate.</t>

<figure anchor="topology" title="CGN network topology" align="center">
	<artwork><![CDATA[
                .
                :
                |       Internet     
............... | ...................
                |       ISP network
                |
                |
            ++------++  External realm
........... |  CGN   |...............
            ++------++  Internal realm            
              |    |               
              |    |
              |    |    ISP network
............. | .. | ................
              |    |  Customer premises
      ++------++  ++------++
      |  CPE1  |  |  CPE2  |  etc.
      ++------++  ++------++
]]></artwork>
  </figure>


</section>





<section title="Requirements for CGN devices">

	<t>What follows is a list of requirements for CGN devices. They are in
    addition to those found in other documents such as <xref target="RFC4787"/>,
    <xref target="RFC5382"/>, and <xref target="RFC5508"/>.</t>

  <t>
    <list style="hanging">
      <t hangText="REQ-1:">A CGN MUST have an "IP address pooling" behaviour of
        "Paired".</t>
      <t hangText="Justification:">This is a stronger form of REQ-2 from <xref
          target="RFC4787"/>.</t>
      <t>Note that this requirement applies regardless of the transport
        protocol. In other words, a CGN must use the same external IP address
        mapping for all sessions associated with the same internal IP address,
        be they TCP, UDP, ICMP, something else, or a mix of different
        protocols.</t>
    </list>
  </t>

  <t>
    <list style="hanging">
      <t hangText="REQ-2:">A CGN SHOULD limit the number of external ports (or,
        equivalently, "identifiers" for ICMP) that are assigned per CPE.
        <list style="letters">
          <t>Limits SHOULD be configurable by the CGN administrator.</t>
          <t>Limits MAY be configured and applied independently per transport
            protocol.</t>
          <t>Additionally, it SHOULD be possible to limit the rate at which
            external ports are allocated.</t>
        </list>
      </t>
      <t hangText="Justification:">A CGN can be considered a network resource
        that is shared by competing subscribers. Limiting the number of external
        ports assigned to each CPE mitigates the DoS attack that a subscriber
        could launch against the CGN in order to get a larger share of the
        resource. It ensures fairness among subscribers. Limiting the rate
        of allocation is intended to further help mitigate DoS attacks.</t>
    </list>
  </t>

  <t>
    <list style="hanging">
      <t hangText="REQ-3:">A CGN SHOULD limit the number of TCP sessions per CPE.
        <list style="letters">
          <t>Limits SHOULD be configurable by the CGN administrator.</t>
          <t>Additionally, it SHOULD be possible to limit the rate at which TCP
            sessions are instanciated.</t>
        </list>
      </t>
      <t hangText="Justification:">A NAT needs to keep track of TCP sessions
        associated to each mapping. This state consumes resources for which, in
        the case of a CGN, subscribers may compete. It is necessary to ensure
        that each subscriber has access to a faire share of the CGN's resources.
        Limiting TCP sessions per CPE and per time unit is an effective
        mitigation against inter-subscriber DoS attacks. Limiting the rate of
        TCP session instanciation is intended to further help mitigate DoS
        attacks.</t>
    </list>
  </t>

  <t>
    <list style="hanging">
      <t hangText="REQ-4:">It SHOULD be possible to administratively turn off
        translation for specific destination addresses and/or ports.</t>
      <t hangText="Justification:">It is common for a CGN administrator to
        provide access for subscribers to servers installed in the ISP's
        network, in the external realm. When such a server is able to reach the
        internal realm via normal routing (which is entirely controlled by the
        ISP), translation is unneeded. In that case, the CGN may forward packets
        without modification, thus acting like a plain router.  This may
        represent an important efficiency gain.</t>
      <t><xref target="passthrough"/> illustrates this use-case.</t>
    </list>
  </t>

	<figure anchor="passthrough" title="CGN pass-through" align="center">
	<artwork><![CDATA[ 
X1:x1            X1':x1'            X2:x2    
+---+from X1:x1  +---+from X1:x1    +---+
|   |  to X2:x2  |   |  to X2:x2    | S |
| C |>>>>>>>>>>>>| C |>>>>>>>>>>>>>>| e |
| P |            | G |              | r |
| E |<<<<<<<<<<<<| N |<<<<<<<<<<<<<<| v |
|   |from X2:x2  |   |from X2:x2    | e |
|   |  to X1:x1  |   |  to X1:x1    | r |
+---+            +---+              +---+
]]></artwork>
  </figure>

  <t>
    <list style="hanging">
      <t hangText="REQ-5:">It is RECOMMENDED that a CGN have an
        "Endpoint-Independent Filtering" behaviour.</t>
      <t hangText="Justification:">This is a stronger form of REQ-8 from <xref
          target="RFC4787"/>. An "Address-Dependent Filtering" behaviour is NOT
        RECOMMENDED. This is based on the observation that some games and
        peer-to-peer applications require EIF for the NAT traversal to work. In
        the context of a CGN it is important to minimise application
        breakage.</t>
    </list>
  </t>

  <t>
    <list style="hanging">
      <t hangText="REQ-6:">When a CGN loses state (due to a crash, reboot,
        failover to a cold standby, etc.), it MUST start using a different
        external address pool.</t>
      <t hangText="Justification:">This is necessary in order to prevent
        collisions between old and new mappings and sessions. It ensures that
        all established sessions are broken instead of redirected to a different
        peer. The previous address pool MAY of course be reused after a second
        loss of state.</t>
    </list>
  </t>

</section>

<section title="Logging">
  <t>It may be necessary for CGN administrators to be able to identify a
    subscriber based on external IPv4 address, port, and timestamp in order to
    deal with abuse and lawful intercept requests. When multiple subscribers
    share a single external address, the source address and port that are
    visible at the destination host have been translated from the ones
    originated by the CPE.</t>

  <t>In order to be able to do this, the CGN needs to log the following
    information for each mapping created:
    <list style="symbols">
      <t>internal source address</t>
      <t>internal source port</t>
      <t>external source address</t>
      <t>external source port</t>
      <t>destination address (but see below)</t>
      <t>destination port (but see below)</t>
      <t>timestamp</t>
    </list>
  </t>
  <t>A disadvantage of this is that CGNs under heavy usage may produce large
    amounts of logs, which may require large storage volume.</t>
  <t>Readers should be aware of logging recommendations for Internet-facing
    servers <xref target="I-D.ietf-intarea-server-logging-recommendations"/>.
    With compliant servers, the destination address and port do not need to be
    logged by the CGN. This can help reduce the amount of logging.</t>
</section>

<section title="Bulk Port Allocation">
  <t>So far we have assumed that a CGN allocates one external port for every
    outgoing connection. In this section, the impacts of allocating multiple
    external ports at a time are discussed.</t>
  <t>There is a range of things a CGN can do:
    <list style="numbers">
      <t>For every outgoing connection, allocate one external port.</t>
      <t>For an outgoing connection, create a "bin" of several random external
        ports. Subsequent outgoing connections will use ports from the "bin".
        When the "bin" is full, a new connection causes a new bin to be
        created.  A bin is smaller or equal to the user's maximum port
        limit.</t>
      <t>Same as (2), but the ports allocated to a "bin" are consecutive
        instead of random.</t>
    </list>
  </t>

  <t>Impacts are as follows.
    <list style="hanging">
      <t hangText="Port Utilization:">The mechanisms at the top of the list are
        very efficient in their port utilization.  In that sense, they have good
        scaling properties (nothing is wasted).  The mechanisms at the bottom of
        the list will waste ports.  The number of wasted ports is proportional
        to size of the "bin".</t>

      <t hangText="Logging:">Mechanism (1) creates a lot of log entries.
        Mechanisms (2) and (3) create the same number of log entries, but (3)'s
        log entries are smaller because a range can be expressed very compactly
        by indicating a range (e.g. "12000-12009"). With large "bin" sizes, the
        logging for mechanisms (2) and (3) can approach the logging frequency of
        DHCP servers.</t>
      <t>Mechanism (1) can log destinations while mechanisms (2) and (3) cannot.
        This means that a CGN implementing one of the latter two will rely on
        the remote peer to follow the recommendations in <xref
          target="I-D.ietf-intarea-server-logging-recommendations"/>. If this is
        not acceptable, mechanisms (2) and (3) cannot be used.</t>

      <t hangText="Security:">Mechanisms (1) and (2) provide very good
        security in that ports numbers are not easily guessed.  Easily guessed
        port numbers put subscribers at risk of the attacks described in <xref
          target="RFC6056"/>.  Mechanism (3) provides poor security to
        subscribers, especially if the "bin" size is small.</t>
    </list>
  </t>
</section>

   <section anchor="IANA" title="IANA Considerations">
     <t>There are no IANA considerations.</t>
   </section>
	
   <section anchor="Security" title="Security Considerations">
     <t>If a malicious subscriber can spoof another subscriber's CPE, it may
       cause a DoS to that subscriber by creating mappings up to the allowed
       limit. Therefore, the CGN administrator SHOULD ensure that spoofing is
       impossible. This can be accomplished with ingress filtering, as described
       in <xref target="RFC2827"/>.</t>
   </section>
   <section title="Acknowledgements">
	<t>
Thanks for the input and review by Tomohiro Nishitani, Yasuhiro Shirasaki, Takeshi Tomochika, Kousuke Shishikura, Dai Kuwabara, Tomoya Yoshida, Takanori
Mizuguchi, Arifumi Matsumoto, Tomohiro Fujisaki, Dan Wing, and Dave Thaler.
    Dan Wing contributed much of section 5.
	</t>
   </section>

 </middle>


 <back>
   <references title="Normative References">
     &RFC2119;
     &RFC2827;
     &RFC4787;
     &RFC5382;
     &RFC5508;
     &RFC6056;
   </references>
   <references title="Informative Reference">
     &I-D.shirasaki-nat444-isp-shared-addr;
     &I-D.ford-shared-addressing-issues;
     &I-D.ietf-intarea-server-logging-recommendations;
   </references>

   <section title="Change Log (to be removed by RFC Editor prior to
     publication)">
     <section title="Changed in -01">
       <t>
         <list style="symbols">
           <t>Terminology: LSN is now CGN.</t>
           <t>Imported all requirements from RFCs 4787, 5382, and 5508. This
             allowed us to eliminate some duplication.</t>
           <t>Added references to
             draft-ietf-intarea-server-logging-recommendations
             and draft-ford-shared-addressing-issues.</t>
           <t>Incorporated a requirement from
             draft-xu-behave-stateful-nat-standby-06.</t>
         </list>
       </t>
     </section>
   </section>

 </back>
</rfc>