Zusammenfassung
- RFC 5265 erlaubt die interne Einstufung nur nach erfolgreicher Registrierung über genau diese Schnittstelle, einer Antwort mit Trusted Networks Configured und solange sich deren Verbindungsstatus nicht geändert hat.
- Der belastbare Nachweis ist ein befristeter Pass: Antwort, Quellregel, Interface, Policy-Version, Überwachungsfrist und Verkehrssperre gehören zusammen.
Das grüne Ergebnis war kleiner als seine Anzeige
Der interne Home Agent antwortete erfolgreich, TNC war vorhanden, Authentisierung und Replay-Prüfung bestanden. Die Anzeige machte daraus „Gerät im vertrauenswürdigen Netz“.
Tatsächlich hatte eine Anfrage über Interface X den erwarteten i-HA erreicht und dessen konfigurierte interne Quellregel erfüllt. Daraus folgt nichts für Y. Ändert X seinen Anschluss, darf das alte Ergebnis nicht weiterwirken.
Das Protokoll liefert also keinen Gerätecharakter, sondern eine Aussage mit Weg und Zeit.
TNC bestätigt eine ausgeführte Konfiguration
Die Unternehmensfirewall muss direkten externen Zugriff zum i-HA verhindern. Zusätzlich führt der Agent eine explizite Liste vertrauenswürdiger Subnetze, vertraut standardmäßig keinem, verwirft fremde Registrierungen und sendet TNC bei akzeptierten Quellen.
Die Extension besagt, dass diese Prüfung stattfand. Sie erkennt weder Gebäude noch Access Point und erteilt keine Anwendungsrechte. Mobile-IPv4-Schutz authentisiert die Nachricht, nicht die semantische Richtigkeit aller Regeln.
Sind Firewall und Subnetzliste gemeinsam falsch, kann eine normgerechte Antwort eine falsche Realität besiegeln. Deshalb gehört die Policy-Version in den Beleg.
Bei Bewegung schließt zuerst das Datentor
Bei einer Statusänderung muss der Knoten Nutzverkehr sofort stoppen, den neuen Anschluss bestimmen, Registrierungen und nötigen VPN-Aufbau abschließen und erst dann fortfahren. Ungewissheit darf keine implizite Freigabe sein.
Der Beispielalgorithmus fragt i-HA und x-HA parallel. Die externe Antwort erlaubt vorläufig „außen“; „innen“ verlangt die gültige i-HA-Antwort mit TNC. Schweigen kann Verlust, Filterung oder Ausfall bedeuten und beweist keinen Ort.
Der Timer erfasst unsichtbare Wechsel
Upstream-Routing kann wechseln, obwohl Layer 2 verbunden bleibt. Daher ist innen periodische Neuregistrierung erforderlich. Nach mehr als T_MONITOR seit dem letzten Erfolg darf der Knoten keine Nutzdaten senden oder empfangen; er verwirft oder puffert sie bis zur erfolgreichen erneuten Prüfung.
Das beseitigt nicht jedes Leck, sondern begrenzt dessen mögliche Dauer. Ein kürzerer Wert senkt das Expositionsfenster und erhöht Signalisierung sowie Abhängigkeit vom Agenten.
Der kleinere Schlüssel entscheidet über den stärkeren Tunnel
IPsec schützt Daten, Mobile IPv4 die Mobilitätssignalisierung. Ein Bruch der Signalisierung kann IPsec-Verkehr umleiten, ohne dessen Vertraulichkeit zu brechen. Auch pseudo-NAT kann Verfügbarkeit zerstören, ohne zu entschlüsseln.
Doch die i-HA-Antwort entscheidet mit, ob der Tunnel entfällt. Ein schwaches gemeinsames Geheimnis ist deshalb fatal: Eine Fälschung kann das Endgerät zum Abschalten der Verschlüsselung bewegen. Angegriffen wurde der Schalter, nicht der starke Algorithmus.
Der notwendige Grenzbeleg
Speichern sollte man Gerät und Schnittstelle, Anschluss, Anfrage und Antwort, Zeiten und TNC, Security Association, Authentisierung und Replay-Entscheid, Quelladresse und passende Regel, Policy-Versionen von i-HA, Firewall und Routing, letzte Prüfung, T_MONITOR, Statuswechsel, gesperrte oder gepufferte Pakete sowie VPN- und Verschlüsselungszustand bei Freigabe.
Anwendungsautorisierung bleibt separat. Belegt ist nur: Diese Schnittstelle bestand zu diesem Zeitpunkt den konfigurierten Innentest dieses Agenten.
Quellen
- https://www.rfc-editor.org/rfc/rfc5265.html
- https://www.rfc-editor.org/rfc/rfc5265.txt
- https://www.rfc-editor.org/info/rfc5265/
- https://datatracker.ietf.org/doc/rfc5265/
- https://datatracker.ietf.org/doc/rfc5265/history/
- https://datatracker.ietf.org/doc/rfc5265/references/
- https://datatracker.ietf.org/doc/rfc5265/referencedby/
- https://www.rfc-editor.org/errata/rfc5265
- https://www.rfc-editor.org/rfc/rfc5266.html
- https://www.rfc-editor.org/rfc/rfc3344.html
- https://www.rfc-editor.org/rfc/rfc4301.html
- https://www.rfc-editor.org/rfc/rfc2409.html
- https://www.rfc-editor.org/rfc/rfc3519.html
- https://www.rfc-editor.org/rfc/rfc3947.html
- https://www.rfc-editor.org/rfc/rfc3948.html
- https://www.rfc-editor.org/rfc/rfc4093.html
- https://www.rfc-editor.org/rfc/rfc4555.html
- https://heng.lu/on-reality-layers-symbolic-power-and-why-clarity-feels-so-hostile/
- https://heng.lu/running-code-primary-the-patch-needed-to-preserve-the-internet-original-design/
- https://heng.lu/on-the-agency-problem-at-the-core-of-internet-governance/
Mitgliederbriefing
Detaillierter Profilkontext
Melden Sie sich mit der richtigen Mitgliedschaftsstufe an, um das vollständige Briefing und die Quellennotizen freizuschalten.
Nur für Strategic Circle
Strategic Circle
Offen für alle Leser. Schalten Sie Profil-Briefings nach Beitritt und Anmeldung frei.
Strategic Circle beitretenNur für Leadership Alliance
Leadership Alliance
Für qualifizierte Inhaber von IP-Assets und Management; melden Sie sich an, um Leadership-Alliance-Briefings freizuschalten.
Leadership Alliance beitreten
