draft-ietf-tsvwg-port-randomization-02.txt   draft-ietf-tsvwg-port-randomization-03.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: March 4, 2009 August 31, 2008 Expires: September 12, 2009 March 11, 2009
Port Randomization Port Randomization
draft-ietf-tsvwg-port-randomization-02 draft-ietf-tsvwg-port-randomization-03
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any This Internet-Draft is submitted to IETF in full conformance with the
applicable patent or other IPR claims of which he or she is aware provisions of BCP 78 and BCP 79.
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of 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.
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."
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 March 4, 2009. This Internet-Draft will expire on September 12, 2009.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract Abstract
Recently, awareness has been raised about a number of "blind" attacks Recently, awareness has been raised about a number of "blind" attacks
that can be performed against the Transmission Control Protocol (TCP) that can be performed against the Transmission Control Protocol (TCP)
and similar protocols. The consequences of these attacks range from and similar protocols. The consequences of these attacks range from
throughput-reduction to broken connections or data corruption. These throughput-reduction to broken connections or data corruption. These
attacks rely on the attacker's ability to guess or know the five- attacks rely on the attacker's ability to guess or know the five-
tuple (Protocol, Source Address, Destination Address, Source Port, tuple (Protocol, Source Address, Destination Address, Source Port,
Destination Port) that identifies the transport protocol instance to Destination Port) that identifies the transport protocol instance to
be attacked. This document describes a number of simple and be attacked. This document describes a number of simple and
efficient methods for the random selection of the client port number, efficient methods for the selection of the client port number, such
such that the possibility of an attacker guessing the exact value is that the possibility of an attacker guessing the exact value is
reduced. While this is not a replacement for cryptographic methods, reduced. While this is not a replacement for cryptographic methods
the described port number randomization algorithms provide improved for protecting the connection, the described port number obfuscation
security/obfuscation with very little effort and without any key algorithms provide improved security/obfuscation with very little
management overhead. The algorithms described in this document are effort and without any key management overhead. The algorithms
local policies that may be incrementally deployed, and that do not described in this document are local policies that may be
violate the specifications of any of the transport protocols that may incrementally deployed, and that do not violate the specifications of
benefit from them, such as TCP, UDP, UDP-lite, SCTP, DCCP, and RTP. any of the transport protocols that may benefit from them, such as
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. Randomizing the Ephemeral Ports . . . . . . . . . . . . . . . 9
3.1. Characteristics of a good ephemeral port randomization 3.1. Characteristics of a good ephemeral port randomization
algorithm . . . . . . . . . . . . . . . . . . . . . . . . 9 algorithm . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2. Ephemeral port number range . . . . . . . . . . . . . . . 10 3.2. Ephemeral port number range . . . . . . . . . . . . . . . 10
3.3. Ephemeral Port Randomization Algorithms . . . . . . . . . 10 3.3. Ephemeral Port Randomization Algorithms . . . . . . . . . 11
3.3.1. Algorithm 1: Simple port randomization algorithm . . . 10 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 . . . . . . . . . . . . . . . . . . . . . . 12 algorithm . . . . . . . . . . . . . . . . . . . . . . 13
3.3.3. Algorithm 3: Simple hash-based algorithm . . . . . . . 12 3.3.3. Algorithm 3: Simple hash-based algorithm . . . . . . . 13
3.3.4. Algorithm 4: Double-hash randomization algorithm . . . 14 3.3.4. Algorithm 4: Double-hash randomization algorithm . . . 15
3.3.5. Algorithm 5: Random-increments port selection
algorithm . . . . . . . . . . . . . . . . . . . . . . 17
3.4. Secret-key considerations for hash-based port 3.4. Secret-key considerations for hash-based port
randomization algorithms . . . . . . . . . . . . . . . . . 16 randomization algorithms . . . . . . . . . . . . . . . . . 18
3.5. Choosing an ephemeral port randomization algorithm . . . . 17 3.5. Choosing an ephemeral port randomization algorithm . . . . 19
4. Port randomization and Network Address Port Translation 4. Port randomization and Network Address Port Translation
(NAPT) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 (NAPT) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
5. Security Considerations . . . . . . . . . . . . . . . . . . . 20 5. Security Considerations . . . . . . . . . . . . . . . . . . . 23
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25
7.1. Normative References . . . . . . . . . . . . . . . . . . . 22 7.1. Normative References . . . . . . . . . . . . . . . . . . . 25
7.2. Informative References . . . . . . . . . . . . . . . . . . 23 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 . . . . . . . . . . . . . . . . . . . 24 implementations . . . . . . . . . . . . . . . . . . . 28
A.1. FreeBSD . . . . . . . . . . . . . . . . . . . . . . . . . 24 A.1. FreeBSD . . . . . . . . . . . . . . . . . . . . . . . . . 28
A.2. Linux . . . . . . . . . . . . . . . . . . . . . . . . . . 24 A.2. Linux . . . . . . . . . . . . . . . . . . . . . . . . . . 28
A.3. NetBSD . . . . . . . . . . . . . . . . . . . . . . . . . . 24 A.3. NetBSD . . . . . . . . . . . . . . . . . . . . . . . . . . 28
A.4. OpenBSD . . . . . . . . . . . . . . . . . . . . . . . . . 24 A.4. OpenBSD . . . . . . . . . . . . . . . . . . . . . . . . . 28
Appendix B. Changes from previous versions of the draft . . . . . 25 Appendix B. Changes from previous versions of the draft . . . . . 29
B.1. Changes from draft-ietf-tsvwg-port-randomization-01 . . . 25 B.1. Changes from draft-ietf-tsvwg-port-randomization-02 . . . 29
B.2. Changes from draft-ietf-tsvwg-port-randomization-00 . . . 25 B.2. Changes from draft-ietf-tsvwg-port-randomization-01 . . . 29
B.3. Changes from draft-larsen-tsvwg-port-randomization-02 . . 25 B.3. Changes from draft-ietf-tsvwg-port-randomization-00 . . . 29
B.4. Changes from draft-larsen-tsvwg-port-randomization-01 . . 25 B.4. Changes from draft-larsen-tsvwg-port-randomization-02 . . 29
B.5. Changes from draft-larsen-tsvwg-port-randomization-00 . . 25 B.5. Changes from draft-larsen-tsvwg-port-randomization-01 . . 29
B.6. Changes from draft-larsen-tsvwg-port-randomisation-00 . . 26 B.6. Changes from draft-larsen-tsvwg-port-randomization-00 . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27 B.7. Changes from draft-larsen-tsvwg-port-randomisation-00 . . 30
Intellectual Property and Copyright Statements . . . . . . . . . . 28 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
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 4, line 33 skipping to change at page 4, line 33
the server IP address and service port number. The IP address and the server IP address and service port number. The IP address and
port number of the client are normally left unspecified by the client port number of the client are normally left unspecified by the client
application and thus chosen automatically by the client networking application and thus chosen automatically by the client networking
stack. Ports chosen automatically by the networking stack are known stack. Ports chosen automatically by the networking stack are known
as ephemeral ports [Stevens]. as ephemeral ports [Stevens].
While the server IP address and well-known port and the client IP While the server IP address and well-known port and the client IP
address may be accurately guessed by an attacker, the ephemeral port address may be accurately guessed by an attacker, the ephemeral port
of the client is usually unknown and must be guessed. of the client is usually unknown and must be guessed.
This document describes a number of algorithms for random selection This document describes a number of algorithms for the selection of
of the client ephemeral port, that reduce the possibility of an off- the ephemeral ports, such that the possibility of an off-path
path attacker guessing the exact value. They are not a replacement attacker guessing the exact value is reduced. They are not a
for cryptographic methods of protecting a connection such as IPsec replacement for cryptographic methods of protecting a connection such
[RFC4301], the TCP MD5 signature option [RFC2385], or the TCP as IPsec [RFC4301], the TCP MD5 signature option [RFC2385], or the
Authentication Option [I-D.ietf-tcpm-tcp-auth-opt]. For example, TCP Authentication Option [I-D.ietf-tcpm-tcp-auth-opt]. For example,
they do not provide any mitigation in those scenarios in which the they do not provide any mitigation in those scenarios in which the
attacker is able to sniff the packets that correspond to the attacker is able to sniff the packets that correspond to the
transport protocol connection to be attacked. However, the proposed transport protocol connection to be attacked. However, the proposed
algorithms provide improved obfuscation with very little effort and algorithms provide improved obfuscation with very little effort and
without any key management overhead. without any key management overhead.
The mechanisms described in this document are local modifications The mechanisms described in this document are local modifications
that may be incrementally deployed, and that does not violate the that may be incrementally deployed, and that does not violate the
specifications of any of the transport protocols that may benefit specifications of any of the transport protocols that may benefit
from it, such as TCP [RFC0793], UDP [RFC0768], SCTP [RFC4960], DCCP from 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 data structures. efficient, and not require substantial state.
We note that while the technique of mitigating "blind" attacks by
obfuscating the ephemeral port election is well-known as "port
randomization", the goal of the algorithms described in tihs document
is to reduce the chances of an attacker guessing the ephemeral ports
selected for new connections, rather than to actually produce a
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 35 skipping to change at page 6, line 35
65535 range. 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 operating systems by having a per-protocol tuples is handled by some implementations by having a per-protocol
global 'next_ephemeral' variable that is equal to the previously global 'next_ephemeral' variable that is equal to the previously
chosen ephemeral port + 1, i.e. the selection process is: chosen ephemeral port + 1, i.e. the selection process is:
/* Initialization at system boot time. Initialization value could be random */ /* Initialization at system boot time. Initialization value could be random */
next_ephemeral = min_ephemeral; next_ephemeral = min_ephemeral;
/* Ephemeral port selection function */ /* Ephemeral port selection function */
count = max_ephemeral - min_ephemeral + 1; count = max_ephemeral - min_ephemeral + 1;
do { do {
skipping to change at page 8, line 14 skipping to change at page 8, line 14
still be in use at a remote system. For example, consider a scenario still be in use at a remote system. For example, consider a scenario
in which a client establishes a TCP connection with a remote web in which a client establishes a TCP connection with a remote web
server, and the web server performs the active close on the server, and the web server performs the active close on the
connection. While the state information for this connection will connection. While the state information for this connection will
disappear at the client side (that is, the connection will be moved disappear at the client side (that is, the connection will be moved
to the fictional CLOSED state), the connection-id will remain in the to the fictional CLOSED state), the connection-id will remain in the
TIME-WAIT state at the web server for 2*MSL (Maximum Segment TIME-WAIT state at the web server for 2*MSL (Maximum Segment
Lifetime). If the same client tried to create a new incarnation of Lifetime). If the same client tried to create a new incarnation of
the previous connection (that is, a connection with the same the previous connection (that is, a connection with the same
connection-id as the one in the TIME_WAIT state at the server), a connection-id as the one in the TIME_WAIT state at the server), a
port number "collision" would occur. The effect of these port number connection-id "collision" would occur. The effect of these
collisions range from connection-establishment failures to TIME-WAIT collisions range from connection-establishment failures to TIME-WAIT
state assassination (with the potential of data corruption) state assassination (with the potential of data corruption)
[RFC1337]. In scenarios in which a specific client establishes TCP [RFC1337]. In scenarios in which a specific client establishes TCP
connections with a specific service at a server, these problems connections with a specific service at a server, these problems
become evident. Therefore, an ephemeral port selection algorithm become evident. Therefore, an ephemeral port selection algorithm
should ideally lead to a low port reuse frequency, to reduce the should ideally minimize the rate of connection-id collisions.
chances of port number collisions.
A simple approach to maximize the five-tuple reuse cycle would be to A simple approach to minimize the rate of these collisions would be
choose port numbers incrementally, so that a given port number would to choose port numbers incrementally, so that a given port number
not be reused until the rest of the port numbers in ephemeral port would not be reused until the rest of the port numbers in ephemeral
range have been used for a transport protocol instance. However, if port range have been used for a transport protocol instance.
a single global variable were used to keep track of the last However, if a single global variable were used to keep track of the
ephemeral port selected, ephemeral port numbers would be trivially last ephemeral port selected, ephemeral port numbers would be
predictable, thus making it easier for an off-path attacker to trivially predictable, thus making it easier for an off-path attacker
"guess" the connection-id in use by a target connection. to "guess" the connection-id in use by a target connection.
3. Randomizing the Ephemeral Ports 3. Randomizing the Ephemeral Ports
3.1. Characteristics of a good ephemeral port randomization algorithm 3.1. Characteristics of a good ephemeral port randomization 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 Maximizing the port reuse cycle. 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 a short port number range, this straightforward policy may lead to collisions
reuse cycle of port numbers, which could lead to the interoperability of connection-id's, which could lead to the interoperability problems
problems discussed in Section 2.3. It is also worth noting that, discussed in Section 2.3. As discussed in Section 1, it is worth
provided adequate randomization algorithms are in use, the larger the noting that while the technique of mitigating "blind" attacks by
range from which ephemeral pots are selected, the smaller the chances obfuscating the ephemeral port election is well-known as "port
of an attacker are to guess the selected port number. randomization", the goal of the algorithms described in this document
is to reduce the chances of an attacker guessing the ephemeral ports
selected for new connections, rather than to actually produce
sequences of random ephemeral ports.
It is also worth noting that, provided adequate algorithms are in
use, the larger the range from which ephemeral pots are selected, the
smaller the chances of an attacker are to guess the selected port
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. Therefore, an ephemeral port selection algorithm become evident. A good algorithm to minimize the collisions of
should ideally lead to a low port reuse frequency, to reduce the connection-id's would consider the time a given five-tuple was last
chances of port number collisions. A good algorithm to maximize the
port reuse cycle would consider the time a given five-tuple was last
used, and would avoid reusing the last recently used five-tuples. A used, and would avoid reusing the last recently used five-tuples. A
simple approach to maximize the five-tuple reuse cycle would be to simple approach to minimize the rate of collisions would be to choose
choose port numbers incrementally, so that a given port number would port numbers incrementally, so that a given port number would not be
not be reused until the rest of the port numbers in ephemeral port reused until the rest of the port numbers in the ephemeral port range
range have been used for a transport protocol instance. However, if have been used for a transport protocol instance. However, if a
a single global variable were used to keep track of the last single global variable were used to keep track of the last ephemeral
ephemeral port selected, ephemeral port numbers would be trivially port selected, ephemeral port numbers would be trivially predictable.
predictable.
It is important to note that a number of applications rely on binding It is important to note that a number of applications rely on binding
specific port numbers that may be within the ephemeral ports range. specific port numbers that may be within the ephemeral ports range.
If such an application was run while the corresponding port number If such an application was run while the corresponding port number
was in use, the application would fail. Therefore, transport was in use, the application would fail. Therefore, transport
protocols should avoid using those port numbers as ephemeral ports. protocols should avoid using those port numbers as ephemeral ports.
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
not complied, an attacker could potentially "steal" an incoming
connection to a local server application by issuing a connection
request to the victim client at roughly the same time the client
tries to connect to the victim server application [CPNI-TCP]
[I-D.gont-tcp-security]. If the SYN segment corresponding to the
attacker's connection request and the SYN segment corresponding to
the victim client "cross each other in the network", and provided the
attacker is able to know or guess the ephemeral port used by the
client, a TCP simultaneous open scenario would take place, and the
incoming connection request sent by the client would be matched with
the attacker's socket rather than with the victim server
application's socket.
It should be noted that most applications based on popular
implementations of TCP API (such as the Sockets API) perform "passive
opens" in three steps. Firstly, the application obtains a file
descriptor to be used for inter-process communication (e.g., by
issuing a socket() call). Secondly, the application binds the file
descriptor to a local TCP port number (e.g., by issuing a bind()
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
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
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
allowed to select a port number that would be later used for
listening to incoming connections. Therefore, these implementations
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
the LISTEN or CLOSED states should not be allowed for allocation as
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 an array of bits, in which each bit
would correspond to each of the port numbers in the range 1024-65535. would correspond to each of the port numbers in the range 1024-65535.
skipping to change at page 11, line 38 skipping to change at page 12, line 38
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 Although carefully chosen random sources and optimized five-tuple
lookup mechanisms (e.g., optimized through hashing) will mitigate the lookup mechanisms (e.g., optimized through hashing) will mitigate the
cost of this verification, some systems may still not want to incur cost of this verification, some systems may still not want to incur
this search time. this search time.
Systems that may be specially susceptible to this kind of repeated Systems that may be especially susceptible to this kind of repeated
five-tuple collisions are those that create many connections from a five-tuple collisions are those that create many connections from a
single local IP address to a single service (i.e. both of the IP single local IP address to a single service (i.e. both of the IP
addresses and the server port are fixed). Web proxy servers and addresses and the server port are fixed). Web proxy servers and
NAPTs [RFC2663] are an examples of such systems. NAPTs [RFC2663] are an examples of such systems.
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,
Even if a given five-tuple is verified to be unique by the port thus possibly leading to collisions of connection-id's. Even if a
selection algorithm, the five-tuple might still be in use at the given five-tuple is verified to be unique by the port selection
remote system. In such a scenario, the connection request could algorithm, the five-tuple might still be in use at the remote system.
possibly fail ([Silbersack] describes this problem for the TCP case). In such a scenario, the connection request could possibly fail
Therefore, it is desirable to keep the port reuse frequency as low as ([Silbersack] describes this problem for the TCP case).
possible.
This algorithm selects ephemeral port numbers randomly and thus This algorithm selects ephemeral port numbers randomly and thus
reduces the chances of an attacker of guessing the ephemeral port reduces the chances of an attacker of guessing the ephemeral port
selected for a target connection. Additionally, it prevents selected for a target connection. Additionally, it prevents
attackers from obtaining the number of outgoing connections attackers from obtaining the number of outgoing connections
established by the client in some period of time. established by the client in some period of time.
3.3.2. Algorithm 2: Another simple port randomization algorithm 3.3.2. Algorithm 2: Another simple port randomization algorithm
Another algorithm for selecting a random port number is shown in Another algorithm for selecting a random port number is shown in
skipping to change at page 15, line 15 skipping to change at page 16, line 15
would provide a separation of the increment of the 'next_ephemeral' would provide a separation of the increment of the 'next_ephemeral'
variable. This improvement could be incorporated into Algorithm 3 as variable. This improvement could be incorporated into Algorithm 3 as
follows: follows:
/* Initialization at system boot time */ /* Initialization at system boot time */
for(i = 0; i < TABLE_LENGTH; i++) for(i = 0; i < TABLE_LENGTH; i++)
table[i] = random() % 65536; table[i] = random() % 65536;
/* Ephemeral port selection function */ /* Ephemeral port selection function */
num_ephemeral = max_ephemeral - min_ephemeral + 1; num_ephemeral = max_ephemeral - min_ephemeral + 1;
offset = F(local_IP, remote_IP, remote_port, secret_key); offset = F(local_IP, remote_IP, remote_port, secret_key1);
index = G(offset); index = G(local_IP, remote_IP, remote_port, secret_key2);
count = num_ephemeral; count = num_ephemeral;
do { do {
port = min_ephemeral + (offset + table[index]) % num_ephemeral; port = min_ephemeral + (offset + table[index]) % num_ephemeral;
table[index]++; table[index]++;
if(five-tuple is unique) if(five-tuple is unique)
return port; return port;
count--; count--;
} while (count > 0); } while (count > 0);
return ERROR; return ERROR;
Figure 5 Figure 5
We will refer to this algorithm as 'Algorithm 4'. We will refer to this algorithm as 'Algorithm 4'.
'table[]' could be initialized with random values, as indicated by 'table[]' could be initialized with random values, as indicated by
the initialization code in Figure 5. G() would return a value the initialization code in Figure 5. The function G() should be a
between 0 and (TABLE_LENGTH-1) taking 'offset' as its input. G() cryptographic hash function like MD5 [RFC1321]. It should use both
could, for example, perform the exclusive-or (xor) operation between IP addresses, the remote port and a secret key value to compute a
all the bytes in 'offset', or could be some cryptographic hash value between 0 and (TABLE_LENGTH-1). Alternatively, G() could take
function such as that used in F(). as "offset" as input, and perform the exclusive-or (xor) operation
between all the bytes in 'offset'.
The array 'table[]' assures that succesive connections to the same The array 'table[]' assures that 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 actual port *increments* into TABLE_LENGTH different spaces. The port sequence
sequence will result from adding the corresponding entry of 'table[]' will result from adding the corresponding entry of 'table[]' to the
to the variable 'offset', which actually selects the actual port variable 'offset', which selects the actual port sequence (as in
sequence (as in Algorithm 3). Algorithm 3). [Allman] has found that even a TABLE_LENGTH of 10 can
result in an improvement over Algorithm 3. Considering the amount of
memory available in most general-purpose systems recommend a
TABLE_LENGTH of 1024 for such systems, but note that other systems
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 and Algorithm 3.
Additionally, an implementation can further limit the attacker's Additionally, an implementation can further limit the attacker's
ability to perform traffic analysis by further separating the ability to perform traffic analysis by further separating the
increment space (that is, using a larger value for TABLE_LENGTH). increment space (that is, using a larger value for TABLE_LENGTH).
3.3.5. Algorithm 5: Random-increments port selection algorithm
[Allman] introduced yet another port randomization selection, which
offers a middle ground between the algorithms that select ephemeral
ports randomly (such as those described in Section 3.3.1 and
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
will refer to this algorithm as 'Algorithm 5'.
/* Initialization code at system boot time. */
next_ephemeral = 0; /* Initialization value could be random. */
N = 500; /* Determines the tradeoff. Should be configurable */
/* Ephemeral port selection function */
num_ephemeral = max_ephemeral - min_ephemeral + 1;
next_ephemeral = next_ephemeral + random(N);
count = num_ephemeral;
do {
port = min_ephemeral + (next_ephemeral % num_ephemeral);
if(five-tuple is unique)
return port;
next_ephemeral++;
count--;
} while (count > 0);
return ERROR;
Figure 6
The value "N" allows for direct control of the tradeoff between the
level of obfuscation and the port reuse frequency. 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 3.4. Secret-key considerations for hash-based port randomization
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 16, line 48 skipping to change at page 19, line 11
attacker is able to obtain a single ephemeral port (assuming a good attacker is able to obtain a single ephemeral port (assuming a good
hash function). If the attacker is able to obtain more ephemeral hash function). If the attacker is able to obtain more ephemeral
ports, key lengths of 64 bits or more should be used. ports, key lengths of 64 bits or more should be used.
Another possible mechanism for protecting the secret key is to change Another possible mechanism for protecting the secret key is to change
it after some time. If the host platform is capable of producing it after some time. If the host platform is capable of producing
reasonable good random data, the secret key can be changed reasonable good random data, the secret key can be changed
automatically. automatically.
Changing the secret will cause abrupt shifts in the chosen ephemeral Changing the secret will cause abrupt shifts in the chosen ephemeral
ports, and consequently collisions may occur. Thus the change in ports, and consequently collisions may occur. That is, upon changing
secret key should be done with consideration and could be performed the secret, the "offset" value (see Figure 4 and Figure 5) used for
whenever one of the following events occur: each destination end-point will be different from that computed with
the previous secret, ths leading to the selection of a port number
recently used for connecting to the same end-point.
Thus the change in secret key should be done with consideration and
could be performed whenever one of the following events occur:
o The system is being bootstrapped.
o Some predefined/random time has expired. o Some predefined/random time has expired.
o The secret has been used N times (i.e. we consider it insecure). o The secret has been used N times (i.e. we consider it insecure).
o There are few active connections (i.e., possibility of collision o There are few active 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 randomization algorithm
[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 offer low collision rates -- at most 0.3%.
However, these results may vary depending on the characteristics of
network traffic and the pecfic 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. future transport protocol instance. However, it is very simple, and
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
port number collisions, which could lead to the failure of the port number collisions, which could lead to the failure of the
connection establishment attempt. connection establishment attempt. [Allman] found that these two
algorithms show the largest collision rates (among all the algorithms
described in this document).
Algorithm 3 provides complete separation in local and remote IP Algorithm 3 provides complete separation in local and remote IP
addresses and remote port space, and only limited separation in other addresses and remote port space, and only limited separation in other
dimensions (See Section Section 3.4), and thus may scale better than dimensions (see Section 3.4). However, implementations should
Algorithm 1 and Algorithm 2. However, implementations should
consider the performance impact of computing the cryptographic hash consider the performance impact of computing the cryptographic hash
used for the offset. used for the offset.
Algorithm 4 improves Algorithm 3, usually leading to a lower port Algorithm 4 improves Algorithm 3, usually leading to a lower port
reuse frequency, at the expense of more processor cycles used for reuse frequency, at the expense of more processor cycles used for
computing G(), and additional kernel memory for storing the array computing G(), and additional kernel memory for storing the array
'table[]'. 'table[]'.
Algorithm 5 offers middle ground between the simple randomization
algorithms (Algorithm 1 and Algorthm 2) and the hash-based algorithms
(Algorithm 3 and Algorithm 4). The upper limit on the random
increments (the value "N" in Figure 6 controls the trade-off between
randomization and port-reuse frequency.
Finally, a special case that may preclude the utilization of Finally, a special case that may preclude the utilization of
Algorithm 3 and Algorithm 4 should be analyzed. There exist some Algorithm 3 and Algorithm 4 should be analyzed. There exist some
applications that contain the following code sequence: applications that contain the following code sequence:
s = socket(); s = socket();
bind(s, IP_address, port = *); bind(s, IP_address, port = *);
Figure 6 Figure 7
In some BSD-derived systems, the call to bind() will result in the In some BSD-derived systems, the call to bind() will result in the
selection of an ephemeral port number. However, as neither the selection of an ephemeral port number. However, as neither the
remote IP address nor the remote port will be available to the remote IP address nor the remote port will be available to the
ephemeral port selection function, the hash function F() used in ephemeral port selection function, the hash function F() used in
Algorithm 3 and Algorithm 4 will not have all the required arguments, Algorithm 3 and Algorithm 4 will not have all the required arguments,
and thus the result of the hash function will be impossible to and thus the result of the hash function will be impossible to
compute. Transport protocols implementating Algorithm 3 or Algorithm compute. Transport protocols implementating Algorithm 3 or Algorithm
4 should consider using Algorithm 2 when facing the scenario just 4 should consider using Algorithm 2 when facing the scenario just
described. described.
skipping to change at page 19, line 18 skipping to change at page 22, line 18
address and transport-protocol port number, thus allowing the address and transport-protocol port number, thus allowing the
transport identifiers of a number of private hosts to be multiplexed transport identifiers of a number of private hosts to be multiplexed
into the transport identifiers of a single external address. into the transport identifiers of a single external address.
[RFC2663] [RFC2663]
In those scenarios in which a NAPT is present between the two end- In those scenarios in which a NAPT is present between the two end-
points of transport-protocol 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 randomizing the ephemeral ports by
means of any of the algorithms discussed in this document. means of any of the algorithms discussed in this document. It should
be noted that in some network scenarios, a NAPT may naturally obscure
ephemeral port selections simply due to the vast range of services
with which it establishes connections and to the overall rate of the
traffic [Allman].
Section 3.5 provides guidance in choosing a port randomization Section 3.5 provides guidance in choosing a port randomization
algorithm. algorithm.
5. Security Considerations 5. Security Considerations
Randomizing ports is no replacement for cryptographic mechanisms, Randomizing ports is no replacement for cryptographic mechanisms,
such as IPsec [RFC4301], in terms of protecting transport protocol such as IPsec [RFC4301], in terms of protecting transport protocol
instances against blind attacks. instances against blind attacks.
skipping to change at page 22, line 5 skipping to change at page 24, line 20
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, Joe Touch, and Dan Wing for
their valuable feedback on earlier versions of this document. 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
support.
7. References 7. References
7.1. Normative References 7.1. Normative References
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
August 1980. August 1980.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, [RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, September 1981. RFC 793, September 1981.
skipping to change at page 23, 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-03 (work in progress), draft-ietf-tcpm-icmp-attacks-04 (work in progress),
March 2008. October 2008.
[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",
Available at:
http://www.icir.org/mallman/papers/ports-ccr09.pdf.
[CPNI-TCP]
Gont, F., "CPNI Technical Note 3/2009: Security Assessment
of the Transmission Control Protocol (TCP)", UK Centre
for the Protection of National Infrastructure, 2009.
[I-D.gont-tcp-security]
Gont, F., "Security Assessment of the Transmission Control
Protocol (TCP)", draft-gont-tcp-security-00 (work in
progress), February 2009.
[Linux] The Linux Project, "http://www.kernel.org". [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".
[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-01 Authentication Option", draft-ietf-tcpm-tcp-auth-opt-04
(work in progress), July 2008. (work in progress), March 2009.
[Watson] Watson, P., "Slipping in the Window: TCP Reset Attacks", [Watson] Watson, P., "Slipping in the Window: TCP Reset Attacks",
CanSecWest 2004 Conference . CanSecWest 2004 Conference .
Appendix A. Survey of the algorithms in use by some popular Appendix A. Survey of the algorithms in use by some popular
implementations implementations
A.1. FreeBSD A.1. FreeBSD
FreeBSD implements Algorithm 1, and in response to this document now FreeBSD implements Algorithm 1, and in response to this document now
skipping to change at page 25, line 7 skipping to change at page 29, line 7
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 Appendix B. Changes from previous versions of the draft
B.1. Changes from draft-ietf-tsvwg-port-randomization-01 B.1. Changes from draft-ietf-tsvwg-port-randomization-02
o Added clarification of what we mean by "port randomization".
o Addresses feedback sent on-list and off-list by Mark Allman.
o Added references to [Allman] and [CPNI-TCP].
B.2. 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.2. Changes from draft-ietf-tsvwg-port-randomization-00 B.3. 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.3. Changes from draft-larsen-tsvwg-port-randomization-02 B.4. 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.4. Changes from draft-larsen-tsvwg-port-randomization-01 B.5. Changes from draft-larsen-tsvwg-port-randomization-01
o No changes. Draft resubmitted after expiration. o No changes. Draft resubmitted after expiration.
B.5. Changes from draft-larsen-tsvwg-port-randomization-00 B.6. 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.6. Changes from draft-larsen-tsvwg-port-randomisation-00 B.7. 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
skipping to change at page 28, line 4 skipping to change at line 1108
Email: michael.larsen@tietoenator.com Email: michael.larsen@tietoenator.com
Fernando Gont Fernando Gont
Universidad Tecnologica Nacional / Facultad Regional Haedo Universidad Tecnologica Nacional / Facultad Regional Haedo
Evaristo Carriego 2644 Evaristo Carriego 2644
Haedo, Provincia de Buenos Aires 1706 Haedo, Provincia de Buenos Aires 1706
Argentina Argentina
Phone: +54 11 4650 8472 Phone: +54 11 4650 8472
Email: fernando@gont.com.ar Email: fernando@gont.com.ar
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
 End of changes. 47 change blocks. 
118 lines changed or deleted 270 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/