[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits] [IPR]

Versions: 00 01 02 03 04

Network WG                                                  Gabor Bajko
Internet Draft                                         Teemu Savolainen
Intended Status: Experimental                                     Nokia
Expires: March 27, 2011                                    M. Boucadair
                                                               P. Levis
                                                         France Telecom
                                                     September 27, 2010


                 Port Restricted IP Address Assignment
                     draft-bajko-pripaddrassign-03


Abstract

   This document defines an IPv4 DHCP Option and related methods to
   allocate the same IPv4 address to multiple nodes by sharing the
   available port space. These options can be used in the context of
   port range-based solutions (port range delegation) or NAT-based ones
   (port delegation or port forwarding).

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 March 27, 2011.

Copyright Notice

   Copyright (c) 2010 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.


Bajko                   Expires March 27, 2011               [Page 1]

Port Restricted IP address assignment                   September 2010

Conventions used in this document

   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].

Terminology and Abbreviations used in this Document

   This document makes use of the following terms:

   - Port restricted IPv4 address: an IP address which can only be used
     in conjunction with the specified port or range of ports. Port
     restriction refers to all known transport protocols (e.g., UDP,
     TCP, SCTP, DCCP).

   - Delegated port or port range: it is a port or a range of ports
     belonging to an IP address managed by an upstream device (such as
     NAT), which are delegated to a client for use as source address
     and port when sending packets.

   - Forwarded port or port range: it is a port or a range of ports
     belonging to an IP address managed by an upstream device such as
     (NAT), which is/are statically mapped to the internal IP address
     of the client and same port number of the client.


   CGN          Carrier Grade Network Address Translation
   CPE          Consumer Premises Equipment, a device that resides
                between internet service provider's network and
                consumers' network.
   PRA          Port Restricted IPv4 Address





















Bajko                   Expires March 27, 2011               [Page 2]

Port Restricted IP address assignment                   September 2010

Table of Content

   1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . .4
   2. Port Randomization . . . . . . . . . . . . . . . . . . . . . . .5
   3. DHCPv4 Option for allocating port restricted public IPv4
      address . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
   3.1 Port Delegation with Port Mask Allocation . . . . . . . . . . .7
   3.2 Port Delegation with Random Port Delegation Function . . . . . 7
   3.3 Port Forwarding with Port Mask Allocation . . . . . . . . . . .8
   3.4 Port Forwarding with Random Port Delegation Function . . . . . 9
   4. Port Mask Sub-Option Usage . . . . . . . . . . . . . . . . . . .9
   4.1 Illustration Examples . . . . . . . . . . . . . . . . . . . . .9
   5. Random Port Delegation Function . . . . . . . . . . . . . . . .11
   6. Option Usage . . . . . . . . . . . . . . . . . . . . . . . . . 12
   6.1 Client Behaviour . . . . . . . . . . . . . . . . . . . . . . .12
   6.2 Server Behaviour . . . . . . . . . . . . . . . . . . . . . . .14
   7. Applicability . . . . . . . . . . . . . . . . . . . . . . . . .15
   8. IANA considerations . . . . . . . . . . . . . . . . . . . . . .15
   9. Security considerations. . . . . . . . . . . . . . . . . . . . 16
   10. Normative References . . . . . . . . . . . . . . . . . . . . .16
   11. Informative References . . . . . . . . . . . . . . . . . . . .16
   12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . .17
   Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . .17






























Bajko                   Expires March 27, 2011               [Page 3]

Port Restricted IP address assignment                   September 2010

