[Secdispatch] Recapping Path Validation Work and Side Meeting

"Liuchunchi(Peter)" <liuchunchi@huawei.com> Thu, 25 January 2024 03:30 UTC

Return-Path: <liuchunchi@huawei.com>
X-Original-To: secdispatch@ietfa.amsl.com
Delivered-To: secdispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BDF4C14F6BC for <secdispatch@ietfa.amsl.com>; Wed, 24 Jan 2024 19:30:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.903
X-Spam-Level:
X-Spam-Status: No, score=-6.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=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_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=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 FZrtaSuzchr9 for <secdispatch@ietfa.amsl.com>; Wed, 24 Jan 2024 19:30:29 -0800 (PST)
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 4EA3CC14F6AC for <secdispatch@ietf.org>; Wed, 24 Jan 2024 19:30:29 -0800 (PST)
Received: from mail.maildlp.com (unknown [172.18.186.31]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4TL5qP18dJz6K8L5 for <secdispatch@ietf.org>; Thu, 25 Jan 2024 11:27:29 +0800 (CST)
Received: from lhrpeml500002.china.huawei.com (unknown [7.191.160.78]) by mail.maildlp.com (Postfix) with ESMTPS id AB3BB1404F9 for <secdispatch@ietf.org>; Thu, 25 Jan 2024 11:30:26 +0800 (CST)
Received: from canpemm500007.china.huawei.com (7.192.104.62) by lhrpeml500002.china.huawei.com (7.191.160.78) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Thu, 25 Jan 2024 03:30:25 +0000
Received: from dggpeml500018.china.huawei.com (7.185.36.186) by canpemm500007.china.huawei.com (7.192.104.62) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Thu, 25 Jan 2024 11:30:23 +0800
Received: from dggpeml500018.china.huawei.com ([7.185.36.186]) by dggpeml500018.china.huawei.com ([7.185.36.186]) with mapi id 15.01.2507.035; Thu, 25 Jan 2024 11:30:23 +0800
From: "Liuchunchi(Peter)" <liuchunchi@huawei.com>
To: secdispatch <secdispatch@ietf.org>
CC: "rdd@cert.org" <rdd@cert.org>
Thread-Topic: Recapping Path Validation Work and Side Meeting
Thread-Index: AdpPPiyuf6vJyY5sSFmSOiUK4yJ/UQ==
Date: Thu, 25 Jan 2024 03:30:23 +0000
Message-ID: <620e234ad46e4fbba13eb37ea5b1afd1@huawei.com>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.138.39.60]
Content-Type: multipart/alternative; boundary="_000_620e234ad46e4fbba13eb37ea5b1afd1huaweicom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdispatch/ThXQ3cWHFU3y1Yyz92zEbWxLJDo>
Subject: [Secdispatch] Recapping Path Validation Work and Side Meeting
X-BeenThere: secdispatch@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Security Dispatch <secdispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdispatch>, <mailto:secdispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdispatch/>
List-Post: <mailto:secdispatch@ietf.org>
List-Help: <mailto:secdispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdispatch>, <mailto:secdispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 25 Jan 2024 03:30:33 -0000

Hello SecDispatch,

In the last IETF 118 I shared work on Network Path Validation, which is to verify whether the forwarding path of a packet aligns with the predetermined control plane path. The path can be either an underlay path or a virtual path.

During the dispatch I mentioned there will be a Path Validation Side Meeting during the week, discussing problem statement, goals and interest. Roman invited for follow-up recap for outcomes, and here's a quick summary if you are interested.

Summary:
About 40 participants from 5 operators, 4 vendors and 4 research institutes joined the side meeting, agreeing the problem exists.
The main use cases that participants are interested in are: routing compliance (data transits within a jurisdiction or on top of a leased line only), securing service function chaining.
2 RTG ADs, Andrew and Jim, presented and are approved of the topic. They suggested a BoF.

Outcomes:

2 ADs sponsored the creation of the NASR Mailing List to continue the discussion. NASR stands for Network Attestation for Secure Routing. If you are interested, consider join and hear us out!

Next Steps:
We will be collecting and addressing the past feedbacks from the SM and SecDispatch, and narrow down the concrete scope and goals, for possible chartering.
Design and analysis on Proof-of-Transit mechanisms should be a first next step.

To Subscribe: https://www.ietf.org/mailman/listinfo/nasr
118 Side Meeting Materials: https://github.com/liuchunchi/path_validation_side_meeting_118

Best regards,
Peter (Chunchi) Liu