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

[Tony Rutkowski <[e-mail]>]

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, [e-mail] 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 <[e-mail]>
> *Sent:* Monday, July 8, 2019 8:36 AM
> *To:* [e-mail]; [e-mail]
> *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, [e-mail] 
> <mailto:[e-mail]> 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
>