1. Introduction

   There are a number of possible solutions to deal with the problem of
   transitioning from IPv4 to IPv6; however none of them is a one fits
   all solution.

   As complementary solution for the IPv4-IPv6 coexistence period, this
   document describes a method, using a vendor specific IPv4 DHCP
   [RFC2131] [RFC2132] Option that allows servers to assign port
   restricted IPv4 addresses to requesting clients. By assigning the
   same IPv4 address to multiple clients, IPv4-only services will
   continue to be delivered to subscribers without any degradation nor
   perceived impact. Furthermore, service providers can continue to
   propose service offerings with sustainable customer base.

   The proposed solution is intended to be used by large ISPs, who as
   of the date of writing this document, have a large enough IPv4
   address pool to be able to allocate one public IPv4 address for each
   and every client. They expect though that the situation is
   unsustainable and they will soon not be able to provide every client
   with a public IPv4 address. Such ISPs have two possibilities to
   choose from:
   - deploy Network Address Translation (NAT), which can be a
   significant investment for ISPs not having NATs yet. The address
   space limitations of [RFC1918] may even force these large ISPs to
   deploy double NATs, which come with all the harmful behaviour of
   Carrier Grade NATs (CGN), as described in [MAEN2008]; or
   - allocate fragments of the same public IPv4 address directly to
   multiple clients (which can be CPEs or end hosts), thus avoid the
   cost of deploying multiple layers of NATs or Carrier Grade NATs. It
   is however assumed, that the demand for IPv4 addresses will decrease
   in the not so distant future, being taken over by IPv6, as the
   proposal in this draft is not by any means a permanent solution for
   the IPv4 address exhaustion problem. In fact, some presented
   deployment scenarios require existence of IPv6 access network.

   For ISPs not having NATs yet, a solution not requiring NATs would
   probably be preferred. For some other ISPs, who already have NATs in
   place, increasing the capacity of their NATs might be a viable
   alternative.

   In other deployment scenarios, allocation of shared addresses to
   devices at the edge of the network would result in distribution of
   NAT functionality to the edges, in some cases even to CPEs [APLUSP].

   This document proposes to use new IPv4 DHCP Option to allocate port-
   restricted IPv4 addresses, or port forwardeding with port
   preservation, to the clients. This method is meant to be an IPv4 to
   IPv6 transition tool, to be only temporarily used during the period
   when the demand for public IPv4 addresses will exceed the
   availability of them.


Bajko                   Expires March 27, 2011               [Page 4]

Port Restricted IP address assignment                   September 2010

   The port restricted IPv4 address option described in this document
   can be used in various deployment scenarios, some of which are
   described in [APLUSP].

   The usage of the options defined in this document are intended to be
   used in an A+P architecture [APLUSP], where a node can always source
   packets from any port number. If the client.s packet source port is
   not within the allocated range, the packets will be NATted. If the
   source port is from the allocated range, it is either not NATed or
   is port forwarded with port number preservation.

2. Port Randomization

   It is well documented that attackers can perform "blind" attacks
   against transport protocols. The consequences of these attacks range
   from throughput-reduction to broken connections or data corruption.
   These attacks rely on the attacker's ability to guess or know the
   five-tuple (Protocol, Source Address, Destination Address, Source
   Port, Destination Port) that identifies the transport protocol
   instance to be attacked. Most of these attacks can be prevented by
   randomly selecting the client source port number such that the
   possibility of an attacker guessing the exact value is reduced.
   [RANDOMPORT] defines a few algorithms which can select a random port
   from the available port range. Clients usually have the (1024,
   65535) port range at their disposal to select a random, not yet used
   port.

   When an IP address is allocated to multiple clients, the source port
   range has to be divided between the clients. The smaller the port
   range, the easier is for an attacker to guess the next port the
   client is going to use. Therefore, it is imperative to divide the
   port range between clients sharing the same IP address in such a way
   that random selection is preserved. This document proposes two
   different methods for port allocation, which preserves partly or
   completely the randomness of the source ports:

      o The first mechanism uses a port mask with a bit locator to
        communicate a range or multiple ranges of ports to a client.
        Randomness is preserved when the client is able to select a
        port randomly across all the available port ranges. The
        algorithms described in [RANDOMPORT] can be used to select a
        random port from one port range, but implementations may find
        it difficult to select random ports across port ranges. Another
        alternative is to assign non contiguous port ranges. Guessing a
        port number within a non-contiguous port ranges is not trivial.

      o The second mechanism uses a cryptographic function to pre-
        allocate random ports from the entire port range. The key and
        other input parameters are communicated to the client, which
        can calculate the ports it can use. The 'side effect' of this
        mechanism is that the client is forced to use random ports, as
        a number of random ports allowed to be used by the client are

