Avishek Ganguly writes: > I have questions regarding use of NO_PROPOSAL_CHOSEN and > INVALID_KE_PAYLOAD in > IKE_SA_INIT exchange in RFC 5996 IKEv2. > > According to > > "Section 3.10.1. Notify Message Types > > NO_PROPOSAL_CHOSEN 14 > None of the proposed crypto suites was acceptable. This can be > sent in any case where the offered proposals (including but not > limited to SA payload values, USE_TRANSPORT_MODE notify, > IPCOMP_SUPPORTED notify) are not acceptable for the responder. > " > > according to the above statement it is meant that if initiator sends a > proposal with a Diffie-Hellman group value that is unacceptable by the > responder, then responder must send a NO_PROPOSAL_CHOSEN notification.
There is no must in the NO_PROPOSAL_CHOSEN text. It says "This can be sent...". In general what IKEv2 error message you get back depends on the implementation and about the order where the implementation parses things. For example some implementation might check the SA first and return NO_PROPOSAL_CHOSEN, but other implementation might check the SA limit first and return NO_ADDITIONAL_SAS if SA limit is already reached. Another similar case might be for example TS_UNACCEPTABLE error. Some implementations do have catch-all policy which says no algorithm proposal is valid for other addresses, thus instead of returning TS_UNACCEPTABLE error when proposed something that is outside their policy, they always return NO_PROPOSAL_CHOSEN as regardless what initiator proposed it cannot fullfill their no algorithm is allowed policy... So do not try to guess what error other end might return... > But according to > > "Section 1.2. The Initial Exchanges > Because the initiator sends its Diffie-Hellman value in the > IKE_SA_INIT, it must guess the Diffie-Hellman group that the > responder will select from its list of supported groups. If the > initiator guesses wrong, the responder will respond with a Notify > payload of type INVALID_KE_PAYLOAD indicating the selected group. > " > > From the INVALID_KE_PAYLOAD description stated above means that > NO_PROPOSAL_CHOSEN case is exclusive of this INVALID_KE_PAYLOAD. INVALID_KE_PAYLOAD is special case, as it is not really an error notification, it is notification telling that yes, your proposal was ok, but you selected wrong group in your KE payload, please try again with correct group. I.e. the INVALID_KE_PAYLOAD is used if the initiator used group in KE payload that is not allowed by the responder, but included some other group that is acceptable in the SA payload. I.e. if there is a way to recover, then you send INVALID_KE_PAYLOAD and tell which group should be used. If none of the groups in the SA payload is acceptable then you send NO_PROPOSAL_CHOSEN, as there is no way to continue, without changing the policy. -- [email protected] _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
