|
Replies:
58
-
Last Post:
Mar 8, 2006 2:58 PM
by: darrenr
|
|
|
Posts:
2,060
From:
Registered:
6/8/05
|
|
|
|
Packet Filtering Hooks Design Document Review
Posted:
Feb 23, 2006 11:22 AM
|
|
Hi,
As the leader of the team implementing a new mechanism for intercepting
packets within Solaris, I'd like to invite people to review our current
design,
which can be found at:
http://www.opensolaris.org/os/community/networking/files/pfhooks-design-2006-02-22.pdf
If you have any feedback or comments, we'd appreciate it if you could
provide it to us via the networking-discuss forum on Open Solaris no
later than the 8th of March, 2006.
Cheers,
Darren
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
Posts:
42
From:
UK
Registered:
6/29/05
|
|
|
|
Re: Packet Filtering Hooks Design Document Review
Posted:
Feb 28, 2006 1:43 AM
in response to: darrenr
|
|
Hi Darren,
I have a couple of comments. Firstly there seems no way of finding out
what zone
a logical interface is associated with. If bge0:1 is associated with
zone1 then I'd
like a way of getting this information. Also if the zoneid changes then
I'd like to
be informed of this event. Secondly I assume that devices such as
aggregations and
vlans that are shown in ifconfig, but for which there is no real
physical device will
be supported. You mention lo0 but I didn't see mention of other types of
devices. Is that
correct?
Thanks
Phil
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
2,060
From:
Registered:
6/8/05
|
|
|
|
Re: Packet Filtering Hooks Design Document Review
Posted:
Feb 28, 2006 1:41 PM
in response to: philk
|
|
Philip Kirk - Solaris Sustaining wrote:
> Hi Darren,
>
> I have a couple of comments. Firstly there seems no way of finding out
> what zone
> a logical interface is associated with. If bge0:1 is associated with
> zone1 then I'd
> like a way of getting this information.
At present this project has no plans for how it should interact
with zone information associated with a network interface.
> Also if the zoneid changes then I'd like to
> be informed of this event.
With these two requests, it sounds like you're after something like this:
zoneid_t net_getlifzoneid(phy_if_t, lif_if_t)
and in addition add a cred_t pointer to the hook_nic_event_t structure,
allowing you to use crgetzoneid() to retrieve the zone information.
I'd prefer to go that route as it provides a mechanism to access any
other cred_t data, at a later stage, without disrupting the structure.
Do you have any other suggestions on where zone information for network
interfaces or events related to zones and network interfaces could be
useful?
> Secondly I assume that devices such as aggregations and
> vlans that are shown in ifconfig, but for which there is no real
> physical device will
> be supported. You mention lo0 but I didn't see mention of other types
> of devices. Is that
> correct?
We intend to support all network interfaces in Solaris.
Darren
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
42
From:
UK
Registered:
6/29/05
|
|
|
|
Re: Packet Filtering Hooks Design Document Review
Posted:
Mar 1, 2006 2:08 AM
in response to: darrenr
|
|
>Do you have any other suggestions on where zone information for network
>interfaces or events related to zones and network interfaces could be
useful?
I have a specific need for the observability part of Clearview. I need
to know
zone related information to route traffic to only those users that should be
allowed to see it.
Thanks
Phil
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
2,060
From:
Registered:
6/8/05
|
|
|
|
Re: Packet Filtering Hooks Design Document Review
Posted:
Mar 1, 2006 11:20 AM
in response to: philk
|
|
Philip Kirk - Solaris Sustaining wrote:
> >Do you have any other suggestions on where zone information for network
> >interfaces or events related to zones and network interfaces could
> be useful?
>
> I have a specific need for the observability part of Clearview. I need
> to know
> zone related information to route traffic to only those users that
> should be
> allowed to see it.
In this case, you should really be looking at the cred_t off the
dblk_t in order to access the zoneid of the "packet".
This would require elevating db_credp to being mentionable on
the man page of dblk(9s) and hence making db_credp a stable
field of dblk_t. You might need to do something about fixing
6352430 or maybe not.
Darren
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
6,810
From:
US
Registered:
3/9/05
|
|
|
|
Re: Packet Filtering Hooks Design Document Review
Posted:
Mar 1, 2006 11:45 AM
in response to: darrenr
|
|
Darren Reed writes:
> > I have a specific need for the observability part of Clearview. I need
> > to know
> > zone related information to route traffic to only those users that
> > should be
> > allowed to see it.
>
>
> In this case, you should really be looking at the cred_t off the
> dblk_t in order to access the zoneid of the "packet".
The cred_t means something only when a user process allocated the
message. That's not true for things coming off the wire, so that
might not be very helpful here.
> This would require elevating db_credp to being mentionable on
> the man page of dblk(9s) and hence making db_credp a stable
> field of dblk_t.
Clearview is integrating in ON, and that's an Consolidation Private
interface. There's no reason that it needs to be made stable for
Clearview to use it.
--
James Carlson, KISS Network <james dot d dot carlson at sun dot com>
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
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
3,422
From:
Austin, TX, USA
Registered:
6/15/05
|
|
|
|
Re: Packet Filtering Hooks Design Document Review
Posted:
Mar 1, 2006 11:57 AM
in response to: carlsonj
|
|
On Wed, Mar 01, 2006 at 02:45:21PM -0500, James Carlson wrote:
> Darren Reed writes:
> > > I have a specific need for the observability part of Clearview. I need
> > > to know
> > > zone related information to route traffic to only those users that
> > > should be
> > > allowed to see it.
> >
> >
> > In this case, you should really be looking at the cred_t off the
> > dblk_t in order to access the zoneid of the "packet".
>
> The cred_t means something only when a user process allocated the
> message. That's not true for things coming off the wire, so that
> might not be very helpful here.
But eventually the packet will be processed and either dropped or
"consumed" by a socket with a zoneid (allzones sockets, presumably, have
the global zone as their zoneid). By then the packetness of the dblk
might be lost, I dunno (check what fireengine/yosemite do), but if not
then it could be a useful place for a hook (if there isn't one already).
Nico
--
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
2,060
From:
Registered:
6/8/05
|
|
|
|
Re: Packet Filtering Hooks Design Document Review
Posted:
Mar 1, 2006 1:33 PM
in response to: carlsonj
|
|
James Carlson wrote:
>Darren Reed writes:
>
>
>>>I have a specific need for the observability part of Clearview. I need
>>>to know
>>>zone related information to route traffic to only those users that
>>>should be
>>>allowed to see it.
>>>
>>>
>>In this case, you should really be looking at the cred_t off the
>>dblk_t in order to access the zoneid of the "packet".
>>
>>
>
>The cred_t means something only when a user process allocated the
>message. That's not true for things coming off the wire, so that
>might not be very helpful here.
>
>
Indeed, that will have to wait until there is a classifier at a
lower level that is capable of making that association.
Darren
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
2,060
From:
Registered:
6/8/05
|
|
|
|
Re: Packet Filtering Hooks Design Document Review
Posted:
Mar 1, 2006 9:56 PM
in response to: carlsonj
|
|
James Carlson wrote:
>Darren Reed writes:
>
>>>I have a specific need for the observability part of Clearview. I need
>>>to know
>>>zone related information to route traffic to only those users that
>>>should be
>>>allowed to see it.
>>>
>>
>>In this case, you should really be looking at the cred_t off the
>>dblk_t in order to access the zoneid of the "packet".
>>
>
>The cred_t means something only when a user process allocated the
>message. That's not true for things coming off the wire, so that
>might not be very helpful here.
>
I should have included that my observations with dtrace indicate
that looking at db_credp->cr_zoneid (using dtrace) is quite reliable
for packets going out of the system as a means to determine the
zone that "owns" a packet.
But if you've got a process in a zone that has been granted
net_rawaccess can't it then go and write packets out with any
IP header? This would make matching on IP address somewhat
useless for outbound packets, if so.
Darren
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
6,810
From:
US
Registered:
3/9/05
|
|
|
|
Re: Packet Filtering Hooks Design Document Review
Posted:
Mar 2, 2006 6:27 AM
in response to: darrenr
|
|
Darren Reed writes:
> I should have included that my observations with dtrace indicate
> that looking at db_credp->cr_zoneid (using dtrace) is quite reliable
> for packets going out of the system as a means to determine the
> zone that "owns" a packet.
It works only when the buffer allocation itself has process context.
So, for instance, you won't see the right result on outbound packets
that are generated by the kernel itself (e.g., ECHO-REPLY). Try
running a script like this:
#!/usr/sbin/dtrace -qs -
fbt:ip:icmp_inbound:entry
{
self->trace++;
self->cred = (struct cred *)0;
}
fbt::put:entry
/self->trace/
{
self->cred = ((mblk_t *)arg0)->b_datap->db_credp;
}
fbt::put:entry
/self->cred && self->cred->cr_zone == 0/
{
printf("no zone pointer\n");
}
fbt::put:entry
/self->cred && self->cred->cr_zone/
{
printf("%d\n", self->cred->cr_zone->zone_id);
}
fbt:ip:icmp_inbound:return
{
self->trace--;
}
"Quite reliable" probably isn't good enough for some security-related
purposes.
> But if you've got a process in a zone that has been granted
> net_rawaccess can't it then go and write packets out with any
> IP header? This would make matching on IP address somewhat
> useless for outbound packets, if so.
I'd think so.
--
James Carlson, KISS Network <james dot d dot carlson at sun dot com>
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
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
2,060
From:
Registered:
6/8/05
|
|
|
|
Re: Packet Filtering Hooks Design Document Review
Posted:
Mar 2, 2006 10:01 AM
in response to: carlsonj
|
|
James Carlson wrote:
>Darren Reed writes:
>
>>I should have included that my observations with dtrace indicate
>>that looking at db_credp->cr_zoneid (using dtrace) is quite reliable
>>for packets going out of the system as a means to determine the
>>zone that "owns" a packet.
>>
>
>It works only when the buffer allocation itself has process context.
>So, for instance, you won't see the right result on outbound packets
>that are generated by the kernel itself (e.g., ECHO-REPLY). Try
>running a script like this:
>
...
Depending on your point of view, this is arguably a bug with how credentials
are assigned to mblks.
Darren
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
6,810
From:
US
Registered:
3/9/05
|
|
|
|
Re: Packet Filtering Hooks Design Document Review
Posted:
Mar 2, 2006 10:06 AM
in response to: darrenr
|
|
Darren Reed writes:
> >It works only when the buffer allocation itself has process context.
> >So, for instance, you won't see the right result on outbound packets
> >that are generated by the kernel itself (e.g., ECHO-REPLY). Try
> >running a script like this:
> >
> ...
>
> Depending on your point of view, this is arguably a bug with how credentials
> are assigned to mblks.
Yep. From mine, it's not a bug at all.
--
James Carlson, KISS Network <james dot d dot carlson at sun dot com>
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
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
3,422
From:
Austin, TX, USA
Registered:
6/15/05
|
|
|
|
Re: Packet Filtering Hooks Design Document Review
Posted:
Mar 2, 2006 10:36 AM
in response to: carlsonj
|
|
On Thu, Mar 02, 2006 at 01:06:25PM -0500, James Carlson wrote:
> Darren Reed writes:
> > >It works only when the buffer allocation itself has process context.
> > >So, for instance, you won't see the right result on outbound packets
> > >that are generated by the kernel itself (e.g., ECHO-REPLY). Try
> > >running a script like this:
> > >
> > ...
> >
> > Depending on your point of view, this is arguably a bug with how credentials
> > are assigned to mblks.
>
> Yep. From mine, it's not a bug at all.
What's wrong with assigning the zcred to such mblks?
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
6,810
From:
US
Registered:
3/9/05
|
|
|
|
Re: Packet Filtering Hooks Design Document Review
Posted:
Mar 2, 2006 10:41 AM
in response to: nico
|
|
Nicolas Williams writes:
> > Yep. From mine, it's not a bug at all.
>
> What's wrong with assigning the zcred to such mblks?
Nothing, except that this doesn't give the answer that Darren wants,
either. You'll see the global zone ID in packets that are related to
non-global zones. (E.g., for the ECHO-REPLY message to an inbound
ECHO matching a non-global zone's IP address.)
--
James Carlson, KISS Network <james dot d dot carlson at sun dot com>
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
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
3,422
From:
Austin, TX, USA
Registered:
6/15/05
|
|
|
|
Re: Packet Filtering Hooks Design Document Review
Posted:
Mar 2, 2006 11:01 AM
in response to: carlsonj
|
|
On Thu, Mar 02, 2006 at 01:41:09PM -0500, James Carlson wrote:
> Nicolas Williams writes:
> > > Yep. From mine, it's not a bug at all.
> >
> > What's wrong with assigning the zcred to such mblks?
>
> Nothing, except that this doesn't give the answer that Darren wants,
> either. You'll see the global zone ID in packets that are related to
> non-global zones. (E.g., for the ECHO-REPLY message to an inbound
> ECHO matching a non-global zone's IP address.)
That's why I said zcred, not kcred :)
Of course, that does nothing about input packets -- like Darren says the
classifier would have to find the right cred_t.
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
6,810
From:
US
Registered:
3/9/05
|
|
|
|
Re: Packet Filtering Hooks Design Document Review
Posted:
Mar 2, 2006 11:07 AM
in response to: nico
|
|
Nicolas Williams writes:
> > Nothing, except that this doesn't give the answer that Darren wants,
> > either. You'll see the global zone ID in packets that are related to
> > non-global zones. (E.g., for the ECHO-REPLY message to an inbound
> > ECHO matching a non-global zone's IP address.)
>
> That's why I said zcred, not kcred :)
zcred doesn't do what you're expecting if you're not in a process
context.
> Of course, that does nothing about input packets -- like Darren says the
> classifier would have to find the right cred_t.
Right ... like the ICMP example I gave above.
--
James Carlson, KISS Network <james dot d dot carlson at sun dot com>
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
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
3,422
From:
Austin, TX, USA
Registered:
6/15/05
|
|
|
|
Re: Packet Filtering Hooks Design Document Review
Posted:
Mar 2, 2006 11:14 AM
in response to: carlsonj
|
|
On Thu, Mar 02, 2006 at 02:07:59PM -0500, James Carlson wrote:
> Nicolas Williams writes:
> > > Nothing, except that this doesn't give the answer that Darren wants,
> > > either. You'll see the global zone ID in packets that are related to
> > > non-global zones. (E.g., for the ECHO-REPLY message to an inbound
> > > ECHO matching a non-global zone's IP address.)
> >
> > That's why I said zcred, not kcred :)
>
> zcred doesn't do what you're expecting if you're not in a process
> context.
Right, but I think the spirit is still right: find the _right_ zcred and
set the mblk to reference it.
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
2,060
From:
Registered:
6/8/05
|
|
|
|
Re: Packet Filtering Hooks Design Document Review
Posted:
Mar 1, 2006 9:47 PM
in response to: philk
|
|
Philip Kirk - Solaris Sustaining wrote:
> >Do you have any other suggestions on where zone information for network
> >interfaces or events related to zones and network interfaces could
> be useful?
>
> I have a specific need for the observability part of Clearview. I need
> to know
> zone related information to route traffic to only those users that
> should be
> allowed to see it.
Ok, but what do you need to know zone related information about?
Routes?
Physical interfaces?
Logical interfaces?
Packets?
..something else..?
Darren
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
42
From:
UK
Registered:
6/29/05
|
|
|
|
Re: Packet Filtering Hooks Design Document Review
Posted:
Mar 6, 2006 9:01 AM
in response to: darrenr
|
|
>Ok, but what do you need to know zone related information about?
Right now I want to know what address is assigned to a zone, so I'd like
to know that bge0:1 and the address tied to it is assigned to zone A for
example.
Thanks
Phil
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
2,060
From:
Registered:
6/8/05
|
|
|
|
Re: Packet Filtering Hooks Design Document Review
Posted:
Mar 6, 2006 2:26 PM
in response to: philk
|
|
Philip Kirk - Solaris Sustaining wrote:
> >Ok, but what do you need to know zone related information about?
>
> Right now I want to know what address is assigned to a zone, so I'd like
> to know that bge0:1 and the address tied to it is assigned to zone A for
> example.
Just to be clear, we can potentially tell you what zone is associated with
an IP address, but we can't answer what IP address(es) are associated with
a zone.
Darren
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
1,992
From:
US
Registered:
3/9/05
|
|
|
|
Re: Packet Filtering Hooks Design Document
Review
Posted:
Mar 3, 2006 12:09 PM
in response to: darrenr
|
|
This isn't my primary area of expertise, but a few comments for your
consideration:
- The diagrams on pages 4 and 6 would be more helpful if they indicated
the entity (for example, the SMF service) which actually performs each
of the steps noted.
- Section 2.1 vaguely notes that there are requirements from firewall
software vendors which are not being met. It would be useful to be more
specific about what those requirements are, and why we've chosen to
defer meeting them.
- Section 3 mentions that the scope of the design may be extended beyond
its initial scope of firewall software. It would be helpful to place
this design into context if you could be more explicit about what those
possible extensions might be.
- Section 3.5 notes two models, and proceeds to pick one without any
rationale for why one meets the requirements in section 2 better than
the other.
- The network interface model in 4.1.1 seems odd to me, and possibly
clumsy to use. There's little explanation that I could find of why the
hook framework should provide differentiation between physical and
logical entities, or of why packet interception is necessarily
associated with a physical interface.
- 4.2.5: Please, can we provide a better way to control the loopback
filtering than an /etc/system setting? Can't this be determined
automatically based on the ipf.conf rules? Is loopback filtering
disabled truly the right default anymore, at least when zones and other
virtualization techniques are likely to be in use?
- Appendix B - I don't get, based on the info presented, why we don't
need analogs for Linux's NF_*_LOCAL_* hooks.
Dave
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
2,060
From:
Registered:
6/8/05
|
|
|
|
Re: Re: Packet Filtering Hooks Design Document
Review
Posted:
Mar 3, 2006 6:16 PM
in response to: dminer
|
|
Dave Miner wrote:
> This isn't my primary area of expertise, but a few comments for your
> consideration:
>
> - The diagrams on pages 4 and 6 would be more helpful if they
> indicated the entity (for example, the SMF service) which actually
> performs each of the steps noted.
>
> - Section 2.1 vaguely notes that there are requirements from firewall
> software vendors which are not being met. It would be useful to be
> more specific about what those requirements are, and why we've chosen
> to defer meeting them.
Well, the most significant one that is being deferred is 6327695.
i.e. some of their requirements fall outside of the scope of this
project and
into the realm of well recognised but nobody wanting to touch in a hurry.
> - Section 3 mentions that the scope of the design may be extended
> beyond its initial scope of firewall software. It would be helpful to
> place this design into context if you could be more explicit about
> what those possible extensions might be.
* anything where you want to change the normal flow of packets between
a network interface and a network protocol.
* anything where you want to change the packets flowing between a
network interface and a network protocol.
...and doing both of these without having to be DL_CAPABILITIES aware.
An obvious example is a NAT device that doesn't want to be involved in
filtering.
With Solaris as it is today, this interface allows you to trivially add
code to
implement something that implements random dropping of packets, amongst
other things.
> - Section 3.5 notes two models, and proceeds to pick one without any
> rationale for why one meets the requirements in section 2 better than
> the other.
In some respects, it is a fuzzy line that divides the two.
The distinction and what I believe to be better about the Linux approach is
that it doesn't suggest that the interface is limited to one purpose and one
purpose only. This ties in with your comment about section (3).
The answer is perhaps more of a "would you use a firewall interface to
implement random drop" or is it better to say "would you use an interface
to intercept packets to implement a firewall" ?
My argument is for the latter and I believe what you're asking for is some
text to be added to express this, correct?
> - The network interface model in 4.1.1 seems odd to me, and possibly
> clumsy to use. There's little explanation that I could find of why
> the hook framework should provide differentiation between physical and
> logical entities, or of why packet interception is necessarily
> associated with a physical interface.
This is a PSARC requirement. We've been told that the Solaris networking
model has both physical interfaces (which have no IP addresses) and logical
interfaces (that do have IP addresses.) We need to model that with this
API. Yes, I wish we didn't have to do it that way but redesigning how
network
interfaces are used by Solaris is out of scope for this project.
> - 4.2.5: Please, can we provide a better way to control the loopback
> filtering than an /etc/system setting? Can't this be determined
> automatically based on the ipf.conf rules?
No, it cant be automatically determined based on rules.
At some point in the future, it will be possible to use the driver's
conf file,
ipf.conf, to set this value, so it will be possible to change it at
run-time.
Code could be developed to make it possible to change at run time, without
unloading the driver, but the best fit for the current design of how
IPFilter
enables filters would be to require it to do a "soft reset". The catch with
promoting this method is then to document a stable method of enabling it at
run-time. The variable that indicates whether it is enabled or not will be
visible with "ipf -T" - a private interface with currently no supported
means
for persistent tuning settings.
So hence the fallback to using /etc/system.
> Is loopback filtering disabled truly the right default anymore, at
> least when zones and other virtualization techniques are likely to be
> in use?
Yes it is, otherwise customers will find themselves with Solaris systems
that don't
work when all of a sudden loopback RPC no longer functions. Further,
while customers
may be using zones and want IPFilter between them, above all else, by
default it needs
to be backward compatible with today's environment.
> - Appendix B - I don't get, based on the info presented, why we don't
> need analogs for Linux's NF_*_LOCAL_* hooks.
At this point in time, they're not required to deliver any functionality or
support IPFilter in Solaris for any of the existing bugs/RFEs that cover it.
The implementation should be such that it is not disruptive to add these in
the future.
Darren
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
3,045
From:
US
Registered:
3/9/05
|
|
|
|
Re: Re: Packet Filtering Hooks Design Document
Review
Posted:
Mar 5, 2006 4:52 AM
in response to: darrenr
|
|
> This is a PSARC requirement. We've been told that the Solaris networking
> model has both physical interfaces (which have no IP addresses) and logical
> interfaces (that do have IP addresses.)
While I agree that each logical interface encapsulates an IP address, it
seems odd to me to say that physical interface have no IP addresses,
especially since i cannot administrative instantiate a physical interface
without also instantiating an IP address (e.g., ifconfig always shows me
something).
It seems more natural to say that physical interface has one or more IP
addresses (though of course some or all may be administratively down).
This also matches the model we will be presenting with IP-level
observability (e.g., snooping on /dev/ipnet/bge0 will show all packets
that are sent to or received from IP addresses that are hosted on bge0 --
see http://opensolaris.org/os/community/networking/ipobs-design.pdf for
more details).
--
meem
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
2,060
From:
Registered:
6/8/05
|
|
|
|
Re: Re: Packet Filtering Hooks Design Document
Review
Posted:
Mar 5, 2006 4:19 PM
in response to: meem
|
|
Peter dot Memishian at Sun dot COM wrote:
> > This is a PSARC requirement. We've been told that the Solaris networking
> > model has both physical interfaces (which have no IP addresses) and logical
> > interfaces (that do have IP addresses.)
>
>While I agree that each logical interface encapsulates an IP address, it
>seems odd to me to say that physical interface have no IP addresses,
>especially since i cannot administrative instantiate a physical interface
>without also instantiating an IP address (e.g., ifconfig always shows me
>something).
>
A physical interface has logical interfaces and it is the logical interfaces
that have IP addresses. The correct way to model this would be to ask
for all of the logical interfaces and with that, receive all of the
addresses
assigned to them.
For example, while you can do "ifconfig bge0", the output
of this is the same as "ifconfig bge0:0" which implies that when you do
"ifconfig bge0 plumb" what you're really doing is "ifconfig bge0:0 plumb".
I would also encourage you and your project team members to have
your prelimary designs officially reviewed by PSARC (if you haven't
done so already) and to get the ARCs opinion this, well before you are
ready to line up for commitment review. While I want to agree with you
about this, I've been told numerous times that physical interfaces do
not have an IP address in Solaris.
>It seems more natural to say that physical interface has one or more IP
>addresses (though of course some or all may be administratively down).
>This also matches the model we will be presenting with IP-level
>observability (e.g., snooping on /dev/ipnet/bge0 will show all packets
>that are sent to or received from IP addresses that are hosted on bge0 --
>see http://opensolaris.org/os/community/networking/ipobs-design.pdf for
>more details).
>
If you mean "bge0" as in "bge0:0", then snooping on /dev/ipnet/bge0
only cares about 1 IP address, that for bge0:0.
If you mean "bge0" as in all logical interfaces on bge0 then does it
matter what IP address(es) are in the packet? Surely it is more
important to know which physical and logical interface a packet is
associated with? Or how else do you intend to discover when a packet
is being transmitted on bge0 that contains no IP address that would
indicate it belongs to that interface?
Darren
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
3,045
From:
US
Registered:
3/9/05
|
|
|
|
Re: Re: Packet Filtering Hooks Design Document
Review
Posted:
Mar 5, 2006 8:26 PM
in response to: darrenr
|
|
> A physical interface has logical interfaces and it is the logical interfaces
> that have IP addresses.
Yes, I know -- but from an administrative perspective, the first physical
interface is not necessarily a logical interface -- e.g., ifconfig -a does
not display it that way.
> For example, while you can do "ifconfig bge0", the output
> of this is the same as "ifconfig bge0:0" which implies that when you do
Yes, I know.
> I would also encourage you and your project team members to have
> your prelimary designs officially reviewed by PSARC (if you haven't
> done so already) and to get the ARCs opinion this, well before you are
> ready to line up for commitment review.
We will. That said, one of our team members is on PSARC, and other PSARC
members (such as Jim Carlson) have already been active in providing
feedback.
> While I want to agree with you about this, I've been told numerous
> times that physical interfaces do not have an IP address in Solaris.
That is true as per the implementation, but not as per the administrative
model.
> If you mean "bge0" as in all logical interfaces on bge0 then does it
> matter what IP address(es) are in the packet? Surely it is more
> important to know which physical and logical interface a packet is
> associated with? Or how else do you intend to discover when a packet
> is being transmitted on bge0 that contains no IP address that would
> indicate it belongs to that interface?
Please read the design document I previously mentioned. It discusses the
trade-offs and rationale behind our approach.
--
meem
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
2,060
From:
Registered:
6/8/05
|
|
|
|
Re: Re: Packet Filtering Hooks Design Document
Review
Posted:
Mar 6, 2006 11:16 AM
in response to: meem
|
|
Peter dot Memishian at Sun dot COM wrote:
> > A physical interface has logical interfaces and it is the logical interfaces
> > that have IP addresses.
>
>Yes, I know -- but from an administrative perspective, the first physical
>interface is not necessarily a logical interface -- e.g., ifconfig -a does
>not display it that way.
>
>
I think the difference here is that this project isn't intending to
provide an
administrative interface but rather an API that allows you to access data
held inside of data structures that are private to the implementation of
network protocols on Solaris.
Darren
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
2,060
From:
Registered:
6/8/05
|
|
|
|
Re: Re: Packet Filtering Hooks Design Document
Review
Posted:
Mar 6, 2006 11:31 AM
in response to: meem
|
|
Peter dot Memishian at Sun dot COM wrote:
>...
>
> > I would also encourage you and your project team members to have
> > your prelimary designs officially reviewed by PSARC (if you haven't
> > done so already) and to get the ARCs opinion this, well before you are
> > ready to line up for commitment review.
>
>We will. That said, one of our team members is on PSARC, and other PSARC
>members (such as Jim Carlson) have already been active in providing
>feedback.
>
This comment disturbs me as it implies that by having someone from
the ARC as part of your team and providing feedback outside of the
ARC environment that there is some implicit approval here.
Whilst having such people on your team can help guide to a better
design, I can't imagine that it can be held up in place of review
by an ARC.
Is the implication here that all Solaris projects should have a PSARC
member as a part of their team so that they can cut down on requirements
in dealing with the ARC?
Jim, would you like to comment here, with your PSARC hat on?
Darren
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
6,810
From:
US
Registered:
3/9/05
|
|
|
|
Re: Re: Packet Filtering Hooks Design Document
Review
Posted:
Mar 6, 2006 11:46 AM
in response to: darrenr
|
|
Darren Reed writes:
> >We will. That said, one of our team members is on PSARC, and other PSARC
> >members (such as Jim Carlson) have already been active in providing
> >feedback.
> >
>
> This comment disturbs me as it implies that by having someone from
> the ARC as part of your team and providing feedback outside of the
> ARC environment that there is some implicit approval here.
What? I can't quite tell what you're saying.
> Whilst having such people on your team can help guide to a better
> design, I can't imagine that it can be held up in place of review
> by an ARC.
>
> Is the implication here that all Solaris projects should have a PSARC
> member as a part of their team so that they can cut down on requirements
> in dealing with the ARC?
>
> Jim, would you like to comment here, with your PSARC hat on?
With my ARC hat on, I think it's great when project teams choose to
consult with particular ARC members or interns whom they feel might
have relevant experience. It's not completely fool-proof, but it does
tend to reduce the chance for surprises later. More generally, I
think it's a good idea to get folks involved in a project any time you
think they might be able to provide useful feedback.
I don't think any such consultation is tantamount to approval. I
can't predict (nor would I ever attempt to) how the other ARC members
might view any particular proposal. The ARC isn't some ivory tower;
it's just a review body made up of independent engineers. And I think
we all know how widely divergent individual engineers can be when
asked for an opinion.
If you've got a specific complaint that someone isn't following the
development process properly, or that there's some sort of improper
behavior going on, please take that up with management rather than
with any mailing list, open or otherwise. I seriously doubt that meem
or any of the other Clearview team members would do as you suggest --
holding up team composition "in place of review by an ARC" -- but if
you do, I don't think this is really the right way to solve the
problem.
--
James Carlson, KISS Network <james dot d dot carlson at sun dot com>
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
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
2,060
From:
Registered:
6/8/05
|
|
|
|
Re: Re: Packet Filtering Hooks Design Document
Review
Posted:
Mar 6, 2006 11:57 AM
in response to: carlsonj
|
|
James Carlson wrote:
>>Whilst having such people on your team can help guide to a better
>>design, I can't imagine that it can be held up in place of review
>>by an ARC.
>>
>>Is the implication here that all Solaris projects should have a PSARC
>>member as a part of their team so that they can cut down on requirements
>>in dealing with the ARC?
>>
>>Jim, would you like to comment here, with your PSARC hat on?
>>
>
>With my ARC hat on, I think it's great when project teams choose to
>consult with particular ARC members or interns whom they feel might
>have relevant experience. It's not completely fool-proof, but it does
>tend to reduce the chance for surprises later. More generally, I
>think it's a good idea to get folks involved in a project any time you
>think they might be able to provide useful feedback.
>
Absolutely, given time constraints of all parties involved.
>
>I don't think any such consultation is tantamount to approval.
>
...
That's the comment I was looking for. In the way I read what meem
said, it suggested to me that perhaps this consultation was like
getting approval. Maybe he didn't mean it to be read that way but
the comment did raise my eyebrow.
>If you've got a specific complaint that someone isn't following the
>development process properly, or that there's some sort of improper
>behavior going on..
>
...
No, that's not the case at all, far from it.
I'm more afraid that someone could spend too much time getting
consultation without ARC'ing and then go to the ARC and still end
up with a large bunch of design issues. Whenever I hear people
say they are afraid of ARCs, I hear Gary's voice in my head saying
"ARC early and ARC often". Although I don't think he means often
as in weekly/monthly, I can see the benefit in "early".
Darren
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
3,422
From:
Austin, TX, USA
Registered:
6/15/05
|
|
|
|
Re: Re: Packet Filtering Hooks Design Document
Review
Posted:
Mar 6, 2006 12:37 PM
in response to: darrenr
|
|
On Mon, Mar 06, 2006 at 11:57:50AM -0800, Darren Reed wrote:
> James Carlson wrote:
> >I don't think any such consultation is tantamount to approval.
> >
> ...
>
> That's the comment I was looking for. In the way I read what meem
> said, it suggested to me that perhaps this consultation was like
> getting approval. Maybe he didn't mean it to be read that way but
> the comment did raise my eyebrow.
ARC members tend to be able to easily catch the obvious-to-the-ARC-but-
not-to-the-i-team problems, so it's good [for the i-team] to get an ARC
member to review your cases before coming to the ARC; it probably makes
the ARC burden heavier for the ARC members though.
Nico
--
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
215
From:
Scotland
Registered:
9/15/05
|
|
|
|
Re: Re: Packet Filtering Hooks Design Document
Review
Posted:
Mar 5, 2006 5:15 PM
in response to: meem
|
|
On Sun, 5 Mar 2006 Peter dot Memishian at Sun dot COM wrote:
> addresses, especially since i cannot administrative instantiate a
> physical interface without also instantiating an IP address (e.g.,
> ifconfig always shows me something).
And I have to say, this is really really confusing for those who come
from other Unixes and don't realise that "ifconfig" actually is
pronounced as "ipconfig" on Solaris (and, as of snv, the word often
pronounced as "ifconfig" is spelled "dl-adm" ;) ).
> down). This also matches the model we will be presenting with IP-level
> observability (e.g., snooping on /dev/ipnet/bge0 will show all packets
> that are sent to or received from IP addresses that are hosted on bge0
> -- see http://opensolaris.org/os/community/networking/ipobs-design.pdf
> for more details).
So what exactly does 'bge0' mean? It seems to be shorthand for more than
one thing, context depending:
- When dladm prints 'bge0', it really means '/dev/bge0'
(notionally at least).
- When ifconfig prints 'bge0', it really means '/dev/ipnet/bge0'.
- When you plumb/unplumb bge0:n, it generally means just /that/ IP
interface only
(/dev/ipnet/bge0:n, notionally at least)
- Except for the special 0th logical interface 'bge0:0', which is also
'bge0' - which will unplumb /all/ IP addresses (just as if it were
referring notionally to the physical interface 'bge0').
Any more special cases?
regards,
--
Paul Jakma,
Network Approachability, KISS. http://quagga.ireland.sun.com/
Sun Microsystems, Dublin, Ireland. tel: EMEA x19190 / +353 1 819 9190
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
3,045
From:
US
Registered:
3/9/05
|
|
|
|
Re: Re: Packet Filtering Hooks Design Document
Review
Posted:
Mar 5, 2006 8:35 PM
in response to: paulj
|
|
> And I have to say, this is really really confusing for those who come
> from other Unixes and don't realise that "ifconfig" actually is
> pronounced as "ipconfig" on Solaris (and, as of snv, the word often
> pronounced as "ifconfig" is spelled "dl-adm" ;) ).
Correct :-)
> So what exactly does 'bge0' mean? It seems to be shorthand for more than
> one thing, context depending:
>
> - When dladm prints 'bge0', it really means '/dev/bge0'
> (notionally at least).
Actually, dladm has two separate notions of bge0 -- one at the device
layer, and one at the link layer. After Clearview's Vanity Naming is
introduced, the device layer (show-phys) will remain "bge0" but the link
layer (show-link) will show whatever name the adminstrator has chosen, or
bge0 by default. Note that if the administrator names an interface
"maint0", then that means they will still have /dev/bge0, but will also
have /dev/net/maint0 (/dev/net is where Clearview proposes to put the
vanity names for network devices).
> - When ifconfig prints 'bge0', it really means '/dev/ipnet/bge0'.
That's one way to think about it -- but really, it represents whatever has
been plumbed as an IP interface. Since the IP interface name is derived
from the link-layer name (when one exists), aforementioned vanity naming
will allow the administrator to have vanity names at this layer.
> - When you plumb/unplumb bge0:n, it generally means just /that/ IP
> interface only
> (/dev/ipnet/bge0:n, notionally at least)
Right, it is a logical interface -- strictly an IP-layer concept that is
basically a shell around an IP address.
> - Except for the special 0th logical interface 'bge0:0', which is also
> 'bge0' - which will unplumb /all/ IP addresses (just as if it were
> referring notionally to the physical interface 'bge0').
Right.
> Any more special cases?
Well, you could view IPMP as a special-case today, as it fuses together
one or more IP interfaces (but the representation will be changing as part
of the Clearview IPMP Rearchitecture). I've got a document that describes
all of this stuff in a bit more detail, but it's not yet ready for
consumption.
--
meem
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
215
From:
Scotland
Registered:
9/15/05
|
|
|
|
Re: Re: Packet Filtering Hooks Design Document
Review
Posted:
Mar 6, 2006 3:21 AM
in response to: meem
|
|
On Sun, 5 Mar 2006 Peter dot Memishian at Sun dot COM wrote:
> Correct :-)
;)
> Actually, dladm has two separate notions of bge0 -- one at the device
> layer, and one at the link layer. After Clearview's Vanity Naming is
> introduced, the device layer (show-phys) will remain "bge0" but the
> link layer (show-link) will show whatever name the adminstrator has
> chosen, or bge0 by default. Note that if the administrator names an
> interface "maint0", then that means they will still have /dev/bge0,
> but will also have /dev/net/maint0 (/dev/net is where Clearview
> proposes to put the vanity names for network devices).
Seems reasonable.
> That's one way to think about it -- but really, it represents whatever
> has been plumbed as an IP interface. Since the IP interface name is
> derived from the link-layer name (when one exists), aforementioned
> vanity naming will allow the administrator to have vanity names at
> this layer.
Ok.
> > - When you plumb/unplumb bge0:n, it generally means just /that/ IP
> > interface only
> > (/dev/ipnet/bge0:n, notionally at least)
>
> Right, it is a logical interface -- strictly an IP-layer concept that is
> basically a shell around an IP address.
Yeah. Now, I know this has /nothing/ to do with what's on Clearviews'
table at the moment, but I wish the above weren't so. E.g. it leads
chicken/egg problems with dynamic addressing (NWAM, assigning one
interface based on the prefix of another (DHCPv6/IPv6 RA interaction)),
doesn't it?
> > - Except for the special 0th logical interface 'bge0:0', which is also
> > 'bge0' - which will unplumb /all/ IP addresses (just as if it were
> > referring notionally to the physical interface 'bge0').
>
> Right.
Isn't this ever so /slightly/ at odds with the previous? :)
Anyway, not $SUBJECT - forgive me.
> Well, you could view IPMP as a special-case today, as it fuses
> together one or more IP interfaces (but the representation will be
> changing as part of the Clearview IPMP Rearchitecture). I've got a
> document that describes all of this stuff in a bit more detail, but
> it's not yet ready for consumption.
Look forward to it!
regards,
--
Paul Jakma,
Network Approachability, KISS. http://quagga.ireland.sun.com/
Sun Microsystems, Dublin, Ireland. tel: EMEA x19190 / +353 1 819 9190
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
3,045
From:
US
Registered:
3/9/05
|
|
|
|
Re: Re: Packet Filtering Hooks Design Document
Review
Posted:
Mar 6, 2006 3:33 AM
in response to: paulj
|
|
> > Right, it is a logical interface -- strictly an IP-layer concept that is
> > basically a shell around an IP address.
>
> Yeah. Now, I know this has /nothing/ to do with what's on Clearviews'
> table at the moment, but I wish the above weren't so. E.g. it leads
> chicken/egg problems with dynamic addressing (NWAM, assigning one
> interface based on the prefix of another (DHCPv6/IPv6 RA interaction)),
> doesn't it?
It creates a lot of problems. Taming it is on the roadmap for Network
Approachability -- but doing so in a backward-compatible manner will be a
challenge.
Anyway, this is a fine topic for another thread, if you or anyone else
wants to discuss further :-)
--
meem
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
1,992
From:
US
Registered:
3/9/05
|
|
|
|
Re: Re: Packet Filtering Hooks Design Document
Review
Posted:
Mar 6, 2006 8:34 AM
in response to: darrenr
|
|
Darren Reed wrote:
...
>> - Section 3.5 notes two models, and proceeds to pick one without any
>> rationale for why one meets the requirements in section 2 better than
>> the other.
>
>
> In some respects, it is a fuzzy line that divides the two.
>
> The distinction and what I believe to be better about the Linux approach is
> that it doesn't suggest that the interface is limited to one purpose and one
> purpose only. This ties in with your comment about section (3).
>
> The answer is perhaps more of a "would you use a firewall interface to
> implement random drop" or is it better to say "would you use an interface
> to intercept packets to implement a firewall" ?
>
> My argument is for the latter and I believe what you're asking for is some
> text to be added to express this, correct?
>
That's the suggestion of all of these comments. There's thinking that
is implicit which the reader has to construct on his own.
>> - The network interface model in 4.1.1 seems odd to me, and possibly
>> clumsy to use. There's little explanation that I could find of why
>> the hook framework should provide differentiation between physical and
>> logical entities, or of why packet interception is necessarily
>> associated with a physical interface.
>
>
> This is a PSARC requirement. We've been told that the Solaris networking
> model has both physical interfaces (which have no IP addresses) and logical
> interfaces (that do have IP addresses.) We need to model that with this
> API. Yes, I wish we didn't have to do it that way but redesigning how
> network
> interfaces are used by Solaris is out of scope for this project.
>
I don't see how it's necessary, for this project's purposes, to
slavishly represent the internals to that degree. There's nothing I saw
in the review that gave any evidence that consumers of this interface
would care about the physical/logical distinction, as all the useful
info is tied to logical interfaces, so why make it harder for the
consumers of the API? Even ifconfig only rarely cares, and you're not
proposing to re-implement ifconfig on this interface, anyway.
>> - 4.2.5: Please, can we provide a better way to control the loopback
>> filtering than an /etc/system setting? Can't this be determined
>> automatically based on the ipf.conf rules?
>
>
> No, it cant be automatically determined based on rules.
> At some point in the future, it will be possible to use the driver's
> conf file,
> ipf.conf, to set this value, so it will be possible to change it at
> run-time.
>
> Code could be developed to make it possible to change at run time, without
> unloading the driver, but the best fit for the current design of how
> IPFilter
> enables filters would be to require it to do a "soft reset". The catch with
> promoting this method is then to document a stable method of enabling it at
> run-time. The variable that indicates whether it is enabled or not will be
> visible with "ipf -T" - a private interface with currently no supported
> means
> for persistent tuning settings.
>
> So hence the fallback to using /etc/system.
>
>> Is loopback filtering disabled truly the right default anymore, at
>> least when zones and other virtualization techniques are likely to be
>> in use?
>
>
> Yes it is, otherwise customers will find themselves with Solaris systems
> that don't
> work when all of a sudden loopback RPC no longer functions. Further,
> while customers
> may be using zones and want IPFilter between them, above all else, by
> default it needs
> to be backward compatible with today's environment.
>
Not that I care that much about this point, but you could conceivably
provide default rulesets which provided exactly the current behavior and
enable loopback filtering. The real issue, to me, is that it's
incredibly clumsy to have to go muck with /etc/system and reboot if I
want to use zones and filtering, which is clearly a very desirable
model. This seems like a very high-priority RFE for IPFilter.
Dave
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
6,810
From:
US
Registered:
3/9/05
|
|
|
|
Re: Re: Packet Filtering Hooks Design Document
Review
Posted:
Mar 6, 2006 9:22 AM
in response to: dminer
|
|
Dave Miner writes:
> I don't see how it's necessary, for this project's purposes, to
> slavishly represent the internals to that degree. There's nothing I saw
> in the review that gave any evidence that consumers of this interface
> would care about the physical/logical distinction, as all the useful
> info is tied to logical interfaces, so why make it harder for the
> consumers of the API? Even ifconfig only rarely cares, and you're not
> proposing to re-implement ifconfig on this interface, anyway.
I don't think that's one of the possible options.
Unfortunately, Solaris makes some odd distinctions in naming addresses
as though they were interfaces, and though those distinctions just
don't exist on other operating systems and obviously do make the
programming interface more complex, they're a crucial part of both the
overall programming model and the administrative we have today.
So, unless this project is going to rewhack IP so that it represents
the interface/address distinction in a different way, I think it needs
to remain true to the underlying internals. This was one of the
issues I had during ARC review.
If not, then you can run into serious problems. For example, unlike
any other operating system I know of, a Solaris administrator may
refer to a particular address by the name of an IP interface -- e.g.,
"ce0:5". If you abstract away that distinction for the programming
interface, then there's no reasonable way that an application using
that interface could deal with such an administrator request. We'd be
creating a rift between ipfilter and ifconfig.
Maybe that rift is a good thing, but I don't think we ought to stumble
into it. We need to have a plan to ditch the current model before we
start hobbling it.
In other words, as long as we're talking about fundamental APIs, we
need to represent the system faithfully, and that means either ripping
out the offending abstraction system-wide or leaving it in place.
--
James Carlson, KISS Network <james dot d dot carlson at sun dot com>
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
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
3,045
From:
US
Registered:
3/9/05
|
|
|
|
Re: Re: Packet Filtering Hooks Design Document
Review
Posted:
Mar 6, 2006 9:51 AM
in response to: carlsonj
|
|
> In other words, as long as we're talking about fundamental APIs, we
> need to represent the system faithfully, and that means either ripping
> out the offending abstraction system-wide or leaving it in place.
Agreed. However, there is a crucial distinction here between
administrative utilities and low-level API's. For the former, we need to
think critically about whether there is a need to expose these
distinctions, or whether simply having a model of IP addresses and
(physical) IP interfaces that have sets of IP addresses is sufficient.
[ I realize you were not saying otherwise -- I just want to be explicit
to avoid continued confusion. ]
--
meem
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
6,810
From:
US
Registered:
3/9/05
|
|
|
|
Re: Re: Packet Filtering Hooks Design Document
Review
Posted:
Mar 6, 2006 10:00 AM
in response to: meem
|
|
Peter dot Memishian at Sun dot COM writes:
>
> > In other words, as long as we're talking about fundamental APIs, we
> > need to represent the system faithfully, and that means either ripping
> > out the offending abstraction system-wide or leaving it in place.
>
> Agreed. However, there is a crucial distinction here between
> administrative utilities and low-level API's. For the former, we need to
> think critically about whether there is a need to expose these
> distinctions, or whether simply having a model of IP addresses and
> (physical) IP interfaces that have sets of IP addresses is sufficient.
Yep, I agree. It should be possible to evolve the APIs and the user
interface separately, but I think it's hazardous to make changes in a
_subset_ of either. In other words, if we choose to present a
simplified model for administration (in fact, we already do, but could
do better), we should use the same model everywhere, and not allow one
feature or product to be "special" in the way it's administered.
If customers have ever told us anything about user interfaces, it's
that they must be consistent.
(The "simplification" I'm referring to is the fact that we blur the
line between physical and logical interfaces in ifconfig, especially
for the zeroth instance, but also in allowing "plumb" to mean
different things in different contexts. I think it actually makes the
system substantially harder to understand, but if you're not trying to
use multiple addresses on a single interface, it is simpler to use
this way.)
--
James Carlson, KISS Network <james dot d dot carlson at sun dot com>
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
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
1,992
From:
US
Registered:
3/9/05
|
|
|
|
Re: Re: Packet Filtering Hooks Design Document
Review
Posted:
Mar 6, 2006 10:03 AM
in response to: carlsonj
|
|
James Carlson wrote:
> Dave Miner writes:
>> I don't see how it's necessary, for this project's purposes, to
>> slavishly represent the internals to that degree. There's nothing I saw
>> in the review that gave any evidence that consumers of this interface
>> would care about the physical/logical distinction, as all the useful
>> info is tied to logical interfaces, so why make it harder for the
>> consumers of the API? Even ifconfig only rarely cares, and you're not
>> proposing to re-implement ifconfig on this interface, anyway.
>
> I don't think that's one of the possible options.
>
> Unfortunately, Solaris makes some odd distinctions in naming addresses
> as though they were interfaces, and though those distinctions just
> don't exist on other operating systems and obviously do make the
> programming interface more complex, they're a crucial part of both the
> overall programming model and the administrative we have today.
>
I would agree, if this interface is really being presented as a general
API that will be useful for many consumers to discover the details of
the configuration. That certainly isn't how I read the presentation in
the design document.
> So, unless this project is going to rewhack IP so that it represents
> the interface/address distinction in a different way, I think it needs
> to remain true to the underlying internals. This was one of the
> issues I had during ARC review.
>
> If not, then you can run into serious problems. For example, unlike
> any other operating system I know of, a Solaris administrator may
> refer to a particular address by the name of an IP interface -- e.g.,
> "ce0:5". If you abstract away that distinction for the programming
> interface, then there's no reasonable way that an application using
> that interface could deal with such an administrator request. We'd be
> creating a rift between ipfilter and ifconfig.
>
I think you're extrapolating my suggestion in the wrong direction. What
value does a consumer of this interface get in understanding the
physical interfaces, and the relationship to the logical? None that I
could come up with on my read through it.
> Maybe that rift is a good thing, but I don't think we ought to stumble
> into it. We need to have a plan to ditch the current model before we
> start hobbling it.
>
> In other words, as long as we're talking about fundamental APIs, we
> need to represent the system faithfully, and that means either ripping
> out the offending abstraction system-wide or leaving it in place.
>
I of course would be happy to see the model change, since it's clumsy in
so many directions, but of course agree that's not this project.
Dave
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
2,060
From:
Registered:
6/8/05
|
|
|
|
Re: Re: Packet Filtering Hooks Design Document
Review
Posted:
Mar 6, 2006 7:39 PM
in response to: dminer
|
|
Dave Miner wrote:
>> ...
>>
>> Yes it is, otherwise customers will find themselves with Solaris
>> systems that don't
>> work when all of a sudden loopback RPC no longer functions. Further,
>> while customers
>> may be using zones and want IPFilter between them, above all else, by
>> default it needs
>> to be backward compatible with today's environment.
>>
>
> Not that I care that much about this point, but you could conceivably
> provide default rulesets which provided exactly the current behavior
> and enable loopback filtering. The real issue, to me, is that it's
> incredibly clumsy to have to go muck with /etc/system and reboot if I
> want to use zones and filtering, which is clearly a very desirable
> model. This seems like a very high-priority RFE for IPFilter.
In making it easy to enable loopback filtering, it changes the nature of
this choice from being a policy decision to something that can be more
ad-hoc. I'm concerned about the nature of that from a security
perspective - can it become too easy to accidently disable/enable?
Do you view being able to enable/disable it via the driver's .conf file
as being equally clumsy?
Darren
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
1,992
From:
US
Registered:
3/9/05
|
|
|
|
Re: Re: Packet Filtering Hooks Design Document
Review
Posted:
Mar 7, 2006 8:22 AM
in response to: darrenr
|
|
Darren Reed wrote:
> Dave Miner wrote:
>
>>> ...
>>>
>>> Yes it is, otherwise customers will find themselves with Solaris
>>> systems that don't
>>> work when all of a sudden loopback RPC no longer functions. Further,
>>> while customers
>>> may be using zones and want IPFilter between them, above all else, by
>>> default it needs
>>> to be backward compatible with today's environment.
>>>
>>
>> Not that I care that much about this point, but you could conceivably
>> provide default rulesets which provided exactly the current behavior
>> and enable loopback filtering. The real issue, to me, is that it's
>> incredibly clumsy to have to go muck with /etc/system and reboot if I
>> want to use zones and filtering, which is clearly a very desirable
>> model. This seems like a very high-priority RFE for IPFilter.
>
>
> In making it easy to enable loopback filtering, it changes the nature of
> this choice from being a policy decision to something that can be more
> ad-hoc. I'm concerned about the nature of that from a security
> perspective - can it become too easy to accidently disable/enable?
>
I've heard several respected security thinkers take the position that
ease-of-use for security features makes them more likely to be used
effectively.
> Do you view being able to enable/disable it via the driver's .conf file
> as being equally clumsy?
>
I'd rather put it in terms of what I'd think would be the user requirements:
- it should be easy for the user to make this selection in the context
of other tasks they'd be doing to configure the filtering feature. It
should be part of what they'd normally do to set other aspects of
filtering policy.
- it must not require a reboot or similarly serious discontinuity of
system services to take effect.
If you could meet those requirements putting it in /etc/system, or a
driver .conf file, then I wouldn't necessarily care.
Dave
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
2,060
From:
Registered:
6/8/05
|
|
|
|
Re: Re: Packet Filtering Hooks Design Document
Review
Posted:
Mar 7, 2006 2:24 PM
in response to: dminer
|
|
Dave Miner wrote:
> ...
> I'd rather put it in terms of what I'd think would be the user
> requirements:
>
> - it should be easy for the user to make this selection in the context
> of other tasks they'd be doing to configure the filtering feature. It
> should be part of what they'd normally do to set other aspects of
> filtering policy.
>
> - it must not require a reboot or similarly serious discontinuity of
> system services to take effect.
>
> If you could meet those requirements putting it in /etc/system, or a
> driver .conf file, then I wouldn't necessarily care.
Not in /etc/system (only read at reboot), but in a driver .conf file
(read when driver is loaded), yes.
Although it does mean unloading IPFilter if it is already loaded...no
service discontinuity.
There's currently no other supported mechanism to put persistant values
somewhere that are used to "tune" IPFilter.
Thanks,
Darren
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
3,422
From:
Austin, TX, USA
Registered:
6/15/05
|
|
|
|
Re: Re: Packet Filtering Hooks Design Document
Review
Posted:
Mar 7, 2006 2:37 PM
in response to: darrenr
|
|
On Tue, Mar 07, 2006 at 02:24:33PM -0800, Darren Reed wrote:
> Not in /etc/system (only read at reboot), but in a driver .conf file
> (read when driver is loaded), yes.
>
> Although it does mean unloading IPFilter if it is already loaded...no
> service discontinuity.
/etc/system has the one benfit of being a single place to look. And
some such settings can be changed at runtime (though mdb is not a sysadmin-
friendly tool for doing so).
driver .conf files are simply less friendly. Not that /etc/system is
all that friendly.
I suspect this struggle will continue until a project comes along to
rationalize and replace/clean-up/integrate ndd and /etc/system settings
into a sysadmin-friendly framework that properly supports presistence
(but also temporary settings).
Nico
--
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
1,992
From:
US
Registered:
3/9/05
|
|
|
|
Re: Re: Packet Filtering Hooks Design Document
Review
Posted:
Mar 7, 2006 2:59 PM
in response to: nico
|
|
Nicolas Williams wrote:
> On Tue, Mar 07, 2006 at 02:24:33PM -0800, Darren Reed wrote:
>> Not in /etc/system (only read at reboot), but in a driver .conf file
>> (read when driver is loaded), yes.
>>
>> Although it does mean unloading IPFilter if it is already loaded...no
>> service discontinuity.
>
> /etc/system has the one benfit of being a single place to look. And
> some such settings can be changed at runtime (though mdb is not a sysadmin-
> friendly tool for doing so).
>
And the drawback of being a free-for-all dump of random things that
wouldn't necessarily occur to anyone who's not a serious Solaris expert
as being the obvious place to configure anything. Not that a driver
.conf file is entirely free of those attributes...
> driver .conf files are simply less friendly. Not that /etc/system is
> all that friendly.
>
Neither of them is likely to meet the "in the flow" requirement I
suggested without some assistance from a higher-level tool. Perhaps
there's a good reason to disagree with the requirement.
> I suspect this struggle will continue until a project comes along to
> rationalize and replace/clean-up/integrate ndd and /etc/system settings
> into a sysadmin-friendly framework that properly supports presistence
> (but also temporary settings).
>
I'm skeptical such a project will occur anytime soon, at least on Sun's
dime, because these are not in the class of tasks that most admins
should have to be doing and so it's easy to find uses of our money which
will give more demonstrable returns. I don't think the two solutions
Darren suggested are the only ones possible for this case, but what do I
know? ;-)
Dave
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
2,060
From:
Registered:
6/8/05
|
|
|
|
Re: Re: Packet Filtering Hooks Design Document
Review
Posted:
Mar 7, 2006 3:10 PM
in response to: dminer
|
|
Dave Miner wrote:
> Nicolas Williams wrote:
> ...
>
>> I suspect this struggle will continue until a project comes along to
>> rationalize and replace/clean-up/integrate ndd and /etc/system settings
>> into a sysadmin-friendly framework that properly supports presistence
>> (but also temporary settings).
>>
>
> I'm skeptical such a project will occur anytime soon, at least on
> Sun's dime, because these are not in the class of tasks that most
> admins should have to be doing and so it's easy to find uses of our
> money which will give more demonstrable returns. I don't think the
> two solutions Darren suggested are the only ones possible for this
> case, but what do I know? ;-)
Do we have anywhere that we can put arbitrary commands to 'tune'
networking at bootup?
If yes, then there are other "easy" options...
Darren
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
1,992
From:
US
Registered:
3/9/05
|
|
|
|
Re: Re: Packet Filtering Hooks Design Document
Review
Posted:
Mar 7, 2006 3:19 PM
in response to: darrenr
|
|
Darren Reed wrote:
> Dave Miner wrote:
>
>> Nicolas Williams wrote:
>> ...
>>
>>> I suspect this struggle will continue until a project comes along to
>>> rationalize and replace/clean-up/integrate ndd and /etc/system settings
>>> into a sysadmin-friendly framework that properly supports presistence
>>> (but also temporary settings).
>>>
>>
>> I'm skeptical such a project will occur anytime soon, at least on
>> Sun's dime, because these are not in the class of tasks that most
>> admins should have to be doing and so it's easy to find uses of our
>> money which will give more demonstrable returns. I don't think the
>> two solutions Darren suggested are the only ones possible for this
>> case, but what do I know? ;-)
>
>
> Do we have anywhere that we can put arbitrary commands to 'tune'
> networking at bootup?
>
> If yes, then there are other "easy" options...
>
Well, you can create any old service you like. I think you even have a
couple already related to ipf whose start methods might be able to
perform the dirty deed.
Dave
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
3,422
From:
Austin, TX, USA
Registered:
6/15/05
|
|
|
|
Re: Re: Packet Filtering Hooks Design Document
Review
Posted:
Mar 7, 2006 3:26 PM
in response to: darrenr
|
|
On Tue, Mar 07, 2006 at 03:10:24PM -0800, Darren Reed wrote:
> Do we have anywhere that we can put arbitrary commands to 'tune'
> networking at bootup?
>
> If yes, then there are other "easy" options...
If all of them can be changed at runtime then SMF services will do.
Just add properites and method code to do the right thing with them to
the various network services and/or NWAM framework.
Any one-time only settings will have to either be fixed to be settable
at runtime or else left alone as /etc/system or driver .conf settings.
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
3,422
From:
Austin, TX, USA
Registered:
6/15/05
|
|
|
|
Re: Re: Packet Filtering Hooks Design Document
Review
Posted:
Mar 7, 2006 3:10 PM
in response to: dminer
|
|
On Tue, Mar 07, 2006 at 05:59:15PM -0500, Dave Miner wrote:
> Nicolas Williams wrote:
> >/etc/system has the one benfit of being a single place to look. And
> >some such settings can be changed at runtime (though mdb is not a sysadmin-
> >friendly tool for doing so).
> >
>
> And the drawback of being a free-for-all dump of random things that
> wouldn't necessarily occur to anyone who's not a serious Solaris expert
> as being the obvious place to configure anything. Not that a driver
> .conf file is entirely free of those attributes...
Yes, which leaves us... wanting something else entirely, no?
> >I suspect this struggle will continue until a project comes along to
> >rationalize and replace/clean-up/integrate ndd and /etc/system settings
> >into a sysadmin-friendly framework that properly supports presistence
> >(but also temporary settings).
> >
>
> I'm skeptical such a project will occur anytime soon, at least on Sun's
> dime, because these are not in the class of tasks that most admins
> should have to be doing and so it's easy to find uses of our money which
> will give more demonstrable returns. I don't think the two solutions
> Darren suggested are the only ones possible for this case, but what do I
> know? ;-)
I have no idea how likely such a project is, but sysadmins certainly
have had to set /etc/system, driver .conf and ndd settings, and they've
had to write rc files for it, and now SMF services. So I do think that
this state of affairs cries out for a better solution.
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
276
From:
US
Registered:
3/9/05
|
|
|
|
Re: Re: Packet Filtering Hooks Design Document
Review
Posted:
Mar 7, 2006 3:15 PM
in response to: nico
|
|
Nicolas Williams writes:
> On Tue, Mar 07, 2006 at 05:59:15PM -0500, Dave Miner wrote:
> > >I suspect this struggle will continue until a project comes along to
> > >rationalize and replace/clean-up/integrate ndd and /etc/system settings
> > >into a sysadmin-friendly framework that properly supports presistence
> > >(but also temporary settings).
> > >
> >
> > I'm skeptical such a project will occur anytime soon, at least on Sun's
> > dime, because these are not in the class of tasks that most admins
> > should have to be doing and so it's easy to find uses of our money which
> > will give more demonstrable returns. I don't think the two solutions
> > Darren suggested are the only ones possible for this case, but what do I
> > know? ;-)
>
> I have no idea how likely such a project is, but sysadmins certainly
> have had to set /etc/system, driver .conf and ndd settings, and they've
> had to write rc files for it, and now SMF services. So I do think that
> this state of affairs cries out for a better solution.
Early SMF design called for kernel read access for the repository so
that it could be used for things like driver settings. Actual SMF
implementation ran into the reality of too much work and too few
resources. If anyone was contemplating attacking the general problem
without using SMF, I'd like to understand why. :)
But, in the absense of folks/funding to do work, it's all academic.
I'm hopeful that someday the SMF team will be able to move this work
back onto our priority list, but it isn't in the documented future.
liane
--
Liane Praza, Solaris Kernel Development
liane dot praza at sun dot com - http://blogs.sun.com/lianep
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
630
From:
HK
Registered:
3/9/05
|
|
|
|
Re: Re: Packet Filtering Hooks Design Document
Review
Posted:
Mar 7, 2006 3:31 PM
in response to: nico
|
|
Nicolas Williams wrote:
> I have no idea how likely such a project is, but sysadmins certainly
> have had to set /etc/system, driver .conf and ndd settings, and they've
> had to write rc files for it, and now SMF services. So I do think that
> this state of affairs cries out for a better solution.
At least for the ndd part, it is in scope of the NWAM project.
So we hope that what we will provide will make the lives of
sysadmins happier regarding network configuration ;-)
--
K. Poon.
kacheong dot poon at sun dot com
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
110
From:
US
Registered:
3/9/05
|
|
|
|
Re: Re: Packet Filtering Hooks Design Document
Review
Posted:
Mar 7, 2006 7:15 PM
in response to: dminer
|
|
Dave Miner wrote On 03/07/06 08:22,:
[about enabling/disabling whether IPFilter filters loopback traffic]
> - it should be easy for the user to make this selection in the context
> of other tasks they'd be doing to configure the filtering feature. It
> should be part of what they'd normally do to set other aspects of
> filtering policy.
Absolutely. Ideally, this parameter setting should be considered part
of the rule set and should be stored in the same file. A set of rules
is always written with a particular expectation of this setting and it
would be wrong to execute it with the wrong setting because it would
not have the intended effect.
But that doesn't mean it's easy to add such a notation to the rule file
format in a compatible way.
-=] Mike [=-
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
2,060
From:
Registered:
6/8/05
|
|
|
|
Re: Re: Packet Filtering Hooks Design Document
Review
Posted:
Mar 7, 2006 7:27 PM
in response to: mditto
|
|
Mike Ditto wrote:
>Dave Miner wrote On 03/07/06 08:22,:
>[about enabling/disabling whether IPFilter filters loopback traffic]
>
>
>>- it should be easy for the user to make this selection in the context
>>of other tasks they'd be doing to configure the filtering feature. It
>>should be part of what they'd normally do to set other aspects of
>>filtering policy.
>>
>>
>
>Absolutely. Ideally, this parameter setting should be considered part
>of the rule set and should be stored in the same file. A set of rules
>is always written with a particular expectation of this setting and it
>would be wrong to execute it with the wrong setting because it would
>not have the intended effect.
>
>But that doesn't mean it's easy to add such a notation to the rule file
>format in a compatible way.
>
>
My preference is to divide describing the security policy (filter rules)
from system or filter configuration.
You can currently do:
$ ipf -f /etc/ipf/ipf.conf
to load rules and to remove them, do:
$ ipf -rf /etc/ipf/ipf.conf
If you start putting "settings" in this file, what effect does a
"remove" have
on them? Or maybe only part of the file or certain lines are recognised,
depending on command line switches or....it becomes a very messy
situation.
The sendmail.cf file is a great historical example of what happens when you
merge setting options and policy.
Darren
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
1,172
From:
US
Registered:
3/9/05
|
|
|
|
Re: Re: Packet Filtering Hooks Design Document
Review
Posted:
Mar 7, 2006 7:39 PM
in response to: darrenr
|
|
Darren Reed wrote:
> If you start putting "settings" in this file, what effect does a
> "remove" have
> on them? Or maybe only part of the file or certain lines are recognised,
> depending on command line switches or....it becomes a very messy situation.
> The sendmail.cf file is a great historical example of what happens when you
> merge setting options and policy.
>
The rules in any single ipf.conf file should describe a
consistent, safe set of ipfilter rules for a single
operating state.
They should be either all applied or none.
- Bart
--
Bart Smaalders Solaris Kernel Performance
barts at cyber dot eng dot sun dot com http://blogs.sun.com/barts
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
6,810
From:
US
Registered:
3/9/05
|
|
|
|
Re: Re: Packet Filtering Hooks Design Document
Review
Posted:
Mar 8, 2006 7:43 AM
in response to: barts
|
|
Bart Smaalders writes:
> The rules in any single ipf.conf file should describe a
> consistent, safe set of ipfilter rules for a single
> operating state.
>
> They should be either all applied or none.
I don't think it's as simple as that in general.
Suppose my configuration says this:
block in quick on foobar0 from ! 192.168.254.0/24 to any
Should the rule set fail to load if "foobar0" doesn't exist in the
system? What should it do if that interface shows up later? What
should it do if I have (or later gain) *OTHER* interfaces on the
system that are not listed in the current rules?
As far as I know, there's currently no way to express the idea that
any new interface should not be brought up unless there are matching
filter rules ready to go for that interface, so it seems to me that
there's a gap between the idea of an "all or none" policy and what
would work.
--
James Carlson, KISS Network <james dot d dot carlson at sun dot com>
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
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
1,172
From:
US
Registered:
3/9/05
|
|
|
|
Re: Re: Packet Filtering Hooks Design Document
Review
Posted:
Mar 8, 2006 11:30 AM
in response to: carlsonj
|
|
James Carlson wrote:
> Bart Smaalders writes:
>> The rules in any single ipf.conf file should describe a
>> consistent, safe set of ipfilter rules for a single
>> operating state.
>>
>> They should be either all applied or none.
>
> I don't think it's as simple as that in general.
>
> Suppose my configuration says this:
>
> block in quick on foobar0 from ! 192.168.254.0/24 to any
>
> Should the rule set fail to load if "foobar0" doesn't exist in the
> system? What should it do if that interface shows up later? What
> should it do if I have (or later gain) *OTHER* interfaces on the
> system that are not listed in the current rules?
>
> As far as I know, there's currently no way to express the idea that
> any new interface should not be brought up unless there are matching
> filter rules ready to go for that interface, so it seems to me that
> there's a gap between the idea of an "all or none" policy and what
> would work.
>
Or perhaps we should just say that
block in all
block out all
should be the first lines in all rule sets, thus blocking IO on
interfaces not explicitly configured in the rule set.
- Bart
--
Bart Smaalders Solaris Kernel Performance
barts at cyber dot eng dot sun dot com http://blogs.sun.com/barts
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
2,060
From:
Registered:
6/8/05
|
|
|
|
Re: Re: Packet Filtering Hooks Design Document
Review
Posted:
Mar 8, 2006 2:39 PM
in response to: carlsonj
|
|
James Carlson wrote:
>Bart Smaalders writes:
>
>
>>The rules in any single ipf.conf file should describe a
>>consistent, safe set of ipfilter rules for a single
>>operating state.
>>
>>They should be either all applied or none.
>>
>>
>
>I don't think it's as simple as that in general.
>
>Suppose my configuration says this:
>
> block in quick on foobar0 from ! 192.168.254.0/24 to any
>
>
A rule will never fail to load because an interface name specified in it
doesn't exist at the time it is loaded. So you can load the above rule,
even though it will likely never match anything. This makes it slightly
more susceptible to user-error but in my experience this happens very
very infrequently.
Hostnames and port names are treated differently and if they fail to be
resolved when you try to load the file, an error will be generated.
Darren
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
3,422
From:
Austin, TX, USA
Registered:
6/15/05
|
|
|
|
Re: Re: Packet Filtering Hooks Design Document
Review
Posted:
Mar 8, 2006 2:54 PM
in response to: darrenr
|
|
On Wed, Mar 08, 2006 at 02:39:51PM -0800, Darren Reed wrote:
> James Carlson wrote:
>
> >Bart Smaalders writes:
> >
> >
> >>The rules in any single ipf.conf file should describe a
> >>consistent, safe set of ipfilter rules for a single
> >>operating state.
> >>
> >>They should be either all applied or none.
> >>
> >>
> >
> >I don't think it's as simple as that in general.
> >
> >Suppose my configuration says this:
> >
> > block in quick on foobar0 from ! 192.168.254.0/24 to any
> >
> >
>
> A rule will never fail to load because an interface name specified in it
> doesn't exist at the time it is loaded. So you can load the above rule,
> even though it will likely never match anything. This makes it slightly
> more susceptible to user-error but in my experience this happens very
> very infrequently.
Will such rules be installed when such interfaces appear?
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
2,060
From:
Registered:
6/8/05
|
|
|
|
Re: Re: Packet Filtering Hooks Design Document
Review
Posted:
Mar 8, 2006 2:58 PM
in response to: nico
|
|
Nicolas Williams wrote:
>On Wed, Mar 08, 2006 at 02:39:51PM -0800, Darren Reed wrote:
>
>
>>James Carlson wrote:
>>
>>
>>
>>>Bart Smaalders writes:
>>>
>>>
>>>
>>>
>>>>The rules in any single ipf.conf file should describe a
>>>>consistent, safe set of ipfilter rules for a single
>>>>operating state.
>>>>
>>>>They should be either all applied or none.
>>>>
>>>>
>>>>
>>>>
>>>I don't think it's as simple as that in general.
>>>
>>>Suppose my configuration says this:
>>>
>>>block in quick on foobar0 from ! 192.168.254.0/24 to any
>>>
>>>
>>>
>>>
>>A rule will never fail to load because an interface name specified in it
>>doesn't exist at the time it is loaded. So you can load the above rule,
>>even though it will likely never match anything. This makes it slightly
>>more susceptible to user-error but in my experience this happens very
>>very infrequently.
>>
>>
>
>Will such rules be installed when such interfaces appear?
>
>
Yes. Or perhaps a better way to think of it is that interface names are
revalidated when an interface is added or removed from Solaris. This
is nothing new, it's always been that way.
Darren
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
1,992
From:
US
Registered:
3/9/05
|
|
|
|
Re: Re: Packet Filtering Hooks Design Document
Review
Posted:
Mar 8, 2006 8:28 AM
in response to: darrenr
|
|
Darren Reed wrote:
> Mike Ditto wrote:
>
>> Dave Miner wrote On 03/07/06 08:22,:
>> [about enabling/disabling whether IPFilter filters loopback traffic]
>>
>>
>>> - it should be easy for the user to make this selection in the context
>>> of other tasks they'd be doing to configure the filtering feature. It
>>> should be part of what they'd normally do to set other aspects of
>>> filtering policy.
>>>
>>>
>> Absolutely. Ideally, this parameter setting should be considered part
>> of the rule set and should be stored in the same file. A set of rules
>> is always written with a particular expectation of this setting and it
>> would be wrong to execute it with the wrong setting because it would
>> not have the intended effect.
>>
>> But that doesn't mean it's easy to add such a notation to the rule file
>> format in a compatible way.
>>
>>
>
> My preference is to divide describing the security policy (filter rules)
> from system or filter configuration.
>
This may be a reasonable position. The issue, to me, is that I think
the loopback filtering is part of the former, not the latter.
Dave
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
