Sécurité tcp additionnel (tcpcrypt) et iptables

j'avais déjà pris lecture du man et en avais retenue que le suivi de connexion n'était nécessaire que pour un nat avec le FORWARD d'activer. Il ma parût logique étant donné que le suivis de connection doit ce faire sur un autre protocole que lo, donc il faut que le suivis des paquets de la machine a vers internet soit bien crypté et renvoyé par un second protocole de cryptage a la machine émanente de la requête (la machine derrière le nat). #je précise que je n'utilise pas encore le nat avec tcpcryptd, pas pour le moment.

Sinon j'ai abandonné, tcpcryptd est mal porté sur linux et je ne pense pas qu'il soit a la base porté sur debian, c'est le même bug que sur celui de github, un protocole nouveau émanent d'une application utilisant des variables noyau (module*, je sais j'ai mon language à moi même et je pense qu'il est très comprehensible) mal implémenté sur le kernel lui même, il faudra donc vérifier l'implémentation et la bonne coordination entre netfilter et l'application, sans compté entre deux le noyau.
Il y a le problème du mkdir -p /var/run/tcpcryptd à faire sinon il ne ce lance pas, un problème de chmod applicatif relatif avec ces droits, je pense.

Donc la question est est-ce parcequ'il résulte d'un manquement à la "sécurité local debian" que tcpcryptd est si délaissé (je ne site pas le problème de dépendance vitale non installé alors qu'elle ce trouve dans les dépots et qui font que sans elles, impossible de faire fonctionner l'application à sa principale et seul fonction ....
Ou bien est-ce parceque debian considère que la vie privé qui est aussi contraignante et non indispensable ne vaut pas mieux en faite que de la simple conduite protectrice et ce peu importe le produit utilisé, comparable à un triple brossage de dent journallier pour les fervants des non sos dentiste ?

Sécurité tcp additionnel (tcpcrypt) et iptables