[Network-tokens] Question List for APN: Q#9 & Q#10

"Pengshuping (Peng Shuping)" <pengshuping@huawei.com> Wed, 30 September 2020 03:08 UTC

Return-Path: <pengshuping@huawei.com>
X-Original-To: network-tokens@ietfa.amsl.com
Delivered-To: network-tokens@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F7B13A0EE0; Tue, 29 Sep 2020 20:08:12 -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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-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 r6JOhVnrzGKp; Tue, 29 Sep 2020 20:08:09 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 CBED73A0ECB; Tue, 29 Sep 2020 20:08:07 -0700 (PDT)
Received: from lhreml751-chm.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id F27D1ABE2C1B9AAFCEC9; Wed, 30 Sep 2020 04:08:04 +0100 (IST)
Received: from lhreml751-chm.china.huawei.com (10.201.108.201) by lhreml751-chm.china.huawei.com (10.201.108.201) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Wed, 30 Sep 2020 04:08:04 +0100
Received: from DGGEML403-HUB.china.huawei.com (10.3.17.33) by lhreml751-chm.china.huawei.com (10.201.108.201) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.1913.5 via Frontend Transport; Wed, 30 Sep 2020 04:08:04 +0100
Received: from DGGEML512-MBX.china.huawei.com ([169.254.2.223]) by DGGEML403-HUB.china.huawei.com ([fe80::74d9:c659:fbec:21fa%31]) with mapi id 14.03.0487.000; Wed, 30 Sep 2020 11:08:00 +0800
From: "Pengshuping (Peng Shuping)" <pengshuping@huawei.com>
To: "apn@ietf.org" <apn@ietf.org>
CC: "architecture-discuss@iab.org" <architecture-discuss@iab.org>, "network-tokens@ietf.org" <network-tokens@ietf.org>
Thread-Topic: Question List for APN: Q#9 & Q#10
Thread-Index: AdaW1eZKcQN8lq3gT3mGXusAXqpF7w==
Date: Wed, 30 Sep 2020 03:08:00 +0000
Message-ID: <4278D47A901B3041A737953BAA078ADE19438DAE@dggeml512-mbx.china.huawei.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.153.195.37]
Content-Type: multipart/alternative; boundary="_000_4278D47A901B3041A737953BAA078ADE19438DAEdggeml512mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/network-tokens/wyaw7D5vehbpXlM91d457XE2FqU>
Subject: [Network-tokens] Question List for APN: Q#9 & Q#10
X-BeenThere: network-tokens@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussion list for network tokens <network-tokens.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/network-tokens>, <mailto:network-tokens-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/network-tokens/>
List-Post: <mailto:network-tokens@ietf.org>
List-Help: <mailto:network-tokens-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/network-tokens>, <mailto:network-tokens-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 30 Sep 2020 03:08:19 -0000

Dear all,

#9.   Will APN raise security issues since application-aware information is carried in the APN packets?
Answers: We can categorize the scenarios wherein APN can be deployed into three categories.
1)     Inter-DC Scenario: In order to reduce the IT investment, most enterprises have moved some of their applications and data into the Cloud. For the large-scale enterprises, generally their applications and data are distributed across multiple clouds. The communication in between clouds and datacenters represents most of the inter-DC traffic, which is usually originated and destined within the domain, and steered according to inter-DC policies. The presence (or not) of APN information in data packets does not interfere with the inter-DC traffic scheme and does not require any additional security measure.

2)     Enterprise Scenario: The enterprise traffic often accesses from CPE (Customer Premise Equipment) towards the Internet or Clouds along the paid leased lines through the controlled BNG (Broadband Network Gateway) interfaces, which means that the enterprise traffic is going to be validated and authorized by the BNG. Therefore, there will be no additional security issue introduced by APN in the Enterprise scenario.

3)     Broadband Scenarios: APN may only introduce security issues when the users access the operators' networks from an untrusted domain. However, the user traffic from the home broadband will be checked and authorized by the BNG, while the user traffic from the mobile broadband will be authorized by the 5GC function.

In the home broadband (FBB) scenario, generally a home broadband user is authorized using the MAC address of the RG (Residential Gateway), the VLAN/QinQ, and the input port on the BNG. Whether the home broadband user has bought a value-added service like game acceleration will be checked further. With APN, the value-added service can be indicated by the App-Info carried in the packets, and it will be checked against the one that the operator has configured in the BNG. If the carried App-Info matches the corresponding policy entry for the user, the validation is passed and the access control is released, so the user can start enjoying the acceleration service for its application.

In the mobile broadband (MBB) scenario, a UE is authorized by the 5GC function, and the traffic steering and QoS policy are enforced by the UPF (User Plane Function) node.  Whether the user has bought a value-added service like game acceleration will be checked against the configured policies. With APN, the value-added service can be indicated by the App-Info carried in the packets, and it will be checked against the one that the operator has configured in the UPF node.  If the carried App-Info matches the corresponding policy entry, the validation is passed and the access control is released, so the user can start enjoying the acceleration service for its application.


