Using PCP To Coordinate Between the CGN and Home Gateway Via Port Allocation
draft-tsou-pcp-natcoord-04

Internet Engineering Task Force                                  C. Zhou
Internet-Draft                                       Huawei Technologies
Intended status: Standards Track                                 T. Tsou
Expires: July 10, 2012                         Huawei Technologies (USA)
                                                                 X. Deng
                                                            M. Boucadair
                                                          France Telecom
                                                                  Q. Sun
                                                           China Telecom
                                                         January 7, 2012

   Using PCP To Coordinate Between the CGN and Home Gateway Via Port
                               Allocation
                       draft-tsou-pcp-natcoord-04

Abstract

   Consider a situation where a subscriber's packets are subject to two
   levels of NAT, with both NATs operating under the control of the ISP.
   An example of this would be a NATing Home Gateway forwarding packets
   to a Large Scale NAT.  This memo proposes that advantage be taken of
   the presence of the second NAT, to offload the burden on the Large
   Scale NAT by delegation to the Home Gateway.  Enhancements to the
   Port Control Protocol are specified to achieve this.  The proposed
   solution applies also for DS-Lite where the AFTR offloads it NAT to
   the B4 element.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on July 10, 2012.

Copyright Notice

   Copyright (c) 2012 IETF Trust and the persons identified as the

Zhou, et al.              Expires July 10, 2012                 [Page 1]
Internet-Draft   NAT Coordination Using Port Allocation     January 2012

   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.

Table of Contents

   1.  Application Scenario . . . . . . . . . . . . . . . . . . . . .  3
   2.  Proposed Solution  . . . . . . . . . . . . . . . . . . . . . .  3
     2.1.  Delegation of Port Sets  . . . . . . . . . . . . . . . . .  3
     2.2.  Packet Processing At the Home Gateway and LSN  . . . . . .  4
     2.3.  Proposed Enhancements To and Usage Of the Port Control
           Protocol . . . . . . . . . . . . . . . . . . . . . . . . .  5
   3.  PCP Coordination Function  . . . . . . . . . . . . . . . . . .  6
     3.1.  Use Cases  . . . . . . . . . . . . . . . . . . . . . . . .  6
     3.2.  Port Range Options . . . . . . . . . . . . . . . . . . . .  6
       3.2.1.  NAT Bypass PCP Option  . . . . . . . . . . . . . . . .  6
       3.2.2.  Port Range Options . . . . . . . . . . . . . . . . . .  8
         3.2.2.1.  Port_Range_Option  . . . . . . . . . . . . . . . .  8
         3.2.2.2.  Cryptographically_Random_Port_Range_Option . . . .  9
   4.  Security Considerations  . . . . . . . . . . . . . . . . . . . 10
   5.  Additional Author  . . . . . . . . . . . . . . . . . . . . . . 10
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 10
   7.  Additional Author  . . . . . . . . . . . . . . . . . . . . . . 10
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 11
     8.2.  informative References . . . . . . . . . . . . . . . . . . 11
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11

Zhou, et al.              Expires July 10, 2012                 [Page 2]
Internet-Draft   NAT Coordination Using Port Allocation     January 2012

1.  Application Scenario

   A Large Scale NAT (LSN) is responsible for translating source
   addresses and ports for packets passing into and out of the provider
   network.  Especially for large scale service providers, one LSN may
   need to support at least tens of thousands of customers, resulting in
   heavy processing requirements for the LSN.

   In some broadband scenarios an additional NAT is present at the edge
   of the customer network.  For convenience we will call this the Home
   Gateway.  The load on the LSN could be reduced if address and port
   translation were actually done at the Home Gateway.  Achieving such
   an outcome would require coordination between the two devices.  This
   memo makes a detailed proposal for the required coordination
   mechanism.

2.  Proposed Solution

2.1.  Delegation of Port Sets

   The basic proposal made in this memo is to provide the means for the
   Home Gateway to request that the LSN delegate to it a set of ports
   and optionally an external address that will be associated with those
   ports.  It is proposed to use the Port Control Protocol (PCP)
   [ID.port-control-protocol] to achieve this.  The procedure is
   illustrated in Figure 1.

      The LSN allocation of port sets MAY take into account the advice
      given in [ID.behave-natx4-log-reduction].

      [RFC6431]defined three port range allocation algorithms:
      contiguous, non-contiguous and pseudo-random.  This document will
      describe the PCP options to support these port range allocation.

