IETF Logo Mail Archive

Re: [IPsec] NO_PROPOSAL_CHOSEN vs INVALID_SYNTAX

Yoav Nir <ynir.ietf@gmail.com> Thu, 20 June 2019 20:51 UTC

Return-Path: <ynir.ietf@gmail.com>
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 3A2861201EE for <ipsec@ietfa.amsl.com>; Thu, 20 Jun 2019 13:51:55 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 1hSHv6jPIwaB for <ipsec@ietfa.amsl.com>; Thu, 20 Jun 2019 13:51:53 -0700 (PDT)
Received: from mail-wr1-x42e.google.com (mail-wr1-x42e.google.com [IPv6:2a00:1450:4864:20::42e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 038661201E4 for <ipsec@ietf.org>; Thu, 20 Jun 2019 13:51:53 -0700 (PDT)
Received: by mail-wr1-x42e.google.com with SMTP id c2so4378501wrm.8 for <ipsec@ietf.org>; Thu, 20 Jun 2019 13:51:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=+kGycsozSQ9OvbyO+oDeNCeUyqi57hXU4IAvGk6eoYI=; b=Iu9uK3fztgT+Owa3/1d+BtPYD4Y33Q6ESlPlOVCd8NqGawpecFQLQmlFMmtPWATjGd A4KO4G4K/wDNmBGAHiEclGuIKApXELei8eN435g3ZNqF3zfrZUDWYHEvqPfCIBuul3KF cznvcrr90wTxgYcm6c6zOekfijH6oV06GqKUc8Dg5FXNuIXHARXzKNaqUY4uw+mXiTKZ VFqh5RiwC2yaPNQ33tKagRrwR3vZJG+AjjVFtI2Y/xq6qIL7Ic6gQjpxz2CzLkged67w dkNww0uHurFA+v4RpB+D+3iaSm65ovvD4N99dR/V7OK1ZiNdtOStmLTZA/jqcROU6amq +p0g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=+kGycsozSQ9OvbyO+oDeNCeUyqi57hXU4IAvGk6eoYI=; b=l8OcEmBACB2FrPAgd6Gr+c718ylA+nr1ZYKyXPF7I6BhGLoXCSM6if3u73FyzMQ1ax v42SaNQbfxyx7D0cNiiQHy9FANDzkNoQUXzN0MstGaXDD55gYVfhvkAAPjwwrVVW6YxL sZy2mzPi3eDcuf8yARx1YGk6AbYpSfPS38ipb+HuSKQQfCdllZiHLixuHp1oQB8zspDf 8/1ZNNQRG3sdZBOstPu4dgQfxOSovRJRhS0BdeRNMc4mtGhjEU0QDLtt12HA5XIDk2yd aClOjcX0kCggOPtiJIQSD5mrzIX2NBVvWi5NHfFShKdn5YASFaakWMQ+m7igclw5VWl3 sasg==
X-Gm-Message-State: APjAAAW4RhIUD7/TXa/5hV21Xy8dSwG1qpLjAnt2FcK9xZtfBqUf/i3B 55ilawneSjYeu5kePRHsyJo=
X-Google-Smtp-Source: APXvYqzJSB1jc1F2g0nl1Y1z3RI5q1jGElGAF6/CYZn64twk4VRjzLWuer06kZDC8m47FQK/xxKJRg==
X-Received: by 2002:adf:f909:: with SMTP id b9mr61687594wrr.119.1561063911499; Thu, 20 Jun 2019 13:51:51 -0700 (PDT)
Received: from [192.168.1.12] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id d18sm1380095wrb.90.2019.06.20.13.51.50 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 20 Jun 2019 13:51:50 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Yoav Nir <ynir.ietf@gmail.com>
In-Reply-To: <alpine.LRH.2.21.1906200940420.9218@bofh.nohats.ca>
Date: Thu, 20 Jun 2019 23:51:48 +0300
Cc: "ipsec@ietf.org WG" <ipsec@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <54816C88-2B2D-4AAD-A906-DF628D4BA946@gmail.com>
References: <alpine.LRH.2.21.1906200940420.9218@bofh.nohats.ca>
To: Paul Wouters <paul@nohats.ca>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/1i9-xO3RSIS-DUkdAndcL-Iq-mI>
Subject: Re: [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 20:51:55 -0000

In the days when I had an IKEv2 implementation, NO_PROPOSAL_CHOSEN was the go-to error code for everything the Responder didn’t like; wrong algorithms, wrong transforms (like transport instead of tunnel), unknown peer, 

INVALID_SYNTAX meant something like malformed packet.

> On 20 Jun 2019, at 16:52, Paul Wouters <paul@nohats.ca> wrote:
> 
> 
> 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 mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec

v2.23.0 | Report a Bug | By Email