Protokoll-Lücke wird geschlossen

Das ist der dritte Artikel in unserer Reihe Die Protokoll-Lücke. In den ersten beiden Artikeln haben wir die Schwierigkeiten, die bei der Kommunikation von Gastgeräten mit Captive Portals auftreten, und die vorgeschlagene Lösung für dieses Problem durch die Definition einer neuen Schnittstelle in dem RFC capport-architecture aufgezeigt. Genau genommen definiert die IETF mit diesem RFC kein neues Protokoll, sondern eine neue Schnittstelle über bekannte Protokolle wie DHCP, IPv6 RA und HTTPS.

Unterschiede zur zuvor gezeigten Version

Im vorherigen Artikel dieser Reihe haben wir bereits den Ablauf und die API beschrieben, seitdem (Januar 2019) haben sich aber doch in einigen Punkten Veränderungen ergeben:

• ICMP wurde durch den allgemeineren Begriff “Captive Portal Signal” ersetzt, jedoch in dieser Version nicht weiter spezifiziert. Diese genauere Festlegung wurde auf einen späteren Zeitpunkt verschoben, da wohl weitere Diskussionen nötig sein werden. Es ist zunächst nicht gelungen, einen Konsens über die Sinnhaftigkeit herzustellen. Wir denken, dass dies vorerst in Ordnung ist, da die Provisionierungs- und API-Teile abgedeckt und einfach zu implementieren sind.
• Die DHCPv4-Option 160 musste ersetzt werden, da ein Test die illegale Verwendung durch einen Anbieter ergab. Apple stellte zu diesem Zweck deren registrierte, aber bisher nicht verwendete Option 114 zur Verfügung.
• Außerdem hat die API einige umbenannte und neue JSON-Felder (siehe unten).

So funktioniert’s

Hier eine schematische Darstellung des aktuellen Ablaufs, wenn sich ein Gerät mit dem Captive Portal verbindet:

1. Das Gerät des Endbenutzers erhält über DHCP grundlegende Netzwerkeinstellungen wie IP, Subnetzmaske, Gateway, DNS-Server usw. Es ist auch eine Variante im Gespräch, bei der PvD (Provisioning Domains) verwendet wird. Das Gerät bekommt die URL des CAPPORT-API-Servers über eine neue DHCP-Option (DHCP6 und RA für IPv6), die in RFC-8910 definiert ist.

2. Das Gerät fragt den CAPPORT-API-Server nach den aktuellen Einschränkungen und bekommt eine URL für eine für Menschen geeignete Webseite. Diese Seite kann aus einem Anmeldeformular, einer Zahlungsaufforderung oder allerlei anderen Informationen bestehen.

3. Das Gerät öffnet einen (Captive) Browser und zeigt dem Benutzer die Anmeldeseite an.

4. Wenn der Endbenutzer alle Anforderungen des Captive Portals erfüllt, wird das Gerät online genommen und kann auf das Internet zugreifen.

5. Das Gerät kann jetzt Daten senden. Wenn das Gerät nicht auf das Internet zugreifen darf, kann das Captive Portal optional ein „Signal“ senden. Spezifische Angaben, was genau unter diesem Signal zu verstehen ist, wird im aktuellen Dokument nicht genauer spezifiziert. Daher ist es derzeit auch auf keiner Seite implementiert.

Die Capport-API

Die in RFC-8908 definierte Capport-API ermöglicht dem Client die Interaktion mit einem Captive Portal über eine generische HTTP-API mit JSON als Datenformat. Es ist vorgeschrieben, dass HTTPS verwendet werden muss (HTTP über TLS – mindestens Version 1.2). Während das Client-Gerät bereits vorher erkannt hat, dass es sich hinter einem Captive Portal befindet, möchte es jetzt den aktuellen Status und einige Details zur Captivity (Einschränkungen) abrufen. Eine wichtige Sache, welche die API liefern muss, ist eine URL zu einer Webseite, die dem Benutzer eine Anmeldeseite oder andere Informationen anzeigt.

Eine Beispielanfrage und -antwort könnte folgendermaßen aussehen:

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

Der Server antwortet dann mit dem JSON-Inhalt für diesen 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,
}

Dies ist natürlich nur dann sinnvoll, wenn Google und Apple sie registrieren und (hoffentlich) auf die gleiche Weise verwenden.

3, 2, 1, los!

Nach der langen Wartezeit waren wir nun doch überrascht, dass Apple und Google noch für das Jahr 2020 ankündigten, die neue Capport-Architektur in ihren neuesten Versionen zu unterstützen.

• Apple hat bereits Unterstützung für iOS und macOS 14 hinzugefügt
• Google liefert die Unterstützung mit Android 11/R, das kürzlich (September 2020) veröffentlicht wurde.
• Mit Update auf die neueste Version ist auch Ihre IACBOX bereit für die neue API. Mit aktueller Software Maintenance bleiben Sie sicher und auf dem neuesten Stand.

Ausblick

So, das wäre nun erledigt? Nicht ganz – es gilt noch eine Vielzahl offener Aufgaben zu lösen, und das kann durchaus noch Jahre dauern. Die alten HTTP-basierten Verbindungsprüfungen bleiben bestehen, da nicht alle Captive Portals diese API unterstützen. Wir werden mit Sicherheit in den kommenden Jahren noch zweigleisig fahren.
Außerdem enthalten die ersten Implementierungen der API bestimmte Informationen noch nicht, wie etwa die venue URL oder die verbleibenden Sekunden- und Bytes, was ein echter Vorteil wäre. Der Capport RFC befindet sich derzeit in der Endphase und die Veröffentlichung sollte abgeschlossen sein, wenn er eine offizielle Nummer erhält.
Wir werden die IACBOX aktuell halten und neu hinzugefügte API-Felder jeweils unterstützen, sobald sie veröffentlicht werden. Bleiben Sie dran, wir halten Sie auf dem Laufenden!