Zhou, et al.              Expires July 10, 2012                 [Page 3]
Internet-Draft   NAT Coordination Using Port Allocation     January 2012

               Home Gateway                      LSN
                    |                             |
                    |                             |
                    |------(1)PCP Request-------->|
                    |                             |
                    |                        +----+----+
                    |                        | Create  |
                    |                        |NAT entry|
                    |                        +----+----+
                    |                             |
                    |<-----(2)PCP Response-----|
                    |          (Port Range)       |
                    |                             |

                Figure 1: Acquiring a Delegated Port Range

   If the Home Gateway allocates all of the ports that have been
   delegated to it for a given protocol, it MAY send a request to the
   LSN for another delegated set of ports.  If the LSN satisfies that
   request, the Home Gateway MUST release the additional set as soon as
   possible.  To achieve this, the Home Gateway May follow a policy for
   allocation of additional ports to flows, that has the same effect as
   searching for "free" ports in the port sets in the order in which
   they were delegated to the Home Gateway.  A port SHOULD be considered
   "free" if no traffic has been observed through it for the timeout
   interval specified for the protocol concerned, as discussed in
   [ID.behave-natx4-log-reduction], or if the Home Gateway knows through
   other means (e.g., host reboot) that it is no longer in use.

2.2.  Packet Processing At the Home Gateway and LSN

   The Home Gateway maps outgoing flows to the delegated ports.  If an
   external address was received it uses that for the source address;
   otherwise it retains the private address of the Home Gateway as the
   source address.

      The procedures are more complicated, of course, if the IP version
      running externally to the LSN is different from the IP version
      running between the Home Gateway and the LSN, since the
      destination address also has to be translated.  The details depend
      on the particular transition mechanism in use, and are left as an
      exercise for the reader.

   If the private address is retained, the LSN recognizes it from the
   original delegation request and changes the source address but not
   the port before forwarding the packet.  If the external public
   address was used, the LSN is not useful and another device may be
   needed to allocate the port range.

Zhou, et al.              Expires July 10, 2012                 [Page 4]
Internet-Draft   NAT Coordination Using Port Allocation     January 2012

   In the reverse direction, the LSN recognizes the public destination
   address and port of an incoming packet as belonging to a delegated
   range for the Home Gateway.  It translates the destination address,
   if necessary, leaving the destination port unchanged.  The Home
   Gateway translates the destination port and address to the
   corresponding values in the customer network and forwards the packet
   in turn.

