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

Michael Richardson <mcr+ietf@sandelman.ca> Wed, 27 March 2024 01: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 E17C5C14CE44 for <ipsec@ietfa.amsl.com>; Tue, 26 Mar 2024 18:12:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.106
X-Spam-Level:
X-Spam-Status: No, score=-7.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_DNSWL_HI=-5, 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 0VQK3JaY7DIJ for <ipsec@ietfa.amsl.com>; Tue, 26 Mar 2024 18:12:17 -0700 (PDT)
Received: from relay.sandelman.ca (relay.cooperix.net [IPv6:2a01:7e00:e000:2bb::1]) (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 019B1C14F618 for <ipsec@ietf.org>; Tue, 26 Mar 2024 18:12:16 -0700 (PDT)
Received: from dyas.sandelman.ca (60-240-91-174.static.tpgi.com.au [60.240.91.174]) by relay.sandelman.ca (Postfix) with ESMTPS id 3EC4C1F448; Wed, 27 Mar 2024 01:12:13 +0000 (UTC)
Authentication-Results: relay.sandelman.ca; dkim=pass (2048-bit key; secure) header.d=sandelman.ca header.i=@sandelman.ca header.b="HkESGtL/"; dkim-atps=neutral
Received: by dyas.sandelman.ca (Postfix, from userid 1000) id D181DA1914; Wed, 27 Mar 2024 12:12:08 +1100 (AEDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=sandelman.ca; s=dyas; t=1711501928; bh=doWJgopSLbhCHmzPK6sIZhsYHiuJPEfMY/M8U+fItcM=; h=From:To:Subject:In-reply-to:References:Date:From; b=HkESGtL/K1okXxOHesd7hccryZUd627w5uxbMMJ34DFGYxLnsEVqmyhhMH6CUF0X0 ltl7s7ch1oqy2J4NLwhxx/Y5CvsUP/6b0XUnskjAFsGlNrbNRpQum+UvABurx5uY8k 6VSlJDvluDYp3V0O4eE/O2Gp/KPYJnsH4YXJxUIHI+VAMeMdcEpMux3mMEeWR2UaGe hv0Lzl2Bue526WrWVYcdfCEbXRBnbN4Cu8pVxHlmw8VNh8MofppaGKB+Q/G3YoJ8lY mHaGVkOZ/cxgip1T6i+kSTkpp4I1zlqC666SGBhg1kk7OcS94aCeNDCXJRI3HIsrVe ZS3BPs7sCMB1g==
Received: from dyas (localhost [127.0.0.1]) by dyas.sandelman.ca (Postfix) with ESMTP id CF58DA190E; Wed, 27 Mar 2024 12:12:08 +1100 (AEDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: "Panwei (William)" <william.panwei@huawei.com>, "ipsec@ietf.org" <ipsec@ietf.org>
In-reply-to: <4b44a218c77a49edbaecd3b524dbaac7@huawei.com>
References: <170922023791.21652.13338059706655424526@ietfa.amsl.com> <CAFU7BAQuNkHDRidjQqGbXySKJ1FCRKuAksDa0BHsvfGeG45k6g@mail.gmail.com> <4b44a218c77a49edbaecd3b524dbaac7@huawei.com>
Comments: In-reply-to "Panwei (William)" <william.panwei@huawei.com> message dated "Tue, 26 Mar 2024 09:24:12 -0000."
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.3
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Date: Wed, 27 Mar 2024 12:12:08 +1100
Message-ID: <476994.1711501928@dyas>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/SnW2d6b1g_-qomRthxO0mQLFASs>
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: Wed, 27 Mar 2024 01:12:23 -0000

Panwei (William) <william.panwei@huawei.com> wrote:
    > I feel that the problem of IPv6 ESP traverse failure, as described in
    > the draft and presentation slides, is because of NAT. IKEv2 already

I'm not sure I understand how you get this from the Problem Statement.
Clearly, we need to clarify the purpose.
It's not about detecting NAT, it's about determining if ESP will work or not.

    > supports the detection of NAT. After the detection of NAT, the peers
    > can use IP + UDP (4500) + ESP to traverse the NAT. Are there some use
    > cases that this existing solution doesn't work and this draft tries to
    > solve? Or, are there some use cases that IKEv2 fails in detecting the
    > existence of NAT?

It's not about detecting or avoiding *NAT* per-se.
We prefer not to have to encapsulate.

I think that you are over-estimating the competency of some operators: the
experience with IPv6 is often not there.   Even when it is, not all equipment
vendors are equally competent at implementing/documenting things.

Imagine a situation where IPsec will be used in a (sub)site to site
configuration.  For instance, between a billing system and an outsourced
credit card processor. {Not replacing TLS, but in addition to}
The administrators of the billing system request "IPsec" from their (inhouse)
network operator, and the operator looks up their howto list, and enables UDP
port 500 and 4500, because that's what IPv4 wanted.
Now the billing system people wonder why the it seems to work, but in fact no
traffic gets through.  It can be very hard to debug.

The purpose of this protocol is to allow that debugging.
The network operator people, who are not allowed into the billing system, can
instead use an ESPping utility to send ESP traffic, adjusting their firewalls
until they understand that UDP!=ESP.

We also realized that one can write/modify traceroute to use ESPping to
determine how far ESP actually gets.

There are also situations where there are ECMP routers in the way which
simply do not know what to do with ESP.  A network operator could introduce
such a sytem into a previously working site-to-site VPN and suddenly things
stop working, or get poor performance.

--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-                      *I*LIKE*TRAINS*