Zum Hauptinhalt springen

2.4. Zustandssynchronisation und Verbindungsablauf

2.4. Zustandssynchronisation und Verbindungsablauf​

Ein IKE-Endpunkt ist berechtigt, jederzeit seinen gesamten mit einer IKE SA und der Sammlung der entsprechenden Child SAs verbundenen Zustand zu vergessen. Dies ist das erwartete Verhalten im Falle eines Absturzes und Neustarts eines Endpunkts. Es ist wichtig, wenn ein Endpunkt versagt oder seinen Zustand zurücksetzt, dass der andere Endpunkt diese Bedingungen erkennt und nicht weiter Bandbreite im Netzwerk verschwendet, indem er Pakete auf verlassenen SAs sendet, nur um zu sehen, dass sie in ein schwarzes Loch fallen.

Die INITIAL_CONTACT-Benachrichtigung besagt, dass diese IKE SA die einzige derzeit aktive IKE SA zwischen den authentifizierten Identitäten ist. Sie KANN gesendet werden, wenn eine IKE SA nach einem Absturz etabliert wird, und der Empfänger KANN diese Information verwenden, um jede andere IKE SA, die er zur selben authentifizierten Identität hat, ohne Warten auf einen Ablauf zu löschen. Diese Benachrichtigung DARF NICHT von einer Entität gesendet werden, die repliziert werden kann (zum Beispiel Roaming-Benutzer-IDs, bei denen der Benutzer berechtigt ist, sich gleichzeitig von zwei entfernten Systemen mit der Unternehmensfirewall zu verbinden). Die INITIAL_CONTACT- Benachrichtigung, falls gesendet, MUSS in der ersten IKE_AUTH-Anfrage oder -antwort sein, nicht als separater späterer Austausch; Parteien, die sie in anderen Nachrichten empfangen, KÖNNEN sie ignorieren.

