On 03/09/2018 05:18 AM, Robert White wrote:
On 03/08/2018 01:12 AM, zrm wrote:
(2.a) The client is adversarial and is trying to circumvent the firewall
rules.
Nope. PCP is not a firewall. The questions of trust and config are in
the humans hand.
If the PCP deamon's configuration says the mapping should be valid, then
your firewall rules should not violate that promise.
If your firewall rules say that a mapping should not be honored then the
PCP deamon's configuration should not be lying about it to the client.
That's the issue. The firewall rules determine how the PCP daemon should
process the request. It helps no one to force the administrator to
specify the same rules verbatim in two separate places.
You are also missing the part where the administrator may want to issue
the blocked ports to specific users after specific requests to the PCP
demon, so probing your own firewall actually removes features.
I see no apparent reason to want the PCP PEER rules to differ from the
firewall rules. You can have client-specific firewall rules. Can you
provide an example where allowing a particular PCP PEER request is
desirable yet allowing the same connection from the same client to be
made implicitly is not, or vice versa?
Moreover, it would be possible to implement PCP exceptions to the normal
firewall rules if you really wanted that for some specific reason, but
that doesn't change the common/baseline case where the rules by default
should be the same for both.
(2.b) The client is asking the PCP daemon to recreate a connection that
was valid with the previous configuration but not the current
configuration.
Then it will fail because the new PCP deamon is newly configured.
It should fail if the new configuration doesn't allow the old
connection. Which requires evaluating the connection parameters against
the current firewall rules, since it should always be allowed if the
connection would be allowed implicitly as a new connection, even if some
additional connections are specifically allowed as PCP requests.
--
To unsubscribe from this list: send the line "unsubscribe netfilter" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
