Re: [Apn] why it is necessary to differentiate the security concern for 5G Vertical Networks from the grand Internet ( was RE: Application-Aware Networking (APN) focused interim

Michael Richardson <mcr+ietf@sandelman.ca> Fri, 11 June 2021 16:43 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: apn@ietfa.amsl.com
Delivered-To: apn@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3BBA3A102A; Fri, 11 Jun 2021 09:43:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 yusyDK69NYc1; Fri, 11 Jun 2021 09:43:52 -0700 (PDT)
Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7CB33A1029; Fri, 11 Jun 2021 09:43:52 -0700 (PDT)
Received: from dooku.sandelman.ca (cpe788a207f397a-cmbc4dfb96bb50.sdns.net.rogers.com [174.116.121.43]) by relay.sandelman.ca (Postfix) with ESMTPS id 63F881F47B; Fri, 11 Jun 2021 16:43:50 +0000 (UTC)
Received: by dooku.sandelman.ca (Postfix, from userid 179) id F38121A02D3; Fri, 11 Jun 2021 12:43:48 -0400 (EDT)
Received: from dooku (localhost [127.0.0.1]) by dooku.sandelman.ca (Postfix) with ESMTP id F0F761A0035; Fri, 11 Jun 2021 12:43:48 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: "Pengshuping (Peng Shuping)" <pengshuping@huawei.com>
cc: linda 73504 <ldunbar@futurewei.com>, "rtgwg@ietf.org" <rtgwg@ietf.org>, "apn@ietf.org" <apn@ietf.org>
In-reply-to: <162895a0861a44b3845073effa25befa@huawei.com>
References: <PH0PR13MB4922A88EFE55FA2398651301A9239@PH0PR13MB4922.namprd13.prod.outlook.com> <c78e1bae-042b-e0bb-be4a-c2223d039b11@sandelman.ca> <PH0PR13MB4922EF9BAC0CCC4BB8CC38E6A93B9@PH0PR13MB4922.namprd13.prod.outlook.com> <13268.1622832941@localhost> <PH0PR13MB4922C32FD7938D6C6391C98FA93B9@PH0PR13MB4922.namprd13.prod.outlook.com> <362.1622914856@localhost> <162895a0861a44b3845073effa25befa@huawei.com>
Comments: In-reply-to "Pengshuping (Peng Shuping)" <pengshuping@huawei.com> message dated "Mon, 07 Jun 2021 01:50:26 -0000."
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.3
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Date: Fri, 11 Jun 2021 12:43:48 -0400
Message-ID: <111762.1623429828@dooku>
Archived-At: <https://mailarchive.ietf.org/arch/msg/apn/CEypnGcKwxI3yQLwJn5YiZ-LoAg>
Subject: Re: [Apn] why it is necessary to differentiate the security concern for 5G Vertical Networks from the grand Internet ( was RE: Application-Aware Networking (APN) focused interim
X-BeenThere: apn@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Application-aware Networking <apn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apn>, <mailto:apn-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/apn/>
List-Post: <mailto:apn@ietf.org>
List-Help: <mailto:apn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apn>, <mailto:apn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 11 Jun 2021 16:43:58 -0000

Pengshuping (Peng Shuping) <pengshuping@huawei.com> wrote:
    > 3. RSVP+Diffserv should have been able to provide differentiated
    > services to some level. However, RSVP replies on end-to-end signaling
    > and it is stateful, while APN relies on the attribute carried in the
    > packet indicating the traffic classification and service provisioning
    > which allows a much better scalability.

*diffedge* is RSVP signaling from the end station (or encapsulating
 node) to the *edge* of that network, at which point there is a device which
 translates the RSVP into diffserv.
 This means that the core of the network does not need to scale, nor keep  state.
 This also means that the diffserv marks are applied by a device which is
 trusted by the core to mark correctly.

    > The traditional services does not have too much differentiated service
    > requirements, so COS/DSCP may be enough. But now we have 5G, the eMBB,
    > uRLLC, and mMTC as well as the various verticals (e.g. Smart City,
    > Smart Grid, V2X, Industry IoT, etc.) have very diverse service
    > requirements, which caused the granularity provided by even DSCP not
    > enough.

This is an assertion which I still haven't seen explained in the use cases.
While many networks use like four diffserv code points, and use them for the
default value, the 64 diffserv code points are intended to be a palette.

    > Meanwhile the network capabilities enabling differentiated
    > services, such as SR policies and network slicing (hundreds to
    > thousands), have been evolving.

okay, but I still don't understand how network slicing matters, except that
it creates a lot more queues to put things into.

    > So there is a mismatch between such 5G
    > differentiated service requirements and the advanced network
    > capabilities, wherein APN fits in the gap. The APN attribute could be
    > used to express the fine granularity service requirements of the 5G or
    > vertical services.

How fine?  you said that end stations are not involved.
How how is the classication done in order to find this fine structure?
In the meeting last week, the classication was to occur on destination
address only.

    > It makes the traffic as an object to be served in
    > the network, and it can be used for policy enforcements in the various
    > nodes along the path such as traffic steering at the headend,
    > performance measurement at the midpoint, and so on.

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [