Nftables: a new packet filtering engine

Well, that's not really a core iptables responsibility, IMHO.

> - rule-matching should be done only for the first packet of a
> connection. Actually it is done per packet when using the filter table.
> While you can do this with PREROUTING, it should be done as a standard.

Um, this is pretty trivial to set up. You probably want something like:
iptables -N NEWPKTS
iptables -A INPUT -m state --state NEW,INVALID -j NEWPKTS

Then put your rules in the NEWPKTS chain. (For simpler setups, you
can just have your first rule accept all ESTABLISHED and RELATED packets).

> - RELATED state whould be handled natively, ne need to add RELATED rules for this.

But if someone wants to log related packets, such an implicit rule would be a PITA.

> - matching TIME_WAIT state as a default is dangerous : a short-lived TCP
> connection will be maintained in the connections' table for too long.

There's an argument that the assured bit should be reset for TIME_WAIT conns (which makes the eligible for reaping if we need to make space), but you have to keep tracking conns through TIME_WAIT; the state is there in TCP for a reason!

> - using macro for rule maintenance, as done by pf.

This, I think, is your real issue: iptables is too low-level. I agree, but it was a deliberate decision to leave building the higher levels to someone else. As I've alluded elsewhere, it didn't really work.

> pf and most commercial firewalls perform that way. Iptables' design is
> way broken.

See above.

Hope that clarifies,
Rusty.