[IPsec] Question Regarding IKEv2 RFC5996 Use of NO_PROPOSAL_CHOSEN and INVALID_KE_PAYLOAD

[Tero Kivinen <[e-mail]>]

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.
-- 
[e-mail]