Bajko                   Expires March 27, 2011               [Page 5]

Port Restricted IP address assignment                   September 2010

        pre-allocated by the server. When this mode is used, the
        network equipments in charge of routing the inbound packets
        towards the clients may require more processing resources.


















































Bajko                   Expires March 27, 2011               [Page 6]

Port Restricted IP address assignment                   September 2010

3. IPv4 DHCP Option for Allocating Port Restricted Public IPv4 Address

   This section defines an encapsulated vendor specific IPv4 DHCP Option
   as per [RFC2132], which allows allocation of port restricted IPv4
   addresses.

   The format for the Option 43 vendor-specific information item is
   depicted in Figure 1.

    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
                                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                   | Option Code   |    length     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Sub-Option 1                              |
   .                                                               .
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       ...                                     |
   .                                                               .
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Sub-Option n                              |
   .                                                               .
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    Figure 1: Port Restricted IP Address DHCP Option format

      Option Code
        Option Code
          OPTION-IPv4-PRA (vendor specific) - 1 byte

        Length
          An 8-bit field indicating the length of the option excluding
          the 'Option Code' and the 'Length' fields.

        Sub-options
          A series of DHCPv4 sub-options.

   The sub-option layout is depicted in Figure 2.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Sub-opt Type |    length     |              DATA...          .
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   .                 ...DATA                                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   Figure 2: Port Restricted IP Address Sub-option layout


   The sub-option types defined in this document are:
   1    Port delegation with port mask allocation
   2    Port delegation with random port delegation function
   3    Port forwarding with port mask allocation
   4    Port forwarding with random port delegation function


Bajko                   Expires March 27, 2011               [Page 7]

Port Restricted IP address assignment                   September 2010

   Length: an 8-bits field indicating the length of the sub-option
   excluding the 'Sub-opt Type' and the 'Length' fields. The value of
   the length field is 8 when the Sub-opt Type equals 1, 26 when the
   Sub-opt Type equals 2, 12 when the Sub-opt Type equals 3 and 30 when
   the Sub-opt Type equals 4.

3.1 Port Delegation with Port Mask Allocation

   The format of the DATA field when sub-option type is set to 1 is
   shown in Figure 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         IPv4 address                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Port Range Value          |       Port Range Mask         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Figure 3: Port Range sub-option

   IPv4 address
        The IPv4 address allocated to the client by the DHCP server, to
        be used as source address for the outgoing packets.


   Port Range Value and Port Range Mask
        Port Range Value indicates the value of the mask to be applied
        and Port Range Mask indicates the position of the bits which
        are used to build the mask.

   Section 4 describes how the client derives the allocated port range
   from the Port Range Value and Port Range Mask values.

3.2 Port Delegation with Random Port Delegation Function

   The format of the DATA field when sub-option type is set to 2 is
   shown in Figure 4.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         IPv4 address                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        function               |         starting point        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    number of delegated ports  |         key K               ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ...                                                           ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ...                                                           ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ...                                                           ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Bajko                   Expires March 27, 2011               [Page 8]

Port Restricted IP address assignment                   September 2010

   ... key K                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   Figure 4: Random Port delegation sub-option


   IPv4 address
        The IPv4 address allocated to the client by the DHCP server, to
        be used as source address for the outgoing packets

   Function
        A 16 bits field whose value is associated with predefined
        encryption functions. This specification associates value 1
        with the predefined function described in Section 5.

   Starting Point
        A 16 bits value used as an input to the specified function.


   Number of delegated ports
        A 16 bits value specifying the number of ports delegated to the
        client for use as source port values.

   Key K
        A 128 bits key used as input to the predefined function for
        delegated port calculation.

