draft-ietf-tsvwg-port-randomization-06.txt   draft-ietf-tsvwg-port-randomization-07.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: August 19, 2010 February 15, 2010 Expires: October 14, 2010 April 12, 2010
Transport Protocol Port Randomization Recommendations Transport Protocol Port Randomization Recommendations
draft-ietf-tsvwg-port-randomization-06 draft-ietf-tsvwg-port-randomization-07
Abstract Abstract
Recently, awareness has been raised about a number of "blind" attacks During the las few years, awareness has been raised about a number of
that can be performed against the Transmission Control Protocol (TCP) "blind" attacks that can be performed against the Transmission
and similar protocols. The consequences of these attacks range from Control Protocol (TCP) and similar protocols. The consequences of
throughput-reduction to broken connections or data corruption. These these attacks range from throughput-reduction to broken connections
attacks rely on the attacker's ability to guess or know the five- or data corruption. These attacks rely on the attacker's ability to
tuple (Protocol, Source Address, Destination Address, Source Port, guess or know the five-tuple (Protocol, Source Address, Destination
Destination Port) that identifies the transport protocol instance to Address, Source Port, Destination Port) that identifies the transport
be attacked. This document describes a number of simple and protocol instance to be attacked. This document describes a number
efficient methods for the selection of the client port number, such of simple and efficient methods for the selection of the client port
that the possibility of an attacker guessing the exact value is number, such that the possibility of an attacker guessing the exact
reduced. While this is not a replacement for cryptographic methods value is reduced. While this is not a replacement for cryptographic
for protecting the transport-protocol instance, the described port methods for protecting the transport-protocol instance, the described
number obfuscation algorithms provide improved security/obfuscation port number obfuscation algorithms provide improved security/
with very little effort and without any key management overhead. The obfuscation with very little effort and without any key management
algorithms described in this document are local policies that may be overhead. The algorithms described in this document are local
incrementally deployed, and that do not violate the specifications of policies that may be incrementally deployed, and that do not violate
any of the transport protocols that may benefit from them, such as the specifications of any of the transport protocols that may benefit
TCP, UDP, UDP-lite, SCTP, DCCP, and RTP (provided the RTP application from them, such as TCP, UDP, UDP-lite, SCTP, DCCP, and RTP (provided
explicitly signals the RTP and RTCP port numbers). the RTP application explicitly signals the RTP and RTCP port
numbers).
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF). Note that other groups may also distribute
other groups may also distribute working documents as Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts. 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 October 14, 2010.
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 19, 2010.
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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the BSD License. described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this 10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow material may not have granted the IETF Trust the right to allow
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
skipping to change at page 3, line 20 skipping to change at page 3, line 20
2.2. Ephemeral port selection . . . . . . . . . . . . . . . . . 7 2.2. Ephemeral port selection . . . . . . . . . . . . . . . . . 7
2.3. Collision of instance-id's . . . . . . . . . . . . . . . . 8 2.3. Collision of instance-id's . . . . . . . . . . . . . . . . 8
3. Obfuscating the Ephemeral Ports . . . . . . . . . . . . . . . 10 3. Obfuscating the Ephemeral Ports . . . . . . . . . . . . . . . 10
3.1. Characteristics of a good ephemeral port obfuscation 3.1. Characteristics of a good ephemeral port obfuscation
algorithm . . . . . . . . . . . . . . . . . . . . . . . . 10 algorithm . . . . . . . . . . . . . . . . . . . . . . . . 10
3.2. Ephemeral port number range . . . . . . . . . . . . . . . 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 . . . 12
3.3.2. Algorithm 2: Another simple port randomization 3.3.2. Algorithm 2: Another simple port randomization
algorithm . . . . . . . . . . . . . . . . . . . . . . 14 algorithm . . . . . . . . . . . . . . . . . . . . . . 14
3.3.3. Algorithm 3: Simple hash-based algorithm . . . . . . . 14 3.3.3. Algorithm 3: Simple hash-based algorithm . . . . . . . 15
3.3.4. Algorithm 4: Double-hash obfuscation algorithm . . . . 17 3.3.4. Algorithm 4: Double-hash obfuscation algorithm . . . . 17
3.3.5. Algorithm 5: Random-increments port selection 3.3.5. Algorithm 5: Random-increments port selection
algorithm . . . . . . . . . . . . . . . . . . . . . . 18 algorithm . . . . . . . . . . . . . . . . . . . . . . 19
3.4. Secret-key considerations for hash-based port 3.4. Secret-key considerations for hash-based port
obfuscation algorithms . . . . . . . . . . . . . . . . . . 20 obfuscation algorithms . . . . . . . . . . . . . . . . . . 21
3.5. Choosing an ephemeral port obfuscation algorithm . . . . . 21 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) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 (NAPT) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
5. Security Considerations . . . . . . . . . . . . . . . . . . . 24 5. Security Considerations . . . . . . . . . . . . . . . . . . . 25
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28
8.1. Normative References . . . . . . . . . . . . . . . . . . . 27 8.1. Normative References . . . . . . . . . . . . . . . . . . . 28
8.2. Informative References . . . . . . . . . . . . . . . . . . 27 8.2. Informative References . . . . . . . . . . . . . . . . . . 28
Appendix A. Survey of the algorithms in use by some popular Appendix A. Survey of the algorithms in use by some popular
implementations . . . . . . . . . . . . . . . . . . . 30 implementations . . . . . . . . . . . . . . . . . . . 31
A.1. FreeBSD . . . . . . . . . . . . . . . . . . . . . . . . . 30 A.1. FreeBSD . . . . . . . . . . . . . . . . . . . . . . . . . 31
A.2. Linux . . . . . . . . . . . . . . . . . . . . . . . . . . 30 A.2. Linux . . . . . . . . . . . . . . . . . . . . . . . . . . 31
A.3. NetBSD . . . . . . . . . . . . . . . . . . . . . . . . . . 30 A.3. NetBSD . . . . . . . . . . . . . . . . . . . . . . . . . . 31
A.4. OpenBSD . . . . . . . . . . . . . . . . . . . . . . . . . 30 A.4. OpenBSD . . . . . . . . . . . . . . . . . . . . . . . . . 31
A.5. OpenSolaris . . . . . . . . . . . . . . . . . . . . . . . 30 A.5. OpenSolaris . . . . . . . . . . . . . . . . . . . . . . . 31
Appendix B. Changes from previous versions of the draft (to Appendix B. Changes from previous versions of the draft (to
be removed by the RFC Editor before publication be removed by the RFC Editor before publication
of this document as a RFC . . . . . . . . . . . . . . 31 of this document as a RFC . . . . . . . . . . . . . . 32
B.1. Changes from draft-ietf-tsvwg-port-randomization-05 . . . 31 B.1. Changes from draft-ietf-tsvwg-port-randomization-06 . . . 32
B.2. Changes from draft-ietf-tsvwg-port-randomization-04 . . . 31 B.2. Changes from draft-ietf-tsvwg-port-randomization-05 . . . 32
B.3. Changes from draft-ietf-tsvwg-port-randomization-03 . . . 31 B.3. Changes from draft-ietf-tsvwg-port-randomization-04 . . . 32
B.4. Changes from draft-ietf-tsvwg-port-randomization-02 . . . 31 B.4. Changes from draft-ietf-tsvwg-port-randomization-03 . . . 32
B.5. Changes from draft-ietf-tsvwg-port-randomization-01 . . . 31 B.5. Changes from draft-ietf-tsvwg-port-randomization-02 . . . 32
B.6. Changes from draft-ietf-tsvwg-port-randomization-00 . . . 31 B.6. Changes from draft-ietf-tsvwg-port-randomization-01 . . . 32
B.7. Changes from draft-larsen-tsvwg-port-randomization-02 . . 31 B.7. Changes from draft-ietf-tsvwg-port-randomization-00 . . . 33
B.8. Changes from draft-larsen-tsvwg-port-randomization-01 . . 32 B.8. Changes from draft-larsen-tsvwg-port-randomization-02 . . 33
B.9. Changes from draft-larsen-tsvwg-port-randomization-00 . . 32 B.9. Changes from draft-larsen-tsvwg-port-randomization-01 . . 33
B.10. Changes from draft-larsen-tsvwg-port-randomisation-00 . . 32 B.10. Changes from draft-larsen-tsvwg-port-randomization-00 . . 33
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33 B.11. Changes from draft-larsen-tsvwg-port-randomisation-00 . . 33
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35
1. Introduction 1. Introduction
Recently, awareness has been raised about a number of "blind" attacks Recently, awareness has been raised about a number of "blind" attacks
(i.e., attacks that can be performed without the need to sniff the (i.e., attacks that can be performed without the need to sniff the
packets that correspond to the transport protocol instance to be packets that correspond to the transport protocol instance to be
attacked) that can be performed against the Transmission Control attacked) that can be performed against the Transmission Control
Protocol (TCP) [RFC0793] and similar protocols. The consequences of Protocol (TCP) [RFC0793] and similar protocols. The consequences of
these attacks range from throughput-reduction to broken connections these attacks range from throughput-reduction to broken connections
or data corruption [I-D.ietf-tcpm-icmp-attacks] [RFC4953] [Watson]. or data corruption [I-D.ietf-tcpm-icmp-attacks] [RFC4953] [Watson].
skipping to change at page 10, line 9 skipping to change at page 10, line 9
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-id's would be, e.g. in the case of TCP, for both end-
points of a TCP connection to keep state about recent connections points 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 end-points end up in the TIME-WAIT state).
3. Obfuscating the Ephemeral Ports 3. Obfuscating the Ephemeral Ports
3.1. Characteristics of a good ephemeral port obfuscation algorithm 3.1. Characteristics of a good ephemeral port obfuscation algorithm
There are a number of factors to consider when designing an algorithm There are several factors to consider when designing an algorithm for
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-id's
o Avoiding conflict with applications that depend on the use of o Avoiding conflict with applications that depend on the use of
specific port numbers. specific port numbers.
Given the goal of improving the transport protocol's resistance to Given the goal of improving the transport protocol's resistance to
skipping to change at page 10, line 39 skipping to change at page 10, line 39
establishment, or data corruption) discussed in Section 2.3. As establishment, or data corruption) discussed in Section 2.3. As
discussed in Section 1, it is worth noting that while the technique discussed in Section 1, it is worth noting that while the technique
of mitigating "blind" attacks by obfuscating the ephemeral port of mitigating "blind" attacks by obfuscating the ephemeral port
election is well-known as "port randomization", the goal of the election is well-known as "port randomization", the goal of the
algorithms described in this document is to reduce the chances of an algorithms described in this document is to reduce the chances of an
attacker guessing the ephemeral ports selected for new transport- attacker guessing the ephemeral ports selected for new transport-
protocol instances, rather than to actually produce sequences of protocol instances, rather than to actually produce sequences of
mathematically random ephemeral port numbers. mathematically random ephemeral port numbers.
It is also worth noting that, provided adequate algorithms are in It is also worth noting that, provided adequate algorithms are in
use, the larger the range from which ephemeral pots are selected, the use, the larger the range from which ephemeral ports are selected,
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-id's 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
skipping to change at page 11, line 16 skipping to change at page 11, line 16
It is important to note that a number of applications rely on binding It is important to note that a number of applications rely on binding
specific port numbers that may be within the ephemeral ports range. specific port numbers that may be within the ephemeral ports range.
If such an application was run while the corresponding port number If such an application was run while the corresponding port number
was in use, the application would fail. Therefore, 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 by issuing a connection connection to a local server application in at least two different
request to the victim client at roughly the same time the client ways. Firstly, an attacker could issue a connection request to the
tries to connect to the victim server application [CPNI-TCP] victim client at roughly the same time the client tries to connect to
[I-D.gont-tcp-security]. If the SYN segment corresponding to the the victim server application [CPNI-TCP] [I-D.gont-tcp-security]. If
attacker's connection request and the SYN segment corresponding to the SYN segment corresponding to the attacker's connection request
the victim client "cross each other in the network", and provided the and the SYN segment corresponding to the victim client "cross each
attacker is able to know or guess the ephemeral port used by the other in the network", and provided the attacker is able to know or
client, a TCP simultaneous open scenario would take place, and the guess the ephemeral port used by the client, a TCP simultaneous open
incoming connection request sent by the client would be matched with scenario would take place, and the incoming connection request sent
the attacker's socket rather than with the victim server by the client would be matched with the attacker's socket rather than
application's socket. with the victim server application's socket. Secondly, an attacker
could specify a more specific socket than the "victim" socket (e.g.,
specify both the local IP address and the local TCP port), and thus
incoming SYN segments matching the attacker's socket would be
delivered to the 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.gont-tcp-security].
The aforementioned issues 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 explititly 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 is not affected by the exploitation of DCCP is not affected by the exploitation of "simultaneous opens" to
"simultaneous opens" to ""steal" incoming connections, as the server "steal" incoming connections, as the server and the client state
and the client state machines are different [RFC4340]. However, it machines are different [RFC4340]. However, it may be affected by the
may be affected by the vector involving binding a more specific vector involving binding a more specific socket. As a result, those
socket. As a result, those tuples {local IP address, local port, tuples {local IP address, local port, Service Code} that are in use
Service Code} that are in use by a local socket should not be allowed by a local socket should not be allowed for allocation as ephemeral
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-49151. the whole range 1024-65535.
Since this range includes ports numbers assigned by IANA, this may Since this range includes ports numbers assigned by IANA, this may
not always be possible, though. A possible workaround for this not always be possible, though. A possible workaround for this
potential problem would be to maintain a local list of the port potential problem would be to maintain a local list of the port
numbers that should not be allocated as ephemeral ports. Thus, numbers that should not be allocated as ephemeral ports. Thus,
before allocating a port number, the ephemeral port selection before allocating a port number, the ephemeral port selection
function would check this list, avoiding the allocation of ports that function would check this list, avoiding the allocation of ports that
may be needed for specific applications. may be needed for specific applications.
Ephemeral port selection algorithms SHOULD use the largest possible Ephemeral port selection algorithms SHOULD use the largest possible
skipping to change at page 13, line 29 skipping to change at page 13, line 30
count--; count--;
} while (count > 0); } while (count > 0);
return ERROR; return ERROR;
Figure 2 Figure 2
We will refer to this algorithm as 'Algorithm 1'. We will refer to this algorithm as 'Algorithm 1'.
Note: "random()" is a function that returns a pseudo-random unsigned Note:
interger number in the range 0-65535 (it may return values larger random() is a function that returns a 32-bit pseudo-random
than 65535, as is the case with the "random()" C-language function). unsigned integer number. Note that the output needs to be
unpredictable, and typical implementations of POSIX random()
function do not necessarily meet this requirement. See [RFC4086]
for randomness requirements for security.
All the variables (in this and all the algorithms discussed in
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 identical
IP addresses and server port, the resulting five-tuple might not be IP addresses and server port, the resulting five-tuple might not be
unique. Therefore, multiple ports may have to be tried and verified unique. Therefore, multiple ports may have to be tried and verified
against all existing transport-protocol instances before a port can against all existing transport-protocol instances before a port can
be chosen. be chosen.
Web proxy servers, NAPTs [RFC2663], and other middle-boxes aggregate Web proxy servers, NAPTs [RFC2663], and other middle-boxes aggregate
multiple peers into the same port space and thus 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
skipping to change at page 15, line 15 skipping to change at page 15, line 25
Algorithm 2. Algorithm 2.
Ideally, we would like a 'next_ephemeral' value for each set of Ideally, we would like a 'next_ephemeral' value for each set of
(local IP address, remote IP addresses, remote port), so that the (local IP address, remote IP addresses, remote port), so that the
port reuse frequency is the lowest possible. Each of these port reuse frequency is the lowest possible. Each of these
'next_ephemeral' variables should be initialized with random values 'next_ephemeral' variables should be initialized with random values
within the ephemeral port range and would thus separate the ephemeral within the ephemeral port range and would thus separate the ephemeral
port space of the transport-protocol instances on a "per destination port space of the transport-protocol instances on a "per destination
end-point" basis (this "separation of the ephemeral port space" means end-point" basis (this "separation of the ephemeral port space" means
that transport-protocol instances with different remote end-points that transport-protocol instances with different remote end-points
will not have different sequences of port numbers; i.e., wil not be will not have different sequences of port numbers; i.e., will not be
part of the same ephemeral port sequence as in the case of the part of the same ephemeral port sequence as in the case of the
traditional BSD ephemeral port selection algorithm). Since we do not traditional BSD ephemeral port selection algorithm). Since we do not
want to maintain in memory all these 'next_ephemeral' values, we want to maintain in memory all these 'next_ephemeral' values, we
propose an offset function F(), that can be computed from the local propose an offset function F(), that can be computed from the local
IP address, remote IP address, remote port and a secret key. F() IP address, remote IP address, remote port and a secret key. F()
will yield (practically) different values for each set of arguments, will yield (practically) different values for each set of arguments,
i.e.: i.e.:
/* Initialization at system boot time. Could be random. */ /* Initialization at system boot time. Could be random. */
next_ephemeral = 0; next_ephemeral = 0;
skipping to change at page 16, line 23 skipping to change at page 16, line 50
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 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 an obfuscation
technique. The secret should be chosen as random as possible, see technique. The secret should be chosen to be as random as possible
[RFC4086] for recommendations on choosing secrets. (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 host
to host basis, but on a user to service basis. In fact, any to host basis, but on a user to service basis. In fact, any
identifier of the remote entity could be used, depending on identifier of the remote entity could be used, depending on
availability an the granularity requested. With SCTP both hostnames availability and the granularity requested. With SCTP both hostnames
and alternative IP addresses may be included in the association and alternative IP addresses may be included in the association
negotiation and either of these could be used in the offset function negotiation and either of these could be used in the offset function
F(). 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 from a given remote
skipping to change at page 19, line 33 skipping to change at page 20, line 33
return ERROR; return ERROR;
Figure 6 Figure 6
This algorithm aims at at producing a monotonically-increasing This algorithm aims at at producing a monotonically-increasing
sequence to prevent the collision of instance-id's, while avoiding sequence to prevent the collision of instance-id's, while avoiding
the use of fixed increments, which would lead to trivially- the use of fixed increments, which would lead to trivially-
predictable sequences. The value "N" allows for direct control of predictable sequences. The value "N" allows for direct control of
the tradeoff between the level of obfuscation and the port reuse the tradeoff between the level of obfuscation and the port reuse
frequency. The smaller the value of "N", the more linear the more frequency. The smaller the value of "N", the more similar this
similar this algorithm is to the traditional BSD port selection algorithm is to the traditional BSD port selection algorithm
algorithm (described in Section 2.2. The larger the value of "N", (described in Section 2.2. The larger the value of "N", the more
the more similar this algorithm is to the algorithm described in similar this algorithm is to the algorithm described in Section 3.3.1
Section 3.3.1 of this document. of this 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-id's. Therefore, "N" should be selecting according to the
following criteria: following criteria:
o It should maximize the wrapping time of the ephemeral port space o It should maximize the wrapping time of the ephemeral port space
o It should minimize collisions of instance-id's o It should minimize collisions of instance-id's
o It should maximize obfuscation o It should maximize obfuscation
skipping to change at page 20, line 17 skipping to change at page 21, line 17
Every complex manipulation (like MD5) is no more secure than the Every complex manipulation (like MD5) is no more secure than the
input values, and in the case of ephemeral ports, the secret key. If input values, and in the case of ephemeral ports, the secret key. If
an attacker is aware of which cryptographic hash function is being an attacker is aware of which cryptographic hash function is being
used by the victim (which we should expect), and the attacker can used by the victim (which we should expect), and the attacker can
obtain enough material (e.g. ephemeral ports chosen by the victim), obtain enough material (e.g. ephemeral ports chosen by the victim),
the attacker may simply search the entire secret key space to find the attacker may simply search the entire secret key space to find
matches. matches.
To protect against this, the secret key should be of a reasonable To protect against this, the secret key should be of a reasonable
length. Key lengths of 32 bits should be adequate, since a 32-bit length. Key lengths of 128 bits should be adequate.
secret would result in approximately 65k possible secrets if the
attacker is able to obtain a single ephemeral port (assuming a good
hash function). If the attacker is able to obtain more ephemeral
ports, key lengths of 64 bits or more should be used.
Another possible mechanism for protecting the secret key is to change Another possible mechanism for protecting the secret key is to change
it after some time. If the host platform is capable of producing it after some time. If the host platform is capable of producing
reasonable good random data, the secret key can be changed 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 Section 3.3.3 and Section 3.3.4)
used for each destination end-point will be different from that used for each destination end-point will be different from that
computed with the previous secret, thus leading to the selection of a computed with the previous secret, thus leading to the selection of a
port number recently used for connecting to the same end-point. port number recently used for connecting to the same end-point.
Thus the change in secret key should be done with consideration and Thus the change in secret key should be done with consideration and
skipping to change at page 24, line 20 skipping to change at page 25, line 20
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 If the local offset function F() results in identical offsets for
different inputs, the port-offset mechanism proposed in this document different inputs at greater frequency than would be expected by
has no or reduced effect. 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
must 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
skipping to change at page 26, line 13 skipping to change at page 27, line 13
RFC. RFC.
7. Acknowledgements 7. Acknowledgements
The offset function was inspired by the mechanism proposed by Steven The offset function was inspired by the mechanism proposed by Steven
Bellovin in [RFC1948] for defending against TCP sequence number Bellovin in [RFC1948] for defending against TCP sequence number
attacks. attacks.
The authors would like to thank (in alphabetical order) Mark Allman, The authors would like to thank (in alphabetical order) Mark Allman,
Matthias Bethke, Stephane Bortzmeyer, Brian Carpenter, Vincent Matthias Bethke, Stephane Bortzmeyer, Brian Carpenter, Vincent
Deffontaines, Lars Eggert, Gorry Fairhurst, Guillermo Gont, Alfred Deffontaines, Ralph Droms, Lars Eggert, Pasi Eronen, Gorry Fairhurst,
Hoenes, Amit Klein, Carlos Pignataro, Kacheong Poon, Pasi Sarolahti, Adrian Farrel, Guillermo Gont, Alfred Hoenes, Avshalom Houri, Charlie
Randall Stewart, Joe Touch, Michael Tuexen, and Dan Wing for their Kaufman, Amit Klein, Carlos Pignataro, Tim Polk, Kacheong Poon, Pasi
valuable feedback on earlier versions of this document. Sarolahti, Randall Stewart, Joe Touch, Michael Tuexen, and Dan Wing
for their valuable feedback on earlier versions of this document.
The authors would like to thank FreeBSD's Mike Silbersack for a very The authors would like to thank FreeBSD's Mike Silbersack for a very
fruitful discussion about ephemeral port selection techniques. fruitful discussion about ephemeral port selection techniques.
Fernando Gont would like to thank Carolina Suarez for her love and Fernando Gont would like to thank Carolina Suarez for her love and
support. support.
8. References 8. References
8.1. Normative References 8.1. Normative References
skipping to change at page 28, line 8 skipping to change at page 29, line 8
8.2. Informative References 8.2. Informative References
[FreeBSD] The FreeBSD Project, "http://www.freebsd.org". [FreeBSD] The FreeBSD Project, "http://www.freebsd.org".
[IANA] "IANA Port Numbers", [IANA] "IANA Port Numbers",
<http://www.iana.org/assignments/port-numbers>. <http://www.iana.org/assignments/port-numbers>.
[I-D.ietf-tcpm-icmp-attacks] [I-D.ietf-tcpm-icmp-attacks]
Gont, F., "ICMP attacks against TCP", Gont, F., "ICMP attacks against TCP",
draft-ietf-tcpm-icmp-attacks-10 (work in progress), draft-ietf-tcpm-icmp-attacks-12 (work in progress),
January 2010. March 2010.
[RFC1337] Braden, B., "TIME-WAIT Assassination Hazards in TCP", [RFC1337] Braden, B., "TIME-WAIT Assassination Hazards in TCP",
RFC 1337, May 1992. RFC 1337, May 1992.
[RFC1948] Bellovin, S., "Defending Against Sequence Number Attacks", [RFC1948] Bellovin, S., "Defending Against Sequence Number Attacks",
RFC 1948, May 1996. RFC 1948, May 1996.
[RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address
Translator (NAT) Terminology and Considerations", Translator (NAT) Terminology and Considerations",
RFC 2663, August 1999. RFC 2663, August 1999.
[RFC4953] Touch, J., "Defending TCP Against Spoofing Attacks", [RFC4953] Touch, J., "Defending TCP Against Spoofing Attacks",
RFC 4953, July 2007. RFC 4953, July 2007.
[I-D.ietf-tsvwg-sctpsocket] [I-D.ietf-tsvwg-sctpsocket]
Stewart, R., Poon, K., Tuexen, M., Yasevich, V., and P. Stewart, R., Poon, K., Tuexen, M., Yasevich, V., and P.
Lei, "Sockets API Extensions for Stream Control Lei, "Sockets API Extensions for Stream Control
Transmission Protocol (SCTP)", Transmission Protocol (SCTP)",
draft-ietf-tsvwg-sctpsocket-21 (work in progress), draft-ietf-tsvwg-sctpsocket-22 (work in progress),
February 2010. March 2010.
[Allman] Allman, M., "Comments On Selecting Ephemeral Ports", ACM [Allman] Allman, M., "Comments On Selecting Ephemeral Ports", ACM
Computer Communication Review, 39(2), 2009. Computer Communication Review, 39(2), 2009.
[CPNI-TCP] [CPNI-TCP]
Gont, F., "CPNI Technical Note 3/2009: Security Assessment Gont, F., "CPNI Technical Note 3/2009: Security Assessment
of the Transmission Control Protocol (TCP)", UK Centre of the Transmission Control Protocol (TCP)", UK Centre
for the Protection of National Infrastructure, 2009. for the Protection of National Infrastructure, 2009.
[I-D.gont-tcp-security] [I-D.gont-tcp-security]
skipping to change at page 29, line 15 skipping to change at page 30, line 15
[Silbersack] [Silbersack]
Silbersack, M., "Improving TCP/IP security through Silbersack, M., "Improving TCP/IP security through
randomization without sacrificing interoperability.", randomization without sacrificing interoperability.",
EuroBSDCon 2005 Conference . EuroBSDCon 2005 Conference .
[Stevens] Stevens, W., "Unix Network Programming, Volume 1: [Stevens] Stevens, W., "Unix Network Programming, Volume 1:
Networking APIs: Socket and XTI", Prentice Hall , 1998. Networking APIs: Socket and XTI", Prentice Hall , 1998.
[I-D.ietf-tcpm-tcp-auth-opt] [I-D.ietf-tcpm-tcp-auth-opt]
Touch, J., Mankin, A., and R. Bonica, "The TCP Touch, J., Mankin, A., and R. Bonica, "The TCP
Authentication Option", draft-ietf-tcpm-tcp-auth-opt-10 Authentication Option", draft-ietf-tcpm-tcp-auth-opt-11
(work in progress), January 2010. (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]
A.2. Linux A.2. Linux
Linux 2.6.15-53-386 implements Algorithm 3. If the algorithm is Linux 2.6.15-53-386 implements Algorithm 3, with MD5 as the hash
faced with the corner-case scenario described in Section 3.5, algorithm. If the algorithm is faced with the corner-case scenario
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
skipping to change at page 31, line 9 skipping to change at page 32, 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-05 B.1. 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.2. 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.2. Changes from draft-ietf-tsvwg-port-randomization-04 o Addresses AD review feedback from Lars Eggert.
B.3. Changes from draft-ietf-tsvwg-port-randomization-04
o Fixes nits. o Fixes nits.
B.3. Changes from draft-ietf-tsvwg-port-randomization-03 B.4. 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.4. Changes from draft-ietf-tsvwg-port-randomization-02 B.5. 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.5. Changes from draft-ietf-tsvwg-port-randomization-01 B.6. 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.6. Changes from draft-ietf-tsvwg-port-randomization-00 B.7. 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.7. Changes from draft-larsen-tsvwg-port-randomization-02 B.8. 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.8. Changes from draft-larsen-tsvwg-port-randomization-01 B.9. Changes from draft-larsen-tsvwg-port-randomization-01
o No changes. Draft resubmitted after expiration. o No changes. Draft resubmitted after expiration.
B.9. Changes from draft-larsen-tsvwg-port-randomization-00 B.10. 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.10. Changes from draft-larsen-tsvwg-port-randomisation-00 B.11. 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. 44 change blocks. 
132 lines changed or deleted 145 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/