1# $NetBSD: TODO.npf,v 1.15 2025/04/17 19:54:24 gdt Exp $ 2 3# Meta 4 5This file intends to be the location for all work needing to be done 6for npf within NetBSD, except for bugs that are straightforward enough 7to live in gnats. The presence of an item does not imply that there 8is consensus that the item should be implemented. 9 10(The older TODO list, last modified in May, 2020: 11 https://www.netbsd.org/~rmind/npf/__tasklist.html 12has been merged into this file.) 13 14## Review all items to see if they are still relevant and correct. 15 16# Syncing 17 18## from https://github.com/rmind/npf/ 19 20Periodically, check this repo to see if there are changes/improvements 21that are not in NetBDS and which are appopriate, and merge them. 22 23## to https://github.com/rmind/npf/ 24 25Periodically, compare code between NetBSD and this repo, and file PRs 26for changes in NetBSD as appropriate, when there are not already PRs. 27 28## Merge https://github.com/rmind/npf doc subdir 29 30rmind's repo has a doc directory. Some content is in man pages and 31thus available within NetBSD. Understand if there are things that 32aren't (likely), decide how to have them in NetBSD 33(/usr/share/doc/npf?) and add them. 34 35# Documentation 36 37## Conversion Guides 38 39Add instructions for converting configuration for other packet filters 40to npf configuration. 41 42## More Examples 43 44## Man page nits 45 46### npf.conf: rule group processing 47 48Explain if groups are processed in the same order as npf.conf. 49Explain what happens if a packet matches the group header, but does 50not match a rule in the group. Currently it is unclear exactly when 51the default group is run, and if multiple matching groups might run. 52 53### npf.conf dynamic ruleset 54 55Dynamic rulesets are mentioned in npfctl, and blocklistd examples, but 56they are not explained in npf.conf. In addition to the basics, while 57it is not expected that these rules be treated as if they have the 58final flag, the code seems to do that. 59 60# NetBSD integration 61 62## save/restore 63 64/etc/rc.d/npf lacks the ability to save and load state (stateful rules 65and NAT). 66 67# npfctl 68 69## npfctl start does not load 70 71npfctl start does not load the configuration if not loaded. 72It is not clear you need to reload first. Or if it loads it should 73print the error messages. Or it should be called enable/disable since 74this is what it does. It does not "start" because like an engine with 75no fuel, an npf with no configuration does not do much. 76 77Alternatively: warn if there are no rules, or decide that npfctl 78behaves as documented. 79 80## better error reporting 81 82although the framework checks the file for consistency, returning 83EINVAL for system failures is probably not good enough. For example if 84a module failed to autoload, it is probably an error and it should be 85reported differently? 86 87## handle array variables in more places 88 89(Decide if this is just about npfctl or also about the kernel, and if 90the latter move it.) 91 92## support variables and inline sets which contain both IPv4 and IPv6 addresses 93 94for example: $ext_if = { inet4(wm0), inet6(wm0) } 95 96(Decide if this is just about npfctl or also about the kernel, and if 97the latter move it.) 98 99## support inline blocks with different types of data in the rule. 100 101This will require a clean-up of the type system in 102npfctl parser, since it is currently a bit of a mess. Examples: 103 104 pass in from all to { inet4(wm0), $some_var, 10.0.0.1, } 105 pass in final proto tcp to 172.28.1.2 port { 161, 162 } 106 pass in final proto { tcp, udp } to 172.28.1.2 port 53 107 108[MOSTLY DONE?] 109 110(Decide if this is just about npfctl or also about the kernel, and if 111the latter move it.) 112 113## npf show improvements 114 115Consistent `npfctl show' output with rule syntax. Difficult/messy 116because rules are compiled into the byte-code. 117 118Add examples of what is wrong. 119 120## -D option to set variables 121 122Allow `npfctl -D varname=value` to set a variable, as if were defined 123in the config file. See pfctl(8). 124 125# Architectural changes 126 127## Layer 2 filtering 128 1291. All rules in NPF are added to a ruleset. At this moment, it is assumed 130 that there is only one ruleset and all rules are processed at layer 3. 131 One approach is to support another ruleset for layer 2 (or rather, have 132 capability to specify the "starting layer"). 133 1342. One way to separate L2 and L3 rules could be by marking groups. In NPF, 135 a group is just a rule (i.e. rules can be nested). 136 1373. npfctl: update the parser such that the group would have an option for 138 specifying a layer. See "group_opts" token in npf_parse.y file. Also, 139 we may want to add support for "hwaddr <mac>" syntax or something. 140 1414. npfctl_build_rule() code will need to distinguish groups/rules which 142 were marked as layer 2, i.e. byte-code generation (npfctl_build_code() 143 and the logic in it) needs to know that we are starting from Ethernet 144 header and not IP header. Note: it needs to be passed to all nested 145 rules, so basically take the option from the "current group". 146 1475. For a start (i.e. less work to do), you can just add byte-code to parse 148 Ethernet header and compare the MAC addresses. Just return "not supported" 149 error for any other filter pattern. 150 1516. libnpf: create a new ruleset for L2 and add all groups (and its nested 152 rules) there. To keep it simpler, we can add npf_rule_setlayer() function 153 and just handle this separation in libnpf rather than npfctl. 154 1557. libnpf-kernel: currently, proplib dictionary has only one "ruleset" dict. 156 This needs to be split into "ruleset-l3" and "ruleset-l2". Retrieve and 157 construct a new ruleset in npfctl_reload(); it is simple, but disgusting 158 proplib code. It is just re-using the existing code to handle another 159 ruleset. 160 1618. Kernel: add a new handler in npf_handler.c, e.g. npf_packet_l2handler() 162 or something. Register it in npf_pfil_register() using Ethernet pfil 163 hook. In the handler, call npf_ruleset_inspect() passing L2 ruleset. 164 165## Consider single large BPF program 166 167Implement NPF rules as a single large BPF program, instead of 168providing BPF byte-code per each rule. In combination with BPF JIT 169compilation, such approach would significantly improve the performance 170of very large rulesets. Problems: BPF byte-code limitations; we can 171either extend the byte-code or workaround them. 172 173## Multiple rule matching 174 175Multiple rule matching to call the rule-procedures or a suitable 176design alternative to that. 177 178(Explain what this means more clearly.) 179 180## ipchains-like feature 181 182Implement ipchains-like feature to support nested rules and sharing of 183a rule group. NPF already supports nested rules. Unresolved questions 184are: 1) what kind of complexity of rule chains do we want to support, 185e.g. a directed graph with loop resolution or more strict hierarchy 186which does not allow jumping up the chain? 2) syntax in npf.conf file. 187 188## Support for packets arriving at or departing the socket layer 189 190Similar to how one can do this in nftables, add a way to write a rule 191that will be applied to all packets being delivered to sockets, or 192really processed by the system as a host rather than simply forwarded. 193The point is to be able to express rules like "block connections to 194this machine's ssh daemon, but don't block ssh connections that are 195merely being routed", without having to match on addresses. 196 197## redundancy and load balancing 198 199Redundancy and load balancing: initially, add state replication and 200replace in-kernel CARP/VRRP with a userlevel daemon. 201 202Check "Note: we probably want to eliminate proplib in NPF before doing 203this." and drop if proplib has in fact been eliminated. 204 205## QoS 206 207QoS: rate limiting, traffic shaping, prioritising. Question: how much 208of this should be a part of the packet filter and how much of the 209network stack (merely involving some integration with the packet 210filters)? 211 212## address/port and port in tables 213 214Tables currently contain addresses. Add support for address/port 215tuples, and ports. 216 217## Separate mss clamping from normal rules 218 219Currently, mss clamping is a rule procedure and has to be specified on 220a matching rule. But, if there are both firewall rules and a desire 221to clamp, then one has to add clamping to all rules. This item is 222about having a way to express rules normally, and also say that 223clamping shouldhappen. 224 225 http://mail-index.netbsd.org/tech-net/2017/01/15/msg006224.html 226 227# Features (not needing architectural changes) 228 229## Add an extension for "route-to" 230 231The essence is to change the next hop of a packet if it matches a 232rule. 233 234 http://mail-index.netbsd.org/tech-net/2014/05/19/msg004526.html 235 236## support for ALTQ 237 238ALTQ is a QoS scheme, and it expects a way to classify packets so that 239different flows can be treated differently. Currently, ALTQ in NetBSD 240uses pf. (An earlier comment indicated a solution might involve mbuf 241tags.) 242 243## Support for NAT64 i.e. the protocol translation. 244 245## MiniUPnP 246 247Add support for MiniUPnP (see http://miniupnp.free.fr/ web page). 248 249## add support for "with short" 250 251(Clarify: is this about dropping packets that are shorter than they 252should be? Why would the user choose?) 253 254## Add specific kinds of ICMP unreachable 255 256Currently, rules are documented to allow returning `ICMP UNREACHABLE` 257given the keyword `return-icmp`. Probably this is ICMP Admin 258Prohibited, but this is not clear. 259 260This item is about different or additional keywords to allow the user 261to specify network, host, or port unreachable instead. 262 263# Security 264 265## Extra measures to protect npf from SYN flood attacks. 266 267E.g. accelerate connection expiration on low memory or after certain 268threshold. The timeout can also be self-balancing. This item is about 269protecting npf state in situations where excessive SYNs arrive in 270situations where a legitimate SYN should trigger a state entry. 271 272## Consider blind reset attacks (see RFC 5961). 273 274This is about the situation when npf is doing stateful processing on a 275TCP connection and only allowing packets matching the connection. 276Extend the definition of a packet matching the connection to meet the 277new rules in RFC5961, and perhaps generate the specified response 278packets. 279 280## Add counters 281 282Add a hit counter to rules, or some other way so that the user can say 283"show me the list of rules and for each rules, how many times it was 284invoked". This is similar to ipfilter's `ipfstat -inh`. 285 286# General 287 288## IPv4 options 289 290Implement "block return-icmp in log final all with ipopts". 291(Explain if this is more than "enable writing rules to match packets 292with ip options".) 293 294Consider defaulting to blocking options, with "allow-ip4opts" to 295enable them. 296 297## IPv6 options 298 299(Jointly with IPv4 options.) 300 301Perhaps a limited set (IPPROTO_ROUTING, IPPROTO_HOPOPTS and 302IPPROTO_DSTOPTS) by default, and "allow-ip6opts" to enable others. 303 304## add an ioctl, similar to PF's DIOCNATLOOK and IPF's SIOCGNATL 305 306document it so that it can be added in third-party software, like: 307 https://github.com/squid-cache/squid/blob/5b74111aff8948e869959113241adada0cd488c2/src/ip/Intercept.cc#L263 308 309### patch squid to support transparent-proxy with NPF. 310 311(Likely, simply using the ioctl from the previous item.) 312 313## support IPv6 jumbograms 314 315(Explain what is or is not supported now, and what needs to happen 316differently.) 317 318## IPv6 reassembly 319 320Investigate and fix the IPv6 reassembly (there is a memory leak). 321 322## nbuf_ensure_writable 323 324Use nbuf_ensure_writable() where appropriate. 325 326# Low priority items 327 328These items are left in the list, but there's no reason to think 329anyone will address them any time soon, or that they are high enough 330priority that anyone should. They can of course be moved (up likely 331clarified if someeone, especially someone intending to work on them, 332doesn't see it that way. (Perhaps we should drop them, but for now 333they are parked.) 334 335## NAT Application Level Gateways for FTP 336 337Generally, FTP is done in passive mode, so that the data connection is 338created by the client, and no particular support is needed in 339firewalls. This item is about creating an alg that allows the 340(regular, not passive mode) inbound connection from the server, based 341on watching the control connection. 342 343(It is likely that there are almost no remaining uses of active FTP, 344and thus it is unlikely this would be implemented.) 345 346## Consider experimentation to use bloom filters against certain DoS attacks. 347 348(This needs much more clarity.) 349 350## support large IPv6 options 351 352as explained here: 353 http://mail-index.netbsd.org/tech-net/2018/04/08/msg006786.html 354But it's not a big problem - perhaps we don't care at all. 355 356## TCP FSM enhancement 357 358Minor TCP FSM investigation: should it be not allowed to immediately 359re-open the connection after RST or FIN? 360 361(Explain what this means, how it relates to standards, and what the 362concerns are.) 363