One document matched: draft-zhou-softwire-b4-nat-00.xml

<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-zhou-softwire-b4-nat-00" ipr="trust200902">
  <front>
    <title abbrev="B4 Behavior in NAT By-pass Solution">DS-Lite AFTR NAT
    Bypass: Co-located B4 and NAT Model</title>

    <author fullname="Xiaohong Deng" initials="X." surname="Deng">
      <organization>France Telecom</organization>

      <address>
        <postal>
          <street></street>

          <city></city>

          <region></region>

          <code></code>

          <country></country>
        </postal>

        <email>xiaohong.deng@orange-ftgroup.com</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>cathyzhou@huawei.com</email>
      </address>
    </author>

    <author fullname="Mohamed Boucadair" initials="M." surname="Boucadair">
      <organization>France Telecom</organization>

      <address>
        <postal>
          <street></street>

          <city>Rennes</city>

          <region></region>

          <code>35000</code>

          <country>France</country>
        </postal>

        <email>mohamed.boucadair@orange-ftgroup.com</email>
      </address>
    </author>

    <author fullname="Gabor Bajko" initials="G." surname="Bajko">
      <organization>Nokia</organization>

      <address>
        <postal>
          <street></street>
        </postal>

        <email>gabor.bajko@nokia.com</email>
      </address>
    </author>

    <author fullname="Tina TSOU" initials="T." surname="Tsou">
      <organization>Huawei Technologies</organization>

      <address>
        <postal>
          <street></street>

          <city></city>

          <code></code>

          <country>P.R. China</country>
        </postal>

        <phone></phone>

        <email>tena@huawei.com</email>
      </address>
    </author>

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

    <abstract>
      <t>This document describes the behavior of the B4 when co-located with a
      NAT while the NAT in the AFTR is disabled. The proposed solution is
      expected to offload the burden on the AFTR, by delegating the NAT to
      B4.</t>
    </abstract>

    <note title="Requirements Language">
      <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>
    </note>
  </front>

  <middle>
    <section title="Introduction">
      <t>As currently defined in <xref
      target="I-D.ietf-softwire-dual-stack-lite"></xref>, B4 element SHOULD
      NOT operate a NAT function because the NAT function will be performed by
      the AFTR in the service provider's network. To reduce the processing
      requirement of NAT device at the network side, address and port
      translation can be made at the customer side, e.g., CPE. For
      convenience, we call this solution as NAT-Bypass.</t>

      <t>To mitigate the port randomization issue identified in <xref
      target="I-D.ietf-intarea-shared-addressing-issues"></xref>, a solution
      is elaborated in <xref target="port_rand"></xref>.</t>

      <t>This document provides descriptions on the B4 behavior when
      supporting NAT-Bypass.</t>
    </section>

    <section title="B4 Behavior">
      <t></t>

      <section title="Provisioning">
        <t>The provisioning of the B4 element is similar to what is defined in
        <xref target="I-D.ietf-softwire-dual-stack-lite"></xref>.</t>
      </section>

      <section title="Plain IPv4 Address">
        <t>A B4 MAY be assigned with a plain IPv4 address.</t>

        <t>When a plain, IPv4 address is assigned, the NAT operations are
        enforced as per current legacy CPEs. The NAT in the AFTR is disabled
        for that user.</t>

        <t>IPv4 datagrams are encapsulated in IPv6 as specified in <xref
        target="I-D.ietf-softwire-dual-stack-lite"></xref>.</t>
      </section>

      <section title="Restricted IPv4 Address">
        <t>In the NAT-Bypass solution, the port set is provisioned to B4
        through PCP option defined in <xref
        target="I-D.tsou-pcp-natcoord"></xref> or specific DHCP options <xref
        target="I-D.bajko-pripaddrassign"></xref>.</t>

        <t>The PCP Server or IPv4 DHCP server may be co-located with the
        AFTR.</t>

        <t>The B4 is responsible for performing NAT and/ALG functions, as well
        as supporting NAT Traversal mechanisms (e.g., UPnP or NAT-PMP).</t>

        <section title="Outgoing Packets Processing">
          <t>Upon receiving an IPv4 packet, the B4 performs NAT using the
          public IPv4 address and port set assigned to it. Then B4
          encapsulates the resulting IPv4 packet into an IPv6 packet, and
          delivers it through IPv6 connectivity to AFTR which will then
          decapsulate the encapsulated packet and forward it through IPv4. The
          destination IPv6 address used for encapsulation should be the AFTR's
          address.</t>
        </section>

        <section title="Incoming Packets Processing">
          <t>Upon receipt of IPv4-in-IPv6 packet from AFTR, B4 will
          decapsulate the packet and translate the public IPv4 address to the
          private IPv4 address. Finally, it delivers the packet to the host
          using the translated IPv4 address. The source IPv6 address used for
          encapsulation at AFTR is the AFTR's address, and the destination
          address is set to the external address of B4.</t>
        </section>
      </section>

      <section title="Stateless Encapsulation">
        <t>B4 may implement the stateless encapsulation specified in Section
        4.4 of <xref target="I-D.ymbk-aplusp"></xref>.</t>
      </section>

      <section title="Fragmentation and Reassembly">
        <t>No change to Section 5.3 of <xref
        target="I-D.ietf-softwire-dual-stack-lite"></xref>.</t>
      </section>

      <section title="DNS">
        <t>The DNS behavior is the same as described in <xref
        target="I-D.ietf-softwire-dual-stack-lite"></xref>.</t>
      </section>
    </section>

    <section title="Security Considerations">
      <t></t>

      <section anchor="port_rand" title="Port Randomization">
        <t>A successful attack against the TCP or UDP requires the attacker to
        have knowledge of a valid five-tuple (protocol, source IP address,
        source port, destination IP address, destination port). As the
        destination IP, the protocol and the destination port together
        identifies a specific service on a specific target that the attacker
        will be spoofing, they are usually known by an attacker. Take BGP TCP
        RESET attack for example, an attacker assumes the destination port of
        179 for BGP. When it comes to Domain Name System (DNS) cache poisoning
        attack, a hacker assumes the destination port of 53 (the port number
        IANA has assigned for DNS). There is a chance source IP is also known
        by an attacker. Therefore, for an attacker, the difficult part of
        guessing five-tuple is source IP and the TCP/UDP source port which is
        different per TCP/UDP session. Random source ports could increase the
        numerical guessing space, thereby increasing the difficulty of an
        attack.</t>

        <t>As a result, it is recommended that NAT devices implement random
        source port selection algorithms in <xref target="RFC6056"></xref>.
        However, contiguous port set allocation might be hurdle to port
        randomization. A simple non-contiguous port set allocation algorithm
        is therefore proposed to achieve a better port randomization NAT.</t>

        <t>On every external IPv4 address, according to port set size N,
        log2(N) bits are randomly choosing by AFTR as subscribers
        identification bit (s bit) among 1st and 16th bits. Take a sharing
        ration 1:32 for example, <xref target="first_example"></xref> shows an
        example of 5 random selected bits of s bit.<figure align="center"
            anchor="first_example"
            title="A s bit selection example (on a sharing ration 1:32 address).">
            <artwork>