3.3 Port forwarding with port mask allocation

   The format of the DATA field when sub-option type is set to 3 is
   depicted in Figure 5.


   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         IPv4 address                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 External IPv4 address                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Port Range Value          |       Port Range Mask         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   Figure 5: External IP Address sub-option


   IPv4 address
       The IPv4 address allocated to the client by the DHCP server, to
       be used as source address for the outgoing packets.


   Port Range Value and Port Range Mask
        Port Range Value indicates the value of the mask to be applied
        and Port Range Mask indicates the position of the bits which
        are used to build the mask.

Bajko                   Expires March 27, 2011               [Page 9]

Port Restricted IP address assignment                   September 2010


   External IPv4 address
        The IPv4 address belonging to an upstream device such as NAT,
   to which the client.s source address is translated in a manner  that
   preserves the port numbers

   Section 4 describes how the client derives the allocated port range
   from the Port Range Value and Port Range Mask values.

3.4 Port forwarding with random port delegation function

   The format of the DATA field when sub-option type is set to 4 is
   shown in Figure 6:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         IPv4 address                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     External IPv4 address                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        function               |         starting point        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    number of delegated ports  |         key K               ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ...                                                           ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ...                                                           ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ...                                                           ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ... key K                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Figure 5: External IP Address with random port sub-option

   where the External IPv4 address field is defined in Section 3.3,
   while the rest of the fields in Section 3.2.


4. Port Mask Sub-Option Usage

   The port mask sub-option is used to specify one or multiple range of
   ports pertaining to the given IP address.

   Concretely, this option is used to notify a remote DHCP client about
   the Port Mask to be applied when selecting a port value as a source
   port. The Port Mask option is used to infer a set of allowed port
   values. A Port Mask defines a set of ports that all have in common a
   subset of pre-positioned bits. This ports set is also called Port
   Range. Two port numbers are said to belong to the same Port Range if
   and only if, they have the same Port Mask.


Bajko                   Expires March 27, 2011              [Page 10]

Port Restricted IP address assignment                   September 2010


   A Port Mask contains two fields: Port Range Value and Port Range
   Mask.

   - The 'Port Range Value' field indicates the value of the
   significant bits of the Port Mask. The 'Port Range Value' is coded as
   follows:
           - The significant bits are those where "1" values are set in
   the Port Range Mask. These bits may take a value of "0" or "1 ".
           - All the other bits (non significant ones) are set to "0".

   - The 'Port Range Mask' field indicates the position of the
   significant bits identified by the bit(s) set to "1".

   The Port Range Value field indicates the value of the mask to be
   applied and the Port Range Mask field indicates the position of the
   bits which are used to build the mask. The "1" values in the Port
   Range Mask field indicate by their position the significant bits of
   the Port Range Value (the pattern of the Port Range Value).

   For example:
        - A Port Range Mask field equal to 1000000000000000 indicates
        that the first bit (the most significant one) is used as a
        pattern of the Port Range Value field;

        - A Port Range Mask field equal to 0000101000000000 indicates
        that the 5th and the 7th most significant bits are used as a
        pattern of the Port Range Value.

   The pattern of the Port Range Value is all the fixed bits in the
   Port Range Value. All the ports the CPE is allowed to use as source
   ports must have their number in accordance with the pattern.

   The Port Range Value is coded as follows:
        - The pattern bits of the Port Range Value are those where "1"
        values are set in the Port Range Mask.  These bits may take a
        value of 0 or 1.
        - All the other bits are set to "0".

4.1 Illustration Examples

   In each of the three examples below allocation of 2048 ports is done
   differently. In all examples it is possible for 32 nodes to share
   the same public IPv4 address. The 4th example illustrates the
   ability of the procedure to enforce a balanced distribution of port
   numbers including the well-known-port values.

   a) the following Port Range Mask and Port Range Value are conveyed
   using DHCP to assign a Port Range (from 2048 to 4095) to a given
   device:
        - Port Range Value: 0000100000000000 (2048)
        - Port Range Mask: 1111100000000000 (63488)

