2.1. Use of Retransmission Timers (Einsatz von Retransmissionstimern)
2.1. Use of Retransmission Timers (Einsatz von Retransmissionstimern)
Alle IKE-Nachrichten treten paarweise auf: Anfrage und Antwort. Der Aufbau einer IKE-SA besteht üblicherweise aus zwei Austauschen. Nach der IKE-SA kann jede Seite der Security Association jederzeit Anfragen starten; viele Anfragen und Antworten können gleichzeitig „unterwegs“ sein. Jede Nachricht ist jedoch als Anfrage oder Antwort gekennzeichnet, und bei jedem Austausch ist eine Seite Initiator, die andere Responder.
Bei jedem IKE-Nachrichtenpaar ist der Initiator bei Timeout für Retransmission verantwortlich. Der Responder DARF niemals eine Antwort retransmitieren, es sei denn, er erhält eine Retransmission der Anfrage. Dann MUSS der Responder die retransmitierte Anfrage ignorieren, außer soweit sie eine Retransmission der Antwort auslöst. Der Initiator MUSS jede Anfrage merken, bis die zugehörige Antwort eintrifft. Der Responder MUSS jede Antwort merken, bis eine Anfrage mit Sequenznummer größer oder gleich der Antwortsequenz plus Fenstergröße eintrifft (Abschnitt 2.3). Zur Speicherersparnis DÜRFEN Responder die Antwort nach einigen Minuten vergessen. Erhält der Responder eine Retransmission zu einer vergessenen Antwort, MUSS er die Anfrage ignorieren (z. B. keine neue Antwort bauen).
IKE ist zuverlässig: Der Initiator MUSS eine Anfrage retransmitieren, bis die Antwort kommt oder die IKE-SA als gescheitert gilt. Dann verwirft der Initiator allen Zustand zu dieser IKE-SA und allen darüber verhandelten Child-SAs. Eine Retransmission MUSS bitidentisch zur ursprünglichen Anfrage ab dem IKE-Header (SPI des IKE-SA-Initiators) sein; davor (IP/UDP) nicht nötig.
IKE_SA_INIT-Retransmissionen brauchen Sonderlogik: Der Responder muss erkennen, ob das Paket zu einer halboffenen IKE-SA gehört (gleiche Antwort erneut senden), neu ist (neue IKE-SA, frische Antwort) oder zu einer IKE-SA mit bereits empfangenem IKE_AUTH gehört (ignorieren).
Nur Initiator-SPI und/oder IP reichen nicht: Zwei Peers hinter einem NAT können dieselbe Initiator-SPI wählen. Ein robuster Responder sucht die IKE-SA über das ganze Paket, einen Hash oder die Ni-Payload.
Einweg-Nachrichten: Kein ACK, daher keine sinnlose Retransmission. Als Fehlermeldungen einmal pro „verursachendem“ Paket senden und nur bei weiteren Verstößen wiederholen; trotzdem Retransmissions begrenzen.