draft-ietf-tsvwg-port-randomization-03.txt   draft-ietf-tsvwg-port-randomization-04.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: September 12, 2009 March 11, 2009 Expires: January 3, 2010 July 2, 2009
Port Randomization Port Randomization
draft-ietf-tsvwg-port-randomization-03 draft-ietf-tsvwg-port-randomization-04
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 33 skipping to change at page 1, line 33
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 12, 2009. This Internet-Draft will expire on January 3, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 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 in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 3, line 12 skipping to change at page 3, line 12
any of the transport protocols that may benefit from them, such as any of the transport protocols that may benefit from them, such as
TCP, UDP, UDP-lite, SCTP, DCCP, and RTP. TCP, UDP, UDP-lite, SCTP, DCCP, and RTP.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Ephemeral Ports . . . . . . . . . . . . . . . . . . . . . . . 6 2. Ephemeral Ports . . . . . . . . . . . . . . . . . . . . . . . 6
2.1. Traditional Ephemeral Port Range . . . . . . . . . . . . . 6 2.1. Traditional Ephemeral Port Range . . . . . . . . . . . . . 6
2.2. Ephemeral port selection . . . . . . . . . . . . . . . . . 6 2.2. Ephemeral port selection . . . . . . . . . . . . . . . . . 6
2.3. Collision of connection-id's . . . . . . . . . . . . . . . 7 2.3. Collision of connection-id's . . . . . . . . . . . . . . . 7
3. Randomizing the Ephemeral Ports . . . . . . . . . . . . . . . 9 3. Obfuscating the Ephemeral Ports . . . . . . . . . . . . . . . 9
3.1. Characteristics of a good ephemeral port randomization 3.1. Characteristics of a good ephemeral port obfuscation
algorithm . . . . . . . . . . . . . . . . . . . . . . . . 9 algorithm . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2. Ephemeral port number range . . . . . . . . . . . . . . . 10 3.2. Ephemeral port number range . . . . . . . . . . . . . . . 10
3.3. Ephemeral Port Randomization Algorithms . . . . . . . . . 11 3.3. Ephemeral Port Obfuscation Algorithms . . . . . . . . . . 11
3.3.1. Algorithm 1: Simple port randomization algorithm . . . 11 3.3.1. Algorithm 1: Simple port randomization algorithm . . . 11
3.3.2. Algorithm 2: Another simple port randomization 3.3.2. Algorithm 2: Another simple port randomization
algorithm . . . . . . . . . . . . . . . . . . . . . . 13 algorithm . . . . . . . . . . . . . . . . . . . . . . 13
3.3.3. Algorithm 3: Simple hash-based algorithm . . . . . . . 13 3.3.3. Algorithm 3: Simple hash-based algorithm . . . . . . . 13
3.3.4. Algorithm 4: Double-hash randomization algorithm . . . 15 3.3.4. Algorithm 4: Double-hash obfuscation algorithm . . . . 15
3.3.5. Algorithm 5: Random-increments port selection 3.3.5. Algorithm 5: Random-increments port selection
algorithm . . . . . . . . . . . . . . . . . . . . . . 17 algorithm . . . . . . . . . . . . . . . . . . . . . . 17
3.4. Secret-key considerations for hash-based port 3.4. Secret-key considerations for hash-based port
randomization algorithms . . . . . . . . . . . . . . . . . 18 obfuscation algorithms . . . . . . . . . . . . . . . . . . 19
3.5. Choosing an ephemeral port randomization algorithm . . . . 19 3.5. Choosing an ephemeral port obfuscation algorithm . . . . . 20
4. Port randomization and Network Address Port Translation 4. Port obfuscation and Network Address Port Translation
(NAPT) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 (NAPT) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
5. Security Considerations . . . . . . . . . . . . . . . . . . . 23 5. Security Considerations . . . . . . . . . . . . . . . . . . . 23
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25
7.1. Normative References . . . . . . . . . . . . . . . . . . . 25 7.1. Normative References . . . . . . . . . . . . . . . . . . . 25
7.2. Informative References . . . . . . . . . . . . . . . . . . 26 7.2. Informative References . . . . . . . . . . . . . . . . . . 26
Appendix A. Survey of the algorithms in use by some popular Appendix A. Survey of the algorithms in use by some popular
implementations . . . . . . . . . . . . . . . . . . . 28 implementations . . . . . . . . . . . . . . . . . . . 28
A.1. FreeBSD . . . . . . . . . . . . . . . . . . . . . . . . . 28 A.1. FreeBSD . . . . . . . . . . . . . . . . . . . . . . . . . 28
A.2. Linux . . . . . . . . . . . . . . . . . . . . . . . . . . 28 A.2. Linux . . . . . . . . . . . . . . . . . . . . . . . . . . 28
A.3. NetBSD . . . . . . . . . . . . . . . . . . . . . . . . . . 28 A.3. NetBSD . . . . . . . . . . . . . . . . . . . . . . . . . . 28
A.4. OpenBSD . . . . . . . . . . . . . . . . . . . . . . . . . 28 A.4. OpenBSD . . . . . . . . . . . . . . . . . . . . . . . . . 28
Appendix B. Changes from previous versions of the draft . . . . . 29 A.5. OpenSolaris . . . . . . . . . . . . . . . . . . . . . . . 28
B.1. Changes from draft-ietf-tsvwg-port-randomization-02 . . . 29 Appendix B. Changes from previous versions of the draft (to
B.2. Changes from draft-ietf-tsvwg-port-randomization-01 . . . 29 be removed by the RFC Editor before publication
B.3. Changes from draft-ietf-tsvwg-port-randomization-00 . . . 29 of this document as a RFC . . . . . . . . . . . . . . 29
B.4. Changes from draft-larsen-tsvwg-port-randomization-02 . . 29 B.1. Changes from draft-ietf-tsvwg-port-randomization-03 . . . 29
B.5. Changes from draft-larsen-tsvwg-port-randomization-01 . . 29 B.2. Changes from draft-ietf-tsvwg-port-randomization-02 . . . 29
B.6. Changes from draft-larsen-tsvwg-port-randomization-00 . . 30 B.3. Changes from draft-ietf-tsvwg-port-randomization-01 . . . 29
B.7. Changes from draft-larsen-tsvwg-port-randomisation-00 . . 30 B.4. Changes from draft-ietf-tsvwg-port-randomization-00 . . . 29
B.5. Changes from draft-larsen-tsvwg-port-randomization-02 . . 29
B.6. Changes from draft-larsen-tsvwg-port-randomization-01 . . 30
B.7. Changes from draft-larsen-tsvwg-port-randomization-00 . . 30
B.8. Changes from draft-larsen-tsvwg-port-randomisation-00 . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31
1. Introduction 1. Introduction
Recently, awareness has been raised about a number of "blind" attacks Recently, awareness has been raised about a number of "blind" attacks
(i.e., attacks that can be performed without the need to sniff the (i.e., attacks that can be performed without the need to sniff the
packets that correspond to the transport protocol instance to be packets that correspond to the transport protocol instance to be
attacked) that can be performed against the Transmission Control attacked) that can be performed against the Transmission Control
Protocol (TCP) [RFC0793] and similar protocols. The consequences of Protocol (TCP) [RFC0793] and similar protocols. The consequences of
these attacks range from throughput-reduction to broken connections these attacks range from throughput-reduction to broken connections
skipping to change at page 5, line 9 skipping to change at page 5, line 9
from it, such as TCP [RFC0793], UDP [RFC0768], SCTP [RFC4960], DCCP from it, such as TCP [RFC0793], UDP [RFC0768], SCTP [RFC4960], DCCP
[RFC4340], UDP-lite [RFC3828], and RTP [RFC3550]. [RFC4340], UDP-lite [RFC3828], and RTP [RFC3550].
Since these mechanisms are obfuscation techniques, focus has been on Since these mechanisms are obfuscation techniques, focus has been on
a reasonable compromise between the level of obfuscation and the ease a reasonable compromise between the level of obfuscation and the ease
of implementation. Thus the algorithms must be computationally of implementation. Thus the algorithms must be computationally
efficient, and not require substantial state. efficient, and not require substantial state.
We note that while the technique of mitigating "blind" attacks by We note that while the technique of mitigating "blind" attacks by
obfuscating the ephemeral port election is well-known as "port obfuscating the ephemeral port election is well-known as "port
randomization", the goal of the algorithms described in tihs document randomization", the goal of the algorithms described in this document
is to reduce the chances of an attacker guessing the ephemeral ports is to reduce the chances of an attacker guessing the ephemeral ports
selected for new connections, rather than to actually produce a selected for new connections, rather than to actually produce
random sequences of ephemeral ports. mathematically random sequences of ephemeral ports.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
2. Ephemeral Ports 2. Ephemeral Ports
2.1. Traditional Ephemeral Port Range 2.1. Traditional Ephemeral Port Range
The Internet Assigned Numbers Authority (IANA) assigns the unique The Internet Assigned Numbers Authority (IANA) assigns the unique
skipping to change at page 6, line 24 skipping to change at page 6, line 24
o The Well Known Ports, 0 through 1023. o The Well Known Ports, 0 through 1023.
o The Registered Ports, 1024 through 49151 o The Registered Ports, 1024 through 49151
o The Dynamic and/or Private Ports, 49152 through 65535 o The Dynamic and/or Private Ports, 49152 through 65535
The range for assigned ports managed by the IANA is 0-1023, with the The range for assigned ports managed by the IANA is 0-1023, with the
remainder being registered by IANA but not assigned. remainder being registered by IANA but not assigned.
The ephemeral port range has traditionally consisted of the 49152- The ephemeral port range defined by IANA has traditionally consisted
65535 range. of the 49152-65535 range.
2.2. Ephemeral port selection 2.2. Ephemeral port selection
As each communication instance is identified by the five-tuple As each communication instance is identified by the five-tuple
{protocol, local IP address, local port, remote IP address, remote {protocol, local IP address, local port, remote IP address, remote
port}, the selection of ephemeral port numbers must result in a port}, the selection of ephemeral port numbers must result in a
unique five-tuple. unique five-tuple.
Selection of ephemeral ports such that they result in unique five- Selection of ephemeral ports such that they result in unique five-
tuples is handled by some implementations by having a per-protocol tuples is handled by some implementations by having a per-protocol
skipping to change at page 9, line 4 skipping to change at page 8, line 30
should ideally minimize the rate of connection-id collisions. should ideally minimize the rate of connection-id collisions.
A simple approach to minimize the rate of these collisions would be A simple approach to minimize the rate of these collisions would be
to choose port numbers incrementally, so that a given port number to choose port numbers incrementally, so that a given port number
would not be reused until the rest of the port numbers in ephemeral would not be reused until the rest of the port numbers in ephemeral
port range have been used for a transport protocol instance. port range have been used for a transport protocol instance.
However, if a single global variable were used to keep track of the However, if a single global variable were used to keep track of the
last ephemeral port selected, ephemeral port numbers would be last ephemeral port selected, ephemeral port numbers would be
trivially predictable, thus making it easier for an off-path attacker trivially predictable, thus making it easier for an off-path attacker
to "guess" the connection-id in use by a target connection. to "guess" the connection-id in use by a target connection.
Section 3.3.3 and Section 3.3.4 describe algorithms that select port
numbers incrementally, while still making it difficult for an off-
path attacker to predict the ephemeral ports used for future
connections.
3. Randomizing the Ephemeral Ports Another possible approach to minimize the rate of collisions of
connection-id's would be for both end-points of a TCP connection to
keep state about recent connections (e.g., have both end-points end
up in the TIME-WAIT state).
3.1. Characteristics of a good ephemeral port randomization algorithm 3. Obfuscating the Ephemeral Ports
3.1. Characteristics of a good ephemeral port obfuscation algorithm
There are a number of factors to consider when designing a policy of There are a number of factors to consider when designing a policy of
selection of ephemeral ports, which include: selection of ephemeral ports, which include:
o Minimizing the predictability of the ephemeral port numbers used o Minimizing the predictability of the ephemeral port numbers used
for future connections. for future connections.
o Minimizing collisions of connection-id's o Minimizing collisions of connection-id's
o Avoiding conflict with applications that depend on the use of o Avoiding conflict with applications that depend on the use of
specific port numbers. specific port numbers.
Given the goal of improving the transport protocol's resistance to Given the goal of improving the transport protocol's resistance to
attack by obfuscation of the five-tuple that identifies a transport- attack by obfuscation of the five-tuple that identifies a transport-
protocol instance, it is key to minimize the predictability of the protocol instance, it is key to minimize the predictability of the
ephemeral ports that will be selected for new connections. While the ephemeral ports that will be selected for new connections. While the
obvious approach to address this requirement would be to select the obvious approach to address this requirement would be to select the
ephemeral ports by simply picking a random value within the chosen ephemeral ports by simply picking a random value within the chosen
port number range, this straightforward policy may lead to collisions port number range, this straightforward policy may lead to collisions
of connection-id's, which could lead to the interoperability problems of connection-id's, which could lead to the interoperability problems
discussed in Section 2.3. As discussed in Section 1, it is worth (namely delays in the establishment of new connections, failures in
noting that while the technique of mitigating "blind" attacks by connection-establishment, or data curruption) discussed in
obfuscating the ephemeral port election is well-known as "port Section 2.3. As discussed in Section 1, it is worth noting that
randomization", the goal of the algorithms described in this document while the technique of mitigating "blind" attacks by obfuscating the
is to reduce the chances of an attacker guessing the ephemeral ports ephemeral port election is well-known as "port randomization", the
selected for new connections, rather than to actually produce goal of the algorithms described in this document is to reduce the
sequences of random ephemeral ports. chances of an attacker guessing the ephemeral ports selected for new
connections, rather than to actually produce sequences of
mathematically random ephemeral port numbers.
It is also worth noting that, provided adequate algorithms are in It is also worth noting that, provided adequate algorithms are in
use, the larger the range from which ephemeral pots are selected, the use, the larger the range from which ephemeral pots are selected, the
smaller the chances of an attacker are to guess the selected port smaller the chances of an attacker are to guess the selected port
number. number.
In scenarios in which a specific client establishes connections with In scenarios in which a specific client establishes connections with
a specific service at a server, the problems described in Section 2.3 a specific service at a server, the problems described in Section 2.3
become evident. A good algorithm to minimize the collisions of become evident. A good algorithm to minimize the collisions of
connection-id's would consider the time a given five-tuple was last connection-id's would consider the time a given five-tuple was last
skipping to change at page 11, line 4 skipping to change at page 11, line 7
ephemeral ports [CPNI-TCP] [I-D.gont-tcp-security]. ephemeral ports [CPNI-TCP] [I-D.gont-tcp-security].
3.2. Ephemeral port number range 3.2. Ephemeral port number range
As mentioned in Section 2.1, the ephemeral port range has As mentioned in Section 2.1, the ephemeral port range has
traditionally consisted of the 49152-65535 range. However, it should traditionally consisted of the 49152-65535 range. However, it should
also include the range 1024-49151 range. also include the range 1024-49151 range.
Since this range includes user-specific server ports, this may not Since this range includes user-specific server ports, this may not
always be possible, though. A possible workaround for this potential always be possible, though. A possible workaround for this potential
problem would be to maintain an array of bits, in which each bit problem would be to maintain a local list of the port numbers that
would correspond to each of the port numbers in the range 1024-65535. should not be allocated as ephemeral ports. Thus, before allocating
A bit set to 0 would indicate that the corresponding port is a port number, the ephemeral port selection function would check this
available for allocation, while a bit set to one would indicate that list, avoiding the allocation of ports that may be needed for
the port is reserved and therefore cannot be allocated. Thus, before specific applications.
allocating a port number, the ephemeral port selection function would
check this array of bits, avoiding the allocation of ports that may
be needed for specific applications.
Transport protocols SHOULD use the largest possible port range, since Transport protocols SHOULD use the largest possible port range, since
this improves the obfuscation provided by randomizing the ephemeral this improves the obfuscation provided by the ephemeral port
ports. selection algorithms.
3.3. Ephemeral Port Randomization Algorithms 3.3. Ephemeral Port Obfuscation Algorithms
Transport protocols SHOULD allocate their ephemeral ports randomly, Transport protocols SHOULD obfuscate the allocatation of their
since this help to mitigate a number of attacks that depend on the ephemeral ports, since this help to mitigate a number of attacks that
attacker's ability to guess or know the five-tuple that identifies depend on the attacker's ability to guess or know the five-tuple that
the transport protocol instance to be attacked. identifies the transport protocol instance to be attacked.
The following subsections describe a number of algorithms that could The following subsections describe a number of algorithms that could
be implemented in order to obfuscate the selection of ephemeral port be implemented in order to obfuscate the selection of ephemeral port
numbers. numbers.
3.3.1. Algorithm 1: Simple port randomization algorithm 3.3.1. Algorithm 1: Simple port randomization algorithm
In order to address the security issues discussed in Section 1 and In order to address the security issues discussed in Section 1 and
Section 2.2, a number of systems have implemented simple ephemeral Section 2.2, a number of systems have implemented simple ephemeral
port number randomization, as follows: port number randomization, as follows:
skipping to change at page 12, line 33 skipping to change at page 12, line 33
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'.
Since the initially chosen port may already be in use with identical Since the initially chosen port may already be in use with identical
IP addresses and server port, the resulting five-tuple might not be IP addresses and server port, the resulting five-tuple might not be
unique. Therefore, multiple ports may have to be tried and verified unique. Therefore, multiple ports may have to be tried and verified
against all existing connections before a port can be chosen. against all existing connections before a port can be chosen.
Although carefully chosen random sources and optimized five-tuple
lookup mechanisms (e.g., optimized through hashing) will mitigate the
cost of this verification, some systems may still not want to incur
this search time.
Systems that may be especially susceptible to this kind of repeated Web proxy servers, NAPTs [RFC2663], and other middle-boxes aggregate
five-tuple collisions are those that create many connections from a multiple peers into the same port space and thus increse the
single local IP address to a single service (i.e. both of the IP population of used ephemeral ports, and hence the chances of
addresses and the server port are fixed). Web proxy servers and collisions of connection-id's. However, [Allman] has shown that at
NAPTs [RFC2663] are an examples of such systems. least in the network scenarios used for measuring the collision
properties of the algorithms described in this document, the
collision rate resulting from the use of the aforementioned middle-
boxes is nevertheless very low.
Since this algorithm performs a completely random port selection Since this algorithm performs a completely random port selection
(i.e., without taking into account the port numbers previously (i.e., without taking into account the port numbers previously
chosen), it has the potential of reusing port numbers too quickly, chosen), it has the potential of reusing port numbers too quickly,
thus possibly leading to collisions of connection-id's. Even if a thus possibly leading to collisions of connection-id's. Even if a
given five-tuple is verified to be unique by the port selection given five-tuple is verified to be unique by the port selection
algorithm, the five-tuple might still be in use at the remote system. algorithm, the five-tuple might still be in use at the remote system.
In such a scenario, the connection request could possibly fail In such a scenario, the connection request could possibly fail
([Silbersack] describes this problem for the TCP case). ([Silbersack] describes this problem for the TCP case).
skipping to change at page 13, line 34 skipping to change at page 13, line 32
return next_ephemeral; return next_ephemeral;
next_ephemeral = min_ephemeral + (random() % num_ephemeral); next_ephemeral = min_ephemeral + (random() % num_ephemeral);
count--; count--;
} while (count > 0); } while (count > 0);
return ERROR; return ERROR;
Figure 3 Figure 3
We will refer to this algorithm as 'Algorithm 2'. The difference We will refer to this algorithm as 'Algorithm 2'. This algorithm
between this algorithm and Algorithm 1 is that the search time for might be unable to select an ephemeral port (i.e., return "ERROR")
this variant may be longer than for the latter, particularly when even if there are port numbers that would result in unique five-
there is a large number of port numbers already in use. Also, this tuples, when there are a large number of port numbers already in use.
algorithm may be unable to select an ephemeral port (i.e., return However, the results in [Allman] have shown that in common scenarios,
"ERROR") even if there are port numbers that would result in unique one port choice is enough, and in most cases where more than one
five-tuples, particularly when there are a large number of port choice is needed two choices suffice. Therefore, in those scenarios
numbers already in use. this would not be problem.
3.3.3. Algorithm 3: Simple hash-based algorithm 3.3.3. Algorithm 3: Simple hash-based algorithm
We would like to achieve the port reuse properties of the traditional We would like to achieve the port reuse properties of the traditional
BSD port selection algorithm, while at the same time achieve the BSD port selection algorithm (described in Section 2.2), while at the
obfuscation properties of Algorithm 1 and Algorithm 2. same time achieve the obfuscation properties of Algorithm 1 and
Algorithm 2.
Ideally, we would like a 'next_ephemeral' value for each set of Ideally, we would like a 'next_ephemeral' value for each set of
(local IP address, remote IP addresses, remote port), so that the (local IP address, remote IP addresses, remote port), so that the
port reuse frequency is the lowest possible. Each of these port reuse frequency is the lowest possible. Each of these
'next_ephemeral' variables should be initialized with random values 'next_ephemeral' variables should be initialized with random values
within the ephemeral port range and would thus separate the ephemeral within the ephemeral port range and would thus separate the ephemeral
port ranges of the connections entirely. Since we do not want to port ranges of the connections entirely. Since we do not want to
maintain in memory all these 'next_ephemeral' values, we propose an maintain in memory all these 'next_ephemeral' values, we propose an
offset function F(), that can be computed from the local IP address, offset function F(), that can be computed from the local IP address,
remote IP address, remote port and a secret key. F() will yield remote IP address, remote port and a secret key. F() will yield
skipping to change at page 15, line 7 skipping to change at page 15, line 7
The function F() should be a cryptographic hash function like MD5 The function F() should be a cryptographic hash function like MD5
[RFC1321]. The function should use both IP addresses, the remote [RFC1321]. The function should use both IP addresses, the remote
port and a secret key value to compute the offset. The remote IP port and a secret key value to compute the offset. The remote IP
address is the primary separator and must be included in the offset address is the primary separator and must be included in the offset
calculation. The local IP address and remote port may in some cases calculation. The local IP address and remote port may in some cases
be constant and not improve the connection separation, however, they be constant and not improve the connection separation, however, they
should also be included in the offset calculation. 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 port randomization is simply an obfuscation necessary, given that Algorithm #3 is simply an obfuscation
technique. The secret should be chosen as random as possible, see technique. The secret should be chosen as random as possible, see
[RFC4086] for recommendations on choosing secrets. [RFC4086] for recommendations on choosing secrets.
Note that on multiuser systems, the function F() could include user Note that on multiuser systems, the function F() could include user
specific information, thereby providing protection not only on a host specific information, thereby providing protection not only on a host
to host basis, but on a user to service basis. In fact, any to host basis, but on a user to service basis. In fact, any
identifier of the remote entity could be used, depending on identifier of the remote entity could be used, depending on
availability an the granularity requested. With SCTP both hostnames availability an 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
skipping to change at page 15, line 47 skipping to change at page 15, line 47
It should be note that, as this algorithm uses a global counter It should be note that, as this algorithm uses a global counter
("next_ephemeral") for selecting ephemeral ports, if an attacker ("next_ephemeral") for selecting ephemeral ports, if an attacker
could force a client to periodically establish a new TCP connection could force a client to periodically establish a new TCP connection
to an attacker controlled machine (or through an attacker observable to an attacker controlled machine (or through an attacker observable
routing path), the attacker could subtract consecutive source port routing path), the attacker could subtract consecutive source port
values to obtain the number of outoing TCP connections established values to obtain the number of outoing TCP connections established
globally by the target host within that time period (up to wrap- globally by the target host within that time period (up to wrap-
around issues and 5-tuple collisions, of course). around issues and 5-tuple collisions, of course).
3.3.4. Algorithm 4: Double-hash randomization algorithm 3.3.4. Algorithm 4: Double-hash obfuscation algorithm
A tradeoff between maintaining a single global 'next_ephemeral' A tradeoff between maintaining a single global 'next_ephemeral'
variable and maintaining 2**N 'next_ephemeral' variables (where N is variable and maintaining 2**N 'next_ephemeral' variables (where N is
the width of of the result of F()) could be achieved as follows. The the width of of the result of F()) could be achieved as follows. The
system would keep an array of TABLE_LENGTH short integers, which system would keep an array of TABLE_LENGTH short integers, which
would provide a separation of the increment of the 'next_ephemeral' would provide a separation of the increment of the 'next_ephemeral'
variable. This improvement could be incorporated into Algorithm 3 as variable. This improvement could be incorporated into Algorithm 3 as
follows: follows:
/* Initialization at system boot time */ /* Initialization at system boot time */
skipping to change at page 16, line 36 skipping to change at page 16, line 36
count--; count--;
} while (count > 0); } while (count > 0);
return ERROR; return ERROR;
Figure 5 Figure 5
We will refer to this algorithm as 'Algorithm 4'. We will refer to this algorithm as 'Algorithm 4'.
'table[]' could be initialized with random values, as indicated by 'table[]' could be initialized with mathematically random values, as
the initialization code in Figure 5. The function G() should be a indicated by the initialization code in Figure 5. The function G()
cryptographic hash function like MD5 [RFC1321]. It should use both should be a cryptographic hash function like MD5 [RFC1321]. It
IP addresses, the remote port and a secret key value to compute a should use both IP addresses, the remote port and a secret key value
value between 0 and (TABLE_LENGTH-1). Alternatively, G() could take to compute a value between 0 and (TABLE_LENGTH-1). Alternatively,
as "offset" as input, and perform the exclusive-or (xor) operation G() could take as "offset" as input, and perform the exclusive-or
between all the bytes in 'offset'. (xor) operation between all the bytes in 'offset'.
The array 'table[]' assures that succesive connections to the same The array 'table[]' assures that succesive connections to the same
end-point will use increasing ephemeral port numbers. However, end-point will use increasing ephemeral port numbers. However,
incrementation of the port numbers is separated into TABLE_LENGTH incrementation of the port numbers is separated into TABLE_LENGTH
different spaces, and thus the port reuse frequency will be different spaces, and thus the port reuse frequency will be
(probabilistically) lower than that of Algorithm 3. That is, a (probabilistically) lower than that of Algorithm 3. That is, a
connection established with some remote end-point will not connection established with some remote end-point will not
necessarily cause the 'next_ephemeral' variable corresponding to necessarily cause the 'next_ephemeral' variable corresponding to
other end-points to be incremented. other end-points to be incremented.
It is interesting to note that the size of 'table[]' does not limit It is interesting to note that the size of 'table[]' does not limit
the number of different port sequences, but rather separates the the number of different port sequences, but rather separates the
*increments* into TABLE_LENGTH different spaces. The port sequence *increments* into TABLE_LENGTH different spaces. The port sequence
will result from adding the corresponding entry of 'table[]' to the will result from adding the corresponding entry of 'table[]' to the
variable 'offset', which selects the actual port sequence (as in variable 'offset', which selects the actual port sequence (as in
Algorithm 3). [Allman] has found that even a TABLE_LENGTH of 10 can Algorithm 3). [Allman] has found that a TABLE_LENGTH of 10 can
result in an improvement over Algorithm 3. Considering the amount of result in an improvement over Algorithm 3. Further increasing the
memory available in most general-purpose systems recommend a TABLE_LENGTH will increase the obfuscation, and possibly further
TABLE_LENGTH of 1024 for such systems, but note that other systems decrease the collision rate.
may choose smaller values for TABLE_LENGTH.
An attacker can perform traffic analysis for any "increment space" An attacker can perform traffic analysis for any "increment space"
into which the attacker has "visibility", namely that the attacker into which the attacker has "visibility", namely that the attacker
can force the client to establish a transport-protocol connection can force the client to establish a transport-protocol connection
whose G(offset) identifies the target "increment space". However, whose G(offset) identifies the target "increment space". However,
the attacker's ability to perform traffic analysis is very reduced the attacker's ability to perform traffic analysis is very reduced
when compared to the traditional BSD algorithm and Algorithm 3. when compared to the traditional BSD algorithm (described in
Additionally, an implementation can further limit the attacker's Section 2.2) and Algorithm 3. Additionally, an implementation can
ability to perform traffic analysis by further separating the further limit the attacker's ability to perform traffic analysis by
increment space (that is, using a larger value for TABLE_LENGTH). further separating the increment space (that is, using a larger value
for TABLE_LENGTH).
3.3.5. Algorithm 5: Random-increments port selection algorithm 3.3.5. Algorithm 5: Random-increments port selection algorithm
[Allman] introduced yet another port randomization selection, which [Allman] introduced another port obfuscation algorithm, which offers
offers a middle ground between the algorithms that select ephemeral a middle ground between the algorithms that select ephemeral ports
ports randomly (such as those described in Section 3.3.1 and randomly (such as those described in Section 3.3.1 and
Section 3.3.2), and those that offer obfuscation but no randomization Section 3.3.2), and those that offer obfuscation but no randomization
(such as those described in Section 3.3.3 and Section 3.3.4). We (such as those described in Section 3.3.3 and Section 3.3.4). We
will refer to this algorithm as 'Algorithm 5'. will refer to this algorithm as 'Algorithm 5'.
/* Initialization code at system boot time. */ /* Initialization code at system boot time. */
next_ephemeral = 0; /* Initialization value could be random. */ next_ephemeral = random() % 65536; /* Initialization value */
N = 500; /* Determines the tradeoff. Should be configurable */ N = 500; /* Determines the tradeoff (configurable) */
/* Ephemeral port selection function */ /* Ephemeral port selection function */
num_ephemeral = max_ephemeral - min_ephemeral + 1; num_ephemeral = max_ephemeral - min_ephemeral + 1;
next_ephemeral = next_ephemeral + random(N);
count = num_ephemeral; count = num_ephemeral;
do { do {
next_ephemeral = next_ephemeral + (random() % N) + 1;
port = min_ephemeral + (next_ephemeral % num_ephemeral); port = min_ephemeral + (next_ephemeral % num_ephemeral);
if(five-tuple is unique) if(five-tuple is unique)
return port; return port;
next_ephemeral++;
count--; count--;
} while (count > 0); } while (count > 0);
return ERROR; return ERROR;
Figure 6 Figure 6
The value "N" allows for direct control of the tradeoff between the This algorithm aims at at producing a monotonically-increasing
level of obfuscation and the port reuse frequency. The larger the sequence to prevent the collision of connection-id's, while avoiding
value of "N", the more similar this algorithm is to the algorithm the use of fixed increments, which would lead to trivially-
described in Section 3.3.1 of this document. predictable sequences. The value "N" allows for direct control of
the tradeoff between the level of obfuscation and the port reuse
frequency. The smaller the value of "N", the more linear the more
similar this algorithm is to the traditioanl BSD port selection
algorithm (described in Section 2.2. The larger the value of "N",
the more similar this algorithm is to the algorithm described in
Section 3.3.1 of this document.
3.4. Secret-key considerations for hash-based port randomization When the port numbers wrap, there's the risk of collisions of
connection-id's. Therefore, "N" should be selecting according to the
following criteria:
o It should maximize the wrapping time of the ephemeral port space
o It should minimize collisions of connection-id's
o It should maximize obfuscation
Clearly, these are competing goals, and the decision of which value
of "N" to use is a tradeoff. Therefore, the value of "N" should be
configurable so that system administrators can make the tradeoff for
themselves.
3.4. Secret-key considerations for hash-based port obfuscation
algorithms algorithms
Every complex manipulation (like MD5) is no more secure than the Every complex manipulation (like MD5) is no more secure than the
input values, and in the case of ephemeral ports, the secret key. If input values, and in the case of ephemeral ports, the secret key. If
an attacker is aware of which cryptographic hash function is being an attacker is aware of which cryptographic hash function is being
used by the victim (which we should expect), and the attacker can used by the victim (which we should expect), and the attacker can
obtain enough material (e.g. ephemeral ports chosen by the victim), obtain enough material (e.g. ephemeral ports chosen by the victim),
the attacker may simply search the entire secret key space to find the attacker may simply search the entire secret key space to find
matches. matches.
skipping to change at page 19, line 35 skipping to change at page 20, line 5
o There are few active connections (i.e., possibility of collision o There are few active connections (i.e., possibility of collision
is low). is low).
o There is little traffic (the performance overhead of collisions is o There is little traffic (the performance overhead of collisions is
tolerated). tolerated).
o There is enough random data available to change the secret key o There is enough random data available to change the secret key
(pseudo-random changes should not be done). (pseudo-random changes should not be done).
3.5. Choosing an ephemeral port randomization algorithm 3.5. Choosing an ephemeral port obfuscation algorithm
[Allman] is an empyrical study of the properties of the algorithms [Allman] is an empyrical study of the properties of the algorithms
described in this document, which has found that all the algorithms described in this document, which has found that all the algorithms
described in this document offer low collision rates -- at most 0.3%. described in this document offer low collision rates -- at most 0.3%.
However, these results may vary depending on the characteristics of That is, in those network scenarios asessed by [Allman] all of the
network traffic and the pecfic network setup. algorithms described in this document perform good in terms of
collisions of connection-id's. However, these results may vary
depending on the characteristics of network traffic and the specific
network setup.
The algorithm sketched in Figure 1 is the traditional ephemeral port The algorithm sketched in Figure 1 is the traditional ephemeral port
selection algorithm implemented in BSD-derived systems. It generates selection algorithm implemented in BSD-derived systems. It generates
a global sequence of ephemeral port numbers, which makes it trivial a global sequence of ephemeral port numbers, which makes it trivial
for an attacker to predict the port number that will be used for a for an attacker to predict the port number that will be used for a
future transport protocol instance. However, it is very simple, and future transport protocol instance. However, it is very simple, and
leads to a low port resuse frequency. leads to a low port resuse frequency.
Algorithm 1 and Algorithm 2 have the advantage that they provide Algorithm 1 and Algorithm 2 have the advantage that they provide
complete randomization. However, they may increase the chances of complete randomization. However, they may increase the chances of
skipping to change at page 22, line 5 skipping to change at page 22, line 5
described. described.
An alternative to this behavior would be to implement "lazy binding" An alternative to this behavior would be to implement "lazy binding"
in response to the bind() call. That is, selection of an epphemeral in response to the bind() call. That is, selection of an epphemeral
port would be delayed until, e.g., connect() or send() are called. port would be delayed until, e.g., connect() or send() are called.
Thus, at that point the ephemeral port is actually selected, all the Thus, at that point the ephemeral port is actually selected, all the
necessary arguments for the hash function F() would be available, and necessary arguments for the hash function F() would be available, and
thus Algorithm 3 and Algorithm 4 could still be used in this thus Algorithm 3 and Algorithm 4 could still be used in this
scenario. This policy has been implemented by Linux [Linux]. scenario. This policy has been implemented by Linux [Linux].
4. Port randomization and Network Address Port Translation (NAPT) 4. Port obfuscation and Network Address Port Translation (NAPT)
Network Address Port Translation (NAPT) translate both the network Network Address Port Translation (NAPT) translate both the network
address and transport-protocol port number, thus allowing the address and transport-protocol port number, thus allowing the
transport identifiers of a number of private hosts to be multiplexed transport identifiers of a number of private hosts to be multiplexed
into the transport identifiers of a single external address. into the transport identifiers of a single external address.
[RFC2663] [RFC2663]
In those scenarios in which a NAPT is present between the two end- In those scenarios in which a NAPT is present between the two end-
points of transport-protocol connection, the obfuscation of the points of transport-protocol connection, 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 randomizing the ephemeral ports by Therefore, NAPTs should consider obfuscating the ephemeral ports by
means of any of the algorithms discussed in this document. It should means of any of the algorithms discussed in this document. It should
be noted that in some network scenarios, a NAPT may naturally obscure be noted that in some network scenarios, a NAPT may naturally obscure
ephemeral port selections simply due to the vast range of services ephemeral port selections simply due to the vast range of services
with which it establishes connections and to the overall rate of the with which it establishes connections and to the overall rate of the
traffic [Allman]. traffic [Allman].
Section 3.5 provides guidance in choosing a port randomization Section 3.5 provides guidance in choosing a port obfuscation
algorithm. algorithm.
5. Security Considerations 5. Security Considerations
Randomizing ports is no replacement for cryptographic mechanisms, Obfuscating ephemeral ports is no replacement for cryptographic
such as IPsec [RFC4301], in terms of protecting transport protocol mechanisms, such as IPsec [RFC4301], in terms of protecting transport
instances against blind attacks. protocol instances against blind attacks.
An eavesdropper, which can monitor the packets that correspond to the An eavesdropper, which can monitor the packets that correspond to the
connection to be attacked could learn the IP addresses and port connection to be attacked could learn the IP addresses and port
numbers in use (and also sequence numbers etc.) and easily attack the numbers in use (and also sequence numbers etc.) and easily attack the
connection. Randomizing ports does not provide any additional connection. Ephemeral port obfuscation does not provide any
protection against this kind of attacks. In such situations, proper additional protection against this kind of attacks. In such
authentication mechanisms such as those described in [RFC4301] should situations, proper authentication mechanisms such as those described
be used. in [RFC4301] should be used.
If the local offset function F() results in identical offsets for If the local offset function F() results in identical offsets for
different inputs, the port-offset mechanism proposed in this document different inputs, the port-offset mechanism proposed in this document
has no or reduced effect. has no or reduced effect.
If random numbers are used as the only source of the secret key, they If random numbers are used as the only source of the secret key, they
must be chosen in accordance with the recommendations given in must be chosen in accordance with the recommendations given in
[RFC4086]. [RFC4086].
If an attacker uses dynamically assigned IP addresses, the current If an attacker uses dynamically assigned IP addresses, the current
skipping to change at page 24, line 14 skipping to change at page 24, line 14
6. Acknowledgements 6. Acknowledgements
The offset function was inspired by the mechanism proposed by Steven The offset function was inspired by the mechanism proposed by Steven
Bellovin in [RFC1948] for defending against TCP sequence number Bellovin in [RFC1948] for defending against TCP sequence number
attacks. attacks.
The authors would like to thank (in alphabetical order) Mark Allman, The authors would like to thank (in alphabetical order) Mark Allman,
Matthias Bethke, Stephane Bortzmeyer, Brian Carpenter, Vincent Matthias Bethke, Stephane Bortzmeyer, Brian Carpenter, Vincent
Deffontaines, Lars Eggert, Gorry Fairhurst, Guillermo Gont, Alfred Deffontaines, Lars Eggert, Gorry Fairhurst, Guillermo Gont, Alfred
Hoenes, Amit Klein, Carlos Pignataro, Joe Touch, and Dan Wing for Hoenes, Amit Klein, Carlos Pignataro, Kacheong Poon, Joe Touch, and
their valuable feedback on earlier versions 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.
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.
7. References 7. References
7.1. Normative References 7.1. Normative References
skipping to change at page 26, line 14 skipping to change at page 26, line 14
7.2. Informative References 7.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-04 (work in progress), draft-ietf-tcpm-icmp-attacks-05 (work in progress),
October 2008. June 2009.
[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.
[RFC4953] Touch, J., "Defending TCP Against Spoofing Attacks", [RFC4953] Touch, J., "Defending TCP Against Spoofing Attacks",
RFC 4953, July 2007. RFC 4953, July 2007.
[Allman] Allman, M., "Comments On Selecting Ephemeral Ports", [Allman] Allman, M., "Comments On Selecting Ephemeral Ports", ACM
Available at: Computer Communicatiion Review, 39(2), 2009.
http://www.icir.org/mallman/papers/ports-ccr09.pdf.
[CPNI-TCP] [CPNI-TCP]
Gont, F., "CPNI Technical Note 3/2009: Security Assessment Gont, F., "CPNI Technical Note 3/2009: Security Assessment
of the Transmission Control Protocol (TCP)", UK Centre of the Transmission Control Protocol (TCP)", UK Centre
for the Protection of National Infrastructure, 2009. for the Protection of National Infrastructure, 2009.
[I-D.gont-tcp-security] [I-D.gont-tcp-security]
Gont, F., "Security Assessment of the Transmission Control Gont, F., "Security Assessment of the Transmission Control
Protocol (TCP)", draft-gont-tcp-security-00 (work in Protocol (TCP)", draft-gont-tcp-security-00 (work in
progress), February 2009. progress), February 2009.
[Linux] The Linux Project, "http://www.kernel.org". [Linux] The Linux Project, "http://www.kernel.org".
[NetBSD] The NetBSD Project, "http://www.netbsd.org". [NetBSD] The NetBSD Project, "http://www.netbsd.org".
[OpenBSD] The OpenBSD Project, "http://www.openbsd.org". [OpenBSD] The OpenBSD Project, "http://www.openbsd.org".
[OpenSolaris]
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] [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
skipping to change at page 28, line 21 skipping to change at page 28, line 21
uses a 'min_port' of 10000 and a 'max_port' of 65535. [FreeBSD] uses a 'min_port' of 10000 and a 'max_port' of 65535. [FreeBSD]
A.2. Linux A.2. Linux
Linux implements Algorithm 3. If the algorithm is faced with the Linux implements Algorithm 3. If the algorithm is faced with the
corner-case scenario described in Section 3.5, Algorithm 1 is used corner-case scenario described in Section 3.5, Algorithm 1 is used
instead [Linux]. instead [Linux].
A.3. NetBSD A.3. NetBSD
NetBSD does not randomize ephemeral port numbers. It selects NetBSD does not obfuscate its ephemeral port numbers. It selects
ephemeral port numbers from the range 49152-65535, starting from port ephemeral port numbers from the range 49152-65535, starting from port
65535, and decreasing the port number for each ephemeral port number 65535, and decreasing the port number for each ephemeral port number
selected [NetBSD]. selected [NetBSD].
A.4. OpenBSD A.4. OpenBSD
OpenBSD implements Algorithm 1, with a 'min_port' of 1024 and a OpenBSD implements Algorithm 1, with a 'min_port' of 1024 and a
'max_port' of 49151. [OpenBSD] 'max_port' of 49151. [OpenBSD]
Appendix B. Changes from previous versions of the draft A.5. OpenSolaris
B.1. Changes from draft-ietf-tsvwg-port-randomization-02 OpenSolaris implements Algorithm 1, with a 'min_port' of 32768 and a
'max_port' of 65535. [OpenSolaris]
Appendix B. Changes from previous versions of the draft (to be removed
by the RFC Editor before publication of this document as a
RFC
B.1. Changes from draft-ietf-tsvwg-port-randomization-03
o Addresses WGLC comments from Mark Allman. See:
http://www.ietf.org/mail-archive/web/tsvwg/current/msg09149.html
B.2. 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.2. Changes from draft-ietf-tsvwg-port-randomization-01 B.3. 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.3. Changes from draft-ietf-tsvwg-port-randomization-00 B.4. 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.4. Changes from draft-larsen-tsvwg-port-randomization-02 B.5. 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.5. Changes from draft-larsen-tsvwg-port-randomization-01 B.6. Changes from draft-larsen-tsvwg-port-randomization-01
o No changes. Draft resubmitted after expiration. o No changes. Draft resubmitted after expiration.
B.6. Changes from draft-larsen-tsvwg-port-randomization-00 B.7. Changes from draft-larsen-tsvwg-port-randomization-00
o Fixed a bug in expressions used to calculate number of ephemeral o Fixed a bug in expressions used to calculate number of ephemeral
ports ports
o Added a survey of the algorithms in use by popular TCP o Added a survey of the algorithms in use by popular TCP
implementations implementations
o The whole document was reorganizaed o The whole document was reorganizaed
o Miscellaneous editorial changes o Miscellaneous editorial changes
B.7. Changes from draft-larsen-tsvwg-port-randomisation-00 B.8. 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. 55 change blocks. 
126 lines changed or deleted 175 lines changed or added

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