#10. Will APN raise privacy issues since application-aware information is carried in the APN packets?
Answers: We can categorize the scenarios wherein APN can be deployed into three categories.
1)     Network Operator Self-Operating Application & Application Providers Self-Operating Network: Applications and networks are controlled and managed by the same entity, either the operators who run their own applications or the application providers who run their own networks. In this case, since it is a single entity, the trustworthy relationship between the application provider and the network operator is built natively, and trustworthy agreements is signed between the users and the entity organizations to enjoy the application-aware network services.
2)     Network Operator's Limited Controlled Domain & Network Operator Controlled Edge Devices: The Application information is added at the edge of the APN network and removed when the packets leave the APN network domain, it won’t hurt the rest of the network but only serves the application-aware network services provisioning.
3)     Encrypted App-Info carried in the data packets & Explicit App-Info carried in the data packets: When the App-info is added directly by the applications and it is   encrypted, while the packets carrying the App-Info are being delivered along the path, the privacy-related information that may be exposed by the original plain App-Info won't be leaked since it is already encrypted. The path and the nodes along the path won't be able to infringe the privacy of the application's user.

If the App-info is added directly by the applications but it is not encrypted, the privacy-related information of the application's user might be exposed along the path. There might be privacy issues introduced by the APN in this scenario. Mechanisms on the proper encoding of the App-Info would be required.

------------------------------------------------------------------------------

All the ten questions and answers have been posted. Cheers!

Best regards,
Shuping



From: Lizhenbin
Sent: Monday, September 14, 2020 10:35 PM
To: apn@ietf.org
Cc: Pengshuping (Peng Shuping) <pengshuping@huawei.com>
Subject: Question List for APN

Hi Folks,
Thanks very much for your attention to APN work. After much preparation work, we summarized the key questions to be clarified for APN which also were always asked. In fact in the past discussion and the APN side meeting of IETF108, many of these questions were discussed and clarified. Here we propose these questions together for your convenience.

The questions to be clarified are as follows:
#1. Which layer is for APN to do the application-aware work?
#2. Does APN provide services within a limited-domain or Internet?
#3. Which area in IETF would the APN work fit better?
#4. What is the relationship between APN and other attempts in IETF’s history?
#5. What are the valuable use cases/usage scenarios of APN?
#6. Is the fine-granularity operations needed/desired in the network?
#7. Why not just use DSCP?
#8. Does APN violate network neutrality?
#9. Will APN raise security issues since application-aware information is carried in the APN packets?
#10. Will APN raise privacy issues since application-aware information is carried in the APN packets?

Shuping Peng will send the detailed answers for these questions in the mailing list in the following one or two weeks. The questions and answers may be not only be sent in the APN mailing list, but also be copied to the architecture discussion mailing list and the network token mailing list for more cross-area feedback if necessary.

If you have any comments on these questions and answers, we can go on to discuss through the mailing list.


Best Regards,
Zhenbin (Robin)




From: Apn [mailto:apn-bounces@ietf.org] On Behalf Of Lizhenbin
Sent: Tuesday, August 18, 2020 7:22 PM
To: apn@ietf.org<mailto:apn@ietf.org>
Subject: [Apn] Welcome to APN Mailing List

Hi Folks,

Welcome to join the APN mailing list. We are glad to have more discussion through the mailing list as the follow-up of the IETF108 APN side meeting.
In the process of APN work, many historic work items such as SPUD, PLUS, etc. have been proposed. It has been tried to be clarified that APN focuses
on the network layer and limited domains. Concerns on the security and privacy issues also have been proposed many times about the work. It also
has been tried to be clarified that in the trustable limited domains the security and privacy issues can be under control. These are the reasons why APN
work is based in the RTG area instead of ART/TSV areas.

But because of too much historic work to be clarified and its proposing the cross-area discussion for which RTG/APP/TSV/INT/SEC/IRTF are involved, it is
necessary to have more discussion to clarify the scope and work items for APN. We wish the mailing list would be helpful to the work and promoting the
cross-area communication to understand each other better.

You can get yourself up to speed with our discussions so far by seeing the materials at < https://github.com/APN-Community/>, especially the materials
From the virtual IETF 108  APN side meeting at < https://github.com/APN-Community/IETF108-Side-Meeting-APN>. This link also gives you pointers to
some of the relevant Internet-Drafts.

Over the next few weeks we will try to guide discussion by introducing some questions for debate. But please also raise your own issues and concerns
and contribute to the exchanges on this list.

Look forwarding to have more fun discussion in the mailing list.


Best Regards,
Dan & Zhenbin