|1st |2nd |3rd |4th |5th |6th |7th | 8th|
+----+----+----+----+----+----+----+----+
| 0  |  s | 0  | 0  | s  | 0  | s  |  0 |
+----+----+----+----+----+----+----+----+
|9th |10th|11th|12th|13th|14th|15th|16th|
+----+----+----+----+----+----+----+----+
| s  | 0  |  s | 0  | 0  | 0  | 0  | 0  | 
+----+----+----+----+----+----+----+----+
</artwork>
          </figure></t>

        <t>Subscriber ID pattern is formed by setting all the s bits to 1 and
        other trivial bits to 0. <xref target="nd_example"></xref> illustrates
        an example of subscriber ID pattern on a sharing ration 1:32 address.
        Note that the subscriber ID pattern will be different, guaranteed by
        the random s bit selection, on every restricted IP address no matter
        whether the sharing ratio varies.<figure align="center"
            anchor="nd_example"
            title="A subscriber ID pattern example (on a sharing ration 1:32 address).">
            <artwork>
|1st |2nd |3rd |4th |5th |6th |7th | 8th|
+----+----+----+----+----+----+----+----+
| 0  |  1 | 0  | 0  | 1  | 0  | 1  |  0 |
+----+----+----+----+----+----+----+----+
|9th |10th|11th|12th|13th|14th|15th|16th|
+----+----+----+----+----+----+----+----+
| 1  | 0  |  1 | 0  | 1  | 0  | 0  | 0  |
+----+----+----+----+----+----+----+----+ 
</artwork>
          </figure></t>

        <t>Subscribers ID value is then assigned by setting subscriber ID
        pattern bits according to a subscriber identification and other
        trivial bits setting to 1. <figure align="center"
            anchor="third_example"
            title="A subscriber ID value example (0# subscriber on this restricted address).">
            <artwork>
|1st |2nd |3rd |4th |5th |6th |7th | 8th|
+----+----+----+----+----+----+----+----+
| 0  |  1 | 0  | 0  | 1  | 0  | 1  |  0 | 
+----+----+----+----+----+----+----+----+
|9th |10th|11th|12th|13th|14th|15th|16th|
+----+----+----+----+----+----+----+----+
| 1  | 0  |  1 | 0  | 1  | 0  | 0  | 0  |
+----+----+----+----+----+----+----+----+
</artwork>
          </figure></t>

        <t>Subscriber ID pattern and subscriber ID value together uniquely
        defines a non-overlapping port set on a restricted IP address.</t>

        <t>Pseudo-code shown in the <xref target="algo"></xref> describe how
        to use subscriber ID pattern and subscriber ID value to implement a
        random ephemeral port selection in a restricted port set.<figure
            align="center" anchor="algo"
            title="Random ephemeral port selection of restricted port set algorithm.">
            <artwork>
do{
    restricted_next_ephemeral = random()|| customer_ID_pattern
                                & customer_ID_value;
    if(five-tuple is unique)
    return restricted_next_ephemeral;
}
</artwork>
          </figure></t>
      </section>
    </section>

    <section anchor="iana" title="IANA Considerations">
      <t>None.</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include='reference.I-D.ietf-softwire-dual-stack-lite'?>

      <?rfc include='reference.RFC.2119'?>

      <?rfc include='reference.RFC.6056'?>
    </references>

    <references title="informative References">
      <?rfc include='reference.I-D.tsou-pcp-natcoord'?>

      <?rfc include='reference.I-D.bajko-pripaddrassign'?>

      <?rfc ?>

      <?rfc include='reference.I-D.ymbk-aplusp'?>

      <?rfc include='reference.I-D.ietf-intarea-shared-addressing-issues'?>
    </references>
  </back>
</rfc>