[Search] [txt|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
tsvwg                                                         A. Ramaiah
Internet-Draft                                                   P. Tate
Intended status: Informational                             Cisco Systems
Expires: January 7, 2009                                    July 6, 2008

        Effects of port randomization with TCP TIME-WAIT state.

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on January 7, 2009.

Ramaiah & Tate           Expires January 7, 2009                [Page 1]

Internet-Draft          Port randomization issues              July 2008


   Source port randomization has been suggested to provide improved
   security and obfuscation which helps in adding robustness towards
   blind attacks.  With TCP in practice, simply producing a random port
   as the source port for a new connection can lead to problems when a
   TCP client establishes connections to a TCP server at a high rate.
   If the same source port value is chosen twice, the client TCP
   connection can fail due to the server having the Transmission Control
   Block (TCB) for this tuple lingering in TIME-WAIT state.

   This memo discusses the ramifications of such source port reuse
   scenarios and suggests some mitigations to avoid the same.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  The TIME-WAIT problem  . . . . . . . . . . . . . . . . . . . .  4
   3.  Approaches to avoid issues due to port randomization . . . . .  6
     3.1.  Recommended solution . . . . . . . . . . . . . . . . . . .  6
     3.2.  Implementation methods . . . . . . . . . . . . . . . . . .  6
       3.2.1.  Method 1: Bit Array and Timers . . . . . . . . . . . .  6
       3.2.2.  Method 2: Bit Array and Passive Timers . . . . . . . .  7
       3.2.3.  Method 3: 2-Bit Array and Timers . . . . . . . . . . .  7
   4.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . .  9
   5.  Informative References . . . . . . . . . . . . . . . . . . . . 10
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
   Intellectual Property and Copyright Statements . . . . . . . . . . 12

Ramaiah & Tate           Expires January 7, 2009                [Page 2]

Internet-Draft          Port randomization issues              July 2008

1.  Introduction

   The draft [I-D.ietf-tsvwg-port-randomization] recommends that
   transport protocols SHOULD allocate ephemeral port numbers randomly,
   since this improves obfuscation of ephemeral port numbers and thus,
   for relatively little cost, improves susceptibility to blind attacks.

   Choosing random ephemeral ports can lead to problems when TCP clients
   establish connections to TCP servers at a high rate or with a small
   ephemeral port range.  If an ephemeral port is randomly chosen twice
   before the TCP server has closed a TCB in TIME-WAIT for the port,
   this may result in connection failure or other side effects.

   The subsequent sections of this document cover the issue in detail
   and discuss solutions to the issue.  The methods described in this
   document are intended to complement and not replace those described
   in [I-D.ietf-tsvwg-port-randomization] .

Ramaiah & Tate           Expires January 7, 2009                [Page 3]

Internet-Draft          Port randomization issues              July 2008

2.  The TIME-WAIT problem

   When a TCP connection is actively closed by the server, it will keep
   the TCB of the connection around in TIME-WAIT state for 2*MSL.  The
   passive closer (client) removes its TCB altogether (once it gets the
   ACK for the FIN) for the connection and keeps no state.  When the
   client attempts a new connection to the server, if the random source
   port selection algorithm returns the same source port as the previous
   incarnation of this connection within the 2*MSL time period, one of
   the following things can happen :

   a) TIME-WAIT assassination of the server TCB.  As per RFC 793, if the
      SYN is in window, the server would respond with RST.  If the SYN
      is outside the window, an ACK would be sent back which would
      solicit an RST back.

   b) As per RFC 1122, some implementations would allow the SYN to be
      accepted to reopen the connection directly from TIME-WAIT state,
      if the sequence number of the SYN is larger than the largest
      sequence number it used on the previous connection incarnation.

   c) The SYN would be dropped by the server to prevent TIME-WAIT
      assassination.  This would cause the connection attempts from the
      client to stall until the server TCB is destroyed.

   It needs to be noted that TCP permits a condition known as
   simultaneous close where both ends send FIN and therefore end up in
   TIME-WAIT state.  In such cases, since the source port selection is a
   local decision, the new connection attempt can be made by choosing a
   different source port than the previous incarnation.  Of further
   note, if the client initiates the FIN and thus is the active closer
   of the connection, the client will retain a TCB in TIME-WAIT state,
   such that the random port algorithm should not be able to return this
   port as available.

   a) and c) can be attributed to the side effects of port
   randomization.  The behavior b) cannot be guaranteed to be
   implemented everywhere and also it depends on the sequence number
   which may be chosen randomly as well.  There are a few factors that
   can lead to scenarios described above occurring more readily:

   -  The Random Number Generator(RNG) is poor leading to repeated
      values often.  It needs to be noted that with a stateless RNG,
      frequent repetitions will occur (the birthday paradox).

