From sacadmin Thu Jun 22 04:29:03 2006 Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k5MBT2On011366 for ; Thu, 22 Jun 2006 04:29:03 -0700 (PDT) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id k5MBTw8p009789; Thu, 22 Jun 2006 07:29:58 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.13.6+Sun/8.13.6/Submit) id k5MBTw4q009786; Thu, 22 Jun 2006 07:29:58 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17562.32566.617112.281658@gargle.gargle.HOWL> Date: Thu, 22 Jun 2006 07:29:58 -0400 From: James Carlson To: psarc@sac.sfbay.sun.com cc: kacheong.poon@sun.com Subject: 2006/407 [TCP|UDP]_EXCLBIND Stability Change X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 5423 I'm sponsoring this case for Kacheong Poon. I believe it's obvious enough to qualify for self review, so I've marked it "closed approved automatic." Please speak up if you disagree. This case requests a Patch/Micro release binding and Stability level is Committed. The Consolidation Private socket options [TCP|UDP]_EXCLBIND were introduced in PSARC 1999/609, "Exclusive Binding Socket Option for TCP and UDP." At that time, there was an urgent need to fix a security issue, port stealing, in RPC. The options were introduced so that the RPC code could use it to bind a port exclusively, hence no port stealing could happen. But it was not clear whether this solution had some unwanted side effects. So the options were marked as Consolidation Private. After so many years of experience, it seems that the options are a reasonable solution to the port stealing issue without adverse side effect. And there have been customers asking how they can solve the port stealing issue. This case requests to change the Stability level of the options to Committed so that our customers can use them in their code with our support. The man pages of tcp(7P) and udp(7P) will be modified as follows. Diff on tcp(7P) at connection time to the address of the network interface used to service the connection. + A note about binding a TCP socket. No two TCP sockets can + be bound to the same port unless the bound IP addresses are + different. IPv4 INADDR_ANY and IPv6 unspecified addresses + compare as equal to any IPv4 or IPv6 address. For example, if a + socket is bound to INADDR_ANY or unspecified address and port X, + no other socket can bind to port X, regardless of the binding + address. This special consideration of INADDR_ANY and unspecified + address can be changed using the socket option SO_REUSEADDR. + If this option is set on a socket doing a bind, IPv4 INADDR_ANY + and IPv6 unspecified address do not compare as equal to any IP + address. This means that as long as the two sockets are not + both bound to INADDR_ANY/unspecified address or the same + IP address, the two sockets can be bound to the same port. + + If an application does not want to allow another socket + using the SO_REUSEADDR option to bind to a port its socket + is bound to, the application can set the TCP level option + TCP_EXCLBIND on a socket. The option values of 0 and 1 mean + enabling and disabling the option respectively. Once this + option is enabled on a socket, no other socket can be bound + to the same port. + Once a connection has been established, data can be exchanged using the read(2) and write(2) system calls. Diff on udp(7P) work interface dependent. Broadcasts may only be sent by the privileged user. + A note about binding a UDP socket. No two UDP sockets can + be bound to the same port unless the bound IP addresses are + different. IPv4 INADDR_ANY and IPv6 unspecified addresses + compare as equal to any IPv4 or IPv6 address. For example, if a + socket is bound to INADDR_ANY or unspecified address and port X, + no other socket can bind to port X, regardless of the binding + address. This special consideration of INADDR_ANY and unspecified + address can be changed using the socket option SO_REUSEADDR. + If this option is set on a socket doing a bind, IPv4 INADDR_ANY + and IPv6 unspecified address do not compare as equal to any IP + address. This means that as long as the two sockets are not + both bound to INADDR_ANY/unspecified address or the same + IP address, the two sockets can be bound to the same port. + + If an application does not want to allow another socket + using the SO_REUSEADDR option to bind to a port its socket + is bound to, the application can set the UDP level option + UDP_EXCLBIND on a socket. The option values of 0 and 1 mean + enabling and disabling the option respectively. Once this + option is enabled on a socket, no other socket can be bound + to the same port. + IPv6 does not support broadcast addresses; their function is supported by IPv6 multicast addresses. The comments on the options in the and will be removed as follows. Diff on tcp.h. /* gap for expansion of ``standard'' options */ #define TCP_ANONPRIVBIND 0x20 /* for internal use only */ ! #define TCP_EXCLBIND 0x21 /* for internal use only */ #ifdef __cplusplus } --- 101,107 ---- /* gap for expansion of ``standard'' options */ #define TCP_ANONPRIVBIND 0x20 /* for internal use only */ ! #define TCP_EXCLBIND 0x21 #ifdef __cplusplus } Diff on udp.h. /* Option definitions. */ #define UDP_ANONPRIVBIND 0x0100 /* for internal use only */ ! #define UDP_EXCLBIND 0x0101 /* for internal use only */ #define UDP_RCVHDR 0x0102 /* for internal use only */ /* * Following option in UDP_ namespace required to be exposed through --- 33,39 ---- /* Option definitions. */ #define UDP_ANONPRIVBIND 0x0100 /* for internal use only */ ! #define UDP_EXCLBIND 0x0101 #define UDP_RCVHDR 0x0102 /* for internal use only */ /* * Following option in UDP_ namespace required to be exposed through From sacadmin Thu Jun 22 04:44:37 2006 Received: from sunnl.holland.sun.com (sunnl.Holland.Sun.COM [129.159.201.1]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k5MBiaIQ011506 for ; Thu, 22 Jun 2006 04:44:37 -0700 (PDT) Received: from vaticaan.holland.sun.com (vaticaan [129.159.201.10]) by sunnl.holland.sun.com (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k5MBiXaD027574; Thu, 22 Jun 2006 13:44:33 +0200 (MEST) Received: from holland (casper@room101 [129.159.201.52]) by vaticaan.holland.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k5MBiXNs014471; Thu, 22 Jun 2006 13:44:33 +0200 (MEST) Message-Id: <200606221144.k5MBiXNs014471@vaticaan.holland.sun.com> From: Casper.Dik@sun.com To: James Carlson cc: psarc@sac.sfbay.sun.com, kacheong.poon@sun.com Subject: Re: 2006/407 [TCP|UDP]_EXCLBIND Stability Change In-Reply-To: <17562.32566.617112.281658@gargle.gargle.HOWL> References: <17562.32566.617112.281658@gargle.gargle.HOWL> Date: Thu, 22 Jun 2006 13:44:33 +0200 Sender: casper@holland.sun.com Status: RO Content-Length: 544 >After so many years of experience, it seems that the options >are a reasonable solution to the port stealing issue without >adverse side effect. And there have been customers asking >how they can solve the port stealing issue. This case requests >to change the Stability level of the options to Committed so >that our customers can use them in their code with our support. > I seem to remember there was some issue with IPv4 vs IPv6. If I understand correctly, exclusively binding to port ipv4 X prevents both IPV6/IPV4 reuses? Casper From sacadmin Thu Jun 22 04:53:12 2006 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.108.38]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k5MBrCOm011618 for ; Thu, 22 Jun 2006 04:53:12 -0700 (PDT) Received: from [192.9.61.50] (punchin-kcpoon.SFBay.Sun.COM [192.9.61.50]) by jurassic.eng.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k5MBr9Nt622640 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Thu, 22 Jun 2006 04:53:11 -0700 (PDT) Message-ID: <449A84A5.3010900@sun.com> Date: Thu, 22 Jun 2006 19:53:09 +0800 From: Kacheong Poon Organization: Sun Microsystems, Inc. User-Agent: Thunderbird 1.5.0.4 (X11/20060602) MIME-Version: 1.0 To: psarc@sac.sfbay.sun.com Subject: Re: 2006/407 [TCP|UDP]_EXCLBIND Stability Change References: <17562.32566.617112.281658@gargle.gargle.HOWL> <200606221144.k5MBiXNs014471@vaticaan.holland.sun.com> In-Reply-To: <200606221144.k5MBiXNs014471@vaticaan.holland.sun.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Status: RO Content-Length: 426 Casper.Dik@Sun.COM wrote: > I seem to remember there was some issue with IPv4 vs IPv6. > > If I understand correctly, exclusively binding to port ipv4 X prevents > both IPV6/IPV4 reuses? Yes, because there is also the IPv4/IPv6 port stealing issue. I've talked about this issue in the following thread http://www.opensolaris.org/jive/thread.jspa?messageID=15541㲵 -- K. Poon. kacheong.poon@sun.com From sacadmin Thu Jun 22 04:56:51 2006 Received: from sunnl.holland.sun.com (sunnl.Holland.Sun.COM [129.159.201.1]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k5MBuoQN012292 for ; Thu, 22 Jun 2006 04:56:50 -0700 (PDT) Received: from vaticaan.holland.sun.com (vaticaan [129.159.201.10]) by sunnl.holland.sun.com (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k5MBulDa003119; Thu, 22 Jun 2006 13:56:47 +0200 (MEST) Received: from holland (casper@room101 [129.159.201.52]) by vaticaan.holland.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k5MBulix015723; Thu, 22 Jun 2006 13:56:47 +0200 (MEST) Message-Id: <200606221156.k5MBulix015723@vaticaan.holland.sun.com> From: Casper.Dik@sun.com To: Kacheong Poon cc: psarc@sac.sfbay.sun.com Subject: Re: 2006/407 [TCP|UDP]_EXCLBIND Stability Change In-Reply-To: <449A84A5.3010900@sun.com> References: <17562.32566.617112.281658@gargle.gargle.HOWL> <200606221144.k5MBiXNs014471@vaticaan.holland.sun.com> <449A84A5.3010900@sun.com> Date: Thu, 22 Jun 2006 13:56:47 +0200 Sender: casper@holland.sun.com Status: RO Content-Length: 485 >Casper.Dik@Sun.COM wrote: > >> I seem to remember there was some issue with IPv4 vs IPv6. >> >> If I understand correctly, exclusively binding to port ipv4 X prevents >> both IPV6/IPV4 reuses? > > >Yes, because there is also the IPv4/IPv6 port stealing issue. >I've talked about this issue in the following thread > >http://www.opensolaris.org/jive/thread.jspa?messageID=15541㲵 I seem to remember that that didn't work all that well; I guess I need to revisit that. Casper From sacadmin Thu Jun 22 04:58:20 2006 Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k5MBwKHL012307 for ; Thu, 22 Jun 2006 04:58:20 -0700 (PDT) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id k5MBxEl3009955; Thu, 22 Jun 2006 07:59:14 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.13.6+Sun/8.13.6/Submit) id k5MBxDD5009952; Thu, 22 Jun 2006 07:59:13 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17562.34320.901092.728905@gargle.gargle.HOWL> Date: Thu, 22 Jun 2006 07:59:12 -0400 From: James Carlson To: Casper.Dik@sun.com Cc: psarc@sac.sfbay.sun.com, kacheong.poon@sun.com Subject: Re: 2006/407 [TCP|UDP]_EXCLBIND Stability Change In-Reply-To: Casper.Dik@Sun.COM's message of 22 June 2006 13:44:33 References: <17562.32566.617112.281658@gargle.gargle.HOWL> <200606221144.k5MBiXNs014471@vaticaan.holland.sun.com> X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 646 Casper.Dik@Sun.COM writes: > I seem to remember there was some issue with IPv4 vs IPv6. > > If I understand correctly, exclusively binding to port ipv4 X prevents > both IPV6/IPV4 reuses? Yes, that's exactly what it does. As documented in the case materials: + enabling and disabling the option respectively. Once this + option is enabled on a socket, no other socket can be bound + to the same port. -- James Carlson, KISS Network Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From sacadmin Thu Jun 22 05:20:17 2006 Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k5MCKGB2012413 for ; Thu, 22 Jun 2006 05:20:17 -0700 (PDT) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id k5MCLBXN010012; Thu, 22 Jun 2006 08:21:11 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.13.6+Sun/8.13.6/Submit) id k5MCLA91010009; Thu, 22 Jun 2006 08:21:10 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17562.35635.552554.363626@gargle.gargle.HOWL> Date: Thu, 22 Jun 2006 08:21:07 -0400 From: James Carlson To: psarc@sac.sfbay.sun.com cc: kacheong.poon@sun.com Subject: Re: 2006/407 [TCP|UDP]_EXCLBIND Stability Change In-Reply-To: James Carlson's message of 22 June 2006 07:29:58 References: <17562.32566.617112.281658@gargle.gargle.HOWL> X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 543 James Carlson writes: > I'm sponsoring this case for Kacheong Poon. I believe it's obvious > enough to qualify for self review, so I've marked it "closed approved > automatic." Please speak up if you disagree. Since Casper spoke up with a concern, I've converted this into a fast-track with timer set to 06/29/2006. -- James Carlson, KISS Network Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From sacadmin Thu Jun 22 05:25:32 2006 Received: from sunnl.holland.sun.com (sunnl.Holland.Sun.COM [129.159.201.1]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k5MCPV55012489 for ; Thu, 22 Jun 2006 05:25:31 -0700 (PDT) Received: from vaticaan.holland.sun.com (vaticaan [129.159.201.10]) by sunnl.holland.sun.com (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k5MCPRGZ016466; Thu, 22 Jun 2006 14:25:28 +0200 (MEST) Received: from holland (casper@room101 [129.159.201.52]) by vaticaan.holland.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k5MCPRJ9020186; Thu, 22 Jun 2006 14:25:27 +0200 (MEST) Message-Id: <200606221225.k5MCPRJ9020186@vaticaan.holland.sun.com> From: Casper.Dik@sun.com To: James Carlson cc: psarc@sac.sfbay.sun.com, kacheong.poon@sun.com Subject: Re: 2006/407 [TCP|UDP]_EXCLBIND Stability Change In-Reply-To: <17562.35635.552554.363626@gargle.gargle.HOWL> References: <17562.32566.617112.281658@gargle.gargle.HOWL> <17562.35635.552554.363626@gargle.gargle.HOWL> Date: Thu, 22 Jun 2006 14:25:27 +0200 Sender: casper@holland.sun.com Status: RO Content-Length: 416 >James Carlson writes: >> I'm sponsoring this case for Kacheong Poon. I believe it's obvious >> enough to qualify for self review, so I've marked it "closed approved >> automatic." Please speak up if you disagree. > >Since Casper spoke up with a concern, I've converted this into a >fast-track with timer set to 06/29/2006. My concern only applies to the implementation; not the specification, it seems. Casper From sacadmin Thu Jun 22 05:36:07 2006 Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k5MCa6Ih012535 for ; Thu, 22 Jun 2006 05:36:07 -0700 (PDT) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id k5MCb192010060; Thu, 22 Jun 2006 08:37:01 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.13.6+Sun/8.13.6/Submit) id k5MCb0o5010057; Thu, 22 Jun 2006 08:37:00 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17562.36587.76582.261370@gargle.gargle.HOWL> Date: Thu, 22 Jun 2006 08:36:59 -0400 From: James Carlson To: Casper.Dik@sun.com Cc: psarc@sac.sfbay.sun.com, kacheong.poon@sun.com Subject: Re: 2006/407 [TCP|UDP]_EXCLBIND Stability Change In-Reply-To: Casper.Dik@Sun.COM's message of 22 June 2006 14:25:27 References: <17562.32566.617112.281658@gargle.gargle.HOWL> <17562.35635.552554.363626@gargle.gargle.HOWL> <200606221225.k5MCPRJ9020186@vaticaan.holland.sun.com> X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 965 Casper.Dik@Sun.COM writes: > >Since Casper spoke up with a concern, I've converted this into a > >fast-track with timer set to 06/29/2006. > > My concern only applies to the implementation; not the specification, > it seems. If you're concerned that it won't operate as specified or that it can't be used to solve the problem intended, then let's clear that up before closing the case. Kacheong: can you explain some usages that'll make the issue clear? In particular, is it possible for me to have an application with a separate v4 and v6-only binding to the same port? Or am I condemned to using the v4-over-v6-socket compatibility mode with a single binding if I enable this option? (If it's the latter, then we may have a problem.) -- James Carlson, KISS Network Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From sacadmin Thu Jun 22 05:38:22 2006 Received: from sunnl.holland.sun.com (sunnl.Holland.Sun.COM [129.159.201.1]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k5MCcLDL012569 for ; Thu, 22 Jun 2006 05:38:22 -0700 (PDT) Received: from vaticaan.holland.sun.com (vaticaan [129.159.201.10]) by sunnl.holland.sun.com (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k5MCcI80023332; Thu, 22 Jun 2006 14:38:18 +0200 (MEST) Received: from holland (casper@room101 [129.159.201.52]) by vaticaan.holland.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k5MCcIj8022122; Thu, 22 Jun 2006 14:38:18 +0200 (MEST) Message-Id: <200606221238.k5MCcIj8022122@vaticaan.holland.sun.com> From: Casper.Dik@sun.com To: James Carlson cc: psarc@sac.sfbay.sun.com, kacheong.poon@sun.com Subject: Re: 2006/407 [TCP|UDP]_EXCLBIND Stability Change In-Reply-To: <17562.36587.76582.261370@gargle.gargle.HOWL> References: <17562.32566.617112.281658@gargle.gargle.HOWL> <17562.35635.552554.363626@gargle.gargle.HOWL> <200606221225.k5MCPRJ9020186@vaticaan.holland.sun.com> <17562.36587.76582.261370@gargle.gargle.HOWL> Date: Thu, 22 Jun 2006 14:38:18 +0200 Sender: casper@holland.sun.com Status: RO Content-Length: 828 >Casper.Dik@Sun.COM writes: >> >Since Casper spoke up with a concern, I've converted this into a >> >fast-track with timer set to 06/29/2006. >> >> My concern only applies to the implementation; not the specification, >> it seems. > >If you're concerned that it won't operate as specified or that it >can't be used to solve the problem intended, then let's clear that up >before closing the case. > >Kacheong: can you explain some usages that'll make the issue clear? >In particular, is it possible for me to have an application with a >separate v4 and v6-only binding to the same port? Or am I condemned >to using the v4-over-v6-socket compatibility mode with a single >binding if I enable this option? > >(If it's the latter, then we may have a problem.) You can always bind both first and then call TCP_EXCLBIND. Casper From sacadmin Thu Jun 22 05:41:36 2006 Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k5MCfasR012610 for ; Thu, 22 Jun 2006 05:41:36 -0700 (PDT) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id k5MCgUB7010081; Thu, 22 Jun 2006 08:42:30 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.13.6+Sun/8.13.6/Submit) id k5MCgU8x010078; Thu, 22 Jun 2006 08:42:30 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17562.36918.89473.620954@gargle.gargle.HOWL> Date: Thu, 22 Jun 2006 08:42:30 -0400 From: James Carlson To: Casper.Dik@sun.com Cc: psarc@sac.sfbay.sun.com, kacheong.poon@sun.com Subject: Re: 2006/407 [TCP|UDP]_EXCLBIND Stability Change In-Reply-To: Casper.Dik@Sun.COM's message of 22 June 2006 14:38:18 References: <17562.32566.617112.281658@gargle.gargle.HOWL> <17562.35635.552554.363626@gargle.gargle.HOWL> <200606221225.k5MCPRJ9020186@vaticaan.holland.sun.com> <17562.36587.76582.261370@gargle.gargle.HOWL> <200606221238.k5MCcIj8022122@vaticaan.holland.sun.com> X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 394 Casper.Dik@Sun.COM writes: > >(If it's the latter, then we may have a problem.) > > You can always bind both first and then call TCP_EXCLBIND. But is that the concern? -- James Carlson, KISS Network Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From sacadmin Thu Jun 22 06:13:13 2006 Received: from localhost.east.sun.com (punchin-sommerfeld.East.Sun.COM [129.148.19.3]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k5MDDC6J015725 for ; Thu, 22 Jun 2006 06:13:13 -0700 (PDT) Received: from localhost.east.sun.com (localhost [127.0.0.1]) by localhost.east.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k5MDD1Ne111651; Thu, 22 Jun 2006 13:13:01 GMT Received: (from sommerfeld@localhost) by localhost.east.sun.com (8.13.6+Sun/8.13.6/Submit) id k5MDD0YO111650; Thu, 22 Jun 2006 09:13:00 -0400 (EDT) X-Authentication-Warning: localhost.east.sun.com: sommerfeld set sender to sommerfeld@sun.com using -f Subject: Re: 2006/407 [TCP|UDP]_EXCLBIND Stability Change From: Bill Sommerfeld To: James Carlson Cc: psarc@sac.sfbay.sun.com, Kacheong Poon In-Reply-To: <17562.32566.617112.281658@gargle.gargle.HOWL> References: <17562.32566.617112.281658@gargle.gargle.HOWL> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1150981980.111197.49.camel@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.340 Date: Thu, 22 Jun 2006 09:13:00 -0400 Status: RO Content-Length: 1465 On Thu, 2006-06-22 at 07:29, James Carlson wrote: > The Consolidation Private socket options [TCP|UDP]_EXCLBIND > were introduced in PSARC 1999/609, "Exclusive Binding Socket > Option for TCP and UDP." At that time, there was an urgent > need to fix a security issue, port stealing, in RPC. The > options were introduced so that the RPC code could use it to > bind a port exclusively, hence no port stealing could happen. > But it was not clear whether this solution had some unwanted > side effects. So the options were marked as Consolidation > Private. I have two interlocking concerns: 1) SCTP has ports, just like TCP and UDP; if we're going to raise the commitment level, why do we need this for TCP and UDP but not for SCTP? 2) I simply don't buy the argument in the case log of 1999/609 that it's inappropriate to express this as "SO_EXCLBIND" because only UDP and TCP have ports instead of requiring one socket option per transport. For what it's worth, BSD also has SO_REUSEPORT as a generic socket option; moreover, even if a protocol doesn't use something called a "port" to specify a particular transport-layer endpoint, SO_EXCLBIND semantics may still be useful; all that requires is that the protocol permit a node to have multiple addresses and have some way to bind to either one of these addresses or all of them. Since this case proposes to promote a private interface, now's as good a time as any to revisit this. - Bill From sacadmin Thu Jun 22 06:50:01 2006 Received: from sunnl.holland.sun.com (sunnl.Holland.Sun.COM [129.159.201.1]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k5MDo05X016654 for ; Thu, 22 Jun 2006 06:50:00 -0700 (PDT) Received: from vaticaan.holland.sun.com (vaticaan [129.159.201.10]) by sunnl.holland.sun.com (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k5MDnu5Q028521; Thu, 22 Jun 2006 15:49:56 +0200 (MEST) Received: from holland (casper@room101 [129.159.201.52]) by vaticaan.holland.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k5MDnuEe005365; Thu, 22 Jun 2006 15:49:56 +0200 (MEST) Message-Id: <200606221349.k5MDnuEe005365@vaticaan.holland.sun.com> From: Casper.Dik@sun.com To: Bill Sommerfeld cc: James Carlson , psarc@sac.sfbay.sun.com, Kacheong Poon Subject: Re: 2006/407 [TCP|UDP]_EXCLBIND Stability Change In-Reply-To: <1150981980.111197.49.camel@localhost> References: <17562.32566.617112.281658@gargle.gargle.HOWL> <1150981980.111197.49.camel@localhost> Date: Thu, 22 Jun 2006 15:49:55 +0200 Sender: casper@holland.sun.com Status: RO Content-Length: 962 > 2) I simply don't buy the argument in the case log of 1999/609 that >it's inappropriate to express this as "SO_EXCLBIND" because only UDP and >TCP have ports instead of requiring one socket option per transport. Quite; the same reasoning could be applied to: SO_LINGER - only applies to connection oriented SO_BROADCAST - only for dgrams SO_DGRAM_ERRIND - only for dgrams >For what it's worth, BSD also has SO_REUSEPORT as a generic socket >option; >moreover, even if a protocol doesn't use something called a "port" to >specify a particular transport-layer endpoint, SO_EXCLBIND semantics >may still be useful; all that requires is that the protocol permit a >node to have multiple addresses and have some way to bind to either one >of these addresses or all of them. > >Since this case proposes to promote a private interface, now's as good a >time as any to revisit this. Yes; this seems like an appropriate change in the architecture. Casper From sacadmin Thu Jun 22 07:53:08 2006 Received: from phys-d3-ha21sca-1 (phys-d3-ha21sca-1.SFBay.Sun.COM [129.145.155.163]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k5MEr8uj019339 for ; Thu, 22 Jun 2006 07:53:08 -0700 (PDT) Received: from conversion-daemon.ha21sca-mail1.sfbay.sun.com by ha21sca-mail1.sfbay.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0J1900301NPO7X@ha21sca-mail1.sfbay.sun.com> (original mail from alan.coopersmith@sun.com) for psarc@sac.sfbay.sun.com; Thu, 22 Jun 2006 07:53:08 -0700 (PDT) Received: from [192.168.0.101] (vpn-sfbay-net-23.SFBay.Sun.COM [129.150.23.0]) by ha21sca-mail1.sfbay.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTP id <0J1900HV3O0JX4@ha21sca-mail1.sfbay.sun.com>; Thu, 22 Jun 2006 07:53:08 -0700 (PDT) Date: Thu, 22 Jun 2006 07:53:01 -0700 From: Alan Coopersmith Subject: Re: 2006/407 [TCP|UDP]_EXCLBIND Stability Change In-reply-to: <17562.32566.617112.281658@gargle.gargle.HOWL> To: James Carlson Cc: psarc@sac.sfbay.sun.com, kacheong.poon@sun.com Message-id: <449AAECD.7080008@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT User-Agent: Thunderbird 1.5.0.4 (X11/20060602) References: <17562.32566.617112.281658@gargle.gargle.HOWL> Status: RO Content-Length: 764 James Carlson wrote: > + enabling and disabling the option respectively. Once this > + option is enabled on a socket, no other socket can be bound > + to the same port. Until when? the machine reboots? Is there any way for another program to undo this? (We tried this in Xsun a couple of years ago, but had to quickly reject, because when the X server restarted it was locked out of the socket by the TCP_EXCLBIND set by the previous X server which was no longer running. Since we don't want to lock users out when the server is killed or crashes without having a chance to clean up, we found that TCP_EXCLBIND was unusable.) -- -Alan Coopersmith- alan.coopersmith@sun.com Sun Microsystems, Inc. - X Window System Engineering From sacadmin Thu Jun 22 07:57:57 2006 Received: from sunnl.holland.sun.com (sunnl.Holland.Sun.COM [129.159.201.1]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k5MEvuSL020015 for ; Thu, 22 Jun 2006 07:57:56 -0700 (PDT) Received: from vaticaan.holland.sun.com (vaticaan [129.159.201.10]) by sunnl.holland.sun.com (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k5MEvpOn004342; Thu, 22 Jun 2006 16:57:51 +0200 (MEST) Received: from holland (casper@room101 [129.159.201.52]) by vaticaan.holland.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k5MEvp7r017270; Thu, 22 Jun 2006 16:57:51 +0200 (MEST) Message-Id: <200606221457.k5MEvp7r017270@vaticaan.holland.sun.com> From: Casper.Dik@sun.com To: Alan Coopersmith cc: James Carlson , psarc@sac.sfbay.sun.com, kacheong.poon@sun.com Subject: Re: 2006/407 [TCP|UDP]_EXCLBIND Stability Change In-Reply-To: <449AAECD.7080008@sun.com> References: <17562.32566.617112.281658@gargle.gargle.HOWL> <449AAECD.7080008@sun.com> Date: Thu, 22 Jun 2006 16:57:51 +0200 Sender: casper@holland.sun.com Status: RO Content-Length: 805 >James Carlson wrote: >> + enabling and disabling the option respectively. Once this >> + option is enabled on a socket, no other socket can be bound >> + to the same port. > >Until when? the machine reboots? Is there any way for another program >to undo this? (We tried this in Xsun a couple of years ago, but had to >quickly reject, because when the X server restarted it was locked out of >the socket by the TCP_EXCLBIND set by the previous X server which was no >longer running. Since we don't want to lock users out when the server >is killed or crashes without having a chance to clean up, we found that >TCP_EXCLBIND was unusable.) It is kinda strange but is this perhaps caused by TIME_WAIT (I'm assuming you are also using REUSEADDR?) I remember the issue well. Casper From sacadmin Thu Jun 22 08:00:42 2006 Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k5MF0fYZ020107 for ; Thu, 22 Jun 2006 08:00:42 -0700 (PDT) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id k5MF1afZ011135; Thu, 22 Jun 2006 11:01:37 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.13.6+Sun/8.13.6/Submit) id k5MF1Y46011124; Thu, 22 Jun 2006 11:01:34 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17562.45260.795904.607470@gargle.gargle.HOWL> Date: Thu, 22 Jun 2006 11:01:32 -0400 From: James Carlson To: Alan Coopersmith Cc: psarc@sac.sfbay.sun.com, kacheong.poon@sun.com Subject: Re: 2006/407 [TCP|UDP]_EXCLBIND Stability Change In-Reply-To: Alan Coopersmith's message of 22 June 2006 07:53:01 References: <17562.32566.617112.281658@gargle.gargle.HOWL> <449AAECD.7080008@sun.com> X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 1081 Alan Coopersmith writes: > James Carlson wrote: > > + enabling and disabling the option respectively. Once this > > + option is enabled on a socket, no other socket can be bound > > + to the same port. > > Until when? the machine reboots? No, until the socket holding the port is closed. > Is there any way for another program > to undo this? No. Intentionally not. It's a security issue. > (We tried this in Xsun a couple of years ago, but had to > quickly reject, because when the X server restarted it was locked out of > the socket by the TCP_EXCLBIND set by the previous X server which was no > longer running. Since we don't want to lock users out when the server > is killed or crashes without having a chance to clean up, we found that > TCP_EXCLBIND was unusable.) Kacheong: TIME-WAIT doesn't factor in here, does it? -- James Carlson, KISS Network Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From sacadmin Thu Jun 22 08:27:31 2006 Received: from phys-d3-ha21sca-1 (phys-d3-ha21sca-1.SFBay.Sun.COM [129.145.155.163]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k5MFRVtl020441 for ; Thu, 22 Jun 2006 08:27:31 -0700 (PDT) Received: from conversion-daemon.ha21sca-mail1.sfbay.sun.com by ha21sca-mail1.sfbay.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0J1900401P3PD8@ha21sca-mail1.sfbay.sun.com> (original mail from alan.coopersmith@sun.com) for psarc@sac.sfbay.sun.com; Thu, 22 Jun 2006 08:27:31 -0700 (PDT) Received: from [192.168.0.101] (vpn-sfbay-net-23.SFBay.Sun.COM [129.150.23.0]) by ha21sca-mail1.sfbay.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTP id <0J1900H8HPLTX4@ha21sca-mail1.sfbay.sun.com>; Thu, 22 Jun 2006 08:27:31 -0700 (PDT) Date: Thu, 22 Jun 2006 08:27:24 -0700 From: Alan Coopersmith Subject: Re: 2006/407 [TCP|UDP]_EXCLBIND Stability Change In-reply-to: <17562.45260.795904.607470@gargle.gargle.HOWL> To: James Carlson Cc: psarc@sac.sfbay.sun.com, kacheong.poon@sun.com Message-id: <449AB6DC.6040409@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT User-Agent: Thunderbird 1.5.0.4 (X11/20060602) References: <17562.32566.617112.281658@gargle.gargle.HOWL> <449AAECD.7080008@sun.com> <17562.45260.795904.607470@gargle.gargle.HOWL> Status: RO Content-Length: 402 James Carlson wrote: >> Is there any way for another program >> to undo this? > > No. Intentionally not. It's a security issue. I understand normal programs not being able to undo it, but I was thinking of a program with extra privilege being able to undo it for cleanup purposes. -- -Alan Coopersmith- alan.coopersmith@sun.com Sun Microsystems, Inc. - X Window System Engineering From sacadmin Thu Jun 22 09:50:29 2006 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.17.57]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k5MGoSHx022456 for ; Thu, 22 Jun 2006 09:50:29 -0700 (PDT) Received: from [192.9.61.50] (punchin-kcpoon.SFBay.Sun.COM [192.9.61.50]) by jurassic.eng.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k5MGoQ9L976849 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Thu, 22 Jun 2006 09:50:28 -0700 (PDT) Message-ID: <449ACA51.20909@sun.com> Date: Fri, 23 Jun 2006 00:50:25 +0800 From: Kacheong Poon Organization: Sun Microsystems, Inc. User-Agent: Thunderbird 1.5.0.4 (X11/20060602) MIME-Version: 1.0 To: psarc@sac.sfbay.sun.com Subject: Re: 2006/407 [TCP|UDP]_EXCLBIND Stability Change References: <17562.32566.617112.281658@gargle.gargle.HOWL> <17562.35635.552554.363626@gargle.gargle.HOWL> <200606221225.k5MCPRJ9020186@vaticaan.holland.sun.com> <17562.36587.76582.261370@gargle.gargle.HOWL> In-Reply-To: <17562.36587.76582.261370@gargle.gargle.HOWL> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Status: RO Content-Length: 833 James Carlson wrote: > Kacheong: can you explain some usages that'll make the issue clear? > In particular, is it possible for me to have an application with a > separate v4 and v6-only binding to the same port? Or am I condemned > to using the v4-over-v6-socket compatibility mode with a single > binding if I enable this option? No, the v4 and v6 sockets using the unspecified address binding to the same port cannot coexist if one of the socket has this option enabled. But it can succeed if the option is enabled after the bind. Note also that with the current implementation of IPV6_V6ONLY socket option, there is really no such thing as v6-only bind as the option can be set/unset anytime without any restriction. So any check depending on this option is not reliable. -- K. Poon. kacheong.poon@sun.com From sacadmin Thu Jun 22 09:54:33 2006 Received: from phys-d3-ha21sca-1 (phys-d3-ha21sca-1.SFBay.Sun.COM [129.145.155.163]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k5MGsXU1022835 for ; Thu, 22 Jun 2006 09:54:33 -0700 (PDT) Received: from conversion-daemon.ha21sca-mail1.sfbay.sun.com by ha21sca-mail1.sfbay.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0J1900801TCJD7@ha21sca-mail1.sfbay.sun.com> (original mail from alan.coopersmith@sun.com) for psarc@sac.sfbay.sun.com; Thu, 22 Jun 2006 09:54:33 -0700 (PDT) Received: from [192.168.0.101] (vpn-129-150-20-127.SFBay.Sun.COM [129.150.20.127]) by ha21sca-mail1.sfbay.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTP id <0J1900HVQTMWX4@ha21sca-mail1.sfbay.sun.com>; Thu, 22 Jun 2006 09:54:33 -0700 (PDT) Date: Thu, 22 Jun 2006 09:54:28 -0700 From: Alan Coopersmith Subject: Re: 2006/407 [TCP|UDP]_EXCLBIND Stability Change In-reply-to: <200606221457.k5MEvp7r017270@vaticaan.holland.sun.com> To: Casper.Dik@sun.com Cc: James Carlson , psarc@sac.sfbay.sun.com, kacheong.poon@sun.com Message-id: <449ACB44.3030406@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT User-Agent: Thunderbird 1.5.0.4 (X11/20060602) References: <17562.32566.617112.281658@gargle.gargle.HOWL> <449AAECD.7080008@sun.com> <200606221457.k5MEvp7r017270@vaticaan.holland.sun.com> Status: RO Content-Length: 336 Casper.Dik@Sun.COM wrote: > It is kinda strange but is this perhaps caused by TIME_WAIT (I'm assuming > you are also using REUSEADDR?) Yes - the TCP_EXCLBIND setting was added immediately after the SO_REUSEADDR setting. -- -Alan Coopersmith- alan.coopersmith@sun.com Sun Microsystems, Inc. - X Window System Engineering From sacadmin Thu Jun 22 10:08:08 2006 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.224.130]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k5MH87G0023392 for ; Thu, 22 Jun 2006 10:08:08 -0700 (PDT) Received: from [192.9.61.50] (punchin-kcpoon.SFBay.Sun.COM [192.9.61.50]) by jurassic.eng.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k5MH85AK991256 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Thu, 22 Jun 2006 10:08:07 -0700 (PDT) Message-ID: <449ACE74.9040905@sun.com> Date: Fri, 23 Jun 2006 01:08:04 +0800 From: Kacheong Poon Organization: Sun Microsystems, Inc. User-Agent: Thunderbird 1.5.0.4 (X11/20060602) MIME-Version: 1.0 To: psarc@sac.sfbay.sun.com Subject: Re: 2006/407 [TCP|UDP]_EXCLBIND Stability Change References: <17562.32566.617112.281658@gargle.gargle.HOWL> <1150981980.111197.49.camel@localhost> In-Reply-To: <1150981980.111197.49.camel@localhost> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Status: RO Content-Length: 1444 Bill Sommerfeld wrote: > I have two interlocking concerns: > 1) SCTP has ports, just like TCP and UDP; if we're going to raise the > commitment level, why do we need this for TCP and UDP but not for SCTP? SCTP did not exist back then :-) In our current SCTP implementation, I think we don't have the port stealing issue. > 2) I simply don't buy the argument in the case log of 1999/609 that > it's inappropriate to express this as "SO_EXCLBIND" because only UDP and > TCP have ports instead of requiring one socket option per transport. > > For what it's worth, BSD also has SO_REUSEPORT as a generic socket > option; > moreover, even if a protocol doesn't use something called a "port" to > specify a particular transport-layer endpoint, SO_EXCLBIND semantics > may still be useful; all that requires is that the protocol permit a > node to have multiple addresses and have some way to bind to either one > of these addresses or all of them. FWIW, the protocol specific options were suggested by our socket standard expert back then. In fact, the point was that things like SO_KEEPALIVE were simple mistakes made by BSD folks. There was no good reason to follow the same naming mistake. > Since this case proposes to promote a private interface, now's as good a > time as any to revisit this. If enough people are happier with a SO_EXCLBIND instead, I can make it happen. -- K. Poon. kacheong.poon@sun.com From sacadmin Thu Jun 22 10:16:47 2006 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.226.130]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k5MHGlVJ023524 for ; Thu, 22 Jun 2006 10:16:47 -0700 (PDT) Received: from [192.9.61.50] (punchin-kcpoon.SFBay.Sun.COM [192.9.61.50]) by jurassic.eng.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k5MHGign999061 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Thu, 22 Jun 2006 10:16:46 -0700 (PDT) Message-ID: <449AD07C.3050808@sun.com> Date: Fri, 23 Jun 2006 01:16:44 +0800 From: Kacheong Poon Organization: Sun Microsystems, Inc. User-Agent: Thunderbird 1.5.0.4 (X11/20060602) MIME-Version: 1.0 To: psarc@sac.sfbay.sun.com Subject: Re: 2006/407 [TCP|UDP]_EXCLBIND Stability Change References: <17562.32566.617112.281658@gargle.gargle.HOWL> <449AAECD.7080008@sun.com> <17562.45260.795904.607470@gargle.gargle.HOWL> In-Reply-To: <17562.45260.795904.607470@gargle.gargle.HOWL> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Status: RO Content-Length: 729 James Carlson wrote: >> (We tried this in Xsun a couple of years ago, but had to >> quickly reject, because when the X server restarted it was locked out of >> the socket by the TCP_EXCLBIND set by the previous X server which was no >> longer running. Since we don't want to lock users out when the server >> is killed or crashes without having a chance to clean up, we found that >> TCP_EXCLBIND was unusable.) > > Kacheong: TIME-WAIT doesn't factor in here, does it? I wished the X server team had told us about this when they tried it... TIME-WAIT does matter here as the bit is not unset when a TCP connection goes into TIME-WAIT state. I think this can be fixed. -- K. Poon. kacheong.poon@sun.com From sacadmin Thu Jun 22 10:19:37 2006 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.17.57]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k5MHJbtb023561 for ; Thu, 22 Jun 2006 10:19:37 -0700 (PDT) Received: from [192.9.61.50] (punchin-kcpoon.SFBay.Sun.COM [192.9.61.50]) by jurassic.eng.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k5MHJYEk103803 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Thu, 22 Jun 2006 10:19:36 -0700 (PDT) Message-ID: <449AD125.7010801@sun.com> Date: Fri, 23 Jun 2006 01:19:33 +0800 From: Kacheong Poon Organization: Sun Microsystems, Inc. User-Agent: Thunderbird 1.5.0.4 (X11/20060602) MIME-Version: 1.0 To: psarc@sac.sfbay.sun.com Subject: Re: 2006/407 [TCP|UDP]_EXCLBIND Stability Change References: <17562.32566.617112.281658@gargle.gargle.HOWL> <449AAECD.7080008@sun.com> <17562.45260.795904.607470@gargle.gargle.HOWL> <449AB6DC.6040409@sun.com> In-Reply-To: <449AB6DC.6040409@sun.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Status: RO Content-Length: 419 Alan Coopersmith wrote: > I understand normal programs not being able to undo it, but I was thinking > of a program with extra privilege being able to undo it for cleanup > purposes. I think if the bit is clear when a TCP connection goes into TIME-WAIT state, it should work for the X server case. I can work with Alan off line on a test about this with X server. -- K. Poon. kacheong.poon@sun.com From sacadmin Thu Jun 22 10:33:41 2006 Received: from sunnl.holland.sun.com (sunnl.Holland.Sun.COM [129.159.201.1]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k5MHXeeZ023975 for ; Thu, 22 Jun 2006 10:33:41 -0700 (PDT) Received: from vaticaan.holland.sun.com (vaticaan [129.159.201.10]) by sunnl.holland.sun.com (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k5MHXcFW024511; Thu, 22 Jun 2006 19:33:38 +0200 (MEST) Received: from holland (casper@room101 [129.159.201.52]) by vaticaan.holland.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k5MHXbiO000703; Thu, 22 Jun 2006 19:33:37 +0200 (MEST) Message-Id: <200606221733.k5MHXbiO000703@vaticaan.holland.sun.com> From: Casper.Dik@sun.com To: Kacheong Poon cc: psarc@sac.sfbay.sun.com Subject: Re: 2006/407 [TCP|UDP]_EXCLBIND Stability Change In-Reply-To: <449AD07C.3050808@sun.com> References: <17562.32566.617112.281658@gargle.gargle.HOWL> <449AAECD.7080008@sun.com> <17562.45260.795904.607470@gargle.gargle.HOWL> <449AD07C.3050808@sun.com> Date: Thu, 22 Jun 2006 19:33:37 +0200 Sender: casper@holland.sun.com Status: RO Content-Length: 353 >I wished the X server team had told us about this when >they tried it... > >TIME-WAIT does matter here as the bit is not unset when a TCP >connection goes into TIME-WAIT state. I think this can be >fixed. Should this bit be unset for all sockets which cannot go into listen state? (Not for the accepted sockets, not for connected sockets) Casper From sacadmin Thu Jun 22 10:52:17 2006 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.104.31]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k5MHqHvq024235 for ; Thu, 22 Jun 2006 10:52:17 -0700 (PDT) Received: from [192.9.61.50] (punchin-kcpoon.SFBay.Sun.COM [192.9.61.50]) by jurassic.eng.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k5MHqETj157197 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Thu, 22 Jun 2006 10:52:16 -0700 (PDT) Message-ID: <449AD8CE.6090308@sun.com> Date: Fri, 23 Jun 2006 01:52:14 +0800 From: Kacheong Poon Organization: Sun Microsystems, Inc. User-Agent: Thunderbird 1.5.0.4 (X11/20060602) MIME-Version: 1.0 To: psarc@sac.sfbay.sun.com Subject: Re: 2006/407 [TCP|UDP]_EXCLBIND Stability Change References: <17562.32566.617112.281658@gargle.gargle.HOWL> <449AAECD.7080008@sun.com> <17562.45260.795904.607470@gargle.gargle.HOWL> <449AD07C.3050808@sun.com> <200606221733.k5MHXbiO000703@vaticaan.holland.sun.com> In-Reply-To: <200606221733.k5MHXbiO000703@vaticaan.holland.sun.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Status: RO Content-Length: 568 Casper.Dik@sun.com wrote: > Should this bit be unset for all sockets which cannot go > into listen state? (Not for the accepted sockets, not for connected > sockets) Ideally, I guess yes. But the interesting TLI "going back" semantics (an endpoint can go back from, say TCP_ESTABLISHED to TCPS_LISTEN or TCPS_BOUND) means that if we do this, we need to also remember to set the bit again when the endpoint goes back. What is benefit if we do the above? I don't think not clearing the bit will cause a problem. -- K. Poon. kacheong.poon@sun.com From sacadmin Thu Jun 22 11:17:30 2006 Received: from sunnl.holland.sun.com (sunnl.Holland.Sun.COM [129.159.201.1]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k5MIHTj6025369 for ; Thu, 22 Jun 2006 11:17:30 -0700 (PDT) Received: from vaticaan.holland.sun.com (vaticaan [129.159.201.10]) by sunnl.holland.sun.com (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k5MIHRn3016010; Thu, 22 Jun 2006 20:17:27 +0200 (MEST) Received: from holland (casper@room101 [129.159.201.52]) by vaticaan.holland.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k5MIHRmB003257; Thu, 22 Jun 2006 20:17:27 +0200 (MEST) Message-Id: <200606221817.k5MIHRmB003257@vaticaan.holland.sun.com> From: Casper.Dik@sun.com To: Kacheong Poon cc: psarc@sac.sfbay.sun.com Subject: Re: 2006/407 [TCP|UDP]_EXCLBIND Stability Change In-Reply-To: <449AD8CE.6090308@sun.com> References: <17562.32566.617112.281658@gargle.gargle.HOWL> <449AAECD.7080008@sun.com> <17562.45260.795904.607470@gargle.gargle.HOWL> <449AD07C.3050808@sun.com> <200606221733.k5MHXbiO000703@vaticaan.holland.sun.com> <449AD8CE.6090308@sun.com> Date: Thu, 22 Jun 2006 20:17:27 +0200 Sender: casper@holland.sun.com Status: RO Content-Length: 232 >What is benefit if we do the above? I don't think >not clearing the bit will cause a problem. Except for time_wait connections. I think we addressed the "go back" semantics for sockets (they no longer work but used to) Casper From sacadmin Fri Jun 23 01:47:38 2006 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.17.57]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k5N8lcbC016627 for ; Fri, 23 Jun 2006 01:47:38 -0700 (PDT) Received: from [192.9.61.50] (punchin-kcpoon.SFBay.Sun.COM [192.9.61.50]) by jurassic.eng.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k5N8lan1391440 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Fri, 23 Jun 2006 01:47:38 -0700 (PDT) Message-ID: <449BAAA7.5010901@sun.com> Date: Fri, 23 Jun 2006 16:47:35 +0800 From: Kacheong Poon Organization: Sun Microsystems, Inc. User-Agent: Thunderbird 1.5.0.4 (X11/20060602) MIME-Version: 1.0 To: psarc@sac.sfbay.sun.com Subject: Re: 2006/407 [TCP|UDP]_EXCLBIND Stability Change References: <17562.32566.617112.281658@gargle.gargle.HOWL> <449AAECD.7080008@sun.com> <17562.45260.795904.607470@gargle.gargle.HOWL> <449AD07C.3050808@sun.com> <200606221733.k5MHXbiO000703@vaticaan.holland.sun.com> <449AD8CE.6090308@sun.com> <200606221817.k5MIHRmB003257@vaticaan.holland.sun.com> In-Reply-To: <200606221817.k5MIHRmB003257@vaticaan.holland.sun.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Status: RO Content-Length: 95 I've filed 6442609 for the TIME-WAIT issue. -- K. Poon. kacheong.poon@sun.com From sacadmin Fri Jun 23 05:41:54 2006 Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k5NCfsgR020953 for ; Fri, 23 Jun 2006 05:41:54 -0700 (PDT) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id k5NCgo7T014545; Fri, 23 Jun 2006 08:42:50 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.13.6+Sun/8.13.6/Submit) id k5NCgovZ014542; Fri, 23 Jun 2006 08:42:50 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17563.57802.390530.666247@gargle.gargle.HOWL> Date: Fri, 23 Jun 2006 08:42:50 -0400 From: James Carlson To: Kacheong Poon Cc: psarc@sac.sfbay.sun.com Subject: Re: 2006/407 [TCP|UDP]_EXCLBIND Stability Change In-Reply-To: Kacheong Poon's message of 23 June 2006 16:47:35 References: <17562.32566.617112.281658@gargle.gargle.HOWL> <449AAECD.7080008@sun.com> <17562.45260.795904.607470@gargle.gargle.HOWL> <449AD07C.3050808@sun.com> <200606221733.k5MHXbiO000703@vaticaan.holland.sun.com> <449AD8CE.6090308@sun.com> <200606221817.k5MIHRmB003257@vaticaan.holland.sun.com> <449BAAA7.5010901@sun.com> X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 529 Kacheong Poon writes: > I've filed 6442609 for the TIME-WAIT issue. Can we have an updated spec? In particular, are you changing to use SO_EXCLBIND as suggested (for what it's worth, I agree with Bill and the others on this, and I think having this per-transport wasn't right) or is the rest unchanged? -- James Carlson, KISS Network Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From sacadmin Mon Jun 26 00:12:27 2006 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.17.57]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k5Q7CQAH023643 for ; Mon, 26 Jun 2006 00:12:26 -0700 (PDT) Received: from [192.9.61.50] (punchin-kcpoon.SFBay.Sun.COM [192.9.61.50]) by jurassic.eng.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k5Q7COoR110299 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Mon, 26 Jun 2006 00:12:26 -0700 (PDT) Message-ID: <449F88D7.8060809@sun.com> Date: Mon, 26 Jun 2006 15:12:23 +0800 From: Kacheong Poon Organization: Sun Microsystems, Inc. User-Agent: Thunderbird 1.5.0.4 (X11/20060602) MIME-Version: 1.0 To: psarc@sac.sfbay.sun.com Subject: Re: 2006/407 [TCP|UDP]_EXCLBIND Stability Change References: <17562.32566.617112.281658@gargle.gargle.HOWL> <449AAECD.7080008@sun.com> <17562.45260.795904.607470@gargle.gargle.HOWL> <449AD07C.3050808@sun.com> <200606221733.k5MHXbiO000703@vaticaan.holland.sun.com> <449AD8CE.6090308@sun.com> <200606221817.k5MIHRmB003257@vaticaan.holland.sun.com> <449BAAA7.5010901@sun.com> <17563.57802.390530.666247@gargle.gargle.HOWL> In-Reply-To: <17563.57802.390530.666247@gargle.gargle.HOWL> Content-Type: multipart/mixed; boundary="------------080004090509090103090703" Status: RO Content-Length: 6980 This is a multi-part message in MIME format. --------------080004090509090103090703 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit James Carlson wrote: > Can we have an updated spec? In particular, are you changing to use > SO_EXCLBIND as suggested (for what it's worth, I agree with Bill and > the others on this, and I think having this per-transport wasn't > right) or is the rest unchanged? Updated spec attached. I didn't spell out the TIME-WAIT change as it is more of an implementation issue. -- K. Poon. kacheong.poon@sun.com --------------080004090509090103090703 Content-Type: text/plain; name="exclbind" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="exclbind" SO_EXCLBIND, socket exclusive binding This case requests a Patch/Micro release binding and Stability level is Committed. The Consolidation Private socket options [TCP|UDP]_EXCLBIND were introduced in PSARC 1999/609, "Exclusive Binding Socket Option for TCP and UDP." At that time, there was an urgent need to fix a security issue, port stealing, in RPC. The options were introduced so that the RPC code could use it to bind a port exclusively, hence no port stealing could happen. But it was not clear whether this solution had some unwanted side effects. So the options were marked as Consolidation Private. After so many years of experience, it seems that the options are a reasonable solution to the port stealing issue without adverse side effect. And there have been customers asking how they can solve the port stealing issue. This case introduces a new SOL_SOCKET level socket option, SO_EXCLBIND. The semantics of this socket option is dependent on the type of socket it is applied on. When enabled on a TCP and a UDP socket, this option is equivalent to TCP_EXCLBIND and UDP_EXCLBIND respectively. This case does not remove the [TCP|UDP]_EXCLBIND options so that existiing apps do not need to be changed. This case also does not define the semantics of this socket option when applied to other kinds of socket. The man pages of [set|get]sockopt(3SOCKET), tcp(7P) and udp(7P) will be modified as follows. Diff on [set|get]sockopt(3SOCKET) + SO_EXCLBIND enable/disable exlusive binding of the + socket + + + SO_TYPE get the type of the socket (get only) *************** *** 230,235 **** --- 235,247 ---- tamp in the native data format, corresponding to when the datagram was received. + The option SO_EXCLBIND option is used to enable/disable the + exclusive binding of a socket. It overrides the use of + SO_REUSEADDR option to reuse an address on bind(3SOCKET). + The actual semantics of this option depends on the underlying + protocol. Refer to the protocol man page for the protocol + specific meaning. + Finally, SO_TYPE and SO_ERROR are options used only with getsockopt(). SO_TYPE returns the type of the socket, for example, SOCK_STREAM. It is useful for servers that inherit *************** *** 355,362 **** SEE ALSO ndd(1M), close(2), ioctl(2), read(2), bind(3SOCKET), getprotobyname(3SOCKET), recv(3SOCKET), recvmsg(3XNET), ! send(3SOCKET), socket(3SOCKET), socket.h(3HEAD), attri- ! butes(5) Solaris Tunable Parameters Reference Manual --- 367,374 ---- SEE ALSO ndd(1M), close(2), ioctl(2), read(2), bind(3SOCKET), getprotobyname(3SOCKET), recv(3SOCKET), recvmsg(3XNET), ! send(3SOCKET), socket(3SOCKET), socket.h(3HEAD), udp(7P), ! tcp(7P), attributes(5) Solaris Tunable Parameters Reference Manual Diff on tcp(7P) at connection time to the address of the network interface used to service the connection. + A note about binding a TCP socket. No two TCP sockets can + be bound to the same port unless the bound IP addresses are + different. IPv4 INADDR_ANY and IPv6 unspecified addresses + compare as equal to any IPv4 or IPv6 address. For example, if a + socket is bound to INADDR_ANY or unspecified address and port X, + no other socket can bind to port X, regardless of the binding + address. This special consideration of INADDR_ANY and unspecified + address can be changed using the socket option SO_REUSEADDR. + If this option is set on a socket doing a bind, IPv4 INADDR_ANY + and IPv6 unspecified address do not compare as equal to any IP + address. This means that as long as the two sockets are not + both bound to INADDR_ANY/unspecified address or the same + IP address, the two sockets can be bound to the same port. + + If an application does not want to allow another socket + using the SO_REUSEADDR option to bind to a port its socket + is bound to, the application can set the socket level option + SO_EXCLBIND on a socket. The option values of 0 and 1 mean + enabling and disabling the option respectively. Once this + option is enabled on a socket, no other socket can be bound + to the same port. + Once a connection has been established, data can be exchanged using the read(2) and write(2) system calls. Diff on udp(7P) work interface dependent. Broadcasts may only be sent by the privileged user. + A note about binding a UDP socket. No two UDP sockets can + be bound to the same port unless the bound IP addresses are + different. IPv4 INADDR_ANY and IPv6 unspecified addresses + compare as equal to any IPv4 or IPv6 address. For example, if a + socket is bound to INADDR_ANY or unspecified address and port X, + no other socket can bind to port X, regardless of the binding + address. This special consideration of INADDR_ANY and unspecified + address can be changed using the socket option SO_REUSEADDR. + If this option is set on a socket doing a bind, IPv4 INADDR_ANY + and IPv6 unspecified address do not compare as equal to any IP + address. This means that as long as the two sockets are not + both bound to INADDR_ANY/unspecified address or the same + IP address, the two sockets can be bound to the same port. + + If an application does not want to allow another socket + using the SO_REUSEADDR option to bind to a port its socket + is bound to, the application can set the socket level option + SO_EXCLBIND on a socket. The option values of 0 and 1 mean + enabling and disabling the option respectively. Once this + option is enabled on a socket, no other socket can be bound + to the same port. + IPv6 does not support broadcast addresses; their function is supported by IPv6 multicast addresses. --------------080004090509090103090703-- From sacadmin Mon Jun 26 14:22:39 2006 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.104.31]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k5QLMd5R008695 for ; Mon, 26 Jun 2006 14:22:39 -0700 (PDT) Received: from [129.146.108.211] (almas.SFBay.Sun.COM [129.146.108.211]) by jurassic.eng.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k5QLMcX5331673; Mon, 26 Jun 2006 14:22:38 -0700 (PDT) Message-ID: <44A0501E.8020306@sun.com> Date: Mon, 26 Jun 2006 14:22:38 -0700 From: Alan Coopersmith User-Agent: Thunderbird 1.5.0.2 (X11/20060427) MIME-Version: 1.0 To: Kacheong Poon CC: psarc@sac.sfbay.sun.com Subject: Re: 2006/407 [TCP|UDP]_EXCLBIND Stability Change References: <17562.32566.617112.281658@gargle.gargle.HOWL> <449AAECD.7080008@sun.com> <17562.45260.795904.607470@gargle.gargle.HOWL> <449AD07C.3050808@sun.com> In-Reply-To: <449AD07C.3050808@sun.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 817 Kacheong Poon wrote: > James Carlson wrote: > >>> (We tried this in Xsun a couple of years ago, but had to >>> quickly reject, because when the X server restarted it was locked out of >>> the socket by the TCP_EXCLBIND set by the previous X server which was no >>> longer running. Since we don't want to lock users out when the server >>> is killed or crashes without having a chance to clean up, we found that >>> TCP_EXCLBIND was unusable.) >> Kacheong: TIME-WAIT doesn't factor in here, does it? > > > I wished the X server team had told us about this when > they tried it... I don't remember who we talked with other than Casper at the time - it's been a couple of years. (S9U2 timeframe.) -- -Alan Coopersmith- alan.coopersmith@sun.com Sun Microsystems, Inc. - X Window System Engineering From sacadmin Wed Jun 28 10:56:55 2006 Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k5SHutsQ004426 for ; Wed, 28 Jun 2006 10:56:55 -0700 (PDT) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id k5SHvuiB028919; Wed, 28 Jun 2006 13:57:56 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.13.6+Sun/8.13.6/Submit) id k5SHvtmd028916; Wed, 28 Jun 2006 13:57:55 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17570.49952.513697.569580@gargle.gargle.HOWL> Date: Wed, 28 Jun 2006 13:57:52 -0400 From: James Carlson To: psarc@sac.sfbay.sun.com cc: kacheong.poon@sun.com Subject: Re: 2006/407 [TCP|UDP]_EXCLBIND Stability Change In-Reply-To: James Carlson's message of 22 June 2006 07:29:58 References: <17562.32566.617112.281658@gargle.gargle.HOWL> X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 364 This fast-track request was approved at today's PSARC meeting. I've deposited the final specification as 'spec.txt' in the case directory. -- James Carlson, KISS Network Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677