draft-ietf-tsvwg-port-randomization-01.txt   draft-ietf-tsvwg-port-randomization-02.txt 
tsvwg M. Larsen Transport Area Working Group M. Larsen
Internet-Draft TietoEnator (tsvwg) TietoEnator
Intended status: Best Current F. Gont Internet-Draft F. Gont
Practice UTN/FRH Intended status: BCP UTN/FRH
Expires: August 28, 2008 February 25, 2008 Expires: March 4, 2009 August 31, 2008
Port Randomization Port Randomization
draft-ietf-tsvwg-port-randomization-01 draft-ietf-tsvwg-port-randomization-02
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 35 skipping to change at page 1, line 35
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 28, 2008. This Internet-Draft will expire on March 4, 2009.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Abstract Abstract
Recently, awareness has been raised about a number of "blind" attacks Recently, awareness has been raised about a number of "blind" attacks
that can be performed against the Transmission Control Protocol (TCP) that can be performed against the Transmission Control Protocol (TCP)
and similar protocols. The consequences of these attacks range from and similar protocols. The consequences of these attacks range from
throughput-reduction to broken connections or data corruption. These throughput-reduction to broken connections or data corruption. These
attacks rely on the attacker's ability to guess or know the five- attacks rely on the attacker's ability to guess or know the five-
tuple (Protocol, Source Address, Destination Address, Source Port, tuple (Protocol, Source Address, Destination Address, Source Port,
Destination Port) that identifies the transport protocol instance to Destination Port) that identifies the transport protocol instance to
be attacked. This document describes a simple and efficient method be attacked. This document describes a number of simple and
for random selection of the client port number, such that the efficient methods for the random selection of the client port number,
possibility of an attacker guessing the exact value is reduced. such that the possibility of an attacker guessing the exact value is
While this is not a replacement for cryptographic methods, the reduced. While this is not a replacement for cryptographic methods,
described port number randomization algorithms provide improved the described port number randomization algorithms provide improved
security/obfuscation with very little effort and without any key security/obfuscation with very little effort and without any key
management overhead. The mechanisms described in this document are a management overhead. The algorithms described in this document are
local modification that may be incrementally deployed, and that does local policies that may be incrementally deployed, and that do not
not violate the specifications of any of the transport protocols that violate the specifications of any of the transport protocols that may
may benefit from it, such as TCP, UDP, SCTP, DCCP, and RTP. benefit from them, such as TCP, UDP, UDP-lite, SCTP, DCCP, and RTP.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Ephemeral Ports . . . . . . . . . . . . . . . . . . . . . . . 6 2. Ephemeral Ports . . . . . . . . . . . . . . . . . . . . . . . 6
2.1. Traditional Ephemeral Port Range . . . . . . . . . . . . . 6 2.1. Traditional Ephemeral Port Range . . . . . . . . . . . . . 6
2.2. Ephemeral port selection . . . . . . . . . . . . . . . . . 6 2.2. Ephemeral port selection . . . . . . . . . . . . . . . . . 6
3. Randomizing the Ephemeral Ports . . . . . . . . . . . . . . . 8 2.3. Collision of connection-id's . . . . . . . . . . . . . . . 7
3. Randomizing the Ephemeral Ports . . . . . . . . . . . . . . . 9
3.1. Characteristics of a good ephemeral port randomization 3.1. Characteristics of a good ephemeral port randomization
algorithm . . . . . . . . . . . . . . . . . . . . . . . . 8 algorithm . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2. Ephemeral port number range . . . . . . . . . . . . . . . 9 3.2. Ephemeral port number range . . . . . . . . . . . . . . . 10
3.3. Ephemeral Port Randomization Algorithms . . . . . . . . . 9 3.3. Ephemeral Port Randomization Algorithms . . . . . . . . . 10
3.3.1. Algorithm 1: Simple port randomization algorithm . . . 9 3.3.1. Algorithm 1: Simple port randomization algorithm . . . 10
3.3.2. Algorithm 2: Another simple port randomization 3.3.2. Algorithm 2: Another simple port randomization
algorithm . . . . . . . . . . . . . . . . . . . . . . 11 algorithm . . . . . . . . . . . . . . . . . . . . . . 12
3.3.3. Algorithm 3: Simple hash-based algorithm . . . . . . . 11 3.3.3. Algorithm 3: Simple hash-based algorithm . . . . . . . 12
3.3.4. Algorithm 4: Double-hash randomization algorithm . . . 13 3.3.4. Algorithm 4: Double-hash randomization algorithm . . . 14
3.4. Secret-key considerations for hash-based port 3.4. Secret-key considerations for hash-based port
randomization algorithms . . . . . . . . . . . . . . . . . 15 randomization algorithms . . . . . . . . . . . . . . . . . 16
3.5. Choosing an ephemeral port randomization algorithm . . . . 16 3.5. Choosing an ephemeral port randomization algorithm . . . . 17
4. Security Considerations . . . . . . . . . . . . . . . . . . . 17 4. Port randomization and Network Address Port Translation
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 (NAPT) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 5. Security Considerations . . . . . . . . . . . . . . . . . . . 20
6.1. Normative References . . . . . . . . . . . . . . . . . . . 19 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21
6.2. Informative References . . . . . . . . . . . . . . . . . . 20 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
7.1. Normative References . . . . . . . . . . . . . . . . . . . 22
7.2. Informative References . . . . . . . . . . . . . . . . . . 23
Appendix A. Survey of the algorithms in use by some popular Appendix A. Survey of the algorithms in use by some popular
implementations . . . . . . . . . . . . . . . . . . . 21 implementations . . . . . . . . . . . . . . . . . . . 24
A.1. FreeBSD . . . . . . . . . . . . . . . . . . . . . . . . . 21 A.1. FreeBSD . . . . . . . . . . . . . . . . . . . . . . . . . 24
A.2. Linux . . . . . . . . . . . . . . . . . . . . . . . . . . 21 A.2. Linux . . . . . . . . . . . . . . . . . . . . . . . . . . 24
A.3. NetBSD . . . . . . . . . . . . . . . . . . . . . . . . . . 21 A.3. NetBSD . . . . . . . . . . . . . . . . . . . . . . . . . . 24
A.4. OpenBSD . . . . . . . . . . . . . . . . . . . . . . . . . 21 A.4. OpenBSD . . . . . . . . . . . . . . . . . . . . . . . . . 24
Appendix B. Changes from previous versions of the draft . . . . . 22 Appendix B. Changes from previous versions of the draft . . . . . 25
B.1. Changes from draft-ietf-tsvwg-port-randomisation-00 . . . 22 B.1. Changes from draft-ietf-tsvwg-port-randomization-01 . . . 25
B.2. Changes from draft-larsen-tsvwg-port-randomisation-02 . . 22 B.2. Changes from draft-ietf-tsvwg-port-randomization-00 . . . 25
B.3. Changes from draft-larsen-tsvwg-port-randomisation-01 . . 22 B.3. Changes from draft-larsen-tsvwg-port-randomization-02 . . 25
B.4. Changes from draft-larsen-tsvwg-port-randomization-00 . . 22 B.4. Changes from draft-larsen-tsvwg-port-randomization-01 . . 25
B.5. Changes from draft-larsen-tsvwg-port-randomisation-00 . . 22 B.5. Changes from draft-larsen-tsvwg-port-randomization-00 . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 B.6. Changes from draft-larsen-tsvwg-port-randomisation-00 . . 26
Intellectual Property and Copyright Statements . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27
Intellectual Property and Copyright Statements . . . . . . . . . . 28
1. Introduction 1. Introduction
Recently, awareness has been raised about a number of "blind" attacks Recently, awareness has been raised about a number of "blind" attacks
(i.e., attacks that can be performed without the need to sniff the (i.e., attacks that can be performed without the need to sniff the
packets that correspond to the transport protocol instance to be packets that correspond to the transport protocol instance to be
attacked) that can be performed against the Transmission Control attacked) that can be performed against the Transmission Control
Protocol (TCP) [RFC0793] and similar protocols. The consequences of Protocol (TCP) [RFC0793] and similar protocols. The consequences of
these attacks range from throughput-reduction to broken connections these attacks range from throughput-reduction to broken connections
or data corruption [I-D.ietf-tcpm-icmp-attacks] [RFC4953] [Watson]. or data corruption [I-D.ietf-tcpm-icmp-attacks] [RFC4953] [Watson].
skipping to change at page 4, line 52 skipping to change at page 4, line 52
algorithms provide improved obfuscation with very little effort and algorithms provide improved obfuscation with very little effort and
without any key management overhead. without any key management overhead.
The mechanisms described in this document are local modifications The mechanisms described in this document are local modifications
that may be incrementally deployed, and that does not violate the that may be incrementally deployed, and that does not violate the
specifications of any of the transport protocols that may benefit specifications of any of the transport protocols that may benefit
from it, such as TCP [RFC0793], UDP [RFC0768], SCTP [RFC4960], DCCP from it, such as TCP [RFC0793], UDP [RFC0768], SCTP [RFC4960], DCCP
[RFC4340], UDP-lite [RFC3828], and RTP [RFC3550]. [RFC4340], UDP-lite [RFC3828], and RTP [RFC3550].
Since these mechanisms are obfuscation techniques, focus has been on Since these mechanisms are obfuscation techniques, focus has been on
a reasonable compromise between level of obfuscation and ease of a reasonable compromise between the level of obfuscation and the ease
implementation. Thus the algorithms must be computationally of implementation. Thus the algorithms must be computationally
efficient, and not require substantial data structures. efficient, and not require substantial data structures.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
2. Ephemeral Ports 2. Ephemeral Ports
2.1. Traditional Ephemeral Port Range 2.1. Traditional Ephemeral Port Range
skipping to change at page 7, line 22 skipping to change at page 7, line 22
port = next_ephemeral; port = next_ephemeral;
if (next_ephemeral == max_ephemeral) { if (next_ephemeral == max_ephemeral) {
next_ephemeral = min_ephemeral; next_ephemeral = min_ephemeral;
} else { } else {
next_ephemeral++; next_ephemeral++;
} }
if (five-tuple is unique) if (five-tuple is unique)
return port; return port;
count--;
} while (count > 0); } while (count > 0);
return ERROR; return ERROR;
Figure 1 Figure 1
This algorithm works well provided that the number of connections for This algorithm works well provided that the number of connections for
a each transport protocol that have a life-time longer than it takes a each transport protocol that have a life-time longer than it takes
to exhaust the total ephemeral port range is small, so that five- to exhaust the total ephemeral port range is small, so that five-
tuple collisions are rare. tuple collisions are rare.
However, this method has the drawback that the 'next_ephemeral' However, this method has the drawback that the 'next_ephemeral'
variable and thus the ephemeral port range is shared between all variable and thus the ephemeral port range is shared between all
connections and the next ports chosen by the client are easy to connections and the next ports chosen by the client are easy to
predict. If an attacker operates an "innocent" server to which the predict. If an attacker operates an "innocent" server to which the
client connects, it is easy to obtain a reference point for the client connects, it is easy to obtain a reference point for the
current value of the 'next_ephemeral' variable. current value of the 'next_ephemeral' variable. Additionally, if an
attacker could force a client to periodically establish a new TCP
connection to an attacker controlled machine (or through an attacker
observable routing path), the attacker could subtract consecutive
source port values to obtain the number of outoing TCP connections
established globally by the target host within that time period (up
to wrap-around issues and 5-tuple collisions, of course).
2.3. Collision of connection-id's
While it is possible for the ephemeral port selection algorithm to
verify that the selected port number results in connection-id that is
not currently in use at that system, the resulting connection-id 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 connection-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
connection-id as the one in the TIME_WAIT state at the server), a
port number "collision" would occur. The effect of these port number
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 lead to a low port reuse frequency, to reduce the
chances of port number collisions.
A simple approach to maximize the five-tuple reuse cycle 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 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 attacker to
"guess" the connection-id in use by a target connection.
3. Randomizing the Ephemeral Ports 3. Randomizing the Ephemeral Ports
3.1. Characteristics of a good ephemeral port randomization algorithm 3.1. Characteristics of a good ephemeral port randomization algorithm
There are a number of factors to consider when designing a policy of There are a number of factors to consider when designing a policy of
selection of ephemeral ports, which include: selection of ephemeral ports, which include:
o Minimizing the predictability of the ephemeral port numbers used o Minimizing the predictability of the ephemeral port numbers used
for future connections. for future connections.
o Maximizing the port reuse cycle. o Maximizing the port reuse cycle.
o Avoiding conflict with applications that depend on the use of o Avoiding conflict with applications that depend on the use of
specific port numbers. specific port numbers.
Given the goal of improving TCP's resistance to attack by obfuscation Given the goal of improving the transport protocol's resistance to
of the four-tuple that identifies a TCP connection, it is key to attack by obfuscation of the five-tuple that identifies a transport-
minimize the predictability of the ephemeral ports that will be protocol instance, it is key to minimize the predictability of the
selected for new connections. While the obvious approach to address ephemeral ports that will be selected for new connections. While the
this requirement would be to select the ephemeral ports by simply obvious approach to address this requirement would be to select the
picking a random value within the chosen port number range, this ephemeral ports by simply picking a random value within the chosen
straightforward policy may lead to a short reuse cycle of port port number range, this straightforward policy may lead to a short
numbers, which could lead to the interoperability problems discussed reuse cycle of port numbers, which could lead to the interoperability
in . It is also worth noting that, provided adequate randomization problems discussed in Section 2.3. It is also worth noting that,
algorithms are in use, the larger the range from which ephemeral pots provided adequate randomization algorithms are in use, the larger the
are selected, the smaller the chances of an attacker are to guess the range from which ephemeral pots are selected, the smaller the chances
selected port number. of an attacker are to guess the selected port number.
A number of implementations will not allow the creation of a new In scenarios in which a specific client establishes connections with
connection if there exists a previous incarnation of the same a specific service at a server, the problems described in Section 2.3
connection in any state other than the fictional state CLOSED. This become evident. Therefore, an ephemeral port selection algorithm
can be problematic in scenarios in which a client establishes should ideally lead to a low port reuse frequency, to reduce the
connections with a specific service at server at a high rate: even if chances of port number collisions. A good algorithm to maximize the
the connections are also closed at a high rate, one of the systems port reuse cycle would consider the time a given five-tuple was last
(the one performing the active close) will keep each of the closed used, and would avoid reusing the last recently used five-tuples. A
connection in the TIME-WAIT state for 2*MSL. If the connection rate simple approach to maximize the five-tuple reuse cycle would be to
is high enough, at some point all the ephemeral ports at the client choose port numbers incrementally, so that a given port number would
will be in use by some connection in the TIME-WAIT state, thus not be reused until the rest of the port numbers in ephemeral port
preventing the establishment of new connections. Therefore, the only range have been used for a transport protocol instance. However, if
strategy that can be relied upon to avoid this interoperability a single global variable were used to keep track of the last
problem is to maximize the ephemeral port reuse cycle at a client, ephemeral port selected, ephemeral port numbers would be trivially
with the goal of reducing the chances that a previous incarnation of predictable.
the same connection exists when a new connection is tried to be
established. A good algorithm to maximize the port reuse cycle would
consider the time a given ephemeral port number was last used, and
would avoid reusing the last recently used port numbers. A simple
approach to maximize the port reuse cycle 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 ephemeral port range
have been used for a TCP connection. 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 It is important to note that a number of applications rely on binding
specific port numbers that may be within the ephemeral ports range. specific port numbers that may be within the ephemeral ports range.
If such an application was run while the corresponding port number If such an application was run while the corresponding port number
was in use, the application would fail. Therefore, transport was in use, the application would fail. Therefore, transport
protocols should avoid using those port numbers as ephemeral ports. protocols should avoid using those port numbers as ephemeral ports.
3.2. Ephemeral port number range 3.2. Ephemeral port number range
As mentioned in Section 2.1, the ephemeral port range has As mentioned in Section 2.1, the ephemeral port range has
skipping to change at page 10, line 6 skipping to change at page 11, line 6
be implemented in order to obfuscate the selection of ephemeral port be implemented in order to obfuscate the selection of ephemeral port
numbers. numbers.
3.3.1. Algorithm 1: Simple port randomization algorithm 3.3.1. Algorithm 1: Simple port randomization algorithm
In order to address the security issues discussed in Section 1 and In order to address the security issues discussed in Section 1 and
Section 2.2, a number of systems have implemented simple ephemeral Section 2.2, a number of systems have implemented simple ephemeral
port number randomization, as follows: port number randomization, as follows:
/* Ephemeral port selection function */ /* Ephemeral port selection function */
next_ephemeral = min_ephemeral + random() num_ephemeral = max_ephemeral - min_ephemeral + 1;
% (max_ephemeral - min_ephemeral + 1); next_ephemeral = min_ephemeral + (random() % num_ephemeral);
count = num_ephemeral;
count = max_ephemeral - min_ephemeral + 1;
do { do {
if(five-tuple is unique) if(five-tuple is unique)
return next_ephemeral; return next_ephemeral;
if (next_ephemeral == max_ephemeral) { if (next_ephemeral == max_ephemeral) {
next_ephemeral = min_ephemeral; next_ephemeral = min_ephemeral;
} else { } else {
next_ephemeral++; next_ephemeral++;
} }
skipping to change at page 10, line 34 skipping to change at page 11, line 33
return ERROR; return ERROR;
Figure 2 Figure 2
We will refer to this algorithm as 'Algorithm 1'. We will refer to this algorithm as 'Algorithm 1'.
Since the initially chosen port may already be in use with identical Since the initially chosen port may already be in use with identical
IP addresses and server port, the resulting five-tuple might not be IP addresses and server port, the resulting five-tuple might not be
unique. Therefore, multiple ports may have to be tried and verified unique. Therefore, multiple ports may have to be tried and verified
against all existing connections before a port can be chosen. against all existing connections before a port can be chosen.
Although carefully chosen random sources and optimized five-tuple Although carefully chosen random sources and optimized five-tuple
lookup mechanisms (e.g., optimized through hashing), will mitigate lookup mechanisms (e.g., optimized through hashing) will mitigate the
the cost of this verification, some systems may still not want to cost of this verification, some systems may still not want to incur
incur this search time. this search time.
Systems that may be specially susceptible to this kind of repeated Systems that may be specially susceptible to this kind of repeated
five-tuple collisions are those that create many connections from a five-tuple collisions are those that create many connections from a
single local IP address to a single service (i.e. both of the IP single local IP address to a single service (i.e. both of the IP
addresses and the server port are fixed). Gateways such as proxy addresses and the server port are fixed). Web proxy servers and
servers are an example of such a system. NAPTs [RFC2663] are an examples of such systems.
Since this algorithm performs a completely random port selection Since this algorithm performs a completely random port selection
(i.e., without taking into account the port numbers previously (i.e., without taking into account the port numbers previously
chosen), it has the potential of reusing port numbers too quickly. chosen), it has the potential of reusing port numbers too quickly.
Even if a given five-tuple is verified to be unique by the port Even if a given five-tuple is verified to be unique by the port
selection algorithm, the five-tuple might still be in use at the selection algorithm, the five-tuple might still be in use at the
remote system. In such a scenario, the connection request could remote system. In such a scenario, the connection request could
possibly fail ([Silbersack] describes this problem for the TCP case). possibly fail ([Silbersack] describes this problem for the TCP case).
Therefore, it is desirable to keep the port reuse frequency as low as Therefore, it is desirable to keep the port reuse frequency as low as
possible. possible.
This algorithm selects ephemeral port numbers randomly and thus
reduces the chances of an attacker of guessing the ephemeral port
selected for a target connection. Additionally, it prevents
attackers from obtaining the number of outgoing connections
established by the client in some period of time.
3.3.2. Algorithm 2: Another simple port randomization algorithm 3.3.2. Algorithm 2: Another simple port randomization algorithm
Another algorithm for selecting a random port number is shown in Another algorithm for selecting a random port number is shown in
Figure 3, in which in the event a local connection-id collision is Figure 3, in which in the event a local connection-id collision is
detected, another port number is selected randomly, as follows: detected, another port number is selected randomly, as follows:
/* Ephemeral port selection function */ /* Ephemeral port selection function */
next_ephemeral = min_ephemeral + random() num_ephemeral = max_ephemeral - min_ephemeral + 1;
% (max_ephemeral - min_ephemeral + 1); next_ephemeral = min_ephemeral + (random() % num_ephemeral);
count = num_ephemeral;
count = max_ephemeral - min_ephemeral + 1;
do { do {
if(five-tuple is unique) if(five-tuple is unique)
return next_ephemeral; return next_ephemeral;
next_ephemeral = min_ephemeral + random() next_ephemeral = min_ephemeral + (random() % num_ephemeral);
% (max_ephemeral - min_ephemeral + 1);
count--; count--;
} while (count > 0); } while (count > 0);
return ERROR; return ERROR;
Figure 3 Figure 3
We will refer to this algorithm as 'Algorithm 2'. The only We will refer to this algorithm as 'Algorithm 2'. The difference
difference between this algorithm and Algorithm 1 is that the search between this algorithm and Algorithm 1 is that the search time for
time for this variant may be longer than for the later, particularly this variant may be longer than for the latter, particularly when
when there are a large number of port numbers already in use. there is a large number of port numbers already in use. Also, this
algorithm may be unable to select an ephemeral port (i.e., return
"ERROR") even if there are port numbers that would result in unique
five-tuples, particularly when there are a large number of port
numbers already in use.
3.3.3. Algorithm 3: Simple hash-based algorithm 3.3.3. Algorithm 3: Simple hash-based algorithm
We would like to achieve the port reuse properties of traditional BSD We would like to achieve the port reuse properties of the traditional
port selection algorithm, while at the same time achieve the BSD port selection algorithm, while at the same time achieve the
obfuscation properties of Algorithm 1 and Algorithm 2. obfuscation properties of Algorithm 1 and Algorithm 2.
Ideally, we would like a 'next_ephemeral' value for each set of Ideally, we would like a 'next_ephemeral' value for each set of
(local IP address, remote IP addresses, remote port), so that the (local IP address, remote IP addresses, remote port), so that the
port reuse frequency is the lowest possible. Each of these port reuse frequency is the lowest possible. Each of these
'next_ephemeral' variables should be initialized with random values 'next_ephemeral' variables should be initialized with random values
within the ephemeral port range and would thus separate the ephemeral within the ephemeral port range and would thus separate the ephemeral
port ranges of the connections entirely. Since we do not want to port ranges of the connections entirely. Since we do not want to
maintain in memory all these 'next_ephemeral' values, we propose an maintain in memory all these 'next_ephemeral' values, we propose an
offset function F(), that can be computed from the local IP address, offset function F(), that can be computed from the local IP address,
remote IP address, remote port and a secret key. F() will yield remote IP address, remote port and a secret key. F() will yield
(practically) different values for each set of arguments, i.e.: (practically) different values for each set of arguments, i.e.:
/* Initialization code at system boot time. Initialization value could be random. */ /* Initialization code at system boot time. Initialization value could be random. */
next_ephemeral = 0; next_ephemeral = 0;
/* Ephemeral port selection function */ /* Ephemeral port selection function */
num_ephemeral = max_ephemeral - min_ephemeral + 1;
offset = F(local_IP, remote_IP, remote_port, secret_key); offset = F(local_IP, remote_IP, remote_port, secret_key);
count = max_ephemeral - min_ephemeral + 1; count = num_ephemeral;
do { do {
port = min_ephemeral + (next_ephemeral + offset) port = min_ephemeral + (next_ephemeral + offset) % num_ephemeral;
% (max_ephemeral - min_ephemeral + 1);
next_ephemeral++; next_ephemeral++;
count--;
if(five-tuple is unique) if(five-tuple is unique)
return port; return port;
count--;
} while (count > 0); } while (count > 0);
return ERROR; return ERROR;
Figure 4 Figure 4
We will refer to this algorithm as 'Algorithm 3'. We will refer to this algorithm as 'Algorithm 3'.
In other words, the function F() provides a per-connection fixed In other words, the function F() provides a per-connection fixed
offset within the global ephemeral port range. Both the 'offset' and offset within the global ephemeral port range. Both the 'offset' and
skipping to change at page 13, line 27 skipping to change at page 14, line 33
ephemeral port must be unique across all IP address permutations, we ephemeral port must be unique across all IP address permutations, we
should ideally always use the same IP address to get a single should ideally always use the same IP address to get a single
starting offset for each association negotiation from a given remote starting offset for each association negotiation from a given remote
entity to minimize the possibility of collisions. A simple numerical entity to minimize the possibility of collisions. A simple numerical
sorting of the IP addresses and always using the numerically lowest sorting of the IP addresses and always using the numerically lowest
could achieve this. However, since most protocols most likely will could achieve this. However, since most protocols most likely will
report the same IP addresses in the same order in each association report the same IP addresses in the same order in each association
setup, this sorting is most likely not necessary and the 'first one' setup, this sorting is most likely not necessary and the 'first one'
can simply be used. can simply be used.
The ability of hostnames to uniquely define hosts can be discusses, The ability of hostnames to uniquely define hosts can be discussed,
and since SCTP always include at least one IP address, we recommend and since SCTP always includes at least one IP address, we recommend
to use this as input to the offset function F() and ignore hostnames to use this as input to the offset function F() and ignore hostnames
chunks when searching for ephemeral ports. chunks when searching for ephemeral ports.
It should be note that, as this algorithm uses a global counter
("next_ephemeral") for selecting ephemeral ports, if an attacker
could force a client to periodically establish a new TCP connection
to an attacker controlled machine (or through an attacker observable
routing path), the attacker could subtract consecutive source port
values to obtain the number of outoing TCP connections established
globally by the target host within that time period (up to wrap-
around issues and 5-tuple collisions, of course).
3.3.4. Algorithm 4: Double-hash randomization algorithm 3.3.4. Algorithm 4: Double-hash randomization algorithm
A tradeoff between maintaining a single global 'next_ephemeral' A tradeoff between maintaining a single global 'next_ephemeral'
variable and maintaining 2**N 'next_ephemeral' variables (where N is variable and maintaining 2**N 'next_ephemeral' variables (where N is
the width of of the result of F()) could be achieved as follows. The the width of of the result of F()) could be achieved as follows. The
system would keep an array of, TABLE_LENGTH short integers, which system would keep an array of TABLE_LENGTH short integers, which
would provide a separation of the increment of the 'next_ephemeral' would provide a separation of the increment of the 'next_ephemeral'
variable. This improvement could be incorporated into Algorithm 3 as variable. This improvement could be incorporated into Algorithm 3 as
follows: follows:
/* Initialization at system boot time */ /* Initialization at system boot time */
for(i = 0; i < TABLE_LENGTH; i++) for(i = 0; i < TABLE_LENGTH; i++)
table[i] = random % 65536; table[i] = random() % 65536;
/* Ephemeral port selection function */ /* Ephemeral port selection function */
num_ephemeral = max_ephemeral - min_ephemeral + 1;
offset = F(local_IP, remote_IP, remote_port, secret_key); offset = F(local_IP, remote_IP, remote_port, secret_key);
index = G(offset); index = G(offset);
count = max_ephemeral - min_ephemeral + 1; count = num_ephemeral;
do { do {
port = min_ephemeral + (offset + table[index]) port = min_ephemeral + (offset + table[index]) % num_ephemeral;
% (max_ephemeral - min_ephemeral + 1);
table[index]++; table[index]++;
count--;
if(five-tuple is unique) if(five-tuple is unique)
return port; return port;
count--;
} while (count > 0); } while (count > 0);
return ERROR; return ERROR;
Figure 5 Figure 5
We will refer to this algorithm as 'Algorithm 4'. We will refer to this algorithm as 'Algorithm 4'.
'table[]' could be initialized with random values, as indicated by 'table[]' could be initialized with random values, as indicated by
the initialization code in Figure 5. G() would return a value the initialization code in Figure 5. G() would return a value
between 0 and (TABLE_LENGTH-1) taking 'offset' as its input. G() between 0 and (TABLE_LENGTH-1) taking 'offset' as its input. G()
could, for example, perform the exclusive-or (xor) operation between could, for example, perform the exclusive-or (xor) operation between
all the bytes in 'offset', or could be another cryptographic hash all the bytes in 'offset', or could be some cryptographic hash
function such as that used in F(). function such as that used in F().
The array 'table[]' assures that succesive connections to the same The array 'table[]' assures that succesive connections to the same
end-point will use increasing ephemeral port numbers. However, end-point will use increasing ephemeral port numbers. However,
incrementation of the port numbers is separated into TABLE_LENGTH incrementation of the port numbers is separated into TABLE_LENGTH
different spaces, and thus the port reuse frequency will be different spaces, and thus the port reuse frequency will be
(probabilistically) lower than that of Algorithm 2. That is, a (probabilistically) lower than that of Algorithm 3. That is, a
connection established with some remote end-point will not connection established with some remote end-point will not
necessarily cause the 'next_ephemeral' variable corresponding to necessarily cause the 'next_ephemeral' variable corresponding to
other end-points to be incremented. other end-points to be incremented.
It is interesting to note that the size of 'table[]' does not limit It is interesting to note that the size of 'table[]' does not limit
the number of different port sequences, but rather separates the the number of different port sequences, but rather separates the
*increments* into TABLE_LENGTH different spaces. The actual port *increments* into TABLE_LENGTH different spaces. The actual port
sequence will result from adding the corresponding entry of 'table[]' sequence will result from adding the corresponding entry of 'table[]'
to the variable 'offset', which actually selects the actual port to the variable 'offset', which actually selects the actual port
sequence (as in Algorithm 3). sequence (as in Algorithm 3).
An attacker can perform traffic analysis for any "increment space"
into which the attacker has "visibility", namely that the attacker
can force the client to establish a transport-protocol connection
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 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.4. Secret-key considerations for hash-based port randomization 3.4. Secret-key considerations for hash-based port randomization
algorithms algorithms
Every complex manipulation (like MD5) is no more secure than the Every complex manipulation (like MD5) is no more secure than the
input values, and in the case of ephemeral ports, the secret key. If input values, and in the case of ephemeral ports, the secret key. If
an attacker is aware of which cryptographic hash function is being an attacker is aware of which cryptographic hash function is being
used by the victim (which we should expect), and the attacker can used by the victim (which we should expect), and the attacker can
obtain enough material (e.g. ephemeral ports chosen by the victim), obtain enough material (e.g. ephemeral ports chosen by the victim),
the attacker may simply search the entire secret key space to find the attacker may simply search the entire secret key space to find
matches. matches.
To protect against this, the secret key should be of a reasonable To protect against this, the secret key should be of a reasonable
length. Key lengths of 32-bits should be adequate, since a 32-bit length. Key lengths of 32 bits should be adequate, since a 32-bit
secret would result in approximately 65k possible secrets if the secret would result in approximately 65k possible secrets if the
attacker is able to obtain a single ephemeral port (assuming a good attacker is able to obtain a single ephemeral port (assuming a good
hash function). If the attacker is able to obtain more ephemeral hash function). If the attacker is able to obtain more ephemeral
ports, key lengths of 64-bits or more should be used. ports, key lengths of 64 bits or more should be used.
Another possible mechanism for protecting the secret key is to change Another possible mechanism for protecting the secret key is to change
it after some time. If the host platform is capable of producing it after some time. If the host platform is capable of producing
reasonable good random data, the secret key can be changed reasonable good random data, the secret key can be changed
automatically. automatically.
Changing the secret will cause abrupt shifts in the chosen ephemeral Changing the secret will cause abrupt shifts in the chosen ephemeral
ports, and consequently collisions may occur. Thus the change in ports, and consequently collisions may occur. Thus the change in
secret key should be done with consideration and could be performed secret key should be done with consideration and could be performed
whenever one of the following events occur: whenever one of the following events occur:
skipping to change at page 16, line 15 skipping to change at page 17, line 28
3.5. Choosing an ephemeral port randomization algorithm 3.5. Choosing an ephemeral port randomization algorithm
The algorithm sketched in Figure 1 is the traditional ephemeral port The algorithm sketched in Figure 1 is the traditional ephemeral port
selection algorithm implemented in BSD-derived systems. It generates selection algorithm implemented in BSD-derived systems. It generates
a global sequence of ephemeral port numbers, which makes it trivial 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 for an attacker to predict the port number that will be used for a
future transport protocol instance. future transport protocol instance.
Algorithm 1 and Algorithm 2 have the advantage that they provide Algorithm 1 and Algorithm 2 have the advantage that they provide
complete randomization. However, they may increase the chances of complete randomization. However, they may increase the chances of
port number collisions, which could lead to failure of the connection port number collisions, which could lead to the failure of the
establishment attempts. connection establishment attempt.
Algorithm 3 provides complete separation in local and remote IP Algorithm 3 provides complete separation in local and remote IP
addresses and remote port space, and only limited separation in other addresses and remote port space, and only limited separation in other
dimensions (See Section Section 3.4), and thus may scale better than dimensions (See Section Section 3.4), and thus may scale better than
Algorithm 1 and Algorithm 2. However, implementations should Algorithm 1 and Algorithm 2. However, implementations should
consider the performance impact of computing the cryptographic hash consider the performance impact of computing the cryptographic hash
used for the offset. used for the offset.
Algorithm 4 improves Algorithm 3, usually leading to a lower port Algorithm 4 improves Algorithm 3, usually leading to a lower port
reuse frequency, at the expense of more processor cycles used for reuse frequency, at the expense of more processor cycles used for
computing G(), and additional kernel memory for storing the array computing G(), and additional kernel memory for storing the array
'table[]'. 'table[]'.
Finally, a special case that precludes the utilization of Algorithm 3 Finally, a special case that may preclude the utilization of
and Algorithm 4 should be analyzed. There exist some applications Algorithm 3 and Algorithm 4 should be analyzed. There exist some
that contain the following code sequence: applications that contain the following code sequence:
s = socket(); s = socket();
bind(s, IP_address, port = *); bind(s, IP_address, port = *);
Figure 6 Figure 6
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 implementating Algorithm 3 or Algorithm
4 should consider using Algorithm 2 when facing the scenario just
described.
This code sequence results in the selection of an ephemeral port An alternative to this behavior would be to implement "lazy binding"
number. However, as neither the remote IP address nor the remote in response to the bind() call. That is, selection of an epphemeral
port will be available to the ephemeral port selection function, the port would be delayed until, e.g., connect() or send() are called.
hash function F() used in Algorithm 3 and Algorithm 4 will not have Thus, at that point the ephemeral port is actually selected, all the
all the required arguments, and thus the result of the hash function necessary arguments for the hash function F() would be available, and
will be impossible to compute. thus Algorithm 3 and Algorithm 4 could still be used in this
scenario. This policy has been implemented by Linux [Linux].
Transport protocols implementing Algorithm 3 or Algorithm 4 should 4. Port randomization and Network Address Port Translation (NAPT)
consider using Algorithm 2 when facing the scenario just described.
This policy has been implemented by Linux [Linux].
4. Security Considerations Network Address Port Translation (NAPT) translate 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 end-
points of transport-protocol connection, the obfuscation of the
ephemeral ports (from the point of view of the external network) will
depend on the ephemeral port selection function at the NAPT.
Therefore, NAPTs should consider randomizing the ephemeral ports by
means of any of the algorithms discussed in this document.
Section 3.5 provides guidance in choosing a port randomization
algorithm.
5. Security Considerations
Randomizing ports is no replacement for cryptographic mechanisms, Randomizing ports is no replacement for cryptographic mechanisms,
such as IPsec [RFC4301], in terms of protecting transport protocol such as IPsec [RFC4301], in terms of protecting transport protocol
instances against blind attacks. instances against blind attacks.
An eavesdropper, which can monitor the packets that correspond to the An eavesdropper, which can monitor the packets that correspond to the
connection to be attacked could learn the IP addresses and port connection to be attacked could learn the IP addresses and port
numbers in use (and also sequence numbers etc.) and easily attack the numbers in use (and also sequence numbers etc.) and easily attack the
connection. Randomizing ports does not provide any additional connection. Randomizing ports does not provide any additional
protection against this kind of attacks. In such situations, proper protection against this kind of attacks. In such situations, proper
skipping to change at page 18, line 5 skipping to change at page 21, line 5
ephemeral port offset (Algorithm 3 and Algorithm 4) for a given five- ephemeral port offset (Algorithm 3 and Algorithm 4) for a given five-
tuple can be sampled and subsequently used to attack an innocent peer tuple can be sampled and subsequently used to attack an innocent peer
reusing this address. However, this is only possible until a re- reusing this address. However, this is only possible until a re-
keying happens as described above. Also, since ephemeral ports are keying happens as described above. Also, since ephemeral ports are
only used on the client side (e.g. the one initiating the only used on the client side (e.g. the one initiating the
connection), both the attacker and the new peer need to act as connection), both the attacker and the new peer need to act as
servers in the scenario just described. While servers using dynamic servers in the scenario just described. While servers using dynamic
IP addresses exist, they are not very common and with an appropriate IP addresses exist, they are not very common and with an appropriate
re-keying mechanism the effect of this attack is limited. re-keying mechanism the effect of this attack is limited.
5. Acknowledgements 6. Acknowledgements
The offset function was inspired by the mechanism proposed by Steven The offset function was inspired by the mechanism proposed by Steven
Bellovin in [RFC1948] for defending against TCP sequence number Bellovin in [RFC1948] for defending against TCP sequence number
attacks. attacks.
The authors would like to thank (in alphabetical order) Mark Allman, The authors would like to thank (in alphabetical order) Mark Allman,
Lars Eggert, Gorry Fairhurst, Alfred Hoenes, Carlos Pignataro, Joe Matthias Bethke, Stephane Bortzmeyer, Brian Carpenter, Vincent
Touch, and Dan Wing for their valuable feedback on earlier versions Deffontaines, Lars Eggert, Gorry Fairhurst, Guillermo Gont, Alfred
of this document. Hoenes, Amit Klein, Carlos Pignataro, Joe Touch, and Dan Wing for
their valuable feedback on earlier versions of this document.
The authors would like to thank FreeBSD's Mike Silbersack for a very The authors would like to thank FreeBSD's Mike Silbersack for a very
fruitful discussion about ephemeral port selection techniques. fruitful discussion about ephemeral port selection techniques.
6. References 7. References
6.1. Normative References 7.1. Normative References
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
August 1980. August 1980.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, [RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, September 1981. RFC 793, September 1981.
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
April 1992. April 1992.
[RFC1948] Bellovin, S., "Defending Against Sequence Number Attacks", [RFC1948] Bellovin, S., "Defending Against Sequence Number Attacks",
RFC 1948, May 1996. RFC 1948, May 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5
Signature Option", RFC 2385, August 1998. Signature Option", RFC 2385, August 1998.
[RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address
Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Translator (NAT) Terminology and Considerations",
Zhang, L., and V. Paxson, "Stream Control Transmission RFC 2663, August 1999.
Protocol", RFC 2960, October 2000.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003. Applications", STD 64, RFC 3550, July 2003.
[RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and [RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and
G. Fairhurst, "The Lightweight User Datagram Protocol G. Fairhurst, "The Lightweight User Datagram Protocol
(UDP-Lite)", RFC 3828, July 2004. (UDP-Lite)", RFC 3828, July 2004.
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
skipping to change at page 20, line 5 skipping to change at page 23, line 5
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005. Internet Protocol", RFC 4301, December 2005.
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram
Congestion Control Protocol (DCCP)", RFC 4340, March 2006. Congestion Control Protocol (DCCP)", RFC 4340, March 2006.
[RFC4960] Stewart, R., "Stream Control Transmission Protocol", [RFC4960] Stewart, R., "Stream Control Transmission Protocol",
RFC 4960, September 2007. RFC 4960, September 2007.
6.2. Informative References 7.2. Informative References
[FreeBSD] The FreeBSD Project, "http://www.freebsd.org". [FreeBSD] The FreeBSD Project, "http://www.freebsd.org".
[IANA] "IANA Port Numbers", [IANA] "IANA Port Numbers",
<http://www.iana.org/assignments/port-numbers>. <http://www.iana.org/assignments/port-numbers>.
[I-D.ietf-tcpm-icmp-attacks] [I-D.ietf-tcpm-icmp-attacks]
Gont, F., "ICMP attacks against TCP", Gont, F., "ICMP attacks against TCP",
draft-ietf-tcpm-icmp-attacks-02 (work in progress), draft-ietf-tcpm-icmp-attacks-03 (work in progress),
May 2007. March 2008.
[RFC1337] Braden, B., "TIME-WAIT Assassination Hazards in TCP",
RFC 1337, May 1992.
[RFC4953] Touch, J., "Defending TCP Against Spoofing Attacks", [RFC4953] Touch, J., "Defending TCP Against Spoofing Attacks",
RFC 4953, July 2007. RFC 4953, July 2007.
[Linux] The Linux Project, "http://www.kernel.org". [Linux] The Linux Project, "http://www.kernel.org".
[NetBSD] The NetBSD Project, "http://www.netbsd.org". [NetBSD] The NetBSD Project, "http://www.netbsd.org".
[OpenBSD] The OpenBSD Project, "http://www.openbsd.org". [OpenBSD] The OpenBSD Project, "http://www.openbsd.org".
[Silbersack] [Silbersack]
Silbersack, M., "Improving TCP/IP security through Silbersack, M., "Improving TCP/IP security through
randomization without sacrificing interoperability.", randomization without sacrificing interoperability.",
EuroBSDCon 2005 Conference , 2005. EuroBSDCon 2005 Conference .
[Stevens] Stevens, W., "Unix Network Programming, Volume 1: [Stevens] Stevens, W., "Unix Network Programming, Volume 1:
Networking APIs: Socket and XTI, Prentice Hall", 1998. Networking APIs: Socket and XTI", Prentice Hall , 1998.
[I-D.ietf-tcpm-tcp-auth-opt] [I-D.ietf-tcpm-tcp-auth-opt]
Touch, J., Mankin, A., and R. Bonica, "The TCP Touch, J., Mankin, A., and R. Bonica, "The TCP
Authentication Option", draft-ietf-tcpm-tcp-auth-opt-00 Authentication Option", draft-ietf-tcpm-tcp-auth-opt-01
(work in progress), November 2007. (work in progress), July 2008.
[Watson] Watson, P., "Slipping in the Window: TCP Reset attacks", [Watson] Watson, P., "Slipping in the Window: TCP Reset Attacks",
december 2003. CanSecWest 2004 Conference .
Appendix A. Survey of the algorithms in use by some popular Appendix A. Survey of the algorithms in use by some popular
implementations implementations
A.1. FreeBSD A.1. FreeBSD
FreeBSD implements Algorithm 2. with a 'min_port' of 49152 and a FreeBSD implements Algorithm 1, and in response to this document now
'max_port' of 65535. If the selected port number is in use, the next uses a 'min_port' of 10000 and a 'max_port' of 65535. [FreeBSD]
available port number is tried next [FreeBSD].
A.2. Linux A.2. Linux
Linux implements Algorithm 3. If the algorithm is faced with the Linux implements Algorithm 3. If the algorithm is faced with the
corner-case scenario described in Section 3.5, Algorithm 2 is used corner-case scenario described in Section 3.5, Algorithm 1 is used
instead [Linux]. instead [Linux].
A.3. NetBSD A.3. NetBSD
NetBSD does not randomize ehemeral port numbers. It selects NetBSD does not randomize ephemeral port numbers. It selects
ephemeral port numbers from the range 49152-65535, starting from port ephemeral port numbers from the range 49152-65535, starting from port
65535, and decreasing the port number for each ephemeral port number 65535, and decreasing the port number for each ephemeral port number
selected [NetBSD]. selected [NetBSD].
A.4. OpenBSD A.4. OpenBSD
OpenBSD implements Algorithm 2. with a 'min_port' of 1024 and a OpenBSD implements Algorithm 1, with a 'min_port' of 1024 and a
'max_port' of 49151. If the selected port number is in use, the next 'max_port' of 49151. [OpenBSD]
available port number is tried next [OpenBSD].
Appendix B. Changes from previous versions of the draft Appendix B. Changes from previous versions of the draft
B.1. Changes from draft-ietf-tsvwg-port-randomisation-00 B.1. Changes from draft-ietf-tsvwg-port-randomization-01
o Added Section 2.3.
o Added discussion of "lazy binding in Section 3.5.
o Added discussion of obtaining the number of outgoing connections.
o Miscellaneous editorial changes
B.2. Changes from draft-ietf-tsvwg-port-randomization-00
o Added Section 3.1. o Added Section 3.1.
o Changed Intended Status from "Satandards Track" to "BCP". o Changed Intended Status from "Standards Track" to "BCP".
o Miscellaneous editorial changes. o Miscellaneous editorial changes.
B.2. Changes from draft-larsen-tsvwg-port-randomisation-02 B.3. Changes from draft-larsen-tsvwg-port-randomization-02
o Draft resubmitted as draft-ietf. o Draft resubmitted as draft-ietf.
o Included references and text on protocols other than TCP. o Included references and text on protocols other than TCP.
o Added the second variant of the simple port randomization o Added the second variant of the simple port randomization
algorithm algorithm
o Reorganized the algorithms into different sections o Reorganized the algorithms into different sections
o Miscellaneous editorial changes. o Miscellaneous editorial changes.
B.3. Changes from draft-larsen-tsvwg-port-randomisation-01 B.4. Changes from draft-larsen-tsvwg-port-randomization-01
o No changes. Draft resubmitted after expiration. o No changes. Draft resubmitted after expiration.
B.4. Changes from draft-larsen-tsvwg-port-randomization-00 B.5. Changes from draft-larsen-tsvwg-port-randomization-00
o Fixed a bug in expressions used to calculate number of ephemeral o Fixed a bug in expressions used to calculate number of ephemeral
ports ports
o Added a survey of the algorithms in use by popular TCP o Added a survey of the algorithms in use by popular TCP
implementations implementations
o The whole document was reorganizaed o The whole document was reorganizaed
o Miscellaneous editorial changes o Miscellaneous editorial changes
B.5. Changes from draft-larsen-tsvwg-port-randomisation-00 B.6. Changes from draft-larsen-tsvwg-port-randomisation-00
o Document resubmitted after original document by M. Larsen expired o Document resubmitted after original document by M. Larsen expired
in 2004 in 2004
o References were included to current WG documents of the TCPM WG o References were included to current WG documents of the TCPM WG
o The document was made more general, to apply to all transport o The document was made more general, to apply to all transport
protocols protocols
o Miscellaneous editorial changes o Miscellaneous editorial changes
Authors' Addresses Authors' Addresses
Michael Vittrup Larsen Michael Vittrup Larsen
TietoEnator TietoEnator
Skanderborgvej 232 Skanderborgvej 232
Aarhus DK-8260 Aarhus DK-8260
Denmark Denmark
skipping to change at page 25, line 44 skipping to change at line 996
attempt made to obtain a general license or permission for the use of attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
 End of changes. 74 change blocks. 
176 lines changed or deleted 267 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/