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

Adrian Farrel <adrian@olddog.co.uk> Sat, 10 August 2024 14:10 UTC

Return-Path: <adrian@olddog.co.uk>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9B75C15108B; Sat, 10 Aug 2024 07:10:24 -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 g5sSPNwaO87V; Sat, 10 Aug 2024 07:10:20 -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 5630FC14F604; Sat, 10 Aug 2024 07:10:16 -0700 (PDT)
Received: from vs4.iomartmail.com (vs4.iomartmail.com [10.12.10.122]) by mta7.iomartmail.com (8.14.7/8.14.7) with ESMTP id 47AEAAiC002917; Sat, 10 Aug 2024 15:10:11 +0100
Received: from vs4.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 964B24604C; Sat, 10 Aug 2024 15:10:11 +0100 (BST)
Received: from vs4.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 93B9D4604B; Sat, 10 Aug 2024 15:10:11 +0100 (BST)
Received: from asmtp1.iomartmail.com (unknown [10.12.10.248]) by vs4.iomartmail.com (Postfix) with ESMTPS; Sat, 10 Aug 2024 15:10:11 +0100 (BST)
Received: from LAPTOPK7AS653V (82-69-109-75.dsl.in-addr.zen.co.uk [82.69.109.75]) (authenticated bits=0) by asmtp1.iomartmail.com (8.14.7/8.14.7) with ESMTP id 47AEABKX011494 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 10 Aug 2024 15:10:11 +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> <05d201daea9a$91419b30$b3c4d190$@olddog.co.uk> <CO1PR13MB49207C8212E2F8974AD4AB8E85BA2@CO1PR13MB4920.namprd13.prod.outlook.com>
In-Reply-To: <CO1PR13MB49207C8212E2F8974AD4AB8E85BA2@CO1PR13MB4920.namprd13.prod.outlook.com>
Date: Sat, 10 Aug 2024 15:10:10 +0100
Organization: Old Dog Consulting
Message-ID: <061701daeb2f$033f6ed0$09be4c70$@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/n6KYGtJaXv8jVl8zh7iqeoaTgJU516dALqZ7hexgeBycA==
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=GPbdlRNwzsAuRc65kDwX9DBDzuxZUbP4QbiZXWJjdyc=; b=vfS oV0W9edwmWzyz+uFzWAU2RVcT3B+O2jNKFFuGXVEEbHDk1n0MY3yzax3Z2TiD+NM dFgSIoaD+A5Wz2mRKq/36Nm7NNxEDmkd06b/TG+P0T4z+1OYgaGko3752yjAC/48 MmUYOeAM9uLRNCyu4N8gux/jvhS/tGdwy+aCxx1XESP2wTGwpNFVv490gpoGkTLh yv7aGBozr4UntyCF4XeBDiqBLrYyIavBmYP0x9v17YX5pPtvgdr0v3v3B85034/i K9XeFpkM2OtjuteAiscwUyeDR1cBkJG3UAJmaGhIN7uRodk/rWWVUywvgE2uCdxf lvqXm/PQ4wpOUYEdSSA==
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--17.784-10.0-31-10
X-imss-scan-details: No--17.784-10.0-31-10
X-TMASE-Version: IMSVA-9.1.0.2090-9.0.1002-28352.003
X-TMASE-Result: 10--17.783700-10.000000
X-TMASE-MatchedRID: vEvJ7Rh1lGjxIbpQ8BhdbI61Z+HJnvsOC/ExpXrHizwdpIqih5+5Ipyu cBtJ3Xx47jUA7Y9PwrRbL6dJhuJhKwW+fKOFXI1dxDiakrJ+Spmu2GmdldmiUADVt9UpyMklZlj 9F1etQo3LtTWpL2rR9KomvGb7szbyBQDlYgP69UdAL3S+E86WTZIONJNyvJzUteXjSBMYnmkNEI 8jb8yN6f7Xxu/Uiyg7Js/WYzrVqqsGZxaaxakfo0H0jmDpcSmLvykBikB9a0CueqlDxh8ToTNvE 6dy8VKbXqciHM+m00kKB2ISl8Ib4NMsGRKm0bkERZfQN+FVqbD+Ngp31WVSjkJsNXD374+pl2iS dQmYgPAzvBERQ2ixH1qNEgaKF0u0N+dRxayfytSeAiCmPx4NwFkMvWAuahr8m5N2YHMD0b8Myrf P9j+C1SAHAopEd76vtpTuebENwS5oIkS76O1dfPprrXQRozaj1Yy/rfW48B1bgyYGyydvUw==
X-TMASE-SNAP-Result: 1.821001.0001-0-1-22:0,33:0,34:0-0
Message-ID-Hash: Z5SYW32WTF4TBXKPFOBIOCZ6YGEJLRAK
X-Message-ID-Hash: Z5SYW32WTF4TBXKPFOBIOCZ6YGEJLRAK
X-MailFrom: adrian@olddog.co.uk
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-secdir.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: [secdir] Re: Secdir last call review of draft-ietf-teas-applicability-actn-slicing-07
List-Id: Security Area Directorate <secdir.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/UdKTJFyA2NDn0D-2eGWmP9okibg>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Owner: <mailto:secdir-owner@ietf.org>
List-Post: <mailto:secdir@ietf.org>
List-Subscribe: <mailto:secdir-join@ietf.org>
List-Unsubscribe: <mailto:secdir-leave@ietf.org>

Thanks again, Linda.

>> 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.

[Linda] sometimes a customer doesn't have the ability to verify the security services. That is why they  buy  security services from their trusted providers. 

The point is that the customer *never* has the ability to verify a security service. They hand over their unprotected traffic to the service provider on the understanding that the traffic will be protected edge-to-edge and delivered unprotected at the destination.

So the crunch is "trusted provider." The level of trust depends, of course, on the nature of the traffic, the trustworthiness of the provider, and the nervousness of the customer.
However, a customer that wishes to be *certain* that the traffic is adequately protected must take responsibility themselves.

> 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.

[Linda] It might be better to say something along the line of  Shared Responsibility for end to end security when using secure network slices. 

I disagree. Even if the protection is delegated to another party, the responsibility for protecting the traffic lies with the owner of the traffic. 

>> - 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.

At this point, what do you say we leave this to the Sec AD to decide whether or not to follow-up on this point?

A