Peter Memishian writes: > > > In any event, I wasn't arguing against a strict default. I was > > arguing against violating explicit admin-specified filtering policy > > merely because some local service needing an exemption is enabled. > > Explicit configuration of filters should trump services. > > This was my thinking as well -- but it seems to be an intentional design > decision with per-socket IPsec policy overrides.
Assuming that we're going to keep these eerily similar things distinct, I think that overriding IPsec policy and IPsec-related filtering could be a separate concern from overriding IP Filter rules. At least with IP Filter, the whole point is to drop (or possibly modify and redirect) packets based on the packet contents. It's a general purpose "what things do I allow in networking?" issue. With IPsec, though, it's a means to an end: setting up IPsec policy. It's not the first place I'd expect a user to land if he was trying to block particular services in general. Thus (maybe) there's a distinction to draw between allowing services to configure one but not the other. > The argument that the > admin both set the original policy and started the application that > conflicted with it (and thus got what he wanted with minimal fuss) made > some sense to me back in simpler times, but with the level of complexity > and feature integration today, I find it hard to defend. +1 -- James Carlson, Solaris Networking <james.d.carlson at sun.com> Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
