- L’infrastructure réseau se compose de switches, bridges, routeurs, load balancers, pare-feu, etc.
- Le système d’exploitation contrôle les communications réseau en classant les paquets, en les plaçant dans des files d’attente et en appliquant des règles de pare-feu, entre autres
- Alors, que se passe-t-il si l’on utilise un protocole de couche transport inexistant ?
- L’OS l’autorisera-t-il ? Les paquets seront-ils réellement transmis ? Le pare-feu les bloquera-t-il ?
- Une expérience a été menée directement pour le vérifier
Aperçu des protocoles Internet
- Internet fonctionne en faisant transiter les données à travers plusieurs couches de protocoles
- Lorsqu’une application envoie une requête, l’OS l’encapsule avec les en-têtes des différentes couches réseau avant de la transmettre
- Couche transport (Transport Layer) : c’est là que se trouvent des protocoles comme TCP (6) et UDP (17)
- Que se passerait-il si l’on modifiait le champ
Protocol de l’en-tête IP pour y mettre un numéro inutilisé ?
Expérience n°1 : test direct sur mon PC
Méthode expérimentale
- Définition de HDP (faux protocole) : conception d’un nouveau protocole de couche transport totalement différent des protocoles existants
- Implémentation du serveur et du client : développement de programmes pour envoyer et recevoir des paquets
- Test en loopback : observation de la manière dont l’OS traite lui-même les paquets
Exécution
$ sudo cargo run --bin server # 서버 실행
$ fortune | cowsay | sudo cargo run --bin client 127.0.0.1 # 클라이언트 실행
Résultats
- L’OS a traité normalement les paquets HDP, qui ont été reçus à nouveau via l’interface loopback
- Des tests supplémentaires ont été effectués en changeant le numéro de protocole IP
- 1 (ICMP), 2 (IGMP), 6 (TCP) → non détectés côté serveur
- 50, 51 (protocoles liés à IPSec) → transmission bloquée dès le client
- 256 (hors de la plage des numéros de protocole IP) → erreur dès l’appel à
socket()
Analyse des causes
- Dans certains cas, l’OS réserve certains numéros de protocole au niveau système et les bloque
- Sur Darwin (macOS basé sur BSD), définir protocol=0 lors de l’appel à
socket() entraîne un filtrage automatique de certains paquets
- Les protocoles liés à IPSec sont probablement bloqués pour des raisons de sécurité
- Comme le numéro de protocole IPv4 est codé sur 8 bits, seules les valeurs de 0 à 255 sont valides
Expérience n°2 : envoi de paquets sur Internet
Plan de l’expérience
- Configuration d’un VPS DigitalOcean : mise en place de l’environnement de test sur un serveur cloud à Francfort, en Allemagne
- Envoi de paquets HDP : émission de paquets depuis mon PC (Arabie saoudite) vers le serveur DigitalOcean
- Analyse de la réaction des équipements réseau : vérifier si les paquets arrivent et si un pare-feu les bloque
Résultat attendu
- Les paquets HDP pourraient être transmis normalement, ou bien être bloqués par certains FAI ou par le pare-feu de DigitalOcean
Résultats réels
- Seul le premier paquet a été transmis, les suivants ont été bloqués
- Vérification avec
tcpdump :
- Les paquets sont bien envoyés depuis mon PC
- Seul le premier paquet est détecté sur le serveur DigitalOcean
- Les paquets suivants sont bloqués quelque part (NAT, pare-feu, FAI, etc.)
Analyse des causes
- DigitalOcean ne prend pas en charge les protocoles IP non standard
- La politique de pare-feu du fournisseur cloud est probablement la cause principale
- On ne sait pas pourquoi seul le premier paquet arrive
Nouvelle expérimentation sur AWS
- L’expérience a été relancée sur AWS avec deux instances
- Dans le même datacenter, les paquets HDP sont envoyés et reçus normalement
- En revanche, via Internet, on retrouve le même problème que sur DigitalOcean : seul le premier paquet arrive
Problèmes majeurs
- NAT (Network Address Translation) : comme il fonctionne sur la base des ports TCP/UDP, il n’a aucun moyen de gérer un nouveau protocole comme HDP
- Pare-feu / filtrage réseau : la plupart des FAI et des fournisseurs cloud bloquent les protocoles IP non approuvés
- Problèmes d’optimisation des équipements réseau : certains équipements réseau peuvent supprimer systématiquement les paquets non standard
Conclusion : mieux vaut utiliser TCP et UDP
- Les implémentations de la pile réseau diffèrent selon les OS
- Le fonctionnement de
socket() varie entre Linux, macOS et Windows
- Les pare-feu et les équipements NAT bloquent les protocoles non standard
- Même si cela fonctionne sur un réseau privé, c’est quasiment impossible sur Internet
- Aucun gain de performance
- Il existe déjà des alternatives éprouvées, comme QUIC implémenté au-dessus d’UDP
- Utilisons TCP/UDP
- Avec des protocoles standard, le NAT basé sur les ports, les pare-feu et le routage sont pris en charge automatiquement
Ressources complémentaires
5 commentaires
Je pense que lire aussi https://www.saturnsoft.net/network/2019/03/21/quic-http3-1/ pourrait vous être utile.
Je me souviens qu’à l’époque, quand on jouait en multi à l’ancien StarCraft via Hamachi, il y avait IPX, et je me rappelle m’être beaucoup demandé ce que c’était.
À bien y réfléchir, le NAT bloquerait tout… Si l’IPv6 s’imposait complètement et que le NAT disparaissait (ce qui n’arrivera probablement jamais), il serait peut-être possible de communiquer avec un protocole qu’on a créé soi-même.
Oh, belle tentative...
C’était une bonne tentative de bousculer les fondations du réseau, mais tous les équipements réseau de ce monde sont spécialisés pour TCP/UDP...
Quand on ne sait pas que les équipements réseau sont produits à la chaîne... ça peut sembler possible... mais une fois qu’on le sait, on comprend que ce n’est pas faisable, sauf si l’on réussit au point d’imposer à tout le monde l’usage de son propre protocole...
Avis Hacker News