Combler les lacunes du protocole

Ceci est le troisième article de la série The protocol gap. Dans les deux premiers articles, nous avons montré les difficultés rencontrées par les dispositifs invités pour communiquer avec les portails captifs et la solution proposée pour résoudre ce problème en définissant une nouvelle interface dans la RFC capport-architecture. Pour être précis, l’IETF ne définit pas un nouveau protocole avec cette RFC, il définit une nouvelle interface sur des protocoles connus comme DHCP, IPv6 RA et HTTPS.

Différences par rapport à la version précédente

Dans l’article précédent de cette série, nous avons déjà montré le flux et l’API, mais certaines choses ont changé depuis (Jan 2019) :

ICMP a été remplacé par un terme plus générique « Signal de portail captif » qui n’est plus spécifié dans cette version. Ceci est suspendu à un moment ultérieur et nécessite plus de discussion car il n’y a pas eu de consensus pour savoir si c’est une bonne chose ou non. Nous pensons que c’est bien pour l’instant, car les parties provisionnement et API sont couvertes et simples à mettre en œuvre.
L’option 160 de DHCPv4 a été remplacée par 114 car un test a montré qu’elle était utilisée (illégalement) dans la nature. Apple a fait don de cette option qui n’a jamais été utilisée activement.
L’API a également été renommée et de nouveaux champs JSON ont été ajoutés (voir les nouveaux champs ci-dessous).

Comment cela fonctionne-t-il ?

Voici le flux de courant lorsqu’un appareil entre dans le réseau :

1. L’appareil de l’utilisateur final reçoit les paramètres initiaux du réseau tels que l’IP, le masque de sous-réseau, la passerelle, le serveur DNS, … via DHCP. Il existe également une variante utilisant PvD (Provisioning Domains). L’appareil apprend l’URL du serveur API CAPPORT via une nouvelle option DHCP (DHCP6 et RA pour IPv6) définie dans le RFC-8910 (une nouvelle version du RFC-7710-bis).

2. Le dispositif interroge le serveur CAPPORT API sur les restrictions actuelles et apprend l’URL d’une page web adaptée aux humains. Cette page peut contenir un formulaire de connexion, un paiement requis ou toute autre information.

3. Le dispositif ouvre un navigateur (captif) et présente la page de connexion à l’utilisateur.

4. Enfin, si les exigences du portail captif sont satisfaites par l’utilisateur final, l’appareil est mis en ligne et autorisé à accéder à l’internet.

5. L’appareil peut désormais envoyer du trafic. Mais si l’appareil n’est pas autorisé à accéder à l’internet, le portail captif peut éventuellement envoyer un « signal ». L’état actuel de cette interface de support ne spécifie pas ce qu’est ce signal. Il n’est donc pas implémenté d’un côté ou de l’autre pour le moment.

L’API capport

L’API capport définie dans la RFC-8908 permet au client d’interagir avec un portail captif via une API HTTP typique avec JSON comme format de données. Il est obligatoire d’utiliser HTTPS (HTTP over TLS – au moins la version 1.2). Alors que le dispositif client sait déjà qu’il se trouve derrière un portail captif, il veut maintenant obtenir l’état actuel et quelques détails sur la captivité. Un élément important que l’API doit fournir est l’URL d’une page web présentée à l’utilisateur avec une page de connexion ou toute autre information.

Un exemple de demande et de réponse pourrait ressembler à ceci :

GET / capport_api HTTP/1.1
Hôte : hotspot.internet-for-guests.com
Accept : application/captive+json

Le serveur répond alors avec le contenu JSON pour ce client :

HTTP/1.1 200 OK
Cache-Control : private
Date : Mon, 06 Jul 2020 10:07:35 GMT
Content-Type : application/captive+json

{
« captive » : false,
« user-portal-url » : « https://hotspot.internet-for-guests.com »,
« seconds-remaining » : 10000,
« bytes-remaining » : 100000000,
}

Bien entendu, cela n’a de sens que si Google et Apple les enregistrent et (espérons-le) les utilisent de la même manière.

3, 2, 1, c’est parti !

Après une longue attente, nous avons été surpris de voir les annonces d’Apple et de Google en 2020 concernant la prise en charge de la nouvelle architecture de support dans leurs dernières versions.

Apple a déjà ajouté la prise en charge dans iOS et macOS 14
Google le prend en charge avec Android 11/R publié récemment (septembre 2020).
Votre IACBOX est prêt pour la nouvelle API en mettant à jour la dernière version dès maintenant. Restez en sécurité et à jour avec notre maintenance logicielle.

Perspectives

Alors, nous avons terminé ? Pas encore – il y a de nombreuses choses en suspens qui prendront probablement des années avant d’être résolues. Les anciennes vérifications de connexion basées sur HTTP resteront présentes car tous les portails captifs ne prendront pas en charge cette API, de sorte que nous verrons une utilisation parallèle pendant des années.
De plus, les premières implémentations n’incluent pas les parties informatives de l’API telles que l’URL du lieu ou les entrées de secondes et d’octets restants, ce qui constituerait le véritable avantage.
Le RFC capport est actuellement en phase finale et devrait être publié prochainement et recevoir enfin un numéro officiel.
Nous mettrons à jour l’IACBOX pour prendre en charge les nouveaux champs de l’API dès qu’ils seront publiés – restez donc au courant.

Êtes-vous un entrepreneur à la recherche d'une solution à ces exigences? Ou êtes-vous un fournisseur de services et conseillez des entreprises sur des solutions de réseaux sans fil ou filaires ?