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

"Panwei (William)" <william.panwei@huawei.com> Mon, 01 April 2024 08:46 UTC

Return-Path: <william.panwei@huawei.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 C4D91C14F6B3 for <ipsec@ietfa.amsl.com>; Mon, 1 Apr 2024 01:46:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 4RGksvQQR86z for <ipsec@ietfa.amsl.com>; Mon, 1 Apr 2024 01:46:53 -0700 (PDT)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B2D8C14F5FA for <ipsec@ietf.org>; Mon, 1 Apr 2024 01:46:53 -0700 (PDT)
Received: from mail.maildlp.com (unknown [172.18.186.216]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4V7Pdh4PL5z6K9CH; Mon, 1 Apr 2024 16:42:16 +0800 (CST)
Received: from lhrpeml500006.china.huawei.com (unknown [7.191.161.198]) by mail.maildlp.com (Postfix) with ESMTPS id 251481400CD; Mon, 1 Apr 2024 16:46:51 +0800 (CST)
Received: from kwepemi100010.china.huawei.com (7.221.188.54) by lhrpeml500006.china.huawei.com (7.191.161.198) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.35; Mon, 1 Apr 2024 09:46:50 +0100
Received: from kwepemi500010.china.huawei.com (7.221.188.191) by kwepemi100010.china.huawei.com (7.221.188.54) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.35; Mon, 1 Apr 2024 16:46:48 +0800
Received: from kwepemi500010.china.huawei.com ([7.221.188.191]) by kwepemi500010.china.huawei.com ([7.221.188.191]) with mapi id 15.01.2507.035; Mon, 1 Apr 2024 16:46:48 +0800
From: "Panwei (William)" <william.panwei@huawei.com>
To: Paul Wouters <paul@nohats.ca>, Michael Richardson <mcr+ietf@sandelman.ca>
CC: "ipsec@ietf.org" <ipsec@ietf.org>
Thread-Topic: [IPsec] Fwd: New Version Notification for draft-colitti-ipsecme-esp-ping-01.txt
Thread-Index: AQHaayQFUr6vZiHeJEm4rFfwTHJng7FJ2NuAgACSVACAAJLA0P//0IaAgADN7XD//4uGAIAAxToAgAdSLjA=
Date: Mon, 01 Apr 2024 08:46:48 +0000
Message-ID: <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>
In-Reply-To: <536308.1711584810@dyas>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.164.106.141]
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/6UODZNl4OcwUlnusX_tn-UdT0V8>
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 08:46:55 -0000

Hi Paul and Michael, thanks for your explanations.

Michael Richardson <mcr+ietf@sandelman.ca> wrote:
    > Paul Wouters <paul@nohats.ca> wrote:
    > > > If you want to do the traceroute to determine how far ESP
    > > > actually gets, you need to make sure every node supports
    > > > the ESPping.
    > >
    > > I think people meant to extend traceroute to use an ESP packet
    > > instead of an ICMP or UDP packet. The machines in the middle
    > > do not need any special support because any packet that hits
    > > TTL=0 should solicite an ICMP response.
    > 
    > That's right, and we yeah, we can do that immediately.
    > Perhaps obviously: The responding server needs to implement this
    > protocol in order to get a reply though.

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.
So, the IPsec sender can determine that the ESP packet can pass through to the IPsec peer by using this extended traceroute mechanism and successfully receiving the ICMP response from the final IPsec peer.

For the purpose of testing the results of ESP packets traversing the network prior to IKE negotiation, is this extended ESP traceroute mechanism enough to use? Is it still necessary to define the ESP-ping mechanism?

Regards & Thanks!
Wei PAN (潘伟)