From meem@triplex.east.sun.com Wed Apr 4 18:32:42 2007 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l351Wf1k009075 for ; Wed, 4 Apr 2007 18:32:41 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l351W7PG011506; Thu, 5 Apr 2007 09:32:08 +0800 (SGT) 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 <0JG000L0149I7800@nwk-avmta-1.sfbay.Sun.COM>; Wed, 04 Apr 2007 18:32:06 -0700 (PDT) Received: from triplex.East.Sun.COM ([129.148.174.104]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JG00058K49HB380@nwk-avmta-1.sfbay.Sun.COM>; Wed, 04 Apr 2007 18:32:06 -0700 (PDT) Received: from triplex.East.Sun.COM (localhost [127.0.0.1]) by triplex.East.Sun.COM (8.14.0+Sun/8.14.0) with ESMTP id l351W50K012792; Wed, 04 Apr 2007 21:32:05 -0400 (EDT) Received: (from meem@localhost) by triplex.East.Sun.COM (8.14.0+Sun/8.14.0/Submit) id l351W5nr012789; Wed, 04 Apr 2007 21:32:05 -0400 (EDT) Date: Wed, 04 Apr 2007 21:32:05 -0400 From: Peter Memishian Subject: PSARC/2007/198 IP Filter ipmp_hook_emulation To: psarc-ext@sun.com Cc: erik.nordmark@sun.com Message-id: <17940.20885.641570.384838@triplex.East.Sun.COM> MIME-version: 1.0 X-Mailer: VM 7.17 under 21.4 (patch 18) "Social Property" XEmacs Lucid Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 3913 I'm sponsoring the following fasttrack on behalf of Erik Nordmark. The requested release binding is micro/patch; the proposed interface (a new ndd tunable) is unstable. The timer expires on Wednesday, 4/11. Background ---------- For IP Filter to do stateful filtering in conjunction with IPMP, IP Filter needs to see the IPMP *group* as though it was a single network interface, since the state in IP Filter is associated with what IP Filter views as a network interface. This was addressed by the IP Filter code base external to Sun by the introduction of an undocumented ndd variable - qif_ndd_set. That variable would be used as ndd -set /dev/pfil qif_ipmp_set ipmp0=ce0,ce1 and that would make IP Filter view the packets on ce0 and ce1 as being on the fictitious "ipmp0" network interface. This was brought into Solaris as part of the IP Filter integration in Solaris 10 [1]. However, with the advent of Packet Filtering Hooks [2] there is no more /dev/pfil hence the above capability was dropped. Since pfhooks is backported to a Solaris 10 update we need to reinstate the ability to handle stateful filtering with IPMP with patch/micro binding. Note that the Clearview IPMP project [3] will model IPMP groups as IP interfaces, thus addressing this problem. However, that project is not yet in Nevada, nor is it yet targeting an update. Thus, we are proposing a short-term fix. Proposal -------- We will introduce a new ndd variable in IP which controls whether the IP Filter hooks and netinfo provider sees the current network interface names (e.g., 'ce0') or sees the emulated group name (e.g., 'ipmp0'). We assume the IP Filter name for the group is the same as IP's group name. Thus, there is no need to specify the group name. The ndd variable is called ipmp_hook_emulation and is a boolean. The variable will default to 0 (false), thus the customer has to explicitly enable it using ndd -set /dev/ip ipmp_hook_emulation 1 Customer impact --------------- A customer which has not used qif_ipmp_set does not need to change anything. A customer which has used qif_ipmp_set will instead need to do enable ipmp_hook_emulation and also ensure the IPMP group name (set by ifconfig) matches the name of the group that had been used with qif_ipmp_set. Clearview IPMP [3] is likely to remove the need for this in the future. Specifically, the expected future behavior of Clearview IPMP with respect to IP Filter is similar if not identical to the default of the above variable being changed to 'true' (without a way to set it to 'false'). While the details of that interaction will be specified by the upcoming Clearview IPMP case, the proposed behavior here is consistent with the future direction of Clearview IPMP. Design details [Not an interface] --------------------------------- When ipmp_hook_emulation is enabled, then the IP module assigns an interface index for each IPMP group name. This interface index is then used as the phy_if_t in the hook and netinfo interfaces in [2]. It is not assigned to any real network interface in IP. We skip certain netinfo and hook aspects since they are not used by IP Filter ("skip" means that they will not work correctly if used by something else when ipmp_hook_emulation are used). Those are hne_lif passed out with the nicinfo events net_lifgetnext() net_phygetnext() That should be acceptable since the exported interfaces in [2] were TCR'd by PSARC to be lowered to Consolidation Private. Exported Interfaces ------------------- Interface Classification Comments ipmp_hook_emulation UNSTABLE ndd variable for /dev/ip References ---------- [1] PSARC 2003/046 Solaris IP Filter [2] PSARC 2005/334 Packet Filtering Hooks [3] PSARC 2005/132 Clearview: Network Interface Coherence [4] CR 6535824 pfhooks and patch for IPMP+IP Filter doesn't work together -- meem From carlsonj@phorcys.east.sun.com Thu Apr 5 05:51:33 2007 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 l35CpX7o018906 for ; Thu, 5 Apr 2007 05:51:33 -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.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l35CoXbG022520; Thu, 5 Apr 2007 05:50:36 -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 <0JG000823ZOBSE00@brm-avmta-1.central.sun.com>; Thu, 05 Apr 2007 06:50:35 -0600 (MDT) Received: from phorcys.east.sun.com ([129.148.174.143]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JG000IDCZOBM070@brm-avmta-1.central.sun.com>; Thu, 05 Apr 2007 06:50:35 -0600 (MDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.0+Sun/8.14.0) with ESMTP id l35CoYtP019405; Thu, 05 Apr 2007 08:50:35 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.0+Sun/8.14.0/Submit) id l35CoYuN019402; Thu, 05 Apr 2007 08:50:34 -0400 (EDT) Date: Thu, 05 Apr 2007 08:50:34 -0400 From: James Carlson Subject: Re: PSARC/2007/198 IP Filter ipmp_hook_emulation In-reply-to: <17940.20885.641570.384838@triplex.East.Sun.COM> To: Peter Memishian Cc: psarc-ext@sun.com, Erik.Nordmark@sun.com Message-id: <17940.61594.762841.672657@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <17940.20885.641570.384838@triplex.East.Sun.COM> Status: RO Content-Length: 1214 Peter Memishian writes: > Proposal > -------- > > We will introduce a new ndd variable in IP which controls whether the IP > Filter hooks and netinfo provider sees the current network interface > names (e.g., 'ce0') or sees the emulated group name (e.g., 'ipmp0'). We > assume the IP Filter name for the group is the same as IP's group name. > Thus, there is no need to specify the group name. > > The ndd variable is called ipmp_hook_emulation and is a boolean. The > variable will default to 0 (false), thus the customer has to explicitly > enable it using > > ndd -set /dev/ip ipmp_hook_emulation 1 Why another tunable? If this is the direction we're driving anyway, and if the only affected users are those trying to use both IPMP and ipfilter at the same time, and there's no way that those users can make sane use of ordinary (and commonly-used) ipfilter expressions such as "keep state" without the feature, then why force users to do something special to enable it? -- James Carlson, Solaris Networking 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 erik.nordmark@sun.com Thu Apr 5 20:04:36 2007 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 l3634a3r010827 for ; Thu, 5 Apr 2007 20:04:36 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l363428G003355; Thu, 5 Apr 2007 20:04:02 -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 <0JG20050B36QWQ00@nwk-avmta-1.sfbay.Sun.COM>; Thu, 05 Apr 2007 20:04:02 -0700 (PDT) Received: from jurassic.eng.sun.com ([129.146.228.50]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JG200M5336MZ120@nwk-avmta-1.sfbay.Sun.COM>; Thu, 05 Apr 2007 20:03:58 -0700 (PDT) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l3632DM4098320 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 05 Apr 2007 20:02:13 -0700 (PDT) Date: Thu, 05 Apr 2007 20:02:12 -0700 From: Erik Nordmark Subject: Re: PSARC/2007/198 IP Filter ipmp_hook_emulation In-reply-to: <17940.61594.762841.672657@gargle.gargle.HOWL> To: James Carlson Cc: Peter Memishian , psarc-ext@sun.com Message-id: <4615B834.1090300@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <17940.20885.641570.384838@triplex.East.Sun.COM> <17940.61594.762841.672657@gargle.gargle.HOWL> User-Agent: Thunderbird 1.5.0.5 (X11/20060911) Status: RO Content-Length: 937 James Carlson wrote: > Why another tunable? > > If this is the direction we're driving anyway, and if the only > affected users are those trying to use both IPMP and ipfilter at the > same time, and there's no way that those users can make sane use of > ordinary (and commonly-used) ipfilter expressions such as "keep state" > without the feature, then why force users to do something special to > enable it? The concern for the patch binding is the users that use IP Filter without any 'keep state' rules. For instance, having such stateless rules for ce0 and ce1 where ce0 and ce1 are in an IPMP group. If we changed the default behavior those rules would no longer apply since IP Filter would see those packets as associated with a different interface. In general, I thought changing the default behavior of the system in a patch was a bad thing. FWIW changing the default behavior in Nevada would be ok with me. Erik From carlsonj@phorcys.east.sun.com Fri Apr 6 04:58:47 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l36BwkVF018099 for ; Fri, 6 Apr 2007 04:58:46 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l36Bw1qI011238; Fri, 6 Apr 2007 12:58:07 +0100 (BST) 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 <0JG200C01RWR3Y00@brm-avmta-1.central.sun.com>; Fri, 06 Apr 2007 05:58:03 -0600 (MDT) Received: from phorcys.east.sun.com ([129.148.174.143]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JG2009TURWRI3E0@brm-avmta-1.central.sun.com>; Fri, 06 Apr 2007 05:58:03 -0600 (MDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.0+Sun/8.14.0) with ESMTP id l36Bw3k9024461; Fri, 06 Apr 2007 07:58:03 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.0+Sun/8.14.0/Submit) id l36Bw3q3024458; Fri, 06 Apr 2007 07:58:03 -0400 (EDT) Date: Fri, 06 Apr 2007 07:58:03 -0400 From: James Carlson Subject: Re: PSARC/2007/198 IP Filter ipmp_hook_emulation In-reply-to: <4615B834.1090300@sun.com> To: Erik Nordmark Cc: Peter Memishian , PSARC-EXT@sun.com Message-id: <17942.13771.120846.784759@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <17940.20885.641570.384838@triplex.East.Sun.COM> <17940.61594.762841.672657@gargle.gargle.HOWL> <4615B834.1090300@sun.com> Status: RO Content-Length: 2476 Erik Nordmark writes: > > If this is the direction we're driving anyway, and if the only > > affected users are those trying to use both IPMP and ipfilter at the > > same time, and there's no way that those users can make sane use of > > ordinary (and commonly-used) ipfilter expressions such as "keep state" > > without the feature, then why force users to do something special to > > enable it? > > The concern for the patch binding is the users that use IP Filter > without any 'keep state' rules. For instance, having such stateless > rules for ce0 and ce1 where ce0 and ce1 are in an IPMP group. > If we changed the default behavior those rules would no longer apply > since IP Filter would see those packets as associated with a different > interface. If ce0 and ce1 are in a group, it should be possible for ipfilter to detect this, right? The rule set will have "ce0" in it, and the kernel portion of ipfilter will need to look this up via netinfo and that'll provide the opportunity. Why not just have the ioctl fail, so ipf fails, the SMF service goes into maintenance, and the patch README explains what we broke (and what they should have done)? It sounds like a rare thing to have a customer successfully using IPMP with ipfilter on a per-interface basis, and rarer still to have useful filters that lack state. (For instance, it's close to impossible to write a useful "allow outbound connections" rule without "keep state.") If you feel moved, or if the gatekeepers insist, then write a small script that groks IPMP groups and rewrites ipf.conf during patch install. > In general, I thought changing the default behavior of the system in a > patch was a bad thing. Not necessarily -- there are multiple bad things here. The pfhooks incompatible change in a patch was a bad thing, and adding yet another ndd tunable that the user must set (and figure out how to put into an rc script) in order to restore normal system operation is a bad thing. I'm looking for a balance. I'd really rather not have a tunable that says, in effect, "make my system work the way it's supposed to." That just invites customer calls and escalations. This case seems quite mild to me. It's nowhere near the level of a driver-renaming patch. -- James Carlson, Solaris Networking 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 erik.nordmark@sun.com Fri Apr 6 09:24:44 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l36GOhJg021948 for ; Fri, 6 Apr 2007 09:24:44 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l36GO2Ob009503; Fri, 6 Apr 2007 17:24:07 +0100 (BST) 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 <0JG300G05485JI00@brm-avmta-1.central.sun.com>; Fri, 06 Apr 2007 10:24:05 -0600 (MDT) Received: from jurassic.eng.sun.com ([129.146.17.55]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JG300CW6484T8C0@brm-avmta-1.central.sun.com>; Fri, 06 Apr 2007 10:24:04 -0600 (MDT) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l36GO30d143599 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 06 Apr 2007 09:24:04 -0700 (PDT) Date: Fri, 06 Apr 2007 09:24:03 -0700 From: Erik Nordmark Subject: Re: PSARC/2007/198 IP Filter ipmp_hook_emulation In-reply-to: <17942.13771.120846.784759@gargle.gargle.HOWL> To: James Carlson Cc: Peter Memishian , PSARC-EXT@sun.com Message-id: <46167423.4000703@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <17940.20885.641570.384838@triplex.East.Sun.COM> <17940.61594.762841.672657@gargle.gargle.HOWL> <4615B834.1090300@sun.com> <17942.13771.120846.784759@gargle.gargle.HOWL> User-Agent: Thunderbird 1.5.0.5 (X11/20060911) Status: RO Content-Length: 1698 James Carlson wrote: > If ce0 and ce1 are in a group, it should be possible for ipfilter to > detect this, right? The rule set will have "ce0" in it, and the > kernel portion of ipfilter will need to look this up via netinfo and > that'll provide the opportunity. The netinfo provider doesn't provide any information about IPMP (such a group names) so there isn't an easy way for IP Filter to tell. > Why not just have the ioctl fail, so ipf fails, the SMF service goes > into maintenance, and the patch README explains what we broke (and > what they should have done)? It sounds like a rare thing to have a > customer successfully using IPMP with ipfilter on a per-interface > basis, and rarer still to have useful filters that lack state. (For > instance, it's close to impossible to write a useful "allow outbound > connections" rule without "keep state.") Wouldn't the result of that be that the system end up without any IP Filter protection until the admin checks svcs -x and fixes things? That wouldn't be consistent with our general desire for security. >> In general, I thought changing the default behavior of the system in a >> patch was a bad thing. > > Not necessarily -- there are multiple bad things here. The pfhooks > incompatible change in a patch was a bad thing, and adding yet another > ndd tunable that the user must set (and figure out how to put into an > rc script) in order to restore normal system operation is a bad thing. > I'm looking for a balance. My point is that the users that want stateful IP Filter with IPMP must already use an *undocumented* ndd variable (qif_ipmp_set). Only those users need to switch to use the new ndd variable. Erik From carlsonj@phorcys.east.sun.com Fri Apr 6 13:04:56 2007 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l36K4tCi025593 for ; Fri, 6 Apr 2007 13:04:56 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l36K3L11018665; Sat, 7 Apr 2007 04:03:27 +0800 (SGT) 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 <0JG300F07EDMPQ00@brm-avmta-1.central.sun.com>; Fri, 06 Apr 2007 14:03:22 -0600 (MDT) Received: from phorcys.east.sun.com ([129.148.174.143]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JG3008CMEDLZW20@brm-avmta-1.central.sun.com>; Fri, 06 Apr 2007 14:03:21 -0600 (MDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.0+Sun/8.14.0) with ESMTP id l36K3L8I025871; Fri, 06 Apr 2007 16:03:21 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.0+Sun/8.14.0/Submit) id l36K3LAb025868; Fri, 06 Apr 2007 16:03:21 -0400 (EDT) Date: Fri, 06 Apr 2007 16:03:21 -0400 From: James Carlson Subject: Re: PSARC/2007/198 IP Filter ipmp_hook_emulation In-reply-to: <46167423.4000703@sun.com> To: Erik Nordmark Cc: Peter Memishian , PSARC-EXT@sun.com Message-id: <17942.42889.198518.532729@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <17940.20885.641570.384838@triplex.East.Sun.COM> <17940.61594.762841.672657@gargle.gargle.HOWL> <4615B834.1090300@sun.com> <17942.13771.120846.784759@gargle.gargle.HOWL> <46167423.4000703@sun.com> Status: RO Content-Length: 2941 Erik Nordmark writes: > James Carlson wrote: > > > If ce0 and ce1 are in a group, it should be possible for ipfilter to > > detect this, right? The rule set will have "ce0" in it, and the > > kernel portion of ipfilter will need to look this up via netinfo and > > that'll provide the opportunity. > > The netinfo provider doesn't provide any information about IPMP (such a > group names) so there isn't an easy way for IP Filter to tell. But netinfo is talking directly to IP, isn't it? How is it that it cannot know? > > Why not just have the ioctl fail, so ipf fails, the SMF service goes > > into maintenance, and the patch README explains what we broke (and > > what they should have done)? It sounds like a rare thing to have a > > customer successfully using IPMP with ipfilter on a per-interface > > basis, and rarer still to have useful filters that lack state. (For > > instance, it's close to impossible to write a useful "allow outbound > > connections" rule without "keep state.") > > Wouldn't the result of that be that the system end up without any IP > Filter protection until the admin checks svcs -x and fixes things? > That wouldn't be consistent with our general desire for security. No, because svc:/milestone/network:default depends on ipfilter, and that'll stop other things from being brought up if the filters are broken. Won't those same customers actually be damaged far worse by the loss of qif_ipmp_set? For those customers who were using qif_ipmp_set and who install this patch, ipfilter will come up quietly and normally -- showing nothing in "svcs -x" and not blocking any services from starting -- but will not actually filter anything. The only hope they have is knowing about this new ndd tunable before they install the patch, and manually modifying their rc script to do the right thing. If they fail, they're left wide open. > >> In general, I thought changing the default behavior of the system in a > >> patch was a bad thing. > > > > Not necessarily -- there are multiple bad things here. The pfhooks > > incompatible change in a patch was a bad thing, and adding yet another > > ndd tunable that the user must set (and figure out how to put into an > > rc script) in order to restore normal system operation is a bad thing. > > I'm looking for a balance. > > My point is that the users that want stateful IP Filter with IPMP must > already use an *undocumented* ndd variable (qif_ipmp_set). Only those > users need to switch to use the new ndd variable. It seems really unfortunate, but if you feel that forcing users through two transitions in order to get this one issue right is the best course of action, then I guess I've failed to convince you. -- James Carlson, Solaris Networking 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 erik.nordmark@Sun.COM Fri Apr 6 15:52:22 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l36MqLEq028728 for ; Fri, 6 Apr 2007 15:52:21 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l36MpfEW001622; Fri, 6 Apr 2007 23:51:44 +0100 (BST) 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 <0JG300A03M67H200@brm-avmta-1.central.sun.com>; Fri, 06 Apr 2007 16:51:43 -0600 (MDT) Received: from jurassic.eng.sun.com ([129.146.224.130]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JG30097EM6606A0@brm-avmta-1.central.sun.com>; Fri, 06 Apr 2007 16:51:43 -0600 (MDT) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l36MpfY9167903 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 06 Apr 2007 15:51:42 -0700 (PDT) Date: Fri, 06 Apr 2007 15:51:41 -0700 From: Erik Nordmark Subject: Re: PSARC/2007/198 IP Filter ipmp_hook_emulation In-reply-to: <17942.42889.198518.532729@gargle.gargle.HOWL> To: James Carlson Cc: Peter Memishian , PSARC-EXT@Sun.COM Message-id: <4616CEFD.6060408@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <17940.20885.641570.384838@triplex.East.Sun.COM> <17940.61594.762841.672657@gargle.gargle.HOWL> <4615B834.1090300@sun.com> <17942.13771.120846.784759@gargle.gargle.HOWL> <46167423.4000703@sun.com> <17942.42889.198518.532729@gargle.gargle.HOWL> User-Agent: Thunderbird 1.5.0.5 (X11/20060911) Status: RO Content-Length: 2288 James Carlson wrote: > Erik Nordmark writes: >> James Carlson wrote: >> >>> If ce0 and ce1 are in a group, it should be possible for ipfilter to >>> detect this, right? The rule set will have "ce0" in it, and the >>> kernel portion of ipfilter will need to look this up via netinfo and >>> that'll provide the opportunity. >> The netinfo provider doesn't provide any information about IPMP (such a >> group names) so there isn't an easy way for IP Filter to tell. > > But netinfo is talking directly to IP, isn't it? How is it that it > cannot know? The netinfo provider exports the the set of information specified in the pfhooks PSARC case. Those are (from sys/neti.h) NA_ADDRESS = 1, NA_PEER, NA_BROADCAST, NA_NETMASK plus mtu, name, and up/down status. Thus no group name. (See section 3.2 in http://sac.eng/arc/PSARC/2005/334/commitment.materials/pfhooks-design-2006-03-13.pdf) Thus IP Filter can't tell that IPMP is used using the netinfo provider. > Won't those same customers actually be damaged far worse by the loss > of qif_ipmp_set? For those customers who were using qif_ipmp_set and > who install this patch, ipfilter will come up quietly and normally -- > showing nothing in "svcs -x" and not blocking any services from > starting -- but will not actually filter anything. We are talking about two different sets of customers. With your design suggestion you are damaging the customers who use stateless filter with IPMP, which is something that we actually document. With the proposed design in the fasttrack the change is imposed on the customers which use stateful filters with IPMP and use the undocumented qif_set_ipmp. My take it is more important to provide a smooth experience for customers that use what we document. > It seems really unfortunate, but if you feel that forcing users > through two transitions in order to get this one issue right is the > best course of action, then I guess I've failed to convince you. FWIW I think the pfhooks project should have been aware of qif_ipmp_set and they should have designed an appropriate solution. This was dropped in my lap in the 11th hour. If you feel like you can do a better design I can reassign the CR to you. It is a stopper for S10U4. Erik From Darren.Reed@sun.com Tue Apr 10 04:15:07 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l3ABF6qH019865 for ; Tue, 10 Apr 2007 04:15:06 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l3ABEJwk011810 for <@newsunmail1brm.central.sun.com:PSARC-EXT@sun.com>; Tue, 10 Apr 2007 12:14:28 +0100 (BST) 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 <0JGA009014K4D800@brm-avmta-1.central.sun.com> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Tue, 10 Apr 2007 05:14:28 -0600 (MDT) Received: from sineb-mail-2.sun.com ([192.18.19.7]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JGA002NL4K27GB0@brm-avmta-1.central.sun.com> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Tue, 10 Apr 2007 05:14:27 -0600 (MDT) Received: from fe-apac-05.sun.com (fe-apac-05.sun.com [192.18.19.176] (may be forged)) by sineb-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l3ABEPrt019196 for ; Tue, 10 Apr 2007 11:14:25 +0000 (GMT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JGA00K014DA1100@mail-apac.sun.com> (original mail from Darren.Reed@Sun.COM) for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Tue, 10 Apr 2007 19:14:25 +0800 (SGT) Received: from brunette ([129.158.87.57]) by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JGA00HPG4JZPNJ5@mail-apac.sun.com>; Tue, 10 Apr 2007 19:14:25 +0800 (SGT) Date: Tue, 10 Apr 2007 21:14:14 +1000 From: Darren Reed Subject: Re: PSARC/2007/198 IP Filter ipmp_hook_emulation Sender: Darren.Reed@sun.com To: Erik Nordmark , James Carlson Cc: PSARC-EXT@sun.com Message-id: <025a01c77b61$60acf3e0$39579e81@brunette> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Mailer: Microsoft Outlook Express 6.00.2900.3028 Content-type: text/plain; reply-type=response; charset=iso-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal X-PMX-Version: 5.2.0.264296 References: <17940.20885.641570.384838@triplex.East.Sun.COM> <17940.61594.762841.672657@gargle.gargle.HOWL> <4615B834.1090300@sun.com> <17942.13771.120846.784759@gargle.gargle.HOWL> <46167423.4000703@sun.com> <17942.42889.198518.532729@gargle.gargle.HOWL> <4616CEFD.6060408@sun.com> Status: RO Content-Length: 3534 From: "Erik Nordmark" > James Carlson wrote: >> Erik Nordmark writes: >>> James Carlson wrote: >>> >>>> If ce0 and ce1 are in a group, it should be possible for ipfilter to >>>> detect this, right? The rule set will have "ce0" in it, and the >>>> kernel portion of ipfilter will need to look this up via netinfo and >>>> that'll provide the opportunity. >>> The netinfo provider doesn't provide any information about IPMP (such a >>> group names) so there isn't an easy way for IP Filter to tell. >> >> But netinfo is talking directly to IP, isn't it? How is it that it >> cannot know? It could know, but there is nothing in the current design of IPMP that fits well with netinfo's design. To properly get the two to interact now requires a chunk of code to dress IPMP up and make it look nice until the new IPMP code comes along and pushes that out of the way. >> Won't those same customers actually be damaged far worse by the loss >> of qif_ipmp_set? For those customers who were using qif_ipmp_set and >> who install this patch, ipfilter will come up quietly and normally -- >> showing nothing in "svcs -x" and not blocking any services from >> starting -- but will not actually filter anything. > > We are talking about two different sets of customers. > > With your design suggestion you are damaging the customers who use > stateless filter with IPMP, which is something that we actually document. To the best of my knowledge, we don't. For those that have filed a bug, they've now got a bug and will have received (directly) information on how to use the above. As with other ndd things, there is no place to "turn it on" - a script needs to be manually modified to make it take place at each boot. One error (on the process side) here was that the bugs filed for ipfilter/ipmp interaction were closed when the code merge became available - these should have been left open. > With the proposed design in the fasttrack the change is imposed on the > customers which use stateful filters with IPMP and use the undocumented > qif_set_ipmp. Ok, I'm confused between "we actually document" and "undocumented". > My take it is more important to provide a smooth experience for customers > that use what we document. > >> It seems really unfortunate, but if you feel that forcing users >> through two transitions in order to get this one issue right is the >> best course of action, then I guess I've failed to convince you. > > FWIW I think the pfhooks project should have been aware of qif_ipmp_set > and they should have designed an appropriate solution. This was dropped in > my lap in the 11th hour. The path that led here was not quite that straight forward as it has only been a recently released patch (11 February 2007) that introduced qif_ipmp_set and friends with PSARC/2006/088. Until that patch (125014-02) was available, doing stateful filtering on IPMP using software only provided by Sun was not possible. The window in nevada duing which qif_ipmp_set was exposed was 5 builds (a few more than originally planned.) The pfhooks project knew that qif_ipmp_set was going to disappear but did not plan on it escaping into an official patch for Solaris 10 and hence this contingncy was not planned for. Looking at just micro(?) releases, the plan was for it to go like this: Solaris 10 Update 3 - using ipf+ipmp with "keep state" fails Solaris 10 Update 4 - using ipf+ipmp with "keep state" fails (without PSARC/2007/198) The problem is the patch between them. Darren From erik.nordmark@sun.com Tue Apr 10 09:20:13 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l3AGKCoG026024 for ; Tue, 10 Apr 2007 09:20:13 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l3AGJJdG012983; Tue, 10 Apr 2007 17:19:29 +0100 (BST) 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 <0JGA0000DIOFFH00@nwk-avmta-2.sfbay.sun.com>; Tue, 10 Apr 2007 09:19:27 -0700 (PDT) Received: from jurassic.eng.sun.com ([129.146.56.36]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JGA00ELOIOFLCD0@nwk-avmta-2.sfbay.sun.com>; Tue, 10 Apr 2007 09:19:27 -0700 (PDT) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l3AGJQYQ261476 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Apr 2007 09:19:26 -0700 (PDT) Date: Tue, 10 Apr 2007 09:19:21 -0700 From: Erik Nordmark Subject: Re: PSARC/2007/198 IP Filter ipmp_hook_emulation In-reply-to: <025a01c77b61$60acf3e0$39579e81@brunette> To: Darren Reed Cc: James Carlson , PSARC-EXT@sun.com Message-id: <461BB909.7070100@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <17940.20885.641570.384838@triplex.East.Sun.COM> <17940.61594.762841.672657@gargle.gargle.HOWL> <4615B834.1090300@sun.com> <17942.13771.120846.784759@gargle.gargle.HOWL> <46167423.4000703@sun.com> <17942.42889.198518.532729@gargle.gargle.HOWL> <4616CEFD.6060408@sun.com> <025a01c77b61$60acf3e0$39579e81@brunette> User-Agent: Thunderbird 1.5.0.5 (X11/20060911) Status: RO Content-Length: 2124 Darren Reed wrote: >> With your design suggestion you are damaging the customers who use >> stateless filter with IPMP, which is something that we actually document. > > To the best of my knowledge, we don't. [FWIW I can't tell whether your response is to the first or second part of the above sentence. I'm assuming that it is about the documentation part.] We document that with IPMP one can only do stateless filtering it in places like http://docs.sun.com/app/docs/doc/816-4554/6maoq023u?a=view in the section titled Guidelines for Using Solaris IP Filter We don't document how to do stateful filtering (qif_ipmp_set) anywhere. >> With the proposed design in the fasttrack the change is imposed on the >> customers which use stateful filters with IPMP and use the >> undocumented qif_set_ipmp. > > Ok, I'm confused between "we actually document" and "undocumented". See above what we document about stateless. Nothing on docs.sun.com (or opensolaris.org, *.sun.com) explain how to use qif_ipmp_set (apart from the emails in this ARC case itself.) > The path that led here was not quite that straight forward as it > has only been a recently released patch (11 February 2007) that > introduced qif_ipmp_set and friends with PSARC/2006/088. Until > that patch (125014-02) was available, doing stateful filtering on > IPMP using software only provided by Sun was not possible. > > The window in nevada duing which qif_ipmp_set was exposed was 5 builds > (a few more than originally planned.) The pfhooks project knew that > qif_ipmp_set was going to disappear but did not plan on it escaping > into an official patch for Solaris 10 and hence this contingncy was > not planned for. > > Looking at just micro(?) releases, the plan was for it to go like this: > Solaris 10 Update 3 - using ipf+ipmp with "keep state" fails > Solaris 10 Update 4 - using ipf+ipmp with "keep state" fails (without > PSARC/2007/198) > > The problem is the patch between them. Understood. But even so the need to do stateful filtering with IPMP seems to be more urgent than we might have thought a while back. Erik From Darren.Reed@sun.com Wed Apr 11 01:24:21 2007 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 l3B8OK2q000151 for ; Wed, 11 Apr 2007 01:24:20 -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.2) with ESMTP id l3B8NgLI003123 for <@sunmail3mpk.sfbay.sun.com:PSARC-EXT@sun.com>; Wed, 11 Apr 2007 02:23:43 -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 <0JGB00215RBIOW00@nwk-avmta-2.sfbay.sun.com> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Wed, 11 Apr 2007 01:23:42 -0700 (PDT) Received: from sineb-mail-2.sun.com ([192.18.19.7]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JGB00L1ORBG7BA0@nwk-avmta-2.sfbay.sun.com> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Wed, 11 Apr 2007 01:23:42 -0700 (PDT) Received: from fe-apac-06.sun.com (fe-apac-06.sun.com [192.18.19.177] (may be forged)) by sineb-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l3B8NekA005254 for ; Wed, 11 Apr 2007 08:23:40 +0000 (GMT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JGB00A01R8C0800@mail-apac.sun.com> (original mail from Darren.Reed@Sun.COM) for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Wed, 11 Apr 2007 16:23:40 +0800 (SGT) Received: from [129.158.87.57] by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JGB00BV1RBFR4EE@mail-apac.sun.com>; Wed, 11 Apr 2007 16:23:40 +0800 (SGT) Date: Wed, 11 Apr 2007 18:23:29 +1000 From: Darren Reed Subject: Re: PSARC/2007/198 IP Filter ipmp_hook_emulation In-reply-to: <461BB909.7070100@sun.com> Sender: Darren.Reed@sun.com To: Erik Nordmark Cc: James Carlson , PSARC-EXT@sun.com Message-id: <461C9B01.1020102@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <17940.20885.641570.384838@triplex.East.Sun.COM> <17940.61594.762841.672657@gargle.gargle.HOWL> <4615B834.1090300@sun.com> <17942.13771.120846.784759@gargle.gargle.HOWL> <46167423.4000703@sun.com> <17942.42889.198518.532729@gargle.gargle.HOWL> <4616CEFD.6060408@sun.com> <025a01c77b61$60acf3e0$39579e81@brunette> <461BB909.7070100@sun.com> User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) Status: RO Content-Length: 2469 Erik Nordmark wrote: > Darren Reed wrote: > >>> With your design suggestion you are damaging the customers who use >>> stateless filter with IPMP, which is something that we actually >>> document. >> >> To the best of my knowledge, we don't. > > [FWIW I can't tell whether your response is to the first or second > part of the above sentence. I'm assuming that it is about the > documentation part.] > > We document that with IPMP one can only do stateless filtering it in > places like > http://docs.sun.com/app/docs/doc/816-4554/6maoq023u?a=view > in the section titled > Guidelines for Using Solaris IP Filter > > We don't document how to do stateful filtering (qif_ipmp_set) anywhere. Correct. What I was referring to with "we don't" was the absence of any documentation pertaining to the use of qif_ipmp_set with pfil to enable IPFilter to filter statefully. >> The path that led here was not quite that straight forward as it >> has only been a recently released patch (11 February 2007) that >> introduced qif_ipmp_set and friends with PSARC/2006/088. Until >> that patch (125014-02) was available, doing stateful filtering on >> IPMP using software only provided by Sun was not possible. >> >> The window in nevada duing which qif_ipmp_set was exposed was 5 builds >> (a few more than originally planned.) The pfhooks project knew that >> qif_ipmp_set was going to disappear but did not plan on it escaping >> into an official patch for Solaris 10 and hence this contingncy was >> not planned for. >> >> Looking at just micro(?) releases, the plan was for it to go like this: >> Solaris 10 Update 3 - using ipf+ipmp with "keep state" fails >> Solaris 10 Update 4 - using ipf+ipmp with "keep state" fails (without >> PSARC/2007/198) >> >> The problem is the patch between them. > > Understood. > > But even so the need to do stateful filtering with IPMP seems to be > more urgent than we might have thought a while back. Up until now my answer to this has been to tell people that when the Clearview IPMP refactoring project completes, the situation will change because the current architecture of IPMP does not lend itself to integrating well with IPFilter. The pfil hack and the current work are what I'd describe as an attempt to paper mache over a bigger problem in the hope it will reduce the amount of IPMP+IPFilter related pain. As for whether or not it is urgent (or has been)...well, that's a topic for dicussion elsewhere. Darren From erik.nordmark@sun.com Wed Apr 11 11:34:32 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l3BIYV4b026368 for ; Wed, 11 Apr 2007 11:34:32 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l3BIXjwf000035; Wed, 11 Apr 2007 19:33:48 +0100 (BST) 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 <0JGC00B0NJKACD00@brm-avmta-1.central.sun.com>; Wed, 11 Apr 2007 12:33:46 -0600 (MDT) Received: from jurassic.eng.sun.com ([129.146.17.55]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JGC00G9ZJK8P5B0@brm-avmta-1.central.sun.com>; Wed, 11 Apr 2007 12:33:45 -0600 (MDT) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l3BIXeO7367260 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Apr 2007 11:33:41 -0700 (PDT) Date: Wed, 11 Apr 2007 11:33:40 -0700 From: Erik Nordmark Subject: Re: PSARC/2007/198 IP Filter ipmp_hook_emulation In-reply-to: <461C9B01.1020102@Sun.COM> To: Darren Reed Cc: James Carlson , PSARC-EXT@sun.com Message-id: <461D2A04.5090505@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <17940.20885.641570.384838@triplex.East.Sun.COM> <17940.61594.762841.672657@gargle.gargle.HOWL> <4615B834.1090300@sun.com> <17942.13771.120846.784759@gargle.gargle.HOWL> <46167423.4000703@sun.com> <17942.42889.198518.532729@gargle.gargle.HOWL> <4616CEFD.6060408@sun.com> <025a01c77b61$60acf3e0$39579e81@brunette> <461BB909.7070100@sun.com> <461C9B01.1020102@Sun.COM> User-Agent: Thunderbird 1.5.0.5 (X11/20060911) Status: RO Content-Length: 1747 Darren Reed wrote: > Erik Nordmark wrote: >> Darren Reed wrote: >> >>>> With your design suggestion you are damaging the customers who use >>>> stateless filter with IPMP, which is something that we actually >>>> document. >>> >>> To the best of my knowledge, we don't. >> >> [FWIW I can't tell whether your response is to the first or second >> part of the above sentence. I'm assuming that it is about the >> documentation part.] >> >> We document that with IPMP one can only do stateless filtering it in >> places like >> http://docs.sun.com/app/docs/doc/816-4554/6maoq023u?a=view >> in the section titled >> Guidelines for Using Solaris IP Filter >> >> We don't document how to do stateful filtering (qif_ipmp_set) anywhere. > > Correct. What I was referring to with "we don't" was the absence of any > documentation pertaining to the use of qif_ipmp_set with pfil to enable > IPFilter to filter statefully. I now see this misunderstanding. I wrote "statless" in the first sentence above and you seem to have read "stateful". > Up until now my answer to this has been to tell people that when the > Clearview IPMP > refactoring project completes, the situation will change because the > current architecture > of IPMP does not lend itself to integrating well with IPFilter. The > pfil hack and the > current work are what I'd describe as an attempt to paper mache over a > bigger problem > in the hope it will reduce the amount of IPMP+IPFilter related pain. > > As for whether or not it is urgent (or has been)...well, that's a topic > for dicussion elsewhere. The fact that is was an escalated bug seems to indicate what it is urgent from the perspective of some customers. But I agree that isn't an ARC issue. Erik From meem@triplex.east.sun.com Sat Apr 14 08:33:28 2007 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l3EFXRcQ026740 for ; Sat, 14 Apr 2007 08:33:28 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l3EFWdCl019088; Sat, 14 Apr 2007 23:32:44 +0800 (SGT) 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 <0JGH00F03V6JMF00@brm-avmta-1.central.sun.com>; Sat, 14 Apr 2007 09:32:43 -0600 (MDT) Received: from triplex.East.Sun.COM ([129.148.174.104]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JGH00GRMV6I7QB0@brm-avmta-1.central.sun.com>; Sat, 14 Apr 2007 09:32:43 -0600 (MDT) Received: from triplex.East.Sun.COM (localhost [127.0.0.1]) by triplex.East.Sun.COM (8.14.0+Sun/8.14.0) with ESMTP id l3EFWdY2025215; Sat, 14 Apr 2007 11:32:39 -0400 (EDT) Received: (from meem@localhost) by triplex.East.Sun.COM (8.14.0+Sun/8.14.0/Submit) id l3EFWdrB025212; Sat, 14 Apr 2007 11:32:39 -0400 (EDT) Date: Sat, 14 Apr 2007 11:32:39 -0400 From: Peter Memishian Subject: re: PSARC/2007/198 ipmp_hook_emulation To: psarc-ext@Sun.COM Cc: erik.nordmark@Sun.COM Message-id: <17952.62487.152474.804750@triplex.East.Sun.COM> MIME-version: 1.0 X-Mailer: VM 7.17 under 21.4 (patch 18) "Social Property" XEmacs Lucid Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 351 At this week's PSARC meeting, it appears the timer for this case was extended to give Jim more time in case he was planning to continue the discussion about the need for the tunable (neither I nor Jim was able to attend the meeting). However, Jim indicated to me offline that he did not need more time. So I'm marking this case approved. -- meem From carlsonj@phorcys.east.sun.com Sat Apr 14 16:46:18 2007 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l3ENkHkY012572 for ; Sat, 14 Apr 2007 16:46:17 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l3ENjNvx007413; Sun, 15 Apr 2007 07:45:31 +0800 (SGT) 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 <0JGI00J03HZSB300@brm-avmta-1.central.sun.com>; Sat, 14 Apr 2007 17:45:28 -0600 (MDT) Received: from phorcys.east.sun.com ([129.148.174.143]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JGI009BQHZRFGF0@brm-avmta-1.central.sun.com>; Sat, 14 Apr 2007 17:45:27 -0600 (MDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.0+Sun/8.14.0) with ESMTP id l3ENjRw1015663; Sat, 14 Apr 2007 19:45:27 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.0+Sun/8.14.0/Submit) id l3ENjRcx015660; Sat, 14 Apr 2007 19:45:27 -0400 (EDT) Date: Sat, 14 Apr 2007 19:45:27 -0400 From: James Carlson Subject: re: PSARC/2007/198 ipmp_hook_emulation In-reply-to: <17952.62487.152474.804750@triplex.East.Sun.COM> To: Peter Memishian Cc: psarc-ext@sun.com, Erik.Nordmark@sun.com Message-id: <17953.26519.541417.238546@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <17952.62487.152474.804750@triplex.East.Sun.COM> Status: RO Content-Length: 663 Peter Memishian writes: > At this week's PSARC meeting, it appears the timer for this case was > extended to give Jim more time in case he was planning to continue the > discussion about the need for the tunable (neither I nor Jim was able > to attend the meeting). However, Jim indicated to me offline that he > did not need more time. So I'm marking this case approved. At the request of the project team, "ack." I'm fine with this. -- James Carlson, Solaris Networking 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