Bajko                   Expires March 27, 2011              [Page 11]

Port Restricted IP address assignment                   September 2010


   b) Unlike the previous example, this one illustrates the case where
   a non Contiguous Port Range is assigned to a given customer's
   device. In this example, the Port Range Value defines 128 Contiguous
   Port Ranges, each one with a length of 16 port values.  Note that
   the two first Port Ranges are both in the well-known ports span
   (i.e., 0-1023) but these two ranges are not adjacent.

   The following Port Range Mask and Port Range Value are conveyed in
   DHCP messages:
        - Port Range Value : 0000000001010000 (80)
        - Port Range Mask : 0000000111110000 (496)

   This means that the 128 following Contiguous Port Ranges are
   assigned to the same device:
        - from 80 to 95
        - from 592 to 607
        - ...
        - from 65104 to 65119

   c) In this example, the Port Range Value defines two Contiguous Port
   Ranges, each one being 1024 ports long:

        - Port Range Value : 0000000000000000 (0)
        - Port Range Mask : 1111010000000000 (62464)

   This means that the two following Contiguous Port Ranges are
   assigned to the same device:
        - from 0 to 1023, and
        - from 2048 to 3071

   d) In this example, 64 contiguous Port Ranges are allocated to each
   CPE (among a set of 4 CPEs sharing the same IPv4 address).

   Among the 64 Contiguous Port Ranges to each CPE, there is always one
   within the span of the first 1024 well-known port values. Hereafter
   is given the Port Range Value and Port Range Mask assigned to 2 CPEs
   (CPE#0 and CPE#3, CPE#1 and CPE#2 being not represented here):

   1.  CPE#0

        - Port Range Value: 0000000000000000 (0)
        - Port Range Mask:  0000001100000000 (768)

   The CPE#0 has therefore the 64 following Contiguous Port Ranges:
        - 1st range: 0-255
        - ...
        - 64th range: 64512-64767

   2.  CPE#3

        - Port Range Value: 0000001100000000 (768)

Bajko                   Expires March 27, 2011              [Page 12]

Port Restricted IP address assignment                   September 2010

        - Port Range Mask:  0000001100000000 (768)

   The CPE#2 has therefore the 64 following Contiguous Port Ranges:
        - 1st range: 768-1023
        - ...
        - 64th range: 65280-65535

5. Random Port Delegation Function

   Delegating random ports can be achieved by defining a function which
   takes as input a key 'k' and an integer 'x' within the range (1024,
   65535) and produces an output 'y' also within the range (1024,
   65535).

   The server uses a cryptographical mechanism (described below) to
   select the random ports for each node. Instead of assigning a range
   of ports using port mask to the client, the server sends the inputs
   of a predefined cryptographic mechanism: a key, an initial value,
   and the number of ports assigned to this node. The client can then
   calculate the full list of assigned ports itself.

   The cryptographical mechanism ensures that the entire 64k port range
   can be efficiently distributed to multiple nodes in a way that when
   nodes calculate the ports, the results will never overlap with ports
   other nodes have calculated (property of permutation), and ports in
   the reserved range (smaller than 1024) are not used. As the
   randomization is done cryptographically, an attacker seeing a node
   using some port X cannot determine which other ports the node may be
   using (as the attacker does not know the key).

   Calculation of the random port list is done as follows:

   The cryptographic mechanism uses an encryption function y = E(K,x)
   that takes as input a key K (for example, 128 bits) and an integer x
   (the plaintext) in range (1024, 65535), and produces an output y
   (the ciphertext), also an integer in range (1024, 65535). This
   section describes one such encryption function, but others are also
   possible.

   The server will select the key K. When server wants to allocate e.g.
   2048 random ports, it selects a starting point 'a' (1024 <= a <=
   65536-2048) in a way that the range (a, a+2048) does not overlap
   with any other active client, and calculates the values E(K,a),
   E(K,a+1), E(K,a+2), ..., E(K,a+2046), E(K,a+2047). These are the
   port numbers allocated for this node. Instead of sending the port
   numbers individually, the server just sends the values 'K', ' a',
   and '2048'. The client will then repeat the same calculation.

   The server SHOULD use different K for each IPv4 address it allocates
   to make attacks as difficult as possible. This way, learning the K
   used in IPv4 address IP1 would not help in attacking IPv4 address
   IP2 that is allocated by the same server to different nodes.

Bajko                   Expires March 27, 2011              [Page 13]

Port Restricted IP address assignment                   September 2010


   With typical encryption functions (such as AES and DES), the input
   (plaintext) and output (ciphertext) are blocks of some fixed size;
   for example, 128 bits for AES, and 64 bits for DES. For port
   randomization, we need an encryption function whose input and output
   is an integer in range (1024, 65535).

   One possible way to do this is to use the 'Generalized-Feistel
   Cipher' [CIPHERS] construction by Black and Rogaway, with AES as the
   underlying round function.

   This would look as follows (using pseudo-code):

        def E(k, x):
            y = Feistel16(k, x)
            if y >= 1024:
                  return y
            else:
                  return E(k, y)

   Note that although E(k,x) is recursive, it is guaranteed to
   terminate. The average number of iterations is just slightly over 1.

   Feistel16 is a 16-bit block cipher:

        def Feistel16(k, x):
            left = x & 0xff
            right = x >> 8
            for round = 1 to 3:
                temp = left ^ FeistelRound(k, round, right))
                left = right
                right = temp
            return (right << 8) | left

   The Feistel round function uses:

        def FeistelRound(k, round, x):
            msg[0] = round
            msg[1] = x
            msg[2...15] = 0
            return AES(k, msg)[0]

   Performance: To generate list of 2048 port numbers, about 6000 calls
   to AES are required (i.e., encrypting 96 kilobytes). Thus, it will
   not be a problem for any device that can do, for example, HTTPS (web
   browsing over SSL/TLS).

   Other port generator functions may be predefined in Standards Track
   documents and allocated a not yet allocated 'function' value within
   the corresponding sub-option type field.

