idnits 2.17.1 draft-ananth-tsvwg-timewait-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 317. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 328. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 335. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 341. 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 a Security Considerations section. ** 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.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (July 6, 2008) is 5773 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC0793' is defined on line 276, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 279, but no explicit reference was found in the text == Outdated reference: A later version (-09) exists of draft-ietf-tsvwg-port-randomization-01 -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 tsvwg A. Ramaiah 3 Internet-Draft P. Tate 4 Intended status: Informational Cisco Systems 5 Expires: January 7, 2009 July 6, 2008 7 Effects of port randomization with TCP TIME-WAIT state. 8 draft-ananth-tsvwg-timewait-00.txt 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on January 7, 2009. 35 Abstract 37 Source port randomization has been suggested to provide improved 38 security and obfuscation which helps in adding robustness towards 39 blind attacks. With TCP in practice, simply producing a random port 40 as the source port for a new connection can lead to problems when a 41 TCP client establishes connections to a TCP server at a high rate. 42 If the same source port value is chosen twice, the client TCP 43 connection can fail due to the server having the Transmission Control 44 Block (TCB) for this tuple lingering in TIME-WAIT state. 46 This memo discusses the ramifications of such source port reuse 47 scenarios and suggests some mitigations to avoid the same. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. The TIME-WAIT problem . . . . . . . . . . . . . . . . . . . . 4 53 3. Approaches to avoid issues due to port randomization . . . . . 6 54 3.1. Recommended solution . . . . . . . . . . . . . . . . . . . 6 55 3.2. Implementation methods . . . . . . . . . . . . . . . . . . 6 56 3.2.1. Method 1: Bit Array and Timers . . . . . . . . . . . . 6 57 3.2.2. Method 2: Bit Array and Passive Timers . . . . . . . . 7 58 3.2.3. Method 3: 2-Bit Array and Timers . . . . . . . . . . . 7 59 4. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 60 5. Informative References . . . . . . . . . . . . . . . . . . . . 10 61 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 62 Intellectual Property and Copyright Statements . . . . . . . . . . 12 64 1. Introduction 66 The draft [I-D.ietf-tsvwg-port-randomization] recommends that 67 transport protocols SHOULD allocate ephemeral port numbers randomly, 68 since this improves obfuscation of ephemeral port numbers and thus, 69 for relatively little cost, improves susceptibility to blind attacks. 71 Choosing random ephemeral ports can lead to problems when TCP clients 72 establish connections to TCP servers at a high rate or with a small 73 ephemeral port range. If an ephemeral port is randomly chosen twice 74 before the TCP server has closed a TCB in TIME-WAIT for the port, 75 this may result in connection failure or other side effects. 77 The subsequent sections of this document cover the issue in detail 78 and discuss solutions to the issue. The methods described in this 79 document are intended to complement and not replace those described 80 in [I-D.ietf-tsvwg-port-randomization] . 82 2. The TIME-WAIT problem 84 When a TCP connection is actively closed by the server, it will keep 85 the TCB of the connection around in TIME-WAIT state for 2*MSL. The 86 passive closer (client) removes its TCB altogether (once it gets the 87 ACK for the FIN) for the connection and keeps no state. When the 88 client attempts a new connection to the server, if the random source 89 port selection algorithm returns the same source port as the previous 90 incarnation of this connection within the 2*MSL time period, one of 91 the following things can happen : 93 a) TIME-WAIT assassination of the server TCB. As per RFC 793, if the 94 SYN is in window, the server would respond with RST. If the SYN 95 is outside the window, an ACK would be sent back which would 96 solicit an RST back. 98 b) As per RFC 1122, some implementations would allow the SYN to be 99 accepted to reopen the connection directly from TIME-WAIT state, 100 if the sequence number of the SYN is larger than the largest 101 sequence number it used on the previous connection incarnation. 103 c) The SYN would be dropped by the server to prevent TIME-WAIT 104 assassination. This would cause the connection attempts from the 105 client to stall until the server TCB is destroyed. 107 It needs to be noted that TCP permits a condition known as 108 simultaneous close where both ends send FIN and therefore end up in 109 TIME-WAIT state. In such cases, since the source port selection is a 110 local decision, the new connection attempt can be made by choosing a 111 different source port than the previous incarnation. Of further 112 note, if the client initiates the FIN and thus is the active closer 113 of the connection, the client will retain a TCB in TIME-WAIT state, 114 such that the random port algorithm should not be able to return this 115 port as available. 117 a) and c) can be attributed to the side effects of port 118 randomization. The behavior b) cannot be guaranteed to be 119 implemented everywhere and also it depends on the sequence number 120 which may be chosen randomly as well. There are a few factors that 121 can lead to scenarios described above occurring more readily: 123 - The Random Number Generator(RNG) is poor leading to repeated 124 values often. It needs to be noted that with a stateless RNG, 125 frequent repetitions will occur (the birthday paradox). 127 - The ephemeral port range that the client is utilizing is small and 128 not taking advantage of the large recommended port space which is 129 1024-65535. Moreover a host or a router can have many TCP 130 applications running, which can result in active as well as 131 passive connection opens which in turn puts a limit on the port 132 availability. 134 - The client is connecting to the server at a high rate, bringing up 135 and tearing down connections quickly with respect to 2*MSL time. 137 It is important to note that many applications (e.g., voice 138 applications, RTP, etc.) are not designed to be able to take 139 advantage of the full ephemeral port range and are required by the 140 design characteristics of the application to only use a subset of 141 these ports. Even if all applications are able to take advantage of 142 the full recommended ephemeral port range (1024 to 65535) and are 143 able to utilize a very good random number generator, the connection 144 rate can be high enough to lead to this TIME-WAIT problem. 146 One of the main motivations to write this document stems from the 147 fact that this issue was observed in the field with one of our voice 148 gateway products. The running code had the TCP/IP stack where the 149 source ports were randomized. The client application was the 150 Interactive Voice Response (IVR) HTTP client which fetches VXML 151 documents from a VXML server (Windows 2003) and does audio playback. 152 When the connection load increased, many server connections were left 153 hanging around in TIME-WAIT state. The port randomization algorithm 154 on the client sometimes returned repeated port values, which resulted 155 in the server dropped the SYN packets. This indirectly affected the 156 connection rate and caused users to view this as a failure of the IVR 157 application. This problem did not occur in earlier versions of the 158 TCP/IP stack which did not include port randomization but instead 159 returned sequential ports. 161 3. Approaches to avoid issues due to port randomization 163 3.1. Recommended solution 165 The solution lies in the client to avoid reusing the same source port 166 for a duration of the server's TIME-WAIT state after it has passively 167 closed the connection. Since many servers may have varying TIME-WAIT 168 timeouts, it is recommended that length of the timer SHOULD be 2*MSL 169 or 4 minutes. It needs to be noted that the TCB and connection 170 resources can be released and only the source port would be marked 171 unusable for this duration. 173 3.2. Implementation methods 175 The following subsections list some possible implementation methods 176 for this issue. 178 3.2.1. Method 1: Bit Array and Timers 180 One approach to solving this problem is to utilize a bit array 181 representing each possible port. Each bit represents one of the 182 ephemeral ports 1024 to 65535. If the bit is 0, the port is 183 available for use and if the bit is 1, the port is unavailable for 184 use. 186 When a connection is opened using an ephemeral port, the bit is set 187 to 1 in the bit array. When a connection is actively closed and 188 transitions from TIME-WAIT to CLOSED and the TCB is removed, the bit 189 representing the port is returned to 0. When a connection is 190 passively closed, no change is made to the bit array. Instead, a 191 timer is started for 2*MSL, and when it expires, the bit representing 192 this port number in the bit array is returned to 0. 194 The algorithm for generating random port numbers can then consult the 195 bit array before returning a port as available. If it is 196 unavailable, find another port number instead to try. Any of the 4 197 algorithms for finding ports described in 198 [I-D.ietf-tsvwg-port-randomization] can still be used with this 199 approach. This approach simply means the check: 201 if (five-tuple is unique) 203 includes consulting the bit array of ports to determine if a port is 204 available. 206 It is also important to note that this easily can be the same bit 207 array referred to in [I-D.ietf-tsvwg-port-randomization] to keep the 208 user-specific server ports from being returned by the random port 209 number algorithm. The user-specific server ports can be reserved 210 using the bit array by setting the bits corresponding to the user- 211 specific server ports to 1. E.g., the setting of these bits could be 212 performed when the listening port is opened. 214 3.2.2. Method 2: Bit Array and Passive Timers 216 This is same as the above except with the following variation. The 217 timer mentioned could be a passive timer, in the sense that instead 218 of having an active timer running for each port, we could simply 219 record the timestamp during connection closure. A recurring timer 220 (background process) which awakens every 2*MSL would scan the array 221 and release all the ports whose timestamps have elapsed are >= 2*MSL 222 from the recorded timestamp. This has the drawback that the port 223 reuse duration is indeterministic (i.e. somewhere between 2*MSL and 224 4*MSL) 226 Another slight variation of the above scheme would be to not have 227 timer (background process) at all. This is an on-demand approach, 228 which relies on checking whether the source port satisfies the 229 condition or not (i.e. 2*MSL has elapsed or not) at the time the port 230 request happens (during bind() or implicit bind()). The issue with 231 this scheme is that you will have the array maintained for a longer 232 period of time and also extra latency incurred to make sure whether 233 the port is safe to be re-used. 235 3.2.3. Method 3: 2-Bit Array and Timers 237 The cost of implementing the approach described in 3.1 is relatively 238 low in terms of memory space for the bit array (~8KBytes) , but may 239 possibly require a timer running for all 64535 ephemeral ports. An 240 alternative approach is to utilize a 2-bit array and a single timer 241 or sleeping (background) process. 243 Two bits in the array are used to represent state for each port. A 244 bit setting of 00 indicates the port is available for use. A bit 245 setting of 01 indicates a port is in use. When a connection is 246 actively closed and transitions from TIME-WAIT to CLOSED and the TCB 247 is removed, the bits representing the port are restored to 00. When 248 a connection is passively closed, the bits representing the port are 249 set to 10. 251 A single timer or sleeping process can be used to expire or awaken at 252 an interval of 2*MSL. When this timer event occurs or the process 253 awakens, all ports in the table with bits set to 10 are set to 11, 254 indicating the ports are ready to be released. All ports in the 255 table with bits set to 11 are then set to 00, and these ports are now 256 available for use. 258 This approach is similar to the approach mentioned in 3.2 except that 259 it uses bit array to store the port state instead of having to store 260 a timestamp which denotes the port release time. 262 4. Acknowledgments 264 Thanks to James Polk for his useful suggestions. Thanks to Jason Kuo 265 for his insight into the workings of the IVR client application. 266 Special thanks to Siva Yaragalla for his comments and suggestions on 267 various aspects of this draft. 269 5. Informative References 271 [I-D.ietf-tsvwg-port-randomization] 272 Larsen, M. and F. Gont, "Port Randomization", 273 draft-ietf-tsvwg-port-randomization-01 (work in progress), 274 February 2008. 276 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 277 RFC 793, September 1981. 279 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 280 Requirement Levels", BCP 14, RFC 2119, March 1997. 282 Authors' Addresses 284 Anantha Ramaiah 285 Cisco Systems 286 170 Tasman Drive 287 San Jose, CA 95134 288 USA 290 Phone: +1 (408) 525-6486 291 Email: ananth@cisco.com 293 Patrick Tate 294 Cisco Systems 295 4055 Faber Place Drive 296 Suit 100 297 North Charleston, South Carolina 29405 298 USA 300 Phone: +1 (678) 352-2730 301 Email: ptate@cisco.com 303 Full Copyright Statement 305 Copyright (C) The IETF Trust (2008). 307 This document is subject to the rights, licenses and restrictions 308 contained in BCP 78, and except as set forth therein, the authors 309 retain all their rights. 311 This document and the information contained herein are provided on an 312 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 313 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 314 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 315 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 316 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 317 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 319 Intellectual Property 321 The IETF takes no position regarding the validity or scope of any 322 Intellectual Property Rights or other rights that might be claimed to 323 pertain to the implementation or use of the technology described in 324 this document or the extent to which any license under such rights 325 might or might not be available; nor does it represent that it has 326 made any independent effort to identify any such rights. Information 327 on the procedures with respect to rights in RFC documents can be 328 found in BCP 78 and BCP 79. 330 Copies of IPR disclosures made to the IETF Secretariat and any 331 assurances of licenses to be made available, or the result of an 332 attempt made to obtain a general license or permission for the use of 333 such proprietary rights by implementers or users of this 334 specification can be obtained from the IETF on-line IPR repository at 335 http://www.ietf.org/ipr. 337 The IETF invites any interested party to bring to its attention any 338 copyrights, patents or patent applications, or other proprietary 339 rights that may cover technology that may be required to implement 340 this standard. Please address the information to the IETF at 341 ietf-ipr@ietf.org.