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

From: Yoav Nir <[email-masked]>
Date: Mon, 1 Sep 2014 10:37:13 +0300

Hi, Avishek

English is not my first language, so I’m not sure what “exclusive” means below, but I hope I can clarify anyways.

Suppose Responder policy is to allow certain groups (say, 19 and 20), while the Initiator’s request includes groups 2, 5, and 14 in the SA payload, and group 2 in the KE payload. 

It seems like both INVALID_KE_PAYLOAD and NO_PROPOSAL_CHOSEN are appropriate, but this is not the case. The purpose of the INVALID_KE_PAYLOAD is to have the Initiator immediately retry (it says so right after the part you quoted) with the correct group. But we already no that the Initiator doesn’t support any of the supported groups. If it did, then the SA payload would include them. So in this case, only NO_PROPOSAL_CHOSEN is appropriate.

NO_PROPOSAL_CHOSEN is the kind of error that is not correctable without configuration changes. INVALID_KE_PAYLOAD is an error that should be automatically corrected immediately.

So although it doesn’t say so explicitly in the RFC, you really need to evaluate the SA payload first. It might not be worth it to check the others.

Hope this helps

Yoav

On Sep 1, 2014, at 7:28 AM, Avishek Ganguly <[email-masked]> wrote:

> Hello,
>  
> 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.
>  
> 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.
>  
> Is it right interpretation of the above two error types ?
>  
> Thanks and Regards,
> Avishek
>  
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec

---

From: Avishek Ganguly <[email-masked]>
Date: Mon, 1 Sep 2014 09:01:42 +0000

Thanks Yoav for your explanation.

> English is not my first language, so I'm not sure what "exclusive" means below, but I hope I can clarify anyways.

By exclusive I mean NO_PROPOSAL_CHOSEN is an error that is not generated because of any DH Group mismatches in KE Payload.

So it seems that INVALID_KE_PAYLOAD is an error that should be generated during CREATE_CHILD_SA exchange. And NO_PROPOSAL_CHOSEN is appropriate for IKE_SA_INIT. Because Before IKE_SA_INIT responder does not know which groups initiator supports. When responder gets a IKE_SA_INIT with invalid DH GROUP
It should assume that there is some configuration issues from initiator side.

Regards,
Avishek
From: Yoav Nir [mailto:[email-masked]]
Sent: Monday, September 01, 2014 1:07 PM
To: Avishek Ganguly
Cc: [email-masked]
Subject: Re: [IPsec] Question Regarding IKEv2 RFC5996 Use of NO_PROPOSAL_CHOSEN and INVALID_KE_PAYLOAD

Hi, Avishek

English is not my first language, so I'm not sure what "exclusive" means below, but I hope I can clarify anyways.

Suppose Responder policy is to allow certain groups (say, 19 and 20), while the Initiator's request includes groups 2, 5, and 14 in the SA payload, and group 2 in the KE payload.

It seems like both INVALID_KE_PAYLOAD and NO_PROPOSAL_CHOSEN are appropriate, but this is not the case. The purpose of the INVALID_KE_PAYLOAD is to have the Initiator immediately retry (it says so right after the part you quoted) with the correct group. But we already no that the Initiator doesn't support any of the supported groups. If it did, then the SA payload would include them. So in this case, only NO_PROPOSAL_CHOSEN is appropriate.

So although it doesn't say so explicitly in the RFC, you really need to evaluate the SA payload first. It might not be worth it to check the others.

Hope this helps

Yoav

On Sep 1, 2014, at 7:28 AM, Avishek Ganguly <[email-masked]<mailto:[email-masked]>> wrote:

Hello,

But according to

Thanks and Regards,
Avishek

_______________________________________________
IPsec mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Yoav Nir <[email-masked]>
Date: Mon, 1 Sep 2014 12:17:00 +0300

> It should assume that there is some configuration issues from initiator side.

No. Both are appropriate in both exchanges.

Both CCSA and IKE_SA_INIT have SA payloads and KE payloads. Since there is no requirement that the new (rekeyed) IKE SA have the same algorithms and groups of the old IKE SA, the proposals may be different. 

Regardless of whether we are creating a new authenticated IKE SA, a Child SA with PFS or a rekeyed IKE SA, you could have an empty intersection of group sets (leading to a NO_PROPOSAL_CHOSEN) or a wrong choice of group in KE payload (leading to INVALID_KE_PAYLOAD)

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 1 Sep 2014 17:16:13 +0300

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
> 
> 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...

> 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-masked]