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

Michael Richardson <mcr+ietf@sandelman.ca> Tue, 27 February 2024 21: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 7253FC15108B for <ipsec@ietfa.amsl.com>; Tue, 27 Feb 2024 13:12:37 -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 UyqPfgVEbvac for <ipsec@ietfa.amsl.com>; Tue, 27 Feb 2024 13:12:33 -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) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 418C0C14CF15 for <ipsec@ietf.org>; Tue, 27 Feb 2024 13:12:32 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id CDE8F3898F; Tue, 27 Feb 2024 16:12:30 -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 6t6a2xiuJUmr; Tue, 27 Feb 2024 16:12:28 -0500 (EST)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id B3E833898E; Tue, 27 Feb 2024 16:12:28 -0500 (EST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sandelman.ca; s=mail; t=1709068348; bh=EPcmS4NYlF2acLU+co4S1mUs+VdKoDczgZY9ikvjJyA=; h=From:To:cc:Subject:In-Reply-To:References:Date:From; b=fVk3yKR6BU73C0BDHUuD3c5/qeeEeslDInCOZLlHaXzkFDi5zEY989zuRu1kJ7i7B 0sMq8V/+G5YKgwcsS3YFY4w8HMLCnKx2FMkD67Q9ADPohtfOcDi2/CIFKTDGE9GLvR NdYGQkD46FZkB3fv7Dttbh/G8XQM72NCfrnstZW3EA1VGS5eNzxHh/FZYT3ijv/LwN rWotAhDf6vWpOSQmx+8Lw27sBaO0BMvZSdwlRT7q1a++EZAPCpDwN/jb5uZg9Af5qu a9nRECteBTsftGjkT2Zz/iBjUdGdXqvcCx6ruSGV7mBl4fGle4Q0HSthvtkmDV5PHp f0E5X3Uar4h5Q==
Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id AF2381FB; Tue, 27 Feb 2024 16:12:28 -0500 (EST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Jen Linkova <furry13@gmail.com>
cc: ipsec@ietf.org
In-Reply-To: <CAFU7BAQamUi4jiwZUM7VufivQ=NnHpLiG1Pi-0HzFmQmy+wWGA@mail.gmail.com>
References: <20240227192506.BA9BC3898C@tuna.sandelman.ca> <22008.1709064760@obiwan.sandelman.ca> <CAFU7BAQamUi4jiwZUM7VufivQ=NnHpLiG1Pi-0HzFmQmy+wWGA@mail.gmail.com>
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 16:12:28 -0500
Message-ID: <5790.1709068348@obiwan.sandelman.ca>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/iWJ5BIo4V7e3idcIRHEe3k2AGKs>
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 21:12:37 -0000

Jen Linkova <furry13@gmail.com> wrote:
    > 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.

I mostly agree.

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

Sure.

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

If there is an IKE SA that works and is up, then we can easily negotiate the right TS to enable
an appropriate ESP-encrypted ICMPv6 (echo request) PING to a target system.  This is not
spoofable or even detectable by an adversary.

I would encourage someone to write a really short I-D that defines an IKEv2
NOTIFY that contained an IP address at which a gateway is willing to
entertain ICMPv6 Echo Requests to.   That would fit into the defined TSr.
In many many environments, that would be the IPv6 address of the inside interface
of the gateway.
But, in some esoteric situations, it would need to be some other address.
In such an I-D, we could argue whether or not the address has to fit into TSi/TSr.
(There are arguments both ways)

That wouldn't be an SPI=7 thing though, so I'd want it another document.

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

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