draft-ietf-tsvwg-port-randomization-05.txt   draft-ietf-tsvwg-port-randomization-06.txt 
Transport Area Working Group M. Larsen Transport Area Working Group M. Larsen
(tsvwg) TietoEnator (tsvwg) TietoEnator
Internet-Draft F. Gont Internet-Draft F. Gont
Intended status: BCP UTN/FRH Intended status: BCP UTN/FRH
Expires: June 3, 2010 November 30, 2009 Expires: August 19, 2010 February 15, 2010
Port Randomization Transport Protocol Port Randomization Recommendations
draft-ietf-tsvwg-port-randomization-05 draft-ietf-tsvwg-port-randomization-06
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 number of simple and be attacked. This document describes a number of simple and
efficient methods for the selection of the client port number, such efficient methods for the selection of the client port number, such
that the possibility of an attacker guessing the exact value is that the possibility of an attacker guessing the exact value is
reduced. While this is not a replacement for cryptographic methods reduced. While this is not a replacement for cryptographic methods
for protecting the connection, the described port number obfuscation for protecting the transport-protocol instance, the described port
algorithms provide improved security/obfuscation with very little number obfuscation algorithms provide improved security/obfuscation
effort and without any key management overhead. The algorithms with very little effort and without any key management overhead. The
described in this document are local policies that may be algorithms described in this document are local policies that may be
incrementally deployed, and that do not violate the specifications of incrementally deployed, and that do not violate the specifications of
any of the transport protocols that may benefit from them, such as any of the transport protocols that may benefit from them, such as
TCP, UDP, UDP-lite, SCTP, DCCP, and RTP. TCP, UDP, UDP-lite, SCTP, DCCP, and RTP (provided the RTP application
explicitly signals the RTP and RTCP port numbers).
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and 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
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 2, line 8 skipping to change at page 2, line 9
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 3, 2010. This Internet-Draft will expire on August 19, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the BSD License. described in the BSD License.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Ephemeral Ports . . . . . . . . . . . . . . . . . . . . . . . 7 2. Ephemeral Ports . . . . . . . . . . . . . . . . . . . . . . . 7
2.1. Traditional Ephemeral Port Range . . . . . . . . . . . . . 7 2.1. Traditional Ephemeral Port Range . . . . . . . . . . . . . 7
2.2. Ephemeral port selection . . . . . . . . . . . . . . . . . 7 2.2. Ephemeral port selection . . . . . . . . . . . . . . . . . 7
2.3. Collision of connection-id's . . . . . . . . . . . . . . . 8 2.3. Collision of instance-id's . . . . . . . . . . . . . . . . 8
3. Obfuscating the Ephemeral Ports . . . . . . . . . . . . . . . 10 3. Obfuscating the Ephemeral Ports . . . . . . . . . . . . . . . 10
3.1. Characteristics of a good ephemeral port obfuscation 3.1. Characteristics of a good ephemeral port obfuscation
algorithm . . . . . . . . . . . . . . . . . . . . . . . . 10 algorithm . . . . . . . . . . . . . . . . . . . . . . . . 10
3.2. Ephemeral port number range . . . . . . . . . . . . . . . 11 3.2. Ephemeral port number range . . . . . . . . . . . . . . . 12
3.3. Ephemeral Port Obfuscation Algorithms . . . . . . . . . . 12 3.3. Ephemeral Port Obfuscation Algorithms . . . . . . . . . . 12
3.3.1. Algorithm 1: Simple port randomization algorithm . . . 12 3.3.1. Algorithm 1: Simple port randomization algorithm . . . 12
3.3.2. Algorithm 2: Another simple port randomization 3.3.2. Algorithm 2: Another simple port randomization
algorithm . . . . . . . . . . . . . . . . . . . . . . 14 algorithm . . . . . . . . . . . . . . . . . . . . . . 14
3.3.3. Algorithm 3: Simple hash-based algorithm . . . . . . . 14 3.3.3. Algorithm 3: Simple hash-based algorithm . . . . . . . 14
3.3.4. Algorithm 4: Double-hash obfuscation algorithm . . . . 17 3.3.4. Algorithm 4: Double-hash obfuscation algorithm . . . . 17
3.3.5. Algorithm 5: Random-increments port selection 3.3.5. Algorithm 5: Random-increments port selection
algorithm . . . . . . . . . . . . . . . . . . . . . . 18 algorithm . . . . . . . . . . . . . . . . . . . . . . 18
3.4. Secret-key considerations for hash-based port 3.4. Secret-key considerations for hash-based port
obfuscation algorithms . . . . . . . . . . . . . . . . . . 20 obfuscation algorithms . . . . . . . . . . . . . . . . . . 20
skipping to change at page 3, line 45 skipping to change at page 3, line 45
Appendix A. Survey of the algorithms in use by some popular Appendix A. Survey of the algorithms in use by some popular
implementations . . . . . . . . . . . . . . . . . . . 30 implementations . . . . . . . . . . . . . . . . . . . 30
A.1. FreeBSD . . . . . . . . . . . . . . . . . . . . . . . . . 30 A.1. FreeBSD . . . . . . . . . . . . . . . . . . . . . . . . . 30
A.2. Linux . . . . . . . . . . . . . . . . . . . . . . . . . . 30 A.2. Linux . . . . . . . . . . . . . . . . . . . . . . . . . . 30
A.3. NetBSD . . . . . . . . . . . . . . . . . . . . . . . . . . 30 A.3. NetBSD . . . . . . . . . . . . . . . . . . . . . . . . . . 30
A.4. OpenBSD . . . . . . . . . . . . . . . . . . . . . . . . . 30 A.4. OpenBSD . . . . . . . . . . . . . . . . . . . . . . . . . 30
A.5. OpenSolaris . . . . . . . . . . . . . . . . . . . . . . . 30 A.5. OpenSolaris . . . . . . . . . . . . . . . . . . . . . . . 30
Appendix B. Changes from previous versions of the draft (to Appendix B. Changes from previous versions of the draft (to
be removed by the RFC Editor before publication be removed by the RFC Editor before publication
of this document as a RFC . . . . . . . . . . . . . . 31 of this document as a RFC . . . . . . . . . . . . . . 31
B.1. Changes from draft-ietf-tsvwg-port-randomization-04 . . . 31 B.1. Changes from draft-ietf-tsvwg-port-randomization-05 . . . 31
B.2. Changes from draft-ietf-tsvwg-port-randomization-03 . . . 31 B.2. Changes from draft-ietf-tsvwg-port-randomization-04 . . . 31
B.3. Changes from draft-ietf-tsvwg-port-randomization-02 . . . 31 B.3. Changes from draft-ietf-tsvwg-port-randomization-03 . . . 31
B.4. Changes from draft-ietf-tsvwg-port-randomization-01 . . . 31 B.4. Changes from draft-ietf-tsvwg-port-randomization-02 . . . 31
B.5. Changes from draft-ietf-tsvwg-port-randomization-00 . . . 31 B.5. Changes from draft-ietf-tsvwg-port-randomization-01 . . . 31
B.6. Changes from draft-larsen-tsvwg-port-randomization-02 . . 31 B.6. Changes from draft-ietf-tsvwg-port-randomization-00 . . . 31
B.7. Changes from draft-larsen-tsvwg-port-randomization-01 . . 32 B.7. Changes from draft-larsen-tsvwg-port-randomization-02 . . 31
B.8. Changes from draft-larsen-tsvwg-port-randomization-00 . . 32 B.8. Changes from draft-larsen-tsvwg-port-randomization-01 . . 32
B.9. Changes from draft-larsen-tsvwg-port-randomisation-00 . . 32 B.9. Changes from draft-larsen-tsvwg-port-randomization-00 . . 32
B.10. Changes from draft-larsen-tsvwg-port-randomisation-00 . . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33
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
skipping to change at page 5, line 30 skipping to change at page 5, line 30
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
port number of the client are normally left unspecified by the client port number of the client are normally left unspecified by the client
application and thus chosen automatically by the client networking application and thus chosen automatically by the client networking
stack. Ports chosen automatically by the networking stack are known stack. Ports chosen automatically by the networking stack are known
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 known by an attacker, the ephemeral port of the client
of the client is usually unknown and must be guessed. is usually unknown and must be guessed.
This document describes a number of algorithms for the selection of This document describes a number of algorithms for the selection of
the ephemeral ports, such that the possibility of an off-path ephemeral port numbers, such that the possibility of an off-path
attacker guessing the exact value is reduced. They are not a attacker guessing the exact value is reduced. They are not a
replacement for cryptographic methods of protecting a connection such replacement for cryptographic methods of protecting a transport-
as IPsec [RFC4301], the TCP MD5 signature option [RFC2385], or the protocol instance such as IPsec [RFC4301], the TCP MD5 signature
TCP Authentication Option [I-D.ietf-tcpm-tcp-auth-opt]. For example, option [RFC2385], or the TCP Authentication Option
they do not provide any mitigation in those scenarios in which the [I-D.ietf-tcpm-tcp-auth-opt]. For example, they do not provide any
attacker is able to sniff the packets that correspond to the mitigation in those scenarios in which the attacker is able to sniff
transport protocol connection to be attacked. However, the proposed the packets that correspond to the transport protocol instance to be
algorithms provide improved obfuscation with very little effort and attacked. However, the proposed algorithms provide improved
without any key management overhead. 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 do 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 them, such as TCP [RFC0793], UDP [RFC0768], SCTP [RFC4960], DCCP
[RFC4340], UDP-lite [RFC3828], and RTP [RFC3550]. [RFC4340], UDP-lite [RFC3828], and RTP [RFC3550] (provided the RTP
application explicitly signals the RTP and RTCP port numbers with
e.g.[RFC3605]).
Since these mechanisms are obfuscation techniques, focus has been on Since these mechanisms are obfuscation techniques, focus has been on
a reasonable compromise between the level of obfuscation and the ease a reasonable compromise between the level of obfuscation and the ease
of implementation. Thus the algorithms must be computationally of implementation. Thus the algorithms must be computationally
efficient, and not require substantial state. efficient, and not require substantial state.
We note that while the technique of mitigating "blind" attacks by We note that while the technique of mitigating "blind" attacks by
obfuscating the ephemeral port election is well-known as "port obfuscating the ephemeral port selection is well-known as "port
randomization", the goal of the algorithms described in this document randomization", the goal of the algorithms described in this document
is to reduce the chances of an attacker guessing the ephemeral ports is to reduce the chances of an attacker guessing the ephemeral ports
selected for new connections, rather than to actually produce selected for new transport protocol instances, rather than to
mathematically random sequences of ephemeral ports. actually produce mathematically random sequences of ephemeral ports.
Throughout this document we will use the term "transport-protocol
instance" as a general term to refer to an instantiation of a
transport protocol (e.g, a "connection" in the case of connection-
oriented transport protocols) and the term "instance-id" as a short-
handle to refer to the group of values that identify a transport-
protocol instance (e.g., in the case of TCP, the five-tuple
{Protocol, IP Source Address, TCP Source Port, IP Destination
Address, TCP Destination Port}).
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 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
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 reserved the following use of the 16-bit port range of TCP
range of TCP and UDP: and UDP:
o The Well Known Ports, 0 through 1023. o The Well Known Ports, 0 through 1023.
o The Registered Ports, 1024 through 49151 o The Registered Ports, 1024 through 49151
o The Dynamic and/or Private Ports, 49152 through 65535 o The Dynamic and/or Private Ports, 49152 through 65535
The range for assigned ports managed by the IANA is 0-1023, with the The dynamic port range defined by IANA consists of the 49152-65535
remainder being registered by IANA but not assigned. range, and is meant for the selection of ephemeral ports.
The ephemeral port range defined by IANA has traditionally consisted
of the 49152-65535 range.
2.2. Ephemeral port selection 2.2. Ephemeral port selection
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
tuples is handled by some implementations by having a per-protocol instance-id's (five-tuples) is handled by some implementations by
global 'next_ephemeral' variable that is equal to the previously having a per-protocol global 'next_ephemeral' variable that is equal
chosen ephemeral port + 1, i.e. the selection process is: to the previously chosen ephemeral port + 1, i.e. the selection
process is:
/* Initialization at system boot time. Could be random */ /* Initialization at system boot time. Could be random */
next_ephemeral = min_ephemeral; next_ephemeral = min_ephemeral;
/* Ephemeral port selection function */ /* 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) {
skipping to change at page 8, line 30 skipping to change at page 8, line 30
return port; return port;
count--; 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 adequately provided that the number of
a each transport protocol that have a life-time longer than it takes transport-protocol instances (for a each transport protocol) that
to exhaust the total ephemeral port range is small, so that five- have a life-time longer than it takes to exhaust the total ephemeral
tuple collisions are rare. port range is small, so that collisions of instance-id's 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 transport-protocol instances and the next ports chosen by the client
predict. If an attacker operates an "innocent" server to which the are easy to predict. If an attacker operates an "innocent" server to
client connects, it is easy to obtain a reference point for the which the client connects, it is easy to obtain a reference point for
current value of the 'next_ephemeral' variable. Additionally, if an the current value of the 'next_ephemeral' variable. Additionally, if
attacker could force a client to periodically establish a new TCP an attacker could force a client to periodically establish e.g., a
connection to an attacker controlled machine (or through an attacker new TCP connection to an attacker controlled machine (or through an
observable routing path), the attacker could subtract consecutive attacker observable routing path), the attacker could subtract
source port values to obtain the number of outoing TCP connections consecutive source port values to obtain the number of outgoing TCP
established globally by the target host within that time period (up connections established globally by the target host within that time
to wrap-around issues and 5-tuple collisions, of course). period (up to wrap-around issues and instance-id collisions, of
course).
2.3. Collision of connection-id's 2.3. Collision of instance-id's
While it is possible for the ephemeral port selection algorithm to While it is possible for the ephemeral port selection algorithm to
verify that the selected port number results in connection-id that is verify that the selected port number results in a instance-id that is
not currently in use at that system, the resulting connection-id may not currently in use by that system, the resulting instance-id may
still be in use at a remote system. For example, consider a scenario 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 in which a client establishes a TCP connection with a remote web
server, and the web server performs the active close on the server, and the web server performs the active close on the
connection. While the state information for this connection will connection. While the state information for this connection will
disappear at the client side (that is, the connection will be moved disappear at the client side (that is, the connection will be moved
to the fictional CLOSED state), the connection-id will remain in the to the fictional CLOSED state), the instance-id will remain in the
TIME-WAIT state at the web server for 2*MSL (Maximum Segment TIME-WAIT state at the web server for 2*MSL (Maximum Segment
Lifetime). If the same client tried to create a new incarnation of Lifetime). If the same client tried to create a new incarnation of
the previous connection (that is, a connection with the same the previous connection (that is, a connection with the same
connection-id as the one in the TIME_WAIT state at the server), a instance-id as the one in the TIME_WAIT state at the server), an
connection-id "collision" would occur. The effect of these instance-id "collision" would occur. The effect of these collisions
collisions range from connection-establishment failures to TIME-WAIT range from connection-establishment failures to TIME-WAIT state
state assassination (with the potential of data corruption) assassination (with the potential of data corruption) [RFC1337]. In
[RFC1337]. In scenarios in which a specific client establishes TCP scenarios in which a specific client establishes TCP connections with
connections with a specific service at a server, these problems a specific service at a server, these problems become evident.
become evident. Therefore, an ephemeral port selection algorithm Therefore, an ephemeral port selection algorithm should ideally
should ideally minimize the rate of connection-id collisions. minimize the rate of instance-id collisions.
A simple approach to minimize the rate of these collisions would be A simple approach to minimize the rate of these collisions would be
to choose port numbers incrementally, so that a given port number to choose port numbers incrementally, so that a given port number
would not be reused until the rest of the port numbers in ephemeral would not be reused until the rest of the port numbers in ephemeral
port range have been used for a transport protocol instance. port range have been used for a transport protocol instance.
However, if a single global variable were used to keep track of the However, if a single global variable were used to keep track of the
last ephemeral port selected, ephemeral port numbers would be last ephemeral port selected, ephemeral port numbers would be
trivially predictable, thus making it easier for an off-path attacker trivially predictable, thus making it easier for an off-path attacker
to "guess" the connection-id in use by a target connection. to "guess" the instance-id in use by a target transport-protocol
Section 3.3.3 and Section 3.3.4 describe algorithms that select port instance. Section 3.3.3 and Section 3.3.4 describe algorithms that
numbers incrementally, while still making it difficult for an off- select port numbers incrementally, while still making it difficult
path attacker to predict the ephemeral ports used for future for an off-path attacker to predict the ephemeral ports used for
connections. future transport-protocol instances.
Another possible approach to minimize the rate of collisions of A simple but inefficient approach to minimize the rate of collisions
connection-id's would be for both end-points of a TCP connection to of instance-id's would be, e.g. in the case of TCP, for both end-
keep state about recent connections (e.g., have both end-points end points of a TCP connection to keep state about recent connections
up in the TIME-WAIT state). (e.g., have both end-points end up in the TIME-WAIT state).
3. Obfuscating the Ephemeral Ports 3. Obfuscating the Ephemeral Ports
3.1. Characteristics of a good ephemeral port obfuscation algorithm 3.1. Characteristics of a good ephemeral port obfuscation algorithm
There are a number of factors to consider when designing a policy of There are a number of factors to consider when designing an algorithm
selection of ephemeral ports, which include: for selecting 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 transport-protocol instances.
o Minimizing collisions of connection-id's o Minimizing collisions of instance-id's
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 the transport protocol's resistance to Given the goal of improving the transport protocol's resistance to
attack by obfuscation of the five-tuple that identifies a transport- attack by obfuscation of the instance-id, it is key to minimize the
protocol instance, it is key to minimize the predictability of the predictability of the ephemeral ports that will be selected for new
ephemeral ports that will be selected for new connections. While the transport-protocol instances. While the obvious approach to address
obvious approach to address this requirement would be to select the this requirement would be to select the ephemeral ports by simply
ephemeral ports by simply picking a random value within the chosen picking a random value within the chosen port number range, this
port number range, this straightforward policy may lead to collisions straightforward policy may lead to collisions of instance-id's, which
of connection-id's, which could lead to the interoperability problems could lead to the interoperability problems (e.g., delays in the
(namely delays in the establishment of new connections, failures in establishment of new connections, failures in connection-
connection-establishment, or data curruption) discussed in establishment, or data corruption) discussed in Section 2.3. As
Section 2.3. As discussed in Section 1, it is worth noting that discussed in Section 1, it is worth noting that while the technique
while the technique of mitigating "blind" attacks by obfuscating the of mitigating "blind" attacks by obfuscating the ephemeral port
ephemeral port election is well-known as "port randomization", the election is well-known as "port randomization", the goal of the
goal of the algorithms described in this document is to reduce the algorithms described in this document is to reduce the chances of an
chances of an attacker guessing the ephemeral ports selected for new attacker guessing the ephemeral ports selected for new transport-
connections, rather than to actually produce sequences of protocol instances, rather than to actually produce sequences of
mathematically random ephemeral port numbers. mathematically random ephemeral port numbers.
It is also worth noting that, provided adequate algorithms are in It is also worth noting that, provided adequate algorithms are in
use, the larger the range from which ephemeral pots are selected, the use, the larger the range from which ephemeral pots are selected, the
smaller the chances of an attacker are to guess the selected port smaller the chances of an attacker are to guess the selected port
number. number.
In scenarios in which a specific client establishes connections with In scenarios in which a specific client establishes transport-
a specific service at a server, the problems described in Section 2.3 protocol instances with a specific service at a server, the problems
become evident. A good algorithm to minimize the collisions of described in Section 2.3 become evident. A good algorithm to
connection-id's would consider the time a given five-tuple was last minimize the collisions of instance-id's would consider the time a
used, and would avoid reusing the last recently used five-tuples. A given five-tuple was last used, and would avoid reusing the last
simple approach to minimize the rate of collisions would be to choose recently used five-tuples. A simple approach to minimize the rate of
port numbers incrementally, so that a given port number would not be collisions would be to choose port numbers incrementally, so that a
reused until the rest of the port numbers in the ephemeral port range given port number would not be reused until the rest of the port
have been used for a transport protocol instance. However, if a numbers in the ephemeral port range have been used for a transport
single global variable were used to keep track of the last ephemeral protocol instance. However, if a single global variable were used to
port selected, ephemeral port numbers would be trivially predictable. 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, ephemeral port
protocols should avoid using those port numbers as ephemeral ports. selection algorithms avoid using those port numbers.
Port numbers that are currently in use by a TCP in the LISTEN state Port numbers that are currently in use by a TCP in the LISTEN state
should not be allowed for use as ephemeral ports. If this rule is should not be allowed for use as ephemeral ports. If this rule is
not complied, an attacker could potentially "steal" an incoming not complied with, an attacker could potentially "steal" an incoming
connection to a local server application by issuing a connection connection to a local server application by issuing a connection
request to the victim client at roughly the same time the client request to the victim client at roughly the same time the client
tries to connect to the victim server application [CPNI-TCP] tries to connect to the victim server application [CPNI-TCP]
[I-D.gont-tcp-security]. If the SYN segment corresponding to the [I-D.gont-tcp-security]. If the SYN segment corresponding to the
attacker's connection request and the SYN segment corresponding to attacker's connection request and the SYN segment corresponding to
the victim client "cross each other in the network", and provided the the victim client "cross each other in the network", and provided the
attacker is able to know or guess the ephemeral port used by the attacker is able to know or guess the ephemeral port used by the
client, a TCP simultaneous open scenario would take place, and the client, a TCP simultaneous open scenario would take place, and the
incoming connection request sent by the client would be matched with incoming connection request sent by the client would be matched with
the attacker's socket rather than with the victim server the attacker's socket rather than with the victim server
application's socket. application's socket.
It should be noted that most applications based on popular It should be noted that most applications based on popular
implementations of TCP API (such as the Sockets API) perform "passive implementations of the TCP API (such as the Sockets API) perform
opens" in three steps. Firstly, the application obtains a file "passive opens" in three steps. Firstly, the application obtains a
descriptor to be used for inter-process communication (e.g., by file descriptor to be used for inter-process communication (e.g., by
issuing a socket() call). Secondly, the application binds the file issuing a socket() call). Secondly, the application binds the file
descriptor to a local TCP port number (e.g., by issuing a bind() descriptor to a local TCP port number (e.g., by issuing a bind()
call), thus creating a TCP in the fictional CLOSED state. Thirdly, call), thus creating a TCP in the fictional CLOSED state. Thirdly,
the aforementioned TCP is put in the LISTEN state (e.g., by issuing a the aforementioned TCP is put in the LISTEN state (e.g., by issuing a
listen() call). As a result, with such an implementation of the TCP listen() call). As a result, with such an implementation of the TCP
API, even if port numbers in use for TCPs in the LISTEN state were API, even if port numbers in use for TCPs in the LISTEN state were
not allowed for use as ephemeral ports, there is a window of time not allowed for use as ephemeral ports, there is a window of time
between the second and the third steps in which an attacker could be between the second and the third steps in which an attacker could be
allowed to select a port number that would be later used for allowed to select a port number that would be later used for
listening to incoming connections. Therefore, these implementations listening to incoming connections. Therefore, these implementations
of the TCP API should enforce a stricter requirement for the of the TCP API should enforce a stricter requirement for the
allocation of port numbers: port numbers that are in use by a TCP in allocation of port numbers: port numbers that are in use by a TCP in
the LISTEN or CLOSED states should not be allowed for allocation as the LISTEN or CLOSED states should not be allowed for allocation as
ephemeral ports [CPNI-TCP] [I-D.gont-tcp-security]. ephemeral ports [CPNI-TCP] [I-D.gont-tcp-security].
The aforementioned issues do not affect SCTP, since most SCTP
implementations do not allow a socket to be bound to the same port
number unless a specific socket option (SCTP_REUSE_PORT) is issued on
the socket (i.e., this behavior needs to be explititly allowed
beforehand). An example of a typical SCTP socket API can be found in
[I-D.ietf-tsvwg-sctpsocket].
DCCP is not affected is not affected by the exploitation of
"simultaneous opens" to ""steal" incoming connections, as the server
and the client state machines are different [RFC4340]. However, it
may be affected by the vector involving binding a more specific
socket. As a result, those tuples {local IP address, local port,
Service Code} that are in use by a local socket should not be allowed
for allocation as ephemeral ports.
3.2. Ephemeral port number range 3.2. Ephemeral port number range
As mentioned in Section 2.1, the ephemeral port range has As mentioned in Section 2.1, the dynamic ports consist of the range
traditionally consisted of the 49152-65535 range. However, it should 49152-65535. However, ephemeral port selection algorithms should use
also include the range 1024-49151 range. the whole range 1024-49151.
Since this range includes user-specific server ports, this may not Since this range includes ports numbers assigned by IANA, this may
always be possible, though. A possible workaround for this potential not always be possible, though. A possible workaround for this
problem would be to maintain a local list of the port numbers that potential problem would be to maintain a local list of the port
should not be allocated as ephemeral ports. Thus, before allocating numbers that should not be allocated as ephemeral ports. Thus,
a port number, the ephemeral port selection function would check this before allocating a port number, the ephemeral port selection
list, avoiding the allocation of ports that may be needed for function would check this list, avoiding the allocation of ports that
specific applications. may be needed for specific applications.
Transport protocols SHOULD use the largest possible port range, since Ephemeral port selection algorithms SHOULD use the largest possible
this improves the obfuscation provided by the ephemeral port port range, since this improves obfuscation.
selection algorithms.
3.3. Ephemeral Port Obfuscation Algorithms 3.3. Ephemeral Port Obfuscation Algorithms
Transport protocols SHOULD obfuscate the allocatation of their Ephemeral port selection algorithms SHOULD obfuscate the allocation
ephemeral ports, since this help to mitigate a number of attacks that of their ephemeral ports, since this helps to mitigate a number of
depend on the attacker's ability to guess or know the five-tuple that attacks that depend on the attacker's ability to guess or know the
identifies the transport protocol instance to be attacked. five-tuple that identifies the transport protocol instance to be
attacked.
The following subsections describe a number of algorithms that could The following subsections describe a number of algorithms that could
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 */
num_ephemeral = max_ephemeral - min_ephemeral + 1; num_ephemeral = max_ephemeral - min_ephemeral + 1;
next_ephemeral = min_ephemeral + (random() % num_ephemeral); next_ephemeral = min_ephemeral + (random() % num_ephemeral);
count = num_ephemeral; count = num_ephemeral;
do { do {
if(five-tuple is unique) if(resulting 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++;
} }
count--; count--;
} while (count > 0); } while (count > 0);
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'.
Note: "random()" is a function that returns a pseudo-random unsigned
interger number in the range 0-65535 (it may return values larger
than 65535, as is the case with the "random()" C-language function).
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 transport-protocol instances before a port can
be chosen.
Web proxy servers, NAPTs [RFC2663], and other middle-boxes aggregate Web proxy servers, NAPTs [RFC2663], and other middle-boxes aggregate
multiple peers into the same port space and thus increse the multiple peers into the same port space and thus increase the
population of used ephemeral ports, and hence the chances of population of used ephemeral ports, and hence the chances of
collisions of connection-id's. However, [Allman] has shown that at collisions of instance-id's. However, [Allman] has shown that at
least in the network scenarios used for measuring the collision least in the network scenarios used for measuring the collision
properties of the algorithms described in this document, the properties of the algorithms described in this document, the
collision rate resulting from the use of the aforementioned middle- collision rate resulting from the use of the aforementioned middle-
boxes is nevertheless very low. boxes is nevertheless very low.
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,
thus possibly leading to collisions of connection-id's. Even if a thus possibly leading to collisions of instance-id's. Even if a
given five-tuple is verified to be unique by the port selection given five-tuple is verified to be unique by the port selection
algorithm, the five-tuple might still be in use at the remote system. algorithm, the five-tuple might still be in use at the remote system.
In such a scenario, the connection request could possibly fail In such a scenario, a connection request could possibly fail
([Silbersack] describes this problem for the TCP case). ([Silbersack] describes this problem for the TCP case).
This algorithm selects ephemeral port numbers randomly and thus This algorithm selects ephemeral port numbers randomly and thus
reduces the chances of an attacker of guessing the ephemeral port reduces the chances of an attacker of guessing the ephemeral port
selected for a target connection. Additionally, it prevents selected for a target transport-protocol instance. Additionally, it
attackers from obtaining the number of outgoing connections prevents attackers from obtaining the number of outgoing transport-
established by the client in some period of time. protocol instances (e.g., TCP connections) established by the client
in some period of time.
3.3.2. Algorithm 2: Another simple port randomization algorithm 3.3.2. Algorithm 2: Another simple port randomization algorithm
Another algorithm for selecting a random port number is shown in The following pseudo-code illustrates another algorithm for selecting
Figure 3, in which in the event a local connection-id collision is a random port number, in which in the event a local instance-id
detected, another port number is selected randomly, as follows: collision is detected, another port number is selected randomly:
/* Ephemeral port selection function */ /* Ephemeral port selection function */
num_ephemeral = max_ephemeral - min_ephemeral + 1; num_ephemeral = max_ephemeral - min_ephemeral + 1;
next_ephemeral = min_ephemeral + (random() % num_ephemeral); next_ephemeral = min_ephemeral + (random() % num_ephemeral);
count = num_ephemeral; count = num_ephemeral;
do { do {
if(five-tuple is unique) if(resulting five-tuple is unique)
return next_ephemeral; return next_ephemeral;
next_ephemeral = min_ephemeral + (random() % num_ephemeral); next_ephemeral = min_ephemeral + (random() % num_ephemeral);
count--; count--;
} while (count > 0); } while (count > 0);
return ERROR; return ERROR;
Figure 3 Figure 3
skipping to change at page 15, line 6 skipping to change at page 15, line 12
We would like to achieve the port reuse properties of the traditional We would like to achieve the port reuse properties of the traditional
BSD port selection algorithm (described in Section 2.2), while at the BSD port selection algorithm (described in Section 2.2), while at the
same time achieve the obfuscation properties of Algorithm 1 and same time achieve the obfuscation properties of Algorithm 1 and
Algorithm 2. 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 space of the transport-protocol instances on a "per destination
maintain in memory all these 'next_ephemeral' values, we propose an end-point" basis (this "separation of the ephemeral port space" means
offset function F(), that can be computed from the local IP address, that transport-protocol instances with different remote end-points
remote IP address, remote port and a secret key. F() will yield will not have different sequences of port numbers; i.e., wil not be
(practically) different values for each set of arguments, i.e.: part of the same ephemeral port sequence as in the case of the
traditional BSD ephemeral port selection algorithm). Since we do not
want to maintain in memory all these 'next_ephemeral' values, we
propose an offset function F(), that can be computed from the local
IP address, remote IP address, remote port and a secret key. F()
will yield (practically) different values for each set of arguments,
i.e.:
/* Initialization at system boot time. Could be random. */ /* Initialization at system boot time. Could be random. */
next_ephemeral = 0; next_ephemeral = 0;
/* Ephemeral port selection function */ /* Ephemeral port selection function */
num_ephemeral = max_ephemeral - min_ephemeral + 1; 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 = num_ephemeral; count = num_ephemeral;
do { do {
port = min_ephemeral + port = min_ephemeral +
(next_ephemeral + offset) % num_ephemeral; (next_ephemeral + offset) % num_ephemeral;
next_ephemeral++; next_ephemeral++;
if(five-tuple is unique) if(resulting five-tuple is unique)
return port; return port;
count--; 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 destination end-
offset within the global ephemeral port range. Both the 'offset' and point" fixed offset within the global ephemeral port range. Both the
'next_ephemeral' variables may take any value within the storage type 'offset' and 'next_ephemeral' variables may take any value within the
range since we are restricting the resulting port similar to that storage type range since we are restricting the resulting port in a
shown in Figure 3. This allows us to simply increment the similar way as in the Algorithm 1 (described in Section 3.3.1). This
'next_ephemeral' variable and rely on the unsigned integer to simply allows us to simply increment the 'next_ephemeral' variable and rely
wrap-around. on the unsigned integer to simply wrap-around.
The function F() should be a cryptographic hash function like MD5 The function F() should be a cryptographic hash function like MD5
[RFC1321]. The function should use both IP addresses, the remote [RFC1321]. The function should use both IP addresses, the remote
port and a secret key value to compute the offset. The remote IP port and a secret key value to compute the offset. The remote IP
address is the primary separator and must be included in the offset address is the primary separator and must be included in the offset
calculation. The local IP address and remote port may in some cases calculation. The local IP address and remote port may in some cases
be constant and not improve the connection separation, however, they be constant and not improve the ephemeral port space separation,
should also be included in the offset calculation. however, they should also be included in the offset calculation.
Cryptographic algorithms stronger than e.g. MD5 should not be Cryptographic algorithms stronger than e.g. MD5 should not be
necessary, given that Algorithm #3 is simply an obfuscation necessary, given that Algorithm #3 is simply an obfuscation
technique. The secret should be chosen as random as possible, see technique. The secret should be chosen as random as possible, see
[RFC4086] for recommendations on choosing secrets. [RFC4086] for recommendations on choosing secrets.
Note that on multiuser systems, the function F() could include user Note that on multiuser systems, the function F() could include user
specific information, thereby providing protection not only on a host specific information, thereby providing protection not only on a host
to host basis, but on a user to service basis. In fact, any to host basis, but on a user to service basis. In fact, any
identifier of the remote entity could be used, depending on identifier of the remote entity could be used, depending on
skipping to change at page 16, line 40 skipping to change at page 17, line 5
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 discussed, The ability of hostnames to uniquely define hosts can be discussed,
and since SCTP always includes 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 It should be noted that, as this algorithm uses a global counter
("next_ephemeral") for selecting ephemeral ports, if an attacker ("next_ephemeral") for selecting ephemeral ports, if an attacker
could force a client to periodically establish a new TCP connection could e.g., force a client to periodically establish a new TCP
to an attacker controlled machine (or through an attacker observable connections to an attacker controlled machine (or through an attacker
routing path), the attacker could subtract consecutive source port observable routing path), the attacker could subtract consecutive
values to obtain the number of outoing TCP connections established source port values to obtain the number of outgoing TCP connections
globally by the target host within that time period (up to wrap- established globally by the target host within that time period (up
around issues and 5-tuple collisions, of course). to wrap-around issues and 5-tuple collisions, of course).
3.3.4. Algorithm 4: Double-hash obfuscation algorithm 3.3.4. Algorithm 4: Double-hash obfuscation 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 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; num_ephemeral = max_ephemeral - min_ephemeral + 1;
offset = F(local_IP, remote_IP, remote_port, secret_key1); offset = F(local_IP, remote_IP, remote_port, secret_key1);
index = G(local_IP, remote_IP, remote_port, secret_key2); index = G(local_IP, remote_IP, remote_port, secret_key2);
count = num_ephemeral; count = num_ephemeral;
do { do {
port = min_ephemeral + (offset + table[index]) % num_ephemeral; port = min_ephemeral + (offset + table[index]) % num_ephemeral;
table[index]++; table[index]++;
if(five-tuple is unique) if(resulting five-tuple is unique)
return port; return port;
count--; 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 mathematically random values, as 'table[]' could be initialized with mathematically random values, as
indicated by the initialization code in Figure 5. The function G() indicated by the initialization code in pseudo-code above. The
should be a cryptographic hash function like MD5 [RFC1321]. It function G() should be a cryptographic hash function like MD5
should use both IP addresses, the remote port and a secret key value [RFC1321]. It should use both IP addresses, the remote port and a
to compute a value between 0 and (TABLE_LENGTH-1). Alternatively, secret key value to compute a value between 0 and (TABLE_LENGTH-1).
G() could take as "offset" as input, and perform the exclusive-or Alternatively, G() could take as "offset" as input, and perform the
(xor) operation between all the bytes in 'offset'. exclusive-or (xor) operation between all the bytes in 'offset'.
The array 'table[]' assures that succesive connections to the same The array 'table[]' assures that successive transport-protocol
end-point will use increasing ephemeral port numbers. However, instances with the same remote end-point will use increasing
incrementation of the port numbers is separated into TABLE_LENGTH ephemeral port numbers. However, incrementation of the port numbers
different spaces, and thus the port reuse frequency will be is separated into TABLE_LENGTH different spaces, and thus the port
(probabilistically) lower than that of Algorithm 3. That is, a reuse frequency will be (probabilistically) lower than that of
connection established with some remote end-point will not Algorithm 3. That is, a new tranport-protocol instance with some
necessarily cause the 'next_ephemeral' variable corresponding to remote end-point will not necessarily cause the 'next_ephemeral'
other end-points to be incremented. variable corresponding to 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 port sequence *increments* into TABLE_LENGTH different spaces. The port sequence
will result from adding the corresponding entry of 'table[]' to the will result from adding the corresponding entry of 'table[]' to the
variable 'offset', which selects the actual port sequence (as in variable 'offset', which selects the actual port sequence (as in
Algorithm 3). [Allman] has found that a TABLE_LENGTH of 10 can Algorithm 3). [Allman] has found that a TABLE_LENGTH of 10 can
result in an improvement over Algorithm 3. Further increasing the result in an improvement over Algorithm 3. Further increasing the
TABLE_LENGTH will increase the obfuscation, and possibly further TABLE_LENGTH will increase the obfuscation, and possibly further
decrease the collision rate. decrease the collision rate.
An attacker can perform traffic analysis for any "increment space" An attacker can perform traffic analysis for any "increment space"
into which the attacker has "visibility", namely that the attacker into which the attacker has "visibility", namely that the attacker
can force the client to establish a transport-protocol connection can force the client to establish a transport-protocol instance whose
whose G(offset) identifies the target "increment space". However, G(offset) identifies the target "increment space". However, the
the attacker's ability to perform traffic analysis is very reduced attacker's ability to perform traffic analysis is very reduced when
when compared to the traditional BSD algorithm (described in compared to the traditional BSD algorithm (described in Section 2.2)
Section 2.2) and Algorithm 3. Additionally, an implementation can and Algorithm 3. Additionally, an implementation can further limit
further limit the attacker's ability to perform traffic analysis by the attacker's ability to perform traffic analysis by further
further separating the increment space (that is, using a larger value separating the increment space (that is, using a larger value for
for TABLE_LENGTH). TABLE_LENGTH).
3.3.5. Algorithm 5: Random-increments port selection algorithm 3.3.5. Algorithm 5: Random-increments port selection algorithm
[Allman] introduced another port obfuscation algorithm, which offers [Allman] introduced another port obfuscation algorithm, which offers
a middle ground between the algorithms that select ephemeral ports a middle ground between the algorithms that select ephemeral ports
randomly (such as those described in Section 3.3.1 and randomly (such as those described in Section 3.3.1 and
Section 3.3.2), and those that offer obfuscation but no randomization Section 3.3.2), and those that offer obfuscation but no randomization
(such as those described in Section 3.3.3 and Section 3.3.4). We (such as those described in Section 3.3.3 and Section 3.3.4). We
will refer to this algorithm as 'Algorithm 5'. will refer to this algorithm as 'Algorithm 5'.
skipping to change at page 19, line 18 skipping to change at page 19, line 18
/* Ephemeral port selection function */ /* Ephemeral port selection function */
num_ephemeral = max_ephemeral - min_ephemeral + 1; num_ephemeral = max_ephemeral - min_ephemeral + 1;
count = num_ephemeral; count = num_ephemeral;
do { do {
next_ephemeral = next_ephemeral + (random() % N) + 1; next_ephemeral = next_ephemeral + (random() % N) + 1;
port = min_ephemeral + (next_ephemeral % num_ephemeral); port = min_ephemeral + (next_ephemeral % num_ephemeral);
if(five-tuple is unique) if(resulting five-tuple is unique)
return port; return port;
count--; count--;
} while (count > 0); } while (count > 0);
return ERROR; return ERROR;
Figure 6 Figure 6
This algorithm aims at at producing a monotonically-increasing This algorithm aims at at producing a monotonically-increasing
sequence to prevent the collision of connection-id's, while avoiding sequence to prevent the collision of instance-id's, while avoiding
the use of fixed increments, which would lead to trivially- the use of fixed increments, which would lead to trivially-
predictable sequences. The value "N" allows for direct control of predictable sequences. The value "N" allows for direct control of
the tradeoff between the level of obfuscation and the port reuse the tradeoff between the level of obfuscation and the port reuse
frequency. The smaller the value of "N", the more linear the more frequency. The smaller the value of "N", the more linear the more
similar this algorithm is to the traditioanl BSD port selection similar this algorithm is to the traditional BSD port selection
algorithm (described in Section 2.2. The larger the value of "N", algorithm (described in Section 2.2. The larger the value of "N",
the more similar this algorithm is to the algorithm described in the more similar this algorithm is to the algorithm described in
Section 3.3.1 of this document. Section 3.3.1 of this document.
When the port numbers wrap, there's the risk of collisions of When the port numbers wrap, there is the risk of collisions of
connection-id's. Therefore, "N" should be selecting according to the instance-id's. Therefore, "N" should be selecting according to the
following criteria: following criteria:
o It should maximize the wrapping time of the ephemeral port space o It should maximize the wrapping time of the ephemeral port space
o It should minimize collisions of connection-id's o It should minimize collisions of instance-id's
o It should maximize obfuscation o It should maximize obfuscation
Clearly, these are competing goals, and the decision of which value Clearly, these are competing goals, and the decision of which value
of "N" to use is a tradeoff. Therefore, the value of "N" should be of "N" to use is a tradeoff. Therefore, the value of "N" should be
configurable so that system administrators can make the tradeoff for configurable so that system administrators can make the tradeoff for
themselves. themselves.
3.4. Secret-key considerations for hash-based port obfuscation 3.4. Secret-key considerations for hash-based port obfuscation
algorithms algorithms
skipping to change at page 20, line 30 skipping to change at page 20, line 30
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. That is, upon changing ports, and consequently collisions may occur. That is, upon changing
the secret, the "offset" value (see Figure 4 and Figure 5) used for the secret, the "offset" value (see Section 3.3.3 and Section 3.3.4)
each destination end-point will be different from that computed with used for each destination end-point will be different from that
the previous secret, ths leading to the selection of a port number computed with the previous secret, thus leading to the selection of a
recently used for connecting to the same end-point. port number recently used for connecting to the same end-point.
Thus the change in secret key should be done with consideration and Thus the change in secret key should be done with consideration and
could be performed whenever one of the following events occur: could be performed whenever one of the following events occur:
o The system is being bootstrapped. o The system is being bootstrapped.
o Some predefined/random time has expired. o Some predefined/random time has expired.
o The secret has been used N times (i.e. we consider it insecure). o The secret has been used N times (i.e. we consider it insecure).
o There are few active connections (i.e., possibility of collision o There are few active transport protocol instances (i.e.,
is low). possibility of collision 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.5. Choosing an ephemeral port obfuscation algorithm 3.5. Choosing an ephemeral port obfuscation algorithm
[Allman] is an empyrical study of the properties of the algorithms [Allman] is an empirical study of the properties of the algorithms
described in this document, which has found that all the algorithms described in this document, which has found that all the algorithms
described in this document offer low collision rates -- at most 0.3%. described in this document offer low collision rates -- at most 0.3%.
That is, in those network scenarios asessed by [Allman] all of the That is, in those network scenarios assessed by [Allman] all of the
algorithms described in this document perform good in terms of algorithms described in this document perform well in terms of
collisions of connection-id's. However, these results may vary collisions of instance-id's. However, these results may vary
depending on the characteristics of network traffic and the specific depending on the characteristics of network traffic and the specific
network setup. network setup.
The algorithm sketched in Figure 1 is the traditional ephemeral port The algorithm described in Section 2.2 is the traditional ephemeral
selection algorithm implemented in BSD-derived systems. It generates port selection algorithm implemented in BSD-derived systems. It
a global sequence of ephemeral port numbers, which makes it trivial generates a global sequence of ephemeral port numbers, which makes it
for an attacker to predict the port number that will be used for a trivial for an attacker to predict the port number that will be used
future transport protocol instance. However, it is very simple, and for a future transport protocol instance. However, it is very
leads to a low port resuse frequency. simple, and leads to a low port reuse frequency.
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 actual randomization of the ephemeral ports. However, they may
port number collisions, which could lead to the failure of the increase the chances of port number collisions, which could lead to
connection establishment attempt. [Allman] found that these two the failure of a connection establishment attempt. [Allman] found
algorithms show the largest collision rates (among all the algorithms that these two algorithms show the largest collision rates (among all
described in this document). the algorithms described in this document).
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 3.4). However, implementations should dimensions (see Section 3.4). 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[]'.
Algorithm 5 offers middle ground between the simple randomization Algorithm 5 offers middle ground between the simple randomization
algorithms (Algorithm 1 and Algorthm 2) and the hash-based algorithms algorithms (Algorithm 1 and Algorithm 2) and the hash-based
(Algorithm 3 and Algorithm 4). The upper limit on the random algorithms (Algorithm 3 and Algorithm 4). The upper limit on the
increments (the value "N" in Figure 6 controls the trade-off between random increments (the value "N" in the pseudo-code included in
randomization and port-reuse frequency. Section 3.3.5 controls the trade-off between randomization and port-
reuse frequency.
Finally, a special case that may preclude the utilization of Finally, a special case that may preclude the utilization of
Algorithm 3 and Algorithm 4 should be analyzed. There exist some Algorithm 3 and Algorithm 4 should be analyzed. There exist some
applications 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 7 Figure 7
In some BSD-derived systems, the call to bind() will result in the In some BSD-derived systems, the call to bind() will result in the
selection of an ephemeral port number. However, as neither the selection of an ephemeral port number. However, as neither the
remote IP address nor the remote port will be available to the remote IP address nor the remote port will be available to the
ephemeral port selection function, the hash function F() used in ephemeral port selection function, the hash function F() used in
Algorithm 3 and Algorithm 4 will not have all the required arguments, Algorithm 3 and Algorithm 4 will not have all the required arguments,
and thus the result of the hash function will be impossible to and thus the result of the hash function will be impossible to
compute. Transport protocols implementating Algorithm 3 or Algorithm compute. Transport protocols implementing Algorithm 3 or Algorithm 4
4 should consider using Algorithm 2 when facing the scenario just should consider using Algorithm 2 when facing the scenario just
described. described.
An alternative to this behavior would be to implement "lazy binding" An alternative to this behavior would be to implement "lazy binding"
in response to the bind() call. That is, selection of an epphemeral in response to the bind() call. That is, selection of an ephemeral
port would be delayed until, e.g., connect() or send() are called. port would be delayed until, e.g., connect() or send() are called.
Thus, at that point the ephemeral port is actually selected, all the Thus, at that point the ephemeral port is actually selected, all the
necessary arguments for the hash function F() would be available, and necessary arguments for the hash function F() would be available, and
thus Algorithm 3 and Algorithm 4 could still be used in this thus Algorithm 3 and Algorithm 4 could still be used in this
scenario. This policy has been implemented by Linux [Linux]. scenario. This algorithm has been implemented by Linux [Linux].
4. Port obfuscation and Network Address Port Translation (NAPT) 4. Port obfuscation and Network Address Port Translation (NAPT)
Network Address Port Translation (NAPT) translate both the network Network Address Port Translation (NAPT) translate both the network
address and transport-protocol port number, thus allowing the address and transport-protocol port number, thus allowing the
transport identifiers of a number of private hosts to be multiplexed transport identifiers of a number of private hosts to be multiplexed
into the transport identifiers of a single external address. into the transport identifiers of a single external address.
[RFC2663] [RFC2663]
In those scenarios in which a NAPT is present between the two end- In those scenarios in which a NAPT is present between the two end-
points of transport-protocol connection, the obfuscation of the points of transport-protocol instance, the obfuscation of the
ephemeral ports (from the point of view of the external network) will ephemeral ports (from the point of view of the external network) will
depend on the ephemeral port selection function at the NAPT. depend on the ephemeral port selection function at the NAPT.
Therefore, NAPTs should consider obfuscating the ephemeral ports by Therefore, NAPTs should consider obfuscating the ephemeral ports by
means of any of the algorithms discussed in this document. It should means of any of the algorithms discussed in this document. It should
be noted that in some network scenarios, a NAPT may naturally obscure be noted that in some network scenarios, a NAPT may naturally obscure
ephemeral port selections simply due to the vast range of services ephemeral port selections simply due to the vast range of services
with which it establishes connections and to the overall rate of the with which it establishes connections and to the overall rate of the
traffic [Allman]. traffic [Allman].
Section 3.5 provides guidance in choosing a port obfuscation Section 3.5 provides guidance in choosing a port obfuscation
algorithm. algorithm.
5. Security Considerations 5. Security Considerations
Obfuscating ephemeral ports is no replacement for cryptographic Obfuscating ephemeral ports is no replacement for cryptographic
mechanisms, such as IPsec [RFC4301], in terms of protecting transport mechanisms, such as IPsec [RFC4301], in terms of protecting
protocol instances against blind attacks. transport-protocol 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 transport-protocol instance to be attacked could learn the IP
numbers in use (and also sequence numbers etc.) and easily attack the addresses and port numbers in use (and also sequence numbers etc.)
connection. Ephemeral port obfuscation does not provide any and easily perform an attack. Ephemeral port obfuscation does not
additional protection against this kind of attacks. In such provide any additional protection against this kind of attacks. In
situations, proper authentication mechanisms such as those described such situations, proper authentication mechanisms such as those
in [RFC4301] should be used. described in [RFC4301] should be used.
If the local offset function F() results in identical offsets for If the local offset function F() results in identical offsets for
different inputs, the port-offset mechanism proposed in this document different inputs, the port-offset mechanism proposed in this document
has no or reduced effect. has no or reduced effect.
If random numbers are used as the only source of the secret key, they If random numbers are used as the only source of the secret key, they
must be chosen in accordance with the recommendations given in must be chosen in accordance with the recommendations given in
[RFC4086]. [RFC4086].
If an attacker uses dynamically assigned IP addresses, the current If an attacker uses dynamically assigned IP addresses, the current
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 transport-
connection), both the attacker and the new peer need to act as protocol communication), both the attacker and the new peer need to
servers in the scenario just described. While servers using dynamic act as servers in the scenario just described. While servers using
IP addresses exist, they are not very common and with an appropriate dynamic IP addresses exist, they are not very common and with an
re-keying mechanism the effect of this attack is limited. appropriate re-keying mechanism the effect of this attack is limited.
6. IANA Considerations 6. IANA Considerations
There are no IANA registries within this document. The RFC-Editor There are no IANA registries within this document. The RFC-Editor
can remove this section before publication of this document as an can remove this section before publication of this document as an
RFC. RFC.
7. Acknowledgements 7. 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,
Matthias Bethke, Stephane Bortzmeyer, Brian Carpenter, Vincent Matthias Bethke, Stephane Bortzmeyer, Brian Carpenter, Vincent
Deffontaines, Lars Eggert, Gorry Fairhurst, Guillermo Gont, Alfred Deffontaines, Lars Eggert, Gorry Fairhurst, Guillermo Gont, Alfred
Hoenes, Amit Klein, Carlos Pignataro, Kacheong Poon, Joe Touch, and Hoenes, Amit Klein, Carlos Pignataro, Kacheong Poon, Pasi Sarolahti,
Dan Wing for their valuable feedback on earlier versions of this Randall Stewart, Joe Touch, Michael Tuexen, and Dan Wing for their
document. 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.
Fernando Gont would like to thank Carolina Suarez for her love and Fernando Gont would like to thank Carolina Suarez for her love and
support. support.
8. References 8. References
8.1. Normative References 8.1. Normative References
skipping to change at page 27, line 28 skipping to change at page 27, line 28
[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.
[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.
[RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute
in Session Description Protocol (SDP)", RFC 3605,
October 2003.
[RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and [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
Requirements for Security", BCP 106, RFC 4086, June 2005. Requirements for Security", BCP 106, RFC 4086, June 2005.
[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.
skipping to change at page 28, line 4 skipping to change at page 28, line 8
8.2. Informative References 8.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-06 (work in progress), draft-ietf-tcpm-icmp-attacks-10 (work in progress),
August 2009. January 2010.
[RFC1337] Braden, B., "TIME-WAIT Assassination Hazards in TCP", [RFC1337] Braden, B., "TIME-WAIT Assassination Hazards in TCP",
RFC 1337, May 1992. RFC 1337, May 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.
[RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address
Translator (NAT) Terminology and Considerations", Translator (NAT) Terminology and Considerations",
RFC 2663, August 1999. RFC 2663, August 1999.
[RFC4953] Touch, J., "Defending TCP Against Spoofing Attacks", [RFC4953] Touch, J., "Defending TCP Against Spoofing Attacks",
RFC 4953, July 2007. RFC 4953, July 2007.
[I-D.ietf-tsvwg-sctpsocket]
Stewart, R., Poon, K., Tuexen, M., Yasevich, V., and P.
Lei, "Sockets API Extensions for Stream Control
Transmission Protocol (SCTP)",
draft-ietf-tsvwg-sctpsocket-21 (work in progress),
February 2010.
[Allman] Allman, M., "Comments On Selecting Ephemeral Ports", ACM [Allman] Allman, M., "Comments On Selecting Ephemeral Ports", ACM
Computer Communicatiion Review, 39(2), 2009. Computer Communication Review, 39(2), 2009.
[CPNI-TCP] [CPNI-TCP]
Gont, F., "CPNI Technical Note 3/2009: Security Assessment Gont, F., "CPNI Technical Note 3/2009: Security Assessment
of the Transmission Control Protocol (TCP)", UK Centre of the Transmission Control Protocol (TCP)", UK Centre
for the Protection of National Infrastructure, 2009. for the Protection of National Infrastructure, 2009.
[I-D.gont-tcp-security] [I-D.gont-tcp-security]
Gont, F., "Security Assessment of the Transmission Control Gont, F., "Security Assessment of the Transmission Control
Protocol (TCP)", draft-gont-tcp-security-00 (work in Protocol (TCP)", draft-gont-tcp-security-00 (work in
progress), February 2009. progress), February 2009.
skipping to change at page 29, line 4 skipping to change at page 29, line 15
[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 . 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-08 Authentication Option", draft-ietf-tcpm-tcp-auth-opt-10
(work in progress), October 2009. (work in progress), January 2010.
[Watson] Watson, P., "Slipping in the Window: TCP Reset Attacks", [Watson] Watson, P., "Slipping in the Window: TCP Reset Attacks",
CanSecWest 2004 Conference . 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 1, and in response to this document now FreeBSD 8.0 implements Algorithm 1, and in response to this document
uses a 'min_port' of 10000 and a 'max_port' of 65535. [FreeBSD] now uses a 'min_port' of 10000 and a 'max_port' of 65535. [FreeBSD]
A.2. Linux A.2. Linux
Linux implements Algorithm 3. If the algorithm is faced with the Linux 2.6.15-53-386 implements Algorithm 3. If the algorithm is
corner-case scenario described in Section 3.5, Algorithm 1 is used faced with the corner-case scenario described in Section 3.5,
instead [Linux]. Algorithm 1 is used instead [Linux].
A.3. NetBSD A.3. NetBSD
NetBSD does not obfuscate its ephemeral port numbers. It selects NetBSD 5.0.1 does not obfuscate its ephemeral port numbers. It
ephemeral port numbers from the range 49152-65535, starting from port selects ephemeral port numbers from the range 49152-65535, starting
65535, and decreasing the port number for each ephemeral port number from port 65535, and decreasing the port number for each ephemeral
selected [NetBSD]. port number selected [NetBSD].
A.4. OpenBSD A.4. OpenBSD
OpenBSD implements Algorithm 1, with a 'min_port' of 1024 and a OpenBSD 4.2 implements Algorithm 1, with a 'min_port' of 1024 and a
'max_port' of 49151. [OpenBSD] 'max_port' of 49151. [OpenBSD]
A.5. OpenSolaris A.5. OpenSolaris
OpenSolaris implements Algorithm 1, with a 'min_port' of 32768 and a OpenSolaris 2009.06 implements Algorithm 1, with a 'min_port' of
'max_port' of 65535. [OpenSolaris] 32768 and a 'max_port' of 65535. [OpenSolaris]
Appendix B. Changes from previous versions of the draft (to be removed Appendix B. Changes from previous versions of the draft (to be removed
by the RFC Editor before publication of this document as a by the RFC Editor before publication of this document as a
RFC RFC
B.1. Changes from draft-ietf-tsvwg-port-randomization-04 B.1. Changes from draft-ietf-tsvwg-port-randomization-05
o Addresses AD review feedback from Lars Eggert.
B.2. Changes from draft-ietf-tsvwg-port-randomization-04
o Fixes nits. o Fixes nits.
B.2. Changes from draft-ietf-tsvwg-port-randomization-03 B.3. Changes from draft-ietf-tsvwg-port-randomization-03
o Addresses WGLC comments from Mark Allman. See: o Addresses WGLC comments from Mark Allman. See:
http://www.ietf.org/mail-archive/web/tsvwg/current/msg09149.html http://www.ietf.org/mail-archive/web/tsvwg/current/msg09149.html
B.3. Changes from draft-ietf-tsvwg-port-randomization-02 B.4. Changes from draft-ietf-tsvwg-port-randomization-02
o Added clarification of what we mean by "port randomization". o Added clarification of what we mean by "port randomization".
o Addresses feedback sent on-list and off-list by Mark Allman. o Addresses feedback sent on-list and off-list by Mark Allman.
o Added references to [Allman] and [CPNI-TCP]. o Added references to [Allman] and [CPNI-TCP].
B.4. Changes from draft-ietf-tsvwg-port-randomization-01 B.5. Changes from draft-ietf-tsvwg-port-randomization-01
o Added Section 2.3. o Added Section 2.3.
o Added discussion of "lazy binding in Section 3.5. o Added discussion of "lazy binding in Section 3.5.
o Added discussion of obtaining the number of outgoing connections. o Added discussion of obtaining the number of outgoing connections.
o Miscellaneous editorial changes o Miscellaneous editorial changes
B.5. Changes from draft-ietf-tsvwg-port-randomization-00 B.6. Changes from draft-ietf-tsvwg-port-randomization-00
o Added Section 3.1. o Added Section 3.1.
o Changed Intended Status from "Standards Track" to "BCP". o Changed Intended Status from "Standards Track" to "BCP".
o Miscellaneous editorial changes. o Miscellaneous editorial changes.
B.6. Changes from draft-larsen-tsvwg-port-randomization-02 B.7. 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.7. Changes from draft-larsen-tsvwg-port-randomization-01 B.8. Changes from draft-larsen-tsvwg-port-randomization-01
o No changes. Draft resubmitted after expiration. o No changes. Draft resubmitted after expiration.
B.8. Changes from draft-larsen-tsvwg-port-randomization-00 B.9. 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 reorganized
o Miscellaneous editorial changes o Miscellaneous editorial changes
B.9. Changes from draft-larsen-tsvwg-port-randomisation-00 B.10. 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
 End of changes. 102 change blocks. 
275 lines changed or deleted 345 lines changed or added

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