Alors, pour m'être posé la même question, et après avoir relu les réponses de Mac Hardy sur LWN, je crois avoir trouvé quelques éléments de réponse. Je crois qu'il faut y voir un compromis entre "tout casser" (pas de rétro/forward compatiblity, pas de plan de transition progressive) et un changement "incrémental" d'iptables qui n'aurait pas permis de résoudre les problèmes les plus pressants (langage dédié, vérifications de syntaxe et atomicité par exemple).
Mac Hardy indique qu'il compte à terme rendre le passage d'iptables à nftables totalement automatisable (scriptable). Cela n'est pas possible en changeant radicalement les paradigmes sous-jacents : sur plusieurs points, la logique chaines/tables d'iptables ne peut pas être transcrite telle quelle automatiquement en rêgles pf : ce n'est plus une retranscription mais une ré-écriture, car il faut repenser la structure du jeux de règles pour arriver aux mêmes fins. Par exemple pf a pris le partis de ne pas traiter le layer7 et de déléguer ça à l'espace utilisateur (proxys ftp ou sip...). Je crois que c'est en ce sens que Mac Hardy disait, dans les commentaires de LWN, qu'il aurait perdu en flexibilité/fonctionnalités en passant vers pf : certaines façons d'exprimer les choses "à la iptables" ne seraient plus possibles, un problème qu'il cherche de toutes évidences à éviter avec nftables, pour de bonnes raisons. Il exprime ailleurs ce soucis explicitement sur LWN, en disant au sujet de pf :There's no way to transform it into something that can be backwards compatible with iptables/ip6tables/arptables/ebtables without basically rewriting it.
Même remarque en ce qui concerne la vaste gamme d'outils générant des rulesets iptables (nufw, shorewall, ipkungfu, ...) : si la structure logique reste suffisamment identiques (au point qu'on puisse scripter la transcription de rulesets iptables en nftables), ils seront peut-être adaptables à moindre frais, mais si elle change radicalement les adapter pourrait imposer une refonte complète (ou autrement dit : iptables continuerai d'être utilisé pendant longtemps). Et vu de l'autre coté des outils, face noyau, il y ne faut pas sous-estimer la possibilité de réutiliser ce qui est déjà en place dans le noyau Linux.
Je crois que c'est sur ce même compromis (paradigmes et logique sous-jacente repris mais étendus et complétés) que la transition de ipchains vers iptables a pu se faire en douceur, au point qu'iptables fut finalement adopté assez rapidement, et que les mainteneurs ont en conséquence pu se permettre de passer ipchains en mode maintenance molle. Notez que chez OpenBSD, pf a d'abord été une quasi ré-écriture d'ipf qu'il remplaçait, et dont il reprenait la syntaxe : dans ces conditions la transition est relativement "facile". DragonFlyBSD est sortis après pf (pas d'historique à respecter). FreeBSD et NetBSD ont conservé le support ipf (et même le vieillissant ipfw pour Free) malgré l'intégration de pf. Et enfin le port de pf sous Windows (oui oui ! ça existe !) ne permet certainement pas à Microsoft de se passer de maintenir leur solution de firewalling native (si ridicule soit-elle).
Mac Hardy n'a certainement pas envie d'avoir à faire évoluer iptables toute sa vie. La contrepartie, c'est qu'iptables puis nftables vont hériter de certains petits problèmes de design et d'ergonomie initiés à l'époque d'ipchains.
Evidement, dans le meilleurs des mondes, Linux aurait des mainteneurs à vie pour ses outils actuels et intégrerait aussi les meilleures choses de ses cousins, pf et bioctl d'OpenBSD, Dtrace et ZFS de Solaris,...
Pour l'anecdote, et toujours dans les commentaires de LWN, Rusty Russel, l'auteur d'ipchains et iptables dit avec son humour légendaire :
But I always intended iptables as the assembler language of firewalls. Someone was supposed to write the cool GUI tool which monitored traffic, let you shape and firewall it without touching this stuff. I'm still waiting :)
[^] # Re: Réinventer
Posté par herodiade . En réponse au journal NFtables, successeur d'Iptables. Évalué à 7.
Mac Hardy indique qu'il compte à terme rendre le passage d'iptables à nftables totalement automatisable (scriptable). Cela n'est pas possible en changeant radicalement les paradigmes sous-jacents : sur plusieurs points, la logique chaines/tables d'iptables ne peut pas être transcrite telle quelle automatiquement en rêgles pf : ce n'est plus une retranscription mais une ré-écriture, car il faut repenser la structure du jeux de règles pour arriver aux mêmes fins. Par exemple pf a pris le partis de ne pas traiter le layer7 et de déléguer ça à l'espace utilisateur (proxys ftp ou sip...). Je crois que c'est en ce sens que Mac Hardy disait, dans les commentaires de LWN, qu'il aurait perdu en flexibilité/fonctionnalités en passant vers pf : certaines façons d'exprimer les choses "à la iptables" ne seraient plus possibles, un problème qu'il cherche de toutes évidences à éviter avec nftables, pour de bonnes raisons. Il exprime ailleurs ce soucis explicitement sur LWN, en disant au sujet de pf :There's no way to transform it into something that can be backwards compatible with iptables/ip6tables/arptables/ebtables without basically rewriting it.
Même remarque en ce qui concerne la vaste gamme d'outils générant des rulesets iptables (nufw, shorewall, ipkungfu, ...) : si la structure logique reste suffisamment identiques (au point qu'on puisse scripter la transcription de rulesets iptables en nftables), ils seront peut-être adaptables à moindre frais, mais si elle change radicalement les adapter pourrait imposer une refonte complète (ou autrement dit : iptables continuerai d'être utilisé pendant longtemps). Et vu de l'autre coté des outils, face noyau, il y ne faut pas sous-estimer la possibilité de réutiliser ce qui est déjà en place dans le noyau Linux.
Je crois que c'est sur ce même compromis (paradigmes et logique sous-jacente repris mais étendus et complétés) que la transition de ipchains vers iptables a pu se faire en douceur, au point qu'iptables fut finalement adopté assez rapidement, et que les mainteneurs ont en conséquence pu se permettre de passer ipchains en mode maintenance molle. Notez que chez OpenBSD, pf a d'abord été une quasi ré-écriture d'ipf qu'il remplaçait, et dont il reprenait la syntaxe : dans ces conditions la transition est relativement "facile". DragonFlyBSD est sortis après pf (pas d'historique à respecter). FreeBSD et NetBSD ont conservé le support ipf (et même le vieillissant ipfw pour Free) malgré l'intégration de pf. Et enfin le port de pf sous Windows (oui oui ! ça existe !) ne permet certainement pas à Microsoft de se passer de maintenir leur solution de firewalling native (si ridicule soit-elle).
Mac Hardy n'a certainement pas envie d'avoir à faire évoluer iptables toute sa vie. La contrepartie, c'est qu'iptables puis nftables vont hériter de certains petits problèmes de design et d'ergonomie initiés à l'époque d'ipchains.
Evidement, dans le meilleurs des mondes, Linux aurait des mainteneurs à vie pour ses outils actuels et intégrerait aussi les meilleures choses de ses cousins, pf et bioctl d'OpenBSD, Dtrace et ZFS de Solaris,...
Pour l'anecdote, et toujours dans les commentaires de LWN, Rusty Russel, l'auteur d'ipchains et iptables dit avec son humour légendaire :
But I always intended iptables as the assembler language of firewalls. Someone was supposed to write the cool GUI tool which monitored traffic, let you shape and firewall it without touching this stuff. I'm still waiting :)