[IPsec] NO_PROPOSAL_CHOSEN vs INVALID_SYNTAX
Paul Wouters <paul@nohats.ca> Thu, 20 June 2019 13:52 UTC
Return-Path: <paul@nohats.ca>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC66E120045 for <ipsec@ietfa.amsl.com>; Thu, 20 Jun 2019 06:52:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca
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 Ydgus_R_CQ_G for <ipsec@ietfa.amsl.com>; Thu, 20 Jun 2019 06:52:11 -0700 (PDT)
Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89871120020 for <ipsec@ietf.org>; Thu, 20 Jun 2019 06:52:11 -0700 (PDT)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 45V3CZ0StLzD0d for <ipsec@ietf.org>; Thu, 20 Jun 2019 15:52:10 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1561038730; bh=8muboYTVfkYSOjD0dfqV8UWfeAOaaeKDPOAZcGm5kUc=; h=Date:From:To:Subject; b=cqyKdoXBEPSVrKClZAzRV6Yle2gPeEGihsfaZm3Y7r7qquW1VospU6J/ojdvgM1Xy fWuElD/58zirHGjDOcblH8tuCIqcvnqvBCB7yvSHtlYE8Sm9vD3rbP9ml//NkQCiez U//gTxg7+btBGjrj36zadeHzlGM0zyaAha2RDtTo=
X-Virus-Scanned: amavisd-new at mx.nohats.ca
Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id WgPPgj5bjFJ2 for <ipsec@ietf.org>; Thu, 20 Jun 2019 15:52:08 +0200 (CEST)
Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS for <ipsec@ietf.org>; Thu, 20 Jun 2019 15:52:07 +0200 (CEST)
Received: by bofh.nohats.ca (Postfix, from userid 1000) id B06904A46EF; Thu, 20 Jun 2019 09:52:06 -0400 (EDT)
DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca B06904A46EF
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id A88B9417255E for <ipsec@ietf.org>; Thu, 20 Jun 2019 09:52:06 -0400 (EDT)
Date: Thu, 20 Jun 2019 09:52:06 -0400
From: Paul Wouters <paul@nohats.ca>
To: "ipsec@ietf.org WG" <ipsec@ietf.org>
Message-ID: <alpine.LRH.2.21.1906200940420.9218@bofh.nohats.ca>
User-Agent: Alpine 2.21 (LRH 202 2017-01-01)
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"; charset="US-ASCII"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/MJx5I1XR0tuRPCu8fPw0URAba08>
Subject: [IPsec] NO_PROPOSAL_CHOSEN vs INVALID_SYNTAX
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.29
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: <https://mailarchive.ietf.org/arch/browse/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: Thu, 20 Jun 2019 13:52:14 -0000
Hi, We are having a discussion about which notify to return in certain cases. The issue comes down to the names of the notifies and their actual dictated use in the RFC that does not always intuitively maps to the name. NO_PROPOSAL_CHOSEN can be interpreted as "no proposal from the IKE/IPsec proposal list matches due to all proposals having at least one mismatching transform" versus "no matching ike connection for your IKE proposal" where proposal refers to the entire IKE proposal, not the proposals list with transforms. INVALID_SYNTAX can be interpreted as "malformed packet" but the RFC text uses this as the "if all other errors dont match, use this one" so you can end up returning this even if there is no invalid syntax at all. So if your IPsec gateway only has static IP based VPNs and an unknown IP connects, some feel NO_PROPOSAL_CHOSEN conveys that, while technically, even though there is no invalid syntax in that proposal, the RFC states we should return INVALID_SYNTAX. Similarly, if during IKE_AUTH you are finding out there is no IPsec configuration that matches the incoming client, there is no "proposal list" to compare, so while NO_PROPOSAL_CHOSEN feels a more natural match, should we really return INVALID_SYNTAX despite there being no syntax problem? That is what the RFC says. I guess in the end, we are really missing a "CONNECTION_REJECTED" notify that would cover all the things not covered in the more specific notifies. What do other implementations do? Should we clarify this anywhere? libreswan was using NO_PROPOSAL_CHOSEN for most of these, but is now slated to be more strict to the RFC and use INVALID_SYNTAX. (and clearly, I'm not happy about it but it seems the RFC dictates this) Paul
- [IPsec] NO_PROPOSAL_CHOSEN vs INVALID_SYNTAX Paul Wouters
- Re: [IPsec] NO_PROPOSAL_CHOSEN vs INVALID_SYNTAX Valery Smyslov
- Re: [IPsec] NO_PROPOSAL_CHOSEN vs INVALID_SYNTAX Tommy Pauly
- Re: [IPsec] NO_PROPOSAL_CHOSEN vs INVALID_SYNTAX Michael Richardson
- Re: [IPsec] NO_PROPOSAL_CHOSEN vs INVALID_SYNTAX Yoav Nir
- [IPsec] NO_PROPOSAL_CHOSEN vs INVALID_SYNTAX Tero Kivinen
- Re: [IPsec] NO_PROPOSAL_CHOSEN vs INVALID_SYNTAX Paul Wouters