6. Option Usage

Bajko                   Expires March 27, 2011              [Page 14]

Port Restricted IP address assignment                   September 2010


6.1 Client Behaviour

   A DHCP client which supports the option defined in this document
   MUST support sub-option types 1 and 2 or 3 and 4.

   A DHCP client which supports the extensions defined in this
   document, SHOULD insert the Vendor Specific Information option 43
   containing OPTION-IPv4-PRA with the sub-option types and Vendor
   Class Identifier option 60 into DHCPDISCOVER message to explicitly
   let the server know that it supports port restricted IPv4 addresses.
      o In the port mask sub-option type, the client SHALL set the IPv4
        address and Mask Locator fields to all zeros. The client MAY
        indicate the number of desired ports in Port Range Value-field,
        or set that to all zeroes.
      o In the random port delegation sub-option type, the client SHALL
        set the IPv4 address field, key field and starting point field
        to all zeros. The client MAY indicate in function field which
        encryption function it prefers, and in the number of delegated
        ports field the number of ports the client would desire.

   When a client, which supports the option defined in this document,
   receives a DHCPOFFER with the 'yiaddr' (client IP address) field set
   to 0.0.0.0, it SHOULD check for the presence of option 43 containing
   OPTION-IPv4-PRA option. If such an option is present, the client MAY
   send a DHCPREQUEST message and insert the option 60 and the option
   43 containing OPTION-IPv4-PRA with the corresponding sub-option
   received in the OPTION-IPv4-PRA option of the previous DHCPOFFER.
   The client MUST NOT include a 'Requested IP Address' DHCP option
   (code 50) into this DHCPREQUEST.

   The client MUST NOT insert the IP address received in OPTION-IPv4-
   PRA into the 'Requested IP Address' DHCP option (Code 50).

   When the client receives a DHCPACK message with an option 43
   containing OPTION-IPv4-PRA option  and a sub-option field 1 or 2, it
   MAY start using the specified IP address in conjunction with the
   source ports specified by the mechanism chosen by DHCP server. The
   client SHOULD NOT use the IP address with different source port
   numbers, as that may result in the packets being NATed, as described
   in [APLUSP].

   When the client receives a DHCPACK message with an option 43 having
   OPTION-IPv4-PRA option and a sub-option field 3 or 4, it MAY start
   using the IP address specified in the External IPv4 address field in
   conjunction with the source ports specified by the mechanism chosen
   by the DHCP server. The address found in the External IP address
   field is the address to which the source address of the packets sent
   by the client will be translated to. The client may use that IP
   address in the application payloads when specifying its own IP
   address.