2.3.  Proposed Enhancements To and Usage Of the Port Control Protocol

   This document proposes the following new option for MAP opcodes:
   PORT_SET_REQUESTED.

      option number: to be allocated

      is valid for OpCodes: MAP44, MAP64, MAP46, or MAP66

      is included in responses: MUST

      has length: 0 in requests, 4 in successful responses.  [As
      mentioned above, if non-consecutive sets of ports are allocated,
      we may want to add parameters of the algorithm for deriving the
      complete set from the initial value provided in the "assigned
      external port" field of the response.]

      may appear more than once: no

   When constructing a PCP request with the PORT_RANGE_REQUESTED option,
   the client MUST set the "internal port" field of the request to zero.
   If requesting a new set of delegated ports, the client MAY set the
   "requested external port" field to a non-zero value.  If releasing a
   set of delegated ports (i.e., by setting the "Requested lifetime"
   field to zero), the client MUST set the "requested external port"
   field to the value of the "assigned external port" field of the
   earlier response from the server.  The remaining fields of the PCP
   request MUST be set as directed by [ID.port-control-protocol]

   Upon receiving a PCP request with the PORT_RANGE_REQUESTED option,
   the server MAY reject it using return codes 151 - NOT_AUTHORIZED, or
   152 - USER_EX_QUOTA.  In this case, the PORT_SET_REQUESTED option in
   the response MUST have zero length (no data).  If the server chooses
   to honour the request, it MUST place the value of the first port in
   the assigned set in the "assigned external port" field of the
   response.  It MUST set the length of the PORT_RANGE_REQUESTED option
   in the response to 4, and MUST provide the number of ports in the
   delegated set as the value of the option.

Zhou, et al.              Expires July 10, 2012                 [Page 5]
Internet-Draft   NAT Coordination Using Port Allocation     January 2012

3.  PCP Coordination Function

3.1.  Use Cases

   PCP can be used to control an upstream device to achieve the
   following goals:

   1.  A plain (i.e., a non-shared) IP address can be assigned to a
       given subscriber because the subscriber subscribed to a service
       which uses a protocol that don't embed a transport number or
       because the NAT is the only deployed platform to manage IP
       addresses.

   2.  An application (e.g., sensor) does not need to listen to a whole
       range of ports available on a given IP address.  Only a limited
       set of ports are used to bind its running services.  For such
       devices, the external port(s) and IP address can be delegated to
       that application and therefore avoid enforcing NAT in the network
       side for its associated flows.  The NAT in the PCP- controlled
       device should be bypassed.

   3.  A device able to restrict its source ports can be delegated an
       external port restricted IP address.  The PCP- controlled device
       should be instructed to by-pass the NAT when handling flows
       destined/issued to that device.

3.2.  Port Range Options

   This section defines new PCP options which are meant to instruct a
   PCP-controlled device to by-pass the NAT function whenever required.

3.2.1.  NAT Bypass PCP Option

   This option (Figure 2) is used by a PCP Client to indicate to the PCP
   Server to not apply any NAT operation to a corresponding binding.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     TBA       |   Reserved    |            0x00               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                        Figure 2: NAT Bypass option

   This option:

Zhou, et al.              Expires July 10, 2012                 [Page 6]
Internet-Draft   NAT Coordination Using Port Allocation     January 2012

   o  name: NAT Bypass option

   o  number: TBA

   o  purpose: A PCP Client inserts this option in a PCP request to
      indicate to the PCP Server to not apply the NAT function.  The NAT
      is then by-passed in the PCP-controlled device.

   o  is valid for OpCodes:all.

   o  length:The length MUST be set to 0.

   o  may appear in:request

   o  maximum occurrences:none

   A PCP Client inserts this option in a PCP request to indicate to the
   PCP Server to not apply the NAT function.  The NAT is then by-passed
   in the PCP-controlled device.

   A PCP Server which supports the NAT by-pass feature MUST include this
   option in its response to the requesting PCP Client.  In particular,
   when the PCP Server does not include this option in its response, the
   PCP Client should deduce that the NAT will be enforced in the PCP-
   controlled device; a NAT will be then enforced in the PCP-controlled
   device.

   The NAT bypass feature can be associated with a plain IP address.  In
   such case, a full external IP address is returned to the requesting
   PCP Client.  The client is then able to use all ports associated with
   that IP address (i.e., without any restriction).  Furthermore, this
   "full" address can be used to access services which do not rely on
   protocols embedding a port number (e.g., some IPsec modes).

   In some cases, the PCP Client can request the by-pass of the NAT but
   without requiring a full IP address (e.g., for the use cases
   described in bullet 2 and 3 of Section 3.1).  In such scenario, in
   addition to the NAT by-pass option, the PCP Client includes in its
   PCP request a Port Set Option (Section 3.2.2.1).  More information
   about this option is provided hereafter.

   The requested lifetime in the PCP MAP request is set to the available
   lifetime of the port set.  If the lifetime is set to zero, it means
   that the requested port set should be deleted.  Internal port,
   external port and the external address are all invalid.

Zhou, et al.              Expires July 10, 2012                 [Page 7]
Internet-Draft   NAT Coordination Using Port Allocation     January 2012

3.2.2.  Port Range Options

   The Port_Range options are used to specify one set of ports
   pertaining to a given IP address.  As defined in [RFC6431],there are
   three kinds of port range: contiguous, non-contiguous and random.
   The Port Range Value and Port Range Mask are used to specify one
   range of ports (contiguous or non-contiguous) pertaining to a given
   IP address.  A cryptographically random Port Range Option may be used
   as a mitigation tool against blind attacks.  We will describe the two
   port set PCP options in this section.

3.2.2.1.  Port_Range_Option

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |M|         Reserved            |       Port Range Value        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     Port Range Mask           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                        Figure 3: Port_Range_Option

   o  M: mode bit.  The mode bit indicates the mode for which the port
      range is allocated.  A value of zero indicates that the port
      ranges are delegated, while a value of 1 indicates that the port
      ranges are port-forwarded.

   o  Port Range Value (PRV): The PRV indicates the value of the
      significant bits of the Port Mask.  By default, no PRV is
      assigned.

   o  Port Range Mask (PRM): The Port Range Mask indicates the position
      of the bits that are used to build the Port Range Value.  By
      default, no PRM value is assigned.  The 1 values in the Port Range
      Mask indicate by their position the significant bits of the Port
      Range Value.

   This option:

   o  name: Port range option

   o  number: TBA

   o  purpose: A PCP Client inserts this option in a PCP request to
      specify one set of ports (contiguous or not contiguous) pertaining
      to a given IP address.

Zhou, et al.              Expires July 10, 2012                 [Page 8]
Internet-Draft   NAT Coordination Using Port Allocation     January 2012

   o  is valid for OpCodes:all.

   o  length:The length MUST be set to 0.

   o  may appear in:request and response

   o  maximum occurrences:none

3.2.2.2.  Cryptographically_Random_Port_Range_Option

   The cryptographically random Port Range PCP Option adheres to the
   format defined in [ID.port-control-protocol].

    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |M|          Reserved           |          function             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        starting point         |   number of delegated ports   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             key K               ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ...                                                           ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ...                                                           ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ...                                                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

           Figure 4: Cryptographically_Random_Port_Range_Option

   o  M: mode bit.  The mode bit indicates the mode for which the port
      range is allocated.  A value of zero indicates that the port
      ranges are delegated, while a value of 1 indicates that the port
      ranges are port-forwarded.

   o  Function: A 16-bit field whose value is associated with predefined
      encryption functions.  This specification associates value 1 with
      the predefined function described in Section 2.2.1 of [RFC6431].

   o  Starting Point: A 16-bit value used as an input to the specified
      function.

   o  Number of delegated ports: A 16-bit value specifying the number of
      ports delegated to the client for use as source port values.

   o  Key K: A 128-bit key used as input to the predefined function for
      delegated port calculation.

Zhou, et al.              Expires July 10, 2012                 [Page 9]
Internet-Draft   NAT Coordination Using Port Allocation     January 2012

   This option:

   o  name: Cryptographically Random Port Range Option

   o  number: TBA

   o  purpose: A PCP Client inserts this option in a PCP request to
      specify one set of random ports pertaining to a given IP address.
      The random ports can be achieved by defining a function that takes
      as input a key 'K' and an integer 'x' within the 1024-65535 port
      range and produces an output 'y' also within the 1024-65535 port
      range.

   o  is valid for OpCodes:all.

   o  length:The length MUST be set to 0.

   o  may appear in:request and response

   o  maximum occurrences:none

4.  Security Considerations

   Will do later.

5.  Additional Author

   Xiaohong Deng <xiaohong.deng@orange-ftgroup.com> joined the list of
   authors for version -03 of this draft.

6.  IANA Considerations

   Will register the new option if this draft goes through as a
   standalone document rather than being incorporated into the base
   protocol.

7.  Additional Author

   Gabor Bajko

   Nokia

   Email: gabor.bajko@nokia.com

Zhou, et al.              Expires July 10, 2012                [Page 10]
Internet-Draft   NAT Coordination Using Port Allocation     January 2012

8.  References

8.1.  Normative References

   [ID.port-control-protocol]
              Wing, D., "Port Control Protocol (PCP)", December 2011.

   [RFC6431]  Boucadair, M., Levis, P., Bajko, G., Savolainen, T., and
              T. Tsou, "Huawei Port Range Configuration Options for PPP
              IP Control Protocol (IPCP)", RFC 6431, November 2011.

8.2.  informative References

   [ID.behave-natx4-log-reduction]
              Tsou, T., Li, W., and T. Taylor, "Port Management To
              Reduce Logging In Large-Scale NATs", September 2010.

Authors' Addresses

   Cathy Zhou
   Huawei Technologies
   Bantian, Longgang District
   Shenzhen  518129
   P.R. China

   Phone:
   Email: cathy.zhou@huawei.com

   Tina Tsou
   Huawei Technologies (USA)
   2330 Central Expressway
   Santa Clara, CA 95050
   USA

   Phone: +1 408 330 4424
   Email: Tina.Tsou.Zouting@huawei.com

   Xiaohong Deng
   France Telecom

   Email: xiaohong.deng@orange-ftgroup.com

Zhou, et al.              Expires July 10, 2012                [Page 11]
Internet-Draft   NAT Coordination Using Port Allocation     January 2012

   Mohamed Boucadair
   France Telecom
   Rennes,   35000
   France

   Email: mohamed.boucadair@orange-ftgroup.com

   Qiong Sun
   China Telecom
   P.R.China

   Phone: 86 10 58552936
   Email: sunqiong@ctbri.com.cn

Zhou, et al.              Expires July 10, 2012                [Page 12]