idnits 2.17.1 draft-ietf-tsvwg-port-randomization-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. 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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 4 instances of too long lines in the document, the longest one being 16 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 11, 2009) is 5518 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 1948 (Obsoleted by RFC 6528) ** Obsolete normative reference: RFC 2385 (Obsoleted by RFC 5925) ** Downref: Normative reference to an Informational RFC: RFC 2663 ** Obsolete normative reference: RFC 4960 (Obsoleted by RFC 9260) == Outdated reference: A later version (-12) exists of draft-ietf-tcpm-icmp-attacks-04 == Outdated reference: A later version (-11) exists of draft-ietf-tcpm-tcp-auth-opt-04 Summary: 9 errors (**), 0 flaws (~~), 3 warnings (==), 3 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: September 12, 2009 March 11, 2009 8 Port Randomization 9 draft-ietf-tsvwg-port-randomization-03 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on September 12, 2009. 34 Copyright Notice 36 Copyright (c) 2009 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents in effect on the date of 41 publication of this document (http://trustee.ietf.org/license-info). 42 Please review these documents carefully, as they describe your rights 43 and restrictions with respect to this document. 45 Abstract 47 Recently, awareness has been raised about a number of "blind" attacks 48 that can be performed against the Transmission Control Protocol (TCP) 49 and similar protocols. The consequences of these attacks range from 50 throughput-reduction to broken connections or data corruption. These 51 attacks rely on the attacker's ability to guess or know the five- 52 tuple (Protocol, Source Address, Destination Address, Source Port, 53 Destination Port) that identifies the transport protocol instance to 54 be attacked. This document describes a number of simple and 55 efficient methods for the selection of the client port number, such 56 that the possibility of an attacker guessing the exact value is 57 reduced. While this is not a replacement for cryptographic methods 58 for protecting the connection, the described port number obfuscation 59 algorithms provide improved security/obfuscation with very little 60 effort and without any key management overhead. The algorithms 61 described in this document are local policies that may be 62 incrementally deployed, and that do not violate the specifications of 63 any of the transport protocols that may benefit from them, such as 64 TCP, UDP, UDP-lite, SCTP, DCCP, and RTP. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 2. Ephemeral Ports . . . . . . . . . . . . . . . . . . . . . . . 6 70 2.1. Traditional Ephemeral Port Range . . . . . . . . . . . . . 6 71 2.2. Ephemeral port selection . . . . . . . . . . . . . . . . . 6 72 2.3. Collision of connection-id's . . . . . . . . . . . . . . . 7 73 3. Randomizing the Ephemeral Ports . . . . . . . . . . . . . . . 9 74 3.1. Characteristics of a good ephemeral port randomization 75 algorithm . . . . . . . . . . . . . . . . . . . . . . . . 9 76 3.2. Ephemeral port number range . . . . . . . . . . . . . . . 10 77 3.3. Ephemeral Port Randomization Algorithms . . . . . . . . . 11 78 3.3.1. Algorithm 1: Simple port randomization algorithm . . . 11 79 3.3.2. Algorithm 2: Another simple port randomization 80 algorithm . . . . . . . . . . . . . . . . . . . . . . 13 81 3.3.3. Algorithm 3: Simple hash-based algorithm . . . . . . . 13 82 3.3.4. Algorithm 4: Double-hash randomization algorithm . . . 15 83 3.3.5. Algorithm 5: Random-increments port selection 84 algorithm . . . . . . . . . . . . . . . . . . . . . . 17 85 3.4. Secret-key considerations for hash-based port 86 randomization algorithms . . . . . . . . . . . . . . . . . 18 87 3.5. Choosing an ephemeral port randomization algorithm . . . . 19 88 4. Port randomization and Network Address Port Translation 89 (NAPT) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 90 5. Security Considerations . . . . . . . . . . . . . . . . . . . 23 91 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24 92 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 93 7.1. Normative References . . . . . . . . . . . . . . . . . . . 25 94 7.2. Informative References . . . . . . . . . . . . . . . . . . 26 95 Appendix A. Survey of the algorithms in use by some popular 96 implementations . . . . . . . . . . . . . . . . . . . 28 97 A.1. FreeBSD . . . . . . . . . . . . . . . . . . . . . . . . . 28 98 A.2. Linux . . . . . . . . . . . . . . . . . . . . . . . . . . 28 99 A.3. NetBSD . . . . . . . . . . . . . . . . . . . . . . . . . . 28 100 A.4. OpenBSD . . . . . . . . . . . . . . . . . . . . . . . . . 28 101 Appendix B. Changes from previous versions of the draft . . . . . 29 102 B.1. Changes from draft-ietf-tsvwg-port-randomization-02 . . . 29 103 B.2. Changes from draft-ietf-tsvwg-port-randomization-01 . . . 29 104 B.3. Changes from draft-ietf-tsvwg-port-randomization-00 . . . 29 105 B.4. Changes from draft-larsen-tsvwg-port-randomization-02 . . 29 106 B.5. Changes from draft-larsen-tsvwg-port-randomization-01 . . 29 107 B.6. Changes from draft-larsen-tsvwg-port-randomization-00 . . 30 108 B.7. Changes from draft-larsen-tsvwg-port-randomisation-00 . . 30 109 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31 111 1. Introduction 113 Recently, awareness has been raised about a number of "blind" attacks 114 (i.e., attacks that can be performed without the need to sniff the 115 packets that correspond to the transport protocol instance to be 116 attacked) that can be performed against the Transmission Control 117 Protocol (TCP) [RFC0793] and similar protocols. The consequences of 118 these attacks range from throughput-reduction to broken connections 119 or data corruption [I-D.ietf-tcpm-icmp-attacks] [RFC4953] [Watson]. 121 All these attacks rely on the attacker's ability to guess or know the 122 five-tuple (Protocol, Source Address, Source port, Destination 123 Address, Destination Port) that identifies the transport protocol 124 instance to be attacked. 126 Services are usually located at fixed, 'well-known' ports [IANA] at 127 the host supplying the service (the server). Client applications 128 connecting to any such service will contact the server by specifying 129 the server IP address and service port number. The IP address and 130 port number of the client are normally left unspecified by the client 131 application and thus chosen automatically by the client networking 132 stack. Ports chosen automatically by the networking stack are known 133 as ephemeral ports [Stevens]. 135 While the server IP address and well-known port and the client IP 136 address may be accurately guessed by an attacker, the ephemeral port 137 of the client is usually unknown and must be guessed. 139 This document describes a number of algorithms for the selection of 140 the ephemeral ports, such that the possibility of an off-path 141 attacker guessing the exact value is reduced. They are not a 142 replacement for cryptographic methods of protecting a connection such 143 as IPsec [RFC4301], the TCP MD5 signature option [RFC2385], or the 144 TCP Authentication Option [I-D.ietf-tcpm-tcp-auth-opt]. For example, 145 they do not provide any mitigation in those scenarios in which the 146 attacker is able to sniff the packets that correspond to the 147 transport protocol connection to be attacked. However, the proposed 148 algorithms provide improved obfuscation with very little effort and 149 without any key management overhead. 151 The mechanisms described in this document are local modifications 152 that may be incrementally deployed, and that does not violate the 153 specifications of any of the transport protocols that may benefit 154 from it, such as TCP [RFC0793], UDP [RFC0768], SCTP [RFC4960], DCCP 155 [RFC4340], UDP-lite [RFC3828], and RTP [RFC3550]. 157 Since these mechanisms are obfuscation techniques, focus has been on 158 a reasonable compromise between the level of obfuscation and the ease 159 of implementation. Thus the algorithms must be computationally 160 efficient, and not require substantial state. 162 We note that while the technique of mitigating "blind" attacks by 163 obfuscating the ephemeral port election is well-known as "port 164 randomization", the goal of the algorithms described in tihs document 165 is to reduce the chances of an attacker guessing the ephemeral ports 166 selected for new connections, rather than to actually produce a 167 random sequences of ephemeral ports. 169 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 170 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 171 document are to be interpreted as described in RFC 2119 [RFC2119]. 173 2. Ephemeral Ports 175 2.1. Traditional Ephemeral Port Range 177 The Internet Assigned Numbers Authority (IANA) assigns the unique 178 parameters and values used in protocols developed by the Internet 179 Engineering Task Force (IETF), including well-known ports [IANA]. 180 IANA has traditionally reserved the following use of the 16-bit port 181 range of TCP and UDP: 183 o The Well Known Ports, 0 through 1023. 185 o The Registered Ports, 1024 through 49151 187 o The Dynamic and/or Private Ports, 49152 through 65535 189 The range for assigned ports managed by the IANA is 0-1023, with the 190 remainder being registered by IANA but not assigned. 192 The ephemeral port range has traditionally consisted of the 49152- 193 65535 range. 195 2.2. Ephemeral port selection 197 As each communication instance is identified by the five-tuple 198 {protocol, local IP address, local port, remote IP address, remote 199 port}, the selection of ephemeral port numbers must result in a 200 unique five-tuple. 202 Selection of ephemeral ports such that they result in unique five- 203 tuples is handled by some implementations by having a per-protocol 204 global 'next_ephemeral' variable that is equal to the previously 205 chosen ephemeral port + 1, i.e. the selection process is: 207 /* Initialization at system boot time. Initialization value could be random */ 208 next_ephemeral = min_ephemeral; 210 /* Ephemeral port selection function */ 211 count = max_ephemeral - min_ephemeral + 1; 213 do { 214 port = next_ephemeral; 215 if (next_ephemeral == max_ephemeral) { 216 next_ephemeral = min_ephemeral; 217 } else { 218 next_ephemeral++; 219 } 221 if (five-tuple is unique) 222 return port; 224 count--; 226 } while (count > 0); 228 return ERROR; 230 Figure 1 232 This algorithm works well provided that the number of connections for 233 a each transport protocol that have a life-time longer than it takes 234 to exhaust the total ephemeral port range is small, so that five- 235 tuple collisions are rare. 237 However, this method has the drawback that the 'next_ephemeral' 238 variable and thus the ephemeral port range is shared between all 239 connections and the next ports chosen by the client are easy to 240 predict. If an attacker operates an "innocent" server to which the 241 client connects, it is easy to obtain a reference point for the 242 current value of the 'next_ephemeral' variable. Additionally, if an 243 attacker could force a client to periodically establish a new TCP 244 connection to an attacker controlled machine (or through an attacker 245 observable routing path), the attacker could subtract consecutive 246 source port values to obtain the number of outoing TCP connections 247 established globally by the target host within that time period (up 248 to wrap-around issues and 5-tuple collisions, of course). 250 2.3. Collision of connection-id's 252 While it is possible for the ephemeral port selection algorithm to 253 verify that the selected port number results in connection-id that is 254 not currently in use at that system, the resulting connection-id may 255 still be in use at a remote system. For example, consider a scenario 256 in which a client establishes a TCP connection with a remote web 257 server, and the web server performs the active close on the 258 connection. While the state information for this connection will 259 disappear at the client side (that is, the connection will be moved 260 to the fictional CLOSED state), the connection-id will remain in the 261 TIME-WAIT state at the web server for 2*MSL (Maximum Segment 262 Lifetime). If the same client tried to create a new incarnation of 263 the previous connection (that is, a connection with the same 264 connection-id as the one in the TIME_WAIT state at the server), a 265 connection-id "collision" would occur. The effect of these 266 collisions range from connection-establishment failures to TIME-WAIT 267 state assassination (with the potential of data corruption) 268 [RFC1337]. In scenarios in which a specific client establishes TCP 269 connections with a specific service at a server, these problems 270 become evident. Therefore, an ephemeral port selection algorithm 271 should ideally minimize the rate of connection-id collisions. 273 A simple approach to minimize the rate of these collisions would be 274 to choose port numbers incrementally, so that a given port number 275 would not be reused until the rest of the port numbers in ephemeral 276 port range have been used for a transport protocol instance. 277 However, if a single global variable were used to keep track of the 278 last ephemeral port selected, ephemeral port numbers would be 279 trivially predictable, thus making it easier for an off-path attacker 280 to "guess" the connection-id in use by a target connection. 282 3. Randomizing the Ephemeral Ports 284 3.1. Characteristics of a good ephemeral port randomization algorithm 286 There are a number of factors to consider when designing a policy of 287 selection of ephemeral ports, which include: 289 o Minimizing the predictability of the ephemeral port numbers used 290 for future connections. 292 o Minimizing collisions of connection-id's 294 o Avoiding conflict with applications that depend on the use of 295 specific port numbers. 297 Given the goal of improving the transport protocol's resistance to 298 attack by obfuscation of the five-tuple that identifies a transport- 299 protocol instance, it is key to minimize the predictability of the 300 ephemeral ports that will be selected for new connections. While the 301 obvious approach to address this requirement would be to select the 302 ephemeral ports by simply picking a random value within the chosen 303 port number range, this straightforward policy may lead to collisions 304 of connection-id's, which could lead to the interoperability problems 305 discussed in Section 2.3. As discussed in Section 1, it is worth 306 noting that while the technique of mitigating "blind" attacks by 307 obfuscating the ephemeral port election is well-known as "port 308 randomization", the goal of the algorithms described in this document 309 is to reduce the chances of an attacker guessing the ephemeral ports 310 selected for new connections, rather than to actually produce 311 sequences of random ephemeral ports. 313 It is also worth noting that, provided adequate algorithms are in 314 use, the larger the range from which ephemeral pots are selected, the 315 smaller the chances of an attacker are to guess the selected port 316 number. 318 In scenarios in which a specific client establishes connections with 319 a specific service at a server, the problems described in Section 2.3 320 become evident. A good algorithm to minimize the collisions of 321 connection-id's would consider the time a given five-tuple was last 322 used, and would avoid reusing the last recently used five-tuples. A 323 simple approach to minimize the rate of collisions would be to choose 324 port numbers incrementally, so that a given port number would not be 325 reused until the rest of the port numbers in the ephemeral port range 326 have been used for a transport protocol instance. However, if a 327 single global variable were used to keep track of the last ephemeral 328 port selected, ephemeral port numbers would be trivially predictable. 330 It is important to note that a number of applications rely on binding 331 specific port numbers that may be within the ephemeral ports range. 332 If such an application was run while the corresponding port number 333 was in use, the application would fail. Therefore, transport 334 protocols should avoid using those port numbers as ephemeral ports. 336 Port numbers that are currently in use by a TCP in the LISTEN state 337 should not be allowed for use as ephemeral ports. If this rule is 338 not complied, an attacker could potentially "steal" an incoming 339 connection to a local server application by issuing a connection 340 request to the victim client at roughly the same time the client 341 tries to connect to the victim server application [CPNI-TCP] 342 [I-D.gont-tcp-security]. If the SYN segment corresponding to the 343 attacker's connection request and the SYN segment corresponding to 344 the victim client "cross each other in the network", and provided the 345 attacker is able to know or guess the ephemeral port used by the 346 client, a TCP simultaneous open scenario would take place, and the 347 incoming connection request sent by the client would be matched with 348 the attacker's socket rather than with the victim server 349 application's socket. 351 It should be noted that most applications based on popular 352 implementations of TCP API (such as the Sockets API) perform "passive 353 opens" in three steps. Firstly, the application obtains a file 354 descriptor to be used for inter-process communication (e.g., by 355 issuing a socket() call). Secondly, the application binds the file 356 descriptor to a local TCP port number (e.g., by issuing a bind() 357 call), thus creating a TCP in the fictional CLOSED state. Thirdly, 358 the aforementioned TCP is put in the LISTEN state (e.g., by issuing a 359 listen() call). As a result, with such an implementation of the TCP 360 API, even if port numbers in use for TCPs in the LISTEN state were 361 not allowed for use as ephemeral ports, there is a window of time 362 between the second and the third steps in which an attacker could be 363 allowed to select a port number that would be later used for 364 listening to incoming connections. Therefore, these implementations 365 of the TCP API should enforce a stricter requirement for the 366 allocation of port numbers: port numbers that are in use by a TCP in 367 the LISTEN or CLOSED states should not be allowed for allocation as 368 ephemeral ports [CPNI-TCP] [I-D.gont-tcp-security]. 370 3.2. Ephemeral port number range 372 As mentioned in Section 2.1, the ephemeral port range has 373 traditionally consisted of the 49152-65535 range. However, it should 374 also include the range 1024-49151 range. 376 Since this range includes user-specific server ports, this may not 377 always be possible, though. A possible workaround for this potential 378 problem would be to maintain an array of bits, in which each bit 379 would correspond to each of the port numbers in the range 1024-65535. 380 A bit set to 0 would indicate that the corresponding port is 381 available for allocation, while a bit set to one would indicate that 382 the port is reserved and therefore cannot be allocated. Thus, before 383 allocating a port number, the ephemeral port selection function would 384 check this array of bits, avoiding the allocation of ports that may 385 be needed for specific applications. 387 Transport protocols SHOULD use the largest possible port range, since 388 this improves the obfuscation provided by randomizing the ephemeral 389 ports. 391 3.3. Ephemeral Port Randomization Algorithms 393 Transport protocols SHOULD allocate their ephemeral ports randomly, 394 since this help to mitigate a number of attacks that depend on the 395 attacker's ability to guess or know the five-tuple that identifies 396 the transport protocol instance to be attacked. 398 The following subsections describe a number of algorithms that could 399 be implemented in order to obfuscate the selection of ephemeral port 400 numbers. 402 3.3.1. Algorithm 1: Simple port randomization algorithm 404 In order to address the security issues discussed in Section 1 and 405 Section 2.2, a number of systems have implemented simple ephemeral 406 port number randomization, as follows: 408 /* Ephemeral port selection function */ 409 num_ephemeral = max_ephemeral - min_ephemeral + 1; 410 next_ephemeral = min_ephemeral + (random() % num_ephemeral); 411 count = num_ephemeral; 413 do { 414 if(five-tuple is unique) 415 return next_ephemeral; 417 if (next_ephemeral == max_ephemeral) { 418 next_ephemeral = min_ephemeral; 419 } else { 420 next_ephemeral++; 421 } 423 count--; 424 } while (count > 0); 426 return ERROR; 428 Figure 2 430 We will refer to this algorithm as 'Algorithm 1'. 432 Since the initially chosen port may already be in use with identical 433 IP addresses and server port, the resulting five-tuple might not be 434 unique. Therefore, multiple ports may have to be tried and verified 435 against all existing connections before a port can be chosen. 436 Although carefully chosen random sources and optimized five-tuple 437 lookup mechanisms (e.g., optimized through hashing) will mitigate the 438 cost of this verification, some systems may still not want to incur 439 this search time. 441 Systems that may be especially susceptible to this kind of repeated 442 five-tuple collisions are those that create many connections from a 443 single local IP address to a single service (i.e. both of the IP 444 addresses and the server port are fixed). Web proxy servers and 445 NAPTs [RFC2663] are an examples of such systems. 447 Since this algorithm performs a completely random port selection 448 (i.e., without taking into account the port numbers previously 449 chosen), it has the potential of reusing port numbers too quickly, 450 thus possibly leading to collisions of connection-id's. Even if a 451 given five-tuple is verified to be unique by the port selection 452 algorithm, the five-tuple might still be in use at the remote system. 453 In such a scenario, the connection request could possibly fail 454 ([Silbersack] describes this problem for the TCP case). 456 This algorithm selects ephemeral port numbers randomly and thus 457 reduces the chances of an attacker of guessing the ephemeral port 458 selected for a target connection. Additionally, it prevents 459 attackers from obtaining the number of outgoing connections 460 established by the client in some period of time. 462 3.3.2. Algorithm 2: Another simple port randomization algorithm 464 Another algorithm for selecting a random port number is shown in 465 Figure 3, in which in the event a local connection-id collision is 466 detected, another port number is selected randomly, 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(five-tuple is unique) 475 return next_ephemeral; 477 next_ephemeral = min_ephemeral + (random() % num_ephemeral); 478 count--; 479 } while (count > 0); 481 return ERROR; 483 Figure 3 485 We will refer to this algorithm as 'Algorithm 2'. The difference 486 between this algorithm and Algorithm 1 is that the search time for 487 this variant may be longer than for the latter, particularly when 488 there is a large number of port numbers already in use. Also, this 489 algorithm may be unable to select an ephemeral port (i.e., return 490 "ERROR") even if there are port numbers that would result in unique 491 five-tuples, particularly when there are a large number of port 492 numbers already in use. 494 3.3.3. Algorithm 3: Simple hash-based algorithm 496 We would like to achieve the port reuse properties of the traditional 497 BSD port selection algorithm, while at the same time achieve the 498 obfuscation properties of Algorithm 1 and Algorithm 2. 500 Ideally, we would like a 'next_ephemeral' value for each set of 501 (local IP address, remote IP addresses, remote port), so that the 502 port reuse frequency is the lowest possible. Each of these 503 'next_ephemeral' variables should be initialized with random values 504 within the ephemeral port range and would thus separate the ephemeral 505 port ranges of the connections entirely. Since we do not want to 506 maintain in memory all these 'next_ephemeral' values, we propose an 507 offset function F(), that can be computed from the local IP address, 508 remote IP address, remote port and a secret key. F() will yield 509 (practically) different values for each set of arguments, i.e.: 511 /* Initialization code at system boot time. Initialization value could be random. */ 512 next_ephemeral = 0; 514 /* Ephemeral port selection function */ 515 num_ephemeral = max_ephemeral - min_ephemeral + 1; 516 offset = F(local_IP, remote_IP, remote_port, secret_key); 517 count = num_ephemeral; 519 do { 520 port = min_ephemeral + (next_ephemeral + offset) % num_ephemeral; 521 next_ephemeral++; 523 if(five-tuple is unique) 524 return port; 526 count--; 528 } while (count > 0); 530 return ERROR; 532 Figure 4 534 We will refer to this algorithm as 'Algorithm 3'. 536 In other words, the function F() provides a per-connection fixed 537 offset within the global ephemeral port range. Both the 'offset' and 538 'next_ephemeral' variables may take any value within the storage type 539 range since we are restricting the resulting port similar to that 540 shown in Figure 3. This allows us to simply increment the 541 'next_ephemeral' variable and rely on the unsigned integer to simply 542 wrap-around. 544 The function F() should be a cryptographic hash function like MD5 545 [RFC1321]. The function should use both IP addresses, the remote 546 port and a secret key value to compute the offset. The remote IP 547 address is the primary separator and must be included in the offset 548 calculation. The local IP address and remote port may in some cases 549 be constant and not improve the connection separation, however, they 550 should also be included in the offset calculation. 552 Cryptographic algorithms stronger than e.g. MD5 should not be 553 necessary, given that port randomization is simply an obfuscation 554 technique. The secret should be chosen as random as possible, see 555 [RFC4086] for recommendations on choosing secrets. 557 Note that on multiuser systems, the function F() could include user 558 specific information, thereby providing protection not only on a host 559 to host basis, but on a user to service basis. In fact, any 560 identifier of the remote entity could be used, depending on 561 availability an the granularity requested. With SCTP both hostnames 562 and alternative IP addresses may be included in the association 563 negotiation and either of these could be used in the offset function 564 F(). 566 When multiple unique identifiers are available, any of these can be 567 chosen as input to the offset function F() since they all uniquely 568 identify the remote entity. However, in cases like SCTP where the 569 ephemeral port must be unique across all IP address permutations, we 570 should ideally always use the same IP address to get a single 571 starting offset for each association negotiation from a given remote 572 entity to minimize the possibility of collisions. A simple numerical 573 sorting of the IP addresses and always using the numerically lowest 574 could achieve this. However, since most protocols most likely will 575 report the same IP addresses in the same order in each association 576 setup, this sorting is most likely not necessary and the 'first one' 577 can simply be used. 579 The ability of hostnames to uniquely define hosts can be discussed, 580 and since SCTP always includes at least one IP address, we recommend 581 to use this as input to the offset function F() and ignore hostnames 582 chunks when searching for ephemeral ports. 584 It should be note that, as this algorithm uses a global counter 585 ("next_ephemeral") for selecting ephemeral ports, if an attacker 586 could force a client to periodically establish a new TCP connection 587 to an attacker controlled machine (or through an attacker observable 588 routing path), the attacker could subtract consecutive source port 589 values to obtain the number of outoing TCP connections established 590 globally by the target host within that time period (up to wrap- 591 around issues and 5-tuple collisions, of course). 593 3.3.4. Algorithm 4: Double-hash randomization algorithm 595 A tradeoff between maintaining a single global 'next_ephemeral' 596 variable and maintaining 2**N 'next_ephemeral' variables (where N is 597 the width of of the result of F()) could be achieved as follows. The 598 system would keep an array of TABLE_LENGTH short integers, which 599 would provide a separation of the increment of the 'next_ephemeral' 600 variable. This improvement could be incorporated into Algorithm 3 as 601 follows: 603 /* Initialization at system boot time */ 604 for(i = 0; i < TABLE_LENGTH; i++) 605 table[i] = random() % 65536; 607 /* Ephemeral port selection function */ 608 num_ephemeral = max_ephemeral - min_ephemeral + 1; 609 offset = F(local_IP, remote_IP, remote_port, secret_key1); 610 index = G(local_IP, remote_IP, remote_port, secret_key2); 611 count = num_ephemeral; 613 do { 614 port = min_ephemeral + (offset + table[index]) % num_ephemeral; 615 table[index]++; 617 if(five-tuple is unique) 618 return port; 620 count--; 622 } while (count > 0); 624 return ERROR; 626 Figure 5 628 We will refer to this algorithm as 'Algorithm 4'. 630 'table[]' could be initialized with random values, as indicated by 631 the initialization code in Figure 5. The function G() should be a 632 cryptographic hash function like MD5 [RFC1321]. It should use both 633 IP addresses, the remote port and a secret key value to compute a 634 value between 0 and (TABLE_LENGTH-1). Alternatively, G() could take 635 as "offset" as input, and perform the exclusive-or (xor) operation 636 between all the bytes in 'offset'. 638 The array 'table[]' assures that succesive connections to the same 639 end-point will use increasing ephemeral port numbers. However, 640 incrementation of the port numbers is separated into TABLE_LENGTH 641 different spaces, and thus the port reuse frequency will be 642 (probabilistically) lower than that of Algorithm 3. That is, a 643 connection established with some remote end-point will not 644 necessarily cause the 'next_ephemeral' variable corresponding to 645 other end-points to be incremented. 647 It is interesting to note that the size of 'table[]' does not limit 648 the number of different port sequences, but rather separates the 649 *increments* into TABLE_LENGTH different spaces. The port sequence 650 will result from adding the corresponding entry of 'table[]' to the 651 variable 'offset', which selects the actual port sequence (as in 652 Algorithm 3). [Allman] has found that even a TABLE_LENGTH of 10 can 653 result in an improvement over Algorithm 3. Considering the amount of 654 memory available in most general-purpose systems recommend a 655 TABLE_LENGTH of 1024 for such systems, but note that other systems 656 may choose smaller values for TABLE_LENGTH. 658 An attacker can perform traffic analysis for any "increment space" 659 into which the attacker has "visibility", namely that the attacker 660 can force the client to establish a transport-protocol connection 661 whose G(offset) identifies the target "increment space". However, 662 the attacker's ability to perform traffic analysis is very reduced 663 when compared to the traditional BSD algorithm and Algorithm 3. 664 Additionally, an implementation can further limit the attacker's 665 ability to perform traffic analysis by further separating the 666 increment space (that is, using a larger value for TABLE_LENGTH). 668 3.3.5. Algorithm 5: Random-increments port selection algorithm 670 [Allman] introduced yet another port randomization selection, which 671 offers a middle ground between the algorithms that select ephemeral 672 ports randomly (such as those described in Section 3.3.1 and 673 Section 3.3.2), and those that offer obfuscation but no randomization 674 (such as those described in Section 3.3.3 and Section 3.3.4). We 675 will refer to this algorithm as 'Algorithm 5'. 677 /* Initialization code at system boot time. */ 678 next_ephemeral = 0; /* Initialization value could be random. */ 679 N = 500; /* Determines the tradeoff. Should be configurable */ 681 /* Ephemeral port selection function */ 682 num_ephemeral = max_ephemeral - min_ephemeral + 1; 683 next_ephemeral = next_ephemeral + random(N); 685 count = num_ephemeral; 687 do { 688 port = min_ephemeral + (next_ephemeral % num_ephemeral); 690 if(five-tuple is unique) 691 return port; 693 next_ephemeral++; 695 count--; 696 } while (count > 0); 698 return ERROR; 700 Figure 6 702 The value "N" allows for direct control of the tradeoff between the 703 level of obfuscation and the port reuse frequency. The larger the 704 value of "N", the more similar this algorithm is to the algorithm 705 described in Section 3.3.1 of this document. 707 3.4. Secret-key considerations for hash-based port randomization 708 algorithms 710 Every complex manipulation (like MD5) is no more secure than the 711 input values, and in the case of ephemeral ports, the secret key. If 712 an attacker is aware of which cryptographic hash function is being 713 used by the victim (which we should expect), and the attacker can 714 obtain enough material (e.g. ephemeral ports chosen by the victim), 715 the attacker may simply search the entire secret key space to find 716 matches. 718 To protect against this, the secret key should be of a reasonable 719 length. Key lengths of 32 bits should be adequate, since a 32-bit 720 secret would result in approximately 65k possible secrets if the 721 attacker is able to obtain a single ephemeral port (assuming a good 722 hash function). If the attacker is able to obtain more ephemeral 723 ports, key lengths of 64 bits or more should be used. 725 Another possible mechanism for protecting the secret key is to change 726 it after some time. If the host platform is capable of producing 727 reasonable good random data, the secret key can be changed 728 automatically. 730 Changing the secret will cause abrupt shifts in the chosen ephemeral 731 ports, and consequently collisions may occur. That is, upon changing 732 the secret, the "offset" value (see Figure 4 and Figure 5) used for 733 each destination end-point will be different from that computed with 734 the previous secret, ths leading to the selection of a port number 735 recently used for connecting to the same end-point. 737 Thus the change in secret key should be done with consideration and 738 could be performed whenever one of the following events occur: 740 o The system is being bootstrapped. 742 o Some predefined/random time has expired. 744 o The secret has been used N times (i.e. we consider it insecure). 746 o There are few active connections (i.e., possibility of collision 747 is low). 749 o There is little traffic (the performance overhead of collisions is 750 tolerated). 752 o There is enough random data available to change the secret key 753 (pseudo-random changes should not be done). 755 3.5. Choosing an ephemeral port randomization algorithm 757 [Allman] is an empyrical study of the properties of the algorithms 758 described in this document, which has found that all the algorithms 759 described in this document offer low collision rates -- at most 0.3%. 760 However, these results may vary depending on the characteristics of 761 network traffic and the pecfic network setup. 763 The algorithm sketched in Figure 1 is the traditional ephemeral port 764 selection algorithm implemented in BSD-derived systems. It generates 765 a global sequence of ephemeral port numbers, which makes it trivial 766 for an attacker to predict the port number that will be used for a 767 future transport protocol instance. However, it is very simple, and 768 leads to a low port resuse frequency. 770 Algorithm 1 and Algorithm 2 have the advantage that they provide 771 complete randomization. However, they may increase the chances of 772 port number collisions, which could lead to the failure of the 773 connection establishment attempt. [Allman] found that these two 774 algorithms show the largest collision rates (among all the algorithms 775 described in this document). 777 Algorithm 3 provides complete separation in local and remote IP 778 addresses and remote port space, and only limited separation in other 779 dimensions (see Section 3.4). However, implementations should 780 consider the performance impact of computing the cryptographic hash 781 used for the offset. 783 Algorithm 4 improves Algorithm 3, usually leading to a lower port 784 reuse frequency, at the expense of more processor cycles used for 785 computing G(), and additional kernel memory for storing the array 786 'table[]'. 788 Algorithm 5 offers middle ground between the simple randomization 789 algorithms (Algorithm 1 and Algorthm 2) and the hash-based algorithms 790 (Algorithm 3 and Algorithm 4). The upper limit on the random 791 increments (the value "N" in Figure 6 controls the trade-off between 792 randomization and port-reuse frequency. 794 Finally, a special case that may preclude the utilization of 795 Algorithm 3 and Algorithm 4 should be analyzed. There exist some 796 applications that contain the following code sequence: 798 s = socket(); 799 bind(s, IP_address, port = *); 801 Figure 7 803 In some BSD-derived systems, the call to bind() will result in the 804 selection of an ephemeral port number. However, as neither the 805 remote IP address nor the remote port will be available to the 806 ephemeral port selection function, the hash function F() used in 807 Algorithm 3 and Algorithm 4 will not have all the required arguments, 808 and thus the result of the hash function will be impossible to 809 compute. Transport protocols implementating Algorithm 3 or Algorithm 810 4 should consider using Algorithm 2 when facing the scenario just 811 described. 813 An alternative to this behavior would be to implement "lazy binding" 814 in response to the bind() call. That is, selection of an epphemeral 815 port would be delayed until, e.g., connect() or send() are called. 816 Thus, at that point the ephemeral port is actually selected, all the 817 necessary arguments for the hash function F() would be available, and 818 thus Algorithm 3 and Algorithm 4 could still be used in this 819 scenario. This policy has been implemented by Linux [Linux]. 821 4. Port randomization and Network Address Port Translation (NAPT) 823 Network Address Port Translation (NAPT) translate both the network 824 address and transport-protocol port number, thus allowing the 825 transport identifiers of a number of private hosts to be multiplexed 826 into the transport identifiers of a single external address. 827 [RFC2663] 829 In those scenarios in which a NAPT is present between the two end- 830 points of transport-protocol connection, the obfuscation of the 831 ephemeral ports (from the point of view of the external network) will 832 depend on the ephemeral port selection function at the NAPT. 833 Therefore, NAPTs should consider randomizing the ephemeral ports by 834 means of any of the algorithms discussed in this document. It should 835 be noted that in some network scenarios, a NAPT may naturally obscure 836 ephemeral port selections simply due to the vast range of services 837 with which it establishes connections and to the overall rate of the 838 traffic [Allman]. 840 Section 3.5 provides guidance in choosing a port randomization 841 algorithm. 843 5. Security Considerations 845 Randomizing ports is no replacement for cryptographic mechanisms, 846 such as IPsec [RFC4301], in terms of protecting transport protocol 847 instances against blind attacks. 849 An eavesdropper, which can monitor the packets that correspond to the 850 connection to be attacked could learn the IP addresses and port 851 numbers in use (and also sequence numbers etc.) and easily attack the 852 connection. Randomizing ports does not provide any additional 853 protection against this kind of attacks. In such situations, proper 854 authentication mechanisms such as those described in [RFC4301] should 855 be used. 857 If the local offset function F() results in identical offsets for 858 different inputs, the port-offset mechanism proposed in this document 859 has no or reduced effect. 861 If random numbers are used as the only source of the secret key, they 862 must be chosen in accordance with the recommendations given in 863 [RFC4086]. 865 If an attacker uses dynamically assigned IP addresses, the current 866 ephemeral port offset (Algorithm 3 and Algorithm 4) for a given five- 867 tuple can be sampled and subsequently used to attack an innocent peer 868 reusing this address. However, this is only possible until a re- 869 keying happens as described above. Also, since ephemeral ports are 870 only used on the client side (e.g. the one initiating the 871 connection), both the attacker and the new peer need to act as 872 servers in the scenario just described. While servers using dynamic 873 IP addresses exist, they are not very common and with an appropriate 874 re-keying mechanism the effect of this attack is limited. 876 6. Acknowledgements 878 The offset function was inspired by the mechanism proposed by Steven 879 Bellovin in [RFC1948] for defending against TCP sequence number 880 attacks. 882 The authors would like to thank (in alphabetical order) Mark Allman, 883 Matthias Bethke, Stephane Bortzmeyer, Brian Carpenter, Vincent 884 Deffontaines, Lars Eggert, Gorry Fairhurst, Guillermo Gont, Alfred 885 Hoenes, Amit Klein, Carlos Pignataro, Joe Touch, and Dan Wing for 886 their valuable feedback on earlier versions of this document. 888 The authors would like to thank FreeBSD's Mike Silbersack for a very 889 fruitful discussion about ephemeral port selection techniques. 891 Fernando Gont would like to thank Carolina Suarez for her love and 892 support. 894 7. References 896 7.1. Normative References 898 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 899 August 1980. 901 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 902 RFC 793, September 1981. 904 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 905 April 1992. 907 [RFC1948] Bellovin, S., "Defending Against Sequence Number Attacks", 908 RFC 1948, May 1996. 910 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 911 Requirement Levels", BCP 14, RFC 2119, March 1997. 913 [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 914 Signature Option", RFC 2385, August 1998. 916 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address 917 Translator (NAT) Terminology and Considerations", 918 RFC 2663, August 1999. 920 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 921 Jacobson, "RTP: A Transport Protocol for Real-Time 922 Applications", STD 64, RFC 3550, July 2003. 924 [RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and 925 G. Fairhurst, "The Lightweight User Datagram Protocol 926 (UDP-Lite)", RFC 3828, July 2004. 928 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 929 Requirements for Security", BCP 106, RFC 4086, June 2005. 931 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 932 Internet Protocol", RFC 4301, December 2005. 934 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 935 Congestion Control Protocol (DCCP)", RFC 4340, March 2006. 937 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", 938 RFC 4960, September 2007. 940 7.2. Informative References 942 [FreeBSD] The FreeBSD Project, "http://www.freebsd.org". 944 [IANA] "IANA Port Numbers", 945 . 947 [I-D.ietf-tcpm-icmp-attacks] 948 Gont, F., "ICMP attacks against TCP", 949 draft-ietf-tcpm-icmp-attacks-04 (work in progress), 950 October 2008. 952 [RFC1337] Braden, B., "TIME-WAIT Assassination Hazards in TCP", 953 RFC 1337, May 1992. 955 [RFC4953] Touch, J., "Defending TCP Against Spoofing Attacks", 956 RFC 4953, July 2007. 958 [Allman] Allman, M., "Comments On Selecting Ephemeral Ports", 959 Available at: 960 http://www.icir.org/mallman/papers/ports-ccr09.pdf. 962 [CPNI-TCP] 963 Gont, F., "CPNI Technical Note 3/2009: Security Assessment 964 of the Transmission Control Protocol (TCP)", UK Centre 965 for the Protection of National Infrastructure, 2009. 967 [I-D.gont-tcp-security] 968 Gont, F., "Security Assessment of the Transmission Control 969 Protocol (TCP)", draft-gont-tcp-security-00 (work in 970 progress), February 2009. 972 [Linux] The Linux Project, "http://www.kernel.org". 974 [NetBSD] The NetBSD Project, "http://www.netbsd.org". 976 [OpenBSD] The OpenBSD Project, "http://www.openbsd.org". 978 [Silbersack] 979 Silbersack, M., "Improving TCP/IP security through 980 randomization without sacrificing interoperability.", 981 EuroBSDCon 2005 Conference . 983 [Stevens] Stevens, W., "Unix Network Programming, Volume 1: 984 Networking APIs: Socket and XTI", Prentice Hall , 1998. 986 [I-D.ietf-tcpm-tcp-auth-opt] 987 Touch, J., Mankin, A., and R. Bonica, "The TCP 988 Authentication Option", draft-ietf-tcpm-tcp-auth-opt-04 989 (work in progress), March 2009. 991 [Watson] Watson, P., "Slipping in the Window: TCP Reset Attacks", 992 CanSecWest 2004 Conference . 994 Appendix A. Survey of the algorithms in use by some popular 995 implementations 997 A.1. FreeBSD 999 FreeBSD implements Algorithm 1, and in response to this document now 1000 uses a 'min_port' of 10000 and a 'max_port' of 65535. [FreeBSD] 1002 A.2. Linux 1004 Linux implements Algorithm 3. If the algorithm is faced with the 1005 corner-case scenario described in Section 3.5, Algorithm 1 is used 1006 instead [Linux]. 1008 A.3. NetBSD 1010 NetBSD does not randomize ephemeral port numbers. It selects 1011 ephemeral port numbers from the range 49152-65535, starting from port 1012 65535, and decreasing the port number for each ephemeral port number 1013 selected [NetBSD]. 1015 A.4. OpenBSD 1017 OpenBSD implements Algorithm 1, with a 'min_port' of 1024 and a 1018 'max_port' of 49151. [OpenBSD] 1020 Appendix B. Changes from previous versions of the draft 1022 B.1. Changes from draft-ietf-tsvwg-port-randomization-02 1024 o Added clarification of what we mean by "port randomization". 1026 o Addresses feedback sent on-list and off-list by Mark Allman. 1028 o Added references to [Allman] and [CPNI-TCP]. 1030 B.2. Changes from draft-ietf-tsvwg-port-randomization-01 1032 o Added Section 2.3. 1034 o Added discussion of "lazy binding in Section 3.5. 1036 o Added discussion of obtaining the number of outgoing connections. 1038 o Miscellaneous editorial changes 1040 B.3. Changes from draft-ietf-tsvwg-port-randomization-00 1042 o Added Section 3.1. 1044 o Changed Intended Status from "Standards Track" to "BCP". 1046 o Miscellaneous editorial changes. 1048 B.4. Changes from draft-larsen-tsvwg-port-randomization-02 1050 o Draft resubmitted as draft-ietf. 1052 o Included references and text on protocols other than TCP. 1054 o Added the second variant of the simple port randomization 1055 algorithm 1057 o Reorganized the algorithms into different sections 1059 o Miscellaneous editorial changes. 1061 B.5. Changes from draft-larsen-tsvwg-port-randomization-01 1063 o No changes. Draft resubmitted after expiration. 1065 B.6. Changes from draft-larsen-tsvwg-port-randomization-00 1067 o Fixed a bug in expressions used to calculate number of ephemeral 1068 ports 1070 o Added a survey of the algorithms in use by popular TCP 1071 implementations 1073 o The whole document was reorganizaed 1075 o Miscellaneous editorial changes 1077 B.7. Changes from draft-larsen-tsvwg-port-randomisation-00 1079 o Document resubmitted after original document by M. Larsen expired 1080 in 2004 1082 o References were included to current WG documents of the TCPM WG 1084 o The document was made more general, to apply to all transport 1085 protocols 1087 o Miscellaneous editorial changes 1089 Authors' Addresses 1091 Michael Vittrup Larsen 1092 TietoEnator 1093 Skanderborgvej 232 1094 Aarhus DK-8260 1095 Denmark 1097 Phone: +45 8938 5100 1098 Email: michael.larsen@tietoenator.com 1100 Fernando Gont 1101 Universidad Tecnologica Nacional / Facultad Regional Haedo 1102 Evaristo Carriego 2644 1103 Haedo, Provincia de Buenos Aires 1706 1104 Argentina 1106 Phone: +54 11 4650 8472 1107 Email: fernando@gont.com.ar