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

"Pengshuping (Peng Shuping)" <pengshuping@huawei.com> Mon, 07 June 2021 01:50 UTC

Return-Path: <pengshuping@huawei.com>
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 6B7AB3A30E3; Sun, 6 Jun 2021 18:50:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, 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 4CycFdQzpi4j; Sun, 6 Jun 2021 18:50:34 -0700 (PDT)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2CBE3A30E1; Sun, 6 Jun 2021 18:50:33 -0700 (PDT)
Received: from fraeml741-chm.china.huawei.com (unknown [172.18.147.200]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4Fyx0p4pYNz6K5Vs; Mon, 7 Jun 2021 09:41:14 +0800 (CST)
Received: from dggeml755-chm.china.huawei.com (10.1.199.136) by fraeml741-chm.china.huawei.com (10.206.15.222) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.2176.2; Mon, 7 Jun 2021 03:50:28 +0200
Received: from dggeml757-chm.china.huawei.com (10.1.199.137) by dggeml755-chm.china.huawei.com (10.1.199.136) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2176.2; Mon, 7 Jun 2021 09:50:26 +0800
Received: from dggeml757-chm.china.huawei.com ([10.1.199.137]) by dggeml757-chm.china.huawei.com ([10.1.199.137]) with mapi id 15.01.2176.012; Mon, 7 Jun 2021 09:50:26 +0800
From: "Pengshuping (Peng Shuping)" <pengshuping@huawei.com>
To: Michael Richardson <mcr+ietf@sandelman.ca>, linda 73504 <ldunbar@futurewei.com>, "rtgwg@ietf.org" <rtgwg@ietf.org>, "apn@ietf.org" <apn@ietf.org>
Thread-Topic: [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
Thread-Index: AddTStILnyj6Dkg0TeKd5kZUmkwsjAF0Ua0AAAJzCwAAApD+gAABOkQAAC50BQAAUrbO8A==
Date: Mon, 07 Jun 2021 01:50:26 +0000
Message-ID: <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>
In-Reply-To: <362.1622914856@localhost>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.108.243.114]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/apn/kBzU2bbYDSK8PAv3-nPmDUewMj8>
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: Mon, 07 Jun 2021 01:50:39 -0000

Hi Michael, 

Many thanks for your interests and the discussions. 

A few clarifications to your points regarding APN.

1. The end-user devices are NOT involved.
2. The "Cloud Loop Networks" should mean about a service operator's controlled network or an enterprise's network, i.e. a limited domain. Although it is a limited domain, still the network is generally built using the devices from multiple vendors, and that is why the standards is needed. 
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. 

Some logics behind APN is like the followings. 

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. Meanwhile the network capabilities enabling differentiated services, such as SR policies and network slicing (hundreds to thousands), have been evolving. 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. 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. 

Best regards, 
Shuping 


-----Original Message-----
From: rtgwg [mailto:rtgwg-bounces@ietf.org] On Behalf Of Michael Richardson
Sent: Sunday, June 6, 2021 1:41 AM
To: linda 73504 <ldunbar@futurewei.com>; rtgwg@ietf.org; apn@ietf.org
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


Linda Dunbar <ldunbar@futurewei.com> wrote:
    > I meant to say that APN is useful in those "Closed Loop Networks",
    > which are becoming more common for the 5G enabled special services.

So what parts of the Close Loop Network needs standards work?

    > The "end user" or services that need APN are the one who have special
    > contracts with the operators. Not all services.

I'm rather convinced that you could use RSVP+Diffserv (aka "diffedge") to do this then.  diffedge did not, AFAIK, ever make it out of ID.
     https://www.ietf.org/archive/id/draft-bernet-diffedge-01.txt

While Joel mentioned many things that made "Intserv" (just RSVP) undeployable in the Internet, it was deployable within Enterprises, and there are now 20+ years of improvements to forwarding plane and control plane CPUs.
Given that you have a closed environment, it seems like diffedge + SDN ought to do what you want.

--
Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide