From sebastien.roy@oracle.com Mon May 3 10:47:24 2010 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o43HlOOR027956 for ; Mon, 3 May 2010 10:47:24 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o43HlN63010585 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Mon, 3 May 2010 12:47:23 -0500 (CDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L1U00307UQZ0800@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 03 May 2010 10:47:23 -0700 (PDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L1U00HJOUQZNA80@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 03 May 2010 10:47:23 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o43HlMqo014759 for ; Mon, 03 May 2010 17:47:22 +0000 (GMT) Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o431lVP8008028 for ; Mon, 03 May 2010 17:47:22 +0000 (GMT) Received: from abhmt017.oracle.com by acsmt354.oracle.com with ESMTP id 210422371272908841; Mon, 03 May 2010 10:47:21 -0700 Received: from [129.148.174.103] (/129.148.174.103) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 03 May 2010 10:47:20 -0700 Date: Mon, 03 May 2010 13:47:19 -0400 From: Sebastien Roy Subject: new socket options for TCP timers [PSARC/2010/151 FastTrack timeout 05/10/2010] To: psarc-ext Cc: Kacheong Poon Message-id: <4BDF0C27.4020700@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt353.oracle.com [141.146.40.153] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090202.4BDF0C2A.00B0:SCFMA4539814,ss=1,fgs=0 User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.8) Gecko/20100329 Lightning/1.0b1 Thunderbird/3.0.3 Status: RO Content-Length: 6481 I'm submitting this fast-track for Kacheong Poon, timing out on 05/10/2010. The release binding is Patch, and the stability level of new socket options is Committed. This case introduces four TCP level socket options, TCP_RTO_INITIAL, TCP_RTO_MIN, TCP_RTO_MAX, and TCP_LINGER2. This case also documents the existing options TCP_CONN_ABORT_THRESHOLD and TCP_ABORT_THRESHOLD. TCP_RTO_INITIAL, TCP_RTO_MIN, TCP_RTO_MAX ----------------------------------------- An application can use these three options to change/retrieve respectively the initial, minimum and maximum retransmission timeout values of a TCP connection. The option value is an uint32_t and the unit is millisecond (actual value is rounded up to the nearest clock tick interval). The lower bound of the options is 1ms. The upper bound of TCP_RTO_INITIAL is 20s. And the upper bound of TCP_RTO_MIN and TCP_RTO_MAX is 2 hours. 0 means no change on the timeout value. These options correspond to the private TCP parameters tcp_rexmit_interval_initial, tcp_rexmit_interval_min and tcp_rexmit_interval_max, which control the default values used in an IP stack. The lower and upper bounds of the options are the same as that of the private TCP parameters. Note that these socket options do not change TCP's dynamic RTO calculation. They only set the boundaries and initial value. For example, the default initial RTO is 3s because of "conservative" (meaning it seems to work) reason. It is really not correct since there is no estimation. If an app knows what it is, it is good to let it set the value. There must be a maximum value when TCP exponentially backs off RTO in doing retransmission. It does not make sense to back off without bound. If an app will abort the connection after a fixed time with no response from its peer, it makes sense to allow the app to control the maximum RTO. Otherwise, it may happen that there is no retransmission at all before the app terminates the connection. Similarly, there must be a minimum. RTO calculation may not converge quickly or the algorithm may not work well for certain type of network (*) and may cause false timeout. If an app knows better, it makes sense to let it set the value. TCP_CONN_ABORT_THRESHOLD, TCP_ABORT_THRESHOLD --------------------------------------------- An application can use these two options to change/retrieve the total time a TCP connection spent doing retransmission without getting back an acknowledgment. TCP_CONN_ABORT_THRESHOLD controls this interval before a connection is established. TCP_ABORT_THRESHOLD controls the interval after a connection is established. The option value is an uint32_t and the unit is millisecond (actual value is rounded up to the nearest clock tick interval). The lower bound of TCP_CONN_ABORT_THRESHOLD is 1000ms and the upper bound is UINT32_MAX ms. The lower bound of TCP_ABORT_THRESHOLD is 500ms and the upper bound is UINT32_MAX ms. These options correspond to the private TCP parameters tcp_ip_abort_cinterval and tcp_ip_abort_interval, which control the default values used in an IP stack. The lower and upper bound of the options are the same as that of the private parameters. TCP_LINGER2 ----------- An application can use this option to change/retrieve the amount of time a closed TCP connection stays in FIN-WAIT-2 state. The option value is an int and the unit is second. The lower bound is 1s and the upper bound is 4294967s (UINT32_MAX/1000). 0 means no change on the value. Negative value is not allowed. This option is introduced to ease porting Linux applications using this option to Solaris. It corresponds to the private TCP parameters tcp_fin_wait_2_flush_interval, which controls the default value used in an IP stack. The unit of this parameter is millisecond, which is different from that of the socket option because the option value unit needs to be the same as in Linux. The lower and upper bound of the option are the same (after unit conversion) as the private TCP parameter. The default value of tcp_fin_wait_2_flush_interval is also changed to 60s. Diff of tcp(7P) *************** *** 216,222 **** --- 216,237 ---- If the local TCP receives no acknowledgements from its peer for a period of time, (for example, if the remote machine crashes), the connection is closed and an error is returned. + The TCP level socket options, TCP_CONN_ABORT_THRESHOLD and + TCP_ABORT_THRESHOLD can be used to change and retrieve this + period of time. The option value is uint32_t and the unit is + millisecond. TCP_CONN_ABORT_THRESHOLD and TCP_ABORT_THRESHOLD + control respectively this period before and after a connection + is established. + During this period, TCP tries to retransmit the unacknowledged + data multiple times, each after a timeout. And the timeout + interval is exponentially backed off. The TCP level socket + options, TCP_RTO_INITIAL, TCP_RTO_MIN, and TCP_RTO_MAX can be + used to control the timeout interval. TCP_RTO_INITIAL controls + the initial retransmission timeout period. TCP_RTO_MIN and + TCP_RTO_MAX control the minimum and maximum timeout period + respectively. The option value is an uint32_t and the unit + is millisecond. TCP follows the congestion control algorithm described in RFC 2581, and also supports the initial congestion window *************** *** 434,439 **** --- 449,465 ---- the TCP ndd parameter tcp_keepalive_abort_interval. The default is eight minutes. + After an application closes a TCP connection, TCP enters the + shutdown sequence. But if the peer does not respond (it + crashes), the connection will be stuck in this state + (FIN-WAIT-2). To prevent this, SunOS starts a timer when TCP + enters this state. If the timer fires and the shutdown + sequence has not completed, the connection will be freed. The + socket option TCP_LINGER2 can be used to change and retrieve + this timeout period. The opton value is an int and the unit + is second. + + SEE ALSO svcs(1), ndd(1M), ioctl(2), read(2), svcadm(1M), write(2), accept(3SOCKET), bind(3SOCKET), connect(3SOCKET), (*) Existing mobile network is a good example. It buffers extensively (how much depends on the provider) and TCP's current algorithm does not work well with that. From garrett.damore@oracle.com Wed May 5 09:43:14 2010 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o45GhEdm029596 for ; Wed, 5 May 2010 09:43:14 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o45GhDRh012474 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 5 May 2010 10:43:13 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L1Y0080TH41YN00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 05 May 2010 09:43:13 -0700 (PDT) Received: from sca-ea-mail-3.sun.com ([192.18.43.21]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L1Y0053DH3XPP30@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 05 May 2010 09:43:09 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o45Gh9iM024357 for ; Wed, 05 May 2010 16:43:09 +0000 (GMT) Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o450r2xp008392 for ; Wed, 05 May 2010 16:43:07 +0000 (GMT) Received: from abhmt008.oracle.com by acsmt355.oracle.com with ESMTP id 216795441273077731; Wed, 05 May 2010 09:42:11 -0700 Received: from [10.7.251.172] (/10.7.251.172) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 05 May 2010 09:42:09 -0700 Date: Wed, 05 May 2010 09:42:05 -0700 From: "Garrett D'Amore" Subject: PSARC 2010/151 new socket options for TCP timers To: PSARC-ext Message-id: <4BE19FDD.90009@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090205.4BE1A01C.0126:SCFMA4539814,ss=1,fgs=0 User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.7) Gecko/20100214 Lightning/1.0b1 Thunderbird/3.0.1 Status: RO Content-Length: 630 I didn't see the mail for this, but I've reviewed the case history on sac.sfbay. It seems reasonable, but I do have some questions: 1) Can an ill-behaved application cause bad things to happen to the TCP stack by setting RTO or abort timers too high? I'm specifically thinking that by setting these timers to a large value, that it might be possible to cause out of control consumption of resources or exhaustion of TCP port numbers.... 2) Perhaps setting some of these values should require a privilege? 3) Ultimately, have the implications of these changes been reviewed from a security standpoint? - Garrett From sebastien.roy@oracle.com Wed May 5 09:54:01 2010 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o45Gs1Mg029895 for ; Wed, 5 May 2010 09:54:01 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o45Gs0j9018893 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 5 May 2010 10:54:00 -0600 (MDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L1Y00H0LHM06J00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 05 May 2010 10:54:00 -0600 (MDT) Received: from sca-ea-mail-1.sun.com ([192.18.43.24]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L1Y0089WHLZ3F60@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 05 May 2010 10:53:59 -0600 (MDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o45GrxJS029867 for ; Wed, 05 May 2010 16:53:59 +0000 (GMT) Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o45EkiPZ009016 for ; Wed, 05 May 2010 16:53:57 +0000 (GMT) Received: from abhmt004.oracle.com by acsmt354.oracle.com with ESMTP id 216823231273078359; Wed, 05 May 2010 09:52:39 -0700 Received: from [129.148.19.4] (/129.148.19.4) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 05 May 2010 09:52:38 -0700 Date: Wed, 05 May 2010 12:52:28 -0400 From: Sebastien Roy Subject: Re: PSARC 2010/151 new socket options for TCP timers In-reply-to: <4BE19FDD.90009@oracle.com> To: "Garrett D'Amore" Cc: PSARC-ext , ka-cheong.poon@oracle.com Message-id: <4BE1A24C.2010209@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt353.oracle.com [141.146.40.153] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090202.4BE1A2A6.0123:SCFMA4539814,ss=1,fgs=0 References: <4BE19FDD.90009@oracle.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.8) Gecko/20100412 Lightning/1.0b1 Thunderbird/3.0.3 Status: RO Content-Length: 975 (I've Cc'ed Kacheong so that he can reply to the specific questions) On 05/ 5/10 12:42 PM, Garrett D'Amore wrote: > I didn't see the mail for this, but I've reviewed the case history on > sac.sfbay. I sent it to psarc-ext@sun.com on Monday and it indeed seems to have made it to the case log. Perhaps a transient mail problem prevented it from reaching all eventual recipients... I'll let Kacheong reply to the rest. -Seb > It seems reasonable, but I do have some questions: > > 1) Can an ill-behaved application cause bad things to happen to the TCP > stack by setting RTO or abort timers too high? I'm specifically thinking > that by setting these timers to a large value, that it might be possible > to cause out of control consumption of resources or exhaustion of TCP > port numbers.... > > 2) Perhaps setting some of these values should require a privilege? > > 3) Ultimately, have the implications of these changes been reviewed from > a security standpoint? From ka-cheong.poon@oracle.com Wed May 5 10:56:10 2010 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o45HuAut003083 for ; Wed, 5 May 2010 10:56:10 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o45Hu7GV058347 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 5 May 2010 11:56:10 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L1Y0030RKHLS000@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 05 May 2010 10:56:09 -0700 (PDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L1Y00LSUKHKHU10@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 05 May 2010 10:56:08 -0700 (PDT) Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o45Hu7WU025867 for ; Wed, 05 May 2010 17:56:07 +0000 (GMT) Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o45GlMh9015701 for ; Wed, 05 May 2010 17:56:05 +0000 (GMT) Received: from abhmt006.oracle.com by acsmt353.oracle.com with ESMTP id 217007441273082103; Wed, 05 May 2010 10:55:03 -0700 Received: from [10.7.251.223] (/10.7.251.223) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 05 May 2010 10:55:02 -0700 Date: Thu, 06 May 2010 01:54:59 +0800 From: Kacheong Poon Subject: Re: PSARC 2010/151 new socket options for TCP timers In-reply-to: <4BE19FDD.90009@oracle.com> To: "Garrett D'Amore" Cc: PSARC-ext Message-id: <4BE1B0F3.5050704@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt353.oracle.com [141.146.40.153] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090202.4BE1B135.016B:SCFMA4539814,ss=1,fgs=0 References: <4BE19FDD.90009@oracle.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.9) Gecko/20100318 Lightning/1.0b1 Thunderbird/3.0.4 Status: RO Content-Length: 1810 On 05/ 6/10 12:42 AM, Garrett D'Amore wrote: > 1) Can an ill-behaved application cause bad things to happen to the TCP > stack by setting RTO or abort timers too high? I'm specifically thinking > that by setting these timers to a large value, that it might be possible > to cause out of control consumption of resources or exhaustion of TCP > port numbers.... The result is that TCP keeps on retransmitting and won't time out for the "long" (TCP_ABORT_THRESHOLD option value) period of time. But an app can do effectively the same thing without using the option by opening up another socket. > 2) Perhaps setting some of these values should require a privilege? I guess unless the system security or policy is affected, the use of a privilege may not be appropriate. IMHO, both are not affected. And from the point of view of resource consumption, an app can use effectively the same amount of resource without the help of the options, new and old (*). If folks are not comfortable with the current ranges of those existing TCP private parameters (the option value ranges are the same), I can certainly change them. > 3) Ultimately, have the implications of these changes been reviewed from > a security standpoint? I guess the implications are obvious. If folks on the list see a problem, please raise it. (*) Note that TCP_CONN_ABORT_THRESHOLD and TCP_ABORT_THRESHOLD have been in Solaris for a long time. I just checked the history, it was added in 1992. Although they were not documented by us, these two options are known in other network stacks. Given their history and the fact that we have not received (AFAIK) any complain, it is safe to assume that documenting them will not introduce new issues. -- K. Poon. ka-cheong.poon@oracle.com From garrett.damore@oracle.com Wed May 5 11:06:57 2010 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o45I6vgG003368 for ; Wed, 5 May 2010 11:06:57 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o45I6ukf065130 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 5 May 2010 12:06:57 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L1Y00605KZKFS00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 05 May 2010 11:06:56 -0700 (PDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L1Y00LKOKZJHU20@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 05 May 2010 11:06:55 -0700 (PDT) Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o45I6sNZ003164 for ; Wed, 05 May 2010 18:06:54 +0000 (GMT) Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o45I6qho019665 for ; Wed, 05 May 2010 18:06:52 +0000 (GMT) Received: from abhmt013.oracle.com by acsmt354.oracle.com with ESMTP id 217044131273082721; Wed, 05 May 2010 11:05:21 -0700 Received: from [10.7.251.172] (/10.7.251.172) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 05 May 2010 11:05:19 -0700 Date: Wed, 05 May 2010 11:05:18 -0700 From: "Garrett D'Amore" Subject: Re: PSARC 2010/151 new socket options for TCP timers In-reply-to: <4BE1B0F3.5050704@oracle.com> To: Kacheong Poon Cc: PSARC-ext Message-id: <4BE1B35E.4070205@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090206.4BE1B3BE.0066:SCFMA4539814,ss=1,fgs=0 References: <4BE19FDD.90009@oracle.com> <4BE1B0F3.5050704@oracle.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.7) Gecko/20100214 Lightning/1.0b1 Thunderbird/3.0.1 Status: RO Content-Length: 2729 Thanks for the clarification. The concern I have is that while an app can achieve the same resource exhaustion by opening multiple files, we *do* have ways to limit the total number of open files that an applications is permitted to have. By setting large values here, and then opening and closing TCP sockets repeatedly, it seems like these options might provide a (worsened) way to bypass those resource limitations. Admittedly, the damage here is limited to DoS executed from someone who already has gained arbitrary code execution capability on the system, but it still seems like this could be strengthened up a bit. The existence of the options in current code doesn't necessarily mean that the existing code doesn't suffer from the same flaw, and exposing it more broadly by documenting the behavior may worsen the situation. - Garrett On 05/ 5/10 10:54 AM, Kacheong Poon wrote: > On 05/ 6/10 12:42 AM, Garrett D'Amore wrote: > >> 1) Can an ill-behaved application cause bad things to happen to the TCP >> stack by setting RTO or abort timers too high? I'm specifically thinking >> that by setting these timers to a large value, that it might be possible >> to cause out of control consumption of resources or exhaustion of TCP >> port numbers.... > > > The result is that TCP keeps on retransmitting and won't time > out for the "long" (TCP_ABORT_THRESHOLD option value) period > of time. But an app can do effectively the same thing without > using the option by opening up another socket. > > >> 2) Perhaps setting some of these values should require a privilege? > > > I guess unless the system security or policy is affected, the > use of a privilege may not be appropriate. IMHO, both are not > affected. And from the point of view of resource consumption, > an app can use effectively the same amount of resource without > the help of the options, new and old (*). > > If folks are not comfortable with the current ranges of those > existing TCP private parameters (the option value ranges are > the same), I can certainly change them. > > >> 3) Ultimately, have the implications of these changes been reviewed from >> a security standpoint? > > > I guess the implications are obvious. If folks on the list > see a problem, please raise it. > > > (*) Note that TCP_CONN_ABORT_THRESHOLD and TCP_ABORT_THRESHOLD > have been in Solaris for a long time. I just checked the > history, it was added in 1992. Although they were not > documented by us, these two options are known in other > network stacks. Given their history and the fact that we > have not received (AFAIK) any complain, it is safe to assume > that documenting them will not introduce new issues. > > From Nicolas.Williams@oracle.com Wed May 5 11:28:28 2010 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o45ISSBM003709 for ; Wed, 5 May 2010 11:28:28 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o45ISOvm012600 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 5 May 2010 12:28:27 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L1Y0050VLZFKJ00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 05 May 2010 11:28:27 -0700 (PDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L1Y00KETLZEZJC0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 05 May 2010 11:28:26 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o45ISP9u023375 for ; Wed, 05 May 2010 18:28:25 +0000 (GMT) Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o45ERglL009365 for ; Wed, 05 May 2010 18:28:24 +0000 (GMT) Received: from abhmt012.oracle.com by acsmt355.oracle.com with ESMTP id 239930541273084079; Wed, 05 May 2010 11:27:59 -0700 Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 05 May 2010 11:27:58 -0700 Date: Wed, 05 May 2010 13:27:53 -0500 From: Nicolas Williams Subject: Re: PSARC 2010/151 new socket options for TCP timers In-reply-to: <4BE1B35E.4070205@oracle.com> To: "Garrett D'Amore" Cc: Kacheong Poon , PSARC-ext Message-id: <20100505182753.GC9429@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090204.4BE1B8C9.00C9:SCFMA4539814,ss=1,fgs=0 References: <4BE19FDD.90009@oracle.com> <4BE1B0F3.5050704@oracle.com> <4BE1B35E.4070205@oracle.com> User-Agent: Mutt/1.5.20 (2010-03-02) Status: RO Content-Length: 1566 On Wed, May 05, 2010 at 11:05:18AM -0700, Garrett D'Amore wrote: > Thanks for the clarification. The concern I have is that while an > app can achieve the same resource exhaustion by opening multiple > files, we *do* have ways to limit the total number of open files > that an applications is permitted to have. By setting large values > here, and then opening and closing TCP sockets repeatedly, it seems > like these options might provide a (worsened) way to bypass those > resource limitations. The app does not need an unlimited number of file descriptor numbers to do what Kacheong described. It can just keep opening new sockets to replace older ones, using say, a total of two or three file descriptor numbers. (You've done this manually, I'm sure: say you ssh somewhere, and then a packet loss spike causes your ssh connection to become unresponsive, so you start a new one and abandon the old one. I know I've done this, lots (it helps that I use screen(1).) > Admittedly, the damage here is limited to DoS executed from someone > who already has gained arbitrary code execution capability on the > system, but it still seems like this could be strengthened up a bit. I don't see how. > The existence of the options in current code doesn't necessarily > mean that the existing code doesn't suffer from the same flaw, and > exposing it more broadly by documenting the behavior may worsen the > situation. I don't think it does any such thing. Moreover, I think not having these options puts us at a disadvantage relative to competitors. Nico -- From ka-cheong.poon@oracle.com Wed May 5 11:32:56 2010 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o45IWuoi003752 for ; Wed, 5 May 2010 11:32:56 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o45IWqUb013039 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 5 May 2010 13:32:56 -0500 (CDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L1Y0052LM6UR100@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 05 May 2010 11:32:54 -0700 (PDT) Received: from sca-ea-mail-3.sun.com ([192.18.43.21]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L1Y00KBCM6TZ6D0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 05 May 2010 11:32:53 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o45IWrpG010975 for ; Wed, 05 May 2010 18:32:53 +0000 (GMT) Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o45HYOVH011963 for ; Wed, 05 May 2010 18:32:49 +0000 (GMT) Received: from abhmt005.oracle.com by acsmt355.oracle.com with ESMTP id 217123061273084330; Wed, 05 May 2010 11:32:10 -0700 Received: from [10.7.251.223] (/10.7.251.223) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 05 May 2010 11:32:10 -0700 Date: Thu, 06 May 2010 02:32:07 +0800 From: Kacheong Poon Subject: Re: PSARC 2010/151 new socket options for TCP timers In-reply-to: <4BE1B35E.4070205@oracle.com> To: "Garrett D'Amore" Cc: PSARC-ext Message-id: <4BE1B9A7.8030503@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt354.oracle.com [141.146.40.154] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090208.4BE1B9D3.00F5:SCFMA4539814,ss=1,fgs=0 References: <4BE19FDD.90009@oracle.com> <4BE1B0F3.5050704@oracle.com> <4BE1B35E.4070205@oracle.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.9) Gecko/20100318 Lightning/1.0b1 Thunderbird/3.0.4 Status: RO Content-Length: 1902 On 05/ 6/10 02:05 AM, Garrett D'Amore wrote: > Thanks for the clarification. The concern I have is that while an app > can achieve the same resource exhaustion by opening multiple files, we > *do* have ways to limit the total number of open files that an > applications is permitted to have. By setting large values here, and > then opening and closing TCP sockets repeatedly, it seems like these > options might provide a (worsened) way to bypass those resource > limitations. The options do not affect the total number of open file descriptors an app can have. Suppose there were really a way now for an app to "kill" a system by opening/closing TCP sockets repeatedly. Why can these options make things worse? The system is already dead, is there a worse situation than this? > Admittedly, the damage here is limited to DoS executed from someone who > already has gained arbitrary code execution capability on the system, > but it still seems like this could be strengthened up a bit. The key question is if there is a new DoS these options introduce which cannot be done without them. Please elaborate the new attack. > The existence of the options in current code doesn't necessarily mean > that the existing code doesn't suffer from the same flaw, and exposing > it more broadly by documenting the behavior may worsen the situation. As I mentioned in the previous mail, the two old options are documented in other OSes, such as HP-UX. So it is not like only folks with access to the Solaris source can know or use them. I am not saying that they have no flaw. But I don't understand the concern of making the situation worse by documenting them by us. They are never a secret. I can't see how one additional document can suddenly enlighten some hostile folks to do harm to some Solaris systems which they don't know before. -- K. Poon. ka-cheong.poon@oracle.com From sebastien.roy@oracle.com Wed May 5 11:56:21 2010 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o45IuL6P004425 for ; Wed, 5 May 2010 11:56:21 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o45IuKCL013007 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 5 May 2010 11:56:21 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L1Y00I13N9WLH00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 05 May 2010 11:56:20 -0700 (PDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L1Y00L3ZN9GHXA0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 05 May 2010 11:56:04 -0700 (PDT) Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o45Iu4PU004246 for ; Wed, 05 May 2010 18:56:04 +0000 (GMT) Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o44KxIZa017539 for ; Wed, 05 May 2010 18:56:01 +0000 (GMT) Received: from abhmt016.oracle.com by acsmt355.oracle.com with ESMTP id 217185481273085675; Wed, 05 May 2010 11:54:35 -0700 Received: from [129.148.174.103] (/129.148.174.103) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 05 May 2010 11:54:35 -0700 Date: Wed, 05 May 2010 14:54:31 -0400 From: Sebastien Roy Subject: new socket options for TCP timers [PSARC/2010/151 FastTrack timeout 05/10/2010] To: psarc-ext Cc: Kacheong Poon Message-id: <4BE1BEE7.4070405@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt353.oracle.com [141.146.40.153] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090203.4BE1BF43.0185:SCFMA4539814,ss=1,fgs=0 User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.8) Gecko/20100412 Lightning/1.0b1 Thunderbird/3.0.3 Status: RO Content-Length: 6563 (I'm resending this mail due to evidence that it was not received the first time) I'm submitting this fast-track for Kacheong Poon, timing out on 05/10/2010. The release binding is Patch, and the stability level of new socket options is Committed. This case introduces four TCP level socket options, TCP_RTO_INITIAL, TCP_RTO_MIN, TCP_RTO_MAX, and TCP_LINGER2. This case also documents the existing options TCP_CONN_ABORT_THRESHOLD and TCP_ABORT_THRESHOLD. TCP_RTO_INITIAL, TCP_RTO_MIN, TCP_RTO_MAX ----------------------------------------- An application can use these three options to change/retrieve respectively the initial, minimum and maximum retransmission timeout values of a TCP connection. The option value is an uint32_t and the unit is millisecond (actual value is rounded up to the nearest clock tick interval). The lower bound of the options is 1ms. The upper bound of TCP_RTO_INITIAL is 20s. And the upper bound of TCP_RTO_MIN and TCP_RTO_MAX is 2 hours. 0 means no change on the timeout value. These options correspond to the private TCP parameters tcp_rexmit_interval_initial, tcp_rexmit_interval_min and tcp_rexmit_interval_max, which control the default values used in an IP stack. The lower and upper bounds of the options are the same as that of the private TCP parameters. Note that these socket options do not change TCP's dynamic RTO calculation. They only set the boundaries and initial value. For example, the default initial RTO is 3s because of "conservative" (meaning it seems to work) reason. It is really not correct since there is no estimation. If an app knows what it is, it is good to let it set the value. There must be a maximum value when TCP exponentially backs off RTO in doing retransmission. It does not make sense to back off without bound. If an app will abort the connection after a fixed time with no response from its peer, it makes sense to allow the app to control the maximum RTO. Otherwise, it may happen that there is no retransmission at all before the app terminates the connection. Similarly, there must be a minimum. RTO calculation may not converge quickly or the algorithm may not work well for certain type of network (*) and may cause false timeout. If an app knows better, it makes sense to let it set the value. TCP_CONN_ABORT_THRESHOLD, TCP_ABORT_THRESHOLD --------------------------------------------- An application can use these two options to change/retrieve the total time a TCP connection spent doing retransmission without getting back an acknowledgment. TCP_CONN_ABORT_THRESHOLD controls this interval before a connection is established. TCP_ABORT_THRESHOLD controls the interval after a connection is established. The option value is an uint32_t and the unit is millisecond (actual value is rounded up to the nearest clock tick interval). The lower bound of TCP_CONN_ABORT_THRESHOLD is 1000ms and the upper bound is UINT32_MAX ms. The lower bound of TCP_ABORT_THRESHOLD is 500ms and the upper bound is UINT32_MAX ms. These options correspond to the private TCP parameters tcp_ip_abort_cinterval and tcp_ip_abort_interval, which control the default values used in an IP stack. The lower and upper bound of the options are the same as that of the private parameters. TCP_LINGER2 ----------- An application can use this option to change/retrieve the amount of time a closed TCP connection stays in FIN-WAIT-2 state. The option value is an int and the unit is second. The lower bound is 1s and the upper bound is 4294967s (UINT32_MAX/1000). 0 means no change on the value. Negative value is not allowed. This option is introduced to ease porting Linux applications using this option to Solaris. It corresponds to the private TCP parameters tcp_fin_wait_2_flush_interval, which controls the default value used in an IP stack. The unit of this parameter is millisecond, which is different from that of the socket option because the option value unit needs to be the same as in Linux. The lower and upper bound of the option are the same (after unit conversion) as the private TCP parameter. The default value of tcp_fin_wait_2_flush_interval is also changed to 60s. Diff of tcp(7P) *************** *** 216,222 **** --- 216,237 ---- If the local TCP receives no acknowledgements from its peer for a period of time, (for example, if the remote machine crashes), the connection is closed and an error is returned. + The TCP level socket options, TCP_CONN_ABORT_THRESHOLD and + TCP_ABORT_THRESHOLD can be used to change and retrieve this + period of time. The option value is uint32_t and the unit is + millisecond. TCP_CONN_ABORT_THRESHOLD and TCP_ABORT_THRESHOLD + control respectively this period before and after a connection + is established. + During this period, TCP tries to retransmit the unacknowledged + data multiple times, each after a timeout. And the timeout + interval is exponentially backed off. The TCP level socket + options, TCP_RTO_INITIAL, TCP_RTO_MIN, and TCP_RTO_MAX can be + used to control the timeout interval. TCP_RTO_INITIAL controls + the initial retransmission timeout period. TCP_RTO_MIN and + TCP_RTO_MAX control the minimum and maximum timeout period + respectively. The option value is an uint32_t and the unit + is millisecond. TCP follows the congestion control algorithm described in RFC 2581, and also supports the initial congestion window *************** *** 434,439 **** --- 449,465 ---- the TCP ndd parameter tcp_keepalive_abort_interval. The default is eight minutes. + After an application closes a TCP connection, TCP enters the + shutdown sequence. But if the peer does not respond (it + crashes), the connection will be stuck in this state + (FIN-WAIT-2). To prevent this, SunOS starts a timer when TCP + enters this state. If the timer fires and the shutdown + sequence has not completed, the connection will be freed. The + socket option TCP_LINGER2 can be used to change and retrieve + this timeout period. The opton value is an int and the unit + is second. + + SEE ALSO svcs(1), ndd(1M), ioctl(2), read(2), svcadm(1M), write(2), accept(3SOCKET), bind(3SOCKET), connect(3SOCKET), (*) Existing mobile network is a good example. It buffers extensively (how much depends on the provider) and TCP's current algorithm does not work well with that. From Andrew.Gabriel@oracle.com Wed May 5 12:21:58 2010 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o45JLvJX004848 for ; Wed, 5 May 2010 12:21:57 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o45JLt4M008732 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 5 May 2010 14:21:57 -0500 (CDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L1Y0070ROGKZ900@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 05 May 2010 12:21:56 -0700 (PDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L1Y0071COGJYK00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 05 May 2010 12:21:55 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o45JLs1b025605 for ; Wed, 05 May 2010 19:21:55 +0000 (GMT) Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o45H3fP3001767 for ; Wed, 05 May 2010 19:21:54 +0000 (GMT) Received: from abhmt016.oracle.com by acsmt354.oracle.com with ESMTP id 240101311273087295; Wed, 05 May 2010 12:21:35 -0700 Received: from [81.187.162.109] (/81.187.162.109) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 05 May 2010 12:21:34 -0700 Date: Wed, 05 May 2010 20:23:23 +0100 From: Andrew Gabriel Subject: Re: PSARC 2010/151 new socket options for TCP timers In-reply-to: <4BE1BD1C.5080407@oracle.com> To: PSARC-ext , ka-cheong.poon@oracle.com Message-id: <4BE1C5AB.2040603@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt353.oracle.com [141.146.40.153] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090206.4BE1C552.0199:SCFMA4539814,ss=1,fgs=0 References: <4BE1BD1C.5080407@oracle.com> User-Agent: Thunderbird 2.0.0.23 (X11/20090929) Status: RO Content-Length: 2850 Garrett D'Amore wrote: > I'm submitting this fast-track for Kacheong Poon, timing out on > 05/10/2010. The release binding is Patch, and the stability level of > new socket options is Committed. > > This case introduces four TCP level socket options, TCP_RTO_INITIAL, > TCP_RTO_MIN, TCP_RTO_MAX, and TCP_LINGER2. This case also documents > the existing options TCP_CONN_ABORT_THRESHOLD and TCP_ABORT_THRESHOLD. [...] > TCP_CONN_ABORT_THRESHOLD, TCP_ABORT_THRESHOLD > --------------------------------------------- > > An application can use these two options to change/retrieve the total > time a TCP connection spent doing retransmission without getting back > an acknowledgment. TCP_CONN_ABORT_THRESHOLD controls this interval > before a connection is established. TCP_ABORT_THRESHOLD controls the > interval after a connection is established. The option value is an > uint32_t and the unit is millisecond (actual value is rounded up to > the nearest clock tick interval). The lower bound of > TCP_CONN_ABORT_THRESHOLD is 1000ms and the upper bound is UINT32_MAX > ms. The lower bound of TCP_ABORT_THRESHOLD is 500ms and the upper > bound is UINT32_MAX ms. > > These options correspond to the private TCP parameters > tcp_ip_abort_cinterval and tcp_ip_abort_interval, which control the > default values used in an IP stack. The lower and upper bound of > the options are the same as that of the private parameters. I can see two cases where I would use these: 1) Where my application wants a short connection establishment timeout or a quick connection failure detection, i.e. shorter in either case than the default TCP values, because my application wants to take some other action in these cases before TCP is likely to have timed out the operation. 2) Where my application requires a permanent TCP connection, and I'm not interested in knowing about timeouts - just keep trying. Unfortunately, 2) is not quite handled in this case, as there are no values which are interpreted as infinity (i.e. no timeout), so I still have to handle the case where connect(), read(), write(), etc return timeouts, even if they do it less often. Having an infinity value might allow me to simplify my application coding (even though I still have to handle the possibility of a RST). Is the value 'zero' free to be interpreted as infinity? > TCP_LINGER2 > ----------- > > [...] The default value of tcp_fin_wait_2_flush_interval is also > changed to 60s. Just wondering if that's safe/acceptable for a patch binding? > Diff of tcp(7P) I would add something to say that changing these new parameters requires detailed knowledge of the application and the TCP protocol, and normally there is no need to change them. We're giving the programmer some rope, but it's worth warning him not to make a noose for himself. -- Andrew Gabriel From garrett.damore@oracle.com Wed May 5 12:31:10 2010 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o45JV9XW005119 for ; Wed, 5 May 2010 12:31:09 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o45JV9vF013390 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 5 May 2010 14:31:09 -0500 (CDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L1Y0042FOVX6C00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 05 May 2010 12:31:09 -0700 (PDT) Received: from sca-ea-mail-2.sun.com ([192.18.43.25]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L1Y00LK5OVWHZC0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 05 May 2010 12:31:08 -0700 (PDT) Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o45JV7H0000731 for ; Wed, 05 May 2010 19:31:08 +0000 (GMT) Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o45AL7dR012760 for ; Wed, 05 May 2010 19:31:06 +0000 (GMT) Received: from abhmt007.oracle.com by acsmt355.oracle.com with ESMTP id 240122531273087776; Wed, 05 May 2010 12:29:36 -0700 Received: from [10.7.251.172] (/10.7.251.172) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 05 May 2010 12:29:35 -0700 Date: Wed, 05 May 2010 12:29:32 -0700 From: "Garrett D'Amore" Subject: Re: PSARC 2010/151 new socket options for TCP timers In-reply-to: <4BE1B9A7.8030503@oracle.com> To: Kacheong Poon Cc: PSARC-ext Message-id: <4BE1C71C.10009@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt353.oracle.com [141.146.40.153] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090208.4BE1C77B.00AC:SCFMA4539814,ss=1,fgs=0 References: <4BE19FDD.90009@oracle.com> <4BE1B0F3.5050704@oracle.com> <4BE1B35E.4070205@oracle.com> <4BE1B9A7.8030503@oracle.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.7) Gecko/20100214 Lightning/1.0b1 Thunderbird/3.0.1 Status: RO Content-Length: 3385 On 05/ 5/10 11:32 AM, Kacheong Poon wrote: > On 05/ 6/10 02:05 AM, Garrett D'Amore wrote: >> Thanks for the clarification. The concern I have is that while an app >> can achieve the same resource exhaustion by opening multiple files, we >> *do* have ways to limit the total number of open files that an >> applications is permitted to have. By setting large values here, and >> then opening and closing TCP sockets repeatedly, it seems like these >> options might provide a (worsened) way to bypass those resource >> limitations. > > > The options do not affect the total number of open file > descriptors an app can have. Suppose there were really > a way now for an app to "kill" a system by opening/closing > TCP sockets repeatedly. Why can these options make things > worse? The system is already dead, is there a worse > situation than this? My point was that these timers could affect the resources that are consumed on the system *after* a socket is closed. Ultimately, that means that any limits already in existence that limit open files won't necessarily apply to these timers. While these timers don't necessarily *create* a *new* weakness, my concern is that increasing the value of the timers may make it *easier* for a malicious program to create a DoS situation. > > >> Admittedly, the damage here is limited to DoS executed from someone who >> already has gained arbitrary code execution capability on the system, >> but it still seems like this could be strengthened up a bit. > > > The key question is if there is a new DoS these options > introduce which cannot be done without them. Please > elaborate the new attack. Its not new.. its a situation where the DoS I described above can be *easier*. I'm not sure just how *much* easier it is, but that's the nature of the question I'm asking. If the networking and security folks have looked at this problem in particular, and decided it is a non-issue (or that I'm misunderstanding something here), then I'm satisfied. I'm simply asking the question, rather than insisting on a change or declaring the state busted. > > >> The existence of the options in current code doesn't necessarily mean >> that the existing code doesn't suffer from the same flaw, and exposing >> it more broadly by documenting the behavior may worsen the situation. > > > As I mentioned in the previous mail, the two old options are > documented in other OSes, such as HP-UX. So it is not like > only folks with access to the Solaris source can know or use > them. I am not saying that they have no flaw. But I don't > understand the concern of making the situation worse by > documenting them by us. They are never a secret. I can't > see how one additional document can suddenly enlighten some > hostile folks to do harm to some Solaris systems which they > don't know before. Certainly you're right -- security through obscurity is no security at all. Still, if we're going to document this functionality, then we ought (IMO) to at least *try* to make sure that they don't create a weakness in the system. It may well be that the risk is acceptable -- I'm pointing out my concern here, and am willing to live with the results of an informed decision, provided the decision is itself "informed" and made by the people with the knowledge to know whether the concerns are valid or not. - Garrett From Nicolas.Williams@oracle.com Wed May 5 12:49:05 2010 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o45Jn5pq005412 for ; Wed, 5 May 2010 12:49:05 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o45Jn2uW059334 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 5 May 2010 13:49:04 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L1Y00903PPS8K00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 05 May 2010 12:49:04 -0700 (PDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L1Y007QUPPRYB10@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 05 May 2010 12:49:03 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o45Jn3TO010776 for ; Wed, 05 May 2010 19:49:03 +0000 (GMT) Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o45FYXdC030734 for ; Wed, 05 May 2010 19:49:02 +0000 (GMT) Received: from abhmt015.oracle.com by acsmt353.oracle.com with ESMTP id 217323501273088941; Wed, 05 May 2010 12:49:01 -0700 Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 05 May 2010 12:49:00 -0700 Date: Wed, 05 May 2010 14:48:56 -0500 From: Nicolas Williams Subject: Re: PSARC 2010/151 new socket options for TCP timers In-reply-to: <4BE1B35E.4070205@oracle.com> To: "Garrett D'Amore" Cc: Kacheong Poon , PSARC-ext Message-id: <20100505194855.GE9429@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt353.oracle.com [141.146.40.153] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090207.4BE1CBAE.01A7:SCFMA4539814,ss=1,fgs=0 References: <4BE19FDD.90009@oracle.com> <4BE1B0F3.5050704@oracle.com> <4BE1B35E.4070205@oracle.com> User-Agent: Mutt/1.5.20 (2010-03-02) Status: RO Content-Length: 312 What happens when a socket in FIN_WAIT2 is close()d, or a process exits and a socket is closed and ends up in FIN_WAIT2? If the FIN_WAIT2 timer is set to 2^31, what happens? Suppose the process is able to exit but the socket lingers. In that case will the lingering socket defeat resource controls? Nico -- From garrett.damore@oracle.com Wed May 5 12:59:34 2010 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o45JxYUA005809 for ; Wed, 5 May 2010 12:59:34 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o45JxXgA027357 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 5 May 2010 14:59:34 -0500 (CDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L1Y00B05Q79CC00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 05 May 2010 12:59:33 -0700 (PDT) Received: from sca-ea-mail-1.sun.com ([192.18.43.24]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L1Y008YPQ79IU00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 05 May 2010 12:59:33 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o45JxXjR014602 for ; Wed, 05 May 2010 19:59:33 +0000 (GMT) Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o457etnT011056 for ; Wed, 05 May 2010 19:59:32 +0000 (GMT) Received: from abhmt001.oracle.com by acsmt354.oracle.com with ESMTP id 217349091273089515; Wed, 05 May 2010 12:58:35 -0700 Received: from [10.7.251.172] (/10.7.251.172) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 05 May 2010 12:58:34 -0700 Date: Wed, 05 May 2010 12:58:33 -0700 From: "Garrett D'Amore" Subject: Re: PSARC 2010/151 new socket options for TCP timers In-reply-to: <20100505194855.GE9429@oracle.com> To: Nicolas Williams Cc: Kacheong Poon , PSARC-ext Message-id: <4BE1CDE9.8090600@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt353.oracle.com [141.146.40.153] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090204.4BE1CE24.0162:SCFMA4539814,ss=1,fgs=0 References: <4BE19FDD.90009@oracle.com> <4BE1B0F3.5050704@oracle.com> <4BE1B35E.4070205@oracle.com> <20100505194855.GE9429@oracle.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.7) Gecko/20100214 Lightning/1.0b1 Thunderbird/3.0.1 Status: RO Content-Length: 502 On 05/ 5/10 12:48 PM, Nicolas Williams wrote: > What happens when a socket in FIN_WAIT2 is close()d, or a process exits > and a socket is closed and ends up in FIN_WAIT2? If the FIN_WAIT2 timer > is set to 2^31, what happens? > > Suppose the process is able to exit but the socket lingers. In that > case will the lingering socket defeat resource controls? > > Nico > *This* is exactly the kind of issue I was talking about. Thanks for making it clearer than I was able to do. - Garrett From Nicolas.Williams@oracle.com Wed May 5 13:03:50 2010 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o45K3o1u005939 for ; Wed, 5 May 2010 13:03:50 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o45K3kWG001958 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 5 May 2010 14:03:49 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L1Y00905QEDY600@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 05 May 2010 13:03:49 -0700 (PDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L1Y007NQQECYD20@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 05 May 2010 13:03:49 -0700 (PDT) Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o45K3mEB012102 for ; Wed, 05 May 2010 20:03:48 +0000 (GMT) Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o45K3lPe023142 for ; Wed, 05 May 2010 20:03:47 +0000 (GMT) Received: from abhmt003.oracle.com by acsmt354.oracle.com with ESMTP id 217359861273089765; Wed, 05 May 2010 13:02:45 -0700 Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 05 May 2010 13:02:44 -0700 Date: Wed, 05 May 2010 15:02:35 -0500 From: Nicolas Williams Subject: Re: PSARC 2010/151 new socket options for TCP timers In-reply-to: <4BE1CDE9.8090600@oracle.com> To: "Garrett D'Amore" Cc: Kacheong Poon , PSARC-ext Message-id: <20100505200235.GF9429@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090204.4BE1CF23.01CE:SCFMA4539814,ss=1,fgs=0 References: <4BE19FDD.90009@oracle.com> <4BE1B0F3.5050704@oracle.com> <4BE1B35E.4070205@oracle.com> <20100505194855.GE9429@oracle.com> <4BE1CDE9.8090600@oracle.com> User-Agent: Mutt/1.5.20 (2010-03-02) Status: RO Content-Length: 677 On Wed, May 05, 2010 at 12:58:33PM -0700, Garrett D'Amore wrote: > On 05/ 5/10 12:48 PM, Nicolas Williams wrote: > >What happens when a socket in FIN_WAIT2 is close()d, or a process exits > >and a socket is closed and ends up in FIN_WAIT2? If the FIN_WAIT2 timer > >is set to 2^31, what happens? > > > >Suppose the process is able to exit but the socket lingers. In that > >case will the lingering socket defeat resource controls? > > *This* is exactly the kind of issue I was talking about. Thanks for > making it clearer than I was able to do. Note: that's the only issue I can imagine. The other timers' being configurable obviously create no such problems. Nico -- From garrett.damore@oracle.com Wed May 5 13:07:35 2010 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o45K7Z72005975 for ; Wed, 5 May 2010 13:07:35 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o45K7Yx7004069 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 5 May 2010 14:07:34 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L1Y00D03QKMEB00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 05 May 2010 13:07:34 -0700 (PDT) Received: from sca-ea-mail-4.sun.com ([192.18.43.22]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L1Y008NIQKMIY10@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 05 May 2010 13:07:34 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o45K7XxK013304 for ; Wed, 05 May 2010 20:07:34 +0000 (GMT) Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o458KsHZ031168 for ; Wed, 05 May 2010 20:07:31 +0000 (GMT) Received: from abhmt009.oracle.com by acsmt354.oracle.com with ESMTP id 240229481273089959; Wed, 05 May 2010 13:05:59 -0700 Received: from [10.7.251.172] (/10.7.251.172) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 05 May 2010 13:05:58 -0700 Date: Wed, 05 May 2010 13:05:57 -0700 From: "Garrett D'Amore" Subject: Re: PSARC 2010/151 new socket options for TCP timers In-reply-to: <20100505200235.GF9429@oracle.com> To: Nicolas Williams Cc: Kacheong Poon , PSARC-ext Message-id: <4BE1CFA5.20906@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090202.4BE1D005.001C:SCFMA4539814,ss=1,fgs=0 References: <4BE19FDD.90009@oracle.com> <4BE1B0F3.5050704@oracle.com> <4BE1B35E.4070205@oracle.com> <20100505194855.GE9429@oracle.com> <4BE1CDE9.8090600@oracle.com> <20100505200235.GF9429@oracle.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.7) Gecko/20100214 Lightning/1.0b1 Thunderbird/3.0.1 Status: RO Content-Length: 1033 On 05/ 5/10 01:02 PM, Nicolas Williams wrote: > On Wed, May 05, 2010 at 12:58:33PM -0700, Garrett D'Amore wrote: > >> On 05/ 5/10 12:48 PM, Nicolas Williams wrote: >> >>> What happens when a socket in FIN_WAIT2 is close()d, or a process exits >>> and a socket is closed and ends up in FIN_WAIT2? If the FIN_WAIT2 timer >>> is set to 2^31, what happens? >>> >>> Suppose the process is able to exit but the socket lingers. In that >>> case will the lingering socket defeat resource controls? >>> >> *This* is exactly the kind of issue I was talking about. Thanks for >> making it clearer than I was able to do. >> > Note: that's the only issue I can imagine. The other timers' being > configurable obviously create no such problems. > Ok, I confess that the plethora of TCP related timer values are not something I have good familiarity with -- my concern was that resources associated with a socket would outlive the handle by which they were accounted (the associated open file). - Garrett From Nicolas.Williams@oracle.com Wed May 5 13:12:09 2010 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o45KC9jq006014 for ; Wed, 5 May 2010 13:12:09 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o45KC8UE006908 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 5 May 2010 14:12:08 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L1Y00E15QS8NX00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 05 May 2010 13:12:08 -0700 (PDT) Received: from sca-ea-mail-3.sun.com ([192.18.43.21]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L1Y0084YQS8J020@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 05 May 2010 13:12:08 -0700 (PDT) Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o45KC7qO019157 for ; Wed, 05 May 2010 20:12:07 +0000 (GMT) Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o45JvUAs002929 for ; Wed, 05 May 2010 20:12:06 +0000 (GMT) Received: from abhmt009.oracle.com by acsmt355.oracle.com with ESMTP id 217381671273090325; Wed, 05 May 2010 13:12:05 -0700 Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 05 May 2010 13:12:04 -0700 Date: Wed, 05 May 2010 15:12:00 -0500 From: Nicolas Williams Subject: Re: PSARC 2010/151 new socket options for TCP timers In-reply-to: <4BE1CFA5.20906@oracle.com> To: "Garrett D'Amore" Cc: Kacheong Poon , PSARC-ext Message-id: <20100505201158.GG9429@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt354.oracle.com [141.146.40.154] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090206.4BE1D116.018E:SCFMA4539814,ss=1,fgs=0 References: <4BE19FDD.90009@oracle.com> <4BE1B0F3.5050704@oracle.com> <4BE1B35E.4070205@oracle.com> <20100505194855.GE9429@oracle.com> <4BE1CDE9.8090600@oracle.com> <20100505200235.GF9429@oracle.com> <4BE1CFA5.20906@oracle.com> User-Agent: Mutt/1.5.20 (2010-03-02) Status: RO Content-Length: 972 On Wed, May 05, 2010 at 01:05:57PM -0700, Garrett D'Amore wrote: > >>>What happens when a socket in FIN_WAIT2 is close()d, or a process exits > >>>and a socket is closed and ends up in FIN_WAIT2? If the FIN_WAIT2 timer > >>>is set to 2^31, what happens? > >> > >>making it clearer than I was able to do. > >Note: that's the only issue I can imagine. The other timers' being > >configurable obviously create no such problems. > > Ok, I confess that the plethora of TCP related timer values are not > something I have good familiarity with -- my concern was that > resources associated with a socket would outlive the handle by which > they were accounted (the associated open file). The FIN-WAIT-2 timer is the only one that could, because it's the only one that relates to lingering resources (or TCP connection states where a socket/pcb could remotely linger). It may be the case that the socket wouldn't linger without the process lingering, but I don't know that. From Nicolas.Williams@oracle.com Wed May 5 14:29:19 2010 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o45LTJgp007823 for ; Wed, 5 May 2010 14:29:19 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o45LTIog020859 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 5 May 2010 14:29:19 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L1Y00G09UCUX900@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 05 May 2010 15:29:18 -0600 (MDT) Received: from sca-ea-mail-3.sun.com ([192.18.43.21]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L1Y007VGUCTSXE0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 05 May 2010 15:29:17 -0600 (MDT) Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o45LTHUV015882 for ; Wed, 05 May 2010 21:29:17 +0000 (GMT) Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o459tnCt012216 for ; Wed, 05 May 2010 21:29:15 +0000 (GMT) Received: from abhmt015.oracle.com by acsmt354.oracle.com with ESMTP id 240455001273094876; Wed, 05 May 2010 14:27:56 -0700 Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 05 May 2010 14:27:55 -0700 Date: Wed, 05 May 2010 16:27:51 -0500 From: Nicolas Williams Subject: Re: PSARC 2010/151 new socket options for TCP timers In-reply-to: <20100505201158.GG9429@oracle.com> To: "Garrett D'Amore" Cc: Kacheong Poon , PSARC-ext Message-id: <20100505212750.GH9429@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt354.oracle.com [141.146.40.154] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090201.4BE1E32C.01B6:SCFMA4539814,ss=1,fgs=0 References: <4BE19FDD.90009@oracle.com> <4BE1B0F3.5050704@oracle.com> <4BE1B35E.4070205@oracle.com> <20100505194855.GE9429@oracle.com> <4BE1CDE9.8090600@oracle.com> <20100505200235.GF9429@oracle.com> <4BE1CFA5.20906@oracle.com> <20100505201158.GG9429@oracle.com> User-Agent: Mutt/1.5.20 (2010-03-02) Status: RO Content-Length: 2774 On Wed, May 05, 2010 at 03:12:00PM -0500, Nicolas Williams wrote: > On Wed, May 05, 2010 at 01:05:57PM -0700, Garrett D'Amore wrote: > > >>>What happens when a socket in FIN_WAIT2 is close()d, or a process exits > > >>>and a socket is closed and ends up in FIN_WAIT2? If the FIN_WAIT2 timer > > >>>is set to 2^31, what happens? > > >> > > >>making it clearer than I was able to do. > > >Note: that's the only issue I can imagine. The other timers' being > > >configurable obviously create no such problems. > > > > Ok, I confess that the plethora of TCP related timer values are not > > something I have good familiarity with -- my concern was that > > resources associated with a socket would outlive the handle by which > > they were accounted (the associated open file). > > The FIN-WAIT-2 timer is the only one that could, because it's the only > one that relates to lingering resources (or TCP connection states where > a socket/pcb could remotely linger). It may be the case that the socket > wouldn't linger without the process lingering, but I don't know that. A bit of reasearch indicates that this is a protential problem, at least on Linux land, and almost certainly on Solaris land as well. Linux has two tunables related to the FIN-WAIT-2 state: " tcp_fin_timeout [like the one proposed here -Nico] Time to hold socket in state FIN-WAIT-2, if it was closed by our side. Peer can be broken and never close its side, or even died unexpectedly. Default value is 60sec. Usual value used in 2.2 was 180 seconds, you may restore it, but remember that if your machine is even underloaded WEB server, you risk to overflow memory with kilotons of dead sockets, FIN-WAIT-2 sockets are less dangerous than FIN-WAIT-1, because they eat maximum 1.5K of memory, but they tend to live longer. Cf. tcp_max_orphans. " and " tcp_max_orphans [max number of sockets lingering in FIN-WAIT-* -Nico] Maximal number of TCP sockets not attached to any user file handle, held by system. If this number is exceeded orphaned connections are reset immediately and warning is printed. This limit exists only to prevent simple DoS attacks, you _must_ not rely on this or lower the limit artificially, but rather increase it (probably, after increasing installed memory), if network conditions require more than default value, and tune network services to linger and kill such states more aggressively. Let me remind you again: each orphan eats up to 64K of unswappable memory. " Sounds like we might want an equivalent to tcp_max_orphans... Also, allowing the FIN-WAIT-2 timer to get set to ridiculously large numbers of seconds strikes me as a bad idea, at least without a tcp_max_orphans. Nico -- From ka-cheong.poon@oracle.com Thu May 6 00:59:58 2010 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o467xwiX007202 for ; Thu, 6 May 2010 00:59:58 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o467xvxF002505 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 6 May 2010 02:59:58 -0500 (CDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L1Z0010VNJXUF00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 06 May 2010 00:59:57 -0700 (PDT) Received: from sca-ea-mail-1.sun.com ([192.18.43.24]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L1Z00196NJXPE00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 06 May 2010 00:59:57 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o467xut3015059 for ; Thu, 06 May 2010 07:59:57 +0000 (GMT) Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o467xttq007992 for ; Thu, 06 May 2010 07:59:55 +0000 (GMT) Received: from abhmt021.oracle.com by acsmt355.oracle.com with ESMTP id 241744391273132742; Thu, 06 May 2010 00:59:02 -0700 Received: from [10.7.251.223] (/10.7.251.223) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 06 May 2010 00:59:02 -0700 Date: Thu, 06 May 2010 15:58:58 +0800 From: Kacheong Poon Subject: Re: PSARC 2010/151 new socket options for TCP timers In-reply-to: <4BE1C5AB.2040603@oracle.com> To: Andrew Gabriel Cc: PSARC-ext Message-id: <4BE276C2.4020902@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt353.oracle.com [141.146.40.153] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090202.4BE276FC.0137:SCFMA4539814,ss=1,fgs=0 References: <4BE1BD1C.5080407@oracle.com> <4BE1C5AB.2040603@oracle.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.9) Gecko/20100318 Lightning/1.0b1 Thunderbird/3.0.4 Status: RO Content-Length: 2076 On 05/ 6/10 03:23 AM, Andrew Gabriel wrote: >> TCP_CONN_ABORT_THRESHOLD, TCP_ABORT_THRESHOLD >> --------------------------------------------- > I can see two cases where I would use these: > 1) Where my application wants a short connection establishment timeout > or a quick connection failure detection, i.e. shorter in either case > than the default TCP values, because my application wants to take some > other action in these cases before TCP is likely to have timed out the > operation. > 2) Where my application requires a permanent TCP connection, and I'm not > interested in knowing about timeouts - just keep trying. > > Unfortunately, 2) is not quite handled in this case, as there are no > values which are interpreted as infinity (i.e. no timeout), so I still > have to handle the case where connect(), read(), write(), etc return > timeouts, even if they do it less often. Having an infinity value might > allow me to simplify my application coding (even though I still have to > handle the possibility of a RST). Is the value 'zero' free to be > interpreted as infinity? The value 0 is free and indeed can be used to mean infinity. But is (2) really useful in practice? Having that only eliminates a subset of errors. And the handling of this subset of errors is probably similar to the handling of its complement. If folks really think that it is a useful, I can add this meaning assuming that there is no objection. >> TCP_LINGER2 >> ----------- >> >> [...] The default value of tcp_fin_wait_2_flush_interval is also >> changed to 60s. > > Just wondering if that's safe/acceptable for a patch binding? Could you please elaborate your concern? >> Diff of tcp(7P) > > I would add something to say that changing these new parameters requires > detailed knowledge of the application and the TCP protocol, and normally > there is no need to change them. We're giving the programmer some rope, > but it's worth warning him not to make a noose for himself. OK, I can add those words to the man page. -- K. Poon. ka-cheong.poon@oracle.com From ka-cheong.poon@oracle.com Thu May 6 01:04:38 2010 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o4684bXK007309 for ; Thu, 6 May 2010 01:04:38 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o4684alI047614 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 6 May 2010 02:04:37 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L1Z00N1DNRP0200@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 06 May 2010 01:04:37 -0700 (PDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L1Z00AQENROOH30@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 06 May 2010 01:04:37 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o4684aG3020943 for ; Thu, 06 May 2010 08:04:36 +0000 (GMT) Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o465hAlb019560 for ; Thu, 06 May 2010 08:04:35 +0000 (GMT) Received: from abhmt020.oracle.com by acsmt353.oracle.com with ESMTP id 241762241273132992; Thu, 06 May 2010 01:03:12 -0700 Received: from [10.7.251.223] (/10.7.251.223) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 06 May 2010 01:03:11 -0700 Date: Thu, 06 May 2010 16:03:09 +0800 From: Kacheong Poon Subject: Re: PSARC 2010/151 new socket options for TCP timers In-reply-to: <4BE1C71C.10009@oracle.com> To: "Garrett D'Amore" Cc: PSARC-ext Message-id: <4BE277BD.3080901@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090203.4BE27814.0065:SCFMA4539814,ss=1,fgs=0 References: <4BE19FDD.90009@oracle.com> <4BE1B0F3.5050704@oracle.com> <4BE1B35E.4070205@oracle.com> <4BE1B9A7.8030503@oracle.com> <4BE1C71C.10009@oracle.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.9) Gecko/20100318 Lightning/1.0b1 Thunderbird/3.0.4 Status: RO Content-Length: 1691 On 05/ 6/10 03:29 AM, Garrett D'Amore wrote: > My point was that these timers could affect the resources that are > consumed on the system *after* a socket is closed. Ultimately, that > means that any limits already in existence that limit open files won't > necessarily apply to these timers. > > While these timers don't necessarily *create* a *new* weakness, my > concern is that increasing the value of the timers may make it *easier* > for a malicious program to create a DoS situation. I think the options neither make it easier nor harder. One can do the same type of resource exhaustion attack right now. And the concern is really about a generic resource control (*) in the network stack, which is outside the scope of this case. As I mentioned in a previous mail, if folks are not comfortable with the value ranges, I can certainly change that. For example, TCP_ABORT_THRESHOLD (tcp_ip_abort_interval) can be limited to 2 hours (oops, this means that inter-planetary TCP communication won't work in Solaris anymore...) > Its not new.. its a situation where the DoS I described above can be > *easier*. I'm not sure just how *much* easier it is, but that's the > nature of the question I'm asking. "Difficulty" is certainly subjective. Does having 2 fewer lines of code mean "easier"? How about 20 lines? I think the question should be practical or impractical (assuming it is always possible). IMHO, the new options do not introduce new attack in practice, nor make an impractical attack practical. (*) Note that the early abort timeout when the system is short in memory is not affected by these options. -- K. Poon. ka-cheong.poon@oracle.com From ka-cheong.poon@oracle.com Thu May 6 01:06:41 2010 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o4686e1r007318 for ; Thu, 6 May 2010 01:06:41 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o4686c5v048761 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 6 May 2010 02:06:40 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L1Z0020JNV36P00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 06 May 2010 01:06:39 -0700 (PDT) Received: from sca-ea-mail-3.sun.com ([192.18.43.21]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L1Z001SRNV3PB00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 06 May 2010 01:06:39 -0700 (PDT) Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o4686coL017339 for ; Thu, 06 May 2010 08:06:39 +0000 (GMT) Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4686b6G004500 for ; Thu, 06 May 2010 08:06:37 +0000 (GMT) Received: from abhmt002.oracle.com by acsmt355.oracle.com with ESMTP id 241777481273133195; Thu, 06 May 2010 01:06:35 -0700 Received: from [10.7.251.223] (/10.7.251.223) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 06 May 2010 01:06:34 -0700 Date: Thu, 06 May 2010 16:06:31 +0800 From: Kacheong Poon Subject: Re: PSARC 2010/151 new socket options for TCP timers In-reply-to: <20100505194855.GE9429@oracle.com> To: Nicolas Williams Cc: "Garrett D'Amore" , PSARC-ext Message-id: <4BE27887.9000706@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090205.4BE2788E.00AE:SCFMA4539814,ss=1,fgs=0 References: <4BE19FDD.90009@oracle.com> <4BE1B0F3.5050704@oracle.com> <4BE1B35E.4070205@oracle.com> <20100505194855.GE9429@oracle.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.9) Gecko/20100318 Lightning/1.0b1 Thunderbird/3.0.4 Status: RO Content-Length: 1522 On 05/ 6/10 03:48 AM, Nicolas Williams wrote: > What happens when a socket in FIN_WAIT2 is close()d, or a process exits > and a socket is closed and ends up in FIN_WAIT2? If the FIN_WAIT2 timer > is set to 2^31, what happens? Nothing special :-) The connection can finish the close sequence and the tcp_t transitions to TIME-WAIT state. > Suppose the process is able to exit but the socket lingers. In that > case will the lingering socket defeat resource controls? I guess your concern is that somehow the peer goes away at the *right* time and TCP stays in the FIN-WAIT-2 state for the extended period of time. I further assume that you are using this as an example of a new attack. And the goal is to create as many lingering tcp_ts in the system as possible. For this attack to be successful, there must be a peer co-operating. And if you have a helpful peer, you can achieve the same thing right now without the help of the new options. In fact, you can do that more effectively (consuming more memory than the proposed attack) without the use of the new option. Although the sequence to do the above is simple, I will let the readers think about how to do that. I will send a mail privately to explain the steps. As I mentioned before, if folks are not comfortable with the value ranges, I can change that. In this case, the max can be changed to a similar value I mentioned previously for TCP_ABORT_THRESHOLD, which is 2 hours. Does this help? -- K. Poon. ka-cheong.poon@oracle.com From kacheong.poon@Sun.COM Thu May 6 01:36:21 2010 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o468aLJn007597 for ; Thu, 6 May 2010 01:36:21 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o468aKY8002872 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 6 May 2010 02:36:20 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L1Z00731P8KC200@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 06 May 2010 01:36:20 -0700 (PDT) Received: from jurassic.Eng.Sun.COM ([129.146.17.63]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L1Z00A9DP8JOF40@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 06 May 2010 01:36:19 -0700 (PDT) Received: from [10.7.251.223] (punchin-kcpoon.SFBay.Sun.COM [10.7.251.223]) by jurassic.Eng.Sun.COM (8.14.4+Sun/8.14.4) with ESMTP id o468aHsX427847 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 06 May 2010 01:36:18 -0700 (PDT) Date: Thu, 06 May 2010 16:36:16 +0800 From: Kacheong Poon Subject: Re: PSARC 2010/151 new socket options for TCP timers In-reply-to: <20100505212750.GH9429@oracle.com> To: Nicolas Williams Cc: "Garrett D'Amore" , PSARC-ext Message-id: <4BE27F80.1080204@sun.com> Organization: Sun Microsystems, Inc. MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4BE19FDD.90009@oracle.com> <4BE1B0F3.5050704@oracle.com> <4BE1B35E.4070205@oracle.com> <20100505194855.GE9429@oracle.com> <4BE1CDE9.8090600@oracle.com> <20100505200235.GF9429@oracle.com> <4BE1CFA5.20906@oracle.com> <20100505201158.GG9429@oracle.com> <20100505212750.GH9429@oracle.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.9) Gecko/20100318 Lightning/1.0b1 Thunderbird/3.0.4 Status: RO Content-Length: 514 On 05/ 6/10 05:27 AM, Nicolas Williams wrote: > Sounds like we might want an equivalent to tcp_max_orphans... Also, > allowing the FIN-WAIT-2 timer to get set to ridiculously large numbers > of seconds strikes me as a bad idea, at least without a tcp_max_orphans. I guess how to do resource control in the network stack is out of scope for this case. As I mentioned in an earlier reply, if folks are not comfortable with the value ranges, I can change that. -- K. Poon. kacheong.poon@sun.com From Nicolas.Williams@oracle.com Thu May 6 08:29:18 2010 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o46FTIk1012705 for ; Thu, 6 May 2010 08:29:18 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o46FSwew013228; Thu, 6 May 2010 08:29:18 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L2000L0Z8CLJD00@nwk-avmta-2.sfbay.sun.com>; Thu, 06 May 2010 08:29:10 -0700 (PDT) Received: from sca-ea-mail-1.sun.com ([192.18.43.24]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L2000D968CKXI90@nwk-avmta-2.sfbay.sun.com>; Thu, 06 May 2010 08:29:08 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o46FT8Pw000047; Thu, 06 May 2010 15:29:08 +0000 (GMT) Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o46DCvbK026337; Thu, 06 May 2010 15:29:07 +0000 (GMT) Received: from abhmt015.oracle.com by acsmt353.oracle.com with ESMTP id 243113511273159716; Thu, 06 May 2010 08:28:36 -0700 Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 06 May 2010 08:28:35 -0700 Date: Thu, 06 May 2010 10:28:31 -0500 From: Nicolas Williams Subject: Re: PSARC 2010/151 new socket options for TCP timers In-reply-to: <4BE27F80.1080204@sun.com> To: Kacheong Poon Cc: "Garrett D'Amore" , PSARC-ext Message-id: <20100506152830.GO9429@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090208.4BE2E043.0192:SCFMA4539814,ss=1,fgs=0 References: <4BE19FDD.90009@oracle.com> <4BE1B0F3.5050704@oracle.com> <4BE1B35E.4070205@oracle.com> <20100505194855.GE9429@oracle.com> <4BE1CDE9.8090600@oracle.com> <20100505200235.GF9429@oracle.com> <4BE1CFA5.20906@oracle.com> <20100505201158.GG9429@oracle.com> <20100505212750.GH9429@oracle.com> <4BE27F80.1080204@sun.com> User-Agent: Mutt/1.5.20 (2010-03-02) Status: RO Content-Length: 467 On Thu, May 06, 2010 at 04:36:16PM +0800, Kacheong Poon wrote: > On 05/ 6/10 05:27 AM, Nicolas Williams wrote: > >Sounds like we might want an equivalent to tcp_max_orphans... Also, > >allowing the FIN-WAIT-2 timer to get set to ridiculously large numbers > >of seconds strikes me as a bad idea, at least without a tcp_max_orphans. > > I guess how to do resource control in the network stack is > out of scope for this case. As I mentioned in an earlier I agree. From Nicolas.Williams@oracle.com Thu May 6 08:33:05 2010 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o46FX5ev012971 for ; Thu, 6 May 2010 08:33:05 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o46FX23U016062 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 6 May 2010 08:33:04 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L2000K0D8J32R00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 06 May 2010 09:33:03 -0600 (MDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L20004BE8J28CB0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 06 May 2010 09:33:02 -0600 (MDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o46FX2ac022149 for ; Thu, 06 May 2010 15:33:02 +0000 (GMT) Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o468HwGH032501 for ; Thu, 06 May 2010 15:33:00 +0000 (GMT) Received: from abhmt004.oracle.com by acsmt353.oracle.com with ESMTP id 219900441273159975; Thu, 06 May 2010 08:32:55 -0700 Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 06 May 2010 08:32:54 -0700 Date: Thu, 06 May 2010 10:32:49 -0500 From: Nicolas Williams Subject: Re: PSARC 2010/151 new socket options for TCP timers In-reply-to: <4BE27887.9000706@oracle.com> To: Kacheong Poon Cc: "Garrett D'Amore" , PSARC-ext Message-id: <20100506153249.GP9429@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt354.oracle.com [141.146.40.154] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090205.4BE2E12E.0070:SCFMA4539814,ss=1,fgs=0 References: <4BE19FDD.90009@oracle.com> <4BE1B0F3.5050704@oracle.com> <4BE1B35E.4070205@oracle.com> <20100505194855.GE9429@oracle.com> <4BE27887.9000706@oracle.com> User-Agent: Mutt/1.5.20 (2010-03-02) Status: RO Content-Length: 1070 On Thu, May 06, 2010 at 04:06:31PM +0800, Kacheong Poon wrote: > >Suppose the process is able to exit but the socket lingers. In that > >case will the lingering socket defeat resource controls? > > I guess your concern is that somehow the peer goes away at the > *right* time and TCP stays in the FIN-WAIT-2 state for the > extended period of time. I further assume that you are using > this as an example of a new attack. And the goal is to create > as many lingering tcp_ts in the system as possible. For this > attack to be successful, there must be a peer co-operating. And The peer need only accept connections though, right? > [...] > As I mentioned before, if folks are not comfortable with the > value ranges, I can change that. In this case, the max can be > changed to a similar value I mentioned previously for > TCP_ABORT_THRESHOLD, which is 2 hours. Does this help? It's not the ABORT threshold that I'm worried about, but the TCP_LINGER2 timer. I recommend that the maximum for that be not more than some smallish value such as 60s. Nico -- From garrett.damore@oracle.com Thu May 6 08:46:14 2010 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o46FkELN013891 for ; Thu, 6 May 2010 08:46:14 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o46FkAHs018818 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 6 May 2010 10:46:13 -0500 (CDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L2000M199516J00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 06 May 2010 08:46:13 -0700 (PDT) Received: from sca-ea-mail-4.sun.com ([192.18.43.22]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L2000DUM950XGA0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 06 May 2010 08:46:12 -0700 (PDT) Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o46FkC0d004197 for ; Thu, 06 May 2010 15:46:12 +0000 (GMT) Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o46FkAlm000526 for ; Thu, 06 May 2010 15:46:11 +0000 (GMT) Received: from abhmt004.oracle.com by acsmt353.oracle.com with ESMTP id 243181401273160770; Thu, 06 May 2010 08:46:10 -0700 Received: from [10.7.251.172] (/10.7.251.172) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 06 May 2010 08:46:08 -0700 Date: Thu, 06 May 2010 08:46:06 -0700 From: "Garrett D'Amore" Subject: Re: PSARC 2010/151 new socket options for TCP timers In-reply-to: <20100506153249.GP9429@oracle.com> To: Nicolas Williams Cc: Kacheong Poon , PSARC-ext Message-id: <4BE2E43E.6010503@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt353.oracle.com [141.146.40.153] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090202.4BE2E443.00FF:SCFMA4539814,ss=1,fgs=0 References: <4BE19FDD.90009@oracle.com> <4BE1B0F3.5050704@oracle.com> <4BE1B35E.4070205@oracle.com> <20100505194855.GE9429@oracle.com> <4BE27887.9000706@oracle.com> <20100506153249.GP9429@oracle.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.7) Gecko/20100214 Lightning/1.0b1 Thunderbird/3.0.1 Status: RO Content-Length: 1772 On 05/ 6/10 08:32 AM, Nicolas Williams wrote: > On Thu, May 06, 2010 at 04:06:31PM +0800, Kacheong Poon wrote: > >>> Suppose the process is able to exit but the socket lingers. In that >>> case will the lingering socket defeat resource controls? >>> >> I guess your concern is that somehow the peer goes away at the >> *right* time and TCP stays in the FIN-WAIT-2 state for the >> extended period of time. I further assume that you are using >> this as an example of a new attack. And the goal is to create >> as many lingering tcp_ts in the system as possible. For this >> attack to be successful, there must be a peer co-operating. And >> > The peer need only accept connections though, right? > > >> [...] >> > >> As I mentioned before, if folks are not comfortable with the >> value ranges, I can change that. In this case, the max can be >> changed to a similar value I mentioned previously for >> TCP_ABORT_THRESHOLD, which is 2 hours. Does this help? >> > It's not the ABORT threshold that I'm worried about, but the TCP_LINGER2 > timer. I recommend that the maximum for that be not more than some > smallish value such as 60s. > I agree. Wouldn't it also be possible to arrange for a "helpful" peer by using a second cooperating process on the same system? I'm approaching the mind, given the earlier discussion, that we need to have a project to examine this problem, and that it may be out of scope for this project. Nevertheless, as we lack a mechanism for ARC to express anything other than via opinion, perhaps derailing (and a subsequent vote to approve) just to facilitate an opinion that suggests that this problem be examined might be in order. I'm not dead set on it, though. - Garrett From Nicolas.Williams@oracle.com Thu May 6 08:50:11 2010 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o46FoBGD013921 for ; Thu, 6 May 2010 08:50:11 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o46Fo8QE024716 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 6 May 2010 08:50:11 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L2000L0N9BNEY00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 06 May 2010 09:50:11 -0600 (MDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L20004OV9BM8BC0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 06 May 2010 09:50:10 -0600 (MDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o46Fo9Ih000688 for ; Thu, 06 May 2010 15:50:10 +0000 (GMT) Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o46DdCsd016825 for ; Thu, 06 May 2010 15:50:09 +0000 (GMT) Received: from abhmt009.oracle.com by acsmt353.oracle.com with ESMTP id 243198431273160999; Thu, 06 May 2010 08:49:59 -0700 Received: from Sun.COM (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 06 May 2010 08:49:58 -0700 Date: Thu, 06 May 2010 10:49:52 -0500 From: Nicolas Williams Subject: Re: PSARC 2010/151 new socket options for TCP timers In-reply-to: <20100506153249.GP9429@oracle.com> To: Kacheong Poon Cc: "Garrett D'Amore" , PSARC-ext Message-id: <20100506154952.GR11130@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt353.oracle.com [141.146.40.153] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090203.4BE2E531.0184:SCFMA4539814,ss=1,fgs=0 References: <4BE19FDD.90009@oracle.com> <4BE1B0F3.5050704@oracle.com> <4BE1B35E.4070205@oracle.com> <20100505194855.GE9429@oracle.com> <4BE27887.9000706@oracle.com> <20100506153249.GP9429@oracle.com> User-Agent: Mutt/1.5.20 (2010-03-02) Status: RO Content-Length: 982 On Thu, May 06, 2010 at 10:32:49AM -0500, Nicolas Williams wrote: > On Thu, May 06, 2010 at 04:06:31PM +0800, Kacheong Poon wrote: > > >Suppose the process is able to exit but the socket lingers. In that > > >case will the lingering socket defeat resource controls? > > > > I guess your concern is that somehow the peer goes away at the > > *right* time and TCP stays in the FIN-WAIT-2 state for the > > extended period of time. I further assume that you are using > > this as an example of a new attack. And the goal is to create > > as many lingering tcp_ts in the system as possible. For this > > attack to be successful, there must be a peer co-operating. And > > The peer need only accept connections though, right? Ah, no, excuse the brain fart. The cooperating peer would have to accept connections _and_ set the TCP_LINGER2 timer very high. Therefore there's no problem whatsoever. Please excuse this long detour. There's nothing wrong with your case, Nico -- From ka-cheong.poon@oracle.com Thu May 6 09:21:41 2010 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o46GLe6N014979 for ; Thu, 6 May 2010 09:21:40 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o46GLeuD011681 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 6 May 2010 09:21:40 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L200000NAS4RU00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 06 May 2010 10:21:40 -0600 (MDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L200048QAS38VE0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 06 May 2010 10:21:40 -0600 (MDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o46GLdTj029748 for ; Thu, 06 May 2010 16:21:39 +0000 (GMT) Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o465hVIu020287 for ; Thu, 06 May 2010 16:21:38 +0000 (GMT) Received: from abhmt003.oracle.com by acsmt354.oracle.com with ESMTP id 220055061273162831; Thu, 06 May 2010 09:20:31 -0700 Received: from [10.7.251.223] (/10.7.251.223) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 06 May 2010 09:20:31 -0700 Date: Fri, 07 May 2010 00:20:28 +0800 From: Kacheong Poon Subject: Re: PSARC 2010/151 new socket options for TCP timers In-reply-to: <20100506153249.GP9429@oracle.com> To: Nicolas Williams Cc: "Garrett D'Amore" , PSARC-ext Message-id: <4BE2EC4C.5030107@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt354.oracle.com [141.146.40.154] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090207.4BE2EC93.0098:SCFMA4539814,ss=1,fgs=0 References: <4BE19FDD.90009@oracle.com> <4BE1B0F3.5050704@oracle.com> <4BE1B35E.4070205@oracle.com> <20100505194855.GE9429@oracle.com> <4BE27887.9000706@oracle.com> <20100506153249.GP9429@oracle.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.9) Gecko/20100318 Lightning/1.0b1 Thunderbird/3.0.4 Status: RO Content-Length: 1348 On 05/ 6/10 11:32 PM, Nicolas Williams wrote: > On Thu, May 06, 2010 at 04:06:31PM +0800, Kacheong Poon wrote: >>> Suppose the process is able to exit but the socket lingers. In that >>> case will the lingering socket defeat resource controls? >> >> I guess your concern is that somehow the peer goes away at the >> *right* time and TCP stays in the FIN-WAIT-2 state for the >> extended period of time. I further assume that you are using >> this as an example of a new attack. And the goal is to create >> as many lingering tcp_ts in the system as possible. For this >> attack to be successful, there must be a peer co-operating. And > > The peer need only accept connections though, right? The peer probably needs to be a special program which knows when to stop at the close sequence to force the Solaris side to be stuck in FIN-WAIT-2 state. A normal TCP app cannot do that. > It's not the ABORT threshold that I'm worried about, but the TCP_LINGER2 > timer. I recommend that the maximum for that be not more than some > smallish value such as 60s. How about the following? The option value must be smaller than the TCP private parameter tcp_fin_wait_2_flush_interval. And this parameter can be changed by the admin to any value less than 2 hours (right now the max is 2^32ms). -- K. Poon. ka-cheong.poon@oracle.com From ka-cheong.poon@oracle.com Thu May 6 09:28:25 2010 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o46GSPhj015027 for ; Thu, 6 May 2010 09:28:25 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o46GSMg2035375 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 6 May 2010 10:28:25 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L200012RB3C4Q00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 06 May 2010 09:28:24 -0700 (PDT) Received: from sca-ea-mail-1.sun.com ([192.18.43.24]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L2000DZ1B3BXLD0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 06 May 2010 09:28:23 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o46GSNjH001159 for ; Thu, 06 May 2010 16:28:23 +0000 (GMT) Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o46D3tct024536 for ; Thu, 06 May 2010 16:28:22 +0000 (GMT) Received: from abhmt007.oracle.com by acsmt354.oracle.com with ESMTP id 220075201273163227; Thu, 06 May 2010 09:27:07 -0700 Received: from [10.7.251.223] (/10.7.251.223) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 06 May 2010 09:27:06 -0700 Date: Fri, 07 May 2010 00:27:03 +0800 From: Kacheong Poon Subject: Re: PSARC 2010/151 new socket options for TCP timers In-reply-to: <4BE2E43E.6010503@oracle.com> To: "Garrett D'Amore" Cc: Nicolas Williams , PSARC-ext Message-id: <4BE2EDD7.1040105@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt353.oracle.com [141.146.40.153] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090201.4BE2EE26.010C:SCFMA4539814,ss=1,fgs=0 References: <4BE19FDD.90009@oracle.com> <4BE1B0F3.5050704@oracle.com> <4BE1B35E.4070205@oracle.com> <20100505194855.GE9429@oracle.com> <4BE27887.9000706@oracle.com> <20100506153249.GP9429@oracle.com> <4BE2E43E.6010503@oracle.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.9) Gecko/20100318 Lightning/1.0b1 Thunderbird/3.0.4 Status: RO Content-Length: 2140 On 05/ 6/10 11:46 PM, Garrett D'Amore wrote: > On 05/ 6/10 08:32 AM, Nicolas Williams wrote: >> On Thu, May 06, 2010 at 04:06:31PM +0800, Kacheong Poon wrote: >>>> Suppose the process is able to exit but the socket lingers. In that >>>> case will the lingering socket defeat resource controls? >>> I guess your concern is that somehow the peer goes away at the >>> *right* time and TCP stays in the FIN-WAIT-2 state for the >>> extended period of time. I further assume that you are using >>> this as an example of a new attack. And the goal is to create >>> as many lingering tcp_ts in the system as possible. For this >>> attack to be successful, there must be a peer co-operating. And >> The peer need only accept connections though, right? >> >>> [...] >>> As I mentioned before, if folks are not comfortable with the >>> value ranges, I can change that. In this case, the max can be >>> changed to a similar value I mentioned previously for >>> TCP_ABORT_THRESHOLD, which is 2 hours. Does this help? >> It's not the ABORT threshold that I'm worried about, but the TCP_LINGER2 >> timer. I recommend that the maximum for that be not more than some >> smallish value such as 60s. > > I agree. Wouldn't it also be possible to arrange for a "helpful" peer by > using a second cooperating process on the same system? The peer needs to be a special program, such as a raw socket program which sends/receives TCP packets directly. In Solaris, only privileged apps can do that. But if the app is privileged, it can do other more "interesting" things directly than this. > I'm approaching the mind, given the earlier discussion, that we need to > have a project to examine this problem, and that it may be out of scope > for this project. Nevertheless, as we lack a mechanism for ARC to > express anything other than via opinion, perhaps derailing (and a > subsequent vote to approve) just to facilitate an opinion that suggests > that this problem be examined might be in order. Which problem are you referring to here? AFAICT, there is no new problem mentioned in this email thread. -- K. Poon. ka-cheong.poon@oracle.com From kacheong.poon@sun.com Mon May 10 12:45:57 2010 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o468aLJn007597 for ; Thu, 6 May 2010 01:36:21 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o468aKY8002872 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 6 May 2010 02:36:20 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L1Z00731P8KC200@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 06 May 2010 01:36:20 -0700 (PDT) Received: from jurassic.Eng.Sun.COM ([129.146.17.63]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L1Z00A9DP8JOF40@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 06 May 2010 01:36:19 -0700 (PDT) Received: from [10.7.251.223] (punchin-kcpoon.SFBay.Sun.COM [10.7.251.223]) by jurassic.Eng.Sun.COM (8.14.4+Sun/8.14.4) with ESMTP id o468aHsX427847 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 06 May 2010 01:36:18 -0700 (PDT) Date: Thu, 06 May 2010 16:36:16 +0800 From: Kacheong Poon Subject: Re: PSARC 2010/151 new socket options for TCP timers In-reply-to: <20100505212750.GH9429@oracle.com> To: Nicolas Williams Cc: "Garrett D'Amore" , PSARC-ext Message-id: <4BE27F80.1080204@sun.com> Organization: Sun Microsystems, Inc. MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4BE19FDD.90009@oracle.com> <4BE1B0F3.5050704@oracle.com> <4BE1B35E.4070205@oracle.com> <20100505194855.GE9429@oracle.com> <4BE1CDE9.8090600@oracle.com> <20100505200235.GF9429@oracle.com> <4BE1CFA5.20906@oracle.com> <20100505201158.GG9429@oracle.com> <20100505212750.GH9429@oracle.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.9) Gecko/20100318 Lightning/1.0b1 Thunderbird/3.0.4 Status: RO Content-Length: 514 On 05/ 6/10 05:27 AM, Nicolas Williams wrote: > Sounds like we might want an equivalent to tcp_max_orphans... Also, > allowing the FIN-WAIT-2 timer to get set to ridiculously large numbers > of seconds strikes me as a bad idea, at least without a tcp_max_orphans. I guess how to do resource control in the network stack is out of scope for this case. As I mentioned in an earlier reply, if folks are not comfortable with the value ranges, I can change that. -- K. Poon. kacheong.poon@sun.com From Nicolas.Williams@Oracle.COM Mon May 10 12:49:33 2010 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o46FTIk1012705 for ; Thu, 6 May 2010 08:29:18 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o46FSwew013228; Thu, 6 May 2010 08:29:18 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L2000L0Z8CLJD00@nwk-avmta-2.sfbay.sun.com>; Thu, 06 May 2010 08:29:10 -0700 (PDT) Received: from sca-ea-mail-1.sun.com ([192.18.43.24]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L2000D968CKXI90@nwk-avmta-2.sfbay.sun.com>; Thu, 06 May 2010 08:29:08 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o46FT8Pw000047; Thu, 06 May 2010 15:29:08 +0000 (GMT) Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o46DCvbK026337; Thu, 06 May 2010 15:29:07 +0000 (GMT) Received: from abhmt015.oracle.com by acsmt353.oracle.com with ESMTP id 243113511273159716; Thu, 06 May 2010 08:28:36 -0700 Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 06 May 2010 08:28:35 -0700 Date: Thu, 06 May 2010 10:28:31 -0500 From: Nicolas Williams Subject: Re: PSARC 2010/151 new socket options for TCP timers In-reply-to: <4BE27F80.1080204@sun.com> To: Kacheong Poon Cc: "Garrett D'Amore" , PSARC-ext Message-id: <20100506152830.GO9429@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090208.4BE2E043.0192:SCFMA4539814,ss=1,fgs=0 References: <4BE19FDD.90009@oracle.com> <4BE1B0F3.5050704@oracle.com> <4BE1B35E.4070205@oracle.com> <20100505194855.GE9429@oracle.com> <4BE1CDE9.8090600@oracle.com> <20100505200235.GF9429@oracle.com> <4BE1CFA5.20906@oracle.com> <20100505201158.GG9429@oracle.com> <20100505212750.GH9429@oracle.com> <4BE27F80.1080204@sun.com> User-Agent: Mutt/1.5.20 (2010-03-02) Status: RO Content-Length: 467 On Thu, May 06, 2010 at 04:36:16PM +0800, Kacheong Poon wrote: > On 05/ 6/10 05:27 AM, Nicolas Williams wrote: > >Sounds like we might want an equivalent to tcp_max_orphans... Also, > >allowing the FIN-WAIT-2 timer to get set to ridiculously large numbers > >of seconds strikes me as a bad idea, at least without a tcp_max_orphans. > > I guess how to do resource control in the network stack is > out of scope for this case. As I mentioned in an earlier I agree. From Nicolas.Williams@oracle.com Mon May 10 13:02:13 2010 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o46FoBGD013921 for ; Thu, 6 May 2010 08:50:11 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o46Fo8QE024716 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 6 May 2010 08:50:11 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L2000L0N9BNEY00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 06 May 2010 09:50:11 -0600 (MDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L20004OV9BM8BC0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 06 May 2010 09:50:10 -0600 (MDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o46Fo9Ih000688 for ; Thu, 06 May 2010 15:50:10 +0000 (GMT) Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o46DdCsd016825 for ; Thu, 06 May 2010 15:50:09 +0000 (GMT) Received: from abhmt009.oracle.com by acsmt353.oracle.com with ESMTP id 243198431273160999; Thu, 06 May 2010 08:49:59 -0700 Received: from Sun.COM (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 06 May 2010 08:49:58 -0700 Date: Thu, 06 May 2010 10:49:52 -0500 From: Nicolas Williams Subject: Re: PSARC 2010/151 new socket options for TCP timers In-reply-to: <20100506153249.GP9429@oracle.com> To: Kacheong Poon Cc: "Garrett D'Amore" , PSARC-ext Message-id: <20100506154952.GR11130@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt353.oracle.com [141.146.40.153] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090203.4BE2E531.0184:SCFMA4539814,ss=1,fgs=0 References: <4BE19FDD.90009@oracle.com> <4BE1B0F3.5050704@oracle.com> <4BE1B35E.4070205@oracle.com> <20100505194855.GE9429@oracle.com> <4BE27887.9000706@oracle.com> <20100506153249.GP9429@oracle.com> User-Agent: Mutt/1.5.20 (2010-03-02) Status: RO Content-Length: 982 On Thu, May 06, 2010 at 10:32:49AM -0500, Nicolas Williams wrote: > On Thu, May 06, 2010 at 04:06:31PM +0800, Kacheong Poon wrote: > > >Suppose the process is able to exit but the socket lingers. In that > > >case will the lingering socket defeat resource controls? > > > > I guess your concern is that somehow the peer goes away at the > > *right* time and TCP stays in the FIN-WAIT-2 state for the > > extended period of time. I further assume that you are using > > this as an example of a new attack. And the goal is to create > > as many lingering tcp_ts in the system as possible. For this > > attack to be successful, there must be a peer co-operating. And > > The peer need only accept connections though, right? Ah, no, excuse the brain fart. The cooperating peer would have to accept connections _and_ set the TCP_LINGER2 timer very high. Therefore there's no problem whatsoever. Please excuse this long detour. There's nothing wrong with your case, Nico -- From Nicolas.Williams@oracle.com Mon May 10 13:05:45 2010 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o46FX5ev012971 for ; Thu, 6 May 2010 08:33:05 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o46FX23U016062 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 6 May 2010 08:33:04 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L2000K0D8J32R00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 06 May 2010 09:33:03 -0600 (MDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L20004BE8J28CB0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 06 May 2010 09:33:02 -0600 (MDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o46FX2ac022149 for ; Thu, 06 May 2010 15:33:02 +0000 (GMT) Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o468HwGH032501 for ; Thu, 06 May 2010 15:33:00 +0000 (GMT) Received: from abhmt004.oracle.com by acsmt353.oracle.com with ESMTP id 219900441273159975; Thu, 06 May 2010 08:32:55 -0700 Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 06 May 2010 08:32:54 -0700 Date: Thu, 06 May 2010 10:32:49 -0500 From: Nicolas Williams Subject: Re: PSARC 2010/151 new socket options for TCP timers In-reply-to: <4BE27887.9000706@oracle.com> To: Kacheong Poon Cc: "Garrett D'Amore" , PSARC-ext Message-id: <20100506153249.GP9429@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt354.oracle.com [141.146.40.154] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090205.4BE2E12E.0070:SCFMA4539814,ss=1,fgs=0 References: <4BE19FDD.90009@oracle.com> <4BE1B0F3.5050704@oracle.com> <4BE1B35E.4070205@oracle.com> <20100505194855.GE9429@oracle.com> <4BE27887.9000706@oracle.com> User-Agent: Mutt/1.5.20 (2010-03-02) Status: RO Content-Length: 1070 On Thu, May 06, 2010 at 04:06:31PM +0800, Kacheong Poon wrote: > >Suppose the process is able to exit but the socket lingers. In that > >case will the lingering socket defeat resource controls? > > I guess your concern is that somehow the peer goes away at the > *right* time and TCP stays in the FIN-WAIT-2 state for the > extended period of time. I further assume that you are using > this as an example of a new attack. And the goal is to create > as many lingering tcp_ts in the system as possible. For this > attack to be successful, there must be a peer co-operating. And The peer need only accept connections though, right? > [...] > As I mentioned before, if folks are not comfortable with the > value ranges, I can change that. In this case, the max can be > changed to a similar value I mentioned previously for > TCP_ABORT_THRESHOLD, which is 2 hours. Does this help? It's not the ABORT threshold that I'm worried about, but the TCP_LINGER2 timer. I recommend that the maximum for that be not more than some smallish value such as 60s. Nico -- From ka-cheong.poon@oracle.com Mon May 10 13:12:34 2010 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o46GLe6N014979 for ; Thu, 6 May 2010 09:21:40 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o46GLeuD011681 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 6 May 2010 09:21:40 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L200000NAS4RU00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 06 May 2010 10:21:40 -0600 (MDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L200048QAS38VE0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 06 May 2010 10:21:40 -0600 (MDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o46GLdTj029748 for ; Thu, 06 May 2010 16:21:39 +0000 (GMT) Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o465hVIu020287 for ; Thu, 06 May 2010 16:21:38 +0000 (GMT) Received: from abhmt003.oracle.com by acsmt354.oracle.com with ESMTP id 220055061273162831; Thu, 06 May 2010 09:20:31 -0700 Received: from [10.7.251.223] (/10.7.251.223) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 06 May 2010 09:20:31 -0700 Date: Fri, 07 May 2010 00:20:28 +0800 From: Kacheong Poon Subject: Re: PSARC 2010/151 new socket options for TCP timers In-reply-to: <20100506153249.GP9429@oracle.com> To: Nicolas Williams Cc: "Garrett D'Amore" , PSARC-ext Message-id: <4BE2EC4C.5030107@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt354.oracle.com [141.146.40.154] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090207.4BE2EC93.0098:SCFMA4539814,ss=1,fgs=0 References: <4BE19FDD.90009@oracle.com> <4BE1B0F3.5050704@oracle.com> <4BE1B35E.4070205@oracle.com> <20100505194855.GE9429@oracle.com> <4BE27887.9000706@oracle.com> <20100506153249.GP9429@oracle.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.9) Gecko/20100318 Lightning/1.0b1 Thunderbird/3.0.4 Status: RO Content-Length: 1348 On 05/ 6/10 11:32 PM, Nicolas Williams wrote: > On Thu, May 06, 2010 at 04:06:31PM +0800, Kacheong Poon wrote: >>> Suppose the process is able to exit but the socket lingers. In that >>> case will the lingering socket defeat resource controls? >> >> I guess your concern is that somehow the peer goes away at the >> *right* time and TCP stays in the FIN-WAIT-2 state for the >> extended period of time. I further assume that you are using >> this as an example of a new attack. And the goal is to create >> as many lingering tcp_ts in the system as possible. For this >> attack to be successful, there must be a peer co-operating. And > > The peer need only accept connections though, right? The peer probably needs to be a special program which knows when to stop at the close sequence to force the Solaris side to be stuck in FIN-WAIT-2 state. A normal TCP app cannot do that. > It's not the ABORT threshold that I'm worried about, but the TCP_LINGER2 > timer. I recommend that the maximum for that be not more than some > smallish value such as 60s. How about the following? The option value must be smaller than the TCP private parameter tcp_fin_wait_2_flush_interval. And this parameter can be changed by the admin to any value less than 2 hours (right now the max is 2^32ms). -- K. Poon. ka-cheong.poon@oracle.com From ka-cheong.poon@oracle.com Mon May 10 13:14:23 2010 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o46GLe6N014979 for ; Thu, 6 May 2010 09:21:40 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o46GLeuD011681 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 6 May 2010 09:21:40 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L200000NAS4RU00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 06 May 2010 10:21:40 -0600 (MDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L200048QAS38VE0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 06 May 2010 10:21:40 -0600 (MDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o46GLdTj029748 for ; Thu, 06 May 2010 16:21:39 +0000 (GMT) Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o465hVIu020287 for ; Thu, 06 May 2010 16:21:38 +0000 (GMT) Received: from abhmt003.oracle.com by acsmt354.oracle.com with ESMTP id 220055061273162831; Thu, 06 May 2010 09:20:31 -0700 Received: from [10.7.251.223] (/10.7.251.223) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 06 May 2010 09:20:31 -0700 Date: Fri, 07 May 2010 00:20:28 +0800 From: Kacheong Poon Subject: Re: PSARC 2010/151 new socket options for TCP timers In-reply-to: <20100506153249.GP9429@oracle.com> To: Nicolas Williams Cc: "Garrett D'Amore" , PSARC-ext Message-id: <4BE2EC4C.5030107@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt354.oracle.com [141.146.40.154] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090207.4BE2EC93.0098:SCFMA4539814,ss=1,fgs=0 References: <4BE19FDD.90009@oracle.com> <4BE1B0F3.5050704@oracle.com> <4BE1B35E.4070205@oracle.com> <20100505194855.GE9429@oracle.com> <4BE27887.9000706@oracle.com> <20100506153249.GP9429@oracle.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.9) Gecko/20100318 Lightning/1.0b1 Thunderbird/3.0.4 Status: RO Content-Length: 1348 On 05/ 6/10 11:32 PM, Nicolas Williams wrote: > On Thu, May 06, 2010 at 04:06:31PM +0800, Kacheong Poon wrote: >>> Suppose the process is able to exit but the socket lingers. In that >>> case will the lingering socket defeat resource controls? >> >> I guess your concern is that somehow the peer goes away at the >> *right* time and TCP stays in the FIN-WAIT-2 state for the >> extended period of time. I further assume that you are using >> this as an example of a new attack. And the goal is to create >> as many lingering tcp_ts in the system as possible. For this >> attack to be successful, there must be a peer co-operating. And > > The peer need only accept connections though, right? The peer probably needs to be a special program which knows when to stop at the close sequence to force the Solaris side to be stuck in FIN-WAIT-2 state. A normal TCP app cannot do that. > It's not the ABORT threshold that I'm worried about, but the TCP_LINGER2 > timer. I recommend that the maximum for that be not more than some > smallish value such as 60s. How about the following? The option value must be smaller than the TCP private parameter tcp_fin_wait_2_flush_interval. And this parameter can be changed by the admin to any value less than 2 hours (right now the max is 2^32ms). -- K. Poon. ka-cheong.poon@oracle.com From ka-cheong.poon@oracle.com Mon May 10 13:16:15 2010 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o4686e1r007318 for ; Thu, 6 May 2010 01:06:41 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o4686c5v048761 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 6 May 2010 02:06:40 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L1Z0020JNV36P00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 06 May 2010 01:06:39 -0700 (PDT) Received: from sca-ea-mail-3.sun.com ([192.18.43.21]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L1Z001SRNV3PB00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 06 May 2010 01:06:39 -0700 (PDT) Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o4686coL017339 for ; Thu, 06 May 2010 08:06:39 +0000 (GMT) Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4686b6G004500 for ; Thu, 06 May 2010 08:06:37 +0000 (GMT) Received: from abhmt002.oracle.com by acsmt355.oracle.com with ESMTP id 241777481273133195; Thu, 06 May 2010 01:06:35 -0700 Received: from [10.7.251.223] (/10.7.251.223) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 06 May 2010 01:06:34 -0700 Date: Thu, 06 May 2010 16:06:31 +0800 From: Kacheong Poon Subject: Re: PSARC 2010/151 new socket options for TCP timers In-reply-to: <20100505194855.GE9429@oracle.com> To: Nicolas Williams Cc: "Garrett D'Amore" , PSARC-ext Message-id: <4BE27887.9000706@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090205.4BE2788E.00AE:SCFMA4539814,ss=1,fgs=0 References: <4BE19FDD.90009@oracle.com> <4BE1B0F3.5050704@oracle.com> <4BE1B35E.4070205@oracle.com> <20100505194855.GE9429@oracle.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.9) Gecko/20100318 Lightning/1.0b1 Thunderbird/3.0.4 Status: RO Content-Length: 1522 On 05/ 6/10 03:48 AM, Nicolas Williams wrote: > What happens when a socket in FIN_WAIT2 is close()d, or a process exits > and a socket is closed and ends up in FIN_WAIT2? If the FIN_WAIT2 timer > is set to 2^31, what happens? Nothing special :-) The connection can finish the close sequence and the tcp_t transitions to TIME-WAIT state. > Suppose the process is able to exit but the socket lingers. In that > case will the lingering socket defeat resource controls? I guess your concern is that somehow the peer goes away at the *right* time and TCP stays in the FIN-WAIT-2 state for the extended period of time. I further assume that you are using this as an example of a new attack. And the goal is to create as many lingering tcp_ts in the system as possible. For this attack to be successful, there must be a peer co-operating. And if you have a helpful peer, you can achieve the same thing right now without the help of the new options. In fact, you can do that more effectively (consuming more memory than the proposed attack) without the use of the new option. Although the sequence to do the above is simple, I will let the readers think about how to do that. I will send a mail privately to explain the steps. As I mentioned before, if folks are not comfortable with the value ranges, I can change that. In this case, the max can be changed to a similar value I mentioned previously for TCP_ABORT_THRESHOLD, which is 2 hours. Does this help? -- K. Poon. ka-cheong.poon@oracle.com From ka-cheong.poon@oracle.com Mon May 10 13:18:13 2010 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o4684bXK007309 for ; Thu, 6 May 2010 01:04:38 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o4684alI047614 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 6 May 2010 02:04:37 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L1Z00N1DNRP0200@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 06 May 2010 01:04:37 -0700 (PDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L1Z00AQENROOH30@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 06 May 2010 01:04:37 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o4684aG3020943 for ; Thu, 06 May 2010 08:04:36 +0000 (GMT) Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o465hAlb019560 for ; Thu, 06 May 2010 08:04:35 +0000 (GMT) Received: from abhmt020.oracle.com by acsmt353.oracle.com with ESMTP id 241762241273132992; Thu, 06 May 2010 01:03:12 -0700 Received: from [10.7.251.223] (/10.7.251.223) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 06 May 2010 01:03:11 -0700 Date: Thu, 06 May 2010 16:03:09 +0800 From: Kacheong Poon Subject: Re: PSARC 2010/151 new socket options for TCP timers In-reply-to: <4BE1C71C.10009@oracle.com> To: "Garrett D'Amore" Cc: PSARC-ext Message-id: <4BE277BD.3080901@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090203.4BE27814.0065:SCFMA4539814,ss=1,fgs=0 References: <4BE19FDD.90009@oracle.com> <4BE1B0F3.5050704@oracle.com> <4BE1B35E.4070205@oracle.com> <4BE1B9A7.8030503@oracle.com> <4BE1C71C.10009@oracle.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.9) Gecko/20100318 Lightning/1.0b1 Thunderbird/3.0.4 Status: RO Content-Length: 1691 On 05/ 6/10 03:29 AM, Garrett D'Amore wrote: > My point was that these timers could affect the resources that are > consumed on the system *after* a socket is closed. Ultimately, that > means that any limits already in existence that limit open files won't > necessarily apply to these timers. > > While these timers don't necessarily *create* a *new* weakness, my > concern is that increasing the value of the timers may make it *easier* > for a malicious program to create a DoS situation. I think the options neither make it easier nor harder. One can do the same type of resource exhaustion attack right now. And the concern is really about a generic resource control (*) in the network stack, which is outside the scope of this case. As I mentioned in a previous mail, if folks are not comfortable with the value ranges, I can certainly change that. For example, TCP_ABORT_THRESHOLD (tcp_ip_abort_interval) can be limited to 2 hours (oops, this means that inter-planetary TCP communication won't work in Solaris anymore...) > Its not new.. its a situation where the DoS I described above can be > *easier*. I'm not sure just how *much* easier it is, but that's the > nature of the question I'm asking. "Difficulty" is certainly subjective. Does having 2 fewer lines of code mean "easier"? How about 20 lines? I think the question should be practical or impractical (assuming it is always possible). IMHO, the new options do not introduce new attack in practice, nor make an impractical attack practical. (*) Note that the early abort timeout when the system is short in memory is not affected by these options. -- K. Poon. ka-cheong.poon@oracle.com From garrett.damore@oracle.com Mon May 10 13:26:46 2010 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o46FkELN013891 for ; Thu, 6 May 2010 08:46:14 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o46FkAHs018818 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 6 May 2010 10:46:13 -0500 (CDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L2000M199516J00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 06 May 2010 08:46:13 -0700 (PDT) Received: from sca-ea-mail-4.sun.com ([192.18.43.22]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L2000DUM950XGA0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 06 May 2010 08:46:12 -0700 (PDT) Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o46FkC0d004197 for ; Thu, 06 May 2010 15:46:12 +0000 (GMT) Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o46FkAlm000526 for ; Thu, 06 May 2010 15:46:11 +0000 (GMT) Received: from abhmt004.oracle.com by acsmt353.oracle.com with ESMTP id 243181401273160770; Thu, 06 May 2010 08:46:10 -0700 Received: from [10.7.251.172] (/10.7.251.172) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 06 May 2010 08:46:08 -0700 Date: Thu, 06 May 2010 08:46:06 -0700 From: "Garrett D'Amore" Subject: Re: PSARC 2010/151 new socket options for TCP timers In-reply-to: <20100506153249.GP9429@oracle.com> To: Nicolas Williams Cc: Kacheong Poon , PSARC-ext Message-id: <4BE2E43E.6010503@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt353.oracle.com [141.146.40.153] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090202.4BE2E443.00FF:SCFMA4539814,ss=1,fgs=0 References: <4BE19FDD.90009@oracle.com> <4BE1B0F3.5050704@oracle.com> <4BE1B35E.4070205@oracle.com> <20100505194855.GE9429@oracle.com> <4BE27887.9000706@oracle.com> <20100506153249.GP9429@oracle.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.7) Gecko/20100214 Lightning/1.0b1 Thunderbird/3.0.1 Status: RO Content-Length: 1772 On 05/ 6/10 08:32 AM, Nicolas Williams wrote: > On Thu, May 06, 2010 at 04:06:31PM +0800, Kacheong Poon wrote: > >>> Suppose the process is able to exit but the socket lingers. In that >>> case will the lingering socket defeat resource controls? >>> >> I guess your concern is that somehow the peer goes away at the >> *right* time and TCP stays in the FIN-WAIT-2 state for the >> extended period of time. I further assume that you are using >> this as an example of a new attack. And the goal is to create >> as many lingering tcp_ts in the system as possible. For this >> attack to be successful, there must be a peer co-operating. And >> > The peer need only accept connections though, right? > > >> [...] >> > >> As I mentioned before, if folks are not comfortable with the >> value ranges, I can change that. In this case, the max can be >> changed to a similar value I mentioned previously for >> TCP_ABORT_THRESHOLD, which is 2 hours. Does this help? >> > It's not the ABORT threshold that I'm worried about, but the TCP_LINGER2 > timer. I recommend that the maximum for that be not more than some > smallish value such as 60s. > I agree. Wouldn't it also be possible to arrange for a "helpful" peer by using a second cooperating process on the same system? I'm approaching the mind, given the earlier discussion, that we need to have a project to examine this problem, and that it may be out of scope for this project. Nevertheless, as we lack a mechanism for ARC to express anything other than via opinion, perhaps derailing (and a subsequent vote to approve) just to facilitate an opinion that suggests that this problem be examined might be in order. I'm not dead set on it, though. - Garrett From ka-cheong.poon@oracle.com Mon May 10 13:32:40 2010 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o467xwiX007202 for ; Thu, 6 May 2010 00:59:58 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o467xvxF002505 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 6 May 2010 02:59:58 -0500 (CDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L1Z0010VNJXUF00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 06 May 2010 00:59:57 -0700 (PDT) Received: from sca-ea-mail-1.sun.com ([192.18.43.24]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L1Z00196NJXPE00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 06 May 2010 00:59:57 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o467xut3015059 for ; Thu, 06 May 2010 07:59:57 +0000 (GMT) Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o467xttq007992 for ; Thu, 06 May 2010 07:59:55 +0000 (GMT) Received: from abhmt021.oracle.com by acsmt355.oracle.com with ESMTP id 241744391273132742; Thu, 06 May 2010 00:59:02 -0700 Received: from [10.7.251.223] (/10.7.251.223) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 06 May 2010 00:59:02 -0700 Date: Thu, 06 May 2010 15:58:58 +0800 From: Kacheong Poon Subject: Re: PSARC 2010/151 new socket options for TCP timers In-reply-to: <4BE1C5AB.2040603@oracle.com> To: Andrew Gabriel Cc: PSARC-ext Message-id: <4BE276C2.4020902@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt353.oracle.com [141.146.40.153] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090202.4BE276FC.0137:SCFMA4539814,ss=1,fgs=0 References: <4BE1BD1C.5080407@oracle.com> <4BE1C5AB.2040603@oracle.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.9) Gecko/20100318 Lightning/1.0b1 Thunderbird/3.0.4 Status: RO Content-Length: 2076 On 05/ 6/10 03:23 AM, Andrew Gabriel wrote: >> TCP_CONN_ABORT_THRESHOLD, TCP_ABORT_THRESHOLD >> --------------------------------------------- > I can see two cases where I would use these: > 1) Where my application wants a short connection establishment timeout > or a quick connection failure detection, i.e. shorter in either case > than the default TCP values, because my application wants to take some > other action in these cases before TCP is likely to have timed out the > operation. > 2) Where my application requires a permanent TCP connection, and I'm not > interested in knowing about timeouts - just keep trying. > > Unfortunately, 2) is not quite handled in this case, as there are no > values which are interpreted as infinity (i.e. no timeout), so I still > have to handle the case where connect(), read(), write(), etc return > timeouts, even if they do it less often. Having an infinity value might > allow me to simplify my application coding (even though I still have to > handle the possibility of a RST). Is the value 'zero' free to be > interpreted as infinity? The value 0 is free and indeed can be used to mean infinity. But is (2) really useful in practice? Having that only eliminates a subset of errors. And the handling of this subset of errors is probably similar to the handling of its complement. If folks really think that it is a useful, I can add this meaning assuming that there is no objection. >> TCP_LINGER2 >> ----------- >> >> [...] The default value of tcp_fin_wait_2_flush_interval is also >> changed to 60s. > > Just wondering if that's safe/acceptable for a patch binding? Could you please elaborate your concern? >> Diff of tcp(7P) > > I would add something to say that changing these new parameters requires > detailed knowledge of the application and the TCP protocol, and normally > there is no need to change them. We're giving the programmer some rope, > but it's worth warning him not to make a noose for himself. OK, I can add those words to the man page. -- K. Poon. ka-cheong.poon@oracle.com From ka-cheong.poon@oracle.com Mon May 10 13:34:31 2010 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o46GSPhj015027 for ; Thu, 6 May 2010 09:28:25 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o46GSMg2035375 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 6 May 2010 10:28:25 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L200012RB3C4Q00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 06 May 2010 09:28:24 -0700 (PDT) Received: from sca-ea-mail-1.sun.com ([192.18.43.24]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L2000DZ1B3BXLD0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 06 May 2010 09:28:23 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o46GSNjH001159 for ; Thu, 06 May 2010 16:28:23 +0000 (GMT) Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o46D3tct024536 for ; Thu, 06 May 2010 16:28:22 +0000 (GMT) Received: from abhmt007.oracle.com by acsmt354.oracle.com with ESMTP id 220075201273163227; Thu, 06 May 2010 09:27:07 -0700 Received: from [10.7.251.223] (/10.7.251.223) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 06 May 2010 09:27:06 -0700 Date: Fri, 07 May 2010 00:27:03 +0800 From: Kacheong Poon Subject: Re: PSARC 2010/151 new socket options for TCP timers In-reply-to: <4BE2E43E.6010503@oracle.com> To: "Garrett D'Amore" Cc: Nicolas Williams , PSARC-ext Message-id: <4BE2EDD7.1040105@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt353.oracle.com [141.146.40.153] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090201.4BE2EE26.010C:SCFMA4539814,ss=1,fgs=0 References: <4BE19FDD.90009@oracle.com> <4BE1B0F3.5050704@oracle.com> <4BE1B35E.4070205@oracle.com> <20100505194855.GE9429@oracle.com> <4BE27887.9000706@oracle.com> <20100506153249.GP9429@oracle.com> <4BE2E43E.6010503@oracle.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.9) Gecko/20100318 Lightning/1.0b1 Thunderbird/3.0.4 Status: RO Content-Length: 2140 On 05/ 6/10 11:46 PM, Garrett D'Amore wrote: > On 05/ 6/10 08:32 AM, Nicolas Williams wrote: >> On Thu, May 06, 2010 at 04:06:31PM +0800, Kacheong Poon wrote: >>>> Suppose the process is able to exit but the socket lingers. In that >>>> case will the lingering socket defeat resource controls? >>> I guess your concern is that somehow the peer goes away at the >>> *right* time and TCP stays in the FIN-WAIT-2 state for the >>> extended period of time. I further assume that you are using >>> this as an example of a new attack. And the goal is to create >>> as many lingering tcp_ts in the system as possible. For this >>> attack to be successful, there must be a peer co-operating. And >> The peer need only accept connections though, right? >> >>> [...] >>> As I mentioned before, if folks are not comfortable with the >>> value ranges, I can change that. In this case, the max can be >>> changed to a similar value I mentioned previously for >>> TCP_ABORT_THRESHOLD, which is 2 hours. Does this help? >> It's not the ABORT threshold that I'm worried about, but the TCP_LINGER2 >> timer. I recommend that the maximum for that be not more than some >> smallish value such as 60s. > > I agree. Wouldn't it also be possible to arrange for a "helpful" peer by > using a second cooperating process on the same system? The peer needs to be a special program, such as a raw socket program which sends/receives TCP packets directly. In Solaris, only privileged apps can do that. But if the app is privileged, it can do other more "interesting" things directly than this. > I'm approaching the mind, given the earlier discussion, that we need to > have a project to examine this problem, and that it may be out of scope > for this project. Nevertheless, as we lack a mechanism for ARC to > express anything other than via opinion, perhaps derailing (and a > subsequent vote to approve) just to facilitate an opinion that suggests > that this problem be examined might be in order. Which problem are you referring to here? AFAICT, there is no new problem mentioned in this email thread. -- K. Poon. ka-cheong.poon@oracle.com From carlsonj@workingcode.com Mon May 10 14:05:43 2010 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o4AL5gxF012850 for ; Mon, 10 May 2010 14:05:43 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o4AL5g8H013194 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Mon, 10 May 2010 15:05:42 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L2800C052LIV700@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 10 May 2010 14:05:42 -0700 (PDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L28004502LHB890@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 10 May 2010 14:05:41 -0700 (PDT) Received: from relay13i.sun.com (ip123.net129179-4.block1.us.syntegra.com [129.179.4.123]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o4AL5evh010388 for ; Mon, 10 May 2010 21:05:41 +0000 (GMT) Received: from mmp11es.mmp.us.syntegra.com ([160.41.208.11] [160.41.208.11]) by relay13i.sun.com with ESMTP id BT-MMP-1097728 for PSARC-ext@sun.com; Mon, 10 May 2010 21:05:39 +0000 (Z) Received: from relay13i.sun.com (relay13i.sun.com [129.179.4.123]) by mmp11es.mmp.us.syntegra.com with ESMTP id BT-MMP-197724945 for PSARC-ext@sun.com; Mon, 10 May 2010 21:05:39 +0000 (Z) Received: from carlson.workingcode.com ([75.150.68.97] [75.150.68.97]) by relay1i.sun.com with ESMTP id BT-MMP-55073567 for PSARC-ext@sun.com; Mon, 10 May 2010 21:05:39 +0000 (Z) Received: from [10.50.23.149] (gate.abinitio.com [65.170.40.132]) (authenticated bits=0) by carlson.workingcode.com (8.14.2+Sun/8.14.4) with ESMTP id o4AL5WDo004116 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 10 May 2010 17:05:32 -0400 (EDT) Date: Mon, 10 May 2010 17:05:31 -0400 From: James Carlson Subject: Re: PSARC 2010/151 new socket options for TCP timers In-reply-to: <4BE276C2.4020902@oracle.com> To: Kacheong Poon Cc: Andrew Gabriel , PSARC-ext Message-id: <4BE8751B.5030001@workingcode.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-DCC-sonic.net-Metrics: carlson; whitelist X-Antispam: No, score=0.0/5.0, scanned in 0.246sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <4BE1BD1C.5080407@oracle.com> <4BE1C5AB.2040603@oracle.com> <4BE276C2.4020902@oracle.com> User-Agent: Thunderbird 2.0.0.22 (X11/20090605) Status: RO Content-Length: 1405 Kacheong Poon wrote: > On 05/ 6/10 03:23 AM, Andrew Gabriel wrote: >> Unfortunately, 2) is not quite handled in this case, as there are no >> values which are interpreted as infinity (i.e. no timeout), so I still >> have to handle the case where connect(), read(), write(), etc return >> timeouts, even if they do it less often. Having an infinity value might >> allow me to simplify my application coding (even though I still have to >> handle the possibility of a RST). Is the value 'zero' free to be >> interpreted as infinity? > > > The value 0 is free and indeed can be used to mean infinity. > But is (2) really useful in practice? Having that only > eliminates a subset of errors. And the handling of this > subset of errors is probably similar to the handling of > its complement. If folks really think that it is a useful, > I can add this meaning assuming that there is no objection. The useful case I can think of is an application where all of the meaningful timers are implemented in user space, and the socket is set non-blocking. In other words, the application isn't expecting to see time-out on connect() or in other cases, and is instead expecting to discard (perhaps with linger=0) when the socket isn't behaving as needed. In that case, a kernel-level timer is just a nuisance (albeit a minor one). -- James Carlson 42.703N 71.076W From ka-cheong.poon@oracle.com Wed May 12 08:26:37 2010 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o4CFQbR1006104 for ; Wed, 12 May 2010 08:26:37 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o4CFQX9r012197 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 12 May 2010 08:26:37 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L2B00705C88X200@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 12 May 2010 09:26:32 -0600 (MDT) Received: from jurassic.Eng.Sun.COM ([129.146.17.63]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L2B007GMC879Z00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 12 May 2010 09:26:32 -0600 (MDT) Received: from [10.7.251.223] (punchin-kcpoon.SFBay.Sun.COM [10.7.251.223]) by jurassic.Eng.Sun.COM (8.14.4+Sun/8.14.4) with ESMTP id o4CFQTSA176011 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 12 May 2010 08:26:30 -0700 (PDT) Date: Wed, 12 May 2010 23:26:27 +0800 From: Kacheong Poon Subject: Re: new socket options for TCP timers [PSARC/2010/151 FastTrack timeout 05/10/2010] In-reply-to: <4BDF0C27.4020700@oracle.com> To: psarc-ext Cc: Sebastien Roy Message-id: <4BEAC8A3.4000600@oracle.com> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_tE1/hGcB8gPf4gV2HSzOLQ)" X-PMX-Version: 5.4.1.325704 References: <4BDF0C27.4020700@oracle.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.9) Gecko/20100318 Lightning/1.0b1 Thunderbird/3.0.4 Status: RO Content-Length: 7892 This is a multi-part message in MIME format. --Boundary_(ID_tE1/hGcB8gPf4gV2HSzOLQ) Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT Attached please find the updated specification of this case. I've incorporated the comments suggested in the discussion. -- K. Poon. kacheong.poon@sun.com --Boundary_(ID_tE1/hGcB8gPf4gV2HSzOLQ) Content-type: text/plain; name=opts Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=opts This case introduces four TCP level socket options, TCP_RTO_INITIAL, TCP_RTO_MIN, TCP_RTO_MAX, and TCP_LINGER2. This case also documents the existing options TCP_CONN_ABORT_THRESHOLD and TCP_ABORT_THRESHOLD. TCP_RTO_INITIAL, TCP_RTO_MIN, TCP_RTO_MAX ----------------------------------------- An application can use these three options to change/retrieve respectively the initial, minimum and maximum retransmission timeout values of a TCP connection. The option value is an uint32_t and the unit is milli-second (actual value is rounded up to the nearest clock tick interval). The lower bound of the options is 1ms. The upper bound of TCP_RTO_INITIAL is 20s. And the upper bound of TCP_RTO_MIN and TCP_RTO_MAX is 2 hours. 0 means no change on the timeout value. These options correspond to the private TCP parameters tcp_rexmit_interval_initial, tcp_rexmit_interval_min and tcp_rexmit_interval_max, which control the default values used in an IP stack. The lower and upper bounds of the options are the same as that of the private TCP parameters. Note that these socket options do not change TCP's dynamic RTO calcuation. They only set the boundaries and initial value. For example, the default initial RTO is 3s because of "conservative" (meaning it seems to work) reason. It is really not correct since there is no estimation. If an app knows what it is, it is good to let it set the value. There must be a maximum value when TCP exponentially backs off RTO in doing retransmission. It does not make sense to back off without bound. If an app will abort the connection after a fixed time with no response from its peer, it makes sense to allow the app to control the maximum RTO. Otherwise, it may happen that there is no retransmission at all before the app terminates the connection. Similarly, there must be a minimum. RTO calculation may not converge quickly or the algorithm may not work well for certain type of network (*) and may cause false timeout. If an app knows better, it makes sense to let it set the value. TCP_CONN_ABORT_THRESHOLD, TCP_ABORT_THRESHOLD --------------------------------------------- An application can use these two options to change/retreive the total time a TCP connection spent doing retransmission without getting back an acknowledgement. TCP_CONN_ABORT_THRESHOLD controls this interval before a connection is established. TCP_ABORT_THRESHOLD controls the interval after a connection is established. The option value is an uint32_t and the unit is milli-second (actual value is rounded up to the nearest clock tick interval). The lower bound of TCP_CONN_ABORT_THRESHOLD is 1000ms and the upper bound is UINT32_MAX ms. The lower bound of TCP_ABORT_THRESHOLD is 500ms and the upper bound is UINT32_MAX ms. The option value 0 means that TCP will try to retransmit forever without timing out. These options correspond to the private TCP parameters tcp_ip_abort_cinterval and tcp_ip_abort_interval, which control the default values used in an IP stack. The lower and upper bound of the options are the same as that of the private parameters. TCP_LINGER2 ----------- An application can use this option to change/retrieve the amount of time a closed TCP connection stays in FIN-WAIT-2 state. The option value is an int and the unit is second. The lower bound is 1s and the upper bound is the value of the TCP private parameter tcp_fin_wait_2_flush_interval. 0 means no change on the value. Negative value is not allowed. This option is introduced to ease porting Linux applications using this option to Solaris. It corresponds to the private TCP parameters tcp_fin_wait_2_flush_interval, which controls the default value used in an IP stack. The unit of this parameter is milli-second, which is different from that of the socket option because the option value unit needs to be the same as in Linux. The lower and upper bound of the option are the same (after unit conversion) as the private TCP parameter. The default value of tcp_fin_wait_2_flush_interval is also changed to 60s. Diff of tcp(7P) *************** *** 216,223 **** --- 216,245 ---- If the local TCP receives no acknowledgements from its peer for a period of time, (for example, if the remote machine crashes), the connection is closed and an error is returned. + The TCP level socket options, TCP_CONN_ABORT_THRESHOLD and + TCP_ABORT_THRESHOLD can be used to change and retrieve this + period of time. The option value is uint32_t and the unit is + milli-second. TCP_CONN_ABORT_THRESHOLD and TCP_ABORT_THRESHOLD + control respecively this period before and after a connection + is established. If the application does not want TCP to time + out, it can use the option value 0. + During this period, TCP tries to retransmit the unacknowledged + data multiple times, each after a timeout. And the timeout + interval is exponentially backed off. The TCP level socket + options, TCP_RTO_INITIAL, TCP_RTO_MIN, and TCP_RTO_MAX can be + used to control the timeout interval. TCP_RTO_INITIAL controls + the initial retransmission timeout period. TCP_RTO_MIN and + TCP_RTO_MAX control the minimum and maximum timeout period + respectively. The option value is an uint32_t and the unit + is milli-second. + Note that the default values of the above options, + TCP_CONN_ABORT_THRESHOLD, TCP_ABORT_THRESHOLD, TCP_RTO_MIN, + TCP_RTO_MAX, and TCP_RTO_INITIAL are appropriate for most + situations. An application should only alter their values + in special circumstances and when it has detailed knowledge + of the network environment. + TCP follows the congestion control algorithm described in RFC 2581, and also supports the initial congestion window (cwnd) changes in RFC 3390. The initial cwnd calculation can *************** *** 434,439 **** --- 456,475 ---- the TCP ndd parameter tcp_keepalive_abort_interval. The default is eight minutes. + After an application closes a TCP connection, TCP enters the + shutdown sequence. But if the peer does not respond (it + crashes), the connection will be stuck in this state + (FIN-WAIT-2). To prevent this, SunOS starts a timer when TCP + enters this state. If the timer fires and the shtudown + sequence has not completed, the connection will be freed. The + socket option TCP_LINGER2 can be used to change and retrieve + this timeout period. The opton value is an int and the unit + is second. The option value cannot be set higher than the + system default value, which is controlled by the TCP private * parameter tcp_fin_wait_2_flush_interval. The default value is + appropriate for most situations. An application should only + change the value in some special circumstances and when it has + detailed knowledge of the network environment. + + SEE ALSO svcs(1), ndd(1M), ioctl(2), read(2), svcadm(1M), write(2), accept(3SOCKET), bind(3SOCKET), connect(3SOCKET), (*) Existing mobile network is a good example. It buffers extensively (how much depends on the provider) and TCP's current algorithm does not work well with that. --Boundary_(ID_tE1/hGcB8gPf4gV2HSzOLQ)-- From sebastien.roy@oracle.com Thu May 13 13:01:55 2010 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o4DK1tpM001023 for ; Thu, 13 May 2010 13:01:55 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o4DK1sKt013704 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 13 May 2010 13:01:55 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L2D00L0NJN7JY00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 13 May 2010 14:01:55 -0600 (MDT) Received: from sca-ea-mail-1.sun.com ([192.18.43.24]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L2D007O4JN6APB0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 13 May 2010 14:01:54 -0600 (MDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o4DK1sN6024151 for ; Thu, 13 May 2010 20:01:54 +0000 (GMT) Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4DK1mvv009323 for ; Thu, 13 May 2010 20:01:48 +0000 (GMT) Received: from abhmt010.oracle.com by acsmt355.oracle.com with ESMTP id 263089771273780827; Thu, 13 May 2010 13:00:27 -0700 Received: from [129.148.174.103] (/129.148.174.103) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 13 May 2010 13:00:27 -0700 Date: Thu, 13 May 2010 16:00:26 -0400 From: Sebastien Roy Subject: Re: new socket options for TCP timers [PSARC/2010/151 FastTrack timeout 05/10/2010] In-reply-to: <4BEAC8A3.4000600@oracle.com> To: Kacheong Poon Cc: psarc-ext Message-id: <4BEC5A5A.6050901@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090207.4BEC5AAE.0023:SCFMA4539814,ss=1,fgs=0 References: <4BDF0C27.4020700@oracle.com> <4BEAC8A3.4000600@oracle.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.8) Gecko/20100412 Lightning/1.0b1 Thunderbird/3.0.3 Status: RO Content-Length: 323 On 05/12/10 11:26 AM, Kacheong Poon wrote: > Attached please find the updated specification of this case. > I've incorporated the comments suggested in the discussion. Note that this case timed out a few days ago and it has not yet received a +1. This is a reminder to members that this spec needs to be reviewed. -Seb From sebastien.roy@oracle.com Mon May 24 10:05:16 2010 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o4OH5GZP003341 for ; Mon, 24 May 2010 10:05:16 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o4OH5Fki017228 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Mon, 24 May 2010 12:05:15 -0500 (CDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L2X00H0DOSRG100@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 24 May 2010 10:05:15 -0700 (PDT) Received: from sca-ea-mail-1.sun.com ([192.18.43.24]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L2X00E4JOSQC040@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 24 May 2010 10:05:14 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o4OH5E0D006276 for ; Mon, 24 May 2010 17:05:14 +0000 (GMT) Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4ODH7OW011890 for ; Mon, 24 May 2010 17:05:12 +0000 (GMT) Received: from abhmt007.oracle.com by acsmt355.oracle.com with ESMTP id 293576981274720702; Mon, 24 May 2010 10:05:02 -0700 Received: from [129.148.174.103] (/129.148.174.103) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 24 May 2010 10:05:01 -0700 Date: Mon, 24 May 2010 13:05:00 -0400 From: Sebastien Roy Subject: Re: new socket options for TCP timers [PSARC/2010/151 FastTrack timeout 05/10/2010] In-reply-to: <4BDF0C27.4020700@oracle.com> To: psarc-ext Cc: Kacheong Poon Message-id: <4BFAB1BC.4080502@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090203.4BFAB1C9.013A:SCFMA4539814,ss=1,fgs=0 References: <4BDF0C27.4020700@oracle.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.8) Gecko/20100412 Lightning/1.0b1 Thunderbird/3.0.3 Status: RO Content-Length: 56 This case was approved during last week's meeting. -Seb