Tero Kivinen wrote:
> I am not sure we reached the decision yet, but I think more text is
> needed if that is allowed, thus creating that text might help moving
> things forward (i.e send replacement text).
Here's a first sketch:
Section 1.3.1:
OLD:
Failure of an attempt to create a CHILD SA SHOULD NOT tear down the
IKE SA: there is no reason to lose the work done to set up the IKE
SA. When an IKE SA is not created, the error message return SHOULD
NOT be encrypted because the other party will not be able to
authenticate that message. [[ Note: this text may be changed in the
future. ]]
NEW:
If creating the CHILD SA fails for any reason, the IKE SA stays
up.
(This section is about CREATE_CHILD_SA exchange, so the text about
IKE_SA creation failures is in wrong place)
Section 1.2:
OLD:
{{ Clarif-4.2}} If creating the Child SA during the IKE_AUTH exchange
fails for some reason, the IKE SA is still created as usual. The
list of responses in the IKE_AUTH exchange that do not prevent an IKE
SA from being set up include at least the following:
NO_PROPOSAL_CHOSEN, TS_UNACCEPTABLE, SINGLE_PAIR_REQUIRED,
INTERNAL_ADDRESS_FAILURE, and FAILED_CP_REQUIRED.
NEW:
{{ Clarif-4.2 }} During the IKE_AUTH exchange, two kinds of
failures can happen.
If the failure is related to creating the Child SA, the IKE SA is
still created as usual. The list of responses in the IKE_AUTH
exchange that do not prevent an IKE SA from being set up include at
least the following: NO_PROPOSAL_CHOSEN, TS_UNACCEPTABLE,
SINGLE_PAIR_REQUIRED, INTERNAL_ADDRESS_FAILURE, and
FAILED_CP_REQUIRED. In this case, the error notification is
included in the last IKE_AUTH response, and the SA/TSi/TSr payloads
are omitted from this message.
If the failure is related to creating the IKE SA (for example,
AUTHENTICATION_FAILED), the IKE_SA is not created. Note that
although the IKE_AUTH messages are encrypted and integrity
protected, if the peer receiving this notification has not
authenticated the other end yet, the information needs to be
treated with caution.
Best regards,
Pasi
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
