idnits 2.17.1 draft-ietf-tsvwg-port-randomization-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 881. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 892. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 899. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 905. 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 2 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 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 (February 25, 2008) is 5905 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) == Unused Reference: 'RFC2960' is defined on line 706, but no explicit reference was found in the text ** 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) ** Obsolete normative reference: RFC 2960 (Obsoleted by RFC 4960) ** Obsolete normative reference: RFC 4960 (Obsoleted by RFC 9260) == Outdated reference: A later version (-12) exists of draft-ietf-tcpm-icmp-attacks-02 == Outdated reference: A later version (-11) exists of draft-ietf-tcpm-tcp-auth-opt-00 Summary: 9 errors (**), 0 flaws (~~), 4 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 tsvwg M. Larsen 3 Internet-Draft TietoEnator 4 Intended status: Best Current F. Gont 5 Practice UTN/FRH 6 Expires: August 28, 2008 February 25, 2008 8 Port Randomization 9 draft-ietf-tsvwg-port-randomization-01 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on August 28, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2008). 40 Abstract 42 Recently, awareness has been raised about a number of "blind" attacks 43 that can be performed against the Transmission Control Protocol (TCP) 44 and similar protocols. The consequences of these attacks range from 45 throughput-reduction to broken connections or data corruption. These 46 attacks rely on the attacker's ability to guess or know the five- 47 tuple (Protocol, Source Address, Destination Address, Source Port, 48 Destination Port) that identifies the transport protocol instance to 49 be attacked. This document describes a simple and efficient method 50 for random selection of the client port number, such that the 51 possibility of an attacker guessing the exact value is reduced. 52 While this is not a replacement for cryptographic methods, the 53 described port number randomization algorithms provide improved 54 security/obfuscation with very little effort and without any key 55 management overhead. The mechanisms described in this document are a 56 local modification that may be incrementally deployed, and that does 57 not violate the specifications of any of the transport protocols that 58 may benefit from it, such as TCP, UDP, SCTP, DCCP, and RTP. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 2. Ephemeral Ports . . . . . . . . . . . . . . . . . . . . . . . 6 64 2.1. Traditional Ephemeral Port Range . . . . . . . . . . . . . 6 65 2.2. Ephemeral port selection . . . . . . . . . . . . . . . . . 6 66 3. Randomizing the Ephemeral Ports . . . . . . . . . . . . . . . 8 67 3.1. Characteristics of a good ephemeral port randomization 68 algorithm . . . . . . . . . . . . . . . . . . . . . . . . 8 69 3.2. Ephemeral port number range . . . . . . . . . . . . . . . 9 70 3.3. Ephemeral Port Randomization Algorithms . . . . . . . . . 9 71 3.3.1. Algorithm 1: Simple port randomization algorithm . . . 9 72 3.3.2. Algorithm 2: Another simple port randomization 73 algorithm . . . . . . . . . . . . . . . . . . . . . . 11 74 3.3.3. Algorithm 3: Simple hash-based algorithm . . . . . . . 11 75 3.3.4. Algorithm 4: Double-hash randomization algorithm . . . 13 76 3.4. Secret-key considerations for hash-based port 77 randomization algorithms . . . . . . . . . . . . . . . . . 15 78 3.5. Choosing an ephemeral port randomization algorithm . . . . 16 79 4. Security Considerations . . . . . . . . . . . . . . . . . . . 17 80 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 81 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 82 6.1. Normative References . . . . . . . . . . . . . . . . . . . 19 83 6.2. Informative References . . . . . . . . . . . . . . . . . . 20 84 Appendix A. Survey of the algorithms in use by some popular 85 implementations . . . . . . . . . . . . . . . . . . . 21 86 A.1. FreeBSD . . . . . . . . . . . . . . . . . . . . . . . . . 21 87 A.2. Linux . . . . . . . . . . . . . . . . . . . . . . . . . . 21 88 A.3. NetBSD . . . . . . . . . . . . . . . . . . . . . . . . . . 21 89 A.4. OpenBSD . . . . . . . . . . . . . . . . . . . . . . . . . 21 90 Appendix B. Changes from previous versions of the draft . . . . . 22 91 B.1. Changes from draft-ietf-tsvwg-port-randomisation-00 . . . 22 92 B.2. Changes from draft-larsen-tsvwg-port-randomisation-02 . . 22 93 B.3. Changes from draft-larsen-tsvwg-port-randomisation-01 . . 22 94 B.4. Changes from draft-larsen-tsvwg-port-randomization-00 . . 22 95 B.5. Changes from draft-larsen-tsvwg-port-randomisation-00 . . 22 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 97 Intellectual Property and Copyright Statements . . . . . . . . . . 25 99 1. Introduction 101 Recently, awareness has been raised about a number of "blind" attacks 102 (i.e., attacks that can be performed without the need to sniff the 103 packets that correspond to the transport protocol instance to be 104 attacked) that can be performed against the Transmission Control 105 Protocol (TCP) [RFC0793] and similar protocols. The consequences of 106 these attacks range from throughput-reduction to broken connections 107 or data corruption [I-D.ietf-tcpm-icmp-attacks] [RFC4953] [Watson]. 109 All these attacks rely on the attacker's ability to guess or know the 110 five-tuple (Protocol, Source Address, Source port, Destination 111 Address, Destination Port) that identifies the transport protocol 112 instance to be attacked. 114 Services are usually located at fixed, 'well-known' ports [IANA] at 115 the host supplying the service (the server). Client applications 116 connecting to any such service will contact the server by specifying 117 the server IP address and service port number. The IP address and 118 port number of the client are normally left unspecified by the client 119 application and thus chosen automatically by the client networking 120 stack. Ports chosen automatically by the networking stack are known 121 as ephemeral ports [Stevens]. 123 While the server IP address and well-known port and the client IP 124 address may be accurately guessed by an attacker, the ephemeral port 125 of the client is usually unknown and must be guessed. 127 This document describes a number of algorithms for random selection 128 of the client ephemeral port, that reduce the possibility of an off- 129 path attacker guessing the exact value. They are not a replacement 130 for cryptographic methods of protecting a connection such as IPsec 131 [RFC4301], the TCP MD5 signature option [RFC2385], or the TCP 132 Authentication Option [I-D.ietf-tcpm-tcp-auth-opt]. For example, 133 they do not provide any mitigation in those scenarios in which the 134 attacker is able to sniff the packets that correspond to the 135 transport protocol connection to be attacked. However, the proposed 136 algorithms provide improved obfuscation with very little effort and 137 without any key management overhead. 139 The mechanisms described in this document are local modifications 140 that may be incrementally deployed, and that does not violate the 141 specifications of any of the transport protocols that may benefit 142 from it, such as TCP [RFC0793], UDP [RFC0768], SCTP [RFC4960], DCCP 143 [RFC4340], UDP-lite [RFC3828], and RTP [RFC3550]. 145 Since these mechanisms are obfuscation techniques, focus has been on 146 a reasonable compromise between level of obfuscation and ease of 147 implementation. Thus the algorithms must be computationally 148 efficient, and not require substantial data structures. 150 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 151 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 152 document are to be interpreted as described in RFC 2119 [RFC2119]. 154 2. Ephemeral Ports 156 2.1. Traditional Ephemeral Port Range 158 The Internet Assigned Numbers Authority (IANA) assigns the unique 159 parameters and values used in protocols developed by the Internet 160 Engineering Task Force (IETF), including well-known ports [IANA]. 161 IANA has traditionally reserved the following use of the 16-bit port 162 range of TCP and UDP: 164 o The Well Known Ports, 0 through 1023. 166 o The Registered Ports, 1024 through 49151 168 o The Dynamic and/or Private Ports, 49152 through 65535 170 The range for assigned ports managed by the IANA is 0-1023, with the 171 remainder being registered by IANA but not assigned. 173 The ephemeral port range has traditionally consisted of the 49152- 174 65535 range. 176 2.2. Ephemeral port selection 178 As each communication instance is identified by the five-tuple 179 {protocol, local IP address, local port, remote IP address, remote 180 port}, the selection of ephemeral port numbers must result in a 181 unique five-tuple. 183 Selection of ephemeral ports such that they result in unique five- 184 tuples is handled by some operating systems by having a per-protocol 185 global 'next_ephemeral' variable that is equal to the previously 186 chosen ephemeral port + 1, i.e. the selection process is: 188 /* Initialization at system boot time. Initialization value could be random */ 189 next_ephemeral = min_ephemeral; 191 /* Ephemeral port selection function */ 192 count = max_ephemeral - min_ephemeral + 1; 194 do { 195 port = next_ephemeral; 196 if (next_ephemeral == max_ephemeral) { 197 next_ephemeral = min_ephemeral; 198 } else { 199 next_ephemeral++; 200 } 202 if (five-tuple is unique) 203 return port; 205 } while (count > 0); 207 return ERROR; 209 Figure 1 211 This algorithm works well provided that the number of connections for 212 a each transport protocol that have a life-time longer than it takes 213 to exhaust the total ephemeral port range is small, so that five- 214 tuple collisions are rare. 216 However, this method has the drawback that the 'next_ephemeral' 217 variable and thus the ephemeral port range is shared between all 218 connections and the next ports chosen by the client are easy to 219 predict. If an attacker operates an "innocent" server to which the 220 client connects, it is easy to obtain a reference point for the 221 current value of the 'next_ephemeral' variable. 223 3. Randomizing the Ephemeral Ports 225 3.1. Characteristics of a good ephemeral port randomization algorithm 227 There are a number of factors to consider when designing a policy of 228 selection of ephemeral ports, which include: 230 o Minimizing the predictability of the ephemeral port numbers used 231 for future connections. 233 o Maximizing the port reuse cycle. 235 o Avoiding conflict with applications that depend on the use of 236 specific port numbers. 238 Given the goal of improving TCP's resistance to attack by obfuscation 239 of the four-tuple that identifies a TCP connection, it is key to 240 minimize the predictability of the ephemeral ports that will be 241 selected for new connections. While the obvious approach to address 242 this requirement would be to select the ephemeral ports by simply 243 picking a random value within the chosen port number range, this 244 straightforward policy may lead to a short reuse cycle of port 245 numbers, which could lead to the interoperability problems discussed 246 in . It is also worth noting that, provided adequate randomization 247 algorithms are in use, the larger the range from which ephemeral pots 248 are selected, the smaller the chances of an attacker are to guess the 249 selected port number. 251 A number of implementations will not allow the creation of a new 252 connection if there exists a previous incarnation of the same 253 connection in any state other than the fictional state CLOSED. This 254 can be problematic in scenarios in which a client establishes 255 connections with a specific service at server at a high rate: even if 256 the connections are also closed at a high rate, one of the systems 257 (the one performing the active close) will keep each of the closed 258 connection in the TIME-WAIT state for 2*MSL. If the connection rate 259 is high enough, at some point all the ephemeral ports at the client 260 will be in use by some connection in the TIME-WAIT state, thus 261 preventing the establishment of new connections. Therefore, the only 262 strategy that can be relied upon to avoid this interoperability 263 problem is to maximize the ephemeral port reuse cycle at a client, 264 with the goal of reducing the chances that a previous incarnation of 265 the same connection exists when a new connection is tried to be 266 established. A good algorithm to maximize the port reuse cycle would 267 consider the time a given ephemeral port number was last used, and 268 would avoid reusing the last recently used port numbers. A simple 269 approach to maximize the port reuse cycle would be to choose port 270 numbers incrementally, so that a given port number would not be 271 reused until the rest of the port numbers in ephemeral port range 272 have been used for a TCP connection. However, if a single global 273 variable were used to keep track of the last ephemeral port selected, 274 ephemeral port numbers would be trivially predictable. 276 It is important to note that a number of applications rely on binding 277 specific port numbers that may be within the ephemeral ports range. 278 If such an application was run while the corresponding port number 279 was in use, the application would fail. Therefore, transport 280 protocols should avoid using those port numbers as ephemeral ports. 282 3.2. Ephemeral port number range 284 As mentioned in Section 2.1, the ephemeral port range has 285 traditionally consisted of the 49152-65535 range. However, it should 286 also include the range 1024-49151 range. 288 Since this range includes user-specific server ports, this may not 289 always be possible, though. A possible workaround for this potential 290 problem would be to maintain an array of bits, in which each bit 291 would correspond to each of the port numbers in the range 1024-65535. 292 A bit set to 0 would indicate that the corresponding port is 293 available for allocation, while a bit set to one would indicate that 294 the port is reserved and therefore cannot be allocated. Thus, before 295 allocating a port number, the ephemeral port selection function would 296 check this array of bits, avoiding the allocation of ports that may 297 be needed for specific applications. 299 Transport protocols SHOULD use the largest possible port range, since 300 this improves the obfuscation provided by randomizing the ephemeral 301 ports. 303 3.3. Ephemeral Port Randomization Algorithms 305 Transport protocols SHOULD allocate their ephemeral ports randomly, 306 since this help to mitigate a number of attacks that depend on the 307 attacker's ability to guess or know the five-tuple that identifies 308 the transport protocol instance to be attacked. 310 The following subsections describe a number of algorithms that could 311 be implemented in order to obfuscate the selection of ephemeral port 312 numbers. 314 3.3.1. Algorithm 1: Simple port randomization algorithm 316 In order to address the security issues discussed in Section 1 and 317 Section 2.2, a number of systems have implemented simple ephemeral 318 port number randomization, as follows: 320 /* Ephemeral port selection function */ 321 next_ephemeral = min_ephemeral + random() 322 % (max_ephemeral - min_ephemeral + 1); 324 count = max_ephemeral - min_ephemeral + 1; 326 do { 327 if(five-tuple is unique) 328 return next_ephemeral; 330 if (next_ephemeral == max_ephemeral) { 331 next_ephemeral = min_ephemeral; 332 } else { 333 next_ephemeral++; 334 } 336 count--; 337 } while (count > 0); 339 return ERROR; 341 Figure 2 343 We will refer to this algorithm as 'Algorithm 1'. 345 Since the initially chosen port may already be in use with identical 346 IP addresses and server port, the resulting five-tuple might not be 347 unique. Therefore, multiple ports may have to be tried and verified 348 against all existing connections before a port can be chosen. 350 Although carefully chosen random sources and optimized five-tuple 351 lookup mechanisms (e.g., optimized through hashing), will mitigate 352 the cost of this verification, some systems may still not want to 353 incur this search time. 355 Systems that may be specially susceptible to this kind of repeated 356 five-tuple collisions are those that create many connections from a 357 single local IP address to a single service (i.e. both of the IP 358 addresses and the server port are fixed). Gateways such as proxy 359 servers are an example of such a system. 361 Since this algorithm performs a completely random port selection 362 (i.e., without taking into account the port numbers previously 363 chosen), it has the potential of reusing port numbers too quickly. 364 Even if a given five-tuple is verified to be unique by the port 365 selection algorithm, the five-tuple might still be in use at the 366 remote system. In such a scenario, the connection request could 367 possibly fail ([Silbersack] describes this problem for the TCP case). 369 Therefore, it is desirable to keep the port reuse frequency as low as 370 possible. 372 3.3.2. Algorithm 2: Another simple port randomization algorithm 374 Another algorithm for selecting a random port number is shown in 375 Figure 3, in which in the event a local connection-id collision is 376 detected, another port number is selected randomly, as follows: 378 /* Ephemeral port selection function */ 379 next_ephemeral = min_ephemeral + random() 380 % (max_ephemeral - min_ephemeral + 1); 382 count = max_ephemeral - min_ephemeral + 1; 384 do { 385 if(five-tuple is unique) 386 return next_ephemeral; 388 next_ephemeral = min_ephemeral + random() 389 % (max_ephemeral - min_ephemeral + 1); 390 count--; 391 } while (count > 0); 393 return ERROR; 395 Figure 3 397 We will refer to this algorithm as 'Algorithm 2'. The only 398 difference between this algorithm and Algorithm 1 is that the search 399 time for this variant may be longer than for the later, particularly 400 when there are a large number of port numbers already in use. 402 3.3.3. Algorithm 3: Simple hash-based algorithm 404 We would like to achieve the port reuse properties of traditional BSD 405 port selection algorithm, while at the same time achieve the 406 obfuscation properties of Algorithm 1 and Algorithm 2. 408 Ideally, we would like a 'next_ephemeral' value for each set of 409 (local IP address, remote IP addresses, remote port), so that the 410 port reuse frequency is the lowest possible. Each of these 411 'next_ephemeral' variables should be initialized with random values 412 within the ephemeral port range and would thus separate the ephemeral 413 port ranges of the connections entirely. Since we do not want to 414 maintain in memory all these 'next_ephemeral' values, we propose an 415 offset function F(), that can be computed from the local IP address, 416 remote IP address, remote port and a secret key. F() will yield 417 (practically) different values for each set of arguments, i.e.: 419 /* Initialization code at system boot time. Initialization value could be random. */ 420 next_ephemeral = 0; 422 /* Ephemeral port selection function */ 423 offset = F(local_IP, remote_IP, remote_port, secret_key); 424 count = max_ephemeral - min_ephemeral + 1; 426 do { 427 port = min_ephemeral + (next_ephemeral + offset) 428 % (max_ephemeral - min_ephemeral + 1); 429 next_ephemeral++; 430 count--; 432 if(five-tuple is unique) 433 return port; 435 } while (count > 0); 437 return ERROR; 439 Figure 4 441 We will refer to this algorithm as 'Algorithm 3'. 443 In other words, the function F() provides a per-connection fixed 444 offset within the global ephemeral port range. Both the 'offset' and 445 'next_ephemeral' variables may take any value within the storage type 446 range since we are restricting the resulting port similar to that 447 shown in Figure 3. This allows us to simply increment the 448 'next_ephemeral' variable and rely on the unsigned integer to simply 449 wrap-around. 451 The function F() should be a cryptographic hash function like MD5 452 [RFC1321]. The function should use both IP addresses, the remote 453 port and a secret key value to compute the offset. The remote IP 454 address is the primary separator and must be included in the offset 455 calculation. The local IP address and remote port may in some cases 456 be constant and not improve the connection separation, however, they 457 should also be included in the offset calculation. 459 Cryptographic algorithms stronger than e.g. MD5 should not be 460 necessary, given that port randomization is simply an obfuscation 461 technique. The secret should be chosen as random as possible, see 462 [RFC4086] for recommendations on choosing secrets. 464 Note that on multiuser systems, the function F() could include user 465 specific information, thereby providing protection not only on a host 466 to host basis, but on a user to service basis. In fact, any 467 identifier of the remote entity could be used, depending on 468 availability an the granularity requested. With SCTP both hostnames 469 and alternative IP addresses may be included in the association 470 negotiation and either of these could be used in the offset function 471 F(). 473 When multiple unique identifiers are available, any of these can be 474 chosen as input to the offset function F() since they all uniquely 475 identify the remote entity. However, in cases like SCTP where the 476 ephemeral port must be unique across all IP address permutations, we 477 should ideally always use the same IP address to get a single 478 starting offset for each association negotiation from a given remote 479 entity to minimize the possibility of collisions. A simple numerical 480 sorting of the IP addresses and always using the numerically lowest 481 could achieve this. However, since most protocols most likely will 482 report the same IP addresses in the same order in each association 483 setup, this sorting is most likely not necessary and the 'first one' 484 can simply be used. 486 The ability of hostnames to uniquely define hosts can be discusses, 487 and since SCTP always include at least one IP address, we recommend 488 to use this as input to the offset function F() and ignore hostnames 489 chunks when searching for ephemeral ports. 491 3.3.4. Algorithm 4: Double-hash randomization algorithm 493 A tradeoff between maintaining a single global 'next_ephemeral' 494 variable and maintaining 2**N 'next_ephemeral' variables (where N is 495 the width of of the result of F()) could be achieved as follows. The 496 system would keep an array of, TABLE_LENGTH short integers, which 497 would provide a separation of the increment of the 'next_ephemeral' 498 variable. This improvement could be incorporated into Algorithm 3 as 499 follows: 501 /* Initialization at system boot time */ 502 for(i = 0; i < TABLE_LENGTH; i++) 503 table[i] = random % 65536; 505 /* Ephemeral port selection function */ 506 offset = F(local_IP, remote_IP, remote_port, secret_key); 507 index = G(offset); 508 count = max_ephemeral - min_ephemeral + 1; 510 do { 511 port = min_ephemeral + (offset + table[index]) 512 % (max_ephemeral - min_ephemeral + 1); 514 table[index]++; 515 count--; 517 if(five-tuple is unique) 518 return port; 520 } while (count > 0); 522 return ERROR; 524 Figure 5 526 We will refer to this algorithm as 'Algorithm 4'. 528 'table[]' could be initialized with random values, as indicated by 529 the initialization code in Figure 5. G() would return a value 530 between 0 and (TABLE_LENGTH-1) taking 'offset' as its input. G() 531 could, for example, perform the exclusive-or (xor) operation between 532 all the bytes in 'offset', or could be another cryptographic hash 533 function such as that used in F(). 535 The array 'table[]' assures that succesive connections to the same 536 end-point will use increasing ephemeral port numbers. However, 537 incrementation of the port numbers is separated into TABLE_LENGTH 538 different spaces, and thus the port reuse frequency will be 539 (probabilistically) lower than that of Algorithm 2. That is, a 540 connection established with some remote end-point will not 541 necessarily cause the 'next_ephemeral' variable corresponding to 542 other end-points to be incremented. 544 It is interesting to note that the size of 'table[]' does not limit 545 the number of different port sequences, but rather separates the 546 *increments* into TABLE_LENGTH different spaces. The actual port 547 sequence will result from adding the corresponding entry of 'table[]' 548 to the variable 'offset', which actually selects the actual port 549 sequence (as in Algorithm 3). 551 3.4. Secret-key considerations for hash-based port randomization 552 algorithms 554 Every complex manipulation (like MD5) is no more secure than the 555 input values, and in the case of ephemeral ports, the secret key. If 556 an attacker is aware of which cryptographic hash function is being 557 used by the victim (which we should expect), and the attacker can 558 obtain enough material (e.g. ephemeral ports chosen by the victim), 559 the attacker may simply search the entire secret key space to find 560 matches. 562 To protect against this, the secret key should be of a reasonable 563 length. Key lengths of 32-bits should be adequate, since a 32-bit 564 secret would result in approximately 65k possible secrets if the 565 attacker is able to obtain a single ephemeral port (assuming a good 566 hash function). If the attacker is able to obtain more ephemeral 567 ports, key lengths of 64-bits or more should be used. 569 Another possible mechanism for protecting the secret key is to change 570 it after some time. If the host platform is capable of producing 571 reasonable good random data, the secret key can be changed 572 automatically. 574 Changing the secret will cause abrupt shifts in the chosen ephemeral 575 ports, and consequently collisions may occur. Thus the change in 576 secret key should be done with consideration and could be performed 577 whenever one of the following events occur: 579 o Some predefined/random time has expired. 581 o The secret has been used N times (i.e. we consider it insecure). 583 o There are few active connections (i.e., possibility of collision 584 is low). 586 o There is little traffic (the performance overhead of collisions is 587 tolerated). 589 o There is enough random data available to change the secret key 590 (pseudo-random changes should not be done). 592 3.5. Choosing an ephemeral port randomization algorithm 594 The algorithm sketched in Figure 1 is the traditional ephemeral port 595 selection algorithm implemented in BSD-derived systems. It generates 596 a global sequence of ephemeral port numbers, which makes it trivial 597 for an attacker to predict the port number that will be used for a 598 future transport protocol instance. 600 Algorithm 1 and Algorithm 2 have the advantage that they provide 601 complete randomization. However, they may increase the chances of 602 port number collisions, which could lead to failure of the connection 603 establishment attempts. 605 Algorithm 3 provides complete separation in local and remote IP 606 addresses and remote port space, and only limited separation in other 607 dimensions (See Section Section 3.4), and thus may scale better than 608 Algorithm 1 and Algorithm 2. However, implementations should 609 consider the performance impact of computing the cryptographic hash 610 used for the offset. 612 Algorithm 4 improves Algorithm 3, usually leading to a lower port 613 reuse frequency, at the expense of more processor cycles used for 614 computing G(), and additional kernel memory for storing the array 615 'table[]'. 617 Finally, a special case that precludes the utilization of Algorithm 3 618 and Algorithm 4 should be analyzed. There exist some applications 619 that contain the following code sequence: 621 s = socket(); 622 bind(s, IP_address, port = *); 624 Figure 6 626 This code sequence results in the selection of an ephemeral port 627 number. However, as neither the remote IP address nor the remote 628 port will be available to the ephemeral port selection function, the 629 hash function F() used in Algorithm 3 and Algorithm 4 will not have 630 all the required arguments, and thus the result of the hash function 631 will be impossible to compute. 633 Transport protocols implementing Algorithm 3 or Algorithm 4 should 634 consider using Algorithm 2 when facing the scenario just described. 635 This policy has been implemented by Linux [Linux]. 637 4. Security Considerations 639 Randomizing ports is no replacement for cryptographic mechanisms, 640 such as IPsec [RFC4301], in terms of protecting transport protocol 641 instances against blind attacks. 643 An eavesdropper, which can monitor the packets that correspond to the 644 connection to be attacked could learn the IP addresses and port 645 numbers in use (and also sequence numbers etc.) and easily attack the 646 connection. Randomizing ports does not provide any additional 647 protection against this kind of attacks. In such situations, proper 648 authentication mechanisms such as those described in [RFC4301] should 649 be used. 651 If the local offset function F() results in identical offsets for 652 different inputs, the port-offset mechanism proposed in this document 653 has no or reduced effect. 655 If random numbers are used as the only source of the secret key, they 656 must be chosen in accordance with the recommendations given in 657 [RFC4086]. 659 If an attacker uses dynamically assigned IP addresses, the current 660 ephemeral port offset (Algorithm 3 and Algorithm 4) for a given five- 661 tuple can be sampled and subsequently used to attack an innocent peer 662 reusing this address. However, this is only possible until a re- 663 keying happens as described above. Also, since ephemeral ports are 664 only used on the client side (e.g. the one initiating the 665 connection), both the attacker and the new peer need to act as 666 servers in the scenario just described. While servers using dynamic 667 IP addresses exist, they are not very common and with an appropriate 668 re-keying mechanism the effect of this attack is limited. 670 5. Acknowledgements 672 The offset function was inspired by the mechanism proposed by Steven 673 Bellovin in [RFC1948] for defending against TCP sequence number 674 attacks. 676 The authors would like to thank (in alphabetical order) Mark Allman, 677 Lars Eggert, Gorry Fairhurst, Alfred Hoenes, Carlos Pignataro, Joe 678 Touch, and Dan Wing for their valuable feedback on earlier versions 679 of this document. 681 The authors would like to thank FreeBSD's Mike Silbersack for a very 682 fruitful discussion about ephemeral port selection techniques. 684 6. References 686 6.1. Normative References 688 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 689 August 1980. 691 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 692 RFC 793, September 1981. 694 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 695 April 1992. 697 [RFC1948] Bellovin, S., "Defending Against Sequence Number Attacks", 698 RFC 1948, May 1996. 700 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 701 Requirement Levels", BCP 14, RFC 2119, March 1997. 703 [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 704 Signature Option", RFC 2385, August 1998. 706 [RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., 707 Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., 708 Zhang, L., and V. Paxson, "Stream Control Transmission 709 Protocol", RFC 2960, October 2000. 711 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 712 Jacobson, "RTP: A Transport Protocol for Real-Time 713 Applications", STD 64, RFC 3550, July 2003. 715 [RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and 716 G. Fairhurst, "The Lightweight User Datagram Protocol 717 (UDP-Lite)", RFC 3828, July 2004. 719 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 720 Requirements for Security", BCP 106, RFC 4086, June 2005. 722 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 723 Internet Protocol", RFC 4301, December 2005. 725 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 726 Congestion Control Protocol (DCCP)", RFC 4340, March 2006. 728 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", 729 RFC 4960, September 2007. 731 6.2. Informative References 733 [FreeBSD] The FreeBSD Project, "http://www.freebsd.org". 735 [IANA] "IANA Port Numbers", 736 . 738 [I-D.ietf-tcpm-icmp-attacks] 739 Gont, F., "ICMP attacks against TCP", 740 draft-ietf-tcpm-icmp-attacks-02 (work in progress), 741 May 2007. 743 [RFC4953] Touch, J., "Defending TCP Against Spoofing Attacks", 744 RFC 4953, July 2007. 746 [Linux] The Linux Project, "http://www.kernel.org". 748 [NetBSD] The NetBSD Project, "http://www.netbsd.org". 750 [OpenBSD] The OpenBSD Project, "http://www.openbsd.org". 752 [Silbersack] 753 Silbersack, M., "Improving TCP/IP security through 754 randomization without sacrificing interoperability.", 755 EuroBSDCon 2005 Conference , 2005. 757 [Stevens] Stevens, W., "Unix Network Programming, Volume 1: 758 Networking APIs: Socket and XTI, Prentice Hall", 1998. 760 [I-D.ietf-tcpm-tcp-auth-opt] 761 Touch, J., Mankin, A., and R. Bonica, "The TCP 762 Authentication Option", draft-ietf-tcpm-tcp-auth-opt-00 763 (work in progress), November 2007. 765 [Watson] Watson, P., "Slipping in the Window: TCP Reset attacks", 766 december 2003. 768 Appendix A. Survey of the algorithms in use by some popular 769 implementations 771 A.1. FreeBSD 773 FreeBSD implements Algorithm 2. with a 'min_port' of 49152 and a 774 'max_port' of 65535. If the selected port number is in use, the next 775 available port number is tried next [FreeBSD]. 777 A.2. Linux 779 Linux implements Algorithm 3. If the algorithm is faced with the 780 corner-case scenario described in Section 3.5, Algorithm 2 is used 781 instead [Linux]. 783 A.3. NetBSD 785 NetBSD does not randomize ehemeral port numbers. It selects 786 ephemeral port numbers from the range 49152-65535, starting from port 787 65535, and decreasing the port number for each ephemeral port number 788 selected [NetBSD]. 790 A.4. OpenBSD 792 OpenBSD implements Algorithm 2. with a 'min_port' of 1024 and a 793 'max_port' of 49151. If the selected port number is in use, the next 794 available port number is tried next [OpenBSD]. 796 Appendix B. Changes from previous versions of the draft 798 B.1. Changes from draft-ietf-tsvwg-port-randomisation-00 800 o Added Section 3.1. 802 o Changed Intended Status from "Satandards Track" to "BCP". 804 o Miscellaneous editorial changes. 806 B.2. Changes from draft-larsen-tsvwg-port-randomisation-02 808 o Draft resubmitted as draft-ietf. 810 o Included references and text on protocols other than TCP. 812 o Added the second variant of the simple port randomization 813 algorithm 815 o Reorganized the algorithms into different sections 817 o Miscellaneous editorial changes. 819 B.3. Changes from draft-larsen-tsvwg-port-randomisation-01 821 o No changes. Draft resubmitted after expiration. 823 B.4. Changes from draft-larsen-tsvwg-port-randomization-00 825 o Fixed a bug in expressions used to calculate number of ephemeral 826 ports 828 o Added a survey of the algorithms in use by popular TCP 829 implementations 831 o The whole document was reorganizaed 833 o Miscellaneous editorial changes 835 B.5. Changes from draft-larsen-tsvwg-port-randomisation-00 837 o Document resubmitted after original document by M. Larsen expired 838 in 2004 840 o References were included to current WG documents of the TCPM WG 842 o The document was made more general, to apply to all transport 843 protocols 845 o Miscellaneous editorial changes 847 Authors' Addresses 849 Michael Vittrup Larsen 850 TietoEnator 851 Skanderborgvej 232 852 Aarhus DK-8260 853 Denmark 855 Phone: +45 8938 5100 856 Email: michael.larsen@tietoenator.com 858 Fernando Gont 859 Universidad Tecnologica Nacional / Facultad Regional Haedo 860 Evaristo Carriego 2644 861 Haedo, Provincia de Buenos Aires 1706 862 Argentina 864 Phone: +54 11 4650 8472 865 Email: fernando@gont.com.ar 867 Full Copyright Statement 869 Copyright (C) The IETF Trust (2008). 871 This document is subject to the rights, licenses and restrictions 872 contained in BCP 78, and except as set forth therein, the authors 873 retain all their rights. 875 This document and the information contained herein are provided on an 876 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 877 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 878 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 879 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 880 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 881 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 883 Intellectual Property 885 The IETF takes no position regarding the validity or scope of any 886 Intellectual Property Rights or other rights that might be claimed to 887 pertain to the implementation or use of the technology described in 888 this document or the extent to which any license under such rights 889 might or might not be available; nor does it represent that it has 890 made any independent effort to identify any such rights. Information 891 on the procedures with respect to rights in RFC documents can be 892 found in BCP 78 and BCP 79. 894 Copies of IPR disclosures made to the IETF Secretariat and any 895 assurances of licenses to be made available, or the result of an 896 attempt made to obtain a general license or permission for the use of 897 such proprietary rights by implementers or users of this 898 specification can be obtained from the IETF on-line IPR repository at 899 http://www.ietf.org/ipr. 901 The IETF invites any interested party to bring to its attention any 902 copyrights, patents or patent applications, or other proprietary 903 rights that may cover technology that may be required to implement 904 this standard. Please address the information to the IETF at 905 ietf-ipr@ietf.org. 907 Acknowledgment 909 Funding for the RFC Editor function is provided by the IETF 910 Administrative Support Activity (IASA).