Return-Path: <adrian@olddog.co.uk>
X-Original-To: teas@ietfa.amsl.com
Delivered-To: teas@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by ietfa.amsl.com (Postfix) with ESMTP id 7F092C14F6A0;
	Fri,  9 Aug 2024 13:27:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.105
X-Spam-Level: 
X-Spam-Status: No, score=-2.105 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_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=olddog.co.uk
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 0dabm2aXAlKQ; Fri,  9 Aug 2024 13:27:43 -0700 (PDT)
Received: from mta7.iomartmail.com (mta7.iomartmail.com [62.128.193.157])
	(using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by ietfa.amsl.com (Postfix) with ESMTPS id DDE33C14F686;
	Fri,  9 Aug 2024 13:27:40 -0700 (PDT)
Received: from vs2.iomartmail.com (vs2.iomartmail.com [10.12.10.123])
	by mta7.iomartmail.com (8.14.7/8.14.7) with ESMTP id 479KRZkD030504;
	Fri, 9 Aug 2024 21:27:35 +0100
Received: from vs2.iomartmail.com (unknown [127.0.0.1])
	by IMSVA (Postfix) with ESMTP id D63B84604B;
	Fri,  9 Aug 2024 21:27:34 +0100 (BST)
Received: from vs2.iomartmail.com (unknown [127.0.0.1])
	by IMSVA (Postfix) with ESMTP id C99DB46048;
	Fri,  9 Aug 2024 21:27:34 +0100 (BST)
Received: from asmtp2.iomartmail.com (unknown [10.12.10.249])
	by vs2.iomartmail.com (Postfix) with ESMTPS;
	Fri,  9 Aug 2024 21:27:34 +0100 (BST)
Received: from LAPTOPK7AS653V (82-69-109-75.dsl.in-addr.zen.co.uk
 [82.69.109.75])
	(authenticated bits=0)
	by asmtp2.iomartmail.com (8.14.7/8.14.7) with ESMTP id 479KRYq0003445
	(version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO);
	Fri, 9 Aug 2024 21:27:34 +0100
From: "Adrian Farrel" <adrian@olddog.co.uk>
To: "'Linda Dunbar'" <linda.dunbar@futurewei.com>, <secdir@ietf.org>
References: 
 <172322405122.255490.10909933045876420270@dt-datatracker-6df4c9dcf5-t2x2k>
In-Reply-To: 
 <172322405122.255490.10909933045876420270@dt-datatracker-6df4c9dcf5-t2x2k>
Date: Fri, 9 Aug 2024 21:27:33 +0100
Organization: Old Dog Consulting
Message-ID: <05d201daea9a$91419b30$b3c4d190$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Content-Language: en-gb
Thread-Index: AQId/n6KYGtJaXv8jVl8zh7iqeoaTrGZNqZg
X-Originating-IP: 82.69.109.75
X-Thinkmail-Auth: adrian@olddog.co.uk
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=olddog.co.uk; h=reply-to
	:from:to:cc:references:in-reply-to:subject:date:message-id
	:mime-version:content-type:content-transfer-encoding; s=
	20221128; bh=eEW1ZFJ6WxTWZ2lxwZVl4eGyBtU8FPMZQazqmnjjybo=; b=DIW
	uMQ+zuOeBA/rt1nzkBqRlQoXOhUJtJhNJIWxFIJqxwOiizMWsAIC7Ggnc+X/rJ2S
	5la7LezTGbLujd/QKxzrt0rKPwfreWxnUSL8va1NiptVH3ABvt76JLdGxnOdzFXa
	dNpldlD1oo9pr3NsUBeeAs37qF9nGQEJTbBBnXgZvFM0RyDjrA3bdqHuDFa632xD
	m6ylb1U8kLrMDNASqPYzv1R2M4EmlJBkF0R7RzZ1i0mntfRveqiuFaFsITL4vuCo
	CK9vXGWbGEr6CzdG82JEIBWd5z2aWrJ/F54u8r4hlNk9c2fIezmoh6kn9aBc/BEl
	2v8Gkw7hB8tMMd6bZaw==
X-TM-AS-GCONF: 00
X-TM-AS-Product-Ver: IMSVA-9.1.0.2090-9.0.0.1002-28352.003
X-TM-AS-Result: No--12.562-10.0-31-10
X-imss-scan-details: No--12.562-10.0-31-10
X-TMASE-Version: IMSVA-9.1.0.2090-9.0.1002-28352.003
X-TMASE-Result: 10--12.562300-10.000000
X-TMASE-MatchedRID: +f/wAVSGjujxIbpQ8BhdbAEaayJtYZNt82SgwNf6SK68MakitBkj0e1v
	YggOx1AL+h4WVqRDM2QYkqRHHX9i8PSQviw2bOGqQQ5+hY6u+47UoMiU4Mi75Y0nZyQtGDZR2V8
	+upK1VKNux6gKtWqXz52zHCpmWHvu9RYy+aTqMwW55gHWZJfOvx6OXxdRGLx87lLGlTAoyS1sLM
	ulItaRHCM8Apv/cf4RQ3OJUoK6MKVHRiy/ZowS2Rd8ENHLtW0zKTREEsKJaMkgxiy2xJZXvZsay
	Yvu9xQu99RfPuwPDMhZLY3A+xQ+0locitgq/alOZfifB9P/JqsBMynvs0jxZRGHFrgBwnSro8WM
	kQWv6iXh7z8MHC5cZ3QdJ7XfU86eOwBXM346/+yqZQywnx/0fmdvsX7iWGqTgsrOO1DgH8k/P0D
	DOhlvXf24KUuwCTry
X-TMASE-SNAP-Result: 1.821001.0001-0-1-22:0,33:0,34:0-0
Message-ID-Hash: 35ND2E6GSKJKUIA6S5K2ECEBN3YAXOVY
X-Message-ID-Hash: 35ND2E6GSKJKUIA6S5K2ECEBN3YAXOVY
X-MailFrom: adrian@olddog.co.uk
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency;
 loop; banned-address; member-moderation; header-match-teas.ietf.org-0;
 nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size;
 news-moderation; no-subject; digests; suspicious-header
CC: draft-ietf-teas-applicability-actn-slicing.all@ietf.org,
 last-call@ietf.org, teas@ietf.org
X-Mailman-Version: 3.3.9rc4
Precedence: list
Reply-To: adrian@olddog.co.uk
Subject: =?utf-8?q?=5BTeas=5D_Re=3A_Secdir_last_call_review_of_draft-ietf-teas-applic?=
	=?utf-8?q?ability-actn-slicing-07?=
List-Id: Traffic Engineering Architecture and Signaling working group
 discussion list <teas.ietf.org>
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/teas/U6xddpo0S4tboUkGvV8ZE2JCUhY>
List-Archive: <https://mailarchive.ietf.org/arch/browse/teas>
List-Help: <mailto:teas-request@ietf.org?subject=help>
List-Owner: <mailto:teas-owner@ietf.org>
List-Post: <mailto:teas@ietf.org>
List-Subscribe: <mailto:teas-join@ietf.org>
List-Unsubscribe: <mailto:teas-leave@ietf.org>

Linda,

Thank you so much for casting your eyes over our document.

Some thoughts in line...

> I have reviewed this document as part of the SEC area directorate's =
ongoing
> effort to review all IETF documents being processed by the IESG.  =
These
> comments were written primarily for the benefit of the Security area =
directors.
> Document editors and WG chairs should treat these comments just like =
any other
> last-call comments
>
> Section 6, paragraph 4 highlights the customer's responsibility for =
end-to-end
> security, even when utilizing secure network slices as a service =
provided by
> their service providers. This raises several questions:
>
> - Does the document imply that customers should not trust the secure =
network
>  slices offered by service providers?

Essentially, yes. No one should trust a security service that they =
cannot, themselves, verify.

However, the text doesn't go quite that far. It says that the customer =
is responsible for ensuring the privacy and integrity of their traffic. =
If a customer chooses to do that by subscribing to a service that claims =
to provide the necessary measures, then the customer is free to do so.

> - It might be beneficial for the document to specify criteria or =
guidelines
> that customers can use to evaluate the security and integrity of =
secure network
> slices as a service. Providing such criteria would help customers make =
informed
> decisions and ensure they meet their security requirements.

It might be, although that is probably way beyond the scope or =
competence of the authors.

If pushed, I would say that no privacy or integrity service that cannot =
be independently verified by the customer can be trusted.

Cheers,
Adrian