Ramaiah & Tate           Expires January 7, 2009                [Page 4]

Internet-Draft          Port randomization issues              July 2008

   -  The ephemeral port range that the client is utilizing is small and
      not taking advantage of the large recommended port space which is
      1024-65535.  Moreover a host or a router can have many TCP
      applications running, which can result in active as well as
      passive connection opens which in turn puts a limit on the port

   -  The client is connecting to the server at a high rate, bringing up
      and tearing down connections quickly with respect to 2*MSL time.

   It is important to note that many applications (e.g., voice
   applications, RTP, etc.) are not designed to be able to take
   advantage of the full ephemeral port range and are required by the
   design characteristics of the application to only use a subset of
   these ports.  Even if all applications are able to take advantage of
   the full recommended ephemeral port range (1024 to 65535) and are
   able to utilize a very good random number generator, the connection
   rate can be high enough to lead to this TIME-WAIT problem.

   One of the main motivations to write this document stems from the
   fact that this issue was observed in the field with one of our voice
   gateway products.  The running code had the TCP/IP stack where the
   source ports were randomized.  The client application was the
   Interactive Voice Response (IVR) HTTP client which fetches VXML
   documents from a VXML server (Windows 2003) and does audio playback.
   When the connection load increased, many server connections were left
   hanging around in TIME-WAIT state.  The port randomization algorithm
   on the client sometimes returned repeated port values, which resulted
   in the server dropped the SYN packets.  This indirectly affected the
   connection rate and caused users to view this as a failure of the IVR
   application.  This problem did not occur in earlier versions of the
   TCP/IP stack which did not include port randomization but instead
   returned sequential ports.

Ramaiah & Tate           Expires January 7, 2009                [Page 5]

Internet-Draft          Port randomization issues              July 2008

3.  Approaches to avoid issues due to port randomization

3.1.  Recommended solution

   The solution lies in the client to avoid reusing the same source port
   for a duration of the server's TIME-WAIT state after it has passively
   closed the connection.  Since many servers may have varying TIME-WAIT
   timeouts, it is recommended that length of the timer SHOULD be 2*MSL
   or 4 minutes.  It needs to be noted that the TCB and connection
   resources can be released and only the source port would be marked
   unusable for this duration.

3.2.  Implementation methods

   The following subsections list some possible implementation methods
   for this issue.

3.2.1.  Method 1: Bit Array and Timers

   One approach to solving this problem is to utilize a bit array
   representing each possible port.  Each bit represents one of the
   ephemeral ports 1024 to 65535.  If the bit is 0, the port is
   available for use and if the bit is 1, the port is unavailable for

   When a connection is opened using an ephemeral port, the bit is set
   to 1 in the bit array.  When a connection is actively closed and
   transitions from TIME-WAIT to CLOSED and the TCB is removed, the bit
   representing the port is returned to 0.  When a connection is
   passively closed, no change is made to the bit array.  Instead, a
   timer is started for 2*MSL, and when it expires, the bit representing
   this port number in the bit array is returned to 0.

   The algorithm for generating random port numbers can then consult the
   bit array before returning a port as available.  If it is
   unavailable, find another port number instead to try.  Any of the 4
   algorithms for finding ports described in
   [I-D.ietf-tsvwg-port-randomization] can still be used with this
   approach.  This approach simply means the check:

   if (five-tuple is unique)

   includes consulting the bit array of ports to determine if a port is

   It is also important to note that this easily can be the same bit
   array referred to in [I-D.ietf-tsvwg-port-randomization] to keep the
   user-specific server ports from being returned by the random port

