Re: Removing PF
On Sun, 14 Apr 2019, John D. Baker wrote: > On Sun, 14 Apr 2019, Mindaugas Rasiukevicius wrote: > > > "John D. Baker" wrote: > > > > > So, I suppose the issue is that although the interface will have > > > multiple addresses, I wish to treat each address independenly, but > > > need to do so symbolically as (at least one of) the exact addresses > > > cannot be known ahead of time or guaranteed to be current. > > > > Would it help if you could apply a filter to the dynamic address list, > > e.g. ifaddrs(netif0, 10.0.0.0/8) or ifaddrs(netif0, ! 10.0.0.0/8)? The > > latter would include all addresses which are not in the 10/8 network. > > That might work. There are at least 2 disparate subnets from which my > ISP may assign addresses, so I'd either need multiple filters (or filter Now that I think about it, the "ifaddrs(netif0, ! net/mask)" form would solve the problem best for me as it would elide any secondary address which I'd have statically assigned anyway, leaving only the ISP-assigned address regardless of which pool from which it was drawn. It also alleviates the need to do extra interface/address manipulation in the dhcpcd exit-hook script as the position of the address in the list is no-longer critical. -- |/"\ John D. Baker, KN5UKS NetBSD Darwin/MacOS X |\ / jdbaker[snail]consolidated[flyspeck]net OpenBSDFreeBSD | X No HTML/proprietary data in email. BSD just sits there and works! |/ \ GPGkeyID: D703 4A7E 479F 63F8 D3F4 BD99 9572 8F23 E4AD 1645
Re: Removing PF
On Sun, 14 Apr 2019, Mindaugas Rasiukevicius wrote: > "John D. Baker" wrote: > > > So, I suppose the issue is that although the interface will have > > multiple addresses, I wish to treat each address independenly, but > > need to do so symbolically as (at least one of) the exact addresses > > cannot be known ahead of time or guaranteed to be current. > > Would it help if you could apply a filter to the dynamic address list, > e.g. ifaddrs(netif0, 10.0.0.0/8) or ifaddrs(netif0, ! 10.0.0.0/8)? The > latter would include all addresses which are not in the 10/8 network. That might work. There are at least 2 disparate subnets from which my ISP may assign addresses, so I'd either need multiple filters (or filter specification that is a list), or a filter address/mask that would cover all of them. That data is not available to subscribers. I'm aware of it only by inspection of my router during connectivity anomalies. If the list returned by ifaddrs(netifN) can be guaranteed to be in the same order every time, a filter by position (offset) in the list would be much simpler for the user, say "ifaddrs(netif0, 0)". If the filter specification looks like an address/netmask, filter that way, otherwise assume it's a position reference and return the Nth address in the list. -- |/"\ John D. Baker, KN5UKS NetBSD Darwin/MacOS X |\ / jdbaker[snail]consolidated[flyspeck]net OpenBSDFreeBSD | X No HTML/proprietary data in email. BSD just sits there and works! |/ \ GPGkeyID: D703 4A7E 479F 63F8 D3F4 BD99 9572 8F23 E4AD 1645
Re: Removing PF
"John D. Baker" wrote: > > > > ifaddrs(netifN) represents a list of addresses currently assigned the > > interface i.e. it works dynamically, you do not need to `npfctl reload`. > > So, to be clear, if an interfaces gains/sheds addresses, ifaddrs(netifN) > will always reflect the current set of addresses on that interface > each time ifaddrs(netifN) is used, correct? Correct. > <...> > > So, I suppose the issue is that although the interface will have > multiple addresses, I wish to treat each address independenly, but > need to do so symbolically as (at least one of) the exact addresses > cannot be known ahead of time or guaranteed to be current. > Would it help if you could apply a filter to the dynamic address list, e.g. ifaddrs(netif0, 10.0.0.0/8) or ifaddrs(netif0, ! 10.0.0.0/8)? The latter would include all addresses which are not in the 10/8 network. -- Mindaugas
Re: Removing PF
On Thu, Apr 04, 2019 at 10:33:47PM +0100, Mindaugas Rasiukevicius wrote: > > - https://gnats.netbsd.org/53199 (Patrick Welche) > > Not sure what exactly the submitter wants. Then please feel free to ask specific questions! > NPF establishes per-interface > state (for a good reason). It seems that some users want a global state > which would be picked up on any interface and in either direction. This > will be added to NetBSD with the next NPF sync from Github; however, there > are drawbacks of such behaviour and it will not be a default. >From this part, it sounds as though you do understand, so to quote the PR: If it is obvious to you how to achieve this with npf, please update the documentation so that it is obvious to others. Patrick
Re: Removing PF
On 07/04/2019 23:29, Mindaugas Rasiukevicius wrote: "John D. Baker" wrote: - dynamic ifaddrs(netifN) (John D. Baker) The "ifaddrs(netifN)" function is what evaluates the addresses on the interface with each reference in a rule, or so the documentation makes it appear. Contrast with "inet4(netifN)" or "inet6(netifN)" that is only evaluated when the configuration file is loaded. "ifaddrs(netifN)" appears to be the equivalent of pf's "(netifN)", but always returns the full list of all addresses on an interface, so cannot be used in a NAT (map foo -> bar) statement. Hence the desire to select a subset or at least only the first address in the list, e.g., pf's "(netifN:0)" dynamic address evaluation with return of only first address. You *can* use ifaddrs(netifN) for a NAT rule in NetBSD -current, but you need to specify the address selection algorithm. Currently, "ip‐hash" or "round‐robin". You cannot select just the first address, though. That is something I can look into. My modem has a site local admin address. My router gets a public IP from it but I'd like to keep the admin address as well. An address selection algo to exclude or only use site local addresses would be of use? Currently I have a dhcpcd exit hook script to remove the site local addresses, reconfigure npf and then re apply the site local addresses. This isn't ideal, hence my request. Roy
Re: Removing PF
On Mon, 8 Apr 2019, Mindaugas Rasiukevicius wrote: > "John D. Baker" wrote: > > Is it possible to assign multiple addresses in a dynamic fashion > > (DHCP, PPP[oE], ???) that ifaddrs(netifN) is meaningful? > > ifaddrs(netifN) represents a list of addresses currently assigned the > interface i.e. it works dynamically, you do not need to `npfctl reload`. So, to be clear, if an interfaces gains/sheds addresses, ifaddrs(netifN) will always reflect the current set of addresses on that interface each time ifaddrs(netifN) is used, correct? > In fact, in-kernel NPF supports the translation address being a table, > using which you can dynamically insert/delete anything you want. I just > have not decided on the npf.conf(5) syntax for it yet. Can this insert/delete be done at any position in the table? I suppose with some exit-hook script fiddling, 'dhcpcd' could be coaxed into manipulating such a table. Is it possible to reference a particular element in the table by position? In my use case, the interface will have one address that may change (be removed and a different one added) at any time for any reason or no reason (at whim of ISP). Whatever this address is will be the translation address for packets leaving the local network(s) and destined for the wild, wild internet. (And likewise accepting incoming connections for permitted externally-visible services and passing them to hosts on the internal networks.) The same interface will also have a statically assigned address that will be the translation address for packets leaving the local network but destined only for the status/configuration interface of the ADSL modem (which is on its own private RFC1918 network). > > Maybe an additional address-selection algorithm that selects any > > specified elements of the list? > > Using what criteria? Do you want an additional address selection > algorithm or do you just want to filter the dynamic list? If one does not use an address selection algorithm at all, does ifaddrs(netifN) guarantee an ordering of the list? If I can guarantee the ordering of addresses assigned to the interface (such as the dynamically-assigned address being always first in the list) I suppose a mechanism to filter based on position in the list is sufficient. So, I suppose the issue is that although the interface will have multiple addresses, I wish to treat each address independenly, but need to do so symbolically as (at least one of) the exact addresses cannot be known ahead of time or guaranteed to be current. I don't know if this makes the situation more clear or not. -- |/"\ John D. Baker, KN5UKS NetBSD Darwin/MacOS X |\ / jdbaker[snail]consolidated[flyspeck]net OpenBSDFreeBSD | X No HTML/proprietary data in email. BSD just sits there and works! |/ \ GPGkeyID: D703 4A7E 479F 63F8 D3F4 BD99 9572 8F23 E4AD 1645
Re: Removing PF
On Sun, 7 Apr 2019, John D. Baker wrote: > Date: Sun, 7 Apr 2019 18:25:33 -0500 (CDT) > From: John D. Baker > To: Mindaugas Rasiukevicius > Cc: tech-kern@NetBSD.org > Subject: Re: Removing PF > > On Sun, 7 Apr 2019, Mindaugas Rasiukevicius wrote: > > > You *can* use ifaddrs(netifN) for a NAT rule in NetBSD -current, but > > you need to specify the address selection algorithm. Currently, > > "ip-hash" or "round-robin". You cannot select just the first address, > > though. That is something I can look into. > Maybe an additional address-selection algorithm that selects any > specified elements of the list? Are address-selection algorithm specifications allowed in filter rules as well? I've become accustomed to things like: ext_if="qe2" int_if="le0" ssh_host="X.y.Z.q" table persist file "/var/db/pf/abusive_hosts" nat on $ext_if from $int_if:network -> ($ext_if:0) rdr on $ext_if from !($ext_if) to ($ext_if) port ssh \ -> $ssh_host pass in on $ext_if proto tcp from !($ext_if) to $ssh_host port ssh \ synproxy state (max-src-conn 25, max-src-conn-rate 3/25 \ overload flush global) so it will be interesting to see how 'npf' features and syntax map onto those of 'pf'. Thanks. -- |/"\ John D. Baker, KN5UKS NetBSD Darwin/MacOS X |\ / jdbaker[snail]consolidated[flyspeck]net OpenBSDFreeBSD | X No HTML/proprietary data in email. BSD just sits there and works! |/ \ GPGkeyID: D703 4A7E 479F 63F8 D3F4 BD99 9572 8F23 E4AD 1645
Re: Removing PF
"John D. Baker" wrote: > Is it possible to assign multiple addresses in a dynamic fashion > (DHCP, PPP[oE], ???) that ifaddrs(netifN) is meaningful? ifaddrs(netifN) represents a list of addresses currently assigned the interface i.e. it works dynamically, you do not need to `npfctl reload`. In fact, in-kernel NPF supports the translation address being a table, using which you can dynamically insert/delete anything you want. I just have not decided on the npf.conf(5) syntax for it yet. > Maybe an additional address-selection algorithm that selects any > specified elements of the list? Using what criteria? Do you want an additional address selection algorithm or do you just want to filter the dynamic list? -- Mindaugas
Re: Removing PF
On Sun, 7 Apr 2019, Mindaugas Rasiukevicius wrote: > You *can* use ifaddrs(netifN) for a NAT rule in NetBSD -current, but > you need to specify the address selection algorithm. Currently, > "ip-hash" or "round-robin". You cannot select just the first address, > though. That is something I can look into. I see. This sounds like something I used on a pf/OpenBSD system which NATed several internal RFC1918 networks to a statically-assigned /27 subnet's worth of public IP addresses (using an "ip-hash" algorithm). It took a bit of tweaking of subnet definitions and NAT rules to avoid it trying to NAT through the network or broadcast addresses ;) As such, the interface's addresses were assigned with appropriate statements in the "/etc/hostname.if" file (OpenBSD) for the public- facing interface. Is it possible to assign multiple addresses in a dynamic fashion (DHCP, PPP[oE], ???) that ifaddrs(netifN) is meaningful? Maybe an additional address-selection algorithm that selects any specified elements of the list? Thanks. -- |/"\ John D. Baker, KN5UKS NetBSD Darwin/MacOS X |\ / jdbaker[snail]consolidated[flyspeck]net OpenBSDFreeBSD | X No HTML/proprietary data in email. BSD just sits there and works! |/ \ GPGkeyID: D703 4A7E 479F 63F8 D3F4 BD99 9572 8F23 E4AD 1645
Re: Removing PF
"John D. Baker" wrote: > > > - dynamic ifaddrs(netifN) (John D. Baker) > > The "ifaddrs(netifN)" function is what evaluates the addresses on the > interface with each reference in a rule, or so the documentation makes > it appear. Contrast with "inet4(netifN)" or "inet6(netifN)" that is > only evaluated when the configuration file is loaded. "ifaddrs(netifN)" > appears to be the equivalent of pf's "(netifN)", but always returns the > full list of all addresses on an interface, so cannot be used in a NAT > (map foo -> bar) statement. Hence the desire to select a subset or at > least only the first address in the list, e.g., pf's "(netifN:0)" dynamic > address evaluation with return of only first address. You *can* use ifaddrs(netifN) for a NAT rule in NetBSD -current, but you need to specify the address selection algorithm. Currently, "ip‐hash" or "round‐robin". You cannot select just the first address, though. That is something I can look into. -- Mindaugas
Re: Removing PF
On Thu, Apr 04, 2019 at 10:33:47PM +0100, Mindaugas Rasiukevicius wrote: > > - altq (Thor Lancelot Simon) > Note: NPF can easily integrate with an already existing packet shaping > mechanism, such as ALTQ, using packet/mbuf tagging. Writing NPF extensions > to do such simple things like tagging is really straightforward. IIUC that is all that is needed here. Martin
Re: Removing PF
On Thu, 4 Apr 2019 19:51:14 +, Taylor R Campbell wrote: First, thanks for gathering all the things mentioned so far into a single posting. > There's also extended documentation, beyond the man pages, here: > > https://rmind.github.io/npf/ Then the following needs to be added to the "TODO" list: TODO: incorporate website documentation into local manual pages. If I need to access a web site to configure the firewall and need the firewall configured to access the web site, I'm stuck. > - ftp-proxy (Jan Danielsson) "Me too." > - pf netifN:0, netifN:network notation (John D. Baker) To be clear, the notation itself is immaterial, but the functionality it represents is what is needed. > - address subset selection (John D. Baker) This is more a generic statement about what pf's "netifN:0" does. For my current needs an eqivalent to "netifN:0" is sufficient, but I can imagine a case for an interface with more than two addresses of the same family in different networks and needing to select any subset of them. > - dynamic ifaddrs(netifN) (John D. Baker) The "ifaddrs(netifN)" function is what evaluates the addresses on the interface with each reference in a rule, or so the documentation makes it appear. Contrast with "inet4(netifN)" or "inet6(netifN)" that is only evaluated when the configuration file is loaded. "ifaddrs(netifN)" appears to be the equivalent of pf's "(netifN)", but always returns the full list of all addresses on an interface, so cannot be used in a NAT (map foo -> bar) statement. Hence the desire to select a subset or at least only the first address in the list, e.g., pf's "(netifN:0)" dynamic address evaluation with return of only first address. > - pf synproxy state (John D. Baker) Be sure such implementation can be used in a straightforward fashion on host firewalls protecting local services. With the current 'pf' in NetBSD, I have to have services listen on a dummy interface (I create "lo1") and redirect traffic to it for synproxy state to work. For services redirected (port forwarded) to an internal or DMZ host, it works as expected without any subterfuge. > - ipf migration path (manu) and likewise a pf migration path. > - altq (Thor Lancelot Simon) Yes, please. > - greylisting integration (MLH) This, too. I use 'spamd' with 'pf' and would like to keep such facility. I should be able to write a config file that can be copied to other systems and used either with no changes at all, or changing only those variables which name the network interfaces. E.g., swap out SPARC-based router for net4501. Copied "pf.rules" (my config file) from SPARC to Soekris box, change variables defining interfaces and away we go. -- |/"\ John D. Baker, KN5UKS NetBSD Darwin/MacOS X |\ / jdbaker[snail]consolidated[flyspeck]net OpenBSDFreeBSD | X No HTML/proprietary data in email. BSD just sits there and works! |/ \ GPGkeyID: D703 4A7E 479F 63F8 D3F4 BD99 9572 8F23 E4AD 1645
Re: Removing PF
Taylor R Campbell wrote: > > - mss clamping (Brian Buhrow) This is supported and has been documented for years.. > - ftp-proxy (Jan Danielsson) > ... > - dynamic NAT updates These two are related and should soon be addressed. > - pf route-through/reply-to (Brian Buhrow) That is more of working with NetBSD's network stack. Once the network stack provides an API (needs to work with IPv4 and IPv6, handle possible interface detach, etc), calling it from NPF is fairly straightforward. > - ipf groups (Manuel Bouyer) I have a design for shared rulesets in mind, but have not had time to implement it yet. No ETA yet. > - dynamic ifaddrs(netifN) (John D. Baker) This is supported in NetBSD -current (the documentation needs a sync from the Github version, though). > - pf netifN:0, netifN:network notation (John D. Baker) > ... > - address subset selection (John D. Baker) These two are the same. > - pf synproxy state (John D. Baker) I am not convinced this should be a part of NPF core, but I see this being useful for certain networks. Happy to support it as an extension, though, so patches are welcome! > - BRIDGE_IPF (Piotr Meyer) IIRC, this is just a matter of testing. > - ipf migration path (manu) Patches / pull requests with documentation improvements are welcome! > - https://gnats.netbsd.org/53199 (Patrick Welche) Not sure what exactly the submitter wants. NPF establishes per-interface state (for a good reason). It seems that some users want a global state which would be picked up on any interface and in either direction. This will be added to NetBSD with the next NPF sync from Github; however, there are drawbacks of such behaviour and it will not be a default. > - altq (Thor Lancelot Simon) In general, I would say that traffic shaping / packet scheduling should be the problem of the network stack. It deals with the queues and can handle it efficiently. Packet filter would either heavy rely on it or would end up duplicating the concepts and mechanisms for packet queuing. However, I am not against adding the framework for this within NPF. Primarily, because it is used outside NetBSD where it would not be able to rely on particular network stack mechanisms. Note: NPF can easily integrate with an already existing packet shaping mechanism, such as ALTQ, using packet/mbuf tagging. Writing NPF extensions to do such simple things like tagging is really straightforward. > - port redirection (MLH) Huh? NPF supports port redirection (and documents it) pretty much since its creation. > - greylisting integration (MLH) > - equivalent of `log followers' (MLH) What are these? -- Mindaugas
Re: Removing PF
Core decided a while ago that npf is the way forward and pf and ipf will be deprecated and removed at some point. It is not worth the effort to try to update pf or ipf. We are not removing pf or ipf immediately but they will certainly be deprecated in netbsd-9 so they can be gone in netbsd-10. We are aware that npf is not at feature and documentation parity with pf and ipf in NetBSD. We're pursuing a funded project to remedy this so that everyone will have a migration path for pf and npf. If you support this, please donate to The NetBSD Foundation! There's a couple of task lists maintained here: src/doc/TODO.npf https://www.NetBSD.org/~rmind/npf/__tasklist.html There's also extended documentation, beyond the man pages, here: https://rmind.github.io/npf/ I read through this thread, and what I've gathered that people are missing so far or find to be not documented clearly enough is: - mss clamping (Brian Buhrow) - ftp-proxy (Jan Danielsson) - pf route-through/reply-to (Brian Buhrow) - ipf groups (Manuel Bouyer) - dynamic NAT updates - pf netifN:0, netifN:network notation (John D. Baker) - dynamic ifaddrs(netifN) (John D. Baker) - address subset selection (John D. Baker) - pf synproxy state (John D. Baker) - BRIDGE_IPF (Piotr Meyer) - ipf migration path (manu) - https://gnats.netbsd.org/53199 (Patrick Welche) - altq (Thor Lancelot Simon) - port redirection (MLH) - greylisting integration (MLH) - equivalent of `log followers' (MLH) Some of this may overlap with what's already in the task lists -- I didn't deduplicate them. It would be helpful if we had a clear statement of what each of these items is, with: 1. a one-line summary 2. a small diagram of network topology 3. a description of the desired behaviour 4. an example configuration file in hypothetical notation 5. a sketch of an example packet trace 6. references to relevant standards This would make it much easier for us to confidently address the shortcomings and write automatic tests for them, and/or update the documentation to make it clearer how to do these. If you can send these to me, that would help us to organize a project to get npf in a position to replace pf and ipf for everyone as soon as possible. Thanks, -Riastradh, NetBSD Core Team
Re: Removing PF
Le 02/04/2019 à 22:29, Mouse a écrit : I continue to use pf and not npf because : [...] However, I must say I'm still a bit confused by this answer (and the others I've seen). Do you understand that PF is a clear security risk for your system? Is it? Do you know MLH's systems enough to know whether any of the known vulnerabilities are relevant? I don't. That's a really simplistic answer; if by any chance he happens to avoid every vuln found until now then it's fine to use PF? What about the next one that comes in, will he still be lucky? No one will fix it, and it's not viable. Or, he could be using PF in an entirely offline network, in which case it is indeed fine (but that doesn't seem to be his particular case). If you really want to use PF, I would recommend that you switch to another OS, for your own safety. PF has no future in NetBSD. It doesn't? It seems to me, from the lack of consensus I'm seeing here, that that remains to be seen. We've been seeing it for eleven years, but we can wait another eleven years in case you still have a doubt about whether anyone wants to work on PF...
Re: Removing PF
> However, I must say I'm still a bit confused by this answer (and the others > I've seen). Do you understand that PF is a clear security risk for your > system? Yes, I see you keep agreeing that NetBSD has no safely working packet filter. We are patiently waiting for one. Since NetBSD v1.2 in my case. If we all aborted support for an OS because there were clear security risks, there wouldn't be any "free" OS development. If I had a clue about packet filter development, I would gladly try to help. My forte was scientific computing. Not much use for that since I retired. :^)
Re: Removing PF
>> I continue to use pf and not npf because : [...] > However, I must say I'm still a bit confused by this answer (and the > others I've seen). Do you understand that PF is a clear security > risk for your system? Is it? Do you know MLH's systems enough to know whether any of the known vulnerabilities are relevant? I don't. > Yes, it is sad if you can't use ftp-proxy on NPF for now, yes NPF's > syntax is not the same as PF's, and so on. But NPF equally has many > advanced benefits, that you don't get with PF. This sounds to me a lot like "yes, NPF doesn't do what you need, but it does all this other neat stuff you don't need, so doesn't that make up for it?" Surely that's not what you intend. > If you really want to use PF, I would recommend that you switch to > another OS, for your own safety. PF has no future in NetBSD. It doesn't? It seems to me, from the lack of consensus I'm seeing here, that that remains to be seen. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Re: Removing PF
Le 02/04/2019 à 20:46, MLH a écrit : I continue to use pf and not npf because : 1) I couldn't get std rulesets to seem to work (been a while though) 2) no port redirection 3) dynamic ruleset use didn't appear to be adequate 4) greylisting (not just email) for custom stuff that I can't see how to support in npf. 5) Needs far more documentation and help than I have seen. I would like to move to npf as some future features look nice (SYN floods, DoS attacks, etc). However, in addition to std rulesets, etc, I use log followers to block attacks. While not the main security, they really help hold down traffic, etc. and I'm not anywhere near willing to give them up. I tried using blacklistd but never could get it to work (also been a while). At least people answer to the question that was asked, so thanks for that already. However, I must say I'm still a bit confused by this answer (and the others I've seen). Do you understand that PF is a clear security risk for your system? Or, you obviously understand, but don't care much? Sure, PF has features NPF doesn't have; but a firewall is supposed to stop the fire, not create the conditions for it to spread. And sure, each software has bugs, but you don't need to have a nobel prize to understand that 11yo unmaintained software has much more bugs than its up-to-date version, in the case of PF it is obviously proven. In essence, if it's that you don't care, then indeed keeping PF may not be a real problem for us, except looking a bit irresponsible. I mean, we don't care either if you give your credit card number to every stranger that calls you on the phone... some responsibility is on the user's side. However, I do believe that our responsibility is still to prevent confusion, even when it implies removing some features. Yes, it is sad if you can't use ftp-proxy on NPF for now, yes NPF's syntax is not the same as PF's, and so on. But NPF equally has many advanced benefits, that you don't get with PF. If you really want to use PF, I would recommend that you switch to another OS, for your own safety. PF has no future in NetBSD. It's been one decade of this, at some point we need to cut the crap.
Re: Removing PF
I continue to use pf and not npf because : 1) I couldn't get std rulesets to seem to work (been a while though) 2) no port redirection 3) dynamic ruleset use didn't appear to be adequate 4) greylisting (not just email) for custom stuff that I can't see how to support in npf. 5) Needs far more documentation and help than I have seen. I would like to move to npf as some future features look nice (SYN floods, DoS attacks, etc). However, in addition to std rulesets, etc, I use log followers to block attacks. While not the main security, they really help hold down traffic, etc. and I'm not anywhere near willing to give them up. I tried using blacklistd but never could get it to work (also been a while).
Re: Removing PF
On 2019-04-01 22:30, Johnny Billquist wrote: On 2019-04-01 15:16, Emmanuel Dreyfus wrote: On Sat, 30 Mar 2019, Maxime Villard wrote: 2) If the effort had been on one firewall instead of three, the one chosen would be more functional. Well, I cannot tell for PF, but IPF is functionnal, I use it a lot and I am not alone It may have bugs, but if you really have to remove it, please make sure there is an easy migration path. Yeah. I happen to use ipf as well. Anecdotal it would appear that npf might be the least tested or used option... I'm using npf, it works fine for what I need. The NetBSD project machines are using npf too, so it does get some real world testing.
Re: Removing PF
m...@netbsd.org wrote: I think it's very telling that all the people arguing back are using ipf, not pf. I suspect anyone that was using pf on NetBSD is no longer using NetBSD. To keep the anecdotes going, I am using pf on NetBSD as my primary firewall. Staffan
Re: Removing PF
Jan Danielsson wrote: > On 2019-04-02 08:53, Martin Husemann wrote: > >> This, exactly, is the showstopper that has prevented me from moving to > >> npf. The ability to add/remove IP addresses from a NAT translation > >> without changing npf.conf doesn't seem to be possible in any > >> documentation I was able to find. If you just want to dynamically change the translation address(es), then NPF in -current already supports that. Basically, NPF supports NAT address being specified as a table. However, npf.conf(5) syntax hides/abstracts some of that (as the common case is for the interface addresses and because we need to specify address selection algorithm). > <...> > >These are the filter rules, not the NAT rules. > >The UPnP device essentially says two things: >1) Hey, I would like external hosts to be able to access me on port > X. (filter rule, this works as you pointed out). >2) Hey, I'm at a.b.c.d, and I would like external port X to redirect > to me at port Y. (NAT rule, this isn't supported yet). > There is a partial support for dynamic NAT rules too, but yes -- it is not documented anywhere. Supporting miniupnpd is essentially the same type of work as for ftp-proxy. If anybody wants to work on miniupnpd, please feel free to contact me. -- Mindaugas
Re: Removing PF
I think it's very telling that all the people arguing back are using ipf, not pf. I suspect anyone that was using pf on NetBSD is no longer using NetBSD. I certainly saw people ragequit NetBSD after their obviously remotely exploited bug reports were ignored. We can't keep having this minefield for unsuspecting users.
Re: Removing PF
On Mon, 1 Apr 2019, Johnny Billquist wrote: On 2019-04-01 15:16, Emmanuel Dreyfus wrote: On Sat, 30 Mar 2019, Maxime Villard wrote: 2) If the effort had been on one firewall instead of three, the one chosen would be more functional. Well, I cannot tell for PF, but IPF is functionnal, I use it a lot and I am not alone It may have bugs, but if you really have to remove it, please make sure there is an easy migration path. Yeah. I happen to use ipf as well. Anecdotal it would appear that npf might be the least tested or used option... Until the proplib transfer size was increased, I found any attempts to migrate real-world rulesets from ipf to npf hit were unsuccessful because the rulesets were too large to load (this is compounded by the way state is handled). Therefore, unless developers had private proplib patches, npf cannot have been tested with even moderate-sized rulesets. Of course, it could be argued that as long as you have tested all the functionality being used by those rulesets, you should be able to safely assume it will scale. -- Stephen
Re: Removing PF
On Tue, Apr 02, 2019 at 11:02:56AM +0200, Jan Danielsson wrote: >2) Hey, I'm at a.b.c.d, and I would like external port X to redirect > to me at port Y. (NAT rule, this isn't supported yet). OK, but that is easy to add. Martin
Re: Removing PF
On 2019-04-02 08:53, Martin Husemann wrote: >> This, exactly, is the showstopper that has prevented me from moving to >> npf. The ability to add/remove IP addresses from a NAT translation >> without changing npf.conf doesn't seem to be possible in any >> documentation I was able to find. > > It is documented at least, from the EXAMPLE section of npfctl(8): > > Addition and removal of entries in the table whose ID is "vip": > ># npfctl table "vip" add 10.0.0.1 ># npfctl table "vip" rem 182.168.0.0/24 > > There also is "npfctl rule add" and "npfctl rule rem". Also blacklistd(8) > obviously does it. These are the filter rules, not the NAT rules. The UPnP device essentially says two things: 1) Hey, I would like external hosts to be able to access me on port X. (filter rule, this works as you pointed out). 2) Hey, I'm at a.b.c.d, and I would like external port X to redirect to me at port Y. (NAT rule, this isn't supported yet). -- Kind Regards, Jan Danielsson
Re: Removing PF
On Sat, 30 Mar 2019 02:30:06 +0100 Jan Danielsson wrote: > On 2019-03-30 01:19, Matt Sporleder wrote: > > What features, exactly, are missing? > >Runtime NAT reconfiguration. miniupnpd wants to be able to > add/remove filter rules (npf can do this) as well as add/remove NAT > entries (npf couldn't do this last time I checked). This, exactly, is the showstopper that has prevented me from moving to npf. The ability to add/remove IP addresses from a NAT translation without changing npf.conf doesn't seem to be possible in any documentation I was able to find. -- Aaron B.
Re: Removing PF
On Mon, 1 Apr 2019, Johnny Billquist wrote: On 2019-04-01 15:16, Emmanuel Dreyfus wrote: On Sat, 30 Mar 2019, Maxime Villard wrote: 2) If the effort had been on one firewall instead of three, the one chosen would be more functional. Well, I cannot tell for PF, but IPF is functionnal, I use it a lot and I am not alone It may have bugs, but if you really have to remove it, please make sure there is an easy migration path. Yeah. I happen to use ipf as well. Anecdotal it would appear that npf might be the least tested or used option... Anecdotal where? I use npf and I've seen traffic from people asking how to set it up. It's non-zero and the only ipf/pf users I know of are on this thread. This is just a SWAG. -- Hisashi T Fujinaka - ht...@twofifty.com BSEE + BSChem + BAEnglish + MSCS + $2.50 = coffee
Re: Removing PF
> On Apr 1, 2019, at 1:33 PM, Johnny Billquist wrote: > > It is obviously inconsistent. You can't both claim that no-one is maintaining > it, and claim people putting some effort into it (with "it" being either pf > or ipf). It is not inconsistent in the sense that if you want to make other changes that touch things that PF uses, you have to spend the time to update PF. This is most significantly related to networking APIs that the Project wishes to make MP-friendly in a performant way. -- thorpej
Re: Removing PF
On 2019-04-01 15:17, Jaromír Doleček wrote: Le lun. 1 avr. 2019 à 14:32, Stephen Borrill a écrit : Your two statements are mutually inconsistent: 1) No-one is maintaining ipf or pf and 2) If the effort had been on one firewall instead of three, the one chosen would be more functional. IMO it's consistent - if we had one, it would be clear to which one to contribute, and clear if the feature is really missing and working. i.e. nobody contributes anything because they don't know to which of the firewalls to contribute. It is obviously inconsistent. You can't both claim that no-one is maintaining it, and claim people putting some effort into it (with "it" being either pf or ipf). Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: b...@softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol
Re: Removing PF
On 2019-04-01 15:16, Emmanuel Dreyfus wrote: On Sat, 30 Mar 2019, Maxime Villard wrote: 2) If the effort had been on one firewall instead of three, the one chosen would be more functional. Well, I cannot tell for PF, but IPF is functionnal, I use it a lot and I am not alone It may have bugs, but if you really have to remove it, please make sure there is an easy migration path. Yeah. I happen to use ipf as well. Anecdotal it would appear that npf might be the least tested or used option... Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: b...@softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol
Re: Removing PF
hello. I can explain this feature. I use it in two ways.
I use a number of public IP addresses from one ISP, whose service is
delivered through a VPN via another ISP. Except for the traffic destined
for the far end of the VPN itself, I want all traffic to get routed through
the VPN and for any state information to be tracked through the VPN. Below
is an example configuration.
The second way I use this is to do essentially the same thing, but to also
explicitly set the destination address on the packets destined for the far
end of the firewall itself.
Let me know if I can explain this more clearly.
-thanks
-Brian
First example:
# $NetBSD: pf.conf,v 1.3 2005/03/15 16:05:03 peter Exp $
# $OpenBSD: pf.conf,v 1.28 2004/04/29 21:03:09 frantzen Exp $
#
# See pf.conf(5) and /usr/share/examples/pf for syntax and examples.
# Remember to set net.inet.ip.forwarding=1 and/or net.inet6.ip6.forwarding=1
# in /etc/sysctl.conf if packets are to be forwarded between interfaces.
ext_if="vlan20"
int_if="wm0"
vpn_if="tun0"
#set options here
set block-policy drop
set skip on $vpn_if
set skip on lo0
scrub in all
#internal filtering rules
pass in quick on $int_if from $int_if:network to $int_if:network
pass in quick on $int_if from $int_if:network to 10.157.0.0/16
pass in quick on $int_if from $int_if:network to 172.209.0.0/18
pass in quick on $int_if from $int_if:network to 10.0.0.0/8
#Pass internal network traffic through the VPN to expose it to the Internet
pass in quick on $int_if route-to $vpn_if from $int_if:network to any keep state
pass out quick on $int_if from $int_if:network to $int_if:network
pass out quick on $int_if from 10.157.0.0/16 to $int_if:network
pass out quick on $int_if from 172.209.0.0/18 to $int_if:network
pass out quick on $int_if from 10.0.0.0/8 to $int_if:network
# The next two lines are the traffic we let into the network unsolicited.
pass out quick on $int_if reply-to $vpn_if inet proto udp to 10.157.230.0/24
port 1723 keep state
pass out quick on $int_if reply-to $vpn_if inet proto tcp to 10.157.230.11 port
{ 22, 25, 53, 80, 110, 143, 443, 587, 993, 995 } keep state
block out quick on $int_if reply-to $vpn_if inet proto udp to $int_if:network
port { 19, 111, 137, 161, 5060 }
block out quick on $int_if from any to any
#Let all pass through the VPN tunnel interface
pass in quick on $vpn_if from any to any
pass out quick on $vpn_if from any to any
#external filtering rules
pass out quick on $ext_if from ($ext_if) to any keep state
pass in quick on $ext_if inet proto icmp from any to ($ext_if) icmp-type
echoreq keep state
block all
Second example:
# Allow the back office to keep using old addresses (06/26/2017)
pass in quick on $dmz_if from $dmz_if:network to $dmz_if:network no state
pass in quick on $dmz_if from $dmz_if:network to $private_if:network no state
#Pass internal network traffic through the VPN to expose it to the Internet
pass in quick on $dmz_if route-to { ($vpn_if 10.157.9.105) } from
$dmz_if:network to any keep state
pass out quick on $dmz_if from $dmz_if:network to $dmz_if:network no state
pass out quick on $dmz_if from $private_if:network to $dmz_if:network no state
# The next line lets unsolicited inbound traffic come into the network.
pass out quick on $dmz_if reply-to { ($vpn_if 10.157.9.105) } from any to
$dmz_if:network keep state
block out quick on $dmz_if from any to any no state
Re: Removing PF
On Mon, Apr 01, 2019 at 10:02:57AM -0700, Brian Buhrow wrote: > 2. For me to use npf at all, I absolutely need to have the > route-through/reply-to feature. Pf has that feature. Can you explain what that does (or give an example)? I have used "map" rules in ipnat.conf in the past with IPF, and NPF calls it "map" as well, but I don't know PF. Martin
Re: Removing PF
Hello. Yes, I listed the features below upthread which are important to me. They exist in pf, and, as far as I can tell, not in npf. -thanks -Brian --- Forwarded mail from "Brian Buhrow" Hello. I will examine the documentation for npf again, but here are the issues I think we should resolve with npf before we rip out pf or ipf. 1. The documentation for npf is still pretty incomplete. The example files are there, but the comments, the last time I looked, were not as complete as I think they should be.The man pages should also explain the syntax of the configuration files in more detail, again with examples. 2. For me to use npf at all, I absolutely need to have the route-through/reply-to feature. Pf has that feature. -Brian
Re: Removing PF
On Mon, Apr 01, 2019 at 03:33:36PM +0100, Stephen Borrill wrote: > On Mon, 1 Apr 2019, Jaromír Dole?~Mek wrote: > > Le lun. 1 avr. 2019 à 14:32, Stephen Borrill a > > écrit : > > > Your two statements are mutually inconsistent: > > > 1) No-one is maintaining ipf or pf > > > and > > > 2) If the effort had been on one firewall instead of three, the one chosen > > > would be more functional. > > > > IMO it's consistent - if we had one, it would be clear to which one to > > contribute, and clear if the feature is really missing and working. > > i.e. nobody contributes anything because they don't know to which of > > the firewalls to contribute. > > > > In either case, let's return to a constructive discussion, and see > > what needs to be done. NPF-only is the future, so let's get to that > > future. > > > > In the past discussion, I've only seen people mentioning only two > > features missing in NPF and present in PF: > > > > 1. ftp-proxy support - Maxime volunteered to implement this in NPF, > > I'm sure help there would be welcome > > 2. group support for config (mentioned by Manuel) - anyone feels like > > taking? > > - ??it might be enough to have some kind of config preprocessor > > initially if that's easier to do?? > > > > Is there anything else? > > The canonical, but not necessarily complete, lists are: > > http://cvsweb.netbsd.org/bsdweb.cgi/src/doc/TODO.npf > > https://www.netbsd.org/~rmind/npf/__tasklist.html http://gnats.netbsd.org/53199 Installed another 2 new servers with ipf after having tried and failed to convert a trivial ruleset to npf.
Re: Removing PF
On Mon, 1 Apr 2019, Jaromír Dole�~Mek wrote: Le lun. 1 avr. 2019 à 14:32, Stephen Borrill a écrit : Your two statements are mutually inconsistent: 1) No-one is maintaining ipf or pf and 2) If the effort had been on one firewall instead of three, the one chosen would be more functional. IMO it's consistent - if we had one, it would be clear to which one to contribute, and clear if the feature is really missing and working. i.e. nobody contributes anything because they don't know to which of the firewalls to contribute. In either case, let's return to a constructive discussion, and see what needs to be done. NPF-only is the future, so let's get to that future. In the past discussion, I've only seen people mentioning only two features missing in NPF and present in PF: 1. ftp-proxy support - Maxime volunteered to implement this in NPF, I'm sure help there would be welcome 2. group support for config (mentioned by Manuel) - anyone feels like taking? - ??it might be enough to have some kind of config preprocessor initially if that's easier to do?? Is there anything else? The canonical, but not necessarily complete, lists are: http://cvsweb.netbsd.org/bsdweb.cgi/src/doc/TODO.npf https://www.netbsd.org/~rmind/npf/__tasklist.html -- Stephen
Re: Removing PF
On Mon, Apr 01, 2019 at 03:17:06PM +0200, Jaromír Dole?ek wrote: > 1. ftp-proxy support - Maxime volunteered to implement this in NPF, > I'm sure help there would be welcome > 2. group support for config (mentioned by Manuel) - anyone feels like taking? > - ??it might be enough to have some kind of config preprocessor > initially if that's easier to do?? I don't think a preprocessor will be enough. groups allow rules in the group to be evaluated, or not, depending on the matching rules in head. Also, depending on how the 'quick' keyword is used in head and/or group rules, processing can stop at the end of the group, or continue with other rules. This is what makes groups usefull. -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: Removing PF
Le lun. 1 avr. 2019 à 14:32, Stephen Borrill a écrit : >Your two statements are mutually inconsistent: > 1) No-one is maintaining ipf or pf > and > 2) If the effort had been on one firewall instead of three, the one chosen > would be more functional. IMO it's consistent - if we had one, it would be clear to which one to contribute, and clear if the feature is really missing and working. i.e. nobody contributes anything because they don't know to which of the firewalls to contribute. In either case, let's return to a constructive discussion, and see what needs to be done. NPF-only is the future, so let's get to that future. In the past discussion, I've only seen people mentioning only two features missing in NPF and present in PF: 1. ftp-proxy support - Maxime volunteered to implement this in NPF, I'm sure help there would be welcome 2. group support for config (mentioned by Manuel) - anyone feels like taking? - ??it might be enough to have some kind of config preprocessor initially if that's easier to do?? Is there anything else? Jaromir
Re: Removing PF
> On Sat, 30 Mar 2019, Maxime Villard wrote: > 2) If the effort had been on one firewall instead of three, the one chosen > would be more functional. Well, I cannot tell for PF, but IPF is functionnal, I use it a lot and I am not alone It may have bugs, but if you really have to remove it, please make sure there is an easy migration path. -- Emmanuel Dreyfus m...@netbsd.org
Re: Removing PF
On Sat, 30 Mar 2019, Maxime Villard wrote: Le 30/03/2019 à 08:51, Michael van Elst a écrit : On Sat, Mar 30, 2019 at 08:17:44AM +0100, Maxime Villard wrote: Le 30/03/2019 à 08:07, Michael van Elst a écrit : m...@m00nbsd.net (Maxime Villard) writes: If the effort hadn't been split on three firewalls in the last 10 years, but rather had been focused on only one, don't you think NPF would now be featureful? Now if the effort of the world hadn't been split among Windows, MacOS and Linux, but rather had been focused on only NetBSD, don't you think NetBSD would now be featureful ? Yes, if the effort had been on one firewall instead of three, the one chosen would be more functional. Period. You have absolutely no point, do you? You just don't understand the point. Period. Hey, I said Period, it must be true. Do you believe people would give up their efforts on Windows, or MacOS or Linux to focus on NetBSD ? Ah, silly me, too abstract. Do you really believe the maintainers of ipf and npf would give up their projects to work on pf ? Ah because there are maintainers of ipf? There is _no_ maintainer of ipf whatsoever. Do you understand, or not? Give me a list of people who maintain ipf. Just like, give me a list of people who maintain pf in NetBSD. Your two statements are mutually inconsistent: 1) No-one is maintaining ipf or pf and 2) If the effort had been on one firewall instead of three, the one chosen would be more functional. -- Stephen
Re: Removing PF
I'm not using pf. I'm not arguing against pf removal, am arguing against your way of arguing. > the questions raised were: why would someone use an insecure firewall? Because, in the real world, the only viable alternative may turn out to be using no firewall at all. If you have a configuration that can't be reaonably ported, what else to do? For me (and others) NetBSD is not (only) a research platform. It's a tool to get their work done.
Re: Removing PF
On Sun, Mar 31, 2019, 8:13 AM Sevan Janiyan wrote: > > > On 30/03/2019 23:27, Mouse wrote: > > (Rule of thumb: anyone who calls something "secure" or > > "insecure" without giving any indication of the threat model in > > question either doesn't understand security or hopes you don't; neither > > alternative is good. It's not universally applicable - here, for > > example, I suspect you were just being a bit over-brief - but it's been > > remarkably useful to me.) > > > Deeming it insecure on that basis of all the bug fixes upstream have > which haven't been merged in our tree since our last sync including > published patches from around this point onwards: > https://www.openbsd.org/errata42.html both of which need to be evaluated > to see if applicable. > Also on the basis of nobody doing this for years, I'd say this is prime evidence for there being no effective maintainer for years. Warner >
Re: Removing PF
On Sat, 30 Mar 2019, John D. Baker wrote: [ Multiple addresses/networks on external NAT router interface. ] I may have overstated the case of PPPOE-ADSL systems in this regard. In this case, the pppoeN pseudo-interface is associated with some physical netifN interface, but pppoeN handles only the ISP-assigned dynamic address (which may spontaneously change at any time for any reason or no reason). The physical netifN interface holds the static address used to access the ADSL modem's status/configuration interface. So the issue of needing a subset of addresses returned by 'ifaddrs(netifN)' does not apply. It does apply in the case of a single netifN interface receiving a ISP-assigned address via DHCP while also maintaining a secondary static address to communicate with the ADSL modem's status/configuration interface. Although one's own router remains online, disruptions within the ISP's infrastructure (fault, maintenance, etc.) may prompt spontaneous change of assigned address. As such the dynamic feature of 'ifaddrs(netifN)' is essential, but there needs to be a way to select a subset of the returned addresses for proper operation to resume. -- |/"\ John D. Baker, KN5UKS NetBSD Darwin/MacOS X |\ / jdbaker[snail]consolidated[flyspeck]net OpenBSDFreeBSD | X No HTML/proprietary data in email. BSD just sits there and works! |/ \ GPGkeyID: D703 4A7E 479F 63F8 D3F4 BD99 9572 8F23 E4AD 1645
Re: Removing PF
On 30/03/2019 23:27, Mouse wrote: > (Rule of thumb: anyone who calls something "secure" or > "insecure" without giving any indication of the threat model in > question either doesn't understand security or hopes you don't; neither > alternative is good. It's not universally applicable - here, for > example, I suspect you were just being a bit over-brief - but it's been > remarkably useful to me.) Deeming it insecure on that basis of all the bug fixes upstream have which haven't been merged in our tree since our last sync including published patches from around this point onwards: https://www.openbsd.org/errata42.html both of which need to be evaluated to see if applicable. Sevan
Re: Removing PF
Mouse wrote: > Security is not a boolean. Some say that security isn't a product, security is a process. Surgeons among us have a particular view on that process ;-) Alex
Re: Removing PF
On Sat, Mar 30, 2019 at 02:43:22PM -0600, Warner Losh wrote: > On Sat, Mar 30, 2019, 2:29 PM Maxime Villard wrote: > > > Le 30/03/2019 à 20:26, Michael van Elst a écrit : > > > On Sat, Mar 30, 2019 at 08:10:21PM +0100, Maxime Villard wrote: > > > > > >> ... sure, meanwhile you didn't really answer to the core of the issue, > > which > > >> I think was stated clearly by Sevan ... > > > > > > The issue is that we need to work on npf before we can drop other code. > > > > ... the questions raised were: why would someone use an insecure firewall? > > ... > > and isn't it irresponsible to provide an insecure firewall? ... you still > > fail to answer ... I see fewer and fewer reasons to keep talking to you, > > given your clear inability to answer in good faith ... > > > > Also, this is a plan to depreciate, not remove from the tree tomorrow. > Declaring it for all to see that it is a rotting, festering caucus is a > good thing. Maybe, it will spur someone to fix that. Extremely unlikely, > but possible. It does let the users know with enough time to migrate and/or > enhance npf to meet their needs. It starts to break the log jam that has > lead to three under supported firewalls in the tree. > > Warner > > > PF(4)Device Drivers Manual PF(4) ... DESCRIPTION The NetBSD version of PF is obsolete, and its use is strongly discouraged. Use npf(7) instead. We had this in the previous N discussions of deleting them.
Re: Removing PF
> the questions raised were: why would someone use an insecure > firewall? (1) "[A]n insecure firewall" strikes me as an attempt to beg the question. Security is not a boolean. All firewalls are insecure; all _code_ is insecure. The only question is, how insecure, and against what threats. (Rule of thumb: anyone who calls something "secure" or "insecure" without giving any indication of the threat model in question either doesn't understand security or hopes you don't; neither alternative is good. It's not universally applicable - here, for example, I suspect you were just being a bit over-brief - but it's been remarkably useful to me.) (2) To answer the question, leaving aside the question-begging attempt: because the code does something they want done. (Surely you could have come up with that much on your own.) If, for example, I wanted a firewall with an FTP proxy, I might well decide that that is important enough to me to be willing to tolerate whatever flaws PF may have. Code that mostly does what I want, even if it has some flaws, is often preferable to code that lacks the flaws but also doesn't actually do what I want done. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Web "documentation" [was Re: Removing PF]
> As for local documentation, suggestions that one must access an
> external resource (web site) for documentation pertaining to the
> configuration of a piece of critical network infrastructure are
> troubling at best. If it's not in a manual page on my local
> installation, it doesn't exist.
This. So very this. And not just in this case.
Webpage "documentation" is, in my experience, critically broken in at
least five ways:
(1) There is usually no way to tell whether the documentation you're
reading matches the code you have; when there is, there is usually no
way to look at the documentation for the version you actually have.
(2) It is useless without a connection to the net.
(3) It requires a relatively large and bloated program to render
readable (even lynx is significantly larger than less, and is a much
less pleasant way to read text).
(4) Nothing ensures that the documentation remains accessible for at
least as long as the software does.
(5) They do not fit the existing documentation paradigm ("man foo").
I have seen attempts to fix 1, 2, and 4 by shipping HTML files. Fixing
3 at the same time requires that the files be hand-written with minimal
markup, rather than the usual blizzard of mechanically generated markup
and insanely long lines that renders the content unreadable with text
tools. And even if that's done, that still leaves 5 unfixed, making me
wonder what value any software author sees in HTML files over manpages
that makes them think it's a tack worth taking.
By the way, (1) is a real issue. At work, once, someone wanted me to
try to build a go wrapper around some C stuff. I failed, in large part
because the (on-the-web) documentation for the reflect package
documented a call that simply didn't exist in the code we had. I had
no way to tell whether this was simple version skew, bugs, or what, and
in any case had no idea what, if anything, could be done about it.
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTMLmo...@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Re: Removing PF
On Sat, Mar 30, 2019 at 11:12:08PM +0100, Piotr Meyer wrote: > On Sat, Mar 30, 2019 at 10:55:23PM +0100, Michael van Elst wrote: > > > Have you actually looked at these commits? He changed parts of the > > internal network API and had to adjust PF code to match these changes > > and keep compiling. You could call that 'maintenance' but hardly 'fixed > > real bugs'. > > Yes, I did. :) > > http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/dist/pf/net/pf.c?rev=1.78=text/x-cvsweb-markup_with_tag=MAIN True, but wasn't in the list. Funny that the bug was introduced by merging a new revision of PF (the bug was in the merging, not in PF) instead of keeping the bit-rotted unmaintained old version. Greetings, -- Michael van Elst Internet: mlel...@serpens.de "A potential Snark may lurk in every tree."
Re: Removing PF
On Sat, Mar 30, 2019, 2:29 PM Maxime Villard wrote: > Le 30/03/2019 à 20:26, Michael van Elst a écrit : > > On Sat, Mar 30, 2019 at 08:10:21PM +0100, Maxime Villard wrote: > > > >> ... sure, meanwhile you didn't really answer to the core of the issue, > which > >> I think was stated clearly by Sevan ... > > > > The issue is that we need to work on npf before we can drop other code. > > ... the questions raised were: why would someone use an insecure firewall? > ... > and isn't it irresponsible to provide an insecure firewall? ... you still > fail to answer ... I see fewer and fewer reasons to keep talking to you, > given your clear inability to answer in good faith ... > Also, this is a plan to depreciate, not remove from the tree tomorrow. Declaring it for all to see that it is a rotting, festering caucus is a good thing. Maybe, it will spur someone to fix that. Extremely unlikely, but possible. It does let the users know with enough time to migrate and/or enhance npf to meet their needs. It starts to break the log jam that has lead to three under supported firewalls in the tree. Warner >
Re: Removing PF
On Sat, Mar 30, 2019 at 08:51:25PM +0100, Piotr Meyer wrote: > > If you care about bugs in pf, open PRs, best with reproducable test > > cases, or just fix the bugs. > There are bugreports already, one with statement related to this > thread (from #50809[1], Feb 2016, three yars ago): Doesn't look like anyone could analyze or reproduce that bug. And the answer was the same as today. > : We really need to decide what to do with pf and ipf. People keep using > : them but it seems that the versions in the tree have bit rotted and we > : get kernel bugs that nobody seems to care about fixing. Particularly > : in the pf case, the code is really old and should be really updated to > : the latest pf if we want to maintain this packet filter in the tree. Just look at the following paragraph. "For that we need to get npf to have feature parity with the other packet filters." It was true 2016, and it is still true. In the meantime we (and that includes Maxime) at least fixed NPF bugs. > BTW: IMO Maxime's arguments are strengthen by fact that he ALREADY > fixed real bugs in PF, as commit history in [3] shows. > > 1 - https://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=50809 > 2 - https://mail-index.netbsd.org/tech-net/2017/03/23/msg006289.html > 3 - > http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/dist/pf/net/?only_with_tag=MAIN Have you actually looked at these commits? He changed parts of the internal network API and had to adjust PF code to match these changes and keep compiling. You could call that 'maintenance' but hardly 'fixed real bugs'. Greetings, -- Michael van Elst Internet: mlel...@serpens.de "A potential Snark may lurk in every tree."
Re: Removing PF
Le 30/03/2019 à 19:22, Michael van Elst a écrit : On Sat, Mar 30, 2019 at 04:55:53PM +0100, Maxime Villard wrote: Of course, if it's really about rototillng things actively in other places and to limit the amount of work to fix the fallout, it suddenly becomes reasonable to remove something you personally don't care about. ... yes, that's part of the goal, removing dead wood makes So, whatever you are not care about, you call dead wood. ... I'm still waiting for you to provide a list of people who maintain PF in NetBSD ... still waiting ... I'm also waiting for you to provide actual answers rather than one-line quotes from my emails, taken out of context, and used to draw glaringly wrong conclusions (if any) ... but I guess no point waiting for that to happen ... We should remember that. ... sure, meanwhile you didn't really answer to the core of the issue, which I think was stated clearly by Sevan ...
Re: Removing PF
Hello. What folks are saying is that they can't do things with NPF that they're currently doing with PF or IPF. It isn't a matter of having a strong preference, it's that, in my case for example, I cannot make the setups I currently use in production work with NPF. And, worse for NPF, when I point this out or ask for suggestions to implement the features I need in NPF to make the switch, I'm met with silence, or, yes, NPF doesn't currently do that. Would I like a secure, mp-safe firewall? Yes, but I need one that has the functionality I currently rely on and, if it's not a newer version of PF, then I need enough documentation, and documented examples, to map a migration from the configurations I'm using and which work, to ones which work in the new environment. What's reiterated in this conversation by, not just me, but at least two other folks who have joined this conversation, is that we're not there yet. For example, someone asked about doing ftp-proxy with NPF. Max claims it's been in NPF since 2011. Ok, ironic that he himself didn't know about that until he looked into the matter, but did he post a link on how to use this 8 year old feature in NPF? No, he did not. If it's there, how do we use it? Where can we read about how to configure it? That's not the only example, but it's a concrete one we've seen in this thread over the past 24 hours. If you want to see NPF embraced, I suggest the following: 1. Make a list of the features missing from NPF that people want in PF and IPF. 2. Make a branch of the NetBSD tree and implement those features using the NPF framework. 3. When you have those features in and working to your satisfaction, discussion can be taken up about merging them back into head. this approach means you don't have to worry about PF or IPF in your branch and you can concentrate on getting NPF up to speed. When it comes time to merge the newly featureful NPF back into head, then Core can decide if it's ready to drop support for PF and/or IPF. those of us who are using PF or IPF know we're dealing with older technology that has issues, but, I'll say it again, those technologies currently do things that NPF apparently doesn't do. You're just not going to get many takers with a promise of less functionality, even if that less functional alternative is more secure. You will see this play out over and over again in a myriad of environments. For the sake of discussion, if I were to take on the effort of importing the current version of PF and if I went so far as to do the work to make it MP-safe, would you still object to having PF in the tree? If the answer is yes, then we're probably at an impass in this discussion. My point is that you're not giving us a real choice here. you're asking us to sign on to a proposal that doesn't deliver functionality we currently have, however flawed it may be. I think we really do want to achieve a common goal, the question is, how to get there? Make NPF dance and sing with feature parity to PF and IPF and then we can discuss. But, I repeat myself. And, as a final note, I'll add that it may be that FreeBSD is discussing dropping PF as we are, but they haven't done it yet and my guess is that they won't until they have a fully functional replacement. I think that needs to be true for us as well. -thanks -Brian
Re: Removing PF
On Sat, Mar 30, 2019 at 08:26:23PM +0100, Michael van Elst wrote: > On Sat, Mar 30, 2019 at 08:10:21PM +0100, Maxime Villard wrote: > > > ... sure, meanwhile you didn't really answer to the core of the issue, which > > I think was stated clearly by Sevan ... > > The issue is that we need to work on npf before we can drop other code. > > If you care about bugs in pf, open PRs, best with reproducable test > cases, or just fix the bugs. There are bugreports already, one with statement related to this thread (from #50809[1], Feb 2016, three yars ago): : We really need to decide what to do with pf and ipf. People keep using : them but it seems that the versions in the tree have bit rotted and we : get kernel bugs that nobody seems to care about fixing. Particularly : in the pf case, the code is really old and should be really updated to : the latest pf if we want to maintain this packet filter in the tree. Although there was conclusions that "NPF is the seemly lack of BRIDGE_IPF" I found that Mindaugas wrote that it should work[2]. BTW: IMO Maxime's arguments are strengthen by fact that he ALREADY fixed real bugs in PF, as commit history in [3] shows. 1 - https://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=50809 2 - https://mail-index.netbsd.org/tech-net/2017/03/23/msg006289.html 3 - http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/dist/pf/net/?only_with_tag=MAIN Regards, -- Piotr 'aniou' Meyer
Re: Removing PF
On Sat, Mar 30, 2019 at 08:10:21PM +0100, Maxime Villard wrote: > ... sure, meanwhile you didn't really answer to the core of the issue, which > I think was stated clearly by Sevan ... The issue is that we need to work on npf before we can drop other code. If you care about bugs in pf, open PRs, best with reproducable test cases, or just fix the bugs. -- Michael van Elst Internet: mlel...@serpens.de "A potential Snark may lurk in every tree."
Re: Removing PF
On Sat, Mar 30, 2019 at 04:55:53PM +0100, Maxime Villard wrote: > > Of course, if it's really about rototillng things actively in other places > > and to limit the amount of work to fix the fallout, it suddenly becomes > > reasonable to remove something you personally don't care about. > > ... yes, that's part of the goal, removing dead wood makes So, whatever you are not care about, you call dead wood. We should remember that. -- Michael van Elst Internet: mlel...@serpens.de "A potential Snark may lurk in every tree."
Re: Removing PF
And, while I'm at it, I like 'pf's "synproxy state" feature on incoming connections. Is there an equivalent in NPF? Looks like "random-id" might be similar to "modulate state" for outgoing connections. -- |/"\ John D. Baker, KN5UKS NetBSD Darwin/MacOS X |\ / jdbaker[snail]consolidated[flyspeck]net OpenBSDFreeBSD | X No HTML/proprietary data in email. BSD just sits there and works! |/ \ GPGkeyID: D703 4A7E 479F 63F8 D3F4 BD99 9572 8F23 E4AD 1645
Re: Removing PF
Le 30/03/2019 à 16:24, Michael van Elst a écrit : On Sat, Mar 30, 2019 at 03:11:22PM +0100, Maxime Villard wrote: The best way forward to drop PF is to actively develop NPF. ... and the best way to actively develop NPF is to stop splitting effort on three firewalls So now you stop maintaining PF and IPF and redirect your efforts to NPF ? If not you, who does ? Somehow this doesn't fit into your narrative that there are no maintainers. ... yes, when PF is not there I don't have to worry about PF-related PRs that report huge vulns in the general indifference, and I don't need to waste time investigating, fixing, and documenting the vulns because I feel like I should care for the poor vulnerable people that use PF ... there indeed are no maintainers, just people like me who make (or rather, have made, and don't want to anymore) changes to prevent the code from collapsing completely, or who mechanically change APIs without ever testing for real, thereby possibly adding even more bugs and vulns than there already are ... Of course, if it's really about rototillng things actively in other places and to limit the amount of work to fix the fallout, it suddenly becomes reasonable to remove something you personally don't care about. ... yes, that's part of the goal, removing dead wood makes stuff easier to maintain and improve, and as discussed in other threads, things that have legitimate reasons to go, have legitimate reasons to go ... and stop directing users to the three of them ... It's a choice, users like that, in particular if that choice makes a difference. Someone like you should understand this. ... I've already said I understand the "missing features" aspect of things, but I've also already questioned whether it was a really good argument, because I don't understand how someone can possibly want a flawed firewall, which, in the case of PF, can open more security holes than it plugs ... so, why? ... Sevan has summed up pretty well the underlying question: isn't it irresponsible to ship an insecure firewall and give our users the impression that they can use it, or even the possibility to use it ... so, isn't it irresponsible?
Re: Removing PF
Just to add my $0.02 The eternal interface of my router has multiple IP addresses. One is dynamic--assigned by my ISP's DHCP server, the other is static and used to access the status/configuration interface of the ADSL modem. I've crafted the interface intialization (via dhcpcd and the exit-hook script) to guarantee the DHCP- (or PPPOE-) assigned address is always first. This lets me use 'pf's "netif:0" notation to always select this primary address alone for use in NAT or filter rules. (Since I control the static auxiliary address, I can refer to it with appropriate variables.) In the available local documentation, I see no equivalent facility in NPF. While "ifaddrs(netif)" does dynamic lookup of addresses, there appears to be no mechanism to select a subset of them. (The dynamic lookup feature is even more important for users stuck behind PPPOE-ADSL systems like AT where the public address changes frequently.) Similarly, 'pf's "netif:network" notation resolves to the network address of an interface's primary IP address. Selection of address subset from result of "ifaddrs(netif)" and network address generation from an interface name are requirements for me to consider learning to configure NPF. As for local documentation, suggestions that one must access an external resource (web site) for documentation pertaining to the configuration of a piece of critical network infrastructure are troubling at best. If it's not in a manual page on my local installation, it doesn't exist. -- |/"\ John D. Baker, KN5UKS NetBSD Darwin/MacOS X |\ / jdbaker[snail]consolidated[flyspeck]net OpenBSDFreeBSD | X No HTML/proprietary data in email. BSD just sits there and works! |/ \ GPGkeyID: D703 4A7E 479F 63F8 D3F4 BD99 9572 8F23 E4AD 1645
Re: Removing PF
On Sat, Mar 30, 2019 at 03:11:22PM +0100, Maxime Villard wrote: > > > The best way forward to drop PF is to actively develop NPF. > > ... and the best way to actively develop NPF is to stop splitting effort on > three firewalls So now you stop maintaining PF and IPF and redirect your efforts to NPF ? If not you, who does ? Somehow this doesn't fit into your narrative that there are no maintainers. Of course, if it's really about rototillng things actively in other places and to limit the amount of work to fix the fallout, it suddenly becomes reasonable to remove something you personally don't care about. > and stop directing users to the three of them ... It's a choice, users like that, in particular if that choice makes a difference. Someone like you should understand this. -- Michael van Elst Internet: mlel...@serpens.de "A potential Snark may lurk in every tree."
Re: Removing PF
Le 30/03/2019 à 14:34, Michael van Elst a écrit : On Sat, Mar 30, 2019 at 02:18:29PM +0100, Piotr Meyer wrote: On Sat, Mar 30, 2019 at 12:59:00PM -, Michael van Elst wrote: Just to get the facts straight: NPF has a bigger market share *outside* NetBSD, at least certainly for commercial users. They also contribute. Ironically, the same is also true for PF... But contributions to PF are made against OpenBSD kernel, true? And the essence of problem is that: - NetBSD version of PF is too old to adapt them without ton of work, That's self-evident, the "ton of work" is of course just the same that would have been needed if you had tracked pf development. ... which doesn't withdraw anything from the fact that no one has been willing to do this work over the last 10 years, and likely not in the next 10 years either ... - even current PF in OpenBSD doesn't fit very well into MP kernels Whatever "MP kernel" is. It no longer fits that well to our recent MP changes of the network stack, but that mostly results in being less efficient, not in being more difficult to port or track. ... reports from FreeBSD on the matter indicate that it is more difficult to port, unsurprisingly, not to mention that having PF will then be an obstacle to enabling full MP-safety in GENERIC ... so no, it's not just less efficient, it becomes a big obstacle to full MP-safety in GENERIC ... and that makes "fresh" import cumbersome and fruitless It's always cumbersome to import foreign code. NPF won't be any different, but since it is a newer development, it has some headstart. Don't believe NPF is something "native" and thus easier to track, see the recent change from our "native" proplib to its proprietary library. ... NPF is NetBSD's native firewall and is well integrated in the NetBSD kernel, the recent switch from proplib to libnv is very anecdotical, if anything ... Le 30/03/2019 à 14:47, Michael van Elst a écrit : That's a myth. When I switched from IPF to NPF, the first thing required was to fix NPF and NPF-related bugs. The NetBSD version of it was pretty much unmaintained, it still is to a lesser degree. ... unmaintained as in "it was 2 months behind the Github version", not as in "it was 11 years behind the OpenBSD version" ... the NPF development is jumping between NetBSD and Github, with changes being regularly merged in both directions by Mindaugas from time to time ... The best way forward to drop PF is to actively develop NPF. ... and the best way to actively develop NPF is to stop splitting effort on three firewalls and stop directing users to the three of them ... it's also to stop this illusional/irrational approach by which it is fine to use inflammable firewalls ... yes, each software has bugs, but maintained software benefits from improvements, outdated software doesn't ... outdated software must be kept synchronized, which brings us back to the first point, no one wants to work on that ...
Re: Removing PF
Hello, If you ignore the feature comparison with npf and you are and avid PF on NetBSD fan, you should be concerned with the following: On 29/03/2019 20:26, Maxime Villard wrote: > Currently, NetBSD's PF is 11 years old, has received no maintenance, > and has accumulated bugs and vulnerabilities that were fixed upstream > but not in NetBSD. The latest examples are two vulnerabilities > recently discovered in PF, that haven't been fixed in NetBSD's PF by > lack of interest. Your firewall of choice in NetBSD (PF) is lacking many bug fixes which need to be integrated either by back porting or importing an up to date version of pf. It is irresponsible to ship an insecure firewall with known issues and an added burden to the security team. To address the security issues requires paying off a huge amount of technical debt in the form of bringing things up to date with upstream version of PF or analysing and back porting changes. Should NetBSD-9 ship with a version of PF with known security issues? Is anyone willing to step forward and take on the work? Sevan
Re: Removing PF
On Sat, Mar 30, 2019 at 12:59:00PM -, Michael van Elst wrote: > >Just to get the facts straight: NPF has a bigger market share *outside* > >NetBSD, at least certainly for commercial users. They also contribute. > > Ironically, the same is also true for PF... But contributions to PF are made against OpenBSD kernel, true? And the essence of problem is that: - NetBSD version of PF is too old to adapt them without ton of work, - even current PF in OpenBSD doesn't fit very well into MP kernels and that makes "fresh" import cumbersome and fruitless I'm right? Regards, -- Piotr 'aniou' Meyer
Re: Removing PF
On Sat, Mar 30, 2019 at 01:40:12PM +0100, Piotr Meyer wrote: > Do you think that there is any equality between remote-triggered > crash and lack of specific feature? BTW: you joke makes strong > argument against PF - there wasn't push for updating NPF features > because they already works in - as we NOW know - buggy and insecure > PF. That's a myth. When I switched from IPF to NPF, the first thing required was to fix NPF and NPF-related bugs. The NetBSD version of it was pretty much unmaintained, it still is to a lesser degree. The best way forward to drop PF is to actively develop NPF. Greetings, -- Michael van Elst Internet: mlel...@serpens.de "A potential Snark may lurk in every tree."
Re: Removing PF
On Sat, Mar 30, 2019 at 02:18:29PM +0100, Piotr Meyer wrote: > On Sat, Mar 30, 2019 at 12:59:00PM -, Michael van Elst wrote: > > >Just to get the facts straight: NPF has a bigger market share *outside* > > >NetBSD, at least certainly for commercial users. They also contribute. > > > > Ironically, the same is also true for PF... > > But contributions to PF are made against OpenBSD kernel, true? And the > essence of problem is that: > - NetBSD version of PF is too old to adapt them without ton of work, That's self-evident, the "ton of work" is of course just the same that would have been needed if you had tracked pf development. > - even current PF in OpenBSD doesn't fit very well into MP kernels Whatever "MP kernel" is. It no longer fits that well to our recent MP changes of the network stack, but that mostly results in being less efficient, not in being more difficult to port or track. > and that makes "fresh" import cumbersome and fruitless It's always cumbersome to import foreign code. NPF won't be any different, but since it is a newer development, it has some headstart. Don't believe NPF is something "native" and thus easier to track, see the recent change from our "native" proplib to its proprietary library. Greetings, -- Michael van Elst Internet: mlel...@serpens.de "A potential Snark may lurk in every tree."
Re: Removing PF
mlel...@serpens.de (Michael van Elst) wrote: > > >Just to get the facts straight: NPF has a bigger market share *outside* > >NetBSD, at least certainly for commercial users. They also contribute. > > Ironically, the same is also true for PF... > Well that tells something about NetBSD, doesn't it?.. -- Mindaugas
Re: Removing PF
rm...@netbsd.org (Mindaugas Rasiukevicius) writes: >Brian Buhrow wrote: >> <...> what would make it harder to maintain than NPF, which has >> absolutely no market share outside of NetBSD? >Just to get the facts straight: NPF has a bigger market share *outside* >NetBSD, at least certainly for commercial users. They also contribute. Ironically, the same is also true for PF... -- -- Michael van Elst Internet: mlel...@serpens.de "A potential Snark may lurk in every tree."
Re: Removing PF
Brian Buhrow wrote: > <...> what would make it harder to maintain than NPF, which has > absolutely no market share outside of NetBSD? Just to get the facts straight: NPF has a bigger market share *outside* NetBSD, at least certainly for commercial users. They also contribute. -- Mindaugas
Re: Removing PF
Johnny Billquist a écrit : > On 2019-03-30 13:13, BERTRAND Joël wrote: >> Maxime Villard a écrit : >>> Hum, wait a minute in here. Am I being totally dumb, or NPF does support >>> ftp-proxy since 2011? See src/dist/pf/usr.sbin/ftp-proxy/npf.c, and the >>> associated commit message. >> >> There is some pieces of code to try to support NPF in ftp-proxy. But >> this code doesn't work as expected (and some code is between #if >> 0/#endif). I have tried to fix this code without success. Maybe I have >> misunderstood some kernel NPF stuff, but my modified ftp-proxy crashed >> kernel. > > Are you saying that NPF is not being updated or supported? > Should we maybe remove it? I have only written that _my_ version of ftp-proxy triggers some bugs in NetBSD-8's npf code. I have no time to investigate, thus I have removed ftp-proxy.
Re: Removing PF
On Sat, Mar 30, 2019 at 01:21:27PM +0100, Johnny Billquist wrote: > Are you saying that NPF is not being updated or supported? > Should we maybe remove it? > Having broken code around for 8 years without anyone even much noticing > (except you maybe) or fixing it would suggest the code is rather rotten, and > little used. > > Only half a :-) intended. Do you think that there is any equality between remote-triggered crash and lack of specific feature? BTW: you joke makes strong argument against PF - there wasn't push for updating NPF features because they already works in - as we NOW know - buggy and insecure PF. PS. Looks like Open, with larger userbase hasn't similar objections before pruning cumbersome code. -- Piotr 'aniou' Meyer
Re: Removing PF
On 2019-03-30 13:13, BERTRAND Joël wrote: Maxime Villard a écrit : Hum, wait a minute in here. Am I being totally dumb, or NPF does support ftp-proxy since 2011? See src/dist/pf/usr.sbin/ftp-proxy/npf.c, and the associated commit message. There is some pieces of code to try to support NPF in ftp-proxy. But this code doesn't work as expected (and some code is between #if 0/#endif). I have tried to fix this code without success. Maybe I have misunderstood some kernel NPF stuff, but my modified ftp-proxy crashed kernel. Are you saying that NPF is not being updated or supported? Should we maybe remove it? Having broken code around for 8 years without anyone even much noticing (except you maybe) or fixing it would suggest the code is rather rotten, and little used. Only half a :-) intended. Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: b...@softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol
Re: Removing PF
Maxime Villard a écrit : > Hum, wait a minute in here. Am I being totally dumb, or NPF does support > ftp-proxy since 2011? See src/dist/pf/usr.sbin/ftp-proxy/npf.c, and the > associated commit message. There is some pieces of code to try to support NPF in ftp-proxy. But this code doesn't work as expected (and some code is between #if 0/#endif). I have tried to fix this code without success. Maybe I have misunderstood some kernel NPF stuff, but my modified ftp-proxy crashed kernel. Regards, JKB
Re: Removing PF
On Sat, Mar 30, 2019 at 10:38:21AM +0100, Maxime Villard wrote: > > Ah, silly me, too abstract. Do you really believe the maintainers > > of ipf and npf would give up their projects to work on pf ? > > Ah because there are maintainers of ipf? There is _no_ maintainer of ipf > whatsoever. Do you understand, or not? Give me a list of people who maintain > ipf. Just like, give me a list of people who maintain pf in NetBSD. What makes you think there are not maintainers of ipf ? Because there's not been any commits for some time ? Actually I'm not aware of show-stopper bugs in ipf, and I run several servers (netbsd-8) facing internet, with ipv6 and quite a bit of traffic. No problems with ipf AFAIK. the tools could be a bit smarter with ipv6 rules and I intend to look at this, but it's not a big deal for daily use. -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: Removing PF
On Sat, Mar 30, 2019 at 11:59:13AM +0100, Maxime Villard wrote: > [...] > Please do not confuse, this thread is about PF, not IPF. I believe we can > easily resolve the ftp-proxy support issue on NPF. I understant it's about pf. But you made it diverge with your statement about split efforts between 3 firewalls. -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: Removing PF
Le 30/03/2019 à 11:06, Manuel Bouyer a écrit : On Sat, Mar 30, 2019 at 06:07:01AM +0100, Maxime Villard wrote: [...] If the effort hadn't been split on three firewalls in the last 10 years, but rather had been focused on only one, don't you think NPF would now be featureful? Exactly. If work had been done to improve ipf instead of reinventing the wheel, ipf would probably be in much better shaoe now. Well, you're not wrong, but there were also many good reasons for developing a firewall from scratch, and NPF is now used in commercial products, while IPF is being dropped by commercial products. NPF is not a failure. I'm still using ipf because npf miss the features I need (essentialy groups). Each time I mentioned this, no comments on this topic were made. This is one of the reasons why we keep IPF for now, to wait for NPF to reach feature-parity. This point hasn't been ignored. But this thread is about PF, not IPF, and was prompted by the two recent PF vulns that were not fixed in NetBSD by anyone. I'm talking about the current state of affairs, and how to move forward. The current state of affairs is that PF is in a deplorable state compared to NPF, which "only" lacks a few features. The argument made about "ftp-proxy", while understandable, does remain highly questionable. PF hasn't received any security updates in NetBSD, so do people really wish to still use it for ftp-proxy? It seems silly to use an outdated firewall, because it creates more security holes than it plugs. Firewalls are not supposed to be inflammable. Please do not confuse, this thread is about PF, not IPF. I believe we can easily resolve the ftp-proxy support issue on NPF.
Re: Removing PF
Le 30/03/2019 à 10:06, BERTRAND Joël a écrit : Michael van Elst a écrit : joel.bertr...@systella.fr (=?UTF-8?Q?BERTRAND_Jo=c3=abl?=) writes: Just a question. I use NPF for a while on NetBSD-8 that provides router functionalities (over a lot of network interfaces with agr, bridge, vpn and some others...). NPF runs fine but I'm unable to configure ftp-proxy. Last time I have checked, ftp proxy doesn't work and I have tried to fix ftp-proxy (src/dist/pf/usr.sbin/ftp-proxy) without any success. A lot of npf code is missing or broken. NPF so far doesn't implement a ftp proxy. The ftp-proxy you found is for PF. I know. But without a function like ftp-proxy, npf cannot replace fp. ftp-proxy seems to be a very simple code. Before dropping fp, I think ftp-proxy has to run with npf. JB Fair enough, this _is_ an actual reason for not removing PF right now. I'll look at how the ftp-proxy stuff can work on NPF.
Re: Removing PF
Le 30/03/2019 à 08:51, Michael van Elst a écrit : On Sat, Mar 30, 2019 at 08:17:44AM +0100, Maxime Villard wrote: Le 30/03/2019 à 08:07, Michael van Elst a écrit : m...@m00nbsd.net (Maxime Villard) writes: If the effort hadn't been split on three firewalls in the last 10 years, but rather had been focused on only one, don't you think NPF would now be featureful? Now if the effort of the world hadn't been split among Windows, MacOS and Linux, but rather had been focused on only NetBSD, don't you think NetBSD would now be featureful ? Yes, if the effort had been on one firewall instead of three, the one chosen would be more functional. Period. You have absolutely no point, do you? You just don't understand the point. Period. Hey, I said Period, it must be true. Do you believe people would give up their efforts on Windows, or MacOS or Linux to focus on NetBSD ? Ah, silly me, too abstract. Do you really believe the maintainers of ipf and npf would give up their projects to work on pf ? Ah because there are maintainers of ipf? There is _no_ maintainer of ipf whatsoever. Do you understand, or not? Give me a list of people who maintain ipf. Just like, give me a list of people who maintain pf in NetBSD. The point is that you only alienate people that are not following your decision. Period. Hah, again. Decision? I haven't taken any decision, I've made a clear and logical proposal to drop PF, that I am sending to a public mailing list for further discussion. You, on the other side, have put forward zero clear argument, and have just thrown random, inaccurate and irrelevant comparisons, that leave my proposal completely unchallenged.
Re: Removing PF
On Sat, Mar 30, 2019 at 06:07:01AM +0100, Maxime Villard wrote: > [...] > If the effort hadn't been split on three firewalls in the last 10 years, but > rather had been focused on only one, don't you think NPF would now be > featureful? Exactly. If work had been done to improve ipf instead of reinventing the wheel, ipf would probably be in much better shaoe now. I'm still using ipf because npf miss the features I need (essentialy groups). Each time I mentioned this, no comments on this topic were made. -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: Removing PF
Le 30/03/2019 à 10:40, Maxime Villard a écrit : Le 30/03/2019 à 10:06, BERTRAND Joël a écrit : Michael van Elst a écrit : joel.bertr...@systella.fr (=?UTF-8?Q?BERTRAND_Jo=c3=abl?=) writes: Just a question. I use NPF for a while on NetBSD-8 that provides router functionalities (over a lot of network interfaces with agr, bridge, vpn and some others...). NPF runs fine but I'm unable to configure ftp-proxy. Last time I have checked, ftp proxy doesn't work and I have tried to fix ftp-proxy (src/dist/pf/usr.sbin/ftp-proxy) without any success. A lot of npf code is missing or broken. NPF so far doesn't implement a ftp proxy. The ftp-proxy you found is for PF. I know. But without a function like ftp-proxy, npf cannot replace fp. ftp-proxy seems to be a very simple code. Before dropping fp, I think ftp-proxy has to run with npf. JB Fair enough, this _is_ an actual reason for not removing PF right now. I'll look at how the ftp-proxy stuff can work on NPF. Hum, wait a minute in here. Am I being totally dumb, or NPF does support ftp-proxy since 2011? See src/dist/pf/usr.sbin/ftp-proxy/npf.c, and the associated commit message.
Re: Removing PF
On Sat, Mar 30, 2019 at 10:06:27AM +0100, BERTRAND Joël wrote: > I know. But without a function like ftp-proxy, npf cannot replace fp. > ftp-proxy seems to be a very simple code. Before dropping fp, I think > ftp-proxy has to run with npf. I agree, there are a couple of functions that NPF has to adopt before it can replace pf and ipf. The earlier, the better. -- Michael van Elst Internet: mlel...@serpens.de "A potential Snark may lurk in every tree."
Re: Removing PF
Michael van Elst a écrit : > joel.bertr...@systella.fr (=?UTF-8?Q?BERTRAND_Jo=c3=abl?=) writes: > >> Just a question. I use NPF for a while on NetBSD-8 that provides router >> functionalities (over a lot of network interfaces with agr, bridge, vpn >> and some others...). NPF runs fine but I'm unable to configure >> ftp-proxy. Last time I have checked, ftp proxy doesn't work and I have >> tried to fix ftp-proxy (src/dist/pf/usr.sbin/ftp-proxy) without any >> success. A lot of npf code is missing or broken. > > NPF so far doesn't implement a ftp proxy. The ftp-proxy you found is for PF. > I know. But without a function like ftp-proxy, npf cannot replace fp. ftp-proxy seems to be a very simple code. Before dropping fp, I think ftp-proxy has to run with npf. JB
Re: Removing PF
joel.bertr...@systella.fr (=?UTF-8?Q?BERTRAND_Jo=c3=abl?=) writes: > Just a question. I use NPF for a while on NetBSD-8 that provides router >functionalities (over a lot of network interfaces with agr, bridge, vpn >and some others...). NPF runs fine but I'm unable to configure >ftp-proxy. Last time I have checked, ftp proxy doesn't work and I have >tried to fix ftp-proxy (src/dist/pf/usr.sbin/ftp-proxy) without any >success. A lot of npf code is missing or broken. NPF so far doesn't implement a ftp proxy. The ftp-proxy you found is for PF. -- -- Michael van Elst Internet: mlel...@serpens.de "A potential Snark may lurk in every tree."
Re: Removing PF
On Sat, Mar 30, 2019 at 08:17:44AM +0100, Maxime Villard wrote: > Le 30/03/2019 à 08:07, Michael van Elst a écrit : > > m...@m00nbsd.net (Maxime Villard) writes: > > > > > If the effort hadn't been split on three firewalls in the last 10 years, > > > but > > > rather had been focused on only one, don't you think NPF would now be > > > featureful? > > > > Now if the effort of the world hadn't been split among Windows, MacOS > > and Linux, but rather had been focused on only NetBSD, don't you think > > NetBSD would now be featureful ? > > Yes, if the effort had been on one firewall instead of three, the one > chosen would be more functional. Period. You have absolutely no point, > do you? You just don't understand the point. Period. Hey, I said Period, it must be true. Do you believe people would give up their efforts on Windows, or MacOS or Linux to focus on NetBSD ? Ah, silly me, too abstract. Do you really believe the maintainers of ipf and npf would give up their projects to work on pf ? Still not getting it ? The point is that you only alienate people that are not following your decision. Period. Hah, again. Greetings, -- Michael van Elst Internet: mlel...@serpens.de "A potential Snark may lurk in every tree."
Re: Removing PF
Le 30/03/2019 à 08:07, Michael van Elst a écrit : m...@m00nbsd.net (Maxime Villard) writes: If the effort hadn't been split on three firewalls in the last 10 years, but rather had been focused on only one, don't you think NPF would now be featureful? Now if the effort of the world hadn't been split among Windows, MacOS and Linux, but rather had been focused on only NetBSD, don't you think NetBSD would now be featureful ? Yes, if the effort had been on one firewall instead of three, the one chosen would be more functional. Period. You have absolutely no point, do you?
Re: Removing PF
m...@m00nbsd.net (Maxime Villard) writes: >If the effort hadn't been split on three firewalls in the last 10 years, but >rather had been focused on only one, don't you think NPF would now be >featureful? Now if the effort of the world hadn't been split among Windows, MacOS and Linux, but rather had been focused on only NetBSD, don't you think NetBSD would now be featureful ? -- -- Michael van Elst Internet: mlel...@serpens.de "A potential Snark may lurk in every tree."
Re: Removing PF
Le 29/03/2019 à 22:10, Brian Buhrow a écrit : ... And, prey tell, why is it harder to maintain a modern version of PF than NPF? ... It is about the _fourth_ time you ask this question, and for the fourth time I am going to provide the exact same answer. PF has a legacy design that makes it difficult to import in MP-safe kernels like NetBSD or FreeBSD. NPF is already MP-safe and well integrated in the NetBSD kernel, and that's why it is a lot easier to work on. Is it clear now, or do you want to ask a fifth time? Again, if it was as easy you as think it is, we woud likely have maintained it. The reality is that no one is willing to maintain PF. At the risk of being extremely rude, although that is not my intention, if as much effort had been put into improving the functionality of NPF as has been put into the effort to get pf removed, I dare say, NPF would now be up to PF in functionality and the conversation would be easier to have. If the effort hadn't been split on three firewalls in the last 10 years, but rather had been focused on only one, don't you think NPF would now be featureful? The fragmented effort that has gone into fixing here and there crazy bugs in PF and IPF, just because random people (like you) wanted their outdated firewall not to collapse, is precisely what has brought us to the current state, that is, three half-baked firewalls, none of which is 100% functional or featureful. I'm even talking from experience here; last year I was looking at network- related PRs, and I found a PR from 2010 where a guy had reported that a single TCP packet could crash the kernel under PF. It turned out that our version of PF had a signedness bug that could cause a length check to pass, which caused a fatal memory corruption. Checking the guy's github, he even had written in 2010 an exploit for it. So for 8 years, the vuln had been sitting in our Gnats with a public exploit, and strictly no one giving a fuck about it. I proceeded to write a reproducer, fix the vuln, then pull it up, then write a security advisory for it. All of that is an awful waste of time and energy, for everybody. Perpetuating this crazy status quo is not going to make the situation any better, it will just make us continue splitting efforts. If we already manage to go from three firewalls to only two, it's a good progress, and again, it reduces the maintenance burden on the kernel. In the case of PF, I've already said it in the internal discussion (but not on tech-kern), if we wanted to import a new version, it would likely be better to remove the one we have, and make a clean import from scratch. In any case, this proposal (about removing PF) is not illegitimate or stupid, and it makes sense, given the awful state of PF. If you want to use outdated firewalls that haven't received security fixes, you can as well follow the NetBSD-6 branch, or older. And, once done, all those features would have to be maintained going forward, No, NPF is homegrown, each feature added doesn't need to be regularly maintained, contrary to PF. not to mention that there would be absolutely no testing outside of the NetBSD environment with NPF. As a matter of fact this is incorrect, NPF works on Linux too, there have been tests/development made on CentOS. I also have a vague memory of NPF being embedded in DPDK. So no, NPF is definitely not NetBSD-specific, and has received testing outside.
Re: Removing PF
On 2019-03-30 01:19, Matt Sporleder wrote: > What features, exactly, are missing? Runtime NAT reconfiguration. miniupnpd wants to be able to add/remove filter rules (npf can do this) as well as add/remove NAT entries (npf couldn't do this last time I checked). -- Kind Regards, Jan Danielsson
Re: Removing PF
Hello. I will examine the documentation for npf again, but here are the issues I think we should resolve with npf before we rip out pf or ipf. 1. The documentation for npf is still pretty incomplete. The example files are there, but the comments, the last time I looked, were not as complete as I think they should be.The man pages should also explain the syntax of the configuration files in more detail, again with examples. The features available in npf should be more fully enumerated. It does me no good to have a feature in npf if I don't know if it exists or how to use it. The recent example of mss clamping in the mailing list being an example. Maxine says that feature exists, but Patrick says he doesn't know how to use it and he didn't even know it was there. 2. For me to use npf at all, I absolutely need to have the route-through/reply-to feature. Pf has that feature. I have 2 choices at this point if I want to continue using NetBSD as a routing system: Keep pf working and performant in modern versions of NetBSD on my own or teach npf how to do route-through/reply-to. Or, I could switch OS's. How many other users/developers are in this position?I don't think we know. 3. The announcement should be included in the NetBSD-8 documentation to say that pf and ipf are deprecated in NetBSD-8 and will be removed in NetBSD-9. In my view, it is insufficient to only include an announcement like this in the -current documentation. It should be added to the last_minute and major changes file for NetBSD-8. -Brian On Mar 29, 8:19pm, Matt Sporleder wrote: } Subject: Re: Removing PF } } } What features, exactly, are missing? >-- End of excerpt from Matt Sporleder
Re: Removing PF
> On Mar 29, 2019, at 5:10 PM, Brian Buhrow wrote: > >hello. My suggestion is, rather than strongly advocating for the > removal of pf, which your message readily conceeds has more functionality > than npf does at this time, why not marshall an effort to get the missing > features from pf into npf? I totally understand that the work to improve > NPF's scalability and robustness is vitally important, but if you want to > get consensus on removing npf, let's now get the additional functionality > into NPF. Once done, we can discuss removing pf again. At the risk of > being extremely rude, although that is not my intention, if as much effort > had been put into improving the functionality of NPF as has been put into > the effort to get pf removed, I dare say, NPF would now be up to PF in > functionality and the conversation would be easier to have. > >right now, NPF doesn't do what I need and from what I can tell in the > documentation, I'm not sure how to write the functionality into NPF. that > leaves me with the task of porting PF to a newer version of NetBSD on my > own, with no support from fellow NetBSD users, running an older version of > NetBSD as long as is feasible, or switching to another OS. You say the > effort to port modern version of PF to NetBSD is greater than writing the > additional functionality into NPF. Yet, somehow, after years, that > functionality is not in NPF. If it were that easy, I think it would have > been done. And, prey tell, why is it harder to maintain a modern version > of PF than NPF? If, for the sake of discussion, a modern version of PF were > imported and it were modified to scale with the new features of the network > stack in NetBSD, what would make it harder to maintain than NPF, which has > absolutely no market share outside of NetBSD? If it is simply that you > don't want to do it, that's fine, but fundamentally, I don't really see > what's harder about maintaining one piece of code versus another. The > documentation for PF is much more complete than it is for NPF, and when I > looked into the NPF source code, it looked like I would hav to grow a lot > of features in NPF to gain parity with PF. And, once done, all those > features would have to be maintained going forward, not to mention that > there would be absolutely no testing outside of the NetBSD environment with > NPF. And, even if the PF code in NetBSD differes from PF under OpenBSD, > there would be enough similarity that some cross testing and patching would > be helpful. >I know you fundamentally disagree with this analysis and I understand > you are more familiar with the specific code inn question than I am, but I > think the fundamental problem here is that the NetBSD network stack is in > flux as folks work to MP-ify it and, the truth is, any firewall > implementation in the stack is going to require a lot of effort to keep up > with those changes. As you've noted, firewalls are hard to write and > maintain. NPF might be a better solution than PF or IPF, but it certainly > doesn't have as many eyes on it and there are a lot of folks who know how > to use one or both of the other solutions who don't have a clue about how > NPF works or should be configured. I think dismissing that knowledge from > the equation is a mistake and should factor heavily in the decision about > which way we should go. >I also think Core should consider funding a project to either add the > missing functionality to NPF, along with improving the documentation, or > funding a project to bring PF up to modern standards of functionality and > scalability. > > -thanks > -Brian What features, exactly, are missing?
Re: Removing PF
hello. My suggestion is, rather than strongly advocating for the removal of pf, which your message readily conceeds has more functionality than npf does at this time, why not marshall an effort to get the missing features from pf into npf? I totally understand that the work to improve NPF's scalability and robustness is vitally important, but if you want to get consensus on removing npf, let's now get the additional functionality into NPF. Once done, we can discuss removing pf again. At the risk of being extremely rude, although that is not my intention, if as much effort had been put into improving the functionality of NPF as has been put into the effort to get pf removed, I dare say, NPF would now be up to PF in functionality and the conversation would be easier to have. right now, NPF doesn't do what I need and from what I can tell in the documentation, I'm not sure how to write the functionality into NPF. that leaves me with the task of porting PF to a newer version of NetBSD on my own, with no support from fellow NetBSD users, running an older version of NetBSD as long as is feasible, or switching to another OS. You say the effort to port modern version of PF to NetBSD is greater than writing the additional functionality into NPF. Yet, somehow, after years, that functionality is not in NPF. If it were that easy, I think it would have been done. And, prey tell, why is it harder to maintain a modern version of PF than NPF? If, for the sake of discussion, a modern version of PF were imported and it were modified to scale with the new features of the network stack in NetBSD, what would make it harder to maintain than NPF, which has absolutely no market share outside of NetBSD? If it is simply that you don't want to do it, that's fine, but fundamentally, I don't really see what's harder about maintaining one piece of code versus another. The documentation for PF is much more complete than it is for NPF, and when I looked into the NPF source code, it looked like I would hav to grow a lot of features in NPF to gain parity with PF. And, once done, all those features would have to be maintained going forward, not to mention that there would be absolutely no testing outside of the NetBSD environment with NPF. And, even if the PF code in NetBSD differes from PF under OpenBSD, there would be enough similarity that some cross testing and patching would be helpful. I know you fundamentally disagree with this analysis and I understand you are more familiar with the specific code inn question than I am, but I think the fundamental problem here is that the NetBSD network stack is in flux as folks work to MP-ify it and, the truth is, any firewall implementation in the stack is going to require a lot of effort to keep up with those changes. As you've noted, firewalls are hard to write and maintain. NPF might be a better solution than PF or IPF, but it certainly doesn't have as many eyes on it and there are a lot of folks who know how to use one or both of the other solutions who don't have a clue about how NPF works or should be configured. I think dismissing that knowledge from the equation is a mistake and should factor heavily in the decision about which way we should go. I also think Core should consider funding a project to either add the missing functionality to NPF, along with improving the documentation, or funding a project to bring PF up to modern standards of functionality and scalability. -thanks -Brian
