2.21. Fehlerbehandlung

Es gibt viele Arten von Fehlern, die während der IKE-Verarbeitung auftreten können. Die allgemeine Regel lautet, dass, wenn eine Anfrage empfangen wird, die schlecht formatiert ist oder aus Gründen der Richtlinie (wie etwa kein passender kryptographischer Algorithmus) nicht akzeptabel ist, die Antwort einen Notify-Payload enthält, der den Fehler angibt. Die Entscheidung, ob eine solche Antwort gesendet wird, hängt davon ab, ob eine authentifizierte IKE-SA existiert.

Wenn bei der Analyse oder Verarbeitung eines Antwortpakets ein Fehler auftritt, lautet die allgemeine Regel, keine Fehlermeldung zurückzusenden, da Antworten keine neuen Anfragen erzeugen sollten (und eine neue Anfrage wäre der einzige Weg, eine Fehlermeldung zurückzusenden). Solche Fehler bei der Analyse oder Verarbeitung von Antwortpaketen sollten den Empfänger dennoch veranlassen, den IKE-Zustand zu bereinigen (z. B. durch Senden eines Delete für eine fehlerhafte SA).

Nur Authentifizierungsfehler (AUTHENTICATION_FAILED und EAP-Fehlschlag) und fehlerhaft formatierte Nachrichten (INVALID_SYNTAX) führen zur Löschung der IKE-SA, ohne dass ein expliziter INFORMATIONAL-Austausch mit einem Delete-Payload erforderlich ist. Andere Fehlerbedingungen KÖNNEN einen solchen Austausch erfordern, wenn die Richtlinie dies vorschreibt. Wird der Austausch mit EAP-Failure beendet, wird keine AUTHENTICATION_FAILED-Benachrichtigung gesendet.

2.21.1. Fehlerbehandlung in IKE_SA_INIT

Fehler, die auftreten, bevor eine kryptographisch geschützte IKE-SA etabliert ist, müssen sehr sorgfältig behandelt werden. Es gibt einen Trade-off zwischen dem Wunsch, dem Peer bei der Diagnose eines Problems zu helfen und somit auf den Fehler zu antworten, und dem Wunsch, Teil eines auf gefälschten Nachrichten basierenden DoS-Angriffs zu werden, zu vermeiden.

In einem IKE_SA_INIT-Austausch führt jede Fehlerbenachrichtigung zum Fehlschlag des Austauschs. Beachten Sie, dass einige Fehlerbenachrichtigungen wie COOKIE, INVALID_KE_PAYLOAD oder INVALID_MAJOR_VERSION zu einem nachfolgenden erfolgreichen Austausch führen können. Da alle Fehlerbenachrichtigungen völlig unauthentifiziert sind, sollte der Empfänger vor dem Aufgeben noch eine Zeit lang versuchen. Der Empfänger sollte nicht sofort aufgrund der Fehlerbenachrichtigung handeln, es sei denn, Korrekturmaßnahmen sind in dieser Spezifikation definiert, wie für COOKIE, INVALID_KE_PAYLOAD und INVALID_MAJOR_VERSION.

2.21.2. Fehlerbehandlung in IKE_AUTH

Alle Fehler, die in einem IKE_AUTH-Austausch auftreten und die Authentifizierung aus welchem Grund auch immer (ungültiger gemeinsamer Schlüssel, ungültige ID, nicht vertrauenswürdiger Zertifikataussteller, widerrufenes oder abgelaufenes Zertifikat usw.) scheitern lassen, SOLLTEN zu einer AUTHENTICATION_FAILED-Benachrichtigung führen. Tritt der Fehler beim Responder auf, wird die Benachrichtigung in der geschützten Antwort zurückgegeben und ist normalerweise der einzige Payload in dieser Antwort. Obwohl die IKE_AUTH-Nachrichten verschlüsselt und integritätsgeschützt sind, muss der Peer, der diese Benachrichtigung empfängt, die Information mit Vorsicht behandeln, falls er das andere Ende noch nicht authentifiziert hat.

Tritt der Fehler beim Initiator auf, kann die Benachrichtigung in einem separaten INFORMATIONAL-Austausch zurückgegeben werden, normalerweise ohne weitere Payloads. Dies ist eine Ausnahme von der allgemeinen Regel, keine neuen Austausche aufgrund von Fehlern in Antworten zu starten.

Beachten Sie jedoch, dass Anforderungsnachrichten, die einen nicht unterstützten kritischen Payload enthalten, oder bei denen die gesamte Nachricht fehlerhaft formatiert ist (statt nur schlechtem Payload-Inhalt), vollständig abgelehnt werden MÜSSEN und nur zu einer UNSUPPORTED_CRITICAL_PAYLOAD- oder INVALID_SYNTAX-Benachrichtigung führen dürfen, die als Antwort gesendet wird. Der Empfänger sollte in diesem Fall die authentifizierungsbezogenen Payloads nicht verifizieren.

Wenn die Authentifizierung im IKE_AUTH-Austausch erfolgreich war, ist die IKE-SA etabliert; jedoch kann das Erstellen der Child-SA oder das Anfordern von Konfigurationsinformationen immer noch fehlschlagen. Dieser Fehlschlag führt nicht automatisch zur Löschung der IKE-SA. Insbesondere KANN ein Responder alle mit der Authentifizierung verbundenen Payloads (IDr, CERT und AUTH) einschließen, während er Fehlerbenachrichtigungen für die piggybacked-Austausche (FAILED_CP_REQUIRED, NO_PROPOSAL_CHOSEN usw.) sendet, und der Initiator DARF die Authentifizierung deswegen nicht scheitern lassen. Der Initiator KANN die IKE-SA natürlich aus Richtliniengründen später löschen.

