Bonjour,
J’ai étudie le fonctionnement de IPSec avec le paquet ipsec-tools (0.6.6-3.1) sur une Debian 4.0 avec un noyau 2.6.18. Avant de passer à l’étude du démon IKE, j’aimerais éclaircir quelques points à propos de IPComp pour bien comprendre.
J’ai testé +/- toutes les configurations possibles avec AH, ESP et IPComp en mode transport et tunnel. Chaque fois que j’ai impliqué IPComp dans une configuration, celle-ci n’a pas fonctionné correctement. Même l’usage de IPComp tout seul en mode transport ou tunnel n’a jamais fonctionné. J’avais posté quelques détails de configurations et des remarques sur le forum francophone de Debian [1] : http://forum.debian-fr.org/viewtopic.php?t=8907&sid=6eae(...) . Mon sujet n’a pas fait fureur :)
Après de nombreuses recherches sur Internet, je trouve quelques pistes en anglais qui annoncent des problèmes. Comme ici, sur la liste de ipsec-tools chez sourceforge : http://sourceforge.net/mailarchive/message.php?msg_id=BAY103(...) . Le post n’est toutefois pas très récent 2005...
D’après ce que je comprends, Setkey utilise un header IPIP de 20bytes. J’ai pu le vérifier avec Wireshark. Je m’étonne par contre de ne pas voir le fameux id ICP propre au protocole IPComp. Je m’étonne d’une remarque qui insinuait que l’usage de ipip n’est pas recommandé par la RFC de IPComp et l’implémentation de IPComp varie entre les différents systèmes.
J’ai lu plusieurs remarques qui mettaient en évidence le fait qu’il faut faire attention à l’ordre de ce qu’on demande dans la SPD. Le fait de demander ESP et puis IPComp n’a pas le même effet que demander IPComp et puis ESP. ESP chiffrant les données, il faut les compresser avant.
Le dernier point qui m’intrigue, c’est que lorsque je teste en mode tunnel IPComp tout seul en ayant adéquatement configuré la SPD et la SAD, les paquets passent bien dans un sens mais pas dans l’autre. Cf. [1]. En jouant avec tcpdump, je vois pourtant les paquets arriver correctement sur la machine. Ce qui est étrange, c’est que iptables ne drop rien, mais la réponse d’un ping ne se fait pas. Comme si le noyau bloquait tout ça. J’ai pensé qu’il s’agissait peut-être d’une option de sysctl.conf à ajuster. J’ai testé en désactivant petit à petit les sécurités genre rp_filter,... mais ça n’a pas marché non plus.
Par contre, j’ai pu tester avec succès l’usage de AH seul, de ESP seul, ou de AH + ESP tant en mode tunnel qu’en mode transport. Dès lors, j’ose penser que je n’ai pas fait une erreur de débutant dans une configuration.
Voilà, je me demandais si quelqu’un ici a déjà rencontré des problèmes avec l’usage de IPComp en utilisant IPSec-tools. Vous pensez certainement que j’ai tendance à faire une tartine pour pas grand-chose. IPComp n’est pas le point fondamentale de IPSec, mais par curiosité, j’aime bien de savoir le pourquoi de comment.
Je serais content d’avoir vos avis sur le sujet,
Merci d’avance,
Nico
# IPSec et IPComp avec ipsec-tools
Posté par arnaudD . Évalué à 1.
IPCOMP ne peut être un requierement, il peut juste être mis en use. La majorité des systèmes permettent d'utiliser require avec ipcomp mais le code d'ipsec derrière n'honore pas le flag requiere.
La raison de ceci est le paragraphe 2.2 de la RFC 3173. En gros, si le header + taille des données compressés > taille des données alors on ne compresse pas les données. Ca evite la possible fragmentation et des cycles cpus inutiles côté reception.
Il est donc normal que tes trames soient envoyés sans header ipcomp et sans compression. Toutefois, ce n'est pas clair pourquoi la réponse ne revient pas.
Si tu veux vérifier que ipcomp fonctionne correctement avec ping, il faut donc
1 / utiliser une taille de paquet suffisante (genre 1200)
2/ si possible donner un motif facilement compressable à ping (option -p sous NetBSD, sous linux je ne sais pas si elle existe.).
Pour tes autres questions, ipsec-tools et ipcomp c'est OK (en tout cas sous NetBSD no problem). De toute facon ipsec-tools ne fait que de parler PF_KEY avec le kernel dans ce cas la, donc rien de bien difficile. Je doute que le bug vienne de la. La SAD et la SPD semble correcte.
Pour les 2 SA pour le mode tunnel, c'est normal. Il y'a bien deux transformations distinctes :
- encapsulation ( ip over ip)
- ipcomp (compression ip)
J'espere que ca va t'avancer un peu.
--
Arnaud
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.