Hi , Please clarify the following .
1. Is it mandatory or optional (implementation dependent) to create an IKEV2 sa when IKE_AUTH exchange fails for reason like NO_PROPOSAL_CHOSEN, TS_UNACCEPTABLE, SINGLE_PAIR_REQUIRED,INTERNAL_ADDRESS_FAILURE, and FAILED_CP_REQUIRED ? Regards, Kalyani -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of [email protected] Sent: Friday, March 27, 2009 10:55 PM To: [email protected]; [email protected] Cc: [email protected] Subject: Re: [IPsec] Ticket #9 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 _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
