[nasr] TBDs in NASR architecture: can network slice APIs help?

Michael Richardson <mcr+ietf@sandelman.ca> Fri, 16 August 2024 20:30 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: nasr@ietfa.amsl.com
Delivered-To: nasr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C49BDC169406 for <nasr@ietfa.amsl.com>; Fri, 16 Aug 2024 13:30:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.108
X-Spam-Level:
X-Spam-Status: No, score=-2.108 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, 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=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 3gL5N6kR0BOF for <nasr@ietfa.amsl.com>; Fri, 16 Aug 2024 13:30:54 -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 ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C17CC1654F2 for <nasr@ietf.org>; Fri, 16 Aug 2024 13:30:53 -0700 (PDT)
Authentication-Results: relay.sandelman.ca; dkim=pass (2048-bit key; secure) header.d=sandelman.ca header.i=@sandelman.ca header.a=rsa-sha256 header.s=dyas header.b=GAgEhOQ5; dkim-atps=neutral
Received: from dyas.sandelman.ca (unknown [132.205.230.6]) by relay.sandelman.ca (Postfix) with ESMTPS id 4CC2E1F483 for <nasr@ietf.org>; Fri, 16 Aug 2024 20:29:02 +0000 (UTC)
Received: by dyas.sandelman.ca (Postfix, from userid 1000) id 07EF4A003F; Fri, 16 Aug 2024 16:30:50 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=sandelman.ca; s=dyas; t=1723840250; bh=1R/p+NoSDa5HQkzVZKVwtfxw0gxp1QDLZvJOP54CSzw=; h=From:To:Subject:Date:From; b=GAgEhOQ56uEJ0LDox2aLDN+mNsChrjjMiSBOX8KjP4NCAiDcwl/UpcYMjojUl2dqe unfxddQJQkZ/7iE1WBx7j31AYsUKPD/4JJakoT+qDpR7digl2Iv9/QhIsa2mNu2a7n JnhxeauOLMdTGZLMVxuRJhLAhYsZl7TDThauNmmhANpQTTRxWGvdp/SApg1Mf8nxyd P7031M6a/ty58MZMNbj/bWttq45oTiz4UVt/4zcYuY6Tado5q2nYLr8uj+xeY5oBeB jEQjiGEnnmCPAsKkysB4fkzozZGl3kqeoxI76FltZxdBcqqKgxq/V7WTW8SsCXOyG5 DhfrDs+8BZlrQ==
Received: from dyas (localhost [127.0.0.1]) by dyas.sandelman.ca (Postfix) with ESMTP id 05BEEA002B for <nasr@ietf.org>; Fri, 16 Aug 2024 16:30:50 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: nasr@ietf.org
X-Attribution: mcr
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: Fri, 16 Aug 2024 16:30:50 -0400
Message-ID: <879537.1723840250@dyas>
Message-ID-Hash: UBXMBX2PWHGAV47ECFUEE6RIICPZOTMG
X-Message-ID-Hash: UBXMBX2PWHGAV47ECFUEE6RIICPZOTMG
X-MailFrom: mcr+ietf@sandelman.ca
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [nasr] TBDs in NASR architecture: can network slice APIs help?
List-Id: Network Attestation for Secure Routing <nasr.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/nasr/EVMkGzN5PvKe3SOB0akznSQDISU>
List-Archive: <https://mailarchive.ietf.org/arch/browse/nasr>
List-Help: <mailto:nasr-request@ietf.org?subject=help>
List-Owner: <mailto:nasr-owner@ietf.org>
List-Post: <mailto:nasr@ietf.org>
List-Subscribe: <mailto:nasr-join@ietf.org>
List-Unsubscribe: <mailto:nasr-leave@ietf.org>

One of the TBDs is the customer/orchestrator API.
I wonder if the 3GPP TS 22.261  mechanism would be a good base for this API.
It seems like a secure path is really a attribute of a network slice.
Probably a new "SST value" might be required.

Clearly, there are no specific "UE" involved, but probably the entire Customer A.
(or part of it).

I don't know much about it, I just read an overview article, and the
connection seemed interesting.  So tell me why I'm wrong.

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