Bajko                   Expires March 27, 2011              [Page 15]

Port Restricted IP address assignment                   September 2010

   In case the initial port set received by the client from the server
   is exhausted and the client needs additional ports, it MAY request
   so by sending a new DHCPDISCOVER message.

   In some deployment scenarios the DHCP client may also act as a DHCP
   server for a network behind it, in which case the node may further
   split the allocated set for other nodes.

   The allocated port-restricted IP address and all the associated
   parameters are valid until indicated in the IP Address Lease Time
   Option (option 51).


6.2 Server Behaviour

   When a server, which supports the option defined in this document,
   receives a DHCPDISCOVER message, it SHOULD check for the presence of
   the option 60 and option 43 containing OPTION-IPv4-PRA option.

   If OPTION-IPv4-PRA is not present in DHCPDISCOVER, the server SHOULD
   allocate full unrestricted public or private [RFC1918] IPv4 address
   to the client, if available, by generating a DHCPOFFER as described
   in [RFC2131].

   The server SHOULD offer the port restricted IPv4 address with option
   43 when the server has support for the extensions specified in this
   document and when:
      o DHCP client has included an OPTION-IPv4-PRA option, and server's
        policy indicates saving unrestricted IPv4 addresses for clients
        that do not support the extensions defined in this document.
        The server MUST include only one of the sub-options into the
        OPTION-IPv4-PRA option.
      O DHCP client has included an OPTION-IPv4-PRA option and the
        server supports only port forwarding allocation, instead of
        restricted or unrestricted public IPv4 address allocation.
      o server receives a DHCPDISCOVER message and server can only
        offer port restricted IP address to the client
      o server receives a DHCPDISCOVER message from a client without
        the OPTION-IPv4-PRA, but knows by means outside the scope of
        this document that the client supports the usage of port-
        restricted IPv4 addresses (or it is only entitled to be
        provisioned with such addresses)

   When server chooses to offer port restricted IPv4 address for
   clients with OPTION-IPv4-PRA, it MUST:
      o set the 'yiaddr' (client IP address) field of the DHCPOFFER
        message to 0.0.0.0
      o choose the port allocation mechanisms, if it is not statically
        configured
      o select a port restricted IPv4 address to be allocated for the
        client


Bajko                   Expires March 27, 2011              [Page 16]

Port Restricted IP address assignment                   September 2010

      o generate parameters required for the chosen port allocation
        mechanism

   When the server receives a DHCPREQUEST message from the client with
   an option 43 having OPTION-IPv4-PRA option field containing the IP
   address and port allocation mechanism parameters it has previously
   offered to the client, the server MUST send a DHCPACK, where the
   'yiaddr' (client IP address) field is set to 0.0.0.0 and the option
   43 containing OPTION-IPv4-PRA option including the IPv4 address and
   parameters required for the used allocation mechanism.

   When the server receives a DHCPREQUEST message from the client with
   an option 43 containing OPTION-IPv4-PRA option field containing an
   IPv4 address and port set it has previously not offered to the
   client, the server MUST send a DHCPNAK to the client.

   When the server detects that a client (e.g. based on a specific
   hardware address) which has already been allocated with a port
   restricted IPv4 address, sent another DHCPDISCOVER, it MAY, based on
   local policy, offer the client with additional port restricted IPv4
   address.

   If the server is deployed in a cascaded DHCP server scenario, the
   node MAY both act as a DHCP client for another server and DHCP
   server for other DHCP clients.

   A server SHOULD ensure the client is residing on an access link
   where usage of port-restricted addresses is not causing problems,
   before allocating it a port restricted IPv4 address.

   A DHCP server MAY decide to either delegate a set of ports to the
   client, or to port forward the set of ports to the client. The DHCP
   server MUST include the external IPv4 address sub-option if port
   forwarding is used.

   The server MUST keep lease times per allocated port sets of the
   shared IP addresses, in case they are delegated to the client.

   The server does not need to send option 60 back to the client.



