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
[email protected]
