draft-ietf-tsvwg-port-randomization-08.txt   draft-ietf-tsvwg-port-randomization-09.txt 
Transport Area Working Group M. Larsen Transport Area Working Group M. Larsen
(tsvwg) TietoEnator (tsvwg) TietoEnator
Internet-Draft F. Gont Internet-Draft F. Gont
Intended status: BCP UTN/FRH Intended status: BCP UTN/FRH
Expires: December 2, 2010 May 31, 2010 Expires: February 16, 2011 August 15, 2010
Transport Protocol Port Randomization Recommendations Transport Protocol Port Randomization Recommendations
draft-ietf-tsvwg-port-randomization-08 draft-ietf-tsvwg-port-randomization-09
Abstract Abstract
During the las few years, awareness has been raised about a number of During the last few years, awareness has been raised about a number
"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 described
skipping to change at page 2, line 4 skipping to change at page 2, line 4
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 2, 2010. 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) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 17 skipping to change at page 3, line 17
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Ephemeral Ports . . . . . . . . . . . . . . . . . . . . . . . 7 2. Ephemeral Ports . . . . . . . . . . . . . . . . . . . . . . . 7
2.1. Traditional Ephemeral Port Range . . . . . . . . . . . . . 7 2.1. Traditional Ephemeral Port Range . . . . . . . . . . . . . 7
2.2. Ephemeral port selection . . . . . . . . . . . . . . . . . 7 2.2. Ephemeral port selection . . . . . . . . . . . . . . . . . 7
2.3. Collision of instance-id's . . . . . . . . . . . . . . . . 9 2.3. Collision of instance-id's . . . . . . . . . . . . . . . . 9
3. Obfuscating the Ephemeral Ports . . . . . . . . . . . . . . . 10 3. Obfuscating the Ephemeral Ports . . . . . . . . . . . . . . . 10
3.1. Characteristics of a good ephemeral port obfuscation 3.1. Characteristics of a good ephemeral port obfuscation
algorithm . . . . . . . . . . . . . . . . . . . . . . . . 10 algorithm . . . . . . . . . . . . . . . . . . . . . . . . 10
3.2. Ephemeral port number range . . . . . . . . . . . . . . . 12 3.2. Ephemeral port number range . . . . . . . . . . . . . . . 12
3.3. Ephemeral Port Obfuscation Algorithms . . . . . . . . . . 12 3.3. Ephemeral Port Obfuscation Algorithms . . . . . . . . . . 12
3.3.1. Algorithm 1: Simple port randomization algorithm . . . 12 3.3.1. Algorithm 1: Simple port randomization algorithm . . . 13
3.3.2. Algorithm 2: Another simple port randomization 3.3.2. Algorithm 2: Another simple port randomization
algorithm . . . . . . . . . . . . . . . . . . . . . . 14 algorithm . . . . . . . . . . . . . . . . . . . . . . 15
3.3.3. Algorithm 3: Simple hash-based algorithm . . . . . . . 15 3.3.3. Algorithm 3: Simple hash-based algorithm . . . . . . . 15
3.3.4. Algorithm 4: Double-hash obfuscation algorithm . . . . 17 3.3.4. Algorithm 4: Double-hash obfuscation algorithm . . . . 18
3.3.5. Algorithm 5: Random-increments port selection 3.3.5. Algorithm 5: Random-increments port selection
algorithm . . . . . . . . . . . . . . . . . . . . . . 19 algorithm . . . . . . . . . . . . . . . . . . . . . . 19
3.4. Secret-key considerations for hash-based port 3.4. Secret-key considerations for hash-based port
obfuscation algorithms . . . . . . . . . . . . . . . . . . 21 obfuscation algorithms . . . . . . . . . . . . . . . . . . 21
3.5. Choosing an ephemeral port obfuscation algorithm . . . . . 22 3.5. Choosing an ephemeral port obfuscation algorithm . . . . . 22
4. Port obfuscation and Network Address Port Translation 4. Port obfuscation and Network Address Port Translation
(NAPT) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 (NAPT) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
5. Security Considerations . . . . . . . . . . . . . . . . . . . 25 5. Security Considerations . . . . . . . . . . . . . . . . . . . 26
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
8.1. Normative References . . . . . . . . . . . . . . . . . . . 28 8.1. Normative References . . . . . . . . . . . . . . . . . . . 29
8.2. Informative References . . . . . . . . . . . . . . . . . . 28 8.2. Informative References . . . . . . . . . . . . . . . . . . 30
Appendix A. Survey of the algorithms in use by some popular Appendix A. Survey of the algorithms in use by some popular
implementations . . . . . . . . . . . . . . . . . . . 31 implementations . . . . . . . . . . . . . . . . . . . 32
A.1. FreeBSD . . . . . . . . . . . . . . . . . . . . . . . . . 31 A.1. FreeBSD . . . . . . . . . . . . . . . . . . . . . . . . . 32
A.2. Linux . . . . . . . . . . . . . . . . . . . . . . . . . . 31 A.2. Linux . . . . . . . . . . . . . . . . . . . . . . . . . . 32
A.3. NetBSD . . . . . . . . . . . . . . . . . . . . . . . . . . 31 A.3. NetBSD . . . . . . . . . . . . . . . . . . . . . . . . . . 32
A.4. OpenBSD . . . . . . . . . . . . . . . . . . . . . . . . . 31 A.4. OpenBSD . . . . . . . . . . . . . . . . . . . . . . . . . 32
A.5. OpenSolaris . . . . . . . . . . . . . . . . . . . . . . . 31 A.5. OpenSolaris . . . . . . . . . . . . . . . . . . . . . . . 32
Appendix B. Changes from previous versions of the draft (to Appendix B. Changes from previous versions of the draft (to
be removed by the RFC Editor before publication be removed by the RFC Editor before publication
of this document as a RFC . . . . . . . . . . . . . . 32 of this document as a RFC . . . . . . . . . . . . . . 33
B.1. Changes from draft-ietf-tsvwg-port-randomization-07 . . . 32 B.1. Changes from draft-ietf-tsvwg-port-randomization-08 . . . 33
B.2. Changes from draft-ietf-tsvwg-port-randomization-06 . . . 32 B.2. Changes from draft-ietf-tsvwg-port-randomization-07 . . . 33
B.3. Changes from draft-ietf-tsvwg-port-randomization-05 . . . 32 B.3. Changes from draft-ietf-tsvwg-port-randomization-06 . . . 33
B.4. Changes from draft-ietf-tsvwg-port-randomization-04 . . . 32 B.4. Changes from draft-ietf-tsvwg-port-randomization-05 . . . 33
B.5. Changes from draft-ietf-tsvwg-port-randomization-03 . . . 32 B.5. Changes from draft-ietf-tsvwg-port-randomization-04 . . . 33
B.6. Changes from draft-ietf-tsvwg-port-randomization-02 . . . 32 B.6. Changes from draft-ietf-tsvwg-port-randomization-03 . . . 33
B.7. Changes from draft-ietf-tsvwg-port-randomization-01 . . . 32 B.7. Changes from draft-ietf-tsvwg-port-randomization-02 . . . 33
B.8. Changes from draft-ietf-tsvwg-port-randomization-00 . . . 33 B.8. Changes from draft-ietf-tsvwg-port-randomization-01 . . . 34
B.9. Changes from draft-larsen-tsvwg-port-randomization-02 . . 33 B.9. Changes from draft-ietf-tsvwg-port-randomization-00 . . . 34
B.10. Changes from draft-larsen-tsvwg-port-randomization-01 . . 33 B.10. Changes from draft-larsen-tsvwg-port-randomization-02 . . 34
B.11. Changes from draft-larsen-tsvwg-port-randomization-00 . . 33 B.11. Changes from draft-larsen-tsvwg-port-randomization-01 . . 34
B.12. Changes from draft-larsen-tsvwg-port-randomisation-00 . . 33 B.12. Changes from draft-larsen-tsvwg-port-randomization-00 . . 34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35 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 [I-D.ietf-tcpm-icmp-attacks] [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
skipping to change at page 5, line 38 skipping to change at page 5, line 38
While the server IP address and well-known port and the client IP While the server IP address and well-known port and the client IP
address may be 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 option [RFC2385], or the TCP Authentication Option [RFC5925]. For
[I-D.ietf-tcpm-tcp-auth-opt]. For example, they do not provide any example, they do not provide any mitigation in those scenarios in
mitigation in those scenarios in which the attacker is able to sniff which the attacker is able to sniff the packets that correspond to
the packets that correspond to the transport protocol instance to be the transport protocol instance to be attacked. However, the
attacked. However, the proposed algorithms provide improved proposed algorithms provide improved obfuscation with very little
obfuscation with very little effort and without any key management effort and without any key management overhead.
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
skipping to change at page 9, line 15 skipping to change at page 9, line 15
attacker observable routing path), the attacker could subtract attacker observable routing path), the attacker could subtract
consecutive source port values to obtain the number of outgoing TCP consecutive source port values to obtain the number of outgoing TCP
connections established globally by the target host within that time connections established globally by the target host within that time
period (up to wrap-around issues and instance-id collisions, of period (up to wrap-around issues and instance-id collisions, of
course). course).
2.3. Collision of instance-id's 2.3. Collision of instance-id's
While it is possible for the ephemeral port selection algorithm to While it is possible for the ephemeral port selection algorithm to
verify that the selected port number results in 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 instance-id 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
TIME-WAIT state at the web server for 2*MSL (Maximum Segment TIME-WAIT state at the web server for 2*MSL (Maximum Segment
Lifetime). If the same client tried to create a new incarnation of Lifetime). If the same client tried to create a new incarnation of
the previous connection (that is, a connection with the same the previous connection (that is, a connection with the same
instance-id as the one in the TIME_WAIT state at the server), an instance-id as the one in the TIME_WAIT state at the server), an
skipping to change at page 11, line 19 skipping to change at page 11, line 19
If such an application was run while the corresponding port number If such an application was run while the corresponding port number
was in use, the application would fail. Therefore, ephemeral port was 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] [I-D.gont-tcp-security]. If the victim server application [CPNI-TCP]
the SYN segment corresponding to the attacker's connection request [I-D.ietf-tcpm-tcp-security]. If the SYN segment corresponding to
and the SYN segment corresponding to the victim client "cross each the attacker's connection request and the SYN segment corresponding
other in the network", and provided the attacker is able to know or to the victim client "cross each other in the network", and provided
guess the ephemeral port used by the client, a TCP simultaneous open the attacker is able to know or guess the ephemeral port used by the
scenario would take place, and the incoming connection request sent client, a TCP simultaneous open scenario would take place, and the
by the client would be matched with the attacker's socket rather than incoming connection request sent by the client would be matched with
with the victim server application's socket. Secondly, an attacker the attacker's socket rather than with the victim server
could specify a more specific socket than the "victim" socket (e.g., application's socket. Secondly, an attacker could specify a more
specify both the local IP address and the local TCP port), and thus specific socket than the "victim" socket (e.g., specify both the
incoming SYN segments matching the attacker's socket would be local IP address and the local TCP port), and thus incoming SYN
delivered to the attacker, rather than to the "victim" socket (see segments matching the attacker's socket would be delivered to the
Section 10.1 of [CPNI-TCP]). attacker, rather than to the "victim" socket (see Section 10.1 of
[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.gont-tcp-security]. ephemeral ports [CPNI-TCP] [I-D.ietf-tcpm-tcp-security].
The aforementioned issue do not affect SCTP, since most SCTP The aforementioned issue do 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 explititly 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]. [I-D.ietf-tsvwg-sctpsocket].
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.
Since this range includes ports numbers assigned by IANA, this may This range includes the IANA Registered Ports, and thus some of these
not always be possible, though. A possible workaround for this port numbers may be needed for providing a particular service at the
potential problem would be to maintain a local list of the port local host, which could result in the problems discussed in
numbers that should not be allocated as ephemeral ports. Thus, Section 3.1. As result, port numbers that may be needed for
before allocating a port number, the ephemeral port selection providing a particular service at the local host SHOULD NOT be
function would check this list, avoiding the allocation of ports that included in the pool of port numbers available for ephemeral port
may be needed for specific applications. randomization. If the host does not provide a particular service,
the port can be safely allocated to ordinary processes.
A possible workaround for this potential problem would be to maintain
a local list of the port numbers that should not be allocated as
ephemeral ports. Thus, before allocating a port number, the
ephemeral port selection function would check this list, avoiding the
allocation of ports that may be needed for specific applications.
Rather than naively excluding all the registered ports,
administrators should identify services that may be offered by the
local host and SHOULD exclude only the corresponding registered
ports.
Ephemeral port selection algorithms SHOULD use the largest possible Ephemeral port selection algorithms SHOULD use the largest possible
port range, since this improves obfuscation. port range, since this improves obfuscation.
3.3. Ephemeral Port Obfuscation Algorithms 3.3. Ephemeral Port Obfuscation Algorithms
Ephemeral port selection algorithms SHOULD obfuscate the allocation Ephemeral port selection algorithms SHOULD obfuscate the allocation
of their ephemeral ports, since this helps to mitigate a number of 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
skipping to change at page 14, line 8 skipping to change at page 14, line 20
Web proxy servers, NAPTs [RFC2663], and other middle-boxes aggregate Web proxy servers, NAPTs [RFC2663], and other middle-boxes aggregate
multiple peers into the same port space and thus increase the multiple peers into the same port space and thus increase the
population of used ephemeral ports, and hence the chances of population of used ephemeral ports, and hence the chances of
collisions of instance-id's. However, [Allman] has shown that at collisions of instance-id's. However, [Allman] has shown that at
least in the network scenarios used for measuring the collision least in the network scenarios used for measuring the collision
properties of the algorithms described in this document, the properties of the algorithms described in this document, the
collision rate resulting from the use of the aforementioned middle- collision rate resulting from the use of the aforementioned middle-
boxes is nevertheless very low. boxes is nevertheless very low.
Since this algorithm performs a completely random port selection Since this algorithm performs port selection without taking into
(i.e., without taking into account the port numbers previously account the port numbers previously chosen, it has the potential of
chosen), it has the potential of reusing port numbers too quickly, reusing port numbers too quickly, thus possibly leading to collisions
thus possibly leading to collisions of instance-id's. Even if a of instance-id's. Even if a given instance-id is verified to be
given five-tuple is verified to be unique by the port selection unique by the port selection algorithm, the instance-id might still
algorithm, the five-tuple might still be in use at the remote system. be in use at the remote system. In such a scenario, a connection
In such a scenario, a connection request could possibly fail request could possibly fail ([Silbersack] describes this problem for
([Silbersack] describes this problem for the TCP case). the TCP case).
However, this algorithm is biased towards the first available port
after a sequence of unavailable port numbers. If the local list of
registered port numbers that should not be allocated as ephemeral
ports (as described in Section 3.2) is significant, an attacker may
actually have a significantly better chance of guessing a port
number.
This algorithm selects ephemeral port numbers randomly and thus
reduces the chances of an attacker of guessing 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 This algorithm selects ephemeral port numbers randomly and thus
reduces the chances of an attacker of guessing the ephemeral port reduces the chances of an attacker of guessing the ephemeral port
selected for a target 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
skipping to change at page 24, line 18 skipping to change at page 24, line 18
address and transport-protocol port number, thus allowing the address and transport-protocol port number, thus allowing the
transport identifiers of a number of private hosts to be multiplexed transport identifiers of a number of private hosts to be multiplexed
into the transport identifiers of a single external address. into the transport identifiers of a single external address.
[RFC2663] [RFC2663]
In those scenarios in which a NAPT is present between the two end- In those scenarios in which a NAPT is present between the two end-
points of transport-protocol instance, the obfuscation of the points of transport-protocol instance, the obfuscation of the
ephemeral ports (from the point of view of the external network) will ephemeral ports (from the point of view of the external network) will
depend on the ephemeral port selection function at the NAPT. depend on the ephemeral port selection function at the NAPT.
Therefore, NAPTs should consider obfuscating the ephemeral ports by Therefore, NAPTs should consider obfuscating the ephemeral ports by
means of any of the algorithms discussed in this document. It should means of any of the algorithms discussed in this document.
be noted that in some network scenarios, a NAPT may naturally obscure
ephemeral port selections simply due to the vast range of services
with which it establishes connections and to the overall rate of the
traffic [Allman].
Section 3.5 provides guidance in choosing a port obfuscation A NAPT that does do not implement port preservation [RFC4787]
[RFC5382] SHOULD obfuscate the ephemeral port of a packet when it is
changed during translation of that packet.
A NAPT that does implement port preservation SHOULD obfuscate the
ephemeral port of a packet only if the port must be changed as a
result of the port being already in use for some other session.
A NAPT that performs parity preservation and that must change the
ephemeral port during translation of a packet SHOULD obfuscate the
ephemeral ports. The algorithms described in this document could be
easily adapted such that the parity is preserved (i.e., force the
lowest order bit of the resulting port number to 0 or 1 according to
whether even or odd parity is desired).
Some applications allocate contiguous ports and expect to see
contiguous port in use at their peers. Clearly, this expectation
might be difficult to accommodate at a NAPT, since some port numbers
might already be in use by other sessions, and thus an alternative
port might need to be selected, thus resulting in a non-contiguous
port number sequence (see Section 4.2.3 of [RFC4787]). A NAPT that
implements a simple port obfuscation algorithm (such as Algorithm 1,
Algorithm 2, or Algorithm 5) is likely to break this assumption, even
if the endpoint selecting an ephemeral port does select ephemeral
ports that are contiguous. However, since a number of different
ephemeral port selection algorithms have been implemented by deployed
NAPTs, any application that relies on any specific ephemeral port
selection algorithm at the NAPT is likely to suffer interoperability
problems when a NAPT is present between the two endpoints of a
transport protocol instance. Nevertheless, some of the algorithms
described in this document (namely Algorithm 3 and Algorithm 4)
select consecutive ephemeral ports such that they are contiguous
(except when one of the port numbers needed to produce a contiguous
sequence is already in use by some other NAPT session). Therefore, a
NAPT willing to produce sequences of contiguous port numbers should
consider implementing Algorithm 3 or Algorithm 4 of this document.
Section 3.5 provides further guidance in choosing a port obfuscation
algorithm. algorithm.
It should be noted that in some network scenarios, a NAPT may
naturally obscure ephemeral port selections simply due to the vast
range of services with which it establishes connections and to the
overall rate of the traffic [Allman].
5. Security Considerations 5. Security Considerations
Obfuscating ephemeral ports is no replacement for cryptographic Obfuscating ephemeral ports is no replacement for cryptographic
mechanisms, such as IPsec [RFC4301], in terms of protecting mechanisms, such as IPsec [RFC4301], in terms of protecting
transport-protocol instances against blind attacks. transport-protocol instances against blind attacks.
An eavesdropper, which can monitor the packets that correspond to the An eavesdropper, which can monitor the packets that correspond to the
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. Ephemeral port obfuscation does not
provide any additional protection against this kind of attacks. In provide any additional protection against this kind of attacks. In
such situations, proper authentication mechanisms such as those such situations, proper authentication mechanisms such as those
described in [RFC4301] should be used. described in [RFC4301] should be used.
If the local offset function F() results in identical offsets for This specification recommends including the whole range 1024-65535
different inputs at greater frequency than would be expected by for the selection of ephemeral ports, and suggests that an
chance, the port-offset mechanism proposed in this document would implementation maintains a list of those port numbers that should not
have a reduced effect. be made available for ephemeral port selection. If the list of port
numbers that are not available is significant, Algorithm 1 may be
highly biased and generate predictable ports, as noted in
Section 3.3.1. In particular, if the list of IANA Registered Ports
is accepted as the local list of port numbers that should not be made
available, certain ports may result with 500 times the probability of
other ports. Systems that support numerous applications resulting in
large lists of unavailable ports, or that use the IANA Registered
Ports without modification, MUST NOT use Algorithm 1.
If the local offset function F() (in Algorithm 3 and Algorithm 4)
results in identical offsets for different inputs at greater
frequency than would be expected by chance, the port-offset mechanism
proposed in this document would have a reduced effect.
If random numbers are used as the only source of the secret key, they 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
skipping to change at page 27, line 7 skipping to change at page 28, line 7
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. IANA Considerations
There are no IANA registries within this document. The RFC-Editor There are no IANA registries within this document. The RFC-Editor
can remove this section before publication of this document as an can remove this section before publication of this document as an
RFC. RFC.
7. Acknowledgements 7. Acknowledgements
The offset function was inspired by the mechanism proposed by Steven The offset function used in Algorithm 3 and Algorithm 4 was inspired
Bellovin in [RFC1948] for defending against TCP sequence number by the mechanism proposed by Steven Bellovin in [RFC1948] for
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, Alfred Hoenes, Avshalom Fairhurst, Adrian Farrel, Guillermo Gont, David Harrington, Alfred
Houri, Charlie Kaufman, Amit Klein, Carlos Pignataro, Tim Polk, Hoenes, Avshalom Houri, Charlie Kaufman, Amit Klein, Carlos
Kacheong Poon, Pasi Sarolahti, Randall Stewart, Joe Touch, Michael Pignataro, Tim Polk, Kacheong Poon, Pasi Sarolahti, Robert Sparks,
Tuexen, and Dan Wing for their valuable feedback on earlier versions Randall Stewart, Joe Touch, Michael Tuexen, Magnus Westerlund, and
of this document. Dan Wing for their valuable feedback on earlier versions of this
document.
The authors would like to thank FreeBSD's Mike Silbersack for a very The authors would like to thank FreeBSD's Mike Silbersack for a very
fruitful discussion about ephemeral port selection techniques. fruitful discussion about ephemeral port selection techniques.
8. References 8. References
8.1. Normative References 8.1. Normative References
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
August 1980. August 1980.
skipping to change at page 28, line 45 skipping to change at page 29, line 45
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
Requirements for Security", BCP 106, RFC 4086, June 2005. Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005. Internet Protocol", RFC 4301, December 2005.
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram
Congestion Control Protocol (DCCP)", RFC 4340, March 2006. Congestion Control Protocol (DCCP)", RFC 4340, March 2006.
[RFC4787] Audet, F. and C. Jennings, "Network Address Translation
(NAT) Behavioral Requirements for Unicast UDP", BCP 127,
RFC 4787, January 2007.
[RFC4960] Stewart, R., "Stream Control Transmission Protocol", [RFC4960] Stewart, R., "Stream Control Transmission Protocol",
RFC 4960, September 2007. RFC 4960, September 2007.
[RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P.
Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142,
RFC 5382, October 2008.
8.2. Informative References 8.2. Informative References
[Allman] Allman, M., "Comments On Selecting Ephemeral Ports", ACM
Computer Communication Review, 39(2), 2009.
[CPNI-TCP]
Gont, F., "CPNI Technical Note 3/2009: Security Assessment
of the Transmission Control Protocol (TCP)", http://
www.cpni.gov.uk/Docs/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]
Gont, F., "Security Assessment of the Transmission Control
Protocol (TCP)", draft-ietf-tcpm-tcp-security-01 (work in
progress), February 2010.
[I-D.ietf-tsvwg-sctpsocket]
Stewart, R., Poon, K., Tuexen, M., Yasevich, V., and P.
Lei, "Sockets API Extensions for Stream Control
Transmission Protocol (SCTP)",
draft-ietf-tsvwg-sctpsocket-23 (work in progress),
July 2010.
[IANA] "IANA Port Numbers", [IANA] "IANA Port Numbers",
<http://www.iana.org/assignments/port-numbers>. <http://www.iana.org/assignments/port-numbers>.
[I-D.ietf-tcpm-icmp-attacks] [Linux] The Linux Project, "http://www.kernel.org".
Gont, F., "ICMP attacks against TCP",
draft-ietf-tcpm-icmp-attacks-12 (work in progress), [NetBSD] The NetBSD Project, "http://www.netbsd.org".
March 2010.
[OpenBSD] The OpenBSD Project, "http://www.openbsd.org".
[OpenSolaris]
OpenSolaris, "http://www.opensolaris.org".
[RFC1337] Braden, B., "TIME-WAIT Assassination Hazards in TCP", [RFC1337] Braden, B., "TIME-WAIT Assassination Hazards in TCP",
RFC 1337, May 1992. RFC 1337, May 1992.
[RFC1948] Bellovin, S., "Defending Against Sequence Number Attacks", [RFC1948] Bellovin, S., "Defending Against Sequence Number Attacks",
RFC 1948, May 1996. RFC 1948, May 1996.
[RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address
Translator (NAT) Terminology and Considerations", Translator (NAT) Terminology and Considerations",
RFC 2663, August 1999. RFC 2663, August 1999.
[RFC4953] Touch, J., "Defending TCP Against Spoofing Attacks", [RFC4953] Touch, J., "Defending TCP Against Spoofing Attacks",
RFC 4953, July 2007. RFC 4953, July 2007.
[I-D.ietf-tsvwg-sctpsocket] [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP
Stewart, R., Poon, K., Tuexen, M., Yasevich, V., and P. Authentication Option", RFC 5925, June 2010.
Lei, "Sockets API Extensions for Stream Control
Transmission Protocol (SCTP)",
draft-ietf-tsvwg-sctpsocket-22 (work in progress),
March 2010.
[Allman] Allman, M., "Comments On Selecting Ephemeral Ports", ACM
Computer Communication Review, 39(2), 2009.
[CPNI-TCP]
Gont, F., "CPNI Technical Note 3/2009: Security Assessment
of the Transmission Control Protocol (TCP)", UK Centre
for the Protection of National Infrastructure, 2009.
[I-D.gont-tcp-security]
Gont, F., "Security Assessment of the Transmission Control
Protocol (TCP)", draft-gont-tcp-security-00 (work in
progress), February 2009.
[Linux] The Linux Project, "http://www.kernel.org".
[NetBSD] The NetBSD Project, "http://www.netbsd.org".
[OpenBSD] The OpenBSD Project, "http://www.openbsd.org".
[OpenSolaris] [RFC5927] Gont, F., "ICMP Attacks against TCP", RFC 5927, July 2010.
OpenSolaris, "http://www.opensolaris.org".
[Silbersack] [Silbersack]
Silbersack, M., "Improving TCP/IP security through Silbersack, M., "Improving TCP/IP security through
randomization without sacrificing interoperability.", randomization without sacrificing interoperability",
EuroBSDCon 2005 Conference . EuroBSDCon 2005 Conference .
[Stevens] Stevens, W., "Unix Network Programming, Volume 1: [Stevens] Stevens, W., "Unix Network Programming, Volume 1:
Networking APIs: Socket and XTI", Prentice Hall , 1998. Networking APIs: Socket and XTI", Prentice Hall , 1998.
[I-D.ietf-tcpm-tcp-auth-opt]
Touch, J., Mankin, A., and R. Bonica, "The TCP
Authentication Option", draft-ietf-tcpm-tcp-auth-opt-11
(work in progress), March 2010.
[Watson] Watson, P., "Slipping in the Window: TCP Reset Attacks", [Watson] Watson, P., "Slipping in the Window: TCP Reset Attacks",
CanSecWest 2004 Conference . CanSecWest 2004 Conference .
Appendix A. Survey of the algorithms in use by some popular Appendix A. Survey of the algorithms in use by some popular
implementations implementations
A.1. FreeBSD A.1. FreeBSD
FreeBSD 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]
skipping to change at page 32, line 9 skipping to change at page 33, line 9
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 Appendix B. Changes from previous versions of the draft (to be removed
by the RFC Editor before publication of this document as a by the RFC Editor before publication of this document as a
RFC RFC
B.1. Changes from draft-ietf-tsvwg-port-randomization-07 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. o Addresses Jari Arkko's DISCUSS.
B.2. Changes from draft-ietf-tsvwg-port-randomization-06 B.3. Changes from draft-ietf-tsvwg-port-randomization-06
o Fixes the writeo in the port number range. o Fixes the writeo in the port number range.
o Fixes the requirements on the random() function. o Fixes the requirements on the random() function.
o Other miscellaneous edits (resulting from IESG feedback. o Other miscellaneous edits (resulting from IESG feedback.
B.3. Changes from draft-ietf-tsvwg-port-randomization-05 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.
o Addresses AD review feedback from Lars Eggert. o Addresses AD review feedback from Lars Eggert.
B.4. Changes from draft-ietf-tsvwg-port-randomization-04 B.5. Changes from draft-ietf-tsvwg-port-randomization-04
o Fixes nits. o Fixes nits.
B.5. Changes from draft-ietf-tsvwg-port-randomization-03 B.6. Changes from draft-ietf-tsvwg-port-randomization-03
o Addresses WGLC comments from Mark Allman. See: o Addresses WGLC comments from Mark Allman. See:
http://www.ietf.org/mail-archive/web/tsvwg/current/msg09149.html http://www.ietf.org/mail-archive/web/tsvwg/current/msg09149.html
B.6. Changes from draft-ietf-tsvwg-port-randomization-02 B.7. Changes from draft-ietf-tsvwg-port-randomization-02
o Added clarification of what we mean by "port randomization". o Added clarification of what we mean by "port randomization".
o Addresses feedback sent on-list and off-list by Mark Allman. o Addresses feedback sent on-list and off-list by Mark Allman.
o Added references to [Allman] and [CPNI-TCP]. o Added references to [Allman] and [CPNI-TCP].
B.7. Changes from draft-ietf-tsvwg-port-randomization-01 B.8. Changes from draft-ietf-tsvwg-port-randomization-01
o Added Section 2.3. o Added Section 2.3.
o Added discussion of "lazy binding in Section 3.5. o Added discussion of "lazy binding in Section 3.5.
o Added discussion of obtaining the number of outgoing connections. o Added discussion of obtaining the number of outgoing connections.
o Miscellaneous editorial changes o Miscellaneous editorial changes
B.8. Changes from draft-ietf-tsvwg-port-randomization-00 B.9. Changes from draft-ietf-tsvwg-port-randomization-00
o Added Section 3.1. o Added Section 3.1.
o Changed Intended Status from "Standards Track" to "BCP". o Changed Intended Status from "Standards Track" to "BCP".
o Miscellaneous editorial changes. o Miscellaneous editorial changes.
B.9. Changes from draft-larsen-tsvwg-port-randomization-02 B.10. Changes from draft-larsen-tsvwg-port-randomization-02
o Draft resubmitted as draft-ietf. o Draft resubmitted as draft-ietf.
o Included references and text on protocols other than TCP. o Included references and text on protocols other than TCP.
o Added the second variant of the simple port randomization o Added the second variant of the simple port randomization
algorithm algorithm
o Reorganized the algorithms into different sections o Reorganized the algorithms into different sections
o Miscellaneous editorial changes. o Miscellaneous editorial changes.
B.10. Changes from draft-larsen-tsvwg-port-randomization-01 B.11. Changes from draft-larsen-tsvwg-port-randomization-01
o No changes. Draft resubmitted after expiration. o No changes. Draft resubmitted after expiration.
B.11. Changes from draft-larsen-tsvwg-port-randomization-00 B.12. Changes from draft-larsen-tsvwg-port-randomization-00
o Fixed a bug in expressions used to calculate number of ephemeral o Fixed a bug in expressions used to calculate number of ephemeral
ports ports
o Added a survey of the algorithms in use by popular TCP o Added a survey of the algorithms in use by popular TCP
implementations implementations
o The whole document was reorganized o The whole document was reorganized
o Miscellaneous editorial changes o Miscellaneous editorial changes
B.12. Changes from draft-larsen-tsvwg-port-randomisation-00 B.13. Changes from draft-larsen-tsvwg-port-randomisation-00
o Document resubmitted after original document by M. Larsen expired o Document resubmitted after original document by M. Larsen expired
in 2004 in 2004
o References were included to current WG documents of the TCPM WG o References were included to current WG documents of the TCPM WG
o The document was made more general, to apply to all transport o The document was made more general, to apply to all transport
protocols protocols
o Miscellaneous editorial changes o Miscellaneous editorial changes
 End of changes. 45 change blocks. 
140 lines changed or deleted 230 lines changed or added

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