IETF Logo Mail Archive

Re: [IPsec] Fwd: New Version Notification for draft-colitti-ipsecme-esp-ping-01.txt

Michael Richardson <mcr+ietf@sandelman.ca> Mon, 01 April 2024 18:26 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 891B6C151078 for <ipsec@ietfa.amsl.com>; Mon, 1 Apr 2024 11:26:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.097
X-Spam-Level:
X-Spam-Status: No, score=-7.097 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_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 KEo8Af7VuocS for <ipsec@ietfa.amsl.com>; Mon, 1 Apr 2024 11:26:15 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (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 6DC3EC15106F for <ipsec@ietf.org>; Mon, 1 Apr 2024 11:26:14 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id E3BF038991; Mon, 1 Apr 2024 14:26:13 -0400 (EDT)
Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id EyvgSeZfHONa; Mon, 1 Apr 2024 14:26:12 -0400 (EDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 426E238990; Mon, 1 Apr 2024 14:26:12 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sandelman.ca; s=mail; t=1711995972; bh=6RN+bTTfrUvjU8Srz34l6avlZqzQWmQqDlTMysPW5Nk=; h=From:To:Subject:In-Reply-To:References:Date:From; b=p0xgZRBudLX9VrRsyblXASLeNWLT7ox4li0HoQTQEKv5jXdRNUdYq35YLAG+g/w1V 463kXrWOAnpBcUI06cXrIvUgVCHJ+jqID1WL43+TbqzY9nLbfH1jFPMXeCz3QiJHmJ iFYyeaHPM/lRntwBPnhzXclCSbAvHVlIRIFcNRToJjb/VZky397ytSV/5j62wklQHa /op1okfrQ2i8W4b/0plFGrh9s1mP/RTbpuzbOWCJd9wR86hc+oQ4zJUeKdswyccfNh 1ACxqUXVT8AND3bGHokse9AXoG1NgrYXtHOU8q6TdUZl+ft9q4LZjeiFAhSCGjm65i CPbivQua+OK5A==
Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 3A694AD; Mon, 1 Apr 2024 14:26:12 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: "Panwei (William)" <william.panwei@huawei.com>, "ipsec@ietf.org" <ipsec@ietf.org>
In-Reply-To: <2217d98aacad4db88a8341849578ebe6@huawei.com>
References: <170922023791.21652.13338059706655424526@ietfa.amsl.com> <CAFU7BAQuNkHDRidjQqGbXySKJ1FCRKuAksDa0BHsvfGeG45k6g@mail.gmail.com> <4b44a218c77a49edbaecd3b524dbaac7@huawei.com> <476994.1711501928@dyas> <3f7b0380650a40e6b9cec4afb7f6d034@huawei.com> <497306.1711523247@dyas> <57bd1510e66b45c7af60513fbba3051c@huawei.com> <343238de-93c9-ed85-2c9d-2d783e3a38ca@nohats.ca> <536308.1711584810@dyas> <2217d98aacad4db88a8341849578ebe6@huawei.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: Mon, 01 Apr 2024 14:26:12 -0400
Message-ID: <32539.1711995972@obiwan.sandelman.ca>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/0ZJUNG2qmPNfUDEaQDDWrX841Zc>
Subject: Re: [IPsec] Fwd: New Version Notification for draft-colitti-ipsecme-esp-ping-01.txt
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: Mon, 01 Apr 2024 18:26:19 -0000

Panwei (William) <william.panwei@huawei.com> wrote:
    > It seems to me that extending the traceroute by using an ESP packet can
    > be done right now and has no requirement for the ESP packet format. Any
    > ESP packets can work with this mechanism, and there is no need for the
    > designated SPIs.

    > The receiver will send back an ICMP response when it receives the ESP
    > packet with TTL=0, no matter what this ESP packet actually looks
    > like. The receiver can be the on-path firewalls or routers, and the
    > final IPsec peer.

Yes, that's true up to the final hop.
At the final hop, when the destination address is local, then one *might*
receive an ICMP Parameter Problem because the SPI is not recognized. Maybe.
If it does not, then the sender will send another packet with TTL one larger,
and then when it gets no reply try again with two larger, etc.

Receiving  ESPping reply with SPI=8, would be a positive reply that the path
was clear (in both directions!).

One thing which the document does not say, and I'm not sure what to say, is
what the TTL of the ESP reply ought to be.
I was contemplating if it should copy the TTL of the incoming packet.
That would weirdly let one traceroute in the reverse direction too, only
the ICMPs would go to the receiving host, which is not the host doing the
traceeroute, so not very useful actually.

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

v2.23.0 | Report a Bug | By Email