FYI

---------- Forwarded message ----------
Date: Mon, 1 Sep 2014 03:37:13
From: Yoav Nir <[email protected]>
Cc: "[email protected]" <[email protected]>
To: Avishek Ganguly <[email protected]>
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.

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 protected]> 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 protected]
https://www.ietf.org/mailman/listinfo/ipsec


_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________
Swan-dev mailing list
[email protected]
https://lists.libreswan.org/mailman/listinfo/swan-dev

Reply via email to