1 # $NetBSD: TODO.npf,v 1.15 2025/04/17 19:54:24 gdt Exp $ 2 3 # Meta 4 5 This file intends to be the location for all work needing to be done 6 for npf within NetBSD, except for bugs that are straightforward enough 7 to live in gnats. The presence of an item does not imply that there 8 is 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 12 has 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 20 Periodically, check this repo to see if there are changes/improvements 21 that are not in NetBDS and which are appopriate, and merge them. 22 23 ## to https://github.com/rmind/npf/ 24 25 Periodically, compare code between NetBSD and this repo, and file PRs 26 for changes in NetBSD as appropriate, when there are not already PRs. 27 28 ## Merge https://github.com/rmind/npf doc subdir 29 30 rmind's repo has a doc directory. Some content is in man pages and 31 thus available within NetBSD. Understand if there are things that 32 aren'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 39 Add instructions for converting configuration for other packet filters 40 to npf configuration. 41 42 ## More Examples 43 44 ## Man page nits 45 46 ### npf.conf: rule group processing 47 48 Explain if groups are processed in the same order as npf.conf. 49 Explain what happens if a packet matches the group header, but does 50 not match a rule in the group. Currently it is unclear exactly when 51 the default group is run, and if multiple matching groups might run. 52 53 ### npf.conf dynamic ruleset 54 55 Dynamic rulesets are mentioned in npfctl, and blocklistd examples, but 56 they are not explained in npf.conf. In addition to the basics, while 57 it is not expected that these rules be treated as if they have the 58 final 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 65 and NAT). 66 67 # npfctl 68 69 ## npfctl start does not load 70 71 npfctl start does not load the configuration if not loaded. 72 It is not clear you need to reload first. Or if it loads it should 73 print the error messages. Or it should be called enable/disable since 74 this is what it does. It does not "start" because like an engine with 75 no fuel, an npf with no configuration does not do much. 76 77 Alternatively: warn if there are no rules, or decide that npfctl 78 behaves as documented. 79 80 ## better error reporting 81 82 although the framework checks the file for consistency, returning 83 EINVAL for system failures is probably not good enough. For example if 84 a module failed to autoload, it is probably an error and it should be 85 reported 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 90 the latter move it.) 91 92 ## support variables and inline sets which contain both IPv4 and IPv6 addresses 93 94 for example: $ext_if = { inet4(wm0), inet6(wm0) } 95 96 (Decide if this is just about npfctl or also about the kernel, and if 97 the latter move it.) 98 99 ## support inline blocks with different types of data in the rule. 100 101 This will require a clean-up of the type system in 102 npfctl 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 111 the latter move it.) 112 113 ## npf show improvements 114 115 Consistent `npfctl show' output with rule syntax. Difficult/messy 116 because rules are compiled into the byte-code. 117 118 Add examples of what is wrong. 119 120 ## -D option to set variables 121 122 Allow `npfctl -D varname=value` to set a variable, as if were defined 123 in the config file. See pfctl(8). 124 125 # Architectural changes 126 127 ## Layer 2 filtering 128 129 1. 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 134 2. 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 137 3. 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 141 4. 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 147 5. 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 151 6. 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 155 7. 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 161 8. 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 167 Implement NPF rules as a single large BPF program, instead of 168 providing BPF byte-code per each rule. In combination with BPF JIT 169 compilation, such approach would significantly improve the performance 170 of very large rulesets. Problems: BPF byte-code limitations; we can 171 either extend the byte-code or workaround them. 172 173 ## Multiple rule matching 174 175 Multiple rule matching to call the rule-procedures or a suitable 176 design alternative to that. 177 178 (Explain what this means more clearly.) 179 180 ## ipchains-like feature 181 182 Implement ipchains-like feature to support nested rules and sharing of 183 a rule group. NPF already supports nested rules. Unresolved questions 184 are: 1) what kind of complexity of rule chains do we want to support, 185 e.g. a directed graph with loop resolution or more strict hierarchy 186 which 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 190 Similar to how one can do this in nftables, add a way to write a rule 191 that will be applied to all packets being delivered to sockets, or 192 really processed by the system as a host rather than simply forwarded. 193 The point is to be able to express rules like "block connections to 194 this machine's ssh daemon, but don't block ssh connections that are 195 merely being routed", without having to match on addresses. 196 197 ## redundancy and load balancing 198 199 Redundancy and load balancing: initially, add state replication and 200 replace in-kernel CARP/VRRP with a userlevel daemon. 201 202 Check "Note: we probably want to eliminate proplib in NPF before doing 203 this." and drop if proplib has in fact been eliminated. 204 205 ## QoS 206 207 QoS: rate limiting, traffic shaping, prioritising. Question: how much 208 of this should be a part of the packet filter and how much of the 209 network stack (merely involving some integration with the packet 210 filters)? 211 212 ## address/port and port in tables 213 214 Tables currently contain addresses. Add support for address/port 215 tuples, and ports. 216 217 ## Separate mss clamping from normal rules 218 219 Currently, mss clamping is a rule procedure and has to be specified on 220 a matching rule. But, if there are both firewall rules and a desire 221 to clamp, then one has to add clamping to all rules. This item is 222 about having a way to express rules normally, and also say that 223 clamping 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 231 The essence is to change the next hop of a packet if it matches a 232 rule. 233 234 http://mail-index.netbsd.org/tech-net/2014/05/19/msg004526.html 235 236 ## support for ALTQ 237 238 ALTQ is a QoS scheme, and it expects a way to classify packets so that 239 different flows can be treated differently. Currently, ALTQ in NetBSD 240 uses pf. (An earlier comment indicated a solution might involve mbuf 241 tags.) 242 243 ## Support for NAT64 i.e. the protocol translation. 244 245 ## MiniUPnP 246 247 Add 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 252 should be? Why would the user choose?) 253 254 ## Add specific kinds of ICMP unreachable 255 256 Currently, rules are documented to allow returning `ICMP UNREACHABLE` 257 given the keyword `return-icmp`. Probably this is ICMP Admin 258 Prohibited, but this is not clear. 259 260 This item is about different or additional keywords to allow the user 261 to specify network, host, or port unreachable instead. 262 263 # Security 264 265 ## Extra measures to protect npf from SYN flood attacks. 266 267 E.g. accelerate connection expiration on low memory or after certain 268 threshold. The timeout can also be self-balancing. This item is about 269 protecting npf state in situations where excessive SYNs arrive in 270 situations where a legitimate SYN should trigger a state entry. 271 272 ## Consider blind reset attacks (see RFC 5961). 273 274 This is about the situation when npf is doing stateful processing on a 275 TCP connection and only allowing packets matching the connection. 276 Extend the definition of a packet matching the connection to meet the 277 new rules in RFC5961, and perhaps generate the specified response 278 packets. 279 280 ## Add counters 281 282 Add 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 284 invoked". This is similar to ipfilter's `ipfstat -inh`. 285 286 # General 287 288 ## IPv4 options 289 290 Implement "block return-icmp in log final all with ipopts". 291 (Explain if this is more than "enable writing rules to match packets 292 with ip options".) 293 294 Consider defaulting to blocking options, with "allow-ip4opts" to 295 enable them. 296 297 ## IPv6 options 298 299 (Jointly with IPv4 options.) 300 301 Perhaps a limited set (IPPROTO_ROUTING, IPPROTO_HOPOPTS and 302 IPPROTO_DSTOPTS) by default, and "allow-ip6opts" to enable others. 303 304 ## add an ioctl, similar to PF's DIOCNATLOOK and IPF's SIOCGNATL 305 306 document 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 316 differently.) 317 318 ## IPv6 reassembly 319 320 Investigate and fix the IPv6 reassembly (there is a memory leak). 321 322 ## nbuf_ensure_writable 323 324 Use nbuf_ensure_writable() where appropriate. 325 326 # Low priority items 327 328 These items are left in the list, but there's no reason to think 329 anyone will address them any time soon, or that they are high enough 330 priority that anyone should. They can of course be moved (up likely 331 clarified if someeone, especially someone intending to work on them, 332 doesn't see it that way. (Perhaps we should drop them, but for now 333 they are parked.) 334 335 ## NAT Application Level Gateways for FTP 336 337 Generally, FTP is done in passive mode, so that the data connection is 338 created by the client, and no particular support is needed in 339 firewalls. This item is about creating an alg that allows the 340 (regular, not passive mode) inbound connection from the server, based 341 on watching the control connection. 342 343 (It is likely that there are almost no remaining uses of active FTP, 344 and 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 352 as explained here: 353 http://mail-index.netbsd.org/tech-net/2018/04/08/msg006786.html 354 But it's not a big problem - perhaps we don't care at all. 355 356 ## TCP FSM enhancement 357 358 Minor TCP FSM investigation: should it be not allowed to immediately 359 re-open the connection after RST or FIN? 360 361 (Explain what this means, how it relates to standards, and what the 362 concerns are.) 363
Indexes created Sat Sep 20 22:09:52 GMT 2025