idnits 2.17.1 draft-ietf-tsvwg-port-randomization-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 15, 2010) is 4965 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Downref: Normative reference to an Informational RFC: RFC 1321 ** Obsolete normative reference: RFC 2385 (Obsoleted by RFC 5925) ** Obsolete normative reference: RFC 4960 (Obsoleted by RFC 9260) == Outdated reference: A later version (-03) exists of draft-ietf-tcpm-tcp-security-01 == Outdated reference: A later version (-32) exists of draft-ietf-tsvwg-sctpsocket-23 -- Obsolete informational reference (is this intentional?): RFC 1948 (Obsoleted by RFC 6528) Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Transport Area Working Group M. Larsen 3 (tsvwg) TietoEnator 4 Internet-Draft F. Gont 5 Intended status: BCP UTN/FRH 6 Expires: February 16, 2011 August 15, 2010 8 Transport Protocol Port Randomization Recommendations 9 draft-ietf-tsvwg-port-randomization-09 11 Abstract 13 During the last few years, awareness has been raised about a number 14 of "blind" attacks that can be performed against the Transmission 15 Control Protocol (TCP) and similar protocols. The consequences of 16 these attacks range from throughput-reduction to broken connections 17 or data corruption. These attacks rely on the attacker's ability to 18 guess or know the five-tuple (Protocol, Source Address, Destination 19 Address, Source Port, Destination Port) that identifies the transport 20 protocol instance to be attacked. This document describes a number 21 of simple and efficient methods for the selection of the client port 22 number, such that the possibility of an attacker guessing the exact 23 value is reduced. While this is not a replacement for cryptographic 24 methods for protecting the transport-protocol instance, the described 25 port number obfuscation algorithms provide improved security/ 26 obfuscation with very little effort and without any key management 27 overhead. The algorithms described in this document are local 28 policies that may be incrementally deployed, and that do not violate 29 the specifications of any of the transport protocols that may benefit 30 from them, such as TCP, UDP, UDP-lite, SCTP, DCCP, and RTP (provided 31 the RTP application explicitly signals the RTP and RTCP port 32 numbers). 34 Status of this Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at http://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on February 16, 2011. 50 Copyright Notice 52 Copyright (c) 2010 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 This document may contain material from IETF Documents or IETF 66 Contributions published or made publicly available before November 67 10, 2008. The person(s) controlling the copyright in some of this 68 material may not have granted the IETF Trust the right to allow 69 modifications of such material outside the IETF Standards Process. 70 Without obtaining an adequate license from the person(s) controlling 71 the copyright in such materials, this document may not be modified 72 outside the IETF Standards Process, and derivative works of it may 73 not be created outside the IETF Standards Process, except to format 74 it for publication as an RFC or to translate it into languages other 75 than English. 77 Table of Contents 79 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 80 2. Ephemeral Ports . . . . . . . . . . . . . . . . . . . . . . . 7 81 2.1. Traditional Ephemeral Port Range . . . . . . . . . . . . . 7 82 2.2. Ephemeral port selection . . . . . . . . . . . . . . . . . 7 83 2.3. Collision of instance-id's . . . . . . . . . . . . . . . . 9 84 3. Obfuscating the Ephemeral Ports . . . . . . . . . . . . . . . 10 85 3.1. Characteristics of a good ephemeral port obfuscation 86 algorithm . . . . . . . . . . . . . . . . . . . . . . . . 10 87 3.2. Ephemeral port number range . . . . . . . . . . . . . . . 12 88 3.3. Ephemeral Port Obfuscation Algorithms . . . . . . . . . . 12 89 3.3.1. Algorithm 1: Simple port randomization algorithm . . . 13 90 3.3.2. Algorithm 2: Another simple port randomization 91 algorithm . . . . . . . . . . . . . . . . . . . . . . 15 92 3.3.3. Algorithm 3: Simple hash-based algorithm . . . . . . . 15 93 3.3.4. Algorithm 4: Double-hash obfuscation algorithm . . . . 18 94 3.3.5. Algorithm 5: Random-increments port selection 95 algorithm . . . . . . . . . . . . . . . . . . . . . . 19 96 3.4. Secret-key considerations for hash-based port 97 obfuscation algorithms . . . . . . . . . . . . . . . . . . 21 98 3.5. Choosing an ephemeral port obfuscation algorithm . . . . . 22 99 4. Port obfuscation and Network Address Port Translation 100 (NAPT) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 101 5. Security Considerations . . . . . . . . . . . . . . . . . . . 26 102 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 103 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28 104 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 105 8.1. Normative References . . . . . . . . . . . . . . . . . . . 29 106 8.2. Informative References . . . . . . . . . . . . . . . . . . 30 107 Appendix A. Survey of the algorithms in use by some popular 108 implementations . . . . . . . . . . . . . . . . . . . 32 109 A.1. FreeBSD . . . . . . . . . . . . . . . . . . . . . . . . . 32 110 A.2. Linux . . . . . . . . . . . . . . . . . . . . . . . . . . 32 111 A.3. NetBSD . . . . . . . . . . . . . . . . . . . . . . . . . . 32 112 A.4. OpenBSD . . . . . . . . . . . . . . . . . . . . . . . . . 32 113 A.5. OpenSolaris . . . . . . . . . . . . . . . . . . . . . . . 32 114 Appendix B. Changes from previous versions of the draft (to 115 be removed by the RFC Editor before publication 116 of this document as a RFC . . . . . . . . . . . . . . 33 117 B.1. Changes from draft-ietf-tsvwg-port-randomization-08 . . . 33 118 B.2. Changes from draft-ietf-tsvwg-port-randomization-07 . . . 33 119 B.3. Changes from draft-ietf-tsvwg-port-randomization-06 . . . 33 120 B.4. Changes from draft-ietf-tsvwg-port-randomization-05 . . . 33 121 B.5. Changes from draft-ietf-tsvwg-port-randomization-04 . . . 33 122 B.6. Changes from draft-ietf-tsvwg-port-randomization-03 . . . 33 123 B.7. Changes from draft-ietf-tsvwg-port-randomization-02 . . . 33 124 B.8. Changes from draft-ietf-tsvwg-port-randomization-01 . . . 34 125 B.9. Changes from draft-ietf-tsvwg-port-randomization-00 . . . 34 126 B.10. Changes from draft-larsen-tsvwg-port-randomization-02 . . 34 127 B.11. Changes from draft-larsen-tsvwg-port-randomization-01 . . 34 128 B.12. Changes from draft-larsen-tsvwg-port-randomization-00 . . 34 129 B.13. Changes from draft-larsen-tsvwg-port-randomisation-00 . . 35 130 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36 132 1. Introduction 134 Recently, awareness has been raised about a number of "blind" attacks 135 (i.e., attacks that can be performed without the need to sniff the 136 packets that correspond to the transport protocol instance to be 137 attacked) that can be performed against the Transmission Control 138 Protocol (TCP) [RFC0793] and similar protocols. The consequences of 139 these attacks range from throughput-reduction to broken connections 140 or data corruption [RFC5927] [RFC4953] [Watson]. 142 All these attacks rely on the attacker's ability to guess or know the 143 five-tuple (Protocol, Source Address, Source port, Destination 144 Address, Destination Port) that identifies the transport protocol 145 instance to be attacked. 147 Services are usually located at fixed, 'well-known' ports [IANA] at 148 the host supplying the service (the server). Client applications 149 connecting to any such service will contact the server by specifying 150 the server IP address and service port number. The IP address and 151 port number of the client are normally left unspecified by the client 152 application and thus chosen automatically by the client networking 153 stack. Ports chosen automatically by the networking stack are known 154 as ephemeral ports [Stevens]. 156 While the server IP address and well-known port and the client IP 157 address may be known by an attacker, the ephemeral port of the client 158 is usually unknown and must be guessed. 160 This document describes a number of algorithms for the selection of 161 ephemeral port numbers, such that the possibility of an off-path 162 attacker guessing the exact value is reduced. They are not a 163 replacement for cryptographic methods of protecting a transport- 164 protocol instance such as IPsec [RFC4301], the TCP MD5 signature 165 option [RFC2385], or the TCP Authentication Option [RFC5925]. For 166 example, they do not provide any mitigation in those scenarios in 167 which the attacker is able to sniff the packets that correspond to 168 the transport protocol instance to be attacked. However, the 169 proposed algorithms provide improved obfuscation with very little 170 effort and without any key management overhead. 172 The mechanisms described in this document are local modifications 173 that may be incrementally deployed, and that do not violate the 174 specifications of any of the transport protocols that may benefit 175 from them, such as TCP [RFC0793], UDP [RFC0768], SCTP [RFC4960], DCCP 176 [RFC4340], UDP-lite [RFC3828], and RTP [RFC3550] (provided the RTP 177 application explicitly signals the RTP and RTCP port numbers with 178 e.g.[RFC3605]). 180 Since these mechanisms are obfuscation techniques, focus has been on 181 a reasonable compromise between the level of obfuscation and the ease 182 of implementation. Thus the algorithms must be computationally 183 efficient, and not require substantial state. 185 We note that while the technique of mitigating "blind" attacks by 186 obfuscating the ephemeral port selection is well-known as "port 187 randomization", the goal of the algorithms described in this document 188 is to reduce the chances of an attacker guessing the ephemeral ports 189 selected for new transport protocol instances, rather than to 190 actually produce mathematically random sequences of ephemeral ports. 192 Throughout this document we will use the term "transport-protocol 193 instance" as a general term to refer to an instantiation of a 194 transport protocol (e.g, a "connection" in the case of connection- 195 oriented transport protocols) and the term "instance-id" as a short- 196 handle to refer to the group of values that identify a transport- 197 protocol instance (e.g., in the case of TCP, the five-tuple 198 {Protocol, IP Source Address, TCP Source Port, IP Destination 199 Address, TCP Destination Port}). 201 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 202 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 203 document are to be interpreted as described in RFC 2119 [RFC2119]. 205 2. Ephemeral Ports 207 2.1. Traditional Ephemeral Port Range 209 The Internet Assigned Numbers Authority (IANA) assigns the unique 210 parameters and values used in protocols developed by the Internet 211 Engineering Task Force (IETF), including well-known ports [IANA]. 212 IANA has reserved the following use of the 16-bit port range of TCP 213 and UDP: 215 o The Well Known Ports, 0 through 1023. 217 o The Registered Ports, 1024 through 49151 219 o The Dynamic and/or Private Ports, 49152 through 65535 221 The dynamic port range defined by IANA consists of the 49152-65535 222 range, and is meant for the selection of ephemeral ports. 224 2.2. Ephemeral port selection 226 As each communication instance is identified by the five-tuple 227 {protocol, local IP address, local port, remote IP address, remote 228 port}, the selection of ephemeral port numbers must result in a 229 unique five-tuple. 231 Selection of ephemeral ports such that they result in unique 232 instance-id's (five-tuples) is handled by some implementations by 233 having a per-protocol global 'next_ephemeral' variable that is equal 234 to the previously chosen ephemeral port + 1, i.e. the selection 235 process is: 237 /* Initialization at system boot time. Could be random */ 238 next_ephemeral = min_ephemeral; 240 /* Ephemeral port selection function */ 241 count = max_ephemeral - min_ephemeral + 1; 243 do { 244 port = next_ephemeral; 245 if (next_ephemeral == max_ephemeral) { 246 next_ephemeral = min_ephemeral; 247 } else { 248 next_ephemeral++; 249 } 251 if (check_suitable_port(port)) 252 return port; 254 count--; 256 } while (count > 0); 258 return ERROR; 260 Figure 1 262 Note: 263 check_suitable_port() is a function that checks whether the 264 resulting port number is acceptable as an ephemeral port. That 265 is, it checks whether the resulting port number is unique and may, 266 in addition, check that the port number is not in use for a 267 connection in the LISTEN or CLOSED states and that the port number 268 is not in the list of port numbers that should not be allocated as 269 ephemeral ports. In BSD-derived systems, the 270 check_suitable_port() would correspond to the in_pcblookup_local() 271 function, where all the necessary checks would be performed. 273 This algorithm works adequately provided that the number of 274 transport-protocol instances (for a each transport protocol) that 275 have a life-time longer than it takes to exhaust the total ephemeral 276 port range is small, so that collisions of instance-id's are rare. 278 However, this method has the drawback that the 'next_ephemeral' 279 variable and thus the ephemeral port range is shared between all 280 transport-protocol instances and the next ports chosen by the client 281 are easy to predict. If an attacker operates an "innocent" server to 282 which the client connects, it is easy to obtain a reference point for 283 the current value of the 'next_ephemeral' variable. Additionally, if 284 an attacker could force a client to periodically establish e.g., a 285 new TCP connection to an attacker controlled machine (or through an 286 attacker observable routing path), the attacker could subtract 287 consecutive source port values to obtain the number of outgoing TCP 288 connections established globally by the target host within that time 289 period (up to wrap-around issues and instance-id collisions, of 290 course). 292 2.3. Collision of instance-id's 294 While it is possible for the ephemeral port selection algorithm to 295 verify that the selected port number results in a instance-id that is 296 not currently in use by that system, the resulting five-tuple may 297 still be in use at a remote system. For example, consider a scenario 298 in which a client establishes a TCP connection with a remote web 299 server, and the web server performs the active close on the 300 connection. While the state information for this connection will 301 disappear at the client side (that is, the connection will be moved 302 to the fictional CLOSED state), the instance-id will remain in the 303 TIME-WAIT state at the web server for 2*MSL (Maximum Segment 304 Lifetime). If the same client tried to create a new incarnation of 305 the previous connection (that is, a connection with the same 306 instance-id as the one in the TIME_WAIT state at the server), an 307 instance-id "collision" would occur. The effect of these collisions 308 range from connection-establishment failures to TIME-WAIT state 309 assassination (with the potential of data corruption) [RFC1337]. In 310 scenarios in which a specific client establishes TCP connections with 311 a specific service at a server, these problems become evident. 312 Therefore, an ephemeral port selection algorithm should ideally 313 minimize the rate of instance-id collisions. 315 A simple approach to minimize the rate of these collisions would be 316 to choose port numbers incrementally, so that a given port number 317 would not be reused until the rest of the port numbers in ephemeral 318 port range have been used for a transport protocol instance. 319 However, if a single global variable were used to keep track of the 320 last ephemeral port selected, ephemeral port numbers would be 321 trivially predictable, thus making it easier for an off-path attacker 322 to "guess" the instance-id in use by a target transport-protocol 323 instance. Section 3.3.3 and Section 3.3.4 describe algorithms that 324 select port numbers incrementally, while still making it difficult 325 for an off-path attacker to predict the ephemeral ports used for 326 future transport-protocol instances. 328 A simple but inefficient approach to minimize the rate of collisions 329 of instance-id's would be, e.g. in the case of TCP, for both end- 330 points of a TCP connection to keep state about recent connections 331 (e.g., have both end-points end up in the TIME-WAIT state). 333 3. Obfuscating the Ephemeral Ports 335 3.1. Characteristics of a good ephemeral port obfuscation algorithm 337 There are several factors to consider when designing an algorithm for 338 selecting ephemeral ports, which include: 340 o Minimizing the predictability of the ephemeral port numbers used 341 for future transport-protocol instances. 343 o Minimizing collisions of instance-id's 345 o Avoiding conflict with applications that depend on the use of 346 specific port numbers. 348 Given the goal of improving the transport protocol's resistance to 349 attack by obfuscation of the instance-id, it is key to minimize the 350 predictability of the ephemeral ports that will be selected for new 351 transport-protocol instances. While the obvious approach to address 352 this requirement would be to select the ephemeral ports by simply 353 picking a random value within the chosen port number range, this 354 straightforward policy may lead to collisions of instance-id's, which 355 could lead to the interoperability problems (e.g., delays in the 356 establishment of new connections, failures in connection- 357 establishment, or data corruption) discussed in Section 2.3. As 358 discussed in Section 1, it is worth noting that while the technique 359 of mitigating "blind" attacks by obfuscating the ephemeral port 360 election is well-known as "port randomization", the goal of the 361 algorithms described in this document is to reduce the chances of an 362 attacker guessing the ephemeral ports selected for new transport- 363 protocol instances, rather than to actually produce sequences of 364 mathematically random ephemeral port numbers. 366 It is also worth noting that, provided adequate algorithms are in 367 use, the larger the range from which ephemeral ports are selected, 368 the smaller the chances of an attacker are to guess the selected port 369 number. 371 In scenarios in which a specific client establishes transport- 372 protocol instances with a specific service at a server, the problems 373 described in Section 2.3 become evident. A good algorithm to 374 minimize the collisions of instance-id's would consider the time a 375 given five-tuple was last used, and would avoid reusing the last 376 recently used five-tuples. A simple approach to minimize the rate of 377 collisions would be to choose port numbers incrementally, so that a 378 given port number would not be reused until the rest of the port 379 numbers in the ephemeral port range have been used for a transport 380 protocol instance. However, if a single global variable were used to 381 keep track of the last ephemeral port selected, ephemeral port 382 numbers would be trivially predictable. 384 It is important to note that a number of applications rely on binding 385 specific port numbers that may be within the ephemeral ports range. 386 If such an application was run while the corresponding port number 387 was in use, the application would fail. Therefore, ephemeral port 388 selection algorithms avoid using those port numbers. 390 Port numbers that are currently in use by a TCP in the LISTEN state 391 should not be allowed for use as ephemeral ports. If this rule is 392 not complied with, an attacker could potentially "steal" an incoming 393 connection to a local server application in at least two different 394 ways. Firstly, an attacker could issue a connection request to the 395 victim client at roughly the same time the client tries to connect to 396 the victim server application [CPNI-TCP] 397 [I-D.ietf-tcpm-tcp-security]. If the SYN segment corresponding to 398 the attacker's connection request and the SYN segment corresponding 399 to the victim client "cross each other in the network", and provided 400 the attacker is able to know or guess the ephemeral port used by the 401 client, a TCP simultaneous open scenario would take place, and the 402 incoming connection request sent by the client would be matched with 403 the attacker's socket rather than with the victim server 404 application's socket. Secondly, an attacker could specify a more 405 specific socket than the "victim" socket (e.g., specify both the 406 local IP address and the local TCP port), and thus incoming SYN 407 segments matching the attacker's socket would be delivered to the 408 attacker, rather than to the "victim" socket (see Section 10.1 of 409 [CPNI-TCP]). 411 It should be noted that most applications based on popular 412 implementations of the TCP API (such as the Sockets API) perform 413 "passive opens" in three steps. Firstly, the application obtains a 414 file descriptor to be used for inter-process communication (e.g., by 415 issuing a socket() call). Secondly, the application binds the file 416 descriptor to a local TCP port number (e.g., by issuing a bind() 417 call), thus creating a TCP in the fictional CLOSED state. Thirdly, 418 the aforementioned TCP is put in the LISTEN state (e.g., by issuing a 419 listen() call). As a result, with such an implementation of the TCP 420 API, even if port numbers in use for TCPs in the LISTEN state were 421 not allowed for use as ephemeral ports, there is a window of time 422 between the second and the third steps in which an attacker could be 423 allowed to select a port number that would be later used for 424 listening to incoming connections. Therefore, these implementations 425 of the TCP API should enforce a stricter requirement for the 426 allocation of port numbers: port numbers that are in use by a TCP in 427 the LISTEN or CLOSED states should not be allowed for allocation as 428 ephemeral ports [CPNI-TCP] [I-D.ietf-tcpm-tcp-security]. 430 The aforementioned issue do not affect SCTP, since most SCTP 431 implementations do not allow a socket to be bound to the same port 432 number unless a specific socket option (SCTP_REUSE_PORT) is issued on 433 the socket (i.e., this behavior needs to be explicitly allowed 434 beforehand). An example of a typical SCTP socket API can be found in 435 [I-D.ietf-tsvwg-sctpsocket]. 437 DCCP is not affected by the exploitation of "simultaneous opens" to 438 "steal" incoming connections, as the server and the client state 439 machines are different [RFC4340]. However, it may be affected by the 440 vector involving binding a more specific socket. As a result, those 441 tuples {local IP address, local port, Service Code} that are in use 442 by a local socket should not be allowed for allocation as ephemeral 443 ports. 445 3.2. Ephemeral port number range 447 As mentioned in Section 2.1, the dynamic ports consist of the range 448 49152-65535. However, ephemeral port selection algorithms should use 449 the whole range 1024-65535. 451 This range includes the IANA Registered Ports, and thus some of these 452 port numbers may be needed for providing a particular service at the 453 local host, which could result in the problems discussed in 454 Section 3.1. As result, port numbers that may be needed for 455 providing a particular service at the local host SHOULD NOT be 456 included in the pool of port numbers available for ephemeral port 457 randomization. If the host does not provide a particular service, 458 the port can be safely allocated to ordinary processes. 460 A possible workaround for this potential problem would be to maintain 461 a local list of the port numbers that should not be allocated as 462 ephemeral ports. Thus, before allocating a port number, the 463 ephemeral port selection function would check this list, avoiding the 464 allocation of ports that may be needed for specific applications. 465 Rather than naively excluding all the registered ports, 466 administrators should identify services that may be offered by the 467 local host and SHOULD exclude only the corresponding registered 468 ports. 470 Ephemeral port selection algorithms SHOULD use the largest possible 471 port range, since this improves obfuscation. 473 3.3. Ephemeral Port Obfuscation Algorithms 475 Ephemeral port selection algorithms SHOULD obfuscate the allocation 476 of their ephemeral ports, since this helps to mitigate a number of 477 attacks that depend on the attacker's ability to guess or know the 478 five-tuple that identifies the transport protocol instance to be 479 attacked. 481 The following subsections describe a number of algorithms that could 482 be implemented in order to obfuscate the selection of ephemeral port 483 numbers. 485 3.3.1. Algorithm 1: Simple port randomization algorithm 487 In order to address the security issues discussed in Section 1 and 488 Section 2.2, a number of systems have implemented simple ephemeral 489 port number randomization, as follows: 491 /* Ephemeral port selection function */ 492 num_ephemeral = max_ephemeral - min_ephemeral + 1; 493 next_ephemeral = min_ephemeral + (random() % num_ephemeral); 494 count = num_ephemeral; 496 do { 497 if(check_suitable_port(port)) 498 return next_ephemeral; 500 if (next_ephemeral == max_ephemeral) { 501 next_ephemeral = min_ephemeral; 502 } else { 503 next_ephemeral++; 504 } 506 count--; 507 } while (count > 0); 509 return ERROR; 511 Figure 2 513 We will refer to this algorithm as 'Algorithm 1'. 515 Note: 516 random() is a function that returns a 32-bit pseudo-random 517 unsigned integer number. Note that the output needs to be 518 unpredictable, and typical implementations of POSIX random() 519 function do not necessarily meet this requirement. See [RFC4086] 520 for randomness requirements for security. 522 All the variables (in this and all the algorithms discussed in 523 this document) are unsigned integers. 525 Since the initially chosen port may already be in use with identical 526 IP addresses and server port, the resulting five-tuple might not be 527 unique. Therefore, multiple ports may have to be tried and verified 528 against all existing transport-protocol instances before a port can 529 be chosen. 531 Web proxy servers, NAPTs [RFC2663], and other middle-boxes aggregate 532 multiple peers into the same port space and thus increase the 533 population of used ephemeral ports, and hence the chances of 534 collisions of instance-id's. However, [Allman] has shown that at 535 least in the network scenarios used for measuring the collision 536 properties of the algorithms described in this document, the 537 collision rate resulting from the use of the aforementioned middle- 538 boxes is nevertheless very low. 540 Since this algorithm performs port selection without taking into 541 account the port numbers previously chosen, it has the potential of 542 reusing port numbers too quickly, thus possibly leading to collisions 543 of instance-id's. Even if a given instance-id is verified to be 544 unique by the port selection algorithm, the instance-id might still 545 be in use at the remote system. In such a scenario, a connection 546 request could possibly fail ([Silbersack] describes this problem for 547 the TCP case). 549 However, this algorithm is biased towards the first available port 550 after a sequence of unavailable port numbers. If the local list of 551 registered port numbers that should not be allocated as ephemeral 552 ports (as described in Section 3.2) is significant, an attacker may 553 actually have a significantly better chance of guessing a port 554 number. 556 This algorithm selects ephemeral port numbers randomly and thus 557 reduces the chances of an attacker of guessing the ephemeral port 558 selected for a target transport-protocol instance. Additionally, it 559 prevents attackers from obtaining the number of outgoing transport- 560 protocol instances (e.g., TCP connections) established by the client 561 in some period of time. 563 This algorithm selects ephemeral port numbers randomly and thus 564 reduces the chances of an attacker of guessing the ephemeral port 565 selected for a target transport-protocol instance. Additionally, it 566 prevents attackers from obtaining the number of outgoing transport- 567 protocol instances (e.g., TCP connections) established by the client 568 in some period of time. 570 3.3.2. Algorithm 2: Another simple port randomization algorithm 572 The following pseudo-code illustrates another algorithm for selecting 573 a random port number, in which in the event a local instance-id 574 collision is detected, another port number is selected randomly: 576 /* Ephemeral port selection function */ 577 num_ephemeral = max_ephemeral - min_ephemeral + 1; 578 next_ephemeral = min_ephemeral + (random() % num_ephemeral); 579 count = num_ephemeral; 581 do { 582 if(check_suitable_port(port)) 583 return next_ephemeral; 585 next_ephemeral = min_ephemeral + (random() % num_ephemeral); 586 count--; 587 } while (count > 0); 589 return ERROR; 591 Figure 3 593 We will refer to this algorithm as 'Algorithm 2'. This algorithm 594 might be unable to select an ephemeral port (i.e., return "ERROR") 595 even if there are port numbers that would result in unique five- 596 tuples, when there are a large number of port numbers already in use. 597 However, the results in [Allman] have shown that in common scenarios, 598 one port choice is enough, and in most cases where more than one 599 choice is needed two choices suffice. Therefore, in those scenarios 600 this would not be problem. 602 3.3.3. Algorithm 3: Simple hash-based algorithm 604 We would like to achieve the port reuse properties of the traditional 605 BSD port selection algorithm (described in Section 2.2), while at the 606 same time achieve the obfuscation properties of Algorithm 1 and 607 Algorithm 2. 609 Ideally, we would like a 'next_ephemeral' value for each set of 610 (local IP address, remote IP addresses, remote port), so that the 611 port reuse frequency is the lowest possible. Each of these 612 'next_ephemeral' variables should be initialized with random values 613 within the ephemeral port range and would thus separate the ephemeral 614 port space of the transport-protocol instances on a "per destination 615 end-point" basis (this "separation of the ephemeral port space" means 616 that transport-protocol instances with different remote end-points 617 will not have different sequences of port numbers; i.e., will not be 618 part of the same ephemeral port sequence as in the case of the 619 traditional BSD ephemeral port selection algorithm). Since we do not 620 want to maintain in memory all these 'next_ephemeral' values, we 621 propose an offset function F(), that can be computed from the local 622 IP address, remote IP address, remote port and a secret key. F() 623 will yield (practically) different values for each set of arguments, 624 i.e.: 626 /* Initialization at system boot time. Could be random. */ 627 next_ephemeral = 0; 629 /* Ephemeral port selection function */ 630 num_ephemeral = max_ephemeral - min_ephemeral + 1; 631 offset = F(local_IP, remote_IP, remote_port, secret_key); 632 count = num_ephemeral; 634 do { 635 port = min_ephemeral + 636 (next_ephemeral + offset) % num_ephemeral; 638 next_ephemeral++; 640 if(check_suitable_port(port)) 641 return port; 643 count--; 645 } while (count > 0); 647 return ERROR; 649 Figure 4 651 We will refer to this algorithm as 'Algorithm 3'. 653 In other words, the function F() provides a "per destination end- 654 point" fixed offset within the global ephemeral port range. Both the 655 'offset' and 'next_ephemeral' variables may take any value within the 656 storage type range since we are restricting the resulting port in a 657 similar way as in the Algorithm 1 (described in Section 3.3.1). This 658 allows us to simply increment the 'next_ephemeral' variable and rely 659 on the unsigned integer to simply wrap-around. 661 The function F() should be a cryptographic hash function like MD5 662 [RFC1321]. The function should use both IP addresses, the remote 663 port and a secret key value to compute the offset. The remote IP 664 address is the primary separator and must be included in the offset 665 calculation. The local IP address and remote port may in some cases 666 be constant and not improve the ephemeral port space separation, 667 however, they should also be included in the offset calculation. 669 Cryptographic algorithms stronger than e.g. MD5 should not be 670 necessary, given that Algorithm #3 is simply an obfuscation 671 technique. The secret should be chosen to be as random as possible 672 (see [RFC4086] for recommendations on choosing secrets). 674 Note that on multiuser systems, the function F() could include user 675 specific information, thereby providing protection not only on a host 676 to host basis, but on a user to service basis. In fact, any 677 identifier of the remote entity could be used, depending on 678 availability and the granularity requested. With SCTP both hostnames 679 and alternative IP addresses may be included in the association 680 negotiation and either of these could be used in the offset function 681 F(). 683 When multiple unique identifiers are available, any of these can be 684 chosen as input to the offset function F() since they all uniquely 685 identify the remote entity. However, in cases like SCTP where the 686 ephemeral port must be unique across all IP address permutations, we 687 should ideally always use the same IP address to get a single 688 starting offset for each association negotiation from a given remote 689 entity to minimize the possibility of collisions. A simple numerical 690 sorting of the IP addresses and always using the numerically lowest 691 could achieve this. However, since most protocols most likely will 692 report the same IP addresses in the same order in each association 693 setup, this sorting is most likely not necessary and the 'first one' 694 can simply be used. 696 The ability of hostnames to uniquely define hosts can be discussed, 697 and since SCTP always includes at least one IP address, we recommend 698 to use this as input to the offset function F() and ignore hostnames 699 chunks when searching for ephemeral ports. 701 It should be noted that, as this algorithm uses a global counter 702 ("next_ephemeral") for selecting ephemeral ports, if an attacker 703 could e.g., force a client to periodically establish a new TCP 704 connections to an attacker controlled machine (or through an attacker 705 observable routing path), the attacker could subtract consecutive 706 source port values to obtain the number of outgoing TCP connections 707 established globally by the target host within that time period (up 708 to wrap-around issues and 5-tuple collisions, of course). 710 3.3.4. Algorithm 4: Double-hash obfuscation algorithm 712 A tradeoff between maintaining a single global 'next_ephemeral' 713 variable and maintaining 2**N 'next_ephemeral' variables (where N is 714 the width of the result of F()) could be achieved as follows. The 715 system would keep an array of TABLE_LENGTH short integers, which 716 would provide a separation of the increment of the 'next_ephemeral' 717 variable. This improvement could be incorporated into Algorithm 3 as 718 follows: 720 /* Initialization at system boot time */ 721 for(i = 0; i < TABLE_LENGTH; i++) 722 table[i] = random() % 65536; 724 /* Ephemeral port selection function */ 725 num_ephemeral = max_ephemeral - min_ephemeral + 1; 726 offset = F(local_IP, remote_IP, remote_port, secret_key1); 727 index = G(local_IP, remote_IP, remote_port, secret_key2); 728 count = num_ephemeral; 730 do { 731 port = min_ephemeral + (offset + table[index]) % num_ephemeral; 732 table[index]++; 734 if(check_suitable_port(port)) 735 return port; 737 count--; 739 } while (count > 0); 741 return ERROR; 743 Figure 5 745 We will refer to this algorithm as 'Algorithm 4'. 747 'table[]' could be initialized with mathematically random values, as 748 indicated by the initialization code in pseudo-code above. The 749 function G() should be a cryptographic hash function like MD5 750 [RFC1321]. It should use both IP addresses, the remote port and a 751 secret key value to compute a value between 0 and (TABLE_LENGTH-1). 752 Alternatively, G() could take as "offset" as input, and perform the 753 exclusive-or (xor) operation between all the bytes in 'offset'. 755 The array 'table[]' assures that successive transport-protocol 756 instances with the same remote end-point will use increasing 757 ephemeral port numbers. However, incrementation of the port numbers 758 is separated into TABLE_LENGTH different spaces, and thus the port 759 reuse frequency will be (probabilistically) lower than that of 760 Algorithm 3. That is, a new tranport-protocol instance with some 761 remote end-point will not necessarily cause the 'next_ephemeral' 762 variable corresponding to other end-points to be incremented. 764 It is interesting to note that the size of 'table[]' does not limit 765 the number of different port sequences, but rather separates the 766 *increments* into TABLE_LENGTH different spaces. The port sequence 767 will result from adding the corresponding entry of 'table[]' to the 768 variable 'offset', which selects the actual port sequence (as in 769 Algorithm 3). [Allman] has found that a TABLE_LENGTH of 10 can 770 result in an improvement over Algorithm 3. Further increasing the 771 TABLE_LENGTH will increase the obfuscation, and possibly further 772 decrease the collision rate. 774 An attacker can perform traffic analysis for any "increment space" 775 into which the attacker has "visibility", namely that the attacker 776 can force the client to establish a transport-protocol instance whose 777 G(offset) identifies the target "increment space". However, the 778 attacker's ability to perform traffic analysis is very reduced when 779 compared to the traditional BSD algorithm (described in Section 2.2) 780 and Algorithm 3. Additionally, an implementation can further limit 781 the attacker's ability to perform traffic analysis by further 782 separating the increment space (that is, using a larger value for 783 TABLE_LENGTH). 785 3.3.5. Algorithm 5: Random-increments port selection algorithm 787 [Allman] introduced another port obfuscation algorithm, which offers 788 a middle ground between the algorithms that select ephemeral ports 789 randomly (such as those described in Section 3.3.1 and 790 Section 3.3.2), and those that offer obfuscation but no randomization 791 (such as those described in Section 3.3.3 and Section 3.3.4). We 792 will refer to this algorithm as 'Algorithm 5'. 794 /* Initialization code at system boot time. */ 795 next_ephemeral = random() % 65536; /* Initialization value */ 796 N = 500; /* Determines the tradeoff */ 798 /* Ephemeral port selection function */ 799 num_ephemeral = max_ephemeral - min_ephemeral + 1; 801 count = num_ephemeral; 803 do { 804 next_ephemeral = next_ephemeral + (random() % N) + 1; 805 port = min_ephemeral + (next_ephemeral % num_ephemeral); 807 if(check_suitable_port(port)) 808 return port; 810 count--; 811 } while (count > 0); 813 return ERROR; 815 Figure 6 817 This algorithm aims at at producing a monotonically-increasing 818 sequence to prevent the collision of instance-id's, while avoiding 819 the use of fixed increments, which would lead to trivially- 820 predictable sequences. The value "N" allows for direct control of 821 the tradeoff between the level of obfuscation and the port reuse 822 frequency. The smaller the value of "N", the more similar this 823 algorithm is to the traditional BSD port selection algorithm 824 (described in Section 2.2. The larger the value of "N", the more 825 similar this algorithm is to the algorithm described in Section 3.3.1 826 of this document. 828 When the port numbers wrap, there is the risk of collisions of 829 instance-id's. Therefore, "N" should be selecting according to the 830 following criteria: 832 o It should maximize the wrapping time of the ephemeral port space 834 o It should minimize collisions of instance-id's 836 o It should maximize obfuscation 838 Clearly, these are competing goals, and the decision of which value 839 of "N" to use is a tradeoff. Therefore, the value of "N" should be 840 configurable so that system administrators can make the tradeoff for 841 themselves. 843 3.4. Secret-key considerations for hash-based port obfuscation 844 algorithms 846 Every complex manipulation (like MD5) is no more secure than the 847 input values, and in the case of ephemeral ports, the secret key. If 848 an attacker is aware of which cryptographic hash function is being 849 used by the victim (which we should expect), and the attacker can 850 obtain enough material (e.g. ephemeral ports chosen by the victim), 851 the attacker may simply search the entire secret key space to find 852 matches. 854 To protect against this, the secret key should be of a reasonable 855 length. Key lengths of 128 bits should be adequate. 857 Another possible mechanism for protecting the secret key is to change 858 it after some time. If the host platform is capable of producing 859 reasonably good random data, the secret key can be changed 860 automatically. 862 Changing the secret will cause abrupt shifts in the chosen ephemeral 863 ports, and consequently collisions may occur. That is, upon changing 864 the secret, the "offset" value (see Section 3.3.3 and Section 3.3.4) 865 used for each destination end-point will be different from that 866 computed with the previous secret, thus leading to the selection of a 867 port number recently used for connecting to the same end-point. 869 Thus the change in secret key should be done with consideration and 870 could be performed whenever one of the following events occur: 872 o The system is being bootstrapped. 874 o Some predefined/random time has expired. 876 o The secret has been used N times (i.e. we consider it insecure). 878 o There are few active transport protocol instances (i.e., 879 possibility of collision is low). 881 o There is little traffic (the performance overhead of collisions is 882 tolerated). 884 o There is enough random data available to change the secret key 885 (pseudo-random changes should not be done). 887 3.5. Choosing an ephemeral port obfuscation algorithm 889 [Allman] is an empirical study of the properties of the algorithms 890 described in this document, which has found that all the algorithms 891 described in this document offer low collision rates -- at most 0.3%. 892 That is, in those network scenarios assessed by [Allman] all of the 893 algorithms described in this document perform well in terms of 894 collisions of instance-id's. However, these results may vary 895 depending on the characteristics of network traffic and the specific 896 network setup. 898 The algorithm described in Section 2.2 is the traditional ephemeral 899 port selection algorithm implemented in BSD-derived systems. It 900 generates a global sequence of ephemeral port numbers, which makes it 901 trivial for an attacker to predict the port number that will be used 902 for a future transport protocol instance. However, it is very 903 simple, and leads to a low port reuse frequency. 905 Algorithm 1 and Algorithm 2 have the advantage that they provide 906 actual randomization of the ephemeral ports. However, they may 907 increase the chances of port number collisions, which could lead to 908 the failure of a connection establishment attempt. [Allman] found 909 that these two algorithms show the largest collision rates (among all 910 the algorithms described in this document). 912 Algorithm 3 provides complete separation in local and remote IP 913 addresses and remote port space, and only limited separation in other 914 dimensions (see Section 3.4). However, implementations should 915 consider the performance impact of computing the cryptographic hash 916 used for the offset. 918 Algorithm 4 improves Algorithm 3, usually leading to a lower port 919 reuse frequency, at the expense of more processor cycles used for 920 computing G(), and additional kernel memory for storing the array 921 'table[]'. 923 Algorithm 5 offers middle ground between the simple randomization 924 algorithms (Algorithm 1 and Algorithm 2) and the hash-based 925 algorithms (Algorithm 3 and Algorithm 4). The upper limit on the 926 random increments (the value "N" in the pseudo-code included in 927 Section 3.3.5 controls the trade-off between randomization and port- 928 reuse frequency. 930 Finally, a special case that may preclude the utilization of 931 Algorithm 3 and Algorithm 4 should be analyzed. There exist some 932 applications that contain the following code sequence: 934 s = socket(); 935 bind(s, IP_address, port = *); 937 Figure 7 939 In some BSD-derived systems, the call to bind() will result in the 940 selection of an ephemeral port number. However, as neither the 941 remote IP address nor the remote port will be available to the 942 ephemeral port selection function, the hash function F() used in 943 Algorithm 3 and Algorithm 4 will not have all the required arguments, 944 and thus the result of the hash function will be impossible to 945 compute. Transport protocols implementing Algorithm 3 or Algorithm 4 946 should consider using Algorithm 2 when facing the scenario just 947 described. 949 An alternative to this behavior would be to implement "lazy binding" 950 in response to the bind() call. That is, selection of an ephemeral 951 port would be delayed until, e.g., connect() or send() are called. 952 Thus, at that point the ephemeral port is actually selected, all the 953 necessary arguments for the hash function F() would be available, and 954 thus Algorithm 3 and Algorithm 4 could still be used in this 955 scenario. This algorithm has been implemented by Linux [Linux]. 957 4. Port obfuscation and Network Address Port Translation (NAPT) 959 Network Address Port Translation (NAPT) translate both the network 960 address and transport-protocol port number, thus allowing the 961 transport identifiers of a number of private hosts to be multiplexed 962 into the transport identifiers of a single external address. 963 [RFC2663] 965 In those scenarios in which a NAPT is present between the two end- 966 points of transport-protocol instance, the obfuscation of the 967 ephemeral ports (from the point of view of the external network) will 968 depend on the ephemeral port selection function at the NAPT. 969 Therefore, NAPTs should consider obfuscating the ephemeral ports by 970 means of any of the algorithms discussed in this document. 972 A NAPT that does do not implement port preservation [RFC4787] 973 [RFC5382] SHOULD obfuscate the ephemeral port of a packet when it is 974 changed during translation of that packet. 976 A NAPT that does implement port preservation SHOULD obfuscate the 977 ephemeral port of a packet only if the port must be changed as a 978 result of the port being already in use for some other session. 980 A NAPT that performs parity preservation and that must change the 981 ephemeral port during translation of a packet SHOULD obfuscate the 982 ephemeral ports. The algorithms described in this document could be 983 easily adapted such that the parity is preserved (i.e., force the 984 lowest order bit of the resulting port number to 0 or 1 according to 985 whether even or odd parity is desired). 987 Some applications allocate contiguous ports and expect to see 988 contiguous port in use at their peers. Clearly, this expectation 989 might be difficult to accommodate at a NAPT, since some port numbers 990 might already be in use by other sessions, and thus an alternative 991 port might need to be selected, thus resulting in a non-contiguous 992 port number sequence (see Section 4.2.3 of [RFC4787]). A NAPT that 993 implements a simple port obfuscation algorithm (such as Algorithm 1, 994 Algorithm 2, or Algorithm 5) is likely to break this assumption, even 995 if the endpoint selecting an ephemeral port does select ephemeral 996 ports that are contiguous. However, since a number of different 997 ephemeral port selection algorithms have been implemented by deployed 998 NAPTs, any application that relies on any specific ephemeral port 999 selection algorithm at the NAPT is likely to suffer interoperability 1000 problems when a NAPT is present between the two endpoints of a 1001 transport protocol instance. Nevertheless, some of the algorithms 1002 described in this document (namely Algorithm 3 and Algorithm 4) 1003 select consecutive ephemeral ports such that they are contiguous 1004 (except when one of the port numbers needed to produce a contiguous 1005 sequence is already in use by some other NAPT session). Therefore, a 1006 NAPT willing to produce sequences of contiguous port numbers should 1007 consider implementing Algorithm 3 or Algorithm 4 of this document. 1008 Section 3.5 provides further guidance in choosing a port obfuscation 1009 algorithm. 1011 It should be noted that in some network scenarios, a NAPT may 1012 naturally obscure ephemeral port selections simply due to the vast 1013 range of services with which it establishes connections and to the 1014 overall rate of the traffic [Allman]. 1016 5. Security Considerations 1018 Obfuscating ephemeral ports is no replacement for cryptographic 1019 mechanisms, such as IPsec [RFC4301], in terms of protecting 1020 transport-protocol instances against blind attacks. 1022 An eavesdropper, which can monitor the packets that correspond to the 1023 transport-protocol instance to be attacked could learn the IP 1024 addresses and port numbers in use (and also sequence numbers etc.) 1025 and easily perform an attack. Ephemeral port obfuscation does not 1026 provide any additional protection against this kind of attacks. In 1027 such situations, proper authentication mechanisms such as those 1028 described in [RFC4301] should be used. 1030 This specification recommends including the whole range 1024-65535 1031 for the selection of ephemeral ports, and suggests that an 1032 implementation maintains a list of those port numbers that should not 1033 be made available for ephemeral port selection. If the list of port 1034 numbers that are not available is significant, Algorithm 1 may be 1035 highly biased and generate predictable ports, as noted in 1036 Section 3.3.1. In particular, if the list of IANA Registered Ports 1037 is accepted as the local list of port numbers that should not be made 1038 available, certain ports may result with 500 times the probability of 1039 other ports. Systems that support numerous applications resulting in 1040 large lists of unavailable ports, or that use the IANA Registered 1041 Ports without modification, MUST NOT use Algorithm 1. 1043 If the local offset function F() (in Algorithm 3 and Algorithm 4) 1044 results in identical offsets for different inputs at greater 1045 frequency than would be expected by chance, the port-offset mechanism 1046 proposed in this document would have a reduced effect. 1048 If random numbers are used as the only source of the secret key, they 1049 should be chosen in accordance with the recommendations given in 1050 [RFC4086]. 1052 If an attacker uses dynamically assigned IP addresses, the current 1053 ephemeral port offset (Algorithm 3 and Algorithm 4) for a given five- 1054 tuple can be sampled and subsequently used to attack an innocent peer 1055 reusing this address. However, this is only possible until a re- 1056 keying happens as described above. Also, since ephemeral ports are 1057 only used on the client side (e.g. the one initiating the transport- 1058 protocol communication), both the attacker and the new peer need to 1059 act as servers in the scenario just described. While servers using 1060 dynamic IP addresses exist, they are not very common and with an 1061 appropriate re-keying mechanism the effect of this attack is limited. 1063 6. IANA Considerations 1065 There are no IANA registries within this document. The RFC-Editor 1066 can remove this section before publication of this document as an 1067 RFC. 1069 7. Acknowledgements 1071 The offset function used in Algorithm 3 and Algorithm 4 was inspired 1072 by the mechanism proposed by Steven Bellovin in [RFC1948] for 1073 defending against TCP sequence number attacks. 1075 The authors would like to thank (in alphabetical order) Mark Allman, 1076 Jari Arkko, Matthias Bethke, Stephane Bortzmeyer, Brian Carpenter, 1077 Vincent Deffontaines, Ralph Droms, Lars Eggert, Pasi Eronen, Gorry 1078 Fairhurst, Adrian Farrel, Guillermo Gont, David Harrington, Alfred 1079 Hoenes, Avshalom Houri, Charlie Kaufman, Amit Klein, Carlos 1080 Pignataro, Tim Polk, Kacheong Poon, Pasi Sarolahti, Robert Sparks, 1081 Randall Stewart, Joe Touch, Michael Tuexen, Magnus Westerlund, and 1082 Dan Wing for their valuable feedback on earlier versions of this 1083 document. 1085 The authors would like to thank FreeBSD's Mike Silbersack for a very 1086 fruitful discussion about ephemeral port selection techniques. 1088 8. References 1090 8.1. Normative References 1092 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 1093 August 1980. 1095 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 1096 RFC 793, September 1981. 1098 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 1099 April 1992. 1101 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1102 Requirement Levels", BCP 14, RFC 2119, March 1997. 1104 [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 1105 Signature Option", RFC 2385, August 1998. 1107 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 1108 Jacobson, "RTP: A Transport Protocol for Real-Time 1109 Applications", STD 64, RFC 3550, July 2003. 1111 [RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute 1112 in Session Description Protocol (SDP)", RFC 3605, 1113 October 2003. 1115 [RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and 1116 G. Fairhurst, "The Lightweight User Datagram Protocol 1117 (UDP-Lite)", RFC 3828, July 2004. 1119 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 1120 Requirements for Security", BCP 106, RFC 4086, June 2005. 1122 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1123 Internet Protocol", RFC 4301, December 2005. 1125 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 1126 Congestion Control Protocol (DCCP)", RFC 4340, March 2006. 1128 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 1129 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 1130 RFC 4787, January 2007. 1132 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", 1133 RFC 4960, September 2007. 1135 [RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. 1137 Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, 1138 RFC 5382, October 2008. 1140 8.2. Informative References 1142 [Allman] Allman, M., "Comments On Selecting Ephemeral Ports", ACM 1143 Computer Communication Review, 39(2), 2009. 1145 [CPNI-TCP] 1146 Gont, F., "CPNI Technical Note 3/2009: Security Assessment 1147 of the Transmission Control Protocol (TCP)", http:// 1148 www.cpni.gov.uk/Docs/tn-03-09-security-assessment-TCP.pdf, 1149 2009. 1151 [FreeBSD] The FreeBSD Project, "http://www.freebsd.org". 1153 [I-D.ietf-tcpm-tcp-security] 1154 Gont, F., "Security Assessment of the Transmission Control 1155 Protocol (TCP)", draft-ietf-tcpm-tcp-security-01 (work in 1156 progress), February 2010. 1158 [I-D.ietf-tsvwg-sctpsocket] 1159 Stewart, R., Poon, K., Tuexen, M., Yasevich, V., and P. 1160 Lei, "Sockets API Extensions for Stream Control 1161 Transmission Protocol (SCTP)", 1162 draft-ietf-tsvwg-sctpsocket-23 (work in progress), 1163 July 2010. 1165 [IANA] "IANA Port Numbers", 1166 . 1168 [Linux] The Linux Project, "http://www.kernel.org". 1170 [NetBSD] The NetBSD Project, "http://www.netbsd.org". 1172 [OpenBSD] The OpenBSD Project, "http://www.openbsd.org". 1174 [OpenSolaris] 1175 OpenSolaris, "http://www.opensolaris.org". 1177 [RFC1337] Braden, B., "TIME-WAIT Assassination Hazards in TCP", 1178 RFC 1337, May 1992. 1180 [RFC1948] Bellovin, S., "Defending Against Sequence Number Attacks", 1181 RFC 1948, May 1996. 1183 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address 1184 Translator (NAT) Terminology and Considerations", 1185 RFC 2663, August 1999. 1187 [RFC4953] Touch, J., "Defending TCP Against Spoofing Attacks", 1188 RFC 4953, July 2007. 1190 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 1191 Authentication Option", RFC 5925, June 2010. 1193 [RFC5927] Gont, F., "ICMP Attacks against TCP", RFC 5927, July 2010. 1195 [Silbersack] 1196 Silbersack, M., "Improving TCP/IP security through 1197 randomization without sacrificing interoperability", 1198 EuroBSDCon 2005 Conference . 1200 [Stevens] Stevens, W., "Unix Network Programming, Volume 1: 1201 Networking APIs: Socket and XTI", Prentice Hall , 1998. 1203 [Watson] Watson, P., "Slipping in the Window: TCP Reset Attacks", 1204 CanSecWest 2004 Conference . 1206 Appendix A. Survey of the algorithms in use by some popular 1207 implementations 1209 A.1. FreeBSD 1211 FreeBSD 8.0 implements Algorithm 1, and in response to this document 1212 now uses a 'min_port' of 10000 and a 'max_port' of 65535. [FreeBSD] 1214 A.2. Linux 1216 Linux 2.6.15-53-386 implements Algorithm 3, with MD5 as the hash 1217 algorithm. If the algorithm is faced with the corner-case scenario 1218 described in Section 3.5, Algorithm 1 is used instead [Linux]. 1220 A.3. NetBSD 1222 NetBSD 5.0.1 does not obfuscate its ephemeral port numbers. It 1223 selects ephemeral port numbers from the range 49152-65535, starting 1224 from port 65535, and decreasing the port number for each ephemeral 1225 port number selected [NetBSD]. 1227 A.4. OpenBSD 1229 OpenBSD 4.2 implements Algorithm 1, with a 'min_port' of 1024 and a 1230 'max_port' of 49151. [OpenBSD] 1232 A.5. OpenSolaris 1234 OpenSolaris 2009.06 implements Algorithm 1, with a 'min_port' of 1235 32768 and a 'max_port' of 65535. [OpenSolaris] 1237 Appendix B. Changes from previous versions of the draft (to be removed 1238 by the RFC Editor before publication of this document as a 1239 RFC 1241 B.1. Changes from draft-ietf-tsvwg-port-randomization-08 1243 o Addresses Tim Polk's DISCUSSes 1245 o Addresses David Harrington's DISCUSS. 1247 o Addresses Robert Sparks's DISCUSS. 1249 B.2. Changes from draft-ietf-tsvwg-port-randomization-07 1251 o Addresses Jari Arkko's DISCUSS. 1253 B.3. Changes from draft-ietf-tsvwg-port-randomization-06 1255 o Fixes the writeo in the port number range. 1257 o Fixes the requirements on the random() function. 1259 o Other miscellaneous edits (resulting from IESG feedback. 1261 B.4. Changes from draft-ietf-tsvwg-port-randomization-05 1263 o Addresses AD review feedback from Lars Eggert. 1265 o Addresses AD review feedback from Lars Eggert. 1267 B.5. Changes from draft-ietf-tsvwg-port-randomization-04 1269 o Fixes nits. 1271 B.6. Changes from draft-ietf-tsvwg-port-randomization-03 1273 o Addresses WGLC comments from Mark Allman. See: 1274 http://www.ietf.org/mail-archive/web/tsvwg/current/msg09149.html 1276 B.7. Changes from draft-ietf-tsvwg-port-randomization-02 1278 o Added clarification of what we mean by "port randomization". 1280 o Addresses feedback sent on-list and off-list by Mark Allman. 1282 o Added references to [Allman] and [CPNI-TCP]. 1284 B.8. Changes from draft-ietf-tsvwg-port-randomization-01 1286 o Added Section 2.3. 1288 o Added discussion of "lazy binding in Section 3.5. 1290 o Added discussion of obtaining the number of outgoing connections. 1292 o Miscellaneous editorial changes 1294 B.9. Changes from draft-ietf-tsvwg-port-randomization-00 1296 o Added Section 3.1. 1298 o Changed Intended Status from "Standards Track" to "BCP". 1300 o Miscellaneous editorial changes. 1302 B.10. Changes from draft-larsen-tsvwg-port-randomization-02 1304 o Draft resubmitted as draft-ietf. 1306 o Included references and text on protocols other than TCP. 1308 o Added the second variant of the simple port randomization 1309 algorithm 1311 o Reorganized the algorithms into different sections 1313 o Miscellaneous editorial changes. 1315 B.11. Changes from draft-larsen-tsvwg-port-randomization-01 1317 o No changes. Draft resubmitted after expiration. 1319 B.12. Changes from draft-larsen-tsvwg-port-randomization-00 1321 o Fixed a bug in expressions used to calculate number of ephemeral 1322 ports 1324 o Added a survey of the algorithms in use by popular TCP 1325 implementations 1327 o The whole document was reorganized 1329 o Miscellaneous editorial changes 1331 B.13. Changes from draft-larsen-tsvwg-port-randomisation-00 1333 o Document resubmitted after original document by M. Larsen expired 1334 in 2004 1336 o References were included to current WG documents of the TCPM WG 1338 o The document was made more general, to apply to all transport 1339 protocols 1341 o Miscellaneous editorial changes 1343 Authors' Addresses 1345 Michael Vittrup Larsen 1346 TietoEnator 1347 Skanderborgvej 232 1348 Aarhus DK-8260 1349 Denmark 1351 Phone: +45 8938 5100 1352 Email: michael.larsen@tietoenator.com 1354 Fernando Gont 1355 Universidad Tecnologica Nacional / Facultad Regional Haedo 1356 Evaristo Carriego 2644 1357 Haedo, Provincia de Buenos Aires 1706 1358 Argentina 1360 Phone: +54 11 4650 8472 1361 Email: fernando@gont.com.ar