On 03/10/2018 04:20 PM, zrm wrote: > 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. Two separate systems, two separate administrative tasks. You don't see any reason _yet_... but persist and you will. I've already given you two reasons that you skipped right over. Why you think "the administrator [would] specify the same rules verbatim in two separate places." is the fundamental failure of your vision. >> 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? I'm getting that you don't see. I provided several scenarios for why the PEER rules would be different than the firewall rules. Lets wanting to keep the default nat ranges away from your SIP traffic was one such example. In general, PCP clients can supply more information in their requests than generic firewall traffic. So with the additional information you may well want to issue ports to PCP clients that you would never issue to a random client. You might want to restrict the PCP clients to subsets of what you are going to do generically. So that "identical rules" thing is one heck of a limiting assumption. -- 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