Da IKE darauf ausgelegt ist, trotz DoS-Angriffen aus dem Netzwerk zu funktionieren, DARF ein Endpunkt nicht aufgrund von Routing-Informationen (zum Beispiel ICMP-Nachrichten) oder ungeschützten IKE-Nachrichten (zum Beispiel Notify-Nachrichten, die sich über unbekannte SPIs beschweren) schließen, dass der andere Endpunkt versagt hat. Ein Endpunkt MUSS schließen, dass der andere Endpunkt versagt hat, nur wenn wiederholte Versuche, ihn zu kontaktieren, für einen Ablaufzeitraum ohne Antwort blieben, oder wenn eine kryptografisch geschützte INITIAL_CONTACT-Benachrichtigung auf einer anderen IKE SA zur selben authentifizierten Identität empfangen wurde. Ein Endpunkt sollte vermuten, dass der andere Endpunkt aufgrund von Routing-Informationen versagt hat, und eine Anfrage initiieren, um zu sehen, ob der andere Endpunkt lebendig ist. Um zu überprüfen, ob die andere Seite lebendig ist, spezifiziert IKE eine leere INFORMATIONAL-Nachricht, die (wie alle IKE-Anfragen) eine Bestätigung erfordert (beachten Sie, dass im Kontext einer IKE SA eine „leere" Nachricht aus einem IKE-Header gefolgt von einem Encrypted-Payload besteht, der keine Payloads enthält). Wenn kürzlich eine Nachricht (kryptografisch geschützt, das heißt nicht retransmittiert) von der anderen Seite empfangen wurde, KÖNNEN ungeschützte Notify- Nachrichten ignoriert werden. Implementierungen MÜSSEN den Durchsatz begrenzen, mit dem sie Aktionen auf Basis ungeschützter Nachrichten ausführen.

Die Anzahl der Wiederholungsversuche und die Dauer der Ablaufzeiten werden von dieser Spezifikation nicht abgedeckt, da sie die Interoperabilität nicht beeinflussen. Es wird vorgeschlagen, dass Nachrichten mindestens ein Dutzend Mal über einen Zeitraum von mindestens mehreren Minuten retransmittiert werden, bevor eine SA aufgegeben wird, aber verschiedene Umgebungen können unterschiedliche Regeln erfordern. Um ein guter Netzwerkbürger zu sein, MÜSSEN die Retransmissionszeiten exponentiell wachsen, um das Netzwerk nicht zu überfluten und eine bestehende Überlastungssituation zu verschlimmern. Wenn auf allen mit einer IKE SA verbundenen SAs nur ausgehender Datenverkehr war, ist es wesentlich, die Lebendigkeit des anderen Endpunkts zu bestätigen, um schwarze Löcher zu vermeiden. Wenn kürzlich keine kryptografisch geschützte Nachricht auf einer IKE SA oder einer ihrer Child SAs empfangen wurde, muss das System eine Lebendigkeitsprüfung durchführen, um zu vermeiden, Nachrichten an einen toten Peer zu senden. (Dies wird manchmal „Dead Peer Detection" oder „DPD" genannt, obwohl es eigentlich lebende Peers erkennt, nicht tote.) Der Empfang einer kürzlich kryptografisch geschützten Nachricht auf einer IKE SA oder einer ihrer Child SAs garantiert die Lebendigkeit der IKE SA und aller ihrer Child SAs. Beachten Sie, dass dies Anforderungen an die Ausfallmodi eines IKE-Endpunkts stellt. Eine Implementierung muss das Senden auf jeder SA stoppen, wenn ein Ausfall sie daran hindert, auf allen verbundenen SAs zu empfangen. Wenn ein System Child SAs erstellt, die unabhängig voneinander ausfallen können, ohne dass die zugehörige IKE SA in der Lage ist, eine Löschnachricht zu senden, dann MUSS das System solche Child SAs über separate IKE SAs aushandeln.

Es gibt einen DoS-Angriff auf den Initiator einer IKE SA, der vermieden werden kann, wenn der Initiator die entsprechenden Vorsichtsmaßnahmen trifft. Da die ersten beiden Nachrichten einer SA-Einrichtung nicht kryptografisch geschützt sind, könnte ein Angreifer auf die Nachricht des Initiators vor dem echten Responder antworten und den Verbindungsaufbau vergiften. Um dies zu verhindern, KANN der Initiator mehrere Antworten auf seine erste Nachricht akzeptieren, jede als potenziell legitim behandeln, darauf antworten und dann alle ungültigen halboffenen Verbindungen löschen, wenn er eine kryptografisch geschützte gültige Antwort auf eine seiner Anfragen erhält. Sobald eine kryptografisch gültige Antwort empfangen wurde, müssen alle nachfolgenden Antworten ignoriert werden, ob sie kryptografisch gültig sind oder nicht.

Beachten Sie, dass mit diesen Regeln es keinen Grund gibt, SA- Lebensdauern auszuhandeln und zu genehmigen. Wenn IKE annimmt, dass der Partner tot ist, basierend auf wiederholtem Fehlen einer Bestätigung für eine IKE-Nachricht, dann werden die IKE SA und alle darüber konfigurierten Child SAs gelöscht.

Ein IKE-Endpunkt kann jederzeit inaktive Child SAs löschen, um die Ressourcen zurückzugewinnen, die für deren Zustandserhaltung verwendet werden. Wenn ein IKE-Endpunkt entscheidet, Child SAs zu löschen, MUSS er Delete-Payloads an das andere Ende senden, das ihn über die Löschung informiert. Er KANN ebenso die IKE SA ablaufen lassen. Das Schließen der IKE SA schließt implizit alle zugehörigen Child SAs. In diesem Fall SOLLTE ein IKE-Endpunkt einen Delete-Payload senden, der angibt, dass er die IKE SA geschlossen hat, es sei denn, der andere Endpunkt antwortet nicht mehr.