Ramaiah & Tate           Expires January 7, 2009                [Page 6]

Internet-Draft          Port randomization issues              July 2008

   number algorithm.  The user-specific server ports can be reserved
   using the bit array by setting the bits corresponding to the user-
   specific server ports to 1.  E.g., the setting of these bits could be
   performed when the listening port is opened.

3.2.2.  Method 2: Bit Array and Passive Timers

   This is same as the above except with the following variation.  The
   timer mentioned could be a passive timer, in the sense that instead
   of having an active timer running for each port, we could simply
   record the timestamp during connection closure.  A recurring timer
   (background process) which awakens every 2*MSL would scan the array
   and release all the ports whose timestamps have elapsed are >= 2*MSL
   from the recorded timestamp.  This has the drawback that the port
   reuse duration is indeterministic (i.e. somewhere between 2*MSL and

   Another slight variation of the above scheme would be to not have
   timer (background process) at all.  This is an on-demand approach,
   which relies on checking whether the source port satisfies the
   condition or not (i.e. 2*MSL has elapsed or not) at the time the port
   request happens (during bind() or implicit bind()).  The issue with
   this scheme is that you will have the array maintained for a longer
   period of time and also extra latency incurred to make sure whether
   the port is safe to be re-used.

3.2.3.  Method 3: 2-Bit Array and Timers

   The cost of implementing the approach described in 3.1 is relatively
   low in terms of memory space for the bit array (~8KBytes) , but may
   possibly require a timer running for all 64535 ephemeral ports.  An
   alternative approach is to utilize a 2-bit array and a single timer
   or sleeping (background) process.

   Two bits in the array are used to represent state for each port.  A
   bit setting of 00 indicates the port is available for use.  A bit
   setting of 01 indicates a port is in use.  When a connection is
   actively closed and transitions from TIME-WAIT to CLOSED and the TCB
   is removed, the bits representing the port are restored to 00.  When
   a connection is passively closed, the bits representing the port are
   set to 10.

   A single timer or sleeping process can be used to expire or awaken at
   an interval of 2*MSL.  When this timer event occurs or the process
   awakens, all ports in the table with bits set to 10 are set to 11,
   indicating the ports are ready to be released.  All ports in the
   table with bits set to 11 are then set to 00, and these ports are now
   available for use.

Ramaiah & Tate           Expires January 7, 2009                [Page 7]

Internet-Draft          Port randomization issues              July 2008

   This approach is similar to the approach mentioned in 3.2 except that
   it uses bit array to store the port state instead of having to store
   a timestamp which denotes the port release time.

Ramaiah & Tate           Expires January 7, 2009                [Page 8]

Internet-Draft          Port randomization issues              July 2008

4.  Acknowledgments

   Thanks to James Polk for his useful suggestions.  Thanks to Jason Kuo
   for his insight into the workings of the IVR client application.
   Special thanks to Siva Yaragalla for his comments and suggestions on
   various aspects of this draft.

Ramaiah & Tate           Expires January 7, 2009                [Page 9]

Internet-Draft          Port randomization issues              July 2008

5.  Informative References

              Larsen, M. and F. Gont, "Port Randomization",
              draft-ietf-tsvwg-port-randomization-01 (work in progress),
              February 2008.

   [RFC0793]  Postel, J., "Transmission Control Protocol", STD 7,
              RFC 793, September 1981.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

Ramaiah & Tate           Expires January 7, 2009               [Page 10]

Internet-Draft          Port randomization issues              July 2008

Authors' Addresses

   Anantha Ramaiah
   Cisco Systems
   170 Tasman Drive
   San Jose, CA  95134

   Phone: +1 (408) 525-6486
   Email: ananth@cisco.com

   Patrick Tate
   Cisco Systems
   4055 Faber Place Drive
   Suit 100
   North Charleston, South Carolina  29405

   Phone: +1 (678) 352-2730
   Email: ptate@cisco.com

Ramaiah & Tate           Expires January 7, 2009               [Page 11]

Internet-Draft          Port randomization issues              July 2008

Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at

Ramaiah & Tate           Expires January 7, 2009               [Page 12]