Re: [IPsec] I-D Action: draft-he-ipsecme-vpn-shared-ipsecsa-00.txt

Michael Richardson <mcr+ietf@sandelman.ca> Wed, 20 March 2024 09:22 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 8C1C4C1519A9 for <ipsec@ietfa.amsl.com>; Wed, 20 Mar 2024 02:22:24 -0700 (PDT)
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_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable 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 XIAT0vp461DV for <ipsec@ietfa.amsl.com>; Wed, 20 Mar 2024 02:22:19 -0700 (PDT)
Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) (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 E8078C151095 for <ipsec@ietf.org>; Wed, 20 Mar 2024 02:22:18 -0700 (PDT)
Received: from dyas.sandelman.ca (dhcp-8677.meeting.ietf.org [31.133.134.119]) by relay.sandelman.ca (Postfix) with ESMTPS id 325A21F4A8; Wed, 20 Mar 2024 09:22:16 +0000 (UTC)
Authentication-Results: relay.sandelman.ca; dkim=pass (2048-bit key; secure) header.d=sandelman.ca header.i=@sandelman.ca header.b="jBztc9xt"; dkim-atps=neutral
Received: by dyas.sandelman.ca (Postfix, from userid 1000) id ADB5FA0C77; Wed, 20 Mar 2024 19:22:12 +1000 (AEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=sandelman.ca; s=dyas; t=1710926532; bh=SDgwIbiI4Mmt9t59BEVnMRg1lSDincIWRHQl7NBm3zQ=; h=From:To:cc:Subject:In-reply-to:References:Date:From; b=jBztc9xtmrQ3SQ++tg62Y/foYK9eyb69Eqs22I+uJOM/Mz7qq+3/jZf3cz47Cd7i7 5SqTkES8gH3wNWUzTJ4LS2sO6zmqHKg6JWqMaEfKmcwsNpwotqVoBETsq0sjedZPwv byAjYgFFH6mfv3Nj9P/aGCJPjhLUa/D0HzE8OyFVKODjlOKmQjCpvE7AsQczqyvH5O A05VaUnxoCgi+mybgeLcEJPIQCeQ6+jrQSibr2wDMftkJoQCMRe3UZiqMQwtxTZHb0 9ulJ6Dah4l7L/BLnXivc50gxmm1q0sswaYXkO5rGxVDgA4biWMcUob0RJB4jp22xer XoZuBfR+ztg3w==
Received: from dyas (localhost [127.0.0.1]) by dyas.sandelman.ca (Postfix) with ESMTP id AB24AA0A82; Wed, 20 Mar 2024 19:22:12 +1000 (AEST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: "Panwei (William)" <william.panwei=40huawei.com@dmarc.ietf.org>
cc: Steffen Klassert <steffen.klassert@secunet.com>, Paul Wouters <paul@nohats.ca>, "ipsec@ietf.org WG" <ipsec@ietf.org>
In-reply-to: <a80bed7fcd02445d8a75555b2764c3a4@huawei.com>
References: <29bca8d122844180afc21cd6b353159a@huawei.com> <4C637D68-CD0C-47C1-8D34-36D01A2DBF1F@aiven.io> <e7bc176dafcd4a719b84842b685a9fc5@huawei.com> <c6dc7d13-2c1c-f5c7-290e-34a88a21d103@nohats.ca> <ZfP5SxlCueJ/aQt/@gauss3.secunet.de> <a80bed7fcd02445d8a75555b2764c3a4@huawei.com>
Comments: In-reply-to "Panwei \(William\)" <william.panwei=40huawei.com@dmarc.ietf.org> message dated "Wed, 20 Mar 2024 08:04:41 +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, 20 Mar 2024 19:22:12 +1000
Message-ID: <167439.1710926532@dyas>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/xHEIADpDR59-758HICOjx4qOxd4>
Subject: Re: [IPsec] I-D Action: draft-he-ipsecme-vpn-shared-ipsecsa-00.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, 20 Mar 2024 09:22:24 -0000

Panwei \(William\) <william.panwei=40huawei.com@dmarc.ietf.org> wrote:
    > At yesterday's meeting, I think people basically understood and
    > accepted the problem statement itself, but also raised different ideas
    > regarding to the solutions.  We'll try to do more analysis and
    > comparison of possible solutions, including what you suggested.

I think that one thing that is unclear to me is whether the different RANs
can tolerate that all the different traffic share the same *IKE* SA.

The next level is whether or not they can tolerate being in the same CHILD
SA.  We could put the "VPN ID" at another layer (inside the common tunnel),
such as some kind of L3VPN, GRE, VXLAN.

    > we'd like to know more if it's OK.  Switching to a new protocol is
    > still a reasonable solution for us, although it has pains.  Developing
    > a new protocol in IETF will cost time, we'd like to adopt the new
    > protocol after it's standardized.  But we need to solve our problem

I don't think you need any new protocols, but maybe new ways to combine
existing protocols.  For instance, some IKEv2 support for configuring VXLAN.
But, this depends upon the *security* and traffic isolation that you need.

For instance, do you have issues of traffic accounting between the RANs that
occurs on the outside (ESP) packets.

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