doc: Add RFC documents

1 files changed, 1627 insertions, 0 deletions

diff --git a/doc/rfc/rfc6056.txt b/doc/rfc/rfc6056.txt
new file mode 100644
index 0000000..9ac738f
--- /dev/null
+++ b/doc/rfc/rfc6056.txt
@@ -0,0 +1,1627 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                         M. Larsen
+Request for Comments: 6056                                         Tieto
+BCP: 156                                                         F. Gont
+Category: Best Current Practice                                  UTN/FRH
+ISSN: 2070-1721                                             January 2011
+
+
+       Recommendations for Transport-Protocol Port Randomization
+
+Abstract
+
+   During the last few years, awareness has been raised about a number
+   of "blind" attacks that can be performed against the Transmission
+   Control Protocol (TCP) and similar 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.  This document describes a number
+   of simple and efficient methods for the selection of the client port
+   number, such that the possibility of an attacker guessing the exact
+   value is reduced.  While this is not a replacement for cryptographic
+   methods for protecting the transport-protocol instance, the
+   aforementioned port selection algorithms provide improved security
+   with very little effort and without any key management overhead.  The
+   algorithms described in this document are local policies that may be
+   incrementally deployed and that do not violate the specifications of
+   any of the transport protocols that may benefit from them, such as
+   TCP, UDP, UDP-lite, Stream Control Transmission Protocol (SCTP),
+   Datagram Congestion Control Protocol (DCCP), and RTP (provided that
+   the RTP application explicitly signals the RTP and RTCP port
+   numbers).
+
+Status of This Memo
+
+   This memo documents an Internet Best Current Practice.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   BCPs is available in Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc6056.
+
+
+
+
+
+Larsen & Gont             Best Current Practice                 [Page 1]
+
+RFC 6056           Port Randomization Recommendations       January 2011
+
+
+Copyright Notice
+
+   Copyright (c) 2011 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.
+
+   This document may contain material from IETF Documents or IETF
+   Contributions published or made publicly available before November
+   10, 2008.  The person(s) controlling the copyright in some of this
+   material may not have granted the IETF Trust the right to allow
+   modifications of such material outside the IETF Standards Process.
+   Without obtaining an adequate license from the person(s) controlling
+   the copyright in such materials, this document may not be modified
+   outside the IETF Standards Process, and derivative works of it may
+   not be created outside the IETF Standards Process, except to format
+   it for publication as an RFC or to translate it into languages other
+   than English.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Larsen & Gont             Best Current Practice                 [Page 2]
+
+RFC 6056           Port Randomization Recommendations       January 2011
+
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
+   2.  Ephemeral Ports  . . . . . . . . . . . . . . . . . . . . . . .  5
+     2.1.  Traditional Ephemeral Port Range . . . . . . . . . . . . .  5
+     2.2.  Ephemeral Port Selection . . . . . . . . . . . . . . . . .  6
+     2.3.  Collision of instance-ids  . . . . . . . . . . . . . . . .  7
+   3.  Obfuscating the Ephemeral Port Selection . . . . . . . . . . .  8
+     3.1.  Characteristics of a Good Algorithm for the
+           Obfuscation of the Ephemeral Port Selection  . . . . . . .  8
+     3.2.  Ephemeral Port Number Range  . . . . . . . . . . . . . . . 10
+     3.3.  Algorithms for the Obfuscation of the Ephemeral Port
+           Selection  . . . . . . . . . . . . . . . . . . . . . . . . 11
+       3.3.1.  Algorithm 1: Simple Port Randomization Algorithm . . . 11
+       3.3.2.  Algorithm 2: Another Simple Port Randomization
+               Algorithm  . . . . . . . . . . . . . . . . . . . . . . 13
+       3.3.3.  Algorithm 3: Simple Hash-Based Port Selection
+               Algorithm  . . . . . . . . . . . . . . . . . . . . . . 14
+       3.3.4.  Algorithm 4: Double-Hash Port Selection Algorithm  . . 16
+       3.3.5.  Algorithm 5: Random-Increments Port Selection
+               Algorithm  . . . . . . . . . . . . . . . . . . . . . . 18
+     3.4.  Secret-Key Considerations for Hash-Based Port
+           Selection Algorithms . . . . . . . . . . . . . . . . . . . 19
+     3.5.  Choosing an Ephemeral Port Selection Algorithm . . . . . . 20
+   4.  Interaction with Network Address Port Translation (NAPT) . . . 22
+   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 23
+   6.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24
+   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
+     7.1.  Normative References . . . . . . . . . . . . . . . . . . . 24
+     7.2.  Informative References . . . . . . . . . . . . . . . . . . 25
+   Appendix A.  Survey of the Algorithms in Use by Some Popular
+                Implementations . . . . . . . . . . . . . . . . . . . 28
+     A.1.  FreeBSD  . . . . . . . . . . . . . . . . . . . . . . . . . 28
+     A.2.  Linux  . . . . . . . . . . . . . . . . . . . . . . . . . . 28
+     A.3.  NetBSD . . . . . . . . . . . . . . . . . . . . . . . . . . 28
+     A.4.  OpenBSD  . . . . . . . . . . . . . . . . . . . . . . . . . 28
+     A.5.  OpenSolaris  . . . . . . . . . . . . . . . . . . . . . . . 28
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Larsen & Gont             Best Current Practice                 [Page 3]
+
+RFC 6056           Port Randomization Recommendations       January 2011
+
+
+1.  Introduction
+
+   Recently, awareness has been raised about a number of "blind" attacks
+   (i.e., attacks that can be performed without the need to sniff the
+   packets that correspond to the transport protocol instance to be
+   attacked) that can be performed against the Transmission Control
+   Protocol (TCP) [RFC0793] and similar protocols.  The consequences of
+   these attacks range from throughput reduction to broken connections
+   or data corruption [RFC5927] [RFC4953] [Watson].
+
+   All these attacks rely on the attacker's ability to guess or know the
+   five-tuple (Protocol, Source Address, Source port, Destination
+   Address, Destination Port) that identifies the transport protocol
+   instance to be attacked.
+
+   Services are usually located at fixed, "well-known" ports [IANA] at
+   the host supplying the service (the server).  Client applications
+   connecting to any such service will contact the server by specifying
+   the server IP address and service port number.  The IP address and
+   port number of the client are normally left unspecified by the client
+   application and thus are chosen automatically by the client
+   networking stack.  Ports chosen automatically by the networking stack
+   are known as ephemeral ports [Stevens].
+
+   While the server IP address, the well-known port, and the client IP
+   address may be known by an attacker, the ephemeral port of the client
+   is usually unknown and must be guessed.
+
+   This document describes a number of algorithms for the selection of
+   ephemeral port numbers, such that the possibility of an off-path
+   attacker guessing the exact value is reduced.  They are not a
+   replacement for cryptographic methods of protecting a transport-
+   protocol instance such as IPsec [RFC4301], the TCP MD5 signature
+   option [RFC2385], or the TCP Authentication Option [RFC5925].  For
+   example, they do not provide any mitigation in those scenarios in
+   which the attacker is able to sniff the packets that correspond to
+   the transport protocol instance to be attacked.  However, the
+   proposed algorithms provide improved resistance to off-path attacks
+   with very little effort and without any key management overhead.
+
+   The mechanisms described in this document are local modifications
+   that may be incrementally deployed, and that do not violate the
+   specifications of any of the transport protocols that may benefit
+   from them, such as TCP [RFC0793], UDP [RFC0768], SCTP [RFC4960], DCCP
+   [RFC4340], UDP-lite [RFC3828], and RTP [RFC3550] (provided the RTP
+   application explicitly signals the RTP and RTCP port numbers with,
+   e.g., [RFC3605]).
+
+
+
+
+Larsen & Gont             Best Current Practice                 [Page 4]
+
+RFC 6056           Port Randomization Recommendations       January 2011
+
+
+   Since these mechanisms are obfuscation techniques, focus has been on
+   a reasonable compromise between the level of obfuscation and the ease
+   of implementation.  Thus, the algorithms must be computationally
+   efficient and not require substantial state.
+
+   We note that while the technique of mitigating "blind" attacks by
+   obfuscating the ephemeral port selection is well-known as "port
+   randomization", the goal of the algorithms described in this document
+   is to reduce the chances of an attacker guessing the ephemeral ports
+   selected for new transport protocol instances, rather than to
+   actually produce mathematically random sequences of ephemeral ports.
+
+   Throughout this document, we will use the term "transport-protocol
+   instance" as a general term to refer to an instantiation of a
+   transport protocol (e.g., a "connection" in the case of connection-
+   oriented transport protocols) and the term "instance-id" as a short-
+   handle to refer to the group of values that identify a transport-
+   protocol instance (e.g., in the case of TCP, the five-tuple
+   {Protocol, IP Source Address, TCP Source Port, IP Destination
+   Address, TCP Destination Port}).
+
+   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].
+
+2.  Ephemeral Ports
+
+2.1.  Traditional Ephemeral Port Range
+
+   The Internet Assigned Numbers Authority (IANA) assigns the unique
+   parameters and values used in protocols developed by the Internet
+   Engineering Task Force (IETF), including well-known ports [IANA].
+   IANA has reserved the following use of the 16-bit port range of TCP
+   and UDP:
+
+   o  The Well-Known Ports, 0 through 1023.
+
+   o  The Registered Ports, 1024 through 49151
+
+   o  The Dynamic and/or Private Ports, 49152 through 65535
+
+   The dynamic port range defined by IANA consists of the 49152-65535
+   range, and is meant for the selection of ephemeral ports.
+
+
+
+
+
+
+
+
+Larsen & Gont             Best Current Practice                 [Page 5]
+
+RFC 6056           Port Randomization Recommendations       January 2011
+
+
+2.2.  Ephemeral Port Selection
+
+   As each communication instance is identified by the five-tuple
+   {protocol, local IP address, local port, remote IP address, remote
+   port}, the selection of ephemeral port numbers must result in a
+   unique five-tuple.
+
+   Selection of ephemeral ports such that they result in unique
+   instance-ids (five-tuples) is handled by some implementations by
+   having a per-protocol global "next_ephemeral" variable that is equal
+   to the previously chosen ephemeral port + 1, i.e., the selection
+   process is:
+
+       /* Initialization at system boot time. Could be random */
+       next_ephemeral = min_ephemeral;
+
+       /* Ephemeral port selection function */
+       count = max_ephemeral - min_ephemeral + 1;
+
+       do {
+           port = next_ephemeral;
+           if (next_ephemeral == max_ephemeral) {
+               next_ephemeral = min_ephemeral;
+           } else {
+               next_ephemeral++;
+           }
+
+           if (check_suitable_port(port))
+               return port;
+
+           count--;
+
+       } while (count > 0);
+
+       return ERROR;
+
+                    Traditional BSD Port Selection Algorithm
+
+   Note:
+      check_suitable_port() is a function that checks whether the
+      resulting port number is acceptable as an ephemeral port.  That
+      is, it checks whether the resulting port number is unique and may,
+      in addition, check that the port number is not in use for a
+      connection in the LISTEN or CLOSED states and that the port number
+      is not in the list of port numbers that should not be allocated as
+      ephemeral ports.  In BSD-derived systems, the
+      check_suitable_port() would correspond to the in_pcblookup_local()
+      function, where all the necessary checks would be performed.
+
+
+
+Larsen & Gont             Best Current Practice                 [Page 6]
+
+RFC 6056           Port Randomization Recommendations       January 2011
+
+
+   This algorithm works adequately provided that the number of
+   transport-protocol instances (for each transport protocol) that have
+   a lifetime longer than it takes to exhaust the total ephemeral port
+   range is small, so that collisions of instance-ids are rare.
+
+   However, this method has the drawback that the "next_ephemeral"
+   variable and thus the ephemeral port range is shared between all
+   transport-protocol instances, and the next ports chosen by the client
+   are easy to predict.  If an attacker operates an "innocent" server to
+   which the client connects, it is easy to obtain a reference point for
+   the current value of the "next_ephemeral" variable.  Additionally, if
+   an attacker could force a client to periodically establish, e.g., a
+   new TCP connection to an attacker-controlled machine (or through an
+   attacker-observable path), the attacker could subtract consecutive
+   source port values to obtain the number of outgoing TCP connections
+   established globally by the target host within that time period (up
+   to wrap-around issues and instance-id collisions, of course).
+
+2.3.  Collision of instance-ids
+
+   While it is possible for the ephemeral port selection algorithm to
+   verify that the selected port number results in a instance-id that is
+   not currently in use by that system, the resulting five-tuple may
+   still be in use at a remote system.  For example, consider a scenario
+   in which a client establishes a TCP connection with a remote web
+   server, and the web server performs the active close on the
+   connection.  While the state information for this connection will
+   disappear at the client side (that is, the connection will be moved
+   to the fictional CLOSED state), the instance-id will remain in the
+   TIME-WAIT state at the web server for 2*MSL (Maximum Segment
+   Lifetime).  If the same client tried to create a new incarnation of
+   the previous connection (that is, a connection with the same
+   instance-id as the one in the TIME_WAIT state at the server), an
+   instance-id "collision" would occur.  The effect of these collisions
+   range from connection-establishment failures to TIME-WAIT state
+   assassination (with the potential of data corruption) [RFC1337].  In
+   scenarios in which a specific client establishes TCP connections with
+   a specific service at a server, these problems become evident.
+   Therefore, an ephemeral port selection algorithm should ideally
+   minimize the rate of instance-id collisions.
+
+   A simple approach to minimize the rate of these collisions would be
+   to choose port numbers incrementally, so that a given port number
+   would not be reused until the rest of the port numbers in the
+   ephemeral port range have been used for a transport protocol
+   instance.  However, if a single global variable were used to keep
+   track of the last ephemeral port selected, ephemeral port numbers
+   would be trivially predictable, thus making it easier for an off-path
+
+
+
+Larsen & Gont             Best Current Practice                 [Page 7]
+
+RFC 6056           Port Randomization Recommendations       January 2011
+
+
+   attacker to "guess" the instance-id in use by a target transport-
+   protocol instance.  Sections 3.3.3 and 3.3.4 describe algorithms that
+   select port numbers incrementally, while still making it difficult
+   for an off-path attacker to predict the ephemeral ports used for
+   future transport-protocol instances.
+
+   A simple but inefficient approach to minimize the rate of collisions
+   of instance-ids would be, e.g., in the case of TCP, for both
+   endpoints of a TCP connection to keep state about recent connections
+   (e.g., have both endpoints end up in the TIME-WAIT state).
+
+3.  Obfuscating the Ephemeral Port Selection
+
+3.1.  Characteristics of a Good Algorithm for the Obfuscation of the
+      Ephemeral Port Selection
+
+   There are several factors to consider when designing an algorithm for
+   selecting ephemeral ports, which include:
+
+   o  Minimizing the predictability of the ephemeral port numbers used
+      for future transport-protocol instances.
+
+   o  Minimizing collisions of instance-ids.
+
+   o  Avoiding conflict with applications that depend on the use of
+      specific port numbers.
+
+   Given the goal of improving the transport protocol's resistance to
+   attack by obfuscation of the instance-id selection, it is key to
+   minimize the predictability of the ephemeral ports that will be
+   selected for new transport-protocol instances.  While the obvious
+   approach to address this requirement would be to select the ephemeral
+   ports by simply picking a random value within the chosen port number
+   range, this straightforward policy may lead to collisions of
+   instance-ids, which could lead to the interoperability problems
+   (e.g., delays in the establishment of new connections, failures in
+   connection establishment, or data corruption) discussed in
+   Section 2.3.  As discussed in Section 1, it is worth noting that
+   while the technique of mitigating "blind" attacks by obfuscating the
+   ephemeral port selection is well-known as "port randomization", the
+   goal of the algorithms described in this document is to reduce the
+   chances that an attacker will guess the ephemeral ports selected for
+   new transport-protocol instances, rather than to actually produce
+   sequences of mathematically random ephemeral port numbers.
+
+
+
+
+
+
+
+Larsen & Gont             Best Current Practice                 [Page 8]
+
+RFC 6056           Port Randomization Recommendations       January 2011
+
+
+   It is also worth noting that, provided adequate algorithms are in
+   use, the larger the range from which ephemeral ports are selected,
+   the smaller the chances of an attacker are to guess the selected port
+   number.
+
+   In scenarios in which a specific client establishes transport-
+   protocol instances with a specific service at a server, the problems
+   described in Section 2.3 become evident.  A good algorithm to
+   minimize the collisions of instance-ids would consider the time a
+   given five-tuple was last used, and would avoid reusing the last
+   recently used five-tuples.  A simple approach to minimize the rate of
+   collisions would be to choose port numbers incrementally, so that a
+   given port number would not be reused until the rest of the port
+   numbers in the ephemeral port range have been used for a transport-
+   protocol instance.  However, if a single global variable were used to
+   keep track of the last ephemeral port selected, ephemeral port
+   numbers would be trivially predictable.
+
+   It is important to note that a number of applications rely on binding
+   specific port numbers that may be within the ephemeral port range.
+   If such an application were run while the corresponding port number
+   were in use, the application would fail.  Therefore, ephemeral port
+   selection algorithms avoid using those port numbers.
+
+   Port numbers that are currently in use by a TCP in the LISTEN state
+   should not be allowed for use as ephemeral ports.  If this rule is
+   not complied with, an attacker could potentially "steal" an incoming
+   connection to a local server application in at least two different
+   ways.  Firstly, an attacker could issue a connection request to the
+   victim client at roughly the same time the client tries to connect to
+   the victim server application [CPNI-TCP] [TCP-SEC].  If the SYN
+   segment corresponding to the attacker's connection request and the
+   SYN segment corresponding to the victim client "cross each other in
+   the network", and provided the attacker is able to know or guess the
+   ephemeral port used by the client, a TCP "simultaneous open" scenario
+   would take place, and the incoming connection request sent by the
+   client would be matched with the attacker's socket rather than with
+   the victim server application's socket.  Secondly, an attacker could
+   specify a more specific socket than the "victim" socket (e.g.,
+   specify both the local IP address and the local TCP port), and thus
+   incoming SYN segments matching the attacker's socket would be
+   delivered to the attacker, rather than to the "victim" socket (see
+   Section 10.1 of [CPNI-TCP]).
+
+   It should be noted that most applications based on popular
+   implementations of the TCP API (such as the Sockets API) perform
+   "passive opens" in three steps.  Firstly, the application obtains a
+   file descriptor to be used for inter-process communication (e.g., by
+
+
+
+Larsen & Gont             Best Current Practice                 [Page 9]
+
+RFC 6056           Port Randomization Recommendations       January 2011
+
+
+   issuing a socket() call).  Secondly, the application binds the file
+   descriptor to a local TCP port number (e.g., by issuing a bind()
+   call), thus creating a TCP in the fictional CLOSED state.  Thirdly,
+   the aforementioned TCP is put in the LISTEN state (e.g., by issuing a
+   listen() call).  As a result, with such an implementation of the TCP
+   API, even if port numbers in use for TCPs in the LISTEN state were
+   not allowed for use as ephemeral ports, there is a window of time
+   between the second and the third steps in which an attacker could be
+   allowed to select a port number that would be later used for
+   listening to incoming connections.  Therefore, these implementations
+   of the TCP API should enforce a stricter requirement for the
+   allocation of port numbers: port numbers that are in use by a TCP in
+   the LISTEN or CLOSED states should not be allowed for allocation as
+   ephemeral ports [CPNI-TCP] [TCP-SEC].
+
+   The aforementioned issue does not affect SCTP, since most SCTP
+   implementations do not allow a socket to be bound to the same port
+   number unless a specific socket option (SCTP_REUSE_PORT) is issued on
+   the socket (i.e., this behavior needs to be explicitly allowed
+   beforehand).  An example of a typical SCTP socket API can be found in
+   [SCTP-SOCKET].
+
+   DCCP is not affected by the exploitation of "simultaneous opens" to
+   "steal" incoming connections, as the server and the client state
+   machines are different [RFC4340].  However, it may be affected by the
+   vector involving binding a more specific socket.  As a result, those
+   tuples {local IP address, local port, Service Code} that are in use
+   by a local socket should not be allowed for allocation as ephemeral
+   ports.
+
+3.2.  Ephemeral Port Number Range
+
+   As mentioned in Section 2.1, the dynamic ports consist of the range
+   49152-65535.  However, ephemeral port selection algorithms should use
+   the whole range 1024-65535.
+
+   This range includes the IANA Registered Ports; thus, some of these
+   port numbers may be needed for providing a particular service at the
+   local host, which could result in the problems discussed in
+   Section 3.1.  As a result, port numbers that may be needed for
+   providing a particular service at the local host SHOULD NOT be
+   included in the pool of port numbers available for ephemeral port
+   randomization.  If the host does not provide a particular service,
+   the port can be safely allocated to ordinary processes.
+
+   A possible workaround for this potential problem would be to maintain
+   a local list of the port numbers that should not be allocated as
+   ephemeral ports.  Thus, before allocating a port number, the
+
+
+
+Larsen & Gont             Best Current Practice                [Page 10]
+
+RFC 6056           Port Randomization Recommendations       January 2011
+
+
+   ephemeral port selection function would check this list, avoiding the
+   allocation of ports that may be needed for specific applications.
+   Rather than naively excluding all the registered ports,
+   administrators should identify services that may be offered by the
+   local host and SHOULD exclude only the corresponding registered
+   ports.
+
+   Ephemeral port selection algorithms SHOULD use the largest possible
+   port range, since this reduces the chances of an off-path attacker of
+   guessing the selected port numbers.
+
+3.3.  Algorithms for the Obfuscation of the Ephemeral Port Selection
+
+   Ephemeral port selection algorithms SHOULD obfuscate the selection of
+   their ephemeral ports, since this helps to mitigate a number of
+   attacks that depend on the attacker's ability to guess or know the
+   five-tuple that identifies the transport-protocol instance to be
+   attacked.
+
+   The following subsections describe a number of algorithms that could
+   be implemented in order to obfuscate the selection of ephemeral port
+   numbers.
+
+3.3.1.  Algorithm 1: Simple Port Randomization Algorithm
+
+   In order to address the security issues discussed in Sections 1 and
+   2.2, a number of systems have implemented simple ephemeral port
+   number randomization, as follows:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Larsen & Gont             Best Current Practice                [Page 11]
+
+RFC 6056           Port Randomization Recommendations       January 2011
+
+
+       /* Ephemeral port selection function */
+       num_ephemeral = max_ephemeral - min_ephemeral + 1;
+       next_ephemeral = min_ephemeral + (random() % num_ephemeral);
+       count = num_ephemeral;
+
+       do {
+           if(check_suitable_port(port))
+                   return next_ephemeral;
+
+           if (next_ephemeral == max_ephemeral) {
+               next_ephemeral = min_ephemeral;
+           } else {
+               next_ephemeral++;
+           }
+
+           count--;
+       } while (count > 0);
+
+       return ERROR;
+
+                              Algorithm 1
+
+   Note:
+      random() is a function that returns a 32-bit pseudo-random
+      unsigned integer number.  Note that the output needs to be
+      unpredictable, and typical implementations of POSIX random()
+      function do not necessarily meet this requirement.  See [RFC4086]
+      for randomness requirements for security.
+
+      All the variables (in this and all the algorithms discussed in
+      this document) are unsigned integers.
+
+   Since the initially chosen port may already be in use with IP
+   addresses and server port that are identical to the ones being used
+   for the socket for which the ephemeral port is to be selected, the
+   resulting five-tuple might not be unique.  Therefore, multiple ports
+   may have to be tried and verified against all existing transport-
+   protocol instances before a port can be chosen.
+
+   Web proxy servers, Network Address Port Translators (NAPTs)
+   [RFC2663], and other middleboxes aggregate multiple peers into the
+   same port space and thus increase the population of used ephemeral
+   ports, and hence the chances of collisions of instance-ids.  However,
+   [Allman] has shown that at least in the network scenarios used for
+   measuring the collision properties of the algorithms described in
+   this document, the collision rate resulting from the use of the
+   aforementioned middleboxes is nevertheless very low.
+
+
+
+
+Larsen & Gont             Best Current Practice                [Page 12]
+
+RFC 6056           Port Randomization Recommendations       January 2011
+
+
+   Since this algorithm performs port selection without taking into
+   account the port numbers previously chosen, it has the potential of
+   reusing port numbers too quickly, thus possibly leading to collisions
+   of instance-ids.  Even if a given instance-id is verified to be
+   unique by the port selection algorithm, the instance-id might still
+   be in use at the remote system.  In such a scenario, a connection
+   request could possibly fail ([Silbersack] describes this problem for
+   the TCP case).
+
+   However, this algorithm is biased towards the first available port
+   after a sequence of unavailable port numbers.  If the local list of
+   registered port numbers that should not be allocated as ephemeral
+   ports (as described in Section 3.2) is significant, an attacker may
+   actually have a significantly better chance of guessing a port
+   number.
+
+   This algorithm selects ephemeral port numbers randomly and thus
+   reduces the chances that an attacker will guess the ephemeral port
+   selected for a target transport-protocol instance.  Additionally, it
+   prevents attackers from obtaining the number of outgoing transport-
+   protocol instances (e.g., TCP connections) established by the client
+   in some period of time.
+
+3.3.2.  Algorithm 2: Another Simple Port Randomization Algorithm
+
+   The following pseudo-code illustrates another algorithm for selecting
+   a random port number, in which in the event a local instance-id
+   collision is detected, another port number is selected randomly:
+
+       /* Ephemeral port selection function */
+       num_ephemeral = max_ephemeral - min_ephemeral + 1;
+       next_ephemeral = min_ephemeral + (random() % num_ephemeral);
+       count = num_ephemeral;
+
+       do {
+           if(check_suitable_port(port))
+                   return next_ephemeral;
+
+           next_ephemeral = min_ephemeral + (random() % num_ephemeral);
+           count--;
+       } while (count > 0);
+
+       return ERROR;
+
+                              Algorithm 2
+
+
+
+
+
+
+Larsen & Gont             Best Current Practice                [Page 13]
+
+RFC 6056           Port Randomization Recommendations       January 2011
+
+
+   When there are a large number of port numbers already in use for the
+   same destination endpoint, this algorithm might be unable (with a
+   very small remaining probability) to select an ephemeral port (i.e.,
+   it would return "ERROR"), even if there are still a few port numbers
+   available that would result in unique five-tuples.  However, the
+   results in [Allman] have shown that in common scenarios, one port
+   choice is enough, and in most cases where more than one choice is
+   needed, two choices suffice.  Therefore, in those scenarios this
+   would not be problem.
+
+3.3.3.  Algorithm 3: Simple Hash-Based Port Selection Algorithm
+
+   We would like to achieve the port-reuse properties of the traditional
+   BSD port selection algorithm (described in Section 2.2), while at the
+   same time achieve the unpredictability properties of Algorithm 1 and
+   Algorithm 2.
+
+   Ideally, we would like a "next_ephemeral" value for each set of
+   (local IP address, remote IP addresses, remote port), so that the
+   port-reuse frequency is the lowest possible.  Each of these
+   "next_ephemeral" variables should be initialized with random values
+   within the ephemeral port range and, together, these would thus
+   separate the ephemeral port space of the transport-protocol instances
+   on a "per-destination endpoint" basis (this "separation of the
+   ephemeral port space" means that transport-protocol instances with
+   different remote endpoints will not have different sequences of port
+   numbers, i.e., will not be part of the same ephemeral port sequence
+   as in the case of the traditional BSD ephemeral port selection
+   algorithm).  Since we do not want to maintain in memory all these
+   "next_ephemeral" values, we propose an offset function F() that can
+   be computed from the local IP address, remote IP address, remote
+   port, and a secret key.  F() will yield (practically) different
+   values for each set of arguments, i.e.:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Larsen & Gont             Best Current Practice                [Page 14]
+
+RFC 6056           Port Randomization Recommendations       January 2011
+
+
+       /* Initialization at system boot time. Could be random. */
+       next_ephemeral = 0;
+
+       /* Ephemeral port selection function */
+       num_ephemeral = max_ephemeral - min_ephemeral + 1;
+       offset = F(local_IP, remote_IP, remote_port, secret_key);
+       count = num_ephemeral;
+
+       do {
+           port = min_ephemeral +
+                  (next_ephemeral + offset) % num_ephemeral;
+
+           next_ephemeral++;
+
+           if(check_suitable_port(port))
+               return port;
+
+           count--;
+
+       } while (count > 0);
+
+       return ERROR;
+
+                              Algorithm 3
+
+   In other words, the function F() provides a "per-destination
+   endpoint" fixed offset within the global ephemeral port range.  Both
+   the "offset" and "next_ephemeral" variables may take any value within
+   the storage type range since we are restricting the resulting port in
+   a similar way as in Algorithm 1 (described in Section 3.3.1).  This
+   allows us to simply increment the "next_ephemeral" variable and rely
+   on the unsigned integer to wrap around.
+
+   The function F() should be a cryptographic hash function like MD5
+   [RFC1321].  The function should use both IP addresses, the remote
+   port, and a secret key value to compute the offset.  The remote IP
+   address is the primary separator and must be included in the offset
+   calculation.  The local IP address and remote port may in some cases
+   be constant and thus not improve the ephemeral port space separation;
+   however, they should also be included in the offset calculation.
+
+   Cryptographic algorithms stronger than, e.g., MD5 should not be
+   necessary, given that Algorithm 3 is simply a technique for the
+   obfuscation of the selection of ephemeral ports.  The secret should
+   be chosen to be as random as possible (see [RFC4086] for
+   recommendations on choosing secrets).
+
+
+
+
+
+Larsen & Gont             Best Current Practice                [Page 15]
+
+RFC 6056           Port Randomization Recommendations       January 2011
+
+
+   Note that on multiuser systems, the function F() could include user-
+   specific information, thereby providing protection not only on a
+   host-to-host basis, but on a user to service basis.  In fact, any
+   identifier of the remote entity could be used, depending on
+   availability and the granularity requested.  With SCTP, both
+   hostnames and alternative IP addresses may be included in the
+   association negotiation, and either of these could be used in the
+   offset function F().
+
+   When multiple unique identifiers are available, any of these can be
+   chosen as input to the offset function F() since they all uniquely
+   identify the remote entity.  However, in cases like SCTP where the
+   ephemeral port must be unique across all IP address permutations, we
+   should ideally always use the same IP address to get a single
+   starting offset for each association negotiation with a given remote
+   entity to minimize the possibility of collisions.  A simple numerical
+   sorting of the IP addresses and always using the numerically lowest
+   could achieve this.  However, since most protocols will generally
+   report the same IP addresses in the same order in each association
+   setup, this sorting is most likely not necessary and the "first one"
+   can simply be used.
+
+   The ability of hostnames to uniquely define hosts can be discussed,
+   and since SCTP always includes at least one IP address, we recommend
+   using this as input to the offset function F() and ignoring hostname
+   chunks when searching for ephemeral ports.
+
+   It should be noted that, as this algorithm uses a global counter
+   ("next_ephemeral") for selecting ephemeral ports, if an attacker
+   could, e.g., force a client to periodically establish a new TCP
+   connection to an attacker-controlled machine (or through an attacker-
+   observable path), the attacker could subtract consecutive source port
+   values to obtain the number of outgoing TCP connections established
+   globally by the target host within that time period (up to wrap-
+   around issues and five-tuple collisions, of course).
+
+3.3.4.  Algorithm 4: Double-Hash Port Selection Algorithm
+
+   A trade-off between maintaining a single global "next_ephemeral"
+   variable and maintaining 2**N "next_ephemeral" variables (where N is
+   the width of the result of F()) could be achieved as follows.  The
+   system would keep an array of TABLE_LENGTH short integers, which
+   would provide a separation of the increment of the "next_ephemeral"
+   variable.  This improvement could be incorporated into Algorithm 3 as
+   follows:
+
+
+
+
+
+
+Larsen & Gont             Best Current Practice                [Page 16]
+
+RFC 6056           Port Randomization Recommendations       January 2011
+
+
+     /* Initialization at system boot time */
+     for(i = 0; i < TABLE_LENGTH; i++)
+         table[i] = random() % 65536;
+
+     /* Ephemeral port selection function */
+     num_ephemeral = max_ephemeral - min_ephemeral + 1;
+     offset = F(local_IP, remote_IP, remote_port, secret_key1);
+     index = G(local_IP, remote_IP, remote_port, secret_key2);
+     count = num_ephemeral;
+
+     do {
+         port = min_ephemeral + (offset + table[index]) % num_ephemeral;
+         table[index]++;
+
+         if(check_suitable_port(port))
+             return port;
+
+        count--;
+
+     } while (count > 0);
+
+     return ERROR;
+
+                            Algorithm 4
+
+   "table[]" could be initialized with mathematically random values, as
+   indicated by the initialization code in pseudo-code above.  The
+   function G() should be a cryptographic hash function like MD5
+   [RFC1321].  It should use both IP addresses, the remote port, and a
+   secret key value to compute a value between 0 and (TABLE_LENGTH-1).
+   Alternatively, G() could take an "offset" as input, and perform the
+   exclusive-or (XOR) operation between all the bytes in "offset".
+
+   The array "table[]" assures that successive transport-protocol
+   instances with the same remote endpoint will use increasing ephemeral
+   port numbers.  However, incrementation of the port numbers is
+   separated into TABLE_LENGTH different spaces, and thus the port-reuse
+   frequency will be (probabilistically) lower than that of Algorithm 3.
+   That is, a new transport-protocol instance with some remote endpoint
+   will not necessarily cause the "next_ephemeral" variable
+   corresponding to other endpoints to be incremented.
+
+   It is interesting to note that the size of "table[]" does not limit
+   the number of different port sequences, but rather separates the
+   *increments* into TABLE_LENGTH different spaces.  The port sequence
+   will result from adding the corresponding entry of "table[]" to the
+   variable "offset", which selects the actual port sequence (as in
+   Algorithm 3).  [Allman] has found that a TABLE_LENGTH of 10 can
+
+
+
+Larsen & Gont             Best Current Practice                [Page 17]
+
+RFC 6056           Port Randomization Recommendations       January 2011
+
+
+   result in an improvement over Algorithm 3.  Further increasing the
+   TABLE_LENGTH will increase the unpredictability of the resulting port
+   number, and possibly further decrease the collision rate.
+
+   An attacker can perform traffic analysis for any "increment space"
+   into which the attacker has "visibility" -- namely, the attacker can
+   force the client to establish a transport-protocol instance whose
+   G(offset) identifies the target "increment space".  However, the
+   attacker's ability to perform traffic analysis is very reduced when
+   compared to the traditional BSD algorithm (described in Section 2.2)
+   and Algorithm 3.  Additionally, an implementation can further limit
+   the attacker's ability to perform traffic analysis by further
+   separating the increment space (that is, using a larger value for
+   TABLE_LENGTH).
+
+3.3.5.  Algorithm 5: Random-Increments Port Selection Algorithm
+
+   [Allman] introduced another port selection algorithm, which offers a
+   middle ground between the algorithms that select ephemeral ports
+   independently at random (such as those described in Sections 3.3.1
+   and 3.3.2), and those that offer obfuscation with less randomization
+   (such as those described in Sections 3.3.3 and 3.3.4).
+
+     /* Initialization code at system boot time. */
+     next_ephemeral = random() % 65536;   /* Initialization value */
+     N = 500;                             /* Determines the trade-off */
+
+     /* Ephemeral port selection function */
+     num_ephemeral = max_ephemeral - min_ephemeral + 1;
+
+     count = num_ephemeral;
+
+     do {
+         next_ephemeral = next_ephemeral + (random() % N) + 1;
+         port = min_ephemeral + (next_ephemeral % num_ephemeral);
+
+         if(check_suitable_port(port))
+                 return port;
+
+          count--;
+     } while (count > 0);
+
+     return ERROR;
+
+                            Algorithm 5
+
+
+
+
+
+
+Larsen & Gont             Best Current Practice                [Page 18]
+
+RFC 6056           Port Randomization Recommendations       January 2011
+
+
+   This algorithm aims at producing a monotonically increasing sequence
+   to prevent the collision of instance-ids, while avoiding the use of
+   fixed increments, which would lead to trivially predictable
+   sequences.  The value "N" allows for direct control of the trade-off
+   between the level of unpredictability and the port-reuse frequency.
+   The smaller the value of "N", the more similar this algorithm is to
+   the traditional BSD port selection algorithm (described in
+   Section 2.2).  The larger the value of "N", the more similar this
+   algorithm is to the algorithm described in Section 3.3.1 of this
+   document.
+
+   When the port numbers wrap, there is the risk of collisions of
+   instance-ids.  Therefore, "N" should be selected according to the
+   following criteria:
+
+   o  It should maximize the wrapping time of the ephemeral port space.
+
+   o  It should minimize collisions of instance-ids.
+
+   o  It should maximize the unpredictability of selected port numbers.
+
+   Clearly, these are competing goals, and the decision of which value
+   of "N" to use is a trade-off.  Therefore, the value of "N" should be
+   configurable so that system administrators can make the trade-off for
+   themselves.
+
+3.4.  Secret-Key Considerations for Hash-Based Port Selection Algorithms
+
+   Every complex manipulation (like MD5) is no more secure than the
+   input values, and in the case of ephemeral ports, the secret key.  If
+   an attacker is aware of which cryptographic hash function is being
+   used by the victim (which we should expect), and the attacker can
+   obtain enough material (e.g., ephemeral ports chosen by the victim),
+   the attacker may simply search the entire secret-key space to find
+   matches.
+
+   To protect against this, the secret key should be of a reasonable
+   length.  Key lengths of 128 bits should be adequate.
+
+   Another possible mechanism for protecting the secret key is to change
+   it after some time.  If the host platform is capable of producing
+   reasonably good random data, the secret key can be changed
+   automatically.
+
+   Changing the secret will cause abrupt shifts in the chosen ephemeral
+   ports, and consequently collisions may occur.  That is, upon changing
+   the secret, the "offset" value (see Sections 3.3.3 and 3.3.4) used
+
+
+
+
+Larsen & Gont             Best Current Practice                [Page 19]
+
+RFC 6056           Port Randomization Recommendations       January 2011
+
+
+   for each destination endpoint will be different from that computed
+   with the previous secret, thus leading to the selection of a port
+   number recently used for connecting to the same endpoint.
+
+   Thus, the change in secret key should be done with consideration and
+   could be performed whenever one of the following events occur:
+
+   o  The system is being bootstrapped.
+
+   o  Some predefined/random time has expired.
+
+   o  The secret key has been used sufficiently often that it should be
+      regarded as insecure now.
+
+   o  There are few active transport-protocol instances (i.e.,
+      possibility of a collision is low).
+
+   o  System load is low (i.e., the performance overhead of local
+      collisions is tolerated).
+
+   o  There is enough random data available to change the secret key
+      (pseudo-random changes should not be done).
+
+3.5.  Choosing an Ephemeral Port Selection Algorithm
+
+   [Allman] is an empirical study of the properties of the algorithms
+   described in this document, which has found that all the algorithms
+   described in this document offer low collision rates -- at most 0.3%.
+   That is, in those network scenarios assessed by [Allman], all of the
+   algorithms described in this document perform well in terms of
+   collisions of instance-ids.  However, these results may vary
+   depending on the characteristics of network traffic and the specific
+   network setup.
+
+   The algorithm described in Section 2.2 is the traditional ephemeral
+   port selection algorithm implemented in BSD-derived systems.  It
+   generates a global sequence of ephemeral port numbers, which makes it
+   trivial for an attacker to predict the port number that will be used
+   for a future transport protocol instance.  However, it is very simple
+   and leads to a low port-reuse frequency.
+
+   Algorithm 1 and Algorithm 2 have the advantage that they provide
+   actual randomization of the ephemeral ports.  However, they may
+   increase the chances of port number collisions, which could lead to
+   the failure of a connection establishment attempt.  [Allman] found
+   that these two algorithms show the largest collision rates (among all
+   the algorithms described in this document).
+
+
+
+
+Larsen & Gont             Best Current Practice                [Page 20]
+
+RFC 6056           Port Randomization Recommendations       January 2011
+
+
+   Algorithm 3 provides complete separation in local and remote IP
+   addresses and remote port space, and only limited separation in other
+   dimensions (see Section 3.4).  However, implementations should
+   consider the performance impact of computing the cryptographic hash
+   used for the offset.
+
+   Algorithm 4 improves Algorithm 3, usually leading to a lower port-
+   reuse frequency, at the expense of more processor cycles used for
+   computing G(), and additional kernel memory for storing the array
+   "table[]".
+
+   Algorithm 5 offers middle ground between the simple randomization
+   algorithms (Algorithm 1 and Algorithm 2) and the hash-based
+   algorithms (Algorithm 3 and Algorithm 4).  The upper limit on the
+   random increments (the value "N" in the pseudo-code included in
+   Section 3.3.5) controls the trade-off between randomization and port-
+   reuse frequency.
+
+   Finally, a special case that may preclude the utilization of
+   Algorithm 3 and Algorithm 4 should be analyzed.  There exist some
+   applications that contain the following code sequence:
+
+       s = socket();
+       bind(s, IP_address, port = *);
+
+   In some BSD-derived systems, the call to bind() will result in the
+   selection of an ephemeral port number.  However, as neither the
+   remote IP address nor the remote port will be available to the
+   ephemeral port selection function, the hash function F() used in
+   Algorithm 3 and Algorithm 4 will not have all the required arguments,
+   and thus the result of the hash function will be impossible to
+   compute.  Transport protocols implementing Algorithm 3 or Algorithm 4
+   should consider using Algorithm 2 when facing the scenario just
+   described.
+
+   An alternative to this behavior would be to implement "lazy binding"
+   in response to the bind() call.  That is, selection of an ephemeral
+   port would be delayed until, e.g., connect() or send() are called.
+   Thus, at that point the ephemeral port is actually selected, all the
+   necessary arguments for the hash function F() are available, and
+   therefore Algorithm 3 and Algorithm 4 could still be used in this
+   scenario.  This algorithm has been implemented by Linux [Linux].
+
+
+
+
+
+
+
+
+
+Larsen & Gont             Best Current Practice                [Page 21]
+
+RFC 6056           Port Randomization Recommendations       January 2011
+
+
+4.  Interaction with Network Address Port Translation (NAPT)
+
+   Network Address Port Translation (NAPT) translates both the network
+   address and transport-protocol port number, thus allowing the
+   transport identifiers of a number of private hosts to be multiplexed
+   into the transport identifiers of a single external address
+   [RFC2663].
+
+   In those scenarios in which a NAPT is present between the two
+   endpoints of a transport-protocol instance, the obfuscation of the
+   ephemeral port selection (from the point of view of the external
+   network) will depend on the ephemeral port selection function at the
+   NAPT.  Therefore, NAPTs should consider obfuscating the selection of
+   ephemeral ports by means of any of the algorithms discussed in this
+   document.
+
+   A NAPT that does not implement port preservation [RFC4787] [RFC5382]
+   SHOULD obfuscate selection of the ephemeral port of a packet when it
+   is changed during translation of that packet.
+
+   A NAPT that does implement port preservation SHOULD obfuscate the
+   ephemeral port of a packet only if the port must be changed as a
+   result of the port being already in use for some other session.
+
+   A NAPT that performs parity preservation and that must change the
+   ephemeral port during translation of a packet SHOULD obfuscate the
+   ephemeral ports.  The algorithms described in this document could be
+   easily adapted such that the parity is preserved (i.e., force the
+   lowest order bit of the resulting port number to 0 or 1 according to
+   whether even or odd parity is desired).
+
+   Some applications allocate contiguous ports and expect to see
+   contiguous ports in use at their peers.  Clearly, this expectation
+   might be difficult to accommodate at a NAPT, since some port numbers
+   might already be in use by other sessions, and thus an alternative
+   port might need to be selected, thus resulting in a non-contiguous
+   port number sequence (see Section 4.2.3 of [RFC4787]).  A NAPT that
+   implements a simple port randomization algorithm (such as Algorithm
+   1, Algorithm 2, or Algorithm 5) is likely to break this assumption,
+   even if the endpoint selecting an ephemeral port does select
+   ephemeral ports that are contiguous.  However, since a number of
+   different ephemeral port selection algorithms have been implemented
+   by deployed NAPTs, any application that relies on any specific
+   ephemeral port selection algorithm at the NAPT is likely to suffer
+   interoperability problems when a NAPT is present between the two
+   endpoints of a transport-protocol instance.  Nevertheless, some of
+   the algorithms described in this document (namely Algorithm 3 and
+   Algorithm 4) select consecutive ephemeral ports such that they are
+
+
+
+Larsen & Gont             Best Current Practice                [Page 22]
+
+RFC 6056           Port Randomization Recommendations       January 2011
+
+
+   contiguous (except when one of the port numbers needed to produce a
+   contiguous sequence is already in use by some other NAPT session).
+   Therefore, a NAPT willing to produce sequences of contiguous port
+   numbers should consider implementing Algorithm 3 or Algorithm 4 of
+   this document.  Section 3.5 provides further guidance in choosing a
+   port selection algorithm.
+
+   It should be noted that in some network scenarios, a NAPT may
+   naturally obscure ephemeral port selections simply due to the vast
+   range of services with which it establishes connections and to the
+   overall rate of the traffic [Allman].
+
+5.  Security Considerations
+
+   Obfuscating the ephemeral port selection is no replacement for
+   cryptographic mechanisms, such as IPsec [RFC4301], in terms of
+   protecting transport-protocol instances against blind attacks.
+
+   An eavesdropper that can monitor the packets that correspond to the
+   transport-protocol instance to be attacked could learn the IP
+   addresses and port numbers in use (and also sequence numbers, etc.)
+   and easily perform an attack.  Obfuscation of the ephemeral port
+   selection does not provide any additional protection against this
+   kind of attack.  In such situations, proper authentication mechanisms
+   such as those described in [RFC4301] should be used.
+
+   This specification recommends including the whole range 1024-65535
+   for the selection of ephemeral ports, and suggests that an
+   implementation maintains a list of those port numbers that should not
+   be made available for ephemeral port selection.  If the list of port
+   numbers that are not available is significant, Algorithm 1 may be
+   highly biased and generate predictable ports, as noted in
+   Section 3.3.1.  In particular, if the list of IANA Registered Ports
+   is accepted as the local list of port numbers that should not be made
+   available, certain ports may result with 500 times the probability of
+   other ports.  Systems that support numerous applications resulting in
+   large lists of unavailable ports, or that use the IANA Registered
+   Ports without modification, MUST NOT use Algorithm 1.
+
+   If the local offset function F() (in Algorithm 3 and Algorithm 4)
+   results in identical offsets for different inputs at greater
+   frequency than would be expected by chance, the port-offset mechanism
+   proposed in this document would have a reduced effect.
+
+   If random numbers are used as the only source of the secret key, they
+   should be chosen in accordance with the recommendations given in
+   [RFC4086].
+
+
+
+
+Larsen & Gont             Best Current Practice                [Page 23]
+
+RFC 6056           Port Randomization Recommendations       January 2011
+
+
+   If an attacker uses dynamically assigned IP addresses, the current
+   ephemeral port offset (Algorithm 3 and Algorithm 4) for a given five-
+   tuple can be sampled and subsequently used to attack an innocent peer
+   reusing this address.  However, this is only possible until a re-
+   keying happens as described above.  Also, since ephemeral ports are
+   only used on the client side (e.g., the one initiating the transport-
+   protocol communication), both the attacker and the new peer need to
+   act as servers in the scenario just described.  While servers using
+   dynamic IP addresses exist, they are not very common, and with an
+   appropriate re-keying mechanism the effect of this attack is limited.
+
+6.  Acknowledgements
+
+   The offset function used in Algorithm 3 and Algorithm 4 was inspired
+   by the mechanism proposed by Steven Bellovin in [RFC1948] for
+   defending against TCP sequence number attacks.
+
+   The authors would like to thank (in alphabetical order) Mark Allman,
+   Jari Arkko, Matthias Bethke, Stephane Bortzmeyer, Brian Carpenter,
+   Vincent Deffontaines, Ralph Droms, Lars Eggert, Pasi Eronen, Gorry
+   Fairhurst, Adrian Farrel, Guillermo Gont, David Harrington, Alfred
+   Hoenes, Avshalom Houri, Charlie Kaufman, Amit Klein, Subramanian
+   Moonesamy, Carlos Pignataro, Tim Polk, Kacheong Poon, Pasi Sarolahti,
+   Robert Sparks, Randall Stewart, Joe Touch, Michael Tuexen, Magnus
+   Westerlund, and Dan Wing for their valuable feedback on draft
+   versions of this document.
+
+   The authors would like to thank Alfred Hoenes for his admirable
+   effort in improving the quality of this document.
+
+   The authors would like to thank FreeBSD's Mike Silbersack for a very
+   fruitful discussion about ephemeral port selection techniques.
+
+   Fernando Gont's attendance to IETF meetings was supported by ISOC's
+   "Fellowship to the IETF" program.
+
+7.  References
+
+7.1.  Normative References
+
+   [RFC0768]      Postel, J., "User Datagram Protocol", STD 6, RFC 768,
+                  August 1980.
+
+   [RFC0793]      Postel, J., "Transmission Control Protocol", STD 7,
+                  RFC 793, September 1981.
+
+   [RFC1321]      Rivest, R., "The MD5 Message-Digest Algorithm",
+                  RFC 1321, April 1992.
+
+
+
+Larsen & Gont             Best Current Practice                [Page 24]
+
+RFC 6056           Port Randomization Recommendations       January 2011
+
+
+   [RFC2119]      Bradner, S., "Key words for use in RFCs to Indicate
+                  Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2385]      Heffernan, A., "Protection of BGP Sessions via the TCP
+                  MD5 Signature Option", RFC 2385, August 1998.
+
+   [RFC3550]      Schulzrinne, H., Casner, S., Frederick, R., and V.
+                  Jacobson, "RTP: A Transport Protocol for Real-Time
+                  Applications", STD 64, RFC 3550, July 2003.
+
+   [RFC3605]      Huitema, C., "Real Time Control Protocol (RTCP)
+                  attribute in Session Description Protocol (SDP)",
+                  RFC 3605, October 2003.
+
+   [RFC3828]      Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E.,
+                  and G. Fairhurst, "The Lightweight User Datagram
+                  Protocol (UDP-Lite)", RFC 3828, July 2004.
+
+   [RFC4086]      Eastlake, D., Schiller, J., and S. Crocker,
+                  "Randomness Requirements for Security", BCP 106,
+                  RFC 4086, June 2005.
+
+   [RFC4301]      Kent, S. and K. Seo, "Security Architecture for the
+                  Internet Protocol", RFC 4301, December 2005.
+
+   [RFC4340]      Kohler, E., Handley, M., and S. Floyd, "Datagram
+                  Congestion Control Protocol (DCCP)", RFC 4340,
+                  March 2006.
+
+   [RFC4787]      Audet, F. and C. Jennings, "Network Address
+                  Translation (NAT) Behavioral Requirements for Unicast
+                  UDP", BCP 127, RFC 4787, January 2007.
+
+   [RFC4960]      Stewart, R., "Stream Control Transmission Protocol",
+                  RFC 4960, September 2007.
+
+   [RFC5382]      Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P.
+                  Srisuresh, "NAT Behavioral Requirements for TCP",
+                  BCP 142, RFC 5382, October 2008.
+
+7.2.  Informative References
+
+   [Allman]       Allman, M., "Comments On Selecting Ephemeral Ports",
+                   ACM Computer Communication Review, 39(2), 2009.
+
+
+
+
+
+
+
+Larsen & Gont             Best Current Practice                [Page 25]
+
+RFC 6056           Port Randomization Recommendations       January 2011
+
+
+   [CPNI-TCP]     Gont, F., "CPNI Technical Note 3/2009: Security
+                  Assessment of the Transmission Control Protocol
+                  (TCP)", 2009, <http://www.cpni.gov.uk/Docs/
+                  tn-03-09-security-assessment-TCP.pdf>.
+
+   [FreeBSD]      The FreeBSD Project, <http://www.freebsd.org>.
+
+   [IANA]         "IANA Port Numbers",
+                  <http://www.iana.org/assignments/port-numbers>.
+
+   [Linux]        The Linux Project, <http://www.kernel.org>.
+
+   [NetBSD]       The NetBSD Project, <http://www.netbsd.org>.
+
+   [OpenBSD]      The OpenBSD Project, <http://www.openbsd.org>.
+
+   [OpenSolaris]  OpenSolaris, <http://www.opensolaris.org>.
+
+   [RFC1337]      Braden, B., "TIME-WAIT Assassination Hazards in TCP",
+                  RFC 1337, May 1992.
+
+   [RFC1948]      Bellovin, S., "Defending Against Sequence Number
+                  Attacks", RFC 1948, May 1996.
+
+   [RFC2663]      Srisuresh, P. and M. Holdrege, "IP Network Address
+                  Translator (NAT) Terminology and Considerations",
+                  RFC 2663, August 1999.
+
+   [RFC4953]      Touch, J., "Defending TCP Against Spoofing Attacks",
+                  RFC 4953, July 2007.
+
+   [RFC5925]      Touch, J., Mankin, A., and R. Bonica, "The TCP
+                  Authentication Option", RFC 5925, June 2010.
+
+   [RFC5927]      Gont, F., "ICMP Attacks against TCP", RFC 5927,
+                  July 2010.
+
+   [SCTP-SOCKET]  Stewart, R., Poon, K., Tuexen, M., Lei, P., and V.
+                  Yasevich, V., "Sockets API Extensions for Stream
+                  Control Transmission Protocol (SCTP)", Work in
+                  Progress, January 2011.
+
+   [Silbersack]   Silbersack, M., "Improving TCP/IP security through
+                  randomization without sacrificing interoperability",
+                  EuroBSDCon 2005 Conference.
+
+   [Stevens]      Stevens, W., "Unix Network Programming, Volume 1:
+                  Networking APIs: Socket and XTI", Prentice Hall, 1998.
+
+
+
+Larsen & Gont             Best Current Practice                [Page 26]
+
+RFC 6056           Port Randomization Recommendations       January 2011
+
+
+   [TCP-SEC]      Gont, F., "Security Assessment of the Transmission
+                  Control Protocol (TCP)", Work in Progress,
+                  February 2010.
+
+   [Watson]       Watson, P., "Slipping in the Window: TCP Reset
+                  Attacks", CanSecWest 2004 Conference.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Larsen & Gont             Best Current Practice                [Page 27]
+
+RFC 6056           Port Randomization Recommendations       January 2011
+
+
+Appendix A.  Survey of the Algorithms in Use by Some Popular
+             Implementations
+
+A.1.  FreeBSD
+
+   FreeBSD 8.0 implements Algorithm 1, and in response to this document
+   now uses a "min_port" of 10000 and a "max_port" of 65535 [FreeBSD].
+
+A.2.  Linux
+
+   Linux 2.6.15-53-386 implements Algorithm 3, with MD5 as the hash
+   algorithm.  If the algorithm is faced with the corner-case scenario
+   described in Section 3.5, Algorithm 1 is used instead [Linux].
+
+A.3.  NetBSD
+
+   NetBSD 5.0.1 does not obfuscate its ephemeral port numbers.  It
+   selects ephemeral port numbers from the range 49152-65535, starting
+   from port 65535, and decreasing the port number for each ephemeral
+   port number selected [NetBSD].
+
+A.4.  OpenBSD
+
+   OpenBSD 4.2 implements Algorithm 1, with a "min_port" of 1024 and a
+   "max_port" of 49151.  [OpenBSD]
+
+A.5.  OpenSolaris
+
+   OpenSolaris 2009.06 implements Algorithm 1, with a "min_port" of
+   32768 and a "max_port" of 65535 [OpenSolaris].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Larsen & Gont             Best Current Practice                [Page 28]
+
+RFC 6056           Port Randomization Recommendations       January 2011
+
+
+Authors' Addresses
+
+   Michael Vittrup Larsen
+   Tieto
+   Skanderborgvej 232
+   Aarhus  DK-8260
+   Denmark
+
+   Phone: +45 8938 5100
+   EMail: michael.larsen@tieto.com
+
+
+   Fernando Gont
+   Universidad Tecnologica Nacional / Facultad Regional Haedo
+   Evaristo Carriego 2644
+   Haedo, Provincia de Buenos Aires  1706
+   Argentina
+
+   Phone: +54 11 4650 8472
+   EMail: fernando@gont.com.ar
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Larsen & Gont             Best Current Practice                [Page 29]
+