idnits 2.17.1 draft-ietf-tsvwg-port-randomization-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 15, 2010) is 5184 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Downref: Normative reference to an Informational RFC: RFC 1321 ** Obsolete normative reference: RFC 2385 (Obsoleted by RFC 5925) ** Obsolete normative reference: RFC 4960 (Obsoleted by RFC 9260) == Outdated reference: A later version (-12) exists of draft-ietf-tcpm-icmp-attacks-10 -- Obsolete informational reference (is this intentional?): RFC 1948 (Obsoleted by RFC 6528) == Outdated reference: A later version (-32) exists of draft-ietf-tsvwg-sctpsocket-21 == Outdated reference: A later version (-11) exists of draft-ietf-tcpm-tcp-auth-opt-10 Summary: 5 errors (**), 0 flaws (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Transport Area Working Group M. Larsen 3 (tsvwg) TietoEnator 4 Internet-Draft F. Gont 5 Intended status: BCP UTN/FRH 6 Expires: August 19, 2010 February 15, 2010 8 Transport Protocol Port Randomization Recommendations 9 draft-ietf-tsvwg-port-randomization-06 11 Abstract 13 Recently, awareness has been raised about a number of "blind" attacks 14 that can be performed against the Transmission Control Protocol (TCP) 15 and similar protocols. The consequences of these attacks range from 16 throughput-reduction to broken connections or data corruption. These 17 attacks rely on the attacker's ability to guess or know the five- 18 tuple (Protocol, Source Address, Destination Address, Source Port, 19 Destination Port) that identifies the transport protocol instance to 20 be attacked. This document describes a number of simple and 21 efficient methods for the selection of the client port number, such 22 that the possibility of an attacker guessing the exact value is 23 reduced. While this is not a replacement for cryptographic methods 24 for protecting the transport-protocol instance, the described port 25 number obfuscation algorithms provide improved security/obfuscation 26 with very little effort and without any key management overhead. The 27 algorithms described in this document are local policies that may be 28 incrementally deployed, and that do not violate the specifications of 29 any of the transport protocols that may benefit from them, such as 30 TCP, UDP, UDP-lite, SCTP, DCCP, and RTP (provided the RTP application 31 explicitly signals the RTP and RTCP port numbers). 33 Status of this Memo 35 This Internet-Draft is submitted to IETF in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF), its areas, and its working groups. Note that 40 other groups may also distribute working documents as Internet- 41 Drafts. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 The list of current Internet-Drafts can be accessed at 49 http://www.ietf.org/ietf/1id-abstracts.txt. 51 The list of Internet-Draft Shadow Directories can be accessed at 52 http://www.ietf.org/shadow.html. 54 This Internet-Draft will expire on August 19, 2010. 56 Copyright Notice 58 Copyright (c) 2010 IETF Trust and the persons identified as the 59 document authors. All rights reserved. 61 This document is subject to BCP 78 and the IETF Trust's Legal 62 Provisions Relating to IETF Documents 63 (http://trustee.ietf.org/license-info) in effect on the date of 64 publication of this document. Please review these documents 65 carefully, as they describe your rights and restrictions with respect 66 to this document. Code Components extracted from this document must 67 include Simplified BSD License text as described in Section 4.e of 68 the Trust Legal Provisions and are provided without warranty as 69 described in the BSD License. 71 This document may contain material from IETF Documents or IETF 72 Contributions published or made publicly available before November 73 10, 2008. The person(s) controlling the copyright in some of this 74 material may not have granted the IETF Trust the right to allow 75 modifications of such material outside the IETF Standards Process. 76 Without obtaining an adequate license from the person(s) controlling 77 the copyright in such materials, this document may not be modified 78 outside the IETF Standards Process, and derivative works of it may 79 not be created outside the IETF Standards Process, except to format 80 it for publication as an RFC or to translate it into languages other 81 than English. 83 Table of Contents 85 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 86 2. Ephemeral Ports . . . . . . . . . . . . . . . . . . . . . . . 7 87 2.1. Traditional Ephemeral Port Range . . . . . . . . . . . . . 7 88 2.2. Ephemeral port selection . . . . . . . . . . . . . . . . . 7 89 2.3. Collision of instance-id's . . . . . . . . . . . . . . . . 8 90 3. Obfuscating the Ephemeral Ports . . . . . . . . . . . . . . . 10 91 3.1. Characteristics of a good ephemeral port obfuscation 92 algorithm . . . . . . . . . . . . . . . . . . . . . . . . 10 93 3.2. Ephemeral port number range . . . . . . . . . . . . . . . 12 94 3.3. Ephemeral Port Obfuscation Algorithms . . . . . . . . . . 12 95 3.3.1. Algorithm 1: Simple port randomization algorithm . . . 12 96 3.3.2. Algorithm 2: Another simple port randomization 97 algorithm . . . . . . . . . . . . . . . . . . . . . . 14 98 3.3.3. Algorithm 3: Simple hash-based algorithm . . . . . . . 14 99 3.3.4. Algorithm 4: Double-hash obfuscation algorithm . . . . 17 100 3.3.5. Algorithm 5: Random-increments port selection 101 algorithm . . . . . . . . . . . . . . . . . . . . . . 18 102 3.4. Secret-key considerations for hash-based port 103 obfuscation algorithms . . . . . . . . . . . . . . . . . . 20 104 3.5. Choosing an ephemeral port obfuscation algorithm . . . . . 21 105 4. Port obfuscation and Network Address Port Translation 106 (NAPT) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 107 5. Security Considerations . . . . . . . . . . . . . . . . . . . 24 108 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 109 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26 110 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 111 8.1. Normative References . . . . . . . . . . . . . . . . . . . 27 112 8.2. Informative References . . . . . . . . . . . . . . . . . . 27 113 Appendix A. Survey of the algorithms in use by some popular 114 implementations . . . . . . . . . . . . . . . . . . . 30 115 A.1. FreeBSD . . . . . . . . . . . . . . . . . . . . . . . . . 30 116 A.2. Linux . . . . . . . . . . . . . . . . . . . . . . . . . . 30 117 A.3. NetBSD . . . . . . . . . . . . . . . . . . . . . . . . . . 30 118 A.4. OpenBSD . . . . . . . . . . . . . . . . . . . . . . . . . 30 119 A.5. OpenSolaris . . . . . . . . . . . . . . . . . . . . . . . 30 120 Appendix B. Changes from previous versions of the draft (to 121 be removed by the RFC Editor before publication 122 of this document as a RFC . . . . . . . . . . . . . . 31 123 B.1. Changes from draft-ietf-tsvwg-port-randomization-05 . . . 31 124 B.2. Changes from draft-ietf-tsvwg-port-randomization-04 . . . 31 125 B.3. Changes from draft-ietf-tsvwg-port-randomization-03 . . . 31 126 B.4. Changes from draft-ietf-tsvwg-port-randomization-02 . . . 31 127 B.5. Changes from draft-ietf-tsvwg-port-randomization-01 . . . 31 128 B.6. Changes from draft-ietf-tsvwg-port-randomization-00 . . . 31 129 B.7. Changes from draft-larsen-tsvwg-port-randomization-02 . . 31 130 B.8. Changes from draft-larsen-tsvwg-port-randomization-01 . . 32 131 B.9. Changes from draft-larsen-tsvwg-port-randomization-00 . . 32 132 B.10. Changes from draft-larsen-tsvwg-port-randomisation-00 . . 32 133 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33 135 1. Introduction 137 Recently, awareness has been raised about a number of "blind" attacks 138 (i.e., attacks that can be performed without the need to sniff the 139 packets that correspond to the transport protocol instance to be 140 attacked) that can be performed against the Transmission Control 141 Protocol (TCP) [RFC0793] and similar protocols. The consequences of 142 these attacks range from throughput-reduction to broken connections 143 or data corruption [I-D.ietf-tcpm-icmp-attacks] [RFC4953] [Watson]. 145 All these attacks rely on the attacker's ability to guess or know the 146 five-tuple (Protocol, Source Address, Source port, Destination 147 Address, Destination Port) that identifies the transport protocol 148 instance to be attacked. 150 Services are usually located at fixed, 'well-known' ports [IANA] at 151 the host supplying the service (the server). Client applications 152 connecting to any such service will contact the server by specifying 153 the server IP address and service port number. The IP address and 154 port number of the client are normally left unspecified by the client 155 application and thus chosen automatically by the client networking 156 stack. Ports chosen automatically by the networking stack are known 157 as ephemeral ports [Stevens]. 159 While the server IP address and well-known port and the client IP 160 address may be known by an attacker, the ephemeral port of the client 161 is usually unknown and must be guessed. 163 This document describes a number of algorithms for the selection of 164 ephemeral port numbers, such that the possibility of an off-path 165 attacker guessing the exact value is reduced. They are not a 166 replacement for cryptographic methods of protecting a transport- 167 protocol instance such as IPsec [RFC4301], the TCP MD5 signature 168 option [RFC2385], or the TCP Authentication Option 169 [I-D.ietf-tcpm-tcp-auth-opt]. For example, they do not provide any 170 mitigation in those scenarios in which the attacker is able to sniff 171 the packets that correspond to the transport protocol instance to be 172 attacked. However, the proposed algorithms provide improved 173 obfuscation with very little effort and without any key management 174 overhead. 176 The mechanisms described in this document are local modifications 177 that may be incrementally deployed, and that do not violate the 178 specifications of any of the transport protocols that may benefit 179 from them, such as TCP [RFC0793], UDP [RFC0768], SCTP [RFC4960], DCCP 180 [RFC4340], UDP-lite [RFC3828], and RTP [RFC3550] (provided the RTP 181 application explicitly signals the RTP and RTCP port numbers with 182 e.g.[RFC3605]). 184 Since these mechanisms are obfuscation techniques, focus has been on 185 a reasonable compromise between the level of obfuscation and the ease 186 of implementation. Thus the algorithms must be computationally 187 efficient, and not require substantial state. 189 We note that while the technique of mitigating "blind" attacks by 190 obfuscating the ephemeral port selection is well-known as "port 191 randomization", the goal of the algorithms described in this document 192 is to reduce the chances of an attacker guessing the ephemeral ports 193 selected for new transport protocol instances, rather than to 194 actually produce mathematically random sequences of ephemeral ports. 196 Throughout this document we will use the term "transport-protocol 197 instance" as a general term to refer to an instantiation of a 198 transport protocol (e.g, a "connection" in the case of connection- 199 oriented transport protocols) and the term "instance-id" as a short- 200 handle to refer to the group of values that identify a transport- 201 protocol instance (e.g., in the case of TCP, the five-tuple 202 {Protocol, IP Source Address, TCP Source Port, IP Destination 203 Address, TCP Destination Port}). 205 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 206 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 207 document are to be interpreted as described in RFC 2119 [RFC2119]. 209 2. Ephemeral Ports 211 2.1. Traditional Ephemeral Port Range 213 The Internet Assigned Numbers Authority (IANA) assigns the unique 214 parameters and values used in protocols developed by the Internet 215 Engineering Task Force (IETF), including well-known ports [IANA]. 216 IANA has reserved the following use of the 16-bit port range of TCP 217 and UDP: 219 o The Well Known Ports, 0 through 1023. 221 o The Registered Ports, 1024 through 49151 223 o The Dynamic and/or Private Ports, 49152 through 65535 225 The dynamic port range defined by IANA consists of the 49152-65535 226 range, and is meant for the selection of ephemeral ports. 228 2.2. Ephemeral port selection 230 As each communication instance is identified by the five-tuple 231 {protocol, local IP address, local port, remote IP address, remote 232 port}, the selection of ephemeral port numbers must result in a 233 unique five-tuple. 235 Selection of ephemeral ports such that they result in unique 236 instance-id's (five-tuples) is handled by some implementations by 237 having a per-protocol global 'next_ephemeral' variable that is equal 238 to the previously chosen ephemeral port + 1, i.e. the selection 239 process is: 241 /* Initialization at system boot time. Could be random */ 242 next_ephemeral = min_ephemeral; 244 /* Ephemeral port selection function */ 245 count = max_ephemeral - min_ephemeral + 1; 247 do { 248 port = next_ephemeral; 249 if (next_ephemeral == max_ephemeral) { 250 next_ephemeral = min_ephemeral; 251 } else { 252 next_ephemeral++; 253 } 255 if (five-tuple is unique) 256 return port; 258 count--; 260 } while (count > 0); 262 return ERROR; 264 Figure 1 266 This algorithm works adequately provided that the number of 267 transport-protocol instances (for a each transport protocol) that 268 have a life-time longer than it takes to exhaust the total ephemeral 269 port range is small, so that collisions of instance-id's are rare. 271 However, this method has the drawback that the 'next_ephemeral' 272 variable and thus the ephemeral port range is shared between all 273 transport-protocol instances and the next ports chosen by the client 274 are easy to predict. If an attacker operates an "innocent" server to 275 which the client connects, it is easy to obtain a reference point for 276 the current value of the 'next_ephemeral' variable. Additionally, if 277 an attacker could force a client to periodically establish e.g., a 278 new TCP connection to an attacker controlled machine (or through an 279 attacker observable routing path), the attacker could subtract 280 consecutive source port values to obtain the number of outgoing TCP 281 connections established globally by the target host within that time 282 period (up to wrap-around issues and instance-id collisions, of 283 course). 285 2.3. Collision of instance-id's 287 While it is possible for the ephemeral port selection algorithm to 288 verify that the selected port number results in a instance-id that is 289 not currently in use by that system, the resulting instance-id may 290 still be in use at a remote system. For example, consider a scenario 291 in which a client establishes a TCP connection with a remote web 292 server, and the web server performs the active close on the 293 connection. While the state information for this connection will 294 disappear at the client side (that is, the connection will be moved 295 to the fictional CLOSED state), the instance-id will remain in the 296 TIME-WAIT state at the web server for 2*MSL (Maximum Segment 297 Lifetime). If the same client tried to create a new incarnation of 298 the previous connection (that is, a connection with the same 299 instance-id as the one in the TIME_WAIT state at the server), an 300 instance-id "collision" would occur. The effect of these collisions 301 range from connection-establishment failures to TIME-WAIT state 302 assassination (with the potential of data corruption) [RFC1337]. In 303 scenarios in which a specific client establishes TCP connections with 304 a specific service at a server, these problems become evident. 305 Therefore, an ephemeral port selection algorithm should ideally 306 minimize the rate of instance-id collisions. 308 A simple approach to minimize the rate of these collisions would be 309 to choose port numbers incrementally, so that a given port number 310 would not be reused until the rest of the port numbers in ephemeral 311 port range have been used for a transport protocol instance. 312 However, if a single global variable were used to keep track of the 313 last ephemeral port selected, ephemeral port numbers would be 314 trivially predictable, thus making it easier for an off-path attacker 315 to "guess" the instance-id in use by a target transport-protocol 316 instance. Section 3.3.3 and Section 3.3.4 describe algorithms that 317 select port numbers incrementally, while still making it difficult 318 for an off-path attacker to predict the ephemeral ports used for 319 future transport-protocol instances. 321 A simple but inefficient approach to minimize the rate of collisions 322 of instance-id's would be, e.g. in the case of TCP, for both end- 323 points of a TCP connection to keep state about recent connections 324 (e.g., have both end-points end up in the TIME-WAIT state). 326 3. Obfuscating the Ephemeral Ports 328 3.1. Characteristics of a good ephemeral port obfuscation algorithm 330 There are a number of factors to consider when designing an algorithm 331 for selecting ephemeral ports, which include: 333 o Minimizing the predictability of the ephemeral port numbers used 334 for future transport-protocol instances. 336 o Minimizing collisions of instance-id's 338 o Avoiding conflict with applications that depend on the use of 339 specific port numbers. 341 Given the goal of improving the transport protocol's resistance to 342 attack by obfuscation of the instance-id, it is key to minimize the 343 predictability of the ephemeral ports that will be selected for new 344 transport-protocol instances. While the obvious approach to address 345 this requirement would be to select the ephemeral ports by simply 346 picking a random value within the chosen port number range, this 347 straightforward policy may lead to collisions of instance-id's, which 348 could lead to the interoperability problems (e.g., delays in the 349 establishment of new connections, failures in connection- 350 establishment, or data corruption) discussed in Section 2.3. As 351 discussed in Section 1, it is worth noting that while the technique 352 of mitigating "blind" attacks by obfuscating the ephemeral port 353 election is well-known as "port randomization", the goal of the 354 algorithms described in this document is to reduce the chances of an 355 attacker guessing the ephemeral ports selected for new transport- 356 protocol instances, rather than to actually produce sequences of 357 mathematically random ephemeral port numbers. 359 It is also worth noting that, provided adequate algorithms are in 360 use, the larger the range from which ephemeral pots are selected, the 361 smaller the chances of an attacker are to guess the selected port 362 number. 364 In scenarios in which a specific client establishes transport- 365 protocol instances with a specific service at a server, the problems 366 described in Section 2.3 become evident. A good algorithm to 367 minimize the collisions of instance-id's would consider the time a 368 given five-tuple was last used, and would avoid reusing the last 369 recently used five-tuples. A simple approach to minimize the rate of 370 collisions would be to choose port numbers incrementally, so that a 371 given port number would not be reused until the rest of the port 372 numbers in the ephemeral port range have been used for a transport 373 protocol instance. However, if a single global variable were used to 374 keep track of the last ephemeral port selected, ephemeral port 375 numbers would be trivially predictable. 377 It is important to note that a number of applications rely on binding 378 specific port numbers that may be within the ephemeral ports range. 379 If such an application was run while the corresponding port number 380 was in use, the application would fail. Therefore, ephemeral port 381 selection algorithms avoid using those port numbers. 383 Port numbers that are currently in use by a TCP in the LISTEN state 384 should not be allowed for use as ephemeral ports. If this rule is 385 not complied with, an attacker could potentially "steal" an incoming 386 connection to a local server application by issuing a connection 387 request to the victim client at roughly the same time the client 388 tries to connect to the victim server application [CPNI-TCP] 389 [I-D.gont-tcp-security]. If the SYN segment corresponding to the 390 attacker's connection request and the SYN segment corresponding to 391 the victim client "cross each other in the network", and provided the 392 attacker is able to know or guess the ephemeral port used by the 393 client, a TCP simultaneous open scenario would take place, and the 394 incoming connection request sent by the client would be matched with 395 the attacker's socket rather than with the victim server 396 application's socket. 398 It should be noted that most applications based on popular 399 implementations of the TCP API (such as the Sockets API) perform 400 "passive opens" in three steps. Firstly, the application obtains a 401 file descriptor to be used for inter-process communication (e.g., by 402 issuing a socket() call). Secondly, the application binds the file 403 descriptor to a local TCP port number (e.g., by issuing a bind() 404 call), thus creating a TCP in the fictional CLOSED state. Thirdly, 405 the aforementioned TCP is put in the LISTEN state (e.g., by issuing a 406 listen() call). As a result, with such an implementation of the TCP 407 API, even if port numbers in use for TCPs in the LISTEN state were 408 not allowed for use as ephemeral ports, there is a window of time 409 between the second and the third steps in which an attacker could be 410 allowed to select a port number that would be later used for 411 listening to incoming connections. Therefore, these implementations 412 of the TCP API should enforce a stricter requirement for the 413 allocation of port numbers: port numbers that are in use by a TCP in 414 the LISTEN or CLOSED states should not be allowed for allocation as 415 ephemeral ports [CPNI-TCP] [I-D.gont-tcp-security]. 417 The aforementioned issues do not affect SCTP, since most SCTP 418 implementations do not allow a socket to be bound to the same port 419 number unless a specific socket option (SCTP_REUSE_PORT) is issued on 420 the socket (i.e., this behavior needs to be explititly allowed 421 beforehand). An example of a typical SCTP socket API can be found in 423 [I-D.ietf-tsvwg-sctpsocket]. 425 DCCP is not affected is not affected by the exploitation of 426 "simultaneous opens" to ""steal" incoming connections, as the server 427 and the client state machines are different [RFC4340]. However, it 428 may be affected by the vector involving binding a more specific 429 socket. As a result, those tuples {local IP address, local port, 430 Service Code} that are in use by a local socket should not be allowed 431 for allocation as ephemeral ports. 433 3.2. Ephemeral port number range 435 As mentioned in Section 2.1, the dynamic ports consist of the range 436 49152-65535. However, ephemeral port selection algorithms should use 437 the whole range 1024-49151. 439 Since this range includes ports numbers assigned by IANA, this may 440 not always be possible, though. A possible workaround for this 441 potential problem would be to maintain a local list of the port 442 numbers that should not be allocated as ephemeral ports. Thus, 443 before allocating a port number, the ephemeral port selection 444 function would check this list, avoiding the allocation of ports that 445 may be needed for specific applications. 447 Ephemeral port selection algorithms SHOULD use the largest possible 448 port range, since this improves obfuscation. 450 3.3. Ephemeral Port Obfuscation Algorithms 452 Ephemeral port selection algorithms SHOULD obfuscate the allocation 453 of their ephemeral ports, since this helps to mitigate a number of 454 attacks that depend on the attacker's ability to guess or know the 455 five-tuple that identifies the transport protocol instance to be 456 attacked. 458 The following subsections describe a number of algorithms that could 459 be implemented in order to obfuscate the selection of ephemeral port 460 numbers. 462 3.3.1. Algorithm 1: Simple port randomization algorithm 464 In order to address the security issues discussed in Section 1 and 465 Section 2.2, a number of systems have implemented simple ephemeral 466 port number randomization, as follows: 468 /* Ephemeral port selection function */ 469 num_ephemeral = max_ephemeral - min_ephemeral + 1; 470 next_ephemeral = min_ephemeral + (random() % num_ephemeral); 471 count = num_ephemeral; 473 do { 474 if(resulting five-tuple is unique) 475 return next_ephemeral; 477 if (next_ephemeral == max_ephemeral) { 478 next_ephemeral = min_ephemeral; 479 } else { 480 next_ephemeral++; 481 } 483 count--; 484 } while (count > 0); 486 return ERROR; 488 Figure 2 490 We will refer to this algorithm as 'Algorithm 1'. 492 Note: "random()" is a function that returns a pseudo-random unsigned 493 interger number in the range 0-65535 (it may return values larger 494 than 65535, as is the case with the "random()" C-language function). 496 Since the initially chosen port may already be in use with identical 497 IP addresses and server port, the resulting five-tuple might not be 498 unique. Therefore, multiple ports may have to be tried and verified 499 against all existing transport-protocol instances before a port can 500 be chosen. 502 Web proxy servers, NAPTs [RFC2663], and other middle-boxes aggregate 503 multiple peers into the same port space and thus increase the 504 population of used ephemeral ports, and hence the chances of 505 collisions of instance-id's. However, [Allman] has shown that at 506 least in the network scenarios used for measuring the collision 507 properties of the algorithms described in this document, the 508 collision rate resulting from the use of the aforementioned middle- 509 boxes is nevertheless very low. 511 Since this algorithm performs a completely random port selection 512 (i.e., without taking into account the port numbers previously 513 chosen), it has the potential of reusing port numbers too quickly, 514 thus possibly leading to collisions of instance-id's. Even if a 515 given five-tuple is verified to be unique by the port selection 516 algorithm, the five-tuple might still be in use at the remote system. 517 In such a scenario, a connection request could possibly fail 518 ([Silbersack] describes this problem for the TCP case). 520 This algorithm selects ephemeral port numbers randomly and thus 521 reduces the chances of an attacker of guessing the ephemeral port 522 selected for a target transport-protocol instance. Additionally, it 523 prevents attackers from obtaining the number of outgoing transport- 524 protocol instances (e.g., TCP connections) established by the client 525 in some period of time. 527 3.3.2. Algorithm 2: Another simple port randomization algorithm 529 The following pseudo-code illustrates another algorithm for selecting 530 a random port number, in which in the event a local instance-id 531 collision is detected, another port number is selected randomly: 533 /* Ephemeral port selection function */ 534 num_ephemeral = max_ephemeral - min_ephemeral + 1; 535 next_ephemeral = min_ephemeral + (random() % num_ephemeral); 536 count = num_ephemeral; 538 do { 539 if(resulting five-tuple is unique) 540 return next_ephemeral; 542 next_ephemeral = min_ephemeral + (random() % num_ephemeral); 543 count--; 544 } while (count > 0); 546 return ERROR; 548 Figure 3 550 We will refer to this algorithm as 'Algorithm 2'. This algorithm 551 might be unable to select an ephemeral port (i.e., return "ERROR") 552 even if there are port numbers that would result in unique five- 553 tuples, when there are a large number of port numbers already in use. 554 However, the results in [Allman] have shown that in common scenarios, 555 one port choice is enough, and in most cases where more than one 556 choice is needed two choices suffice. Therefore, in those scenarios 557 this would not be problem. 559 3.3.3. Algorithm 3: Simple hash-based algorithm 561 We would like to achieve the port reuse properties of the traditional 562 BSD port selection algorithm (described in Section 2.2), while at the 563 same time achieve the obfuscation properties of Algorithm 1 and 564 Algorithm 2. 566 Ideally, we would like a 'next_ephemeral' value for each set of 567 (local IP address, remote IP addresses, remote port), so that the 568 port reuse frequency is the lowest possible. Each of these 569 'next_ephemeral' variables should be initialized with random values 570 within the ephemeral port range and would thus separate the ephemeral 571 port space of the transport-protocol instances on a "per destination 572 end-point" basis (this "separation of the ephemeral port space" means 573 that transport-protocol instances with different remote end-points 574 will not have different sequences of port numbers; i.e., wil not be 575 part of the same ephemeral port sequence as in the case of the 576 traditional BSD ephemeral port selection algorithm). Since we do not 577 want to maintain in memory all these 'next_ephemeral' values, we 578 propose an offset function F(), that can be computed from the local 579 IP address, remote IP address, remote port and a secret key. F() 580 will yield (practically) different values for each set of arguments, 581 i.e.: 583 /* Initialization at system boot time. Could be random. */ 584 next_ephemeral = 0; 586 /* Ephemeral port selection function */ 587 num_ephemeral = max_ephemeral - min_ephemeral + 1; 588 offset = F(local_IP, remote_IP, remote_port, secret_key); 589 count = num_ephemeral; 591 do { 592 port = min_ephemeral + 593 (next_ephemeral + offset) % num_ephemeral; 595 next_ephemeral++; 597 if(resulting five-tuple is unique) 598 return port; 600 count--; 602 } while (count > 0); 604 return ERROR; 606 Figure 4 608 We will refer to this algorithm as 'Algorithm 3'. 610 In other words, the function F() provides a "per destination end- 611 point" fixed offset within the global ephemeral port range. Both the 612 'offset' and 'next_ephemeral' variables may take any value within the 613 storage type range since we are restricting the resulting port in a 614 similar way as in the Algorithm 1 (described in Section 3.3.1). This 615 allows us to simply increment the 'next_ephemeral' variable and rely 616 on the unsigned integer to simply wrap-around. 618 The function F() should be a cryptographic hash function like MD5 619 [RFC1321]. The function should use both IP addresses, the remote 620 port and a secret key value to compute the offset. The remote IP 621 address is the primary separator and must be included in the offset 622 calculation. The local IP address and remote port may in some cases 623 be constant and not improve the ephemeral port space separation, 624 however, they should also be included in the offset calculation. 626 Cryptographic algorithms stronger than e.g. MD5 should not be 627 necessary, given that Algorithm #3 is simply an obfuscation 628 technique. The secret should be chosen as random as possible, see 629 [RFC4086] for recommendations on choosing secrets. 631 Note that on multiuser systems, the function F() could include user 632 specific information, thereby providing protection not only on a host 633 to host basis, but on a user to service basis. In fact, any 634 identifier of the remote entity could be used, depending on 635 availability an the granularity requested. With SCTP both hostnames 636 and alternative IP addresses may be included in the association 637 negotiation and either of these could be used in the offset function 638 F(). 640 When multiple unique identifiers are available, any of these can be 641 chosen as input to the offset function F() since they all uniquely 642 identify the remote entity. However, in cases like SCTP where the 643 ephemeral port must be unique across all IP address permutations, we 644 should ideally always use the same IP address to get a single 645 starting offset for each association negotiation from a given remote 646 entity to minimize the possibility of collisions. A simple numerical 647 sorting of the IP addresses and always using the numerically lowest 648 could achieve this. However, since most protocols most likely will 649 report the same IP addresses in the same order in each association 650 setup, this sorting is most likely not necessary and the 'first one' 651 can simply be used. 653 The ability of hostnames to uniquely define hosts can be discussed, 654 and since SCTP always includes at least one IP address, we recommend 655 to use this as input to the offset function F() and ignore hostnames 656 chunks when searching for ephemeral ports. 658 It should be noted that, as this algorithm uses a global counter 659 ("next_ephemeral") for selecting ephemeral ports, if an attacker 660 could e.g., force a client to periodically establish a new TCP 661 connections to an attacker controlled machine (or through an attacker 662 observable routing path), the attacker could subtract consecutive 663 source port values to obtain the number of outgoing TCP connections 664 established globally by the target host within that time period (up 665 to wrap-around issues and 5-tuple collisions, of course). 667 3.3.4. Algorithm 4: Double-hash obfuscation algorithm 669 A tradeoff between maintaining a single global 'next_ephemeral' 670 variable and maintaining 2**N 'next_ephemeral' variables (where N is 671 the width of the result of F()) could be achieved as follows. The 672 system would keep an array of TABLE_LENGTH short integers, which 673 would provide a separation of the increment of the 'next_ephemeral' 674 variable. This improvement could be incorporated into Algorithm 3 as 675 follows: 677 /* Initialization at system boot time */ 678 for(i = 0; i < TABLE_LENGTH; i++) 679 table[i] = random() % 65536; 681 /* Ephemeral port selection function */ 682 num_ephemeral = max_ephemeral - min_ephemeral + 1; 683 offset = F(local_IP, remote_IP, remote_port, secret_key1); 684 index = G(local_IP, remote_IP, remote_port, secret_key2); 685 count = num_ephemeral; 687 do { 688 port = min_ephemeral + (offset + table[index]) % num_ephemeral; 689 table[index]++; 691 if(resulting five-tuple is unique) 692 return port; 694 count--; 696 } while (count > 0); 698 return ERROR; 700 Figure 5 702 We will refer to this algorithm as 'Algorithm 4'. 704 'table[]' could be initialized with mathematically random values, as 705 indicated by the initialization code in pseudo-code above. The 706 function G() should be a cryptographic hash function like MD5 707 [RFC1321]. It should use both IP addresses, the remote port and a 708 secret key value to compute a value between 0 and (TABLE_LENGTH-1). 709 Alternatively, G() could take as "offset" as input, and perform the 710 exclusive-or (xor) operation between all the bytes in 'offset'. 712 The array 'table[]' assures that successive transport-protocol 713 instances with the same remote end-point will use increasing 714 ephemeral port numbers. However, incrementation of the port numbers 715 is separated into TABLE_LENGTH different spaces, and thus the port 716 reuse frequency will be (probabilistically) lower than that of 717 Algorithm 3. That is, a new tranport-protocol instance with some 718 remote end-point will not necessarily cause the 'next_ephemeral' 719 variable corresponding to other end-points to be incremented. 721 It is interesting to note that the size of 'table[]' does not limit 722 the number of different port sequences, but rather separates the 723 *increments* into TABLE_LENGTH different spaces. The port sequence 724 will result from adding the corresponding entry of 'table[]' to the 725 variable 'offset', which selects the actual port sequence (as in 726 Algorithm 3). [Allman] has found that a TABLE_LENGTH of 10 can 727 result in an improvement over Algorithm 3. Further increasing the 728 TABLE_LENGTH will increase the obfuscation, and possibly further 729 decrease the collision rate. 731 An attacker can perform traffic analysis for any "increment space" 732 into which the attacker has "visibility", namely that the attacker 733 can force the client to establish a transport-protocol instance whose 734 G(offset) identifies the target "increment space". However, the 735 attacker's ability to perform traffic analysis is very reduced when 736 compared to the traditional BSD algorithm (described in Section 2.2) 737 and Algorithm 3. Additionally, an implementation can further limit 738 the attacker's ability to perform traffic analysis by further 739 separating the increment space (that is, using a larger value for 740 TABLE_LENGTH). 742 3.3.5. Algorithm 5: Random-increments port selection algorithm 744 [Allman] introduced another port obfuscation algorithm, which offers 745 a middle ground between the algorithms that select ephemeral ports 746 randomly (such as those described in Section 3.3.1 and 747 Section 3.3.2), and those that offer obfuscation but no randomization 748 (such as those described in Section 3.3.3 and Section 3.3.4). We 749 will refer to this algorithm as 'Algorithm 5'. 751 /* Initialization code at system boot time. */ 752 next_ephemeral = random() % 65536; /* Initialization value */ 753 N = 500; /* Determines the tradeoff */ 755 /* Ephemeral port selection function */ 756 num_ephemeral = max_ephemeral - min_ephemeral + 1; 758 count = num_ephemeral; 760 do { 761 next_ephemeral = next_ephemeral + (random() % N) + 1; 762 port = min_ephemeral + (next_ephemeral % num_ephemeral); 764 if(resulting five-tuple is unique) 765 return port; 767 count--; 768 } while (count > 0); 770 return ERROR; 772 Figure 6 774 This algorithm aims at at producing a monotonically-increasing 775 sequence to prevent the collision of instance-id's, while avoiding 776 the use of fixed increments, which would lead to trivially- 777 predictable sequences. The value "N" allows for direct control of 778 the tradeoff between the level of obfuscation and the port reuse 779 frequency. The smaller the value of "N", the more linear the more 780 similar this algorithm is to the traditional BSD port selection 781 algorithm (described in Section 2.2. The larger the value of "N", 782 the more similar this algorithm is to the algorithm described in 783 Section 3.3.1 of this document. 785 When the port numbers wrap, there is the risk of collisions of 786 instance-id's. Therefore, "N" should be selecting according to the 787 following criteria: 789 o It should maximize the wrapping time of the ephemeral port space 791 o It should minimize collisions of instance-id's 793 o It should maximize obfuscation 795 Clearly, these are competing goals, and the decision of which value 796 of "N" to use is a tradeoff. Therefore, the value of "N" should be 797 configurable so that system administrators can make the tradeoff for 798 themselves. 800 3.4. Secret-key considerations for hash-based port obfuscation 801 algorithms 803 Every complex manipulation (like MD5) is no more secure than the 804 input values, and in the case of ephemeral ports, the secret key. If 805 an attacker is aware of which cryptographic hash function is being 806 used by the victim (which we should expect), and the attacker can 807 obtain enough material (e.g. ephemeral ports chosen by the victim), 808 the attacker may simply search the entire secret key space to find 809 matches. 811 To protect against this, the secret key should be of a reasonable 812 length. Key lengths of 32 bits should be adequate, since a 32-bit 813 secret would result in approximately 65k possible secrets if the 814 attacker is able to obtain a single ephemeral port (assuming a good 815 hash function). If the attacker is able to obtain more ephemeral 816 ports, key lengths of 64 bits or more should be used. 818 Another possible mechanism for protecting the secret key is to change 819 it after some time. If the host platform is capable of producing 820 reasonable good random data, the secret key can be changed 821 automatically. 823 Changing the secret will cause abrupt shifts in the chosen ephemeral 824 ports, and consequently collisions may occur. That is, upon changing 825 the secret, the "offset" value (see Section 3.3.3 and Section 3.3.4) 826 used for each destination end-point will be different from that 827 computed with the previous secret, thus leading to the selection of a 828 port number recently used for connecting to the same end-point. 830 Thus the change in secret key should be done with consideration and 831 could be performed whenever one of the following events occur: 833 o The system is being bootstrapped. 835 o Some predefined/random time has expired. 837 o The secret has been used N times (i.e. we consider it insecure). 839 o There are few active transport protocol instances (i.e., 840 possibility of collision is low). 842 o There is little traffic (the performance overhead of collisions is 843 tolerated). 845 o There is enough random data available to change the secret key 846 (pseudo-random changes should not be done). 848 3.5. Choosing an ephemeral port obfuscation algorithm 850 [Allman] is an empirical study of the properties of the algorithms 851 described in this document, which has found that all the algorithms 852 described in this document offer low collision rates -- at most 0.3%. 853 That is, in those network scenarios assessed by [Allman] all of the 854 algorithms described in this document perform well in terms of 855 collisions of instance-id's. However, these results may vary 856 depending on the characteristics of network traffic and the specific 857 network setup. 859 The algorithm described in Section 2.2 is the traditional ephemeral 860 port selection algorithm implemented in BSD-derived systems. It 861 generates a global sequence of ephemeral port numbers, which makes it 862 trivial for an attacker to predict the port number that will be used 863 for a future transport protocol instance. However, it is very 864 simple, and leads to a low port reuse frequency. 866 Algorithm 1 and Algorithm 2 have the advantage that they provide 867 actual randomization of the ephemeral ports. However, they may 868 increase the chances of port number collisions, which could lead to 869 the failure of a connection establishment attempt. [Allman] found 870 that these two algorithms show the largest collision rates (among all 871 the algorithms described in this document). 873 Algorithm 3 provides complete separation in local and remote IP 874 addresses and remote port space, and only limited separation in other 875 dimensions (see Section 3.4). However, implementations should 876 consider the performance impact of computing the cryptographic hash 877 used for the offset. 879 Algorithm 4 improves Algorithm 3, usually leading to a lower port 880 reuse frequency, at the expense of more processor cycles used for 881 computing G(), and additional kernel memory for storing the array 882 'table[]'. 884 Algorithm 5 offers middle ground between the simple randomization 885 algorithms (Algorithm 1 and Algorithm 2) and the hash-based 886 algorithms (Algorithm 3 and Algorithm 4). The upper limit on the 887 random increments (the value "N" in the pseudo-code included in 888 Section 3.3.5 controls the trade-off between randomization and port- 889 reuse frequency. 891 Finally, a special case that may preclude the utilization of 892 Algorithm 3 and Algorithm 4 should be analyzed. There exist some 893 applications that contain the following code sequence: 895 s = socket(); 896 bind(s, IP_address, port = *); 898 Figure 7 900 In some BSD-derived systems, the call to bind() will result in the 901 selection of an ephemeral port number. However, as neither the 902 remote IP address nor the remote port will be available to the 903 ephemeral port selection function, the hash function F() used in 904 Algorithm 3 and Algorithm 4 will not have all the required arguments, 905 and thus the result of the hash function will be impossible to 906 compute. Transport protocols implementing Algorithm 3 or Algorithm 4 907 should consider using Algorithm 2 when facing the scenario just 908 described. 910 An alternative to this behavior would be to implement "lazy binding" 911 in response to the bind() call. That is, selection of an ephemeral 912 port would be delayed until, e.g., connect() or send() are called. 913 Thus, at that point the ephemeral port is actually selected, all the 914 necessary arguments for the hash function F() would be available, and 915 thus Algorithm 3 and Algorithm 4 could still be used in this 916 scenario. This algorithm has been implemented by Linux [Linux]. 918 4. Port obfuscation and Network Address Port Translation (NAPT) 920 Network Address Port Translation (NAPT) translate both the network 921 address and transport-protocol port number, thus allowing the 922 transport identifiers of a number of private hosts to be multiplexed 923 into the transport identifiers of a single external address. 924 [RFC2663] 926 In those scenarios in which a NAPT is present between the two end- 927 points of transport-protocol instance, the obfuscation of the 928 ephemeral ports (from the point of view of the external network) will 929 depend on the ephemeral port selection function at the NAPT. 930 Therefore, NAPTs should consider obfuscating the ephemeral ports by 931 means of any of the algorithms discussed in this document. It should 932 be noted that in some network scenarios, a NAPT may naturally obscure 933 ephemeral port selections simply due to the vast range of services 934 with which it establishes connections and to the overall rate of the 935 traffic [Allman]. 937 Section 3.5 provides guidance in choosing a port obfuscation 938 algorithm. 940 5. Security Considerations 942 Obfuscating ephemeral ports is no replacement for cryptographic 943 mechanisms, such as IPsec [RFC4301], in terms of protecting 944 transport-protocol instances against blind attacks. 946 An eavesdropper, which can monitor the packets that correspond to the 947 transport-protocol instance to be attacked could learn the IP 948 addresses and port numbers in use (and also sequence numbers etc.) 949 and easily perform an attack. Ephemeral port obfuscation does not 950 provide any additional protection against this kind of attacks. In 951 such situations, proper authentication mechanisms such as those 952 described in [RFC4301] should be used. 954 If the local offset function F() results in identical offsets for 955 different inputs, the port-offset mechanism proposed in this document 956 has no or reduced effect. 958 If random numbers are used as the only source of the secret key, they 959 must be chosen in accordance with the recommendations given in 960 [RFC4086]. 962 If an attacker uses dynamically assigned IP addresses, the current 963 ephemeral port offset (Algorithm 3 and Algorithm 4) for a given five- 964 tuple can be sampled and subsequently used to attack an innocent peer 965 reusing this address. However, this is only possible until a re- 966 keying happens as described above. Also, since ephemeral ports are 967 only used on the client side (e.g. the one initiating the transport- 968 protocol communication), both the attacker and the new peer need to 969 act as servers in the scenario just described. While servers using 970 dynamic IP addresses exist, they are not very common and with an 971 appropriate re-keying mechanism the effect of this attack is limited. 973 6. IANA Considerations 975 There are no IANA registries within this document. The RFC-Editor 976 can remove this section before publication of this document as an 977 RFC. 979 7. Acknowledgements 981 The offset function was inspired by the mechanism proposed by Steven 982 Bellovin in [RFC1948] for defending against TCP sequence number 983 attacks. 985 The authors would like to thank (in alphabetical order) Mark Allman, 986 Matthias Bethke, Stephane Bortzmeyer, Brian Carpenter, Vincent 987 Deffontaines, Lars Eggert, Gorry Fairhurst, Guillermo Gont, Alfred 988 Hoenes, Amit Klein, Carlos Pignataro, Kacheong Poon, Pasi Sarolahti, 989 Randall Stewart, Joe Touch, Michael Tuexen, and Dan Wing for their 990 valuable feedback on earlier versions of this document. 992 The authors would like to thank FreeBSD's Mike Silbersack for a very 993 fruitful discussion about ephemeral port selection techniques. 995 Fernando Gont would like to thank Carolina Suarez for her love and 996 support. 998 8. References 1000 8.1. Normative References 1002 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 1003 August 1980. 1005 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 1006 RFC 793, September 1981. 1008 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 1009 April 1992. 1011 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1012 Requirement Levels", BCP 14, RFC 2119, March 1997. 1014 [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 1015 Signature Option", RFC 2385, August 1998. 1017 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 1018 Jacobson, "RTP: A Transport Protocol for Real-Time 1019 Applications", STD 64, RFC 3550, July 2003. 1021 [RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute 1022 in Session Description Protocol (SDP)", RFC 3605, 1023 October 2003. 1025 [RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and 1026 G. Fairhurst, "The Lightweight User Datagram Protocol 1027 (UDP-Lite)", RFC 3828, July 2004. 1029 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 1030 Requirements for Security", BCP 106, RFC 4086, June 2005. 1032 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1033 Internet Protocol", RFC 4301, December 2005. 1035 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 1036 Congestion Control Protocol (DCCP)", RFC 4340, March 2006. 1038 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", 1039 RFC 4960, September 2007. 1041 8.2. Informative References 1043 [FreeBSD] The FreeBSD Project, "http://www.freebsd.org". 1045 [IANA] "IANA Port Numbers", 1046 . 1048 [I-D.ietf-tcpm-icmp-attacks] 1049 Gont, F., "ICMP attacks against TCP", 1050 draft-ietf-tcpm-icmp-attacks-10 (work in progress), 1051 January 2010. 1053 [RFC1337] Braden, B., "TIME-WAIT Assassination Hazards in TCP", 1054 RFC 1337, May 1992. 1056 [RFC1948] Bellovin, S., "Defending Against Sequence Number Attacks", 1057 RFC 1948, May 1996. 1059 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address 1060 Translator (NAT) Terminology and Considerations", 1061 RFC 2663, August 1999. 1063 [RFC4953] Touch, J., "Defending TCP Against Spoofing Attacks", 1064 RFC 4953, July 2007. 1066 [I-D.ietf-tsvwg-sctpsocket] 1067 Stewart, R., Poon, K., Tuexen, M., Yasevich, V., and P. 1068 Lei, "Sockets API Extensions for Stream Control 1069 Transmission Protocol (SCTP)", 1070 draft-ietf-tsvwg-sctpsocket-21 (work in progress), 1071 February 2010. 1073 [Allman] Allman, M., "Comments On Selecting Ephemeral Ports", ACM 1074 Computer Communication Review, 39(2), 2009. 1076 [CPNI-TCP] 1077 Gont, F., "CPNI Technical Note 3/2009: Security Assessment 1078 of the Transmission Control Protocol (TCP)", UK Centre 1079 for the Protection of National Infrastructure, 2009. 1081 [I-D.gont-tcp-security] 1082 Gont, F., "Security Assessment of the Transmission Control 1083 Protocol (TCP)", draft-gont-tcp-security-00 (work in 1084 progress), February 2009. 1086 [Linux] The Linux Project, "http://www.kernel.org". 1088 [NetBSD] The NetBSD Project, "http://www.netbsd.org". 1090 [OpenBSD] The OpenBSD Project, "http://www.openbsd.org". 1092 [OpenSolaris] 1093 OpenSolaris, "http://www.opensolaris.org". 1095 [Silbersack] 1096 Silbersack, M., "Improving TCP/IP security through 1097 randomization without sacrificing interoperability.", 1098 EuroBSDCon 2005 Conference . 1100 [Stevens] Stevens, W., "Unix Network Programming, Volume 1: 1101 Networking APIs: Socket and XTI", Prentice Hall , 1998. 1103 [I-D.ietf-tcpm-tcp-auth-opt] 1104 Touch, J., Mankin, A., and R. Bonica, "The TCP 1105 Authentication Option", draft-ietf-tcpm-tcp-auth-opt-10 1106 (work in progress), January 2010. 1108 [Watson] Watson, P., "Slipping in the Window: TCP Reset Attacks", 1109 CanSecWest 2004 Conference . 1111 Appendix A. Survey of the algorithms in use by some popular 1112 implementations 1114 A.1. FreeBSD 1116 FreeBSD 8.0 implements Algorithm 1, and in response to this document 1117 now uses a 'min_port' of 10000 and a 'max_port' of 65535. [FreeBSD] 1119 A.2. Linux 1121 Linux 2.6.15-53-386 implements Algorithm 3. If the algorithm is 1122 faced with the corner-case scenario described in Section 3.5, 1123 Algorithm 1 is used instead [Linux]. 1125 A.3. NetBSD 1127 NetBSD 5.0.1 does not obfuscate its ephemeral port numbers. It 1128 selects ephemeral port numbers from the range 49152-65535, starting 1129 from port 65535, and decreasing the port number for each ephemeral 1130 port number selected [NetBSD]. 1132 A.4. OpenBSD 1134 OpenBSD 4.2 implements Algorithm 1, with a 'min_port' of 1024 and a 1135 'max_port' of 49151. [OpenBSD] 1137 A.5. OpenSolaris 1139 OpenSolaris 2009.06 implements Algorithm 1, with a 'min_port' of 1140 32768 and a 'max_port' of 65535. [OpenSolaris] 1142 Appendix B. Changes from previous versions of the draft (to be removed 1143 by the RFC Editor before publication of this document as a 1144 RFC 1146 B.1. Changes from draft-ietf-tsvwg-port-randomization-05 1148 o Addresses AD review feedback from Lars Eggert. 1150 B.2. Changes from draft-ietf-tsvwg-port-randomization-04 1152 o Fixes nits. 1154 B.3. Changes from draft-ietf-tsvwg-port-randomization-03 1156 o Addresses WGLC comments from Mark Allman. See: 1157 http://www.ietf.org/mail-archive/web/tsvwg/current/msg09149.html 1159 B.4. Changes from draft-ietf-tsvwg-port-randomization-02 1161 o Added clarification of what we mean by "port randomization". 1163 o Addresses feedback sent on-list and off-list by Mark Allman. 1165 o Added references to [Allman] and [CPNI-TCP]. 1167 B.5. Changes from draft-ietf-tsvwg-port-randomization-01 1169 o Added Section 2.3. 1171 o Added discussion of "lazy binding in Section 3.5. 1173 o Added discussion of obtaining the number of outgoing connections. 1175 o Miscellaneous editorial changes 1177 B.6. Changes from draft-ietf-tsvwg-port-randomization-00 1179 o Added Section 3.1. 1181 o Changed Intended Status from "Standards Track" to "BCP". 1183 o Miscellaneous editorial changes. 1185 B.7. Changes from draft-larsen-tsvwg-port-randomization-02 1187 o Draft resubmitted as draft-ietf. 1189 o Included references and text on protocols other than TCP. 1191 o Added the second variant of the simple port randomization 1192 algorithm 1194 o Reorganized the algorithms into different sections 1196 o Miscellaneous editorial changes. 1198 B.8. Changes from draft-larsen-tsvwg-port-randomization-01 1200 o No changes. Draft resubmitted after expiration. 1202 B.9. Changes from draft-larsen-tsvwg-port-randomization-00 1204 o Fixed a bug in expressions used to calculate number of ephemeral 1205 ports 1207 o Added a survey of the algorithms in use by popular TCP 1208 implementations 1210 o The whole document was reorganized 1212 o Miscellaneous editorial changes 1214 B.10. Changes from draft-larsen-tsvwg-port-randomisation-00 1216 o Document resubmitted after original document by M. Larsen expired 1217 in 2004 1219 o References were included to current WG documents of the TCPM WG 1221 o The document was made more general, to apply to all transport 1222 protocols 1224 o Miscellaneous editorial changes 1226 Authors' Addresses 1228 Michael Vittrup Larsen 1229 TietoEnator 1230 Skanderborgvej 232 1231 Aarhus DK-8260 1232 Denmark 1234 Phone: +45 8938 5100 1235 Email: michael.larsen@tietoenator.com 1237 Fernando Gont 1238 Universidad Tecnologica Nacional / Facultad Regional Haedo 1239 Evaristo Carriego 2644 1240 Haedo, Provincia de Buenos Aires 1706 1241 Argentina 1243 Phone: +54 11 4650 8472 1244 Email: fernando@gont.com.ar