From sacadmin Tue Aug 29 13:48:42 2006 Received: from eastmail1bur.East.Sun.COM (eastmail1bur.East.Sun.COM [129.148.9.49]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k7TKmfBs018939 for ; Tue, 29 Aug 2006 13:48:41 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1bur.East.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k7TKmekH028124; Tue, 29 Aug 2006 16:48:40 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by thunk.east.sun.com (8.13.7+Sun/8.13.7) with ESMTP id k7TKmexA021681; Tue, 29 Aug 2006 16:48:40 -0400 (EDT) Subject: PSARC 2006/515 ping -N From: Bill Sommerfeld To: psarc@sac.sfbay.sun.com Cc: Paul Wernau Content-Type: text/plain Date: Tue, 29 Aug 2006 16:48:39 -0400 Message-Id: <1156884519.19843.13.camel@thunk> Mime-Version: 1.0 X-Mailer: Evolution 2.6.2 Content-Transfer-Encoding: 7bit Status: RO Content-Length: 3328 I'm sponsoring this case for Paul Wernau. Timer expires 9/5/2006. As it introduces a previously unrecognized command flag, a release binding of "Patch" is appropriate. PSARC 1997/244 classifies ping as "Stable", and this case proposes to match that with a "Committed" classification. ping(1m) is a powerful tool for network fault isolation. While ping currently provides an option to specify specific gateways, this option modifies the outgoing packet headers to add a Source Route/Record Route header option, frequently causing routers to administratively prohibit the traffic. This case proposes to add a new option, -N, to ping(1m), which allows a user with sufficient privilege to optionally specify a next-hop router, thus effectively bypassing the system routing table for remote hosts. This new option will use the existing IP_NEXTHOP socket option to set a per-socket policy (see ip(7P) and PSARC/2005/603) to specify a next hop IPv4 router for this socket, i.e. the packets will be sent directly to the specified next-hop router for forwarding. Similarly for IPv6, it will use the IPV6_NEXTHOP socket option (see ip6(7p)). Specifying a next hop router through IP_NEXTHOP requires sys_net_config privilege and ping will enforce this requirement. The privilege model will mirror that of the "-b" IPsec policy bypass option delivered with PSARC/2006/215. Related work: We are flexible regarding option letter choice, but there is substantial variability between different systems in ping options. We have not discovered any other ping implementation which supports either this functionality, or defines a '-N' option. Man page level diffs... $ diff -c /tmp/ping.orig /tmp/ping.IPNEXTHOP *** /tmp/ping.orig Fri May 19 16:11:55 2006 --- /tmp/ping.IPNEXTHOP Fri May 19 16:16:19 2006 *************** *** 12,19 **** /usr/sbin/ping -s [-l | -U] [-abdlLnrRv] [-A addr_family] [-c traffic_class] [-g gateway [ -g gateway...]] ! [-F flow_label] [-I interval] [-i interface] [-P tos] ! [-p port] [-t ttl] host [data_size] [npackets] DESCRIPTION The utility ping utilizes the ICMP (ICMP6 in IPv6) --- 12,19 ---- /usr/sbin/ping -s [-l | -U] [-abdlLnrRv] [-A addr_family] [-c traffic_class] [-g gateway [ -g gateway...]] ! [-N next_hop_router ] [-F flow_label] [-I interval] [-i interface] ! [-P tos] [-p port] [-t ttl] host [data_size] [npackets] DESCRIPTION The utility ping utilizes the ICMP (ICMP6 in IPv6) *************** *** 187,194 **** --- 187,205 ---- used by superuser or a user granted the sys_net_config privilege. + -N + Specify a next hop router so that the probe packet + goes through the specified router along its path to + the target host. This option essentially bypasses the + system routing table and leaves the probe packet + header unmodified. Only one next hop router may be + specified. Because this option bypasses the + system-wide routing table for this connection, it can + only be used by superuser or a user granted the + sys_net_config privilege. + SunOS 5.10 Last change: 25 Apr 2006 3 From sacadmin Wed Aug 30 04:28:29 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 k7UBSS99011415 for ; Wed, 30 Aug 2006 04:28:28 -0700 (PDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.13.7+Sun/8.13.7) with ESMTP id k7UBUP9n005894; Wed, 30 Aug 2006 07:30:25 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.13.7+Sun/8.13.7/Submit) id k7UBUPqU005891; Wed, 30 Aug 2006 07:30:25 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17653.30417.208358.211714@gargle.gargle.HOWL> Date: Wed, 30 Aug 2006 07:30:25 -0400 From: James Carlson To: Bill Sommerfeld Cc: psarc@sac.sfbay.sun.com, Paul Wernau Subject: Re: PSARC 2006/515 ping -N In-Reply-To: Bill Sommerfeld's message of 29 August 2006 16:48:39 References: <1156884519.19843.13.camel@thunk> X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 2174 Bill Sommerfeld writes: > Specifying a next hop router through IP_NEXTHOP requires sys_net_config > privilege and ping will enforce this requirement. The privilege model > will mirror that of the "-b" IPsec policy bypass option delivered with > PSARC/2006/215. While I understand the -b policy issue, and I can (somewhat) understand the general IP_NEXTHOP restriction for unprivileged user programs, what's the justification for reflecting this restriction in ping's user interface? Ping already intentionally allows the user to do privileged things that he ordinarily wouldn't be able to do -- including generating and receiving raw IP datagrams -- through a controlled interface that doesn't allow arbitrary hackery. Why is setting the next-hop option on outbound ICMP Echo datagrams particularly sensitive -- compared with, say, "-g" or "-i" -- such that the existing usage model for this new option needs to be different from the others? What can the user do that's hazardous? > + -N > > + Specify a next hop router so that the probe packet > + goes through the specified router along its path to > + the target host. This option essentially bypasses the > + system routing table and leaves the probe packet > + header unmodified. Only one next hop router may be > + specified. Because this option bypasses the > + system-wide routing table for this connection, it can > + only be used by superuser or a user granted the > + sys_net_config privilege. Need some more details here: - Does this work with IPv6 as well? You mention IP_NEXTHOP specifically, and I think that's v4-only. - Can "superuser" root still use the new feature even if it doesn't have sys_net_config? That's what the above text seems to imply. - If I specify "-i" and "-N," does the right thing happen regardless of order? (I assume so; just checking.) -- 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 Wed Aug 30 10:04:10 2006 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k7UH4ALs024080 for ; Wed, 30 Aug 2006 10:04:10 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k7UH4A9S026833 for ; Wed, 30 Aug 2006 10:04:10 -0700 (PDT) Received: from fe-amer-01.sun.com ([192.18.108.175]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k7UH49gY016077 for ; Wed, 30 Aug 2006 11:04:09 -0600 (MDT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0J4T00H01LTRYN00@mail-amer.sun.com> (original mail from Paul.Wernau@Sun.COM) for psarc@sac.sfbay.sun.com; Wed, 30 Aug 2006 11:04:09 -0600 (MDT) Received: from [129.148.174.30] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0J4T00I96M2WGK62@mail-amer.sun.com>; Wed, 30 Aug 2006 11:04:09 -0600 (MDT) Date: Wed, 30 Aug 2006 13:04:03 -0400 From: Paul Wernau Subject: Re: PSARC 2006/515 ping -N In-reply-to: <17653.30417.208358.211714@gargle.gargle.HOWL> Sender: Paul.Wernau@Sun.COM To: James Carlson Cc: Bill Sommerfeld , psarc@sac.sfbay.sun.com Message-id: <44F5C503.1070505@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <1156884519.19843.13.camel@thunk> <17653.30417.208358.211714@gargle.gargle.HOWL> User-Agent: Mail/News 1.5.0.4 (X11/20060731) Status: RO Content-Length: 2821 James Carlson wrote: > Bill Sommerfeld writes: >> Specifying a next hop router through IP_NEXTHOP requires sys_net_config >> privilege and ping will enforce this requirement. The privilege model >> will mirror that of the "-b" IPsec policy bypass option delivered with >> PSARC/2006/215. > > While I understand the -b policy issue, and I can (somewhat) > understand the general IP_NEXTHOP restriction for unprivileged user > programs, what's the justification for reflecting this restriction in > ping's user interface? > > Ping already intentionally allows the user to do privileged things > that he ordinarily wouldn't be able to do -- including generating and > receiving raw IP datagrams -- through a controlled interface that > doesn't allow arbitrary hackery. > > Why is setting the next-hop option on outbound ICMP Echo datagrams > particularly sensitive -- compared with, say, "-g" or "-i" -- such > that the existing usage model for this new option needs to be > different from the others? What can the user do that's hazardous? > The reason for this restriction is simply following the privilege model of this option in ip(7p). It is interesting to note that IPV6_NEXTHOP does not have this restriction. I would be fine in having the restriction lifted and will take whatever advice PSARC has in this regard. I don't really have a plausible threat model to support enforcing this restriction for ping (as opposed to the general case with this socket option, where I think the restriction has some merit.) >> + -N >> >> + Specify a next hop router so that the probe packet >> + goes through the specified router along its path to >> + the target host. This option essentially bypasses the >> + system routing table and leaves the probe packet >> + header unmodified. Only one next hop router may be >> + specified. Because this option bypasses the >> + system-wide routing table for this connection, it can >> + only be used by superuser or a user granted the >> + sys_net_config privilege. > > Need some more details here: > > - Does this work with IPv6 as well? You mention IP_NEXTHOP > specifically, and I think that's v4-only. > Argh. Yes, it works with v6 also. I should amend the materials to reflect that. > - Can "superuser" root still use the new feature even if it doesn't > have sys_net_config? That's what the above text seems to imply. > It is purely privilege based. So this text needs to be changed, but I will await the advice on whether to even have this restriction. > - If I specify "-i" and "-N," does the right thing happen regardless > of order? (I assume so; just checking.) > Yes, it is all part of getopt() switch statement. Thanks, Paul From sacadmin Wed Aug 30 10:36: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 k7UHa3Ci025604 for ; Wed, 30 Aug 2006 10:36:03 -0700 (PDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.13.7+Sun/8.13.7) with ESMTP id k7UHbxR1007418; Wed, 30 Aug 2006 13:37:59 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.13.7+Sun/8.13.7/Submit) id k7UHbxqn007415; Wed, 30 Aug 2006 13:37:59 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17653.52471.108759.716378@gargle.gargle.HOWL> Date: Wed, 30 Aug 2006 13:37:59 -0400 From: James Carlson To: Paul Wernau Cc: Bill Sommerfeld , psarc@sac.sfbay.sun.com Subject: Re: PSARC 2006/515 ping -N In-Reply-To: Paul Wernau's message of 30 August 2006 13:04:03 References: <1156884519.19843.13.camel@thunk> <17653.30417.208358.211714@gargle.gargle.HOWL> <44F5C503.1070505@sun.com> X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 2367 Paul Wernau writes: > > Why is setting the next-hop option on outbound ICMP Echo datagrams > > particularly sensitive -- compared with, say, "-g" or "-i" -- such > > that the existing usage model for this new option needs to be > > different from the others? What can the user do that's hazardous? > > > > The reason for this restriction is simply following the privilege model > of this option in ip(7p). But that privilege model _assumes_ that the user can send arbitrary packets. That's not so with ping. Ping presents a drastically reduced set of functionality to the user. (Given the existing SO_DONTROUTE, I'm not even sure IP_NEXTHOP ought to be privileged, but that's perhaps a different issue.) > It is interesting to note that IPV6_NEXTHOP > does not have this restriction. Indeed. > I would be fine in having the > restriction lifted and will take whatever advice PSARC has in this > regard. I don't really have a plausible threat model to support > enforcing this restriction for ping (as opposed to the general case with > this socket option, where I think the restriction has some merit.) OK. > > Need some more details here: > > > > - Does this work with IPv6 as well? You mention IP_NEXTHOP > > specifically, and I think that's v4-only. > > > > Argh. Yes, it works with v6 also. I should amend the materials to > reflect that. OK. > > - Can "superuser" root still use the new feature even if it doesn't > > have sys_net_config? That's what the above text seems to imply. > > > > It is purely privilege based. So this text needs to be changed, but I > will await the advice on whether to even have this restriction. I'd rather not, unless there's a specific threat we've assessed here. > > - If I specify "-i" and "-N," does the right thing happen regardless > > of order? (I assume so; just checking.) > > > > > Yes, it is all part of getopt() switch statement. We're close to dipping into design or code review here (sorry about that), but I think you need to set the nexthop first and then set the interface with bind(), regardless of the order on the command line. -- 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 Wed Aug 30 12:48:48 2006 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k7UJmmJO001428 for ; Wed, 30 Aug 2006 12:48:48 -0700 (PDT) Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k7UJmmn7018650 for ; Wed, 30 Aug 2006 12:48:48 -0700 (PDT) Received: from fe-amer-06.sun.com ([192.18.108.180]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k7UJmmGZ000238 for ; Wed, 30 Aug 2006 13:48:48 -0600 (MDT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0J4T00901TAYM900@mail-amer.sun.com> (original mail from Paul.Wernau@Sun.COM) for psarc@sac.sfbay.sun.com; Wed, 30 Aug 2006 13:48:48 -0600 (MDT) Received: from [129.148.174.30] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0J4T00ANXTPBIQ04@mail-amer.sun.com>; Wed, 30 Aug 2006 13:48:48 -0600 (MDT) Date: Wed, 30 Aug 2006 15:48:40 -0400 From: Paul Wernau Subject: Re: PSARC 2006/515 ping -N In-reply-to: <17653.52471.108759.716378@gargle.gargle.HOWL> Sender: Paul.Wernau@Sun.COM To: James Carlson Cc: Bill Sommerfeld , psarc@sac.sfbay.sun.com Message-id: <44F5EB98.1020700@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <1156884519.19843.13.camel@thunk> <17653.30417.208358.211714@gargle.gargle.HOWL> <44F5C503.1070505@sun.com> <17653.52471.108759.716378@gargle.gargle.HOWL> User-Agent: Mail/News 1.5.0.4 (X11/20060731) Status: RO Content-Length: 1082 > >>> - Can "superuser" root still use the new feature even if it doesn't >>> have sys_net_config? That's what the above text seems to imply. >>> >> It is purely privilege based. So this text needs to be changed, but I >> will await the advice on whether to even have this restriction. > > I'd rather not, unless there's a specific threat we've assessed here. > OK, I'll remove that restriction and work on getting some new materials. >>> - If I specify "-i" and "-N," does the right thing happen regardless >>> of order? (I assume so; just checking.) >>> >> >> Yes, it is all part of getopt() switch statement. > > We're close to dipping into design or code review here (sorry about > that), but I think you need to set the nexthop first and then set the > interface with bind(), regardless of the order on the command line. > nexthop is set before bind() in the current code, but I will make sure you get a chance to review this once I rip out the privilege checks (assuming no other ARC members have an objection to ripping out these checks). -Paul From sacadmin Wed Aug 30 22:57:30 2006 Received: from sineb-mail-1.sun.com ([192.18.19.6]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k7V5vTKr015941 for ; Wed, 30 Aug 2006 22:57:29 -0700 (PDT) Received: from fe-apac-05.sun.com (fe-apac-05.sun.com [192.18.19.176] (may be forged)) by sineb-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k7V5vMnS026740 for ; Thu, 31 Aug 2006 13:57:23 +0800 (SGT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0J4U00001LR2ZI00@mail-apac.sun.com> (original mail from Darren.Reed@Sun.COM) for psarc@sac.sfbay.sun.com; Thu, 31 Aug 2006 13:57:22 +0800 (SGT) Received: from [129.158.219.204] by mail-apac.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0J4U003XJLVK5C2J@mail-apac.sun.com>; Thu, 31 Aug 2006 13:57:22 +0800 (SGT) Date: Thu, 31 Aug 2006 13:57:20 +0800 From: Darren Reed Subject: Re: PSARC 2006/515 ping -N In-reply-to: <17653.30417.208358.211714@gargle.gargle.HOWL> Sender: Darren.Reed@Sun.COM To: James Carlson Cc: Bill Sommerfeld , psarc@sac.sfbay.sun.com, Paul Wernau Message-id: <44F67A40.6000604@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en References: <1156884519.19843.13.camel@thunk> <17653.30417.208358.211714@gargle.gargle.HOWL> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20060120 Status: RO Content-Length: 281 Should this case be extended to cover traceroute as well as ping? To currently achieve this functionality with traceroute would require using LSRR (-g), which increases the likelihood of the packets being dropped due to security policy restrictions on IP header options. Darren From sacadmin Thu Aug 31 07:00:42 2006 Received: from sfbaymail2sca.sfbay.sun.com (sfbaymail2sca.SFBay.Sun.COM [129.145.155.42]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k7VE0gtk022761 for ; Thu, 31 Aug 2006 07:00:42 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k7VE0fFL022412 for ; Thu, 31 Aug 2006 07:00:42 -0700 (PDT) Received: from fe-amer-06.sun.com ([192.18.108.180]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k7VE0fcB016637 for ; Thu, 31 Aug 2006 08:00:41 -0600 (MDT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0J4V00A017V9JI00@mail-amer.sun.com> (original mail from Paul.Wernau@Sun.COM) for psarc@sac.sfbay.sun.com; Thu, 31 Aug 2006 08:00:41 -0600 (MDT) Received: from [129.148.174.30] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0J4V001CW894HQG3@mail-amer.sun.com>; Thu, 31 Aug 2006 08:00:41 -0600 (MDT) Date: Thu, 31 Aug 2006 10:00:34 -0400 From: Paul Wernau Subject: Re: PSARC 2006/515 ping -N In-reply-to: <44F67A40.6000604@sun.com> Sender: Paul.Wernau@Sun.COM To: Darren Reed Cc: James Carlson , Bill Sommerfeld , psarc@sac.sfbay.sun.com Message-id: <44F6EB82.9030603@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <1156884519.19843.13.camel@thunk> <17653.30417.208358.211714@gargle.gargle.HOWL> <44F67A40.6000604@sun.com> User-Agent: Mail/News 1.5.0.4 (X11/20060731) Status: RO Content-Length: 472 Darren Reed wrote: > Should this case be extended to cover traceroute as well as ping? I would really prefer to defer this. I've considered traceroute in this context as well as the IPsec policy bypass context and it seems to me to require a little more analysis and might stir up more controversy due to the inherent asymmetry of the protocol. I intend to eventually open up a sister case for traceroute but need to think about it a little more. Thanks, Paul From sacadmin Thu Aug 31 12:36:28 2006 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k7VJaSSx000135 for ; Thu, 31 Aug 2006 12:36:28 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k7VJaRqd026194 for ; Thu, 31 Aug 2006 12:36:27 -0700 (PDT) Received: from fe-amer-01.sun.com ([192.18.108.175]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k7VJaR86014241 for ; Thu, 31 Aug 2006 13:36:27 -0600 (MDT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0J4V00601N64FQ00@mail-amer.sun.com> (original mail from Paul.Wernau@Sun.COM) for psarc@sac.sfbay.sun.com; Thu, 31 Aug 2006 13:36:27 -0600 (MDT) Received: from [129.148.174.30] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0J4V00IJBNSQGKZ2@mail-amer.sun.com>; Thu, 31 Aug 2006 13:36:27 -0600 (MDT) Date: Thu, 31 Aug 2006 15:36:19 -0400 From: Paul Wernau Subject: Re: PSARC 2006/515 ping -N In-reply-to: <17653.52471.108759.716378@gargle.gargle.HOWL> Sender: Paul.Wernau@Sun.COM To: James Carlson Cc: Bill Sommerfeld , Darren.Reed@Sun.COM, psarc@sac.sfbay.sun.com Message-id: <44F73A33.2030609@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT References: <1156884519.19843.13.camel@thunk> <17653.30417.208358.211714@gargle.gargle.HOWL> <44F5C503.1070505@sun.com> <17653.52471.108759.716378@gargle.gargle.HOWL> User-Agent: Mail/News 1.5.0.4 (X11/20060731) Status: RO Content-Length: 2658 I think all issues have converged. Here is the revised spec, which removes the privilege restriction (all users can use this option) and makes sure to mention both IP_NEXTHOP and IPV6_NEXTHOP. --------------------------------------------------------------------- ping(1m) is a powerful tool for network fault isolation. While ping currently provides an option to specify specific gateways, this option modifies the outgoing packet headers to add a Source Route/Record Route header option, frequently causing routers to administratively prohibit the traffic. This case proposes to add a new option, -N, to ping(1m), which allows a user to optionally specify a next-hop router, thus effectively bypassing the system routing table for remote hosts. This new option will use the existing IP_NEXTHOP socket option to set a per-socket policy (see ip(7P) and PSARC/2005/603) to specify a next hop router for this socket, i.e. the packets will be sent directly to the specified next-hop router for forwarding. Similarly for IPv6, it will use the IPV6_NEXTHOP socket option (see ip6(7p)). Man page level diffs... $ diff -c /tmp/ping.orig /tmp/ping.IPNEXTHOP *** /tmp/ping.orig Fri May 19 16:11:55 2006 --- /tmp/ping.IPNEXTHOP Fri May 19 16:16:19 2006 *************** *** 12,19 **** /usr/sbin/ping -s [-l | -U] [-abdlLnrRv] [-A addr_family] [-c traffic_class] [-g gateway [ -g gateway...]] ! [-F flow_label] [-I interval] [-i interface] [-P tos] ! [-p port] [-t ttl] host [data_size] [npackets] DESCRIPTION The utility ping utilizes the ICMP (ICMP6 in IPv6) --- 12,19 ---- /usr/sbin/ping -s [-l | -U] [-abdlLnrRv] [-A addr_family] [-c traffic_class] [-g gateway [ -g gateway...]] ! [-N next_hop_router ] [-F flow_label] [-I interval] [-i interface] ! [-P tos] [-p port] [-t ttl] host [data_size] [npackets] DESCRIPTION The utility ping utilizes the ICMP (ICMP6 in IPv6) *************** *** 187,194 **** --- 187,205 ---- used by superuser or a user granted the sys_net_config privilege. + -N + Specify a next hop router so that the probe packet + goes through the specified router along its path to + the target host. This option essentially bypasses the + system routing table and leaves the probe packet + header unmodified. Only one next hop router may be + specified. SunOS 5.10 Last change: 25 Apr 2006 3 --------------------------------------------------------------------- From sacadmin Wed Sep 6 10:13:56 2006 Received: from eastmail1bur.East.Sun.COM (eastmail1bur.East.Sun.COM [129.148.9.49]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k86HDuvw008644 for ; Wed, 6 Sep 2006 10:13:56 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1bur.East.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k86HDsvP008445; Wed, 6 Sep 2006 13:13:54 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by thunk.east.sun.com (8.13.7+Sun/8.13.7) with ESMTP id k86HDslT025639; Wed, 6 Sep 2006 13:13:54 -0400 (EDT) Subject: Re: PSARC 2006/515 ping -N From: Bill Sommerfeld To: psarc@sac.sfbay.sun.com Cc: Paul Wernau In-Reply-To: <1156884519.19843.13.camel@thunk> References: <1156884519.19843.13.camel@thunk> Content-Type: text/plain Date: Wed, 06 Sep 2006 13:13:54 -0400 Message-Id: <1157562834.25500.1.camel@thunk> Mime-Version: 1.0 X-Mailer: Evolution 2.6.2 Content-Transfer-Encoding: 7bit Status: RO Content-Length: 54 This case was approved during today's PSARC meeting.