8. IANA considerations

   No action is required from IANA since this document adheres to
   [RFC2132].

9. Security considerations

   The solution is generally vulnerable to DoS when used in shared
   medium or when access network authentication is not a prerequisite
   to IP address assignment. The solution SHOULD only be used on point-

Bajko                   Expires March 27, 2011              [Page 17]

Port Restricted IP address assignment                   September 2010

   to-point links, tunnels, and/or in environments where authentication
   at link layer is performed before IP address assignment, and not
   shared medium.

   The cryptographically random port delegation mechanism is vulnerable
   for blind attacks initiated by nodes located in the same
   administrative domain, served by the same DHCP server, and that are
   sharing the same public IPv4 address, and therefore have knowledge
   of the cryptographic key used for that particular public IPv4
   address.

10. References
10.1 Normative References

   [RFC2119]    Bradner, S., .Key words for use in RFCs to Indicate
                Requirement Levels., March 1997

   [RFC2131]    Droms, R., "Dynamic Host Configuration Protocol",
                RFC2131, March 1997

   [RFC2132]    Alexander, S., Droms, R., .DHCP Options and BOOTP
                Vendor Extensions., RFC2132, March 1997

10.2 Informative References


   [RFC1918]    Rekhter, Y., Moskowitz, B., Karrenberg, D., J. de
                Groot, G., Lear, E., "Address Allocation for Private
                Internets", RFC1918, February 1996

   [MAEN2008]   Maennel, O., Bush, R., Cittadini, L., Bellovin, S., "A
                Better Approach than Carrier-Grade-NAT", 2008,
                Technical Report CUCS-041-08

   [RANDOMPORT] Larsen, M., Gont, F., .Port Randomization., August
                2010, draft-ietf-tsvwg-port-randomization-09

   [CIPHERS]    John Black and Phillip Rogaway: .Ciphers with Arbitrary
                Finite Domains., Topics in Cryptology - CT-RSA 2002,
                Lecture Notes in Computer Science vol. 2271, 2002

   [APLUSP]     Bush, R., Ed., "The A+P Approach to the IPv4 Address
                Shortage", October 2009, draft-ymbk-aplusp-05 (Work in
                progress)

12. Contributors

   Jean Luc Grimault and Alain Villefranque contributed text to earlier
   version of the document.

   The encryption function from Section 5 was provided by Pasi Eronen.


Bajko                   Expires March 27, 2011              [Page 18]

Port Restricted IP address assignment                   September 2010

   The authors would also like to thank Lars Eggert, Olaf Maenel, Randy
   Bush, Alain Durand, Jean-Luc Grimault, Alain Villefranque for their
   valuable comments.


Authors' Addresses

   Gabor Bajko
   gabor(dot)Bajko(at)nokia(dot)com

   Teemu Savolainen
   Nokia
   Hermiankatu 12 D
   FI-33720 TAMPERE
   Finland

   Email: teemu.savolainen@nokia.com


   Mohamed Boucadair
   France Telecom
   Rennes
   France

   Email: mohamed.boucadair@orange-ftgroup.com


   Pierre Levis
   France Telecom
   42 rue des Coutures
   BP 6243
   Caen Cedex 4  14066
   France

   Email: pierre.levis@orange-ftgroup.com


















Bajko                   Expires March 27, 2011              [Page 19]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/