idnits 2.17.1 draft-larsen-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 683. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 694. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 701. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 707. 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.) ** 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 217: '...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 (February 11, 2007) is 6277 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) ** 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) == Outdated reference: A later version (-06) exists of draft-ietf-tcpm-tcp-antispoof-05 == Outdated reference: A later version (-12) exists of draft-ietf-tcpm-icmp-attacks-01 Summary: 8 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 Ericsson 4 Intended status: Standards Track F. Gont 5 Expires: August 15, 2007 UTN/FRH 6 February 11, 2007 8 Port Randomization 9 draft-larsen-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 15, 2007. 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 four- 47 tuple (Source Address, Destination Address, Source port, Destination 48 Port) that identifies the transport protocol instance to be attacked. 49 This document describes a simple and efficient method for random 50 selection of the client port number, such that the possibility of an 51 attacker guessing the exact value is reduced. While this is not a 52 replacement for cryptographic methods, the described port number 53 randomization algorithms provide improved security/obfuscation with 54 very little effort and without any key management overhead. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Ephemeral Ports . . . . . . . . . . . . . . . . . . . . . . . 4 60 2.1. Traditional Ephemeral Port Range . . . . . . . . . . . . . 4 61 2.2. Ephemeral port selection . . . . . . . . . . . . . . . . . 4 62 3. Randomizing the Ephemeral Ports . . . . . . . . . . . . . . . 6 63 3.1. Ephemeral port number range . . . . . . . . . . . . . . . 6 64 3.2. Ephemeral Port Randomization Algorithms . . . . . . . . . 6 65 3.3. Secret Key . . . . . . . . . . . . . . . . . . . . . . . . 11 66 3.4. Choosing Algorithm . . . . . . . . . . . . . . . . . . . . 11 67 4. Security Considerations . . . . . . . . . . . . . . . . . . . 13 68 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 69 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 70 6.1. Normative References . . . . . . . . . . . . . . . . . . . 15 71 6.2. Informative References . . . . . . . . . . . . . . . . . . 15 72 Appendix A. Survey of the algorithms in use by some popular 73 implementations . . . . . . . . . . . . . . . . . . . 17 74 A.1. FreeBSD . . . . . . . . . . . . . . . . . . . . . . . . . 17 75 A.2. Linux . . . . . . . . . . . . . . . . . . . . . . . . . . 17 76 A.3. NetBSD . . . . . . . . . . . . . . . . . . . . . . . . . . 17 77 A.4. OpenBSD . . . . . . . . . . . . . . . . . . . . . . . . . 17 78 Appendix B. Changes from previous versions of the draft . . . . . 18 79 B.1. Changes from draft-larsen-tsvwg-port-randomization-00 . . 18 80 B.2. Changes from draft-larsen-tsvwg-port-randomisation-00 . . 18 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 82 Intellectual Property and Copyright Statements . . . . . . . . . . 20 84 1. Introduction 86 Recently, awareness has been raised about a number of "blind" attacks 87 that can be performed against the Transmission Control Protocol (TCP) 88 [RFC0793] and similar protocols. The consequences of these attacks 89 range from throughput-reduction to broken connections or data 90 corruption [I-D.ietf-tcpm-icmp-attacks] [I-D.ietf-tcpm-tcp-antispoof] 91 [Watson]. 93 All these attacks rely on the attacker's ability to guess or know the 94 four-tuple (Source Address, Source port, Destination Address, 95 Destination Port) that identifies the transport protocol instance to 96 be attacked. 98 Services are usually located at fixed, 'well-known' ports [IANA] at 99 the host supplying the service (the server). Client applications 100 connecting to any such service will contact the server by specifying 101 the server IP address and service port number. The IP address and 102 port number of the client are normally left unspecified by the client 103 application and thus chosen automatically by the client networking 104 stack. Ports chosen automatically by the networking stack are known 105 as ephemeral ports [Stevens]. 107 While the server IP address and well-known port and the client IP 108 address may be available to the attacker, the ephemeral port of the 109 client is usually unknown and must be guessed. 111 This document describes a method for random selection of the client 112 ephemeral port, thereby reducing the possibility of an off-path 113 attacker guessing the exact value. This is not a replacement for 114 cryptographic methods such as IPsec [RFC4301] or the TCP MD5 115 signature option [RFC2385]. However, the proposed algorithm provides 116 improved obfuscation with very little effort and without any key 117 management overhead. 119 The mechanism described is a local modification that may be 120 incrementally deployed, and does not violate the specifications of 121 any of the transport protocols that may benefit from it [RFC0793] 122 [RFC0768] [RFC2960] [RFC4340]. 124 Since the mechanism is an obfuscation technique, focus has been on a 125 reasonable compromise between level of obfuscation and ease of 126 implementation. Thus the algorithm must be computationally 127 efficient, and not require substantial data structures. 129 2. Ephemeral Ports 131 2.1. Traditional Ephemeral Port Range 133 The Internet Assigned Numbers Authority (IANA) assigns the unique 134 parameters and values used in protocols developed by the Internet 135 Engineering Task Force (IETF), including well-known ports [IANA]. 136 IANA has traditionally reserved the following use of the 16-bit port 137 range of TCP and UDP: 139 o The Well Known Ports, 0 through 1023. 141 o The Registered Ports, 1024 through 49151 143 o The Dynamic and/or Private Ports, 49152 through 65535 145 The range for assigned ports managed by the IANA is 0-1023, with the 146 remainder being registered by IANA but not assigned. 148 The ephemeral port range has traditionally consisted of the 49152- 149 65535 range. 151 2.2. Ephemeral port selection 153 As each communication instance is identified by the four-tuple {local 154 IP address, local port, remote IP address, remote port}, selection 155 ephemeral port numbers must result in a unique four-tuple. 157 Selection of ephemeral ports such that they result in unique four- 158 tuples is handled by some operating systems by having a global 'next 159 ephemeral port' variable that is equal to the previously chosen 160 ephemeral port + 1, i.e. the selection process is: 162 next_ephemeral_port = 1024; /*initialization, could be random */ 164 /* Ephemeral port selection */ 165 count = max_ephemeral - min_ephemeral + 1; 167 do { 168 port = next_ephemeral; 169 if (next_ephemeral == max_ephemeral) { 170 next_ephemeral = min_ephemeral; 171 } else { 172 next_ephemeral++; 173 } 175 if (four-tuple is unique) 176 return port; 178 } while (count > 0); 180 return ERROR; 182 Figure 1 184 We will refer to this as 'Algorithm 1'. 186 This algorithm works well provided that the number of connections 187 (globally, across all four-tuples) that has a life-time longer than 188 it takes to exhaust the total ephemeral port range is small, so that 189 four-tuple collisions are rare. 191 However, this method has the drawback that the 'next_ephemeral' 192 variable and thus the ephemeral port range is shared between all 193 connections and the next ports chosen by the client are easy to 194 predict. If an attacker operates an "innocent" server to which the 195 client connects, it is easy to obtain a reference point for the 196 current value of the 'next_ephemeral' variable. 198 3. Randomizing the Ephemeral Ports 200 3.1. Ephemeral port number range 202 As mentioned in Section 2.1, the ephemeral port range has 203 traditionally consisted of the 49152-65535 range. However, it should 204 also include the range 1024-49151 range. 206 Since this range includes user-specific server ports, this may not 207 always be possible, though. A possible workaround for this potential 208 problem would be to maintain an array of bits, in which each bit 209 would correspond to each of the port numbers in the range 1024-65535. 210 A bit set to 0 would indicate that the corresponding port is 211 available for allocation, while a bit set to one would indicate that 212 the port is reserved and therefore cannot be allocated. Thus, before 213 allocating a port number, the ephemeral port selection function would 214 check this array of bits, avoiding the allocation of ports that may 215 be needed for specific applications. 217 Transport protocols SHOULD use the largest possible port range, since 218 this improves the obfuscation provided by randomizing the ephemeral 219 ports. 221 3.2. Ephemeral Port Randomization Algorithms 223 In order to address the security issues discussed in Section 2.2, a 224 number of systems have implemented simple ephemeral port number 225 randomization, as follows: 227 next_ephemeral = min_ephemeral + random() 228 % (max_ephemeral - min_ephemeral + 1); 230 count = max_ephemeral - min_ephemeral + 1; 232 do { 233 if(four-tuple is unique) 234 return next_ephemeral; 236 if (next_ephemeral == max_ephemeral) { 237 next_ephemeral = min_ephemeral; 238 } else { 239 next_ephemeral_port++; 240 } 242 count--; 243 } while (count > 0); 245 return ERROR; 247 Figure 2 249 We will refer to this algorithm as 'Algorithm 2'. 251 Since the the chosen port may already be in use with identical IP 252 addresses and server port, the resulting four-tuple might not be 253 unique. Therefore, multiple ports may have to be tried and verified 254 against all existing connections before a port can be chosen. 256 Although carefully chosen random sources and optimized four-tuple 257 lookup mechanisms (e.g., optimized through hashing), will mitigate 258 the cost of this verification, some systems may still not want to 259 incur this unknown search time. 261 Systems that may be specially susceptible to this kind of repeated 262 four-tuple collisions are those that create many connections from a 263 single local IP address to a single service (i.e. both IP addresses 264 and server port are fixed). Gateways such as proxy servers are an 265 example of such a system. 267 Since this algorithm performs a completely random port selection 268 (i.e., without taking into account the port numbers previously 269 chosen), it has the potential of reusing port numbers too quickly. 270 Even if a given four-tuple is verified to be unique by the port 271 selection algorithm, there four-tuple might still be in use at the 272 remote system. In such a scenario, the connection request would 273 possible fail ([Silbersack] describes this problem in detail). 274 Therefore, it is desirable to keep the port reuse frequency as low as 275 possible. 277 We would like to achieve the port reuse properties of Algorithm 1, 278 while at the same time achieve the obfuscation properties of 279 Algorithm 2. 281 Ideally, we would like a 'next_ephemeral' value for each set of 282 (local IP address, remote IP addresses, remote port), so that the 283 port reuse frequency is the lowest possible. Each of these 284 'next_ephemeral' variables should be initialized with random values 285 within the ephemeral port range and would thus separate the ephemeral 286 port ranges of the connections entirely. Since we do not want to 287 maintain in memory all these 'next_ephemeral' values, we propose an 288 offset function F(), that can be computed from the local IP address, 289 remote IP address, remote port and a secret key. F() will yield 290 (practically) different values for each set of arguments, i.e.: 292 /* Initialization code */ 293 next_ephemeral = 0; /* could be random */ 295 /* Ephemeral port selection */ 296 offset = F(local_IP, remote_IP, remote_port, secret_key); 297 count = max_ephemeral - min_ephemeral + 1; 299 do { 300 port = min_ephemeral + (next_ephemeral + offset) 301 % (max_ephemeral - min_ephemeral + 1); 302 next_ephemeral++; 303 count--; 305 if(four-tuple is unique) 306 return port; 308 } while (count > 0); 310 return ERROR; 312 Figure 3 314 We will refer to this algorithm as 'Algorithm 3'. 316 In other words, the function F() provides a per-connection fixed 317 offset of the global ephemeral port range controlled by 318 'next_ephemeral'. Both the 'offset' and 'next_ephemeral' variables 319 may take any value within the storage type range since we are 320 restricting the resulting port similar to that shown in Figure 2. 321 This allows us to simply increment the 'next_ephemeral' variable and 322 rely on the unsigned integer to simply wrap-around. 324 The function F() should be a cryptographic hash function like MD5 325 [RFC1321]. The function should use both IP addresses, the remote 326 port and a secret key value to compute the offset. The remote IP 327 address is the primary separator and must be included in the offset 328 calculation. The local IP address and remote port may in some cases 329 be constant and not improve the connection separation, however, they 330 should also be included in the offset calculation. 332 Cryptographic algorithms stronger than e.g. MD5 should not be 333 necessary, given that port randomization is simply an obfuscation 334 technique. The secret should be chosen as random as possible, see 335 [RFC4086] for recommendations on choosing secrets. 337 Note that on multiuser systems, the function F() could include user 338 specific information, thereby providing protection not only on a host 339 to host basis, but on a user to service basis. 341 A tradeoff between maintaining a single global 'next_ephemeral' 342 variable and maintaining 2**N 'next_ephemeral' variables (where N is 343 the width of of the result of F()) could be achieved as follows. The 344 system would keep an array of, TABLE_LENGTH short integers, which 345 would provide a separation of the increment of the 'next_ephemeral' 346 variable. This improvement could be incorporated into Algorithm 3 as 347 follows: 349 /* Initialization code */ 350 for(i = 0; i < TABLE_LENGTH; i++) /* Initialization code */ 351 table[i] = random % 65536; 353 /* Ephemeral port selection */ 354 offset = F(local_IP, remote_IP, remote_port, secret_key); 355 index = G(offset); 356 count = max_ephemeral - min_ephemeral + 1; 358 do { 359 port = min_ephemeral + (offset + table[index]) 360 % (max_ephemeral - min_ephemeral + 1); 362 table[index]++; 363 count--; 365 if(four-tuple is unique) 366 return port; 368 } while (count > 0); 370 return ERROR; 372 Figure 4 374 'table[]' could be initialized with random values, as indicated by 375 the initialization code in Figure 4. G() would return a value 376 between 0 and (TABLE_LENGTH-1) taking 'offset' as its input. G() 377 could, for example, perform exclusive-or (xor) operation between all 378 the bytes in 'offset', or could be another cryptographic hash 379 function such as that used in F(). 381 The array 'table[]' assures that succesive connections to the same 382 end-point will use increasing ephemeral port numbers. However, 383 incrementation of the port numbers is separated into TABLE_LENGTH 384 different spaces, and thus the port reuse frequency will be 385 (probabilistically) lower than that of Algorithm 2. That is, a 386 connection established for a given for-tuple will not necessarily 387 cause the 'next_ephemeral' variable corresponding to other four- 388 tuples to be incremented. 390 It is interesting to note that the size of 'table[]' does not limit 391 the number of different port sequences, but rather separates the 392 *increments* into TABLE_LENGTH different spaces. The actual port 393 sequence will result from adding the corresponding entry of 'table[]' 394 to the variable 'offset', which actually selects the actual port 395 sequence (as in Algorithm 3). 397 3.3. Secret Key 399 Every complex manipulation (like MD5) is no more secure than the 400 input values, and in the case of ephemeral ports, the secret key. If 401 an attacker is aware of which cryptographic hash function is being 402 used by the victim (which we should expect), and the attacker can 403 obtain enough material (e.g. ephemeral ports chosen by the victim), 404 the attacker may simply search the entire secret key space to find 405 matches. 407 To protect against this, the secret key should be of a reasonable 408 length. Key-lengths of 32-bits should be adequate, since a 32-bit 409 secret would result in approximately 65k possible secrets if the 410 attacker is able to obtain a single ephemeral port (assuming a good 411 hash function). If the attacker is able to obtain more ephemeral 412 ports, key-lengths of 64-bits or more should be used. 414 Another possible mechanism for protecting the secret key is to change 415 it after some time. If the host platform is capable of producing 416 reasonable good random data, the secret key can be changed. 418 Changing the secret will cause abrupt shifts in the chosen ephemeral 419 ports, and consequently collisions may occur. Thus the change in 420 secret key should be done with consideration and could be performed 421 whenever one of the following events occur: 423 o Some predefined/random time has expired. 425 o The secret has been used N times (i.e. we consider it insecure). 427 o There are few active connections (i.e., possibility of collision 428 is low). 430 o There is little traffic (the performance overhead of collisions is 431 tolerated). 433 o There is enough random data available to change the secret key 434 (pseudo-random changes should not be done). 436 3.4. Choosing Algorithm 438 Algorithm 1 is the traditional ephemeral port selection algorithm 439 implemented in BSD-derived systems. It generates a global sequence 440 of ephemeral port numbers, which makes it trivial for an attacker to 441 predict the port number that will be used for a future transport 442 protocol instance. 444 Algorithm 2 has the advantage that it provides complete 445 randomization. However, it may increase the chances of port number 446 collisions, which could lead to failure of the connection 447 establishment attempts. 449 Algorithm 3 provides complete separation in local and remote IP 450 addresses and remote port space, and only limited separation in other 451 dimensions (See Section Section 3.3), and thus scales better than 452 Algorithm 2. However, implementations should consider the 453 performance impact of computing the cryptographic hash used for the 454 offset. 456 Algorithm 4 improves Algorithm 3, usually leading to a lower port 457 reuse frequency, at the expense of more processor cycles used for 458 computing G(), and additional kernel memory for storing the array 459 'table[]'. 461 Finally, a special case that precludes the utilization of Algorithm 3 462 and Algorithm 4 should be analyzed. There exist some applications 463 that contain the following code sequence: 465 s = socket(); 466 bind(s, IP_address, port = *); 468 Figure 5 470 This code sequence results in the selection of an ephemeral port 471 number. However, as neither the remote IP address nor the remote TCP 472 port will be available to the ephemeral port selection function, the 473 hash function F() used in Algorithm 3 and Algorithm 4 will not have 474 all the required arguments, and thus the result of the hash function 475 will be impossible to compute. 477 Transport protocols implementing Algorithm 3 or Algorithm 4 should 478 consider using Algorithm 2 when facing the scenario just described. 479 This policy has been implemented by Linux [Linux]. 481 4. Security Considerations 483 Randomizing ports is no replacement for cryptographic mechanisms, 484 such as IPsec [RFC4301]. 486 An eavesdropper, which can monitor the packets that correspond to the 487 connection to be attacked could learn the IP addresses and port 488 numbers in use (and also sequence numbers etc.) and easily attack the 489 connection. Randomizing ports does not provide any additional 490 protection against this kind of attacks. In such situations, proper 491 authentication mechanisms such as those described in [RFC4301] should 492 be used. 494 If the local offset function F() results in identical offsets for 495 different inputs, the port-offset mechanism proposed in this document 496 has no or reduced effect. 498 If random numbers are used as the only source of the secret key, they 499 must be chosen in accordance with the recommendations given in 500 [RFC4086]. 502 If all ports available in the ephemeral port range are in use, 503 randomization provides no obfuscation. 505 If an attacker uses dynamically assigned IP addresses, the current 506 ephemeral port offset (Algorithm 3 and Algorithm 4) for a given four- 507 tuple can be sampled and subsequently be used to attack an innocent 508 peer reusing this address. However, this is only possible until a 509 re-keying happens as described above. Also, since ephemeral ports 510 are only used on the client side (e.g. the one initiating the 511 connection), both the attacker and the new peer need to act as 512 servers in the scenario just described. While servers using dynamic 513 IP addresses exist, they are not very common and with an appropriate 514 re-keying mechanism the effect of this attack is limited. 516 5. Acknowledgements 518 The offset function was inspired by the mechanism proposed by Steven 519 Bellovin in [RFC1948] for defending against TCP sequence number 520 attacks. 522 The authors would like to thank Alfred Hoenes and Carlos Pignataro 523 for their valuable feedback on earlier versions of this document. 525 The authors would like to thank FreeBSD's Mike Silbersack for a very 526 fruitful discussion about ephemeral port selection techniques. 528 6. References 530 6.1. Normative References 532 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 533 RFC 793, September 1981. 535 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 536 August 1980. 538 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 539 April 1992. 541 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 542 Requirements for Security", BCP 106, RFC 4086, June 2005. 544 [RFC1948] Bellovin, S., "Defending Against Sequence Number Attacks", 545 RFC 1948, May 1996. 547 [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 548 Signature Option", RFC 2385, August 1998. 550 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 551 Internet Protocol", RFC 4301, December 2005. 553 [RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., 554 Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., 555 Zhang, L., and V. Paxson, "Stream Control Transmission 556 Protocol", RFC 2960, October 2000. 558 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 559 Congestion Control Protocol (DCCP)", RFC 4340, March 2006. 561 6.2. Informative References 563 [Watson] Watson, P., "Slipping in the Window: TCP Reset attacks", 564 december 2003. 566 [IANA] "IANA Port Numbers", 567 . 569 [Stevens] Stevens, W., "Unix Network Programming, Volume 1: 570 Networking APIs: Socket and XTI, Prentice Hall", 1998. 572 [Silbersack] 573 Silbersack, M., "Improving TCP/IP security through 574 randomization without sacrificing interoperability.", 575 EuroBSDCon 2005 Conference , 2005. 577 [I-D.ietf-tcpm-tcp-antispoof] 578 Touch, J., "Defending TCP Against Spoofing Attacks", 579 draft-ietf-tcpm-tcp-antispoof-05 (work in progress), 580 October 2006. 582 [I-D.ietf-tcpm-icmp-attacks] 583 Gont, F., "ICMP attacks against TCP", 584 draft-ietf-tcpm-icmp-attacks-01 (work in progress), 585 October 2006. 587 [Linux] The Linux Project, "http://www.kernel.org". 589 [FreeBSD] The FreeBSD Project, "http://www.freebsd.org". 591 [NetBSD] The NetBSD Project, "http://www.netbsd.org". 593 [OpenBSD] The OpenBSD Project, "http://www.openbsd.org". 595 Appendix A. Survey of the algorithms in use by some popular 596 implementations 598 A.1. FreeBSD 600 FreeBSD implements Algorithm 2. with a 'min_port' of 49152 and a 601 'max_port' of 65535. If the selected port number is in use, the next 602 available port number is tried next [FreeBSD]. 604 A.2. Linux 606 Linux implements Algorithm 3. If the algorithm is faced with the 607 corner-case scenario described in Section 3.4, Algorithm 2 is used 608 instead [Linux]. 610 A.3. NetBSD 612 NetBSD does not randomize ehemeral port numbers. It selects 613 ephemeral port numbers from the range 49152-65535, starting from port 614 65535, and decreasing the port number for each ephemeral port number 615 selected [NetBSD]. 617 A.4. OpenBSD 619 OpenBSD implements Algorithm 2. with a 'min_port' of 1024 and a 620 'max_port' of 49151. If the selected port number is in use, the next 621 available port number is tried next [OpenBSD]. 623 Appendix B. Changes from previous versions of the draft 625 B.1. Changes from draft-larsen-tsvwg-port-randomization-00 627 o Fixed a bug in expressions used to calculate number of ephemeral 628 ports 630 o Added a survey of the algorithms in use by popular TCP 631 implementations 633 o The whole document was reorganizaed 635 o Miscellaneous editorial changes 637 B.2. Changes from draft-larsen-tsvwg-port-randomisation-00 639 o Document resubmitted after original document by M. Larsen expired 640 in 2004 642 o References were included to current WG documents of the TCPM WG 644 o The document was made more general, to apply to all transport 645 protocols 647 o Miscellaneous editorial changes 649 Authors' Addresses 651 Michael Vittrup Larsen 652 Ericsson 653 Skanderborgvej 232 654 Aarhus DK-8260 655 Denmark 657 Phone: +45 8938 5100 658 Email: michael.vittrup.larsen@ericsson.com 660 Fernando Gont 661 Universidad Tecnologica Nacional / Facultad Regional Haedo 662 Evaristo Carriego 2644 663 Haedo, Provincia de Buenos Aires 1706 664 Argentina 666 Phone: +54 11 4650 8472 667 Email: fernando@gont.com.ar 669 Full Copyright Statement 671 Copyright (C) The IETF Trust (2007). 673 This document is subject to the rights, licenses and restrictions 674 contained in BCP 78, and except as set forth therein, the authors 675 retain all their rights. 677 This document and the information contained herein are provided on an 678 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 679 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 680 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 681 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 682 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 683 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 685 Intellectual Property 687 The IETF takes no position regarding the validity or scope of any 688 Intellectual Property Rights or other rights that might be claimed to 689 pertain to the implementation or use of the technology described in 690 this document or the extent to which any license under such rights 691 might or might not be available; nor does it represent that it has 692 made any independent effort to identify any such rights. Information 693 on the procedures with respect to rights in RFC documents can be 694 found in BCP 78 and BCP 79. 696 Copies of IPR disclosures made to the IETF Secretariat and any 697 assurances of licenses to be made available, or the result of an 698 attempt made to obtain a general license or permission for the use of 699 such proprietary rights by implementers or users of this 700 specification can be obtained from the IETF on-line IPR repository at 701 http://www.ietf.org/ipr. 703 The IETF invites any interested party to bring to its attention any 704 copyrights, patents or patent applications, or other proprietary 705 rights that may cover technology that may be required to implement 706 this standard. Please address the information to the IETF at 707 ietf-ipr@ietf.org. 709 Acknowledgment 711 Funding for the RFC Editor function is provided by the IETF 712 Administrative Support Activity (IASA).