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

Yoav Nir <ynir.ietf@gmail.com> Mon, 01 September 2014 07:37 UTC

Return-Path: <ynir.ietf@gmail.com>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A51D1A014C for <ipsec@ietfa.amsl.com>; Mon, 1 Sep 2014 00:37:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TmhQwJXyNyJ8 for <ipsec@ietfa.amsl.com>; Mon, 1 Sep 2014 00:37:24 -0700 (PDT)
Received: from mail-we0-x232.google.com (mail-we0-x232.google.com [IPv6:2a00:1450:400c:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 789D61A011B for <ipsec@ietf.org>; Mon, 1 Sep 2014 00:37:19 -0700 (PDT)
Received: by mail-we0-f178.google.com with SMTP id u57so4947403wes.23 for <ipsec@ietf.org>; Mon, 01 Sep 2014 00:37:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=v0l3hXPJ3AkgOiKpZYayGJzAywSWAM/2EcLXpn9lajQ=; b=TlOvLKzewUJ9UtGT6uWbEh6VGy1+ZTbzuiKPr8tYhlrFhjihTrXWjXAyuqiKHf8ne2 Y6niA/m3ztaowgxyRuskuXruWCKfBtw4P9hG4t0sn2KlQ2h5u1Mt+LPsJHY7xiwaC5QU Dxd+Y8NZp/b88i+vDtlnfU1LXDDm/vTN6i9BSTZfIrhzZs/Ev4fVHA9SgtSZUttPHRyD bsov9Tc/bsbn9R7+VmuPhGH9CdjonP9n8Cr9wy3vw+6mlyxkg3hQ+xhUIX/3zO5bjuHJ qd6nOtNvxT6L4tmLEzTJvajGS5vv4vB7TOX4l9jZUah6l3Bj69RvTyjrBMjM6jshzaMz OJoQ==
X-Received: by 10.195.12.4 with SMTP id em4mr1028685wjd.98.1409557037576; Mon, 01 Sep 2014 00:37:17 -0700 (PDT)
Received: from [172.24.251.145] (dyn32-131.checkpoint.com. [194.29.32.131]) by mx.google.com with ESMTPSA id xa6sm106168wjc.19.2014.09.01.00.37.16 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 01 Sep 2014 00:37:17 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_8A28D0D2-627B-4B68-9AC4-5083D5EDB4D7"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Yoav Nir <ynir.ietf@gmail.com>
In-Reply-To: <f349616c76c3467a95239d459bb4fb01@DM2PR0601MB713.namprd06.prod.outlook.com>
Date: Mon, 01 Sep 2014 10:37:13 +0300
Message-Id: <583C5D54-E70D-42AE-845C-79CF5CB8F71F@gmail.com>
References: <f349616c76c3467a95239d459bb4fb01@DM2PR0601MB713.namprd06.prod.outlook.com>
To: Avishek Ganguly <aganguly@ixiacom.com>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/0vWlapgWZffifKGN16Zscc1Yhps
Cc: "ipsec@ietf.org" <ipsec@ietf.org>
Subject: Re: [IPsec] Question Regarding IKEv2 RFC5996 Use of NO_PROPOSAL_CHOSEN and INVALID_KE_PAYLOAD
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 01 Sep 2014 07:37:27 -0000

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 <aganguly@ixiacom.com> 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
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec