idnits 2.17.1 draft-ietf-tsvwg-port-randomization-00.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 784. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 795. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 802. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 808. 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 is 1 instance of too long lines in the document, the longest one being 4 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 229: '...nsport protocols SHOULD use the larges...' 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 (December 4, 2007) is 5988 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: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC2960' is defined on line 620, 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 Summary: 10 errors (**), 0 flaws (~~), 3 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: Standards Track F. Gont 5 Expires: June 6, 2008 UTN/FRH 6 December 4, 2007 8 Port Randomization 9 draft-ietf-tsvwg-port-randomization-00 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 June 6, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 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 . . . . . . . . . . . . . . . . . . . . . . . 5 64 2.1. Traditional Ephemeral Port Range . . . . . . . . . . . . . 5 65 2.2. Ephemeral port selection . . . . . . . . . . . . . . . . . 5 66 3. Randomizing the Ephemeral Ports . . . . . . . . . . . . . . . 7 67 3.1. Ephemeral port number range . . . . . . . . . . . . . . . 7 68 3.2. Ephemeral Port Randomization Algorithms . . . . . . . . . 7 69 3.2.1. Algorithm 1: Simple port randomization algorithm . . . 7 70 3.2.2. Algorithm 2: Another simple port randomization 71 algorithm . . . . . . . . . . . . . . . . . . . . . . 9 72 3.2.3. Algorithm 3: Simple hash-based algorithm . . . . . . . 9 73 3.2.4. Algorithm 4: Double-hash randomization algorithm . . . 11 74 3.3. Secret-key considerations for hash-based port 75 randomization algorithms . . . . . . . . . . . . . . . . . 13 76 3.4. Choosing an ephemeral port randomization algorithm . . . . 14 77 4. Security Considerations . . . . . . . . . . . . . . . . . . . 15 78 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 79 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 80 6.1. Normative References . . . . . . . . . . . . . . . . . . . 17 81 6.2. Informative References . . . . . . . . . . . . . . . . . . 17 82 Appendix A. Survey of the algorithms in use by some popular 83 implementations . . . . . . . . . . . . . . . . . . . 19 84 A.1. FreeBSD . . . . . . . . . . . . . . . . . . . . . . . . . 19 85 A.2. Linux . . . . . . . . . . . . . . . . . . . . . . . . . . 19 86 A.3. NetBSD . . . . . . . . . . . . . . . . . . . . . . . . . . 19 87 A.4. OpenBSD . . . . . . . . . . . . . . . . . . . . . . . . . 19 88 Appendix B. Changes from previous versions of the draft . . . . . 20 89 B.1. Changes from draft-larsen-tsvwg-port-randomisation-02 . . 20 90 B.2. Changes from draft-larsen-tsvwg-port-randomisation-01 . . 20 91 B.3. Changes from draft-larsen-tsvwg-port-randomization-00 . . 20 92 B.4. Changes from draft-larsen-tsvwg-port-randomisation-00 . . 20 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 94 Intellectual Property and Copyright Statements . . . . . . . . . . 22 96 1. Introduction 98 Recently, awareness has been raised about a number of "blind" attacks 99 that can be performed against the Transmission Control Protocol (TCP) 100 [RFC0793] and similar protocols. The consequences of these attacks 101 range from throughput-reduction to broken connections or data 102 corruption [I-D.ietf-tcpm-icmp-attacks] [I-D.ietf-tcpm-tcp-antispoof] 103 [Watson]. 105 All these attacks rely on the attacker's ability to guess or know the 106 five-tuple (Protocol, Source Address, Source port, Destination 107 Address, Destination Port) that identifies the transport protocol 108 instance to be attacked. 110 Services are usually located at fixed, 'well-known' ports [IANA] at 111 the host supplying the service (the server). Client applications 112 connecting to any such service will contact the server by specifying 113 the server IP address and service port number. The IP address and 114 port number of the client are normally left unspecified by the client 115 application and thus chosen automatically by the client networking 116 stack. Ports chosen automatically by the networking stack are known 117 as ephemeral ports [Stevens]. 119 While the server IP address and well-known port and the client IP 120 address may be accurately guessed by an attacker, the ephemeral port 121 of the client is usually unknown and must be guessed. 123 This document describes a number of algorithms for random selection 124 of the client ephemeral port, that reduce the possibility of an off- 125 path attacker guessing the exact value. They are not a replacement 126 for cryptographic methods of protecting a connection such as IPsec 127 [RFC4301] or the TCP MD5 signature option [RFC2385]. However, the 128 proposed algorithms provide improved obfuscation with very little 129 effort and without any key management overhead. 131 The mechanisms described in this document are local modifications 132 that may be incrementally deployed, and that does not violate the 133 specifications of any of the transport protocols that may benefit 134 from it, such as TCP [RFC0793], UDP [RFC0768], SCTP [RFC4960], DCCP 135 [RFC4340], UDP-lite [RFC3828], and RTP [RFC3550]. 137 Since these mechanisms are obfuscation techniques, focus has been on 138 a reasonable compromise between level of obfuscation and ease of 139 implementation. Thus the algorithms must be computationally 140 efficient, and not require substantial data structures. 142 2. Ephemeral Ports 144 2.1. Traditional Ephemeral Port Range 146 The Internet Assigned Numbers Authority (IANA) assigns the unique 147 parameters and values used in protocols developed by the Internet 148 Engineering Task Force (IETF), including well-known ports [IANA]. 149 IANA has traditionally reserved the following use of the 16-bit port 150 range of TCP and UDP: 152 o The Well Known Ports, 0 through 1023. 154 o The Registered Ports, 1024 through 49151 156 o The Dynamic and/or Private Ports, 49152 through 65535 158 The range for assigned ports managed by the IANA is 0-1023, with the 159 remainder being registered by IANA but not assigned. 161 The ephemeral port range has traditionally consisted of the 49152- 162 65535 range. 164 2.2. Ephemeral port selection 166 As each communication instance is identified by the five-tuple 167 {protocol, local IP address, local port, remote IP address, remote 168 port}, the selection of ephemeral port numbers must result in a 169 unique five-tuple. 171 Selection of ephemeral ports such that they result in unique five- 172 tuples is handled by some operating systems by having a per-protocol 173 global 'next_ephemeral' variable that is equal to the previously 174 chosen ephemeral port + 1, i.e. the selection process is: 176 next_ephemeral = min_ephemeral; /*initialization, could be random */ 178 /* Ephemeral port selection */ 179 count = max_ephemeral - min_ephemeral + 1; 181 do { 182 port = next_ephemeral; 183 if (next_ephemeral == max_ephemeral) { 184 next_ephemeral = min_ephemeral; 185 } else { 186 next_ephemeral++; 187 } 189 if (five-tuple is unique) 190 return port; 192 } while (count > 0); 194 return ERROR; 196 Figure 1 198 This algorithm works well provided that the number of connections for 199 a each transport protocol that have a life-time longer than it takes 200 to exhaust the total ephemeral port range is small, so that five- 201 tuple collisions are rare. 203 However, this method has the drawback that the 'next_ephemeral' 204 variable and thus the ephemeral port range is shared between all 205 connections and the next ports chosen by the client are easy to 206 predict. If an attacker operates an "innocent" server to which the 207 client connects, it is easy to obtain a reference point for the 208 current value of the 'next_ephemeral' variable. 210 3. Randomizing the Ephemeral Ports 212 3.1. Ephemeral port number range 214 As mentioned in Section 2.1, the ephemeral port range has 215 traditionally consisted of the 49152-65535 range. However, it should 216 also include the range 1024-49151 range. 218 Since this range includes user-specific server ports, this may not 219 always be possible, though. A possible workaround for this potential 220 problem would be to maintain an array of bits, in which each bit 221 would correspond to each of the port numbers in the range 1024-65535. 222 A bit set to 0 would indicate that the corresponding port is 223 available for allocation, while a bit set to one would indicate that 224 the port is reserved and therefore cannot be allocated. Thus, before 225 allocating a port number, the ephemeral port selection function would 226 check this array of bits, avoiding the allocation of ports that may 227 be needed for specific applications. 229 Transport protocols SHOULD use the largest possible port range, since 230 this improves the obfuscation provided by randomizing the ephemeral 231 ports. 233 3.2. Ephemeral Port Randomization Algorithms 235 3.2.1. Algorithm 1: Simple port randomization algorithm 237 In order to address the security issues discussed in Section 1 and 238 Section 2.2, a number of systems have implemented simple ephemeral 239 port number randomization, as follows: 241 next_ephemeral = min_ephemeral + random() 242 % (max_ephemeral - min_ephemeral + 1); 244 count = max_ephemeral - min_ephemeral + 1; 246 do { 247 if(five-tuple is unique) 248 return next_ephemeral; 250 if (next_ephemeral == max_ephemeral) { 251 next_ephemeral = min_ephemeral; 252 } else { 253 next_ephemeral++; 254 } 256 count--; 257 } while (count > 0); 259 return ERROR; 261 Figure 2 263 We will refer to this algorithm as 'Algorithm 1'. 265 Since the initially chosen port may already be in use with identical 266 IP addresses and server port, the resulting five-tuple might not be 267 unique. Therefore, multiple ports may have to be tried and verified 268 against all existing connections before a port can be chosen. 270 Although carefully chosen random sources and optimized five-tuple 271 lookup mechanisms (e.g., optimized through hashing), will mitigate 272 the cost of this verification, some systems may still not want to 273 incur this search time. 275 Systems that may be specially susceptible to this kind of repeated 276 five-tuple collisions are those that create many connections from a 277 single local IP address to a single service (i.e. both of the IP 278 addresses and the server port are fixed). Gateways such as proxy 279 servers are an example of such a system. 281 Since this algorithm performs a completely random port selection 282 (i.e., without taking into account the port numbers previously 283 chosen), it has the potential of reusing port numbers too quickly. 284 Even if a given five-tuple is verified to be unique by the port 285 selection algorithm, the five-tuple might still be in use at the 286 remote system. In such a scenario, the connection request could 287 possibly fail ([Silbersack] describes this problem for the TCP case). 288 Therefore, it is desirable to keep the port reuse frequency as low as 289 possible. 291 3.2.2. Algorithm 2: Another simple port randomization algorithm 293 Another algorithm for selecting a random port number is shown in 294 Figure 3, in which in the event a local connection-id collision is 295 detected, another port number is selected randomly, as follows: 297 next_ephemeral = min_ephemeral + random() 298 % (max_ephemeral - min_ephemeral + 1); 300 count = max_ephemeral - min_ephemeral + 1; 302 do { 303 if(five-tuple is unique) 304 return next_ephemeral; 306 next_ephemeral = min_ephemeral + random() 307 % (max_ephemeral - min_ephemeral + 1); 308 count--; 309 } while (count > 0); 311 return ERROR; 313 Figure 3 315 We will refer to this algorithm as 'Algorithm 2'. The only 316 difference between this algorithm and Algorithm 1 is that the search 317 time for this variant may be longer than for the later, particularly 318 when there are a large number of port numbers already in use. 320 3.2.3. Algorithm 3: Simple hash-based algorithm 322 We would like to achieve the port reuse properties of traditional BSD 323 port selection algorithm, while at the same time achieve the 324 obfuscation properties of Algorithm 1 and Algorithm 2. 326 Ideally, we would like a 'next_ephemeral' value for each set of 327 (local IP address, remote IP addresses, remote port), so that the 328 port reuse frequency is the lowest possible. Each of these 329 'next_ephemeral' variables should be initialized with random values 330 within the ephemeral port range and would thus separate the ephemeral 331 port ranges of the connections entirely. Since we do not want to 332 maintain in memory all these 'next_ephemeral' values, we propose an 333 offset function F(), that can be computed from the local IP address, 334 remote IP address, remote port and a secret key. F() will yield 335 (practically) different values for each set of arguments, i.e.: 337 /* Initialization code */ 338 next_ephemeral = 0; /* could be random */ 340 /* Ephemeral port selection */ 341 offset = F(local_IP, remote_IP, remote_port, secret_key); 342 count = max_ephemeral - min_ephemeral + 1; 344 do { 345 port = min_ephemeral + (next_ephemeral + offset) 346 % (max_ephemeral - min_ephemeral + 1); 347 next_ephemeral++; 348 count--; 350 if(five-tuple is unique) 351 return port; 353 } while (count > 0); 355 return ERROR; 357 Figure 4 359 We will refer to this algorithm as 'Algorithm 3'. 361 In other words, the function F() provides a per-connection fixed 362 offset within the global ephemeral port range. Both the 'offset' and 363 'next_ephemeral' variables may take any value within the storage type 364 range since we are restricting the resulting port similar to that 365 shown in Figure 3. This allows us to simply increment the 366 'next_ephemeral' variable and rely on the unsigned integer to simply 367 wrap-around. 369 The function F() should be a cryptographic hash function like MD5 370 [RFC1321]. The function should use both IP addresses, the remote 371 port and a secret key value to compute the offset. The remote IP 372 address is the primary separator and must be included in the offset 373 calculation. The local IP address and remote port may in some cases 374 be constant and not improve the connection separation, however, they 375 should also be included in the offset calculation. 377 Cryptographic algorithms stronger than e.g. MD5 should not be 378 necessary, given that port randomization is simply an obfuscation 379 technique. The secret should be chosen as random as possible, see 380 [RFC4086] for recommendations on choosing secrets. 382 Note that on multiuser systems, the function F() could include user 383 specific information, thereby providing protection not only on a host 384 to host basis, but on a user to service basis. In fact, any 385 identifier of the remote entity could be used, depending on 386 availability an the granularity requested. With SCTP both hostnames 387 and alternative IP addresses may be included in the association 388 negotiation and either of these could be used in the offset function 389 F(). 391 When multiple unique identifiers are available, any of these can be 392 chosen as input to the offset function F() since they all uniquely 393 identify the remote entity. However, in cases like SCTP where the 394 ephemeral port must be unique across all IP address permutations, we 395 should ideally always use the same IP address to get a single 396 starting offset for each association negotiation from a given remote 397 entity to minimize the possibility of collisions. A simple numerical 398 sorting of the IP addresses and always using the numerically lowest 399 could achieve this. However, since most protocols most likely will 400 report the same IP addresses in the same order in each association 401 setup, this sorting is most likely not necessary and the 'first one' 402 can simply be used. 404 The ability of hostnames to uniquely define hosts can be discusses, 405 and since SCTP always include at least one IP address, we recommend 406 to use this as input to the offset function F() and ignore hostnames 407 chunks when searching for ephemeral ports. 409 3.2.4. Algorithm 4: Double-hash randomization algorithm 411 A tradeoff between maintaining a single global 'next_ephemeral' 412 variable and maintaining 2**N 'next_ephemeral' variables (where N is 413 the width of of the result of F()) could be achieved as follows. The 414 system would keep an array of, TABLE_LENGTH short integers, which 415 would provide a separation of the increment of the 'next_ephemeral' 416 variable. This improvement could be incorporated into Algorithm 3 as 417 follows: 419 /* Initialization code */ 420 for(i = 0; i < TABLE_LENGTH; i++) /* Initialization code */ 421 table[i] = random % 65536; 423 /* Ephemeral port selection */ 424 offset = F(local_IP, remote_IP, remote_port, secret_key); 425 index = G(offset); 426 count = max_ephemeral - min_ephemeral + 1; 428 do { 429 port = min_ephemeral + (offset + table[index]) 430 % (max_ephemeral - min_ephemeral + 1); 432 table[index]++; 433 count--; 435 if(five-tuple is unique) 436 return port; 438 } while (count > 0); 440 return ERROR; 442 Figure 5 444 We will refer to this algorithm as 'Algorithm 4'. 446 'table[]' could be initialized with random values, as indicated by 447 the initialization code in Figure 5. G() would return a value 448 between 0 and (TABLE_LENGTH-1) taking 'offset' as its input. G() 449 could, for example, perform the exclusive-or (xor) operation between 450 all the bytes in 'offset', or could be another cryptographic hash 451 function such as that used in F(). 453 The array 'table[]' assures that succesive connections to the same 454 end-point will use increasing ephemeral port numbers. However, 455 incrementation of the port numbers is separated into TABLE_LENGTH 456 different spaces, and thus the port reuse frequency will be 457 (probabilistically) lower than that of Algorithm 2. That is, a 458 connection established with some remote end-point will not 459 necessarily cause the 'next_ephemeral' variable corresponding to 460 other end-points to be incremented. 462 It is interesting to note that the size of 'table[]' does not limit 463 the number of different port sequences, but rather separates the 464 *increments* into TABLE_LENGTH different spaces. The actual port 465 sequence will result from adding the corresponding entry of 'table[]' 466 to the variable 'offset', which actually selects the actual port 467 sequence (as in Algorithm 3). 469 3.3. Secret-key considerations for hash-based port randomization 470 algorithms 472 Every complex manipulation (like MD5) is no more secure than the 473 input values, and in the case of ephemeral ports, the secret key. If 474 an attacker is aware of which cryptographic hash function is being 475 used by the victim (which we should expect), and the attacker can 476 obtain enough material (e.g. ephemeral ports chosen by the victim), 477 the attacker may simply search the entire secret key space to find 478 matches. 480 To protect against this, the secret key should be of a reasonable 481 length. Key lengths of 32-bits should be adequate, since a 32-bit 482 secret would result in approximately 65k possible secrets if the 483 attacker is able to obtain a single ephemeral port (assuming a good 484 hash function). If the attacker is able to obtain more ephemeral 485 ports, key lengths of 64-bits or more should be used. 487 Another possible mechanism for protecting the secret key is to change 488 it after some time. If the host platform is capable of producing 489 reasonable good random data, the secret key can be changed 490 automatically. 492 Changing the secret will cause abrupt shifts in the chosen ephemeral 493 ports, and consequently collisions may occur. Thus the change in 494 secret key should be done with consideration and could be performed 495 whenever one of the following events occur: 497 o Some predefined/random time has expired. 499 o The secret has been used N times (i.e. we consider it insecure). 501 o There are few active connections (i.e., possibility of collision 502 is low). 504 o There is little traffic (the performance overhead of collisions is 505 tolerated). 507 o There is enough random data available to change the secret key 508 (pseudo-random changes should not be done). 510 3.4. Choosing an ephemeral port randomization algorithm 512 The algorithm sketched in Figure 1 is the traditional ephemeral port 513 selection algorithm implemented in BSD-derived systems. It generates 514 a global sequence of ephemeral port numbers, which makes it trivial 515 for an attacker to predict the port number that will be used for a 516 future transport protocol instance. 518 Algorithm 1 and Algorithm 2 have the advantage that they provide 519 complete randomization. However, they may increase the chances of 520 port number collisions, which could lead to failure of the connection 521 establishment attempts. 523 Algorithm 3 provides complete separation in local and remote IP 524 addresses and remote port space, and only limited separation in other 525 dimensions (See Section Section 3.3), and thus may scale better than 526 Algorithm 1 and Algorithm 2. However, implementations should 527 consider the performance impact of computing the cryptographic hash 528 used for the offset. 530 Algorithm 4 improves Algorithm 3, usually leading to a lower port 531 reuse frequency, at the expense of more processor cycles used for 532 computing G(), and additional kernel memory for storing the array 533 'table[]'. 535 Finally, a special case that precludes the utilization of Algorithm 3 536 and Algorithm 4 should be analyzed. There exist some applications 537 that contain the following code sequence: 539 s = socket(); 540 bind(s, IP_address, port = *); 542 Figure 6 544 This code sequence results in the selection of an ephemeral port 545 number. However, as neither the remote IP address nor the remote 546 port will be available to the ephemeral port selection function, the 547 hash function F() used in Algorithm 3 and Algorithm 4 will not have 548 all the required arguments, and thus the result of the hash function 549 will be impossible to compute. 551 Transport protocols implementing Algorithm 3 or Algorithm 4 should 552 consider using Algorithm 2 when facing the scenario just described. 553 This policy has been implemented by Linux [Linux]. 555 4. Security Considerations 557 Randomizing ports is no replacement for cryptographic mechanisms, 558 such as IPsec [RFC4301], in terms of protecting transport protocol 559 instances against blind attacks. 561 An eavesdropper, which can monitor the packets that correspond to the 562 connection to be attacked could learn the IP addresses and port 563 numbers in use (and also sequence numbers etc.) and easily attack the 564 connection. Randomizing ports does not provide any additional 565 protection against this kind of attacks. In such situations, proper 566 authentication mechanisms such as those described in [RFC4301] should 567 be used. 569 If the local offset function F() results in identical offsets for 570 different inputs, the port-offset mechanism proposed in this document 571 has no or reduced effect. 573 If random numbers are used as the only source of the secret key, they 574 must be chosen in accordance with the recommendations given in 575 [RFC4086]. 577 If an attacker uses dynamically assigned IP addresses, the current 578 ephemeral port offset (Algorithm 3 and Algorithm 4) for a given five- 579 tuple can be sampled and subsequently used to attack an innocent peer 580 reusing this address. However, this is only possible until a re- 581 keying happens as described above. Also, since ephemeral ports are 582 only used on the client side (e.g. the one initiating the 583 connection), both the attacker and the new peer need to act as 584 servers in the scenario just described. While servers using dynamic 585 IP addresses exist, they are not very common and with an appropriate 586 re-keying mechanism the effect of this attack is limited. 588 5. Acknowledgements 590 The offset function was inspired by the mechanism proposed by Steven 591 Bellovin in [RFC1948] for defending against TCP sequence number 592 attacks. 594 The authors would like to thank Mark Allman, Lars Eggert, Gorry 595 Fairhurst, Alfred Hoenes, Carlos Pignataro, and Dan Wing for their 596 valuable feedback on earlier versions of this document. 598 The authors would like to thank FreeBSD's Mike Silbersack for a very 599 fruitful discussion about ephemeral port selection techniques. 601 6. References 603 6.1. Normative References 605 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 606 August 1980. 608 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 609 RFC 793, September 1981. 611 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 612 April 1992. 614 [RFC1948] Bellovin, S., "Defending Against Sequence Number Attacks", 615 RFC 1948, May 1996. 617 [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 618 Signature Option", RFC 2385, August 1998. 620 [RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., 621 Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., 622 Zhang, L., and V. Paxson, "Stream Control Transmission 623 Protocol", RFC 2960, October 2000. 625 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 626 Jacobson, "RTP: A Transport Protocol for Real-Time 627 Applications", STD 64, RFC 3550, July 2003. 629 [RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and 630 G. Fairhurst, "The Lightweight User Datagram Protocol 631 (UDP-Lite)", RFC 3828, July 2004. 633 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 634 Requirements for Security", BCP 106, RFC 4086, June 2005. 636 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 637 Internet Protocol", RFC 4301, December 2005. 639 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 640 Congestion Control Protocol (DCCP)", RFC 4340, March 2006. 642 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", 643 RFC 4960, September 2007. 645 6.2. Informative References 647 [FreeBSD] The FreeBSD Project, "http://www.freebsd.org". 649 [IANA] "IANA Port Numbers", 650 . 652 [I-D.ietf-tcpm-icmp-attacks] 653 Gont, F., "ICMP attacks against TCP", 654 draft-ietf-tcpm-icmp-attacks-02 (work in progress), 655 May 2007. 657 [I-D.ietf-tcpm-tcp-antispoof] 658 Touch, J., "Defending TCP Against Spoofing Attacks", 659 draft-ietf-tcpm-tcp-antispoof-06 (work in progress), 660 February 2007. 662 [Linux] The Linux Project, "http://www.kernel.org". 664 [NetBSD] The NetBSD Project, "http://www.netbsd.org". 666 [OpenBSD] The OpenBSD Project, "http://www.openbsd.org". 668 [Silbersack] 669 Silbersack, M., "Improving TCP/IP security through 670 randomization without sacrificing interoperability.", 671 EuroBSDCon 2005 Conference , 2005. 673 [Stevens] Stevens, W., "Unix Network Programming, Volume 1: 674 Networking APIs: Socket and XTI, Prentice Hall", 1998. 676 [Watson] Watson, P., "Slipping in the Window: TCP Reset attacks", 677 december 2003. 679 Appendix A. Survey of the algorithms in use by some popular 680 implementations 682 A.1. FreeBSD 684 FreeBSD implements Algorithm 2. with a 'min_port' of 49152 and a 685 'max_port' of 65535. If the selected port number is in use, the next 686 available port number is tried next [FreeBSD]. 688 A.2. Linux 690 Linux implements Algorithm 3. If the algorithm is faced with the 691 corner-case scenario described in Section 3.4, Algorithm 2 is used 692 instead [Linux]. 694 A.3. NetBSD 696 NetBSD does not randomize ehemeral port numbers. It selects 697 ephemeral port numbers from the range 49152-65535, starting from port 698 65535, and decreasing the port number for each ephemeral port number 699 selected [NetBSD]. 701 A.4. OpenBSD 703 OpenBSD implements Algorithm 2. with a 'min_port' of 1024 and a 704 'max_port' of 49151. If the selected port number is in use, the next 705 available port number is tried next [OpenBSD]. 707 Appendix B. Changes from previous versions of the draft 709 B.1. Changes from draft-larsen-tsvwg-port-randomisation-02 711 o Draft resubmitted as draft-ietf. 713 o Included references and text on protocols other than TCP. 715 o Added the second variant of the simple port randomization 716 algorithm 718 o Reorganized the algorithms into different sections 720 o Miscellaneous editorial changes. 722 B.2. Changes from draft-larsen-tsvwg-port-randomisation-01 724 o No changes. Draft resubmitted after expiration. 726 B.3. Changes from draft-larsen-tsvwg-port-randomization-00 728 o Fixed a bug in expressions used to calculate number of ephemeral 729 ports 731 o Added a survey of the algorithms in use by popular TCP 732 implementations 734 o The whole document was reorganizaed 736 o Miscellaneous editorial changes 738 B.4. Changes from draft-larsen-tsvwg-port-randomisation-00 740 o Document resubmitted after original document by M. Larsen expired 741 in 2004 743 o References were included to current WG documents of the TCPM WG 745 o The document was made more general, to apply to all transport 746 protocols 748 o Miscellaneous editorial changes 750 Authors' Addresses 752 Michael Vittrup Larsen 753 TietoEnator 754 Skanderborgvej 232 755 Aarhus DK-8260 756 Denmark 758 Phone: +45 8938 5100 759 Email: michael.larsen@tietoenator.com 761 Fernando Gont 762 Universidad Tecnologica Nacional / Facultad Regional Haedo 763 Evaristo Carriego 2644 764 Haedo, Provincia de Buenos Aires 1706 765 Argentina 767 Phone: +54 11 4650 8472 768 Email: fernando@gont.com.ar 770 Full Copyright Statement 772 Copyright (C) The IETF Trust (2007). 774 This document is subject to the rights, licenses and restrictions 775 contained in BCP 78, and except as set forth therein, the authors 776 retain all their rights. 778 This document and the information contained herein are provided on an 779 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 780 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 781 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 782 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 783 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 784 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 786 Intellectual Property 788 The IETF takes no position regarding the validity or scope of any 789 Intellectual Property Rights or other rights that might be claimed to 790 pertain to the implementation or use of the technology described in 791 this document or the extent to which any license under such rights 792 might or might not be available; nor does it represent that it has 793 made any independent effort to identify any such rights. Information 794 on the procedures with respect to rights in RFC documents can be 795 found in BCP 78 and BCP 79. 797 Copies of IPR disclosures made to the IETF Secretariat and any 798 assurances of licenses to be made available, or the result of an 799 attempt made to obtain a general license or permission for the use of 800 such proprietary rights by implementers or users of this 801 specification can be obtained from the IETF on-line IPR repository at 802 http://www.ietf.org/ipr. 804 The IETF invites any interested party to bring to its attention any 805 copyrights, patents or patent applications, or other proprietary 806 rights that may cover technology that may be required to implement 807 this standard. Please address the information to the IETF at 808 ietf-ipr@ietf.org. 810 Acknowledgment 812 Funding for the RFC Editor function is provided by the IETF 813 Administrative Support Activity (IASA).