[Teas] Re: Secdir last call review of draft-ietf-teas-applicability-actn-slicing-07

Adrian Farrel <adrian@olddog.co.uk> Fri, 09 August 2024 20:27 UTC

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, 09 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: [Teas] Re: Secdir last call review of draft-ietf-teas-applicability-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