2.21. Error Handling (Fehlerbehandlung)

Während der IKE-Verarbeitung können viele Fehler auftreten. Grundregel: Bei schlecht formatierten oder aus Richtliniengründen (z. B. keine passenden Algorithmen) unannehmbaren Anfragen enthält die Antwort eine Notify-Nutzlast mit dem Fehler. Ob geantwortet wird, hängt davon ab, ob eine authentisierte IKE SA existiert.

Bei Parse- oder Verarbeitungsfehlern einer Antwort wird in der Regel kein Fehler zurückgesendet, da Antworten keine neuen Anfragen auslösen sollen. Der Empfänger sollte den IKE-Zustand dennoch bereinigen (z. B. Delete bei schlechter SA).

Nur Authentisierungsfehler (AUTHENTICATION_FAILED und EAP-Fehler) und formal falsche Nachrichten (INVALID_SYNTAX) führen zum Löschen der IKE SA ohne expliziten INFORMATIONAL mit Delete. Andere Fehler KÖNNEN einen solchen Austausch erfordern, wenn die Richtlinie es verlangt. Bei EAP Failure wird AUTHENTICATION_FAILED nicht gesendet.

2.21.1. Error Handling in IKE_SA_INIT (Fehler in IKE_SA_INIT)

Fehler vor einer kryptografisch geschützten IKE SA erfordern Vorsicht. Abwägung zwischen Diagnosehilfe für den Peer und Vermeidung von DoS durch gefälschte Nachrichten.

In IKE_SA_INIT führt jede Fehlerbenachrichtigung zum Scheitern des Austauschs. Einige (COOKIE, INVALID_KE_PAYLOAD, INVALID_MAJOR_VERSION) können späteren Erfolg ermöglichen. Alle Fehlerbenachrichtigungen sind unauthentisiert; der Empfänger sollte eine Weile weiterversuchen. Nur wenn dieses Dokument Korrekturmaßnahmen definiert, sollte sofort gehandelt werden.

2.21.2. Error Handling in IKE_AUTH (Fehler in IKE_AUTH)

Alle IKE_AUTH-Fehler, die die Authentisierung scheitern lassen (ungültiges Shared Secret, ID, nicht vertrauenswürdiger Aussteller, widerrufenes/abgelaufenes Zertifikat usw.), SOLLEN AUTHENTICATION_FAILED erzeugen. Liegt der Fehler beim Responder, steht die Benachrichtigung in der geschützten Antwort, oft allein. Auch verschlüsselt sollte der Peer, der den anderen noch nicht authentisiert hat, vorsichtig sein.

Liegt der Fehler beim Initiator, KANN die Benachrichtigung in einem separaten INFORMATIONAL stehen. Ausnahme von der Regel, keine neuen Austausche auf Antwortfehler zu starten.

Anfragen mit nicht unterstützter kritischer Nutzlast oder völlig fehlerhafter Nachricht MÜSSEN insgesamt abgewiesen werden und DÜRFEN nur UNSUPPORTED_CRITICAL_PAYLOAD oder INVALID_SYNTAX als Antwort auslösen. Authentisierungsnutzlasten sollten dann nicht geprüft werden.

Gelingt die Authentisierung in IKE_AUTH, ist die IKE SA etabliert; Child-SA oder Konfiguration kann dennoch scheitern. Das löscht die IKE SA nicht automatisch. Der Responder kann IDr, CERT, AUTH senden und parallel Fehler für mitgeführte Vorgänge (FAILED_CP_REQUIRED, NO_PROPOSAL_CHOSEN usw.); der Initiator DARF die Authentisierung deswegen nicht als gescheitert werten.

In IKE_AUTH oder dem direkt folgenden INFORMATIONAL löschen oder verhindern nur UNSUPPORTED_CRITICAL_PAYLOAD, INVALID_SYNTAX und AUTHENTICATION_FAILED die IKE SA ohne Delete. Erweiterungen können weitere Benachrichtigungen mit gleicher Semantik definieren, DÜRFEN sie aber nicht nutzen, ohne dass der Peer sie versteht (z. B. Vendor ID).

2.21.3. Error Handling after IKE SA is Authenticated (Nach IKE-SA-Authentisierung)

Nach Authentisierung der IKE SA MUSS jede fehlerhafte Anfrage eine Antwort mit Fehlerhinweis erzeugen.

Normalerweise sollte eine gültige Antwort beim anderen keinen Fehler erzeugen; Fehler sollten nicht als INFORMATIONAL außerhalb von Antworten gesendet werden (Schleifenrisiko). Bei inkonsistentem Zustand kann Löschen der IKE SA sinnvoll sein.

Liefert ein Peer bei formal fehlerhafter Anfrage (nach MAC- und Fensterprüfung) INVALID_SYNTAX, gilt die Benachrichtigung für beide als fatal: IKE SA wird ohne explizites Delete gelöscht.

2.21.4. Error Handling Outside IKE SA (Außerhalb der IKE SA)

Knoten MÜSSEN die Rate von Antworten auf ungeschützte Nachrichten begrenzen.

Nachrichten auf UDP 500/4500 außerhalb einer bekannten IKE SA (und kein IKE-Start): möglicherweise nach Absturz. Als Antwort markiert: auditieren, NICHT antworten. Als Anfrage: auditieren, antworten optional. Antwort: gleiche IP/Port-Quelle, gleiche IKE-SPIs, kopiert Message ID, nicht kryptografisch geschützt, Notify INVALID_IKE_SPI (Ziel-SPI unbekannt, oft Reboot).

Empfänger einer solchen ungeschützten Notify antwortet NICHT und ändert keinen SA-Zustand. Als Hinweis auf mögliche SA-Probleme Lebendigkeit prüfen; Häufigkeit begrenzen (DoS).

Außerhalb von IKE-Anfragen (z. B. ESP mit unbekanntem SPI) SOLL ein INFORMATIONAL mit Notify gestartet werden.

Verdächtige Nachrichten von IP/Port (bei NAT-T) mit bestehender IKE SA SOLLEN mit IKE Notify in INFORMATIONAL über jener SA beantwortet werden. Empfänger ändert keinen SA-Zustand, kann aber protokollieren.