1.3.1. Erstellen neuer Child SAs mit dem CREATE_CHILD_SA-Austausch

1.3.1. Erstellen neuer Child SAs mit dem CREATE_CHILD_SA-Austausch

Eine Child SA kann durch Senden einer CREATE_CHILD_SA-Anfrage erstellt werden. Die CREATE_CHILD_SA-Anfrage zum Erstellen einer neuen Child SA lautet:

Initiator Responder

HDR, SK {SA, Ni, [KEi], TSi, TSr} -->

Der Initiator sendet SA-Angebote im SA-Payload, einen Nonce im Ni-Payload, optional einen Diffie-Hellman-Wert im KEi-Payload und die vorgeschlagenen Traffic Selectors für die vorgeschlagene Child SA in den TSi- und TSr- Payloads.

Die CREATE_CHILD_SA-Antwort zum Erstellen einer neuen Child SA lautet:

                         <--  HDR, SK {SA, Nr, [KEr],
                                  TSi, TSr}

Der Responder antwortet (mit derselben Message ID) mit dem akzeptierten Angebot in einem SA-Payload und einem Diffie-Hellman-Wert im KEr-Payload, falls KEi in der Anfrage enthalten war und die ausgewählte kryptografische Suite diese Gruppe umfasst.

Die Traffic Selectors für den Datenverkehr, der auf dieser SA gesendet werden soll, werden in den TS-Payloads in der Antwort angegeben, die eine Teilmenge dessen sein können, was der Initiator der Child SA vorgeschlagen hat.

Die USE_TRANSPORT_MODE-Benachrichtigung KANN in einer Anfragenachricht enthalten sein, die auch einen SA-Payload enthält, der eine Child SA anfordert. Sie fordert, dass die Child SA den Transportmodus anstelle des Tunnelmodus für die erstellte SA verwendet. Wenn die Anfrage akzeptiert wird, MUSS die Antwort ebenfalls eine Benachrichtigung vom Typ USE_TRANSPORT_MODE enthalten. Wenn der Responder die Anfrage ablehnt, wird die Child SA im Tunnelmodus eingerichtet. Wenn dies für den Initiator inakzeptabel ist, MUSS der Initiator die SA löschen. Hinweis: Außer bei Verwendung dieser Option zur Aushandlung des Transportmodus werden alle Child SAs den Tunnelmodus verwenden.

Die ESP_TFC_PADDING_NOT_SUPPORTED-Benachrichtigung besagt, dass der sendende Endpunkt keine Pakete akzeptiert, die Traffic Flow Confidentiality (TFC)-Padding über die ausgehandelte Child SA enthalten. Wenn keiner der Endpunkte TFC-Padding akzeptiert, ist diese Benachrichtigung sowohl in der Anfrage als auch in der Antwort enthalten. Wenn diese Benachrichtigung nur in einer der Nachrichten enthalten ist, kann TFC-Padding weiterhin in die andere Richtung gesendet werden.

Die NON_FIRST_FRAGMENTS_ALSO-Benachrichtigung wird zur Fragmentierungskontrolle verwendet. Siehe [IPSECARCH] für eine ausführlichere Erklärung. Beide Parteien müssen dem Senden von Nicht-Erst-Fragmenten zustimmen, bevor eine Partei dies tut. Sie wird nur aktiviert, wenn die NON_FIRST_FRAGMENTS_ALSO-Benachrichtigung sowohl in der ein SA vorschlagenden Anfrage als auch in der sie akzeptierenden Antwort enthalten ist. Wenn der Responder keine Nicht-Erst-Fragmente senden oder empfangen möchte, lässt er lediglich die NON_FIRST_FRAGMENTS_ALSO-Benachrichtigung aus seiner Antwort weg, lehnt aber nicht die gesamte Child-SA-Erstellung ab.

Eine IPCOMP_SUPPORTED-Benachrichtigung, die in Abschnitt 2.22 behandelt wird, kann ebenfalls im Austausch enthalten sein.

Ein fehlgeschlagener Versuch, eine Child SA zu erstellen, SOLLTE die IKE SA nicht abbrechen: es gibt keinen Grund, die Arbeit zu verlieren, die zur Einrichtung der IKE SA geleistet wurde. Siehe Abschnitt 2.21 für eine Liste von Fehlernachrichten, die auftreten können, wenn das Erstellen einer Child SA fehlschlägt.