2.1. Verwendung von Retransmission-Stimern
2.1. Verwendung von Retransmission-Stimern
Alle Nachrichten in IKE existieren paarweise: eine Anfrage und eine Antwort. Das Aufbauen einer IKE SA besteht normalerweise aus zwei Austauschen. Sobald die IKE SA etabliert ist, kann jedes Ende der Security Association jederzeit Anfragen initiieren, und es können zu einem gegebenen Zeitpunkt viele Anfragen und Antworten „in der Luft" sein. Aber jede Nachricht wird als Anfrage oder Antwort gekennzeichnet, und für jeden Austausch ist ein Ende der Security Association der Initiator und das andere der Responder.
Für jedes IKE-Nachrichtenpaar ist der Initiator für die Retransmission bei Zeitüberschreitung verantwortlich. Der Responder DARF eine Antwort niemals retransmitieren, es sei denn, er empfängt eine Retransmission der Anfrage. In diesem Fall MUSS der Responder die retransmittierte Anfrage ignorieren, außer insoweit sie eine Retransmission der Antwort verursacht. Der Initiator MUSS jede Anfrage merken, bis er die entsprechende Antwort erhält. Der Responder MUSS jede Antwort merken, bis er eine Anfrage mit einer Sequenznummer größer oder gleich der Sequenznummer der Antwort plus der Größe seines Fensters erhält (siehe Abschnitt 2.3). Um Speicher zu sparen, ist es dem Responder erlaubt, die Antwort nach einigen Minuten zu vergessen. Wenn der Responder eine retransmittierte Anfrage für die er die Antwort bereits vergessen hat empfängt, MUSS er die Anfrage ignorieren (und nicht etwa versuchen, eine neue Antwort zu konstruieren).
IKE ist ein zuverlässiges Protokoll: Der Initiator MUSS eine Anfrage retransmittieren, bis er eine entsprechende Antwort erhält oder die IKE SA als fehlgeschlagen betrachtet. Im letzteren Fall gibt der Initiator den gesamten mit der IKE SA und allen darüber ausgehandelten Child SAs verbundenen Zustand auf. Eine Retransmission der IKE_SA_INIT-Anfrage MUSS bitgenau mit der ursprünglichen Anfrage identisch sein. Das heißt, alles ab dem IKE-Header (der Initiator-IKE-SA-SPI) MUSS bitgenau identisch sein; Elemente davor (wie IP- und UDP-Header) müssen nicht identisch sein.
Retransmissionen der IKE_SA_INIT-Anfrage erfordern eine besondere Behandlung. Wenn ein Responder eine IKE_SA_INIT-Anfrage empfängt, muss er bestimmen, ob das Paket eine Retransmission gehörig zu einer bestehenden „halboffenen" IKE SA ist (in welchem Fall der Responder dieselbe Antwort retransmittiert), oder eine neue Anfrage (in welchem Fall der Responder eine neue IKE SA erstellt und eine neue Antwort sendet), oder ob es zu einer bestehenden IKE SA gehört, bei der die IKE_AUTH-Anfrage bereits empfangen wurde (in welchem Fall der Responder sie ignoriert).
Es reicht nicht aus, den Initiator-SPI und/oder die IP-Adresse zu verwenden, um diese drei Fälle zu unterscheiden, da zwei verschiedene Peers hinter demselben NAT denselben Initiator-SPI wählen könnten. Stattdessen wird ein robuster Responder die IKE-SA-Suche durchführen, indem er das gesamte Paket, dessen Hash oder den Ni-Payload verwendet.
Die Retransmissionsrichtlinie für unidirektionale Nachrichten ist etwas anders als die für normale Nachrichten. Da niemals eine Bestätigung gesendet wird, gibt es keinen Grund, unidirektionale Nachrichten gratuit zu retransmitieren. Da all diese Nachrichten Fehler sind, ist es sinnvoll, sie einmal pro „fehlerhaftem" Paket zu senden und sie nur dann zu retransmitieren, wenn weitere fehlerhafte Pakete empfangen werden. Ebenso ist es sinnvoll, Retransmissionen solcher Fehlernachrichten zu begrenzen.