draft-ietf-tsvwg-port-randomization-00.txt   draft-ietf-tsvwg-port-randomization-01.txt 
tsvwg M. Larsen tsvwg M. Larsen
Internet-Draft TietoEnator Internet-Draft TietoEnator
Intended status: Standards Track F. Gont Intended status: Best Current F. Gont
Expires: June 6, 2008 UTN/FRH Practice UTN/FRH
December 4, 2007 Expires: August 28, 2008 February 25, 2008
Port Randomization Port Randomization
draft-ietf-tsvwg-port-randomization-00 draft-ietf-tsvwg-port-randomization-01
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 June 6, 2008. This Internet-Draft will expire on August 28, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). 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
skipping to change at page 3, line 8 skipping to change at page 3, line 8
described port number randomization algorithms provide improved 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 mechanisms described in this document are a
local modification that may be incrementally deployed, and that does local modification that may be incrementally deployed, and that does
not violate the specifications of any of the transport protocols that not violate the specifications of any of the transport protocols that
may benefit from it, such as TCP, UDP, SCTP, DCCP, and RTP. may benefit from it, such as TCP, UDP, SCTP, DCCP, and RTP.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Ephemeral Ports . . . . . . . . . . . . . . . . . . . . . . . 5 2. Ephemeral Ports . . . . . . . . . . . . . . . . . . . . . . . 6
2.1. Traditional Ephemeral Port Range . . . . . . . . . . . . . 5 2.1. Traditional Ephemeral Port Range . . . . . . . . . . . . . 6
2.2. Ephemeral port selection . . . . . . . . . . . . . . . . . 5 2.2. Ephemeral port selection . . . . . . . . . . . . . . . . . 6
3. Randomizing the Ephemeral Ports . . . . . . . . . . . . . . . 7 3. Randomizing the Ephemeral Ports . . . . . . . . . . . . . . . 8
3.1. Ephemeral port number range . . . . . . . . . . . . . . . 7 3.1. Characteristics of a good ephemeral port randomization
3.2. Ephemeral Port Randomization Algorithms . . . . . . . . . 7 algorithm . . . . . . . . . . . . . . . . . . . . . . . . 8
3.2.1. Algorithm 1: Simple port randomization algorithm . . . 7 3.2. Ephemeral port number range . . . . . . . . . . . . . . . 9
3.2.2. Algorithm 2: Another simple port randomization 3.3. Ephemeral Port Randomization Algorithms . . . . . . . . . 9
algorithm . . . . . . . . . . . . . . . . . . . . . . 9 3.3.1. Algorithm 1: Simple port randomization algorithm . . . 9
3.2.3. Algorithm 3: Simple hash-based algorithm . . . . . . . 9 3.3.2. Algorithm 2: Another simple port randomization
3.2.4. Algorithm 4: Double-hash randomization algorithm . . . 11 algorithm . . . . . . . . . . . . . . . . . . . . . . 11
3.3. Secret-key considerations for hash-based port 3.3.3. Algorithm 3: Simple hash-based algorithm . . . . . . . 11
randomization algorithms . . . . . . . . . . . . . . . . . 13 3.3.4. Algorithm 4: Double-hash randomization algorithm . . . 13
3.4. Choosing an ephemeral port randomization algorithm . . . . 14 3.4. Secret-key considerations for hash-based port
4. Security Considerations . . . . . . . . . . . . . . . . . . . 15 randomization algorithms . . . . . . . . . . . . . . . . . 15
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 3.5. Choosing an ephemeral port randomization algorithm . . . . 16
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 4. Security Considerations . . . . . . . . . . . . . . . . . . . 17
6.1. Normative References . . . . . . . . . . . . . . . . . . . 17 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18
6.2. Informative References . . . . . . . . . . . . . . . . . . 17 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
6.1. Normative References . . . . . . . . . . . . . . . . . . . 19
6.2. Informative References . . . . . . . . . . . . . . . . . . 20
Appendix A. Survey of the algorithms in use by some popular Appendix A. Survey of the algorithms in use by some popular
implementations . . . . . . . . . . . . . . . . . . . 19 implementations . . . . . . . . . . . . . . . . . . . 21
A.1. FreeBSD . . . . . . . . . . . . . . . . . . . . . . . . . 19 A.1. FreeBSD . . . . . . . . . . . . . . . . . . . . . . . . . 21
A.2. Linux . . . . . . . . . . . . . . . . . . . . . . . . . . 19 A.2. Linux . . . . . . . . . . . . . . . . . . . . . . . . . . 21
A.3. NetBSD . . . . . . . . . . . . . . . . . . . . . . . . . . 19 A.3. NetBSD . . . . . . . . . . . . . . . . . . . . . . . . . . 21
A.4. OpenBSD . . . . . . . . . . . . . . . . . . . . . . . . . 19 A.4. OpenBSD . . . . . . . . . . . . . . . . . . . . . . . . . 21
Appendix B. Changes from previous versions of the draft . . . . . 20 Appendix B. Changes from previous versions of the draft . . . . . 22
B.1. Changes from draft-larsen-tsvwg-port-randomisation-02 . . 20 B.1. Changes from draft-ietf-tsvwg-port-randomisation-00 . . . 22
B.2. Changes from draft-larsen-tsvwg-port-randomisation-01 . . 20 B.2. Changes from draft-larsen-tsvwg-port-randomisation-02 . . 22
B.3. Changes from draft-larsen-tsvwg-port-randomization-00 . . 20 B.3. Changes from draft-larsen-tsvwg-port-randomisation-01 . . 22
B.4. Changes from draft-larsen-tsvwg-port-randomisation-00 . . 20 B.4. Changes from draft-larsen-tsvwg-port-randomization-00 . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 B.5. Changes from draft-larsen-tsvwg-port-randomisation-00 . . 22
Intellectual Property and Copyright Statements . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24
Intellectual Property and Copyright Statements . . . . . . . . . . 25
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
that can be performed against the Transmission Control Protocol (TCP) (i.e., attacks that can be performed without the need to sniff the
[RFC0793] and similar protocols. The consequences of these attacks packets that correspond to the transport protocol instance to be
range from throughput-reduction to broken connections or data attacked) that can be performed against the Transmission Control
corruption [I-D.ietf-tcpm-icmp-attacks] [I-D.ietf-tcpm-tcp-antispoof] Protocol (TCP) [RFC0793] and similar protocols. The consequences of
[Watson]. these attacks range from throughput-reduction to broken connections
or data corruption [I-D.ietf-tcpm-icmp-attacks] [RFC4953] [Watson].
All these attacks rely on the attacker's ability to guess or know the All these attacks rely on the attacker's ability to guess or know the
five-tuple (Protocol, Source Address, Source port, Destination five-tuple (Protocol, Source Address, Source port, Destination
Address, Destination Port) that identifies the transport protocol Address, Destination Port) that identifies the transport protocol
instance to be attacked. instance to be attacked.
Services are usually located at fixed, 'well-known' ports [IANA] at Services are usually located at fixed, 'well-known' ports [IANA] at
the host supplying the service (the server). Client applications the host supplying the service (the server). Client applications
connecting to any such service will contact the server by specifying connecting to any such service will contact the server by specifying
the server IP address and service port number. The IP address and the server IP address and service port number. The IP address and
skipping to change at page 4, line 36 skipping to change at page 4, line 37
as ephemeral ports [Stevens]. as ephemeral ports [Stevens].
While the server IP address and well-known port and the client IP While the server IP address and well-known port and the client IP
address may be accurately guessed by an attacker, the ephemeral port address may be accurately guessed by an attacker, the ephemeral port
of the client is usually unknown and must be guessed. of the client is usually unknown and must be guessed.
This document describes a number of algorithms for random selection This document describes a number of algorithms for random selection
of the client ephemeral port, that reduce the possibility of an off- of the client ephemeral port, that reduce the possibility of an off-
path attacker guessing the exact value. They are not a replacement path attacker guessing the exact value. They are not a replacement
for cryptographic methods of protecting a connection such as IPsec for cryptographic methods of protecting a connection such as IPsec
[RFC4301] or the TCP MD5 signature option [RFC2385]. However, the [RFC4301], the TCP MD5 signature option [RFC2385], or the TCP
proposed algorithms provide improved obfuscation with very little Authentication Option [I-D.ietf-tcpm-tcp-auth-opt]. For example,
effort and without any key management overhead. 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 connection to be attacked. However, the proposed
algorithms provide improved obfuscation with very little effort and
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 level of obfuscation and ease of
implementation. Thus the algorithms must be computationally 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",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
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
The Internet Assigned Numbers Authority (IANA) assigns the unique The Internet Assigned Numbers Authority (IANA) assigns the unique
parameters and values used in protocols developed by the Internet parameters and values used in protocols developed by the Internet
Engineering Task Force (IETF), including well-known ports [IANA]. Engineering Task Force (IETF), including well-known ports [IANA].
IANA has traditionally reserved the following use of the 16-bit port IANA has traditionally reserved the following use of the 16-bit port
range of TCP and UDP: range of TCP and UDP:
skipping to change at page 6, line 5 skipping to change at page 7, line 5
As each communication instance is identified by the five-tuple As each communication instance is identified by the five-tuple
{protocol, local IP address, local port, remote IP address, remote {protocol, local IP address, local port, remote IP address, remote
port}, the selection of ephemeral port numbers must result in a port}, the selection of ephemeral port numbers must result in a
unique five-tuple. unique five-tuple.
Selection of ephemeral ports such that they result in unique five- Selection of ephemeral ports such that they result in unique five-
tuples is handled by some operating systems by having a per-protocol tuples is handled by some operating systems by having a per-protocol
global 'next_ephemeral' variable that is equal to the previously global 'next_ephemeral' variable that is equal to the previously
chosen ephemeral port + 1, i.e. the selection process is: chosen ephemeral port + 1, i.e. the selection process is:
next_ephemeral = min_ephemeral; /*initialization, could be random */ /* Initialization at system boot time. Initialization value could be random */
next_ephemeral = min_ephemeral;
/* Ephemeral port selection */ /* Ephemeral port selection function */
count = max_ephemeral - min_ephemeral + 1; count = max_ephemeral - min_ephemeral + 1;
do { do {
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++;
} }
skipping to change at page 7, line 7 skipping to change at page 8, line 7
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.
3. Randomizing the Ephemeral Ports 3. Randomizing the Ephemeral Ports
3.1. Ephemeral port number range 3.1. Characteristics of a good ephemeral port randomization algorithm
There are a number of factors to consider when designing a policy of
selection of ephemeral ports, which include:
o Minimizing the predictability of the ephemeral port numbers used
for future connections.
o Maximizing the port reuse cycle.
o Avoiding conflict with applications that depend on the use of
specific port numbers.
Given the goal of improving TCP's resistance to attack by obfuscation
of the four-tuple that identifies a TCP connection, it is key to
minimize the predictability of the ephemeral ports that will be
selected for new connections. 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 a short reuse cycle of port
numbers, which could lead to the interoperability problems discussed
in . It is also worth noting that, provided adequate randomization
algorithms are in use, the larger the range from which ephemeral pots
are selected, the smaller the chances of an attacker are to guess the
selected port number.
A number of implementations will not allow the creation of a new
connection if there exists a previous incarnation of the same
connection in any state other than the fictional state CLOSED. This
can be problematic in scenarios in which a client establishes
connections with a specific service at server at a high rate: even if
the connections are also closed at a high rate, one of the systems
(the one performing the active close) will keep each of the closed
connection in the TIME-WAIT state for 2*MSL. If the connection rate
is high enough, at some point all the ephemeral ports at the client
will be in use by some connection in the TIME-WAIT state, thus
preventing the establishment of new connections. Therefore, the only
strategy that can be relied upon to avoid this interoperability
problem is to maximize the ephemeral port reuse cycle at a client,
with the goal of reducing the chances that a previous incarnation of
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
specific port numbers that may be within the ephemeral ports range.
If such an application was run while the corresponding port number
was in use, the application would fail. Therefore, transport
protocols should avoid using those port numbers as ephemeral ports.
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
traditionally consisted of the 49152-65535 range. However, it should traditionally consisted of the 49152-65535 range. However, it should
also include the range 1024-49151 range. also include the range 1024-49151 range.
Since this range includes user-specific server ports, this may not Since this range includes user-specific server ports, this may not
always be possible, though. A possible workaround for this potential always be possible, though. A possible workaround for this potential
problem would be to maintain an array of bits, in which each bit problem would be to maintain an array of bits, in which each bit
would correspond to each of the port numbers in the range 1024-65535. would correspond to each of the port numbers in the range 1024-65535.
A bit set to 0 would indicate that the corresponding port is A bit set to 0 would indicate that the corresponding port is
available for allocation, while a bit set to one would indicate that available for allocation, while a bit set to one would indicate that
the port is reserved and therefore cannot be allocated. Thus, before the port is reserved and therefore cannot be allocated. Thus, before
allocating a port number, the ephemeral port selection function would allocating a port number, the ephemeral port selection function would
check this array of bits, avoiding the allocation of ports that may check this array of bits, avoiding the allocation of ports that may
be needed for specific applications. be needed for specific applications.
Transport protocols SHOULD use the largest possible port range, since Transport protocols SHOULD use the largest possible port range, since
this improves the obfuscation provided by randomizing the ephemeral this improves the obfuscation provided by randomizing the ephemeral
ports. ports.
3.2. Ephemeral Port Randomization Algorithms 3.3. Ephemeral Port Randomization Algorithms
3.2.1. Algorithm 1: Simple port randomization algorithm Transport protocols SHOULD allocate their ephemeral ports randomly,
since this help 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 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 */
next_ephemeral = min_ephemeral + random() next_ephemeral = min_ephemeral + random()
% (max_ephemeral - min_ephemeral + 1); % (max_ephemeral - min_ephemeral + 1);
count = max_ephemeral - min_ephemeral + 1; 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) {
skipping to change at page 8, line 52 skipping to change at page 11, line 4
addresses and the server port are fixed). Gateways such as proxy addresses and the server port are fixed). Gateways such as proxy
servers are an example of such a system. servers are an example of such a system.
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.
3.2.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 */
next_ephemeral = min_ephemeral + random() next_ephemeral = min_ephemeral + random()
% (max_ephemeral - min_ephemeral + 1); % (max_ephemeral - min_ephemeral + 1);
count = max_ephemeral - min_ephemeral + 1; 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()
skipping to change at page 9, line 35 skipping to change at page 11, line 38
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 only
difference between this algorithm and Algorithm 1 is that the search difference between this algorithm and Algorithm 1 is that the search
time for this variant may be longer than for the later, particularly time for this variant may be longer than for the later, particularly
when there are a large number of port numbers already in use. when there are a large number of port numbers already in use.
3.2.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 traditional BSD
port selection algorithm, while at the same time achieve the 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 */ /* Initialization code at system boot time. Initialization value could be random. */
next_ephemeral = 0; /* could be random */ next_ephemeral = 0;
/* Ephemeral port selection */ /* Ephemeral port selection function */
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 = max_ephemeral - min_ephemeral + 1;
do { do {
port = min_ephemeral + (next_ephemeral + offset) port = min_ephemeral + (next_ephemeral + offset)
% (max_ephemeral - min_ephemeral + 1); % (max_ephemeral - min_ephemeral + 1);
next_ephemeral++; next_ephemeral++;
count--; count--;
if(five-tuple is unique) if(five-tuple is unique)
skipping to change at page 11, line 28 skipping to change at page 13, line 32
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 discusses,
and since SCTP always include at least one IP address, we recommend and since SCTP always include 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.
3.2.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 code */ /* Initialization at system boot time */
for(i = 0; i < TABLE_LENGTH; i++) /* Initialization code */ for(i = 0; i < TABLE_LENGTH; i++)
table[i] = random % 65536; table[i] = random % 65536;
/* Ephemeral port selection */ /* Ephemeral port selection function */
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 = max_ephemeral - min_ephemeral + 1;
do { do {
port = min_ephemeral + (offset + table[index]) port = min_ephemeral + (offset + table[index])
% (max_ephemeral - min_ephemeral + 1); % (max_ephemeral - min_ephemeral + 1);
table[index]++; table[index]++;
count--; count--;
skipping to change at page 13, line 7 skipping to change at page 15, line 7
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).
3.3. 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.
skipping to change at page 14, line 5 skipping to change at page 16, line 5
o There are few active connections (i.e., possibility of collision o There are few active connections (i.e., possibility of collision
is low). is low).
o There is little traffic (the performance overhead of collisions is o There is little traffic (the performance overhead of collisions is
tolerated). tolerated).
o There is enough random data available to change the secret key o There is enough random data available to change the secret key
(pseudo-random changes should not be done). (pseudo-random changes should not be done).
3.4. 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 failure of the connection
establishment attempts. establishment attempts.
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.3), 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 precludes the utilization of Algorithm 3
skipping to change at page 16, line 11 skipping to change at page 18, line 11
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 5. 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 Mark Allman, Lars Eggert, Gorry The authors would like to thank (in alphabetical order) Mark Allman,
Fairhurst, Alfred Hoenes, Carlos Pignataro, and Dan Wing for their Lars Eggert, Gorry Fairhurst, Alfred Hoenes, Carlos Pignataro, Joe
valuable feedback on earlier versions of this document. 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 6. References
6.1. Normative References 6.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
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., [RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C.,
Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M.,
Zhang, L., and V. Paxson, "Stream Control Transmission Zhang, L., and V. Paxson, "Stream Control Transmission
Protocol", RFC 2960, October 2000. 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
skipping to change at page 18, line 13 skipping to change at page 20, line 17
[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-02 (work in progress),
May 2007. May 2007.
[I-D.ietf-tcpm-tcp-antispoof] [RFC4953] Touch, J., "Defending TCP Against Spoofing Attacks",
Touch, J., "Defending TCP Against Spoofing Attacks", RFC 4953, July 2007.
draft-ietf-tcpm-tcp-antispoof-06 (work in progress),
February 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 , 2005.
[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]
Touch, J., Mankin, A., and R. Bonica, "The TCP
Authentication Option", draft-ietf-tcpm-tcp-auth-opt-00
(work in progress), November 2007.
[Watson] Watson, P., "Slipping in the Window: TCP Reset attacks", [Watson] Watson, P., "Slipping in the Window: TCP Reset attacks",
december 2003. december 2003.
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 2. with a 'min_port' of 49152 and a
'max_port' of 65535. If the selected port number is in use, the next 'max_port' of 65535. If the selected port number is in use, the next
available port number is tried next [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.4, Algorithm 2 is used corner-case scenario described in Section 3.5, Algorithm 2 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 ehemeral 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 2. 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. If the selected port number is in use, the next
available port number is tried next [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-larsen-tsvwg-port-randomisation-02 B.1. Changes from draft-ietf-tsvwg-port-randomisation-00
o Added Section 3.1.
o Changed Intended Status from "Satandards Track" to "BCP".
o Miscellaneous editorial changes.
B.2. Changes from draft-larsen-tsvwg-port-randomisation-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.2. Changes from draft-larsen-tsvwg-port-randomisation-01 B.3. Changes from draft-larsen-tsvwg-port-randomisation-01
o No changes. Draft resubmitted after expiration. o No changes. Draft resubmitted after expiration.
B.3. Changes from draft-larsen-tsvwg-port-randomization-00 B.4. 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.4. Changes from draft-larsen-tsvwg-port-randomisation-00 B.5. 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 22, line 7 skipping to change at page 25, line 7
Universidad Tecnologica Nacional / Facultad Regional Haedo Universidad Tecnologica Nacional / Facultad Regional Haedo
Evaristo Carriego 2644 Evaristo Carriego 2644
Haedo, Provincia de Buenos Aires 1706 Haedo, Provincia de Buenos Aires 1706
Argentina Argentina
Phone: +54 11 4650 8472 Phone: +54 11 4650 8472
Email: fernando@gont.com.ar Email: fernando@gont.com.ar
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
 End of changes. 38 change blocks. 
76 lines changed or deleted 172 lines changed or added

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