Re: [Smart] New Version Notification for draft-mcfadden-smart-endpoint-taxonomy-for-cless-00.txt

"Arnaud.Taddei.IETF" <Arnaud.Taddei.IETF@protonmail.com> Tue, 09 July 2019 14:54 UTC

Return-Path: <Arnaud.Taddei.IETF@protonmail.com>
X-Original-To: smart@ietfa.amsl.com
Delivered-To: smart@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98998120181 for <smart@ietfa.amsl.com>; Tue, 9 Jul 2019 07:54:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.573
X-Spam-Level:
X-Spam-Status: No, score=0.573 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO=1, FROM_WORDY=2.261, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=protonmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NXClJVhlO4jQ for <smart@ietfa.amsl.com>; Tue, 9 Jul 2019 07:54:25 -0700 (PDT)
Received: from mail4.protonmail.ch (mail4.protonmail.ch [185.70.40.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFFDB120170 for <smart@irtf.org>; Tue, 9 Jul 2019 07:54:23 -0700 (PDT)
Date: Tue, 09 Jul 2019 14:54:19 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=default; t=1562684061; bh=rclR0g0fko9IIvII54LW2+J0xZn9YrVsXpQj2K3zBgM=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References: Feedback-ID:From; b=PuaNnPweg2Q1awUn1AymxHiDYc3WVsP8YV7+fTW/OYBWi8x0ar2iqZOn2HccGurYH o61Ix25miPn08qcR1noSX8bP+PwmFkqsyoV8C6gEC4t0dJgz4Ns8qtMj7CnKGfui5+ FLfk8lLhyA7pmrQQld6UVW3KVjuh/jsLLHLglKmE=
To: Tony Rutkowski <rutkowski.tony@gmail.com>
From: "Arnaud.Taddei.IETF" <Arnaud.Taddei.IETF@protonmail.com>
Cc: "mark@internetpolicyadvisors.com" <mark@internetpolicyadvisors.com>, "smart@irtf.org" <smart@irtf.org>
Reply-To: "Arnaud.Taddei.IETF" <Arnaud.Taddei.IETF@protonmail.com>
Message-ID: <5adGUOElK4PNdErBvjY24I_Tbw6FiHZG3yu0FkbgpVpFsKrlJHK-IlBGX9DRYm7Cq3WV5RakOC36FFe_nDNTYo3KrMWdg_XeKttiOjnlxwU=@protonmail.com>
In-Reply-To: <89108d73-e6a0-90fd-16ba-d1bb8e6d0958@gmail.com>
References: <156259169027.840.9135095847874577233.idtracker@ietfa.amsl.com> <019f01d53590$cf8c2a50$6ea47ef0$@internetpolicyadvisors.com> <5efde727-8e1d-9e9e-a9a4-32ce3f60e359@gmail.com> <01c301d53593$a3236c50$e96a44f0$@internetpolicyadvisors.com> <89108d73-e6a0-90fd-16ba-d1bb8e6d0958@gmail.com>
Feedback-ID: kou6vaSHQeY5dgFN9dCIYKo4z6hnnNmKuV4IBJw2wx4vSVPtftyhWUTBigri6zMJ3K1hxYJjI-3RAIGaizMt5g==:Ext:ProtonMail
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="b1_fcf0d80992571761f3d125b2046eaefe"
Archived-At: <https://mailarchive.ietf.org/arch/msg/smart/C4opm3TRxAWn_zdOGMk6wro39TQ>
Subject: Re: [Smart] New Version Notification for draft-mcfadden-smart-endpoint-taxonomy-for-cless-00.txt
X-BeenThere: smart@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Stopping Malware And Researching Threats <smart.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/smart>, <mailto:smart-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/smart/>
List-Post: <mailto:smart@irtf.org>
List-Help: <mailto:smart-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/smart>, <mailto:smart-request@irtf.org?subject=subscribe>
X-List-Received-Date: Tue, 09 Jul 2019 14:54:29 -0000

Yes I think Tony makes a point.

I don't think it introduces a new endpoint model type but we need to be mindful of the internal model representation of an endpoint with a 5G chip as it will have a number of side effects for defining the "attack surface" both internally and externally to the endpoint.

In fact if you take the perspective of say an employee in a company, from a zero trust perspective, 5G will actually have a major effect on the way organizations will have to completely change their security models and will have to reconsider their approach to endpoints. Think the day when Apple will ship a MacBookPro with no Wifi and a 5G chip.

I actually can see the effect beyond 3GPP and ETSI as the problem is now coming deeper even in ITU-T SG17. The past 2 ultra intense weeks in China including for Q7/17 and Q8/17 opened my eyes on the relevance of CLESS even there and especially for zero trust in 5G contexts.

Hope this helps

Sent with [ProtonMail](https://protonmail.com) Secure Email.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Monday 8 July 2019 20:06, Tony Rutkowski <rutkowski.tony@gmail.com> wrote:

> Full Stand Alone (SA) 5G specified by Rel. 16 will consist of fully virtualised architectures orchestrated on-demand using NFV based network slicing among virtualised Network Functions.  Given this reality and that the slices will be using different network protocols, including E2E Ethernet, and instantiating architectures and functions for periods of time using many different NF identifiers, it isn't clear how this comports with the typically highly rigid TCP/IP centric model.  (Indeed, it isn't clear that the term "internet" has meaning.)
>
> In a 5G/NFV environment, enormously diverse Network Functions will exist all over the instantiated architectures - including on end user equipment.  The interesting question is whether a taxonomy for NFs exists, and whether your draft should use the conceptualisation in the interest of accommodating 5G.  It's worth noting that useful work along those lines exists out there.  Some is found in NFV ISG specifications, e.g., ETSI GS NFV-IFA 014.  Other material can be found at IETF meetings.  See, e.g., https://www.ietf.org/proceedings/92/slides/slides-92-rtgarea-3.pdf
>
> CLESS is certainly headed in the right direction - certainly in a 5G world.
>
> --tony
>
> On 08-Jul-19 9:47 AM, mark@internetpolicyadvisors.com wrote:
>
>> Those are pretty useful questions. I’ve gotten the same comments from others off-list.  The scoping of CLESS is something we should try to make progress on the list.
>>
>> The 5G question is a little different for me. Do you think that 5G introduces categories of endpoints that would not be present in existing, or other, transport infrastructures?  If so, I’m happy to amend the text.
>>
>> Thanks,
>>
>> mark
>>
>> From: Tony Rutkowski [<rutkowski.tony@gmail.com>](mailto:rutkowski.tony@gmail.com)
>> Sent: Monday, July 8, 2019 8:36 AM
>> To: mark@internetpolicyadvisors.com; smart@irtf.org
>> Subject: Re: [Smart] New Version Notification for draft-mcfadden-smart-endpoint-taxonomy-for-cless-00.txt
>>
>>> But, there's an important question here. CLESS specifically rules out network infrastructure in its discussion. Should the taxonomy for CLESS incorporate endpoints that are part of the network infrastructure? Said a different way: is network infrastructure out of scope for CLESS?
>>
>> Do you intend this to be 5G relevant?
>>
>> -tr
>>
>> On 08-Jul-19 9:26 AM, mark@internetpolicyadvisors.com wrote:
>>
>>> A new version of I-D, draft-mcfadden-smart-endpoint-taxonomy-for-cless-00.txt
>>>
>>> has been successfully submitted by Mark McFadden and posted to the IETF repository.
>>>
>>>
>>>
>>> Name:            draft-mcfadden-smart-endpoint-taxonomy-for-cless
>>>
>>> Revision: 00
>>>
>>> Title:           Endpoint Taxonomy for CLESS
>>>
>>> Document date:   2019-07-08
>>>
>>> Group:           Individual Submission
>>>
>>> Pages:           15
>>>
>>> URL:
>>> https://www.ietf.org/internet-drafts/draft-mcfadden-smart-endpoint-taxonomy-for-cless-00.txt
>>>
>>> Status:
>>> https://datatracker.ietf.org/doc/draft-mcfadden-smart-endpoint-taxonomy-for-cless/
>>>
>>> Htmlized:
>>> https://tools.ietf.org/html/draft-mcfadden-smart-endpoint-taxonomy-for-cless-00
>>>
>>> Htmlized:
>>> https://datatracker.ietf.org/doc/html/draft-mcfadden-smart-endpoint-taxonomy-for-cless
>>>
>>>
>>>
>>>
>>>
>>> Abstract:
>>>
>>>    A separate document [I-D:draft-taddei-smart-cless-introduction]
>>>
>>>    (CLESS) attempts to establish the capabilities and limitations of
>>>
>>>    endpoint-only security solutions and explore potential alternative
>>>
>>>    approaches. That document discusses endpoints in general terms. It
>>>
>>>    has been suggested that there are classes of endpoints that have
>>>
>>>    different characteristics. Those classes may have completely
>>>
>>>    different threat landscapes and the endpoints may have completely
>>>
>>>    different security capabilities. In support of the work on CLESS,
>>>
>>>    this document provides a taxonomy of endpoints that is intended to
>>>
>>>    provide a foundation for further work on CLESS and research on
>>>
>>>    approaches to providing endpoint security alternatives in a diverse
>>>
>>>    group of settings.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.
>>>
>>>
>>>
>>> The IETF Secretariat