Re: [IPsec] [furry13/ipsecme-esp-ping] Abandoning non-reserved SPIs (PR #6)

Michael Richardson <mcr+ietf@sandelman.ca> Tue, 27 February 2024 20:12 UTC

Return-Path: <mcr+ietf@sandelman.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 AFB7EC151069 for <ipsec@ietfa.amsl.com>; Tue, 27 Feb 2024 12:12:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.106
X-Spam-Level:
X-Spam-Status: No, score=-2.106 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sandelman.ca
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BOQzs0lJZZRl for <ipsec@ietfa.amsl.com>; Tue, 27 Feb 2024 12:12:42 -0800 (PST)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96953C151063 for <ipsec@ietf.org>; Tue, 27 Feb 2024 12:12:42 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id EB8EB3898F for <ipsec@ietf.org>; Tue, 27 Feb 2024 15:12:41 -0500 (EST)
Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id HWKMlz3bfzoH for <ipsec@ietf.org>; Tue, 27 Feb 2024 15:12:40 -0500 (EST)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 662723898E for <ipsec@ietf.org>; Tue, 27 Feb 2024 15:12:40 -0500 (EST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sandelman.ca; s=mail; t=1709064760; bh=VnlVwyOSRqIEWvTSXTrKfxiSictwqYBoffLyQBvms3A=; h=From:To:Subject:In-Reply-To:References:Date:From; b=rIYzLXmmMpdXQCkgWZk9ziGxzBgnA7elhCI195Ry24cHKCxTe2AV50qVgzkfHpWEv ubyZuMEOSGKi6QHrzNIIuPNM178NUCwy86IEFpIRCKRySWROCp4Tk4/xRFrDcbq968 OFRqXSOAgToScWYtF72JjNhmFh9Lif5SdXcGKsxLGJWIhBN6jhugOgtf8eHA6KHuPt YLe5hIT425wpo2bXN5iMnO/OPyd7nCJEsI6wXTaVtWl9MRCrEAmF6XV54Y69xjpcOp TM54m2z5H2iGdUtWX8yQIeK///Hd092wopqZ6gjTnLL0vwqtxYbkRlXwmtPS+AU8Mu 5I+H6c6yMH20A==
Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 62EFA1FB for <ipsec@ietf.org>; Tue, 27 Feb 2024 15:12:40 -0500 (EST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: ipsec@ietf.org
In-Reply-To: <20240227192506.BA9BC3898C@tuna.sandelman.ca>
References: <20240227192506.BA9BC3898C@tuna.sandelman.ca>
X-Mailer: MH-E 8.6+git; nmh 1.8+dev; GNU Emacs 28.2
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Date: Tue, 27 Feb 2024 15:12:40 -0500
Message-ID: <22008.1709064760@obiwan.sandelman.ca>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/rHkfznUpgyYCkYuxLeIOY5rPRt4>
Subject: Re: [IPsec] [furry13/ipsecme-esp-ping] Abandoning non-reserved SPIs (PR #6)
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.39
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: Tue, 27 Feb 2024 20:12:46 -0000

In github issue:
https://github.com/furry13/ipsecme-esp-ping/pull/6

I said:
>I am not in favour of any link to IKE.

I don't think it's useful to signal in IKE that the host/gateway supports SPI=7.
I believe in many debug situations, the person doing the diagnostics won't
have a credential that they can use in IKE, and the person that has that
credential (it could be a physical token) won't know how to do the debugging.

Consider a scenario where some branch office regularly has an external
auditor physically present.  Said auditor expects to operate their Remote
Access VPN from their laptop, for which they got permission some years before.
Central IT turns on IPv6, and everything is great, but they didn't think to
enable ESP (because NAT44 rules, right?).  Assume auditor's VPN hub supports IPv6.

Auditor+Auditor's local host: "Hello, IT.  The VPN that has works for
*Auditor* since 2007 has suddendly stopped working.  It was approved in
ticket #87245 back in the day."
IT: "Uh. When did it stop?  When we enabled IPv6.  Oh."

ESP Ping means that the IT can effectively send ESP packets from some host
*they* control at the branch office, aiming at the Auditor's VPN end-point.
They don't even need ESP Responses to work, but it's sure nice if they do.
Further, ESP Ping could be used in a *traceroute* like way using TTLs to
determine how far the ESP Ping packet gets.
  traceroute --protocol=51
probably gets one 2/3 of the way there, but maybe not all the way.
In the process, they discover some IPv6 firewall which thinks only TCP and
UDP exist, and it gets fixed.

--
Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide