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

Jen Linkova <furry13@gmail.com> Tue, 27 February 2024 20:25 UTC

Return-Path: <furry13@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 77494C14F747 for <ipsec@ietfa.amsl.com>; Tue, 27 Feb 2024 12:25:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.858
X-Spam-Level:
X-Spam-Status: No, score=-1.858 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, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] 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 ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JtQnCXHdVPE3 for <ipsec@ietfa.amsl.com>; Tue, 27 Feb 2024 12:25:08 -0800 (PST)
Received: from mail-lj1-x22d.google.com (mail-lj1-x22d.google.com [IPv6:2a00:1450:4864:20::22d]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CAB5BC14F681 for <ipsec@ietf.org>; Tue, 27 Feb 2024 12:25:08 -0800 (PST)
Received: by mail-lj1-x22d.google.com with SMTP id 38308e7fff4ca-2d2628e81b8so1637271fa.0 for <ipsec@ietf.org>; Tue, 27 Feb 2024 12:25:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1709065507; x=1709670307; darn=ietf.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=+3OtVyZkrpQwKFDRP+/Vv3+hHndy/+fu/TAXt/eHrKc=; b=cWF6fbr8HbrS0mg1PSTma9YEgOJuWhp2/0P6xxyzEDELmtELK+fV9m/c7Ig3ePCsy5 iGY0kNP2wjGkNXNfxOhUhqV/vF4foK/VZZ3azpCvRaR+9TIM/mCEYwz6Q70tQgelemUd 5EqR5GodC4QTkhAqXmhu64wlygzQwU5oj9Nrjh1XIRpyCHzDGkAxECY2u/xiLnXO6DUW iTGctt3EkUD6EJM+b7CyRRq+1Vhnv8TExODMo2aa/e7oAiTN87lKxV3JAYlKzGyJRumd mREJzjeQvPaV3Gts3zIQjOS43WDBbEpnzrA8CjGiN2FBz2EBzPe86tKj87Ul0GXC/gIo OqrQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709065507; x=1709670307; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=+3OtVyZkrpQwKFDRP+/Vv3+hHndy/+fu/TAXt/eHrKc=; b=F03HEJN8oCzXqxr0Rs6s1Ja8pSsp47r3ogsweE0DD+0lK2Q1/WrmOniCTMg8+OM1kU rb4gOd9fenADfo7A9IaeUNm+l9T5e4/tbfnC/d1efl9PKRoesLN8ohiu3Ag2PJuWN1Jh bZC8XP4eu04N70Asbp/xpLaPwRyeT26wJZtK1hgo/cFmn7yySk2yu0SXGSICX1A3QrjH GlTQHrmnZAOn8hOK9CzPeMKjiqlLs/BTLbUGnCTPXA8tRLhqFK/JW87eBYvPs0UVSnLE CQdQoACPw0HtHToLK+WM/UuoAZ2DH1k3KdiB845cO2Sxet2zkaBecOaeXW24I9WFonYG 5Fsg==
X-Gm-Message-State: AOJu0Yww6QrGqGMPC1AJ/QIqB3oGjgKihj0nzCmaO8fgoeJEyWLgCyux ZxwLJ8WlP/f5PUw7G/eGomHXO22wVa26wXBH0eXWcMbRpm5eWGRjO6aZkAzRZcDfen4EgGPH4H6 7tHlyfWhegde/Ze/i0XpYwhDWPoqcy8Ko
X-Google-Smtp-Source: AGHT+IERM3zaFNcyZ1pPn5ZdQ19GPe6wrnGlhbNmKrReKyiBr8UmqyP+G7L22rx9KgsakHuZW8tRN/0FanhylZNZZjg=
X-Received: by 2002:a2e:809:0:b0:2d2:b903:5384 with SMTP id 9-20020a2e0809000000b002d2b9035384mr124854lji.9.1709065506688; Tue, 27 Feb 2024 12:25:06 -0800 (PST)
MIME-Version: 1.0
References: <20240227192506.BA9BC3898C@tuna.sandelman.ca> <22008.1709064760@obiwan.sandelman.ca>
In-Reply-To: <22008.1709064760@obiwan.sandelman.ca>
From: Jen Linkova <furry13@gmail.com>
Date: Wed, 28 Feb 2024 07:24:54 +1100
Message-ID: <CAFU7BAQamUi4jiwZUM7VufivQ=NnHpLiG1Pi-0HzFmQmy+wWGA@mail.gmail.com>
To: Michael Richardson <mcr+ietf@sandelman.ca>
Cc: ipsec@ietf.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/RJCVrdDoIPP0RfyQlWBOGJgsl6Y>
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:25:09 -0000

On Wed, Feb 28, 2024 at 7:12 AM Michael Richardson
<mcr+ietf@sandelman.ca> wrote:
> 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.

[skip]

In your scenario announcing ESP Ping capability in IKE is useless but harmless.
You seem to assume that ESP ping is only used by humans
troubleshooting the network, but think about other case:
a device (a phone, for example) is going to establish an IPSec session
to a VPN server or, even better, a voice gateway (as WiFi Calling
requires IPSec). Currently, if IKE succeeds but ESP fails, it's very
hard for the device to detect the issue.
If the peer supports ESP ping and announces it in IKE, the device can
use ESP ping to find out that..ooops, the corporate WiFi the device is
connected to is having issues with end2end ESP connectivity, and
switch back to the mobile network, instead of blackholing the data
packets.

So I do not see any harm in advertising it in IKE but I do see some
benefits - but I clearly might be missing smth here.

-- 
Cheers, Jen Linkova