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

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