In einem IKE_AUTH-Austausch, oder im unmittelbar folgenden INFORMATIONAL-Austausch (falls bei der Verarbeitung einer Antwort auf IKE_AUTH ein Fehler auftrat), sind die Benachrichtigungen UNSUPPORTED_CRITICAL_PAYLOAD, INVALID_SYNTAX und AUTHENTICATION_FAILED die einzigen, die ohne Delete-Payload zum Löschen oder Nicht-Erstellen der IKE-SA führen. Erweiterungsdokumente dürfen neue Fehlerbenachrichtigungen mit dieser Semantik definieren, DÜRFEN sie aber nur verwenden, wenn gezeigt wurde, dass der Peer sie versteht, etwa durch Verwendung eines Vendor-ID-Payloads.

2.21.3. Fehlerbehandlung nach Authentifizierung der IKE SA

Nachdem die IKE-SA authentifiziert ist, MÜSSEN alle Anfragen mit Fehlern zu einer Antwort führen, die den Fehler meldet.

In normalen Situationen sollten keine Fälle auftreten, in denen eine gültige Antwort von einem Peer zu einer Fehlersituation beim anderen Peer führt, also sollte es keinen Grund geben, dass ein Peer Fehlermeldungen an das andere Ende sendet, außer als Antwort. Da das Senden solcher Fehlermeldungen als INFORMATIONAL-Austausch zu weiteren Fehlern führen könnte, die Schleifen verursachen, SOLLTEN solche Fehler nicht gesendet werden. Wenn Fehler gesehen werden, die anzeigen, dass die Peers nicht denselben Zustand haben, kann es gut sein, die IKE-SA zu löschen, um den Zustand zu bereinigen und neu zu beginnen.

Wenn ein Peer bei der Analyse einer Anfrage bemerkt, dass sie schlecht formatiert ist (nachdem sie die MAC-Prüfungen und Fensterprüfungen bestanden hat) und eine INVALID_SYNTAX-Benachrichtigung zurückgibt, dann gilt diese Fehlerbenachrichtigung bei beiden Peers als fatal, was bedeutet, dass die IKE-SA ohne einen expliziten Delete-Payload gelöscht wird.

2.21.4. Fehlerbehandlung außerhalb der IKE SA

Ein Knoten muss die Rate begrenzen, mit der er Nachrichten als Antwort auf ungeschützte Nachrichten sendet.

Wenn ein Knoten auf UDP-Port 500 oder 4500 eine Nachricht außerhalb des Kontexts einer ihm bekannten IKE-SA empfängt (und die Nachricht keine Anfrage zum Starten einer IKE-SA ist), kann dies das Ergebnis eines kürzlichen Absturzes des Knotens sein. Ist die Nachricht als Antwort markiert, kann der Knoten das verdächtige Ereignis auditieren, darf aber NICHT antworten. Ist die Nachricht als Anfrage markiert, kann der Knoten das verdächtige Ereignis auditieren und KANN eine Antwort senden. Wird eine Antwort gesendet, MUSS die Antwort an die IP-Adresse und den Port gesendet werden, von woher sie kam, mit den gleichen IKE-SPIs und der kopierten Message-ID. Die Antwort DARF NICHT kryptographisch geschützt sein und MUSS einen INVALID_IKE_SPI-Notify-Payload enthalten. Die INVALID_IKE_SPI-Benachrichtigung zeigt an, dass eine IKE-Nachricht mit einem nicht erkannten Ziel-SPI empfangen wurde; dies bedeutet normalerweise, dass der Empfänger neu gestartet ist und das Vorhandensein einer IKE-SA vergessen hat.

Ein Peer, der einen solchen ungeschützten Notify-Payload empfängt, DARF NICHT antworten und DARF den Zustand vorhandener SAs nicht ändern. Die Nachricht könnte gefälscht sein oder eine Antwort, zu deren Senden ein echter Kommunikationspartner getäuscht wurde. Ein Knoten sollte eine solche Nachricht (sowie eine Netzwerknachricht wie ICMP Destination Unreachable) als Hinweis behandeln, dass es Probleme mit SAs zu dieser IP-Adresse geben könnte, und sollte eine Liveness-Prüfung für solche IKE-SAs initiieren. Eine Implementierung SOLLTE die Häufigkeit solcher Tests begrenzen, um nicht in einen DoS-Angriff hineingetäuscht zu werden.

Tritt ein Fehler außerhalb des Kontexts einer IKE-Anfrage auf (z. B. der Knoten erhält ESP-Nachrichten auf einem nicht existierenden SPI), SOLLTE der Knoten einen INFORMATIONAL-Austausch mit einem das Problem beschreibenden Notify-Payload initiieren.

Ein Knoten, der von einer IP-Adresse (und Port, falls NAT-Traversal verwendet wird), mit der er eine IKE-SA hat, eine verdächtige Nachricht empfängt, SOLLTE einen IKE-Notify-Payload in einem IKE-INFORMATIONAL-Austausch über diese SA senden. Der Empfänger DARF den Zustand keiner SA als Folge dessen ändern, kann aber das Ereignis auditieren, um bei der Diagnose von Fehlfunktionen zu helfen.