Re: [IPsec] NO_PROPOSAL_CHOSEN vs INVALID_SYNTAX

"Valery Smyslov" <smyslov.ietf@gmail.com> Thu, 20 June 2019 14:39 UTC

Return-Path: <smyslov.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 0E08A12014B for <ipsec@ietfa.amsl.com>; Thu, 20 Jun 2019 07:39:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.499
X-Spam-Level:
X-Spam-Status: No, score=-0.499 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, RCVD_IN_SORBS_WEB=1.5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no 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 zmgTKM1ZslQY for <ipsec@ietfa.amsl.com>; Thu, 20 Jun 2019 07:39:55 -0700 (PDT)
Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com [IPv6:2a00:1450:4864:20::22a]) (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 44E1D12013C for <ipsec@ietf.org>; Thu, 20 Jun 2019 07:39:55 -0700 (PDT)
Received: by mail-lj1-x22a.google.com with SMTP id k18so2916587ljc.11 for <ipsec@ietf.org>; Thu, 20 Jun 2019 07:39:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=ex7Tji0YQBtDtChnQYFpJ674SMDy1ELwjbbzdNMzA3o=; b=Zg6OxxjTAx6TyyYsK04v+Cmym1mu45GhjurpoGaAbnb6nnYDi8xNnYZFTl1WFeigpQ D9kXXGgV/+hgpKBpgg7jxtIA7U2Kg4y5S+5Ca9/8r3XiM/NONoNiftjYzT1XooKKzLQc NQxBe+lvJBbO5ZYqY7Nbi7+wvW37ECLwJIKNKFQ0Sa4NYFtr6DaK+KW/p4GMIMmmIY/F pn0DlwhRJG431Ywoybo6Om56duGy74XWBQLIvUhUcQx1fGu1eNdjSmSEE8wS5CIqepWG lEMdFVqeIpmGZShewJsRT+X8WHhEsBfL7Em5BmEXcL4rhGvgEOOjOCVrAcpjWWc1+GPr RBtg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=ex7Tji0YQBtDtChnQYFpJ674SMDy1ELwjbbzdNMzA3o=; b=VhNfvoaOebUco1na9hHFZ20sEiewFEHTePf3wK3311nIhKLm8DTHHorfOCHtv69URZ +6C/d9lvXOdcqcZOxMShREFSYJztHV3RBc7DTUZiiJvg6zd347P8RHgBWmBWevMlqA/l GG6pkUXFmPJu6+txcjwt8204tueXdKTEvtWDzjYzpOtA3Mfw7Re18Zcugkz9au87M5dX +BCHnUAxtwcqtquhDs7XJyrXRJ7x+xQfCnOqUz8fhqMXYlF/k7omMbMityQfdaUhfz7d 9jssyvpHuP2XD4PGN0DgroY2SGXYYNgDRpt4WDQr2tRy9hrU5JV4bmDPkqEatXYhh0jz WkuQ==
X-Gm-Message-State: APjAAAWBWbaVV2VKSpWDYzeZ7JroK5tjX/Vpd1v2+azUZVmMD2aJK4s/ MRJbF+9oXyL3ATUhLnAbgmwsbO0f
X-Google-Smtp-Source: APXvYqw2HIvC0ft6ilhOwbXDo4oaOpN0xgIgqJPF3VRIZd5O3yykzRBqY+AgVPAKYmnmrbMzBTLjRQ==
X-Received: by 2002:a2e:9158:: with SMTP id q24mr44765364ljg.119.1561041592543; Thu, 20 Jun 2019 07:39:52 -0700 (PDT)
Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id h10sm3172083lfj.10.2019.06.20.07.39.51 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 20 Jun 2019 07:39:51 -0700 (PDT)
From: Valery Smyslov <smyslov.ietf@gmail.com>
To: 'Paul Wouters' <paul@nohats.ca>, ipsec@ietf.org
References: <alpine.LRH.2.21.1906200940420.9218@bofh.nohats.ca>
In-Reply-To: <alpine.LRH.2.21.1906200940420.9218@bofh.nohats.ca>
Date: Thu, 20 Jun 2019 17:39:30 +0300
Message-ID: <028201d52775$f89a8230$e9cf8690$@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQMOVHCg7qEpa2o+m56j10GVVAXT7qQyP5gA
Content-Language: ru
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/_h9jVDUkExiyIwnsKAt608_qspE>
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 14:40:06 -0000

Hi Paul,

generally the INVALID_SYNTAX must be returned when something
fatal happened, that cannot be fixed by adjusting configuration etc.,
only re-installing app after bug-fixing would help.
In contrast, NO_PROPOSAL_CHOSEN means that after some actions from 
operator the connection would succeed.

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

I'd rather not return anything in this case.

> 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'd return NO_PROPOSAL_CHOSEN.

Regards,
Valery.

> 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