Network Working Group S. Peng Internet-Draft Z. Li Intended status: Informational Huawei Technologies Expires: April 4, 2021 D. Voyer Bell Canada C. Li China Telecom P. Liu China Mobile C. Cao China Unicom October 1, 2020 APN Security and Privacy Considerations draft-peng-apn-security-privacy-consideration-00 Abstract APN (Application-aware Networking) architecture aims to convey Application-aware Information including application/user/flow identifiers and SLA/service requirements along with the data packets into the network and make the network aware of applications and their requirements in order to provide corresponding application-aware network services and guarantee their SLA requirements. There have been challenges of the privacy and security issues that could potentially be introduced by conveying the application-aware information into the network. This document describes the security and privacy considerations of APN in various possible scenarios wherein APN will be deployed. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Peng, et al. Expires April 4, 2021 [Page 1] Internet-Draft APN Security and Privacy October 2020 Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on April 4, 2021. Copyright Notice Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminologies . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Adding Points of Application-aware Information . . . . . . . 4 3.1. APN Framework . . . . . . . . . . . . . . . . . . . . . . 4 3.2. App-info added by the application . . . . . . . . . . . . 4 3.3. App-info added by the Network Edge Device . . . . . . . . 4 4. Privacy Considerations . . . . . . . . . . . . . . . . . . . 5 4.1. Network Operator Self-Operating Application . . . . . . . 5 4.2. Application Providers Self-Operating Network . . . . . . 5 4.3. Network Operator's Limited Controlled Domain . . . . . . 5 4.4. Network Operator Controlled Edge Devices . . . . . . . . 6 4.5. Encrypted App-Info carried in the data packets . . . . . 6 4.6. Explicit App-Info carried in the data packets . . . . . . 6 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 5.1. Inter-DC Scenario . . . . . . . . . . . . . . . . . . . . 7 5.2. Enterprise Scenario . . . . . . . . . . . . . . . . . . . 7 5.3. Broadband Scenarios . . . . . . . . . . . . . . . . . . . 8 6. Potential Security Issues and Mitigations . . . . . . . . . . 9 6.1. One application within one terminal . . . . . . . . . . . 9 6.2. Two different applications within one terminal . . . . . 10 6.3. The same applications in two terminals . . . . . . . . . 10 6.4. App-info tampered along the way . . . . . . . . . . . . . 10 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 10 Peng, et al. Expires April 4, 2021 [Page 2] Internet-Draft APN Security and Privacy October 2020 9. Normative References . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 1. Introduction Application-aware Networking (APN) is introduced in [I-D.li-apn-framework] and [I-D.li-apn-problem-statement-usecases]. APN conveys Application-aware Information (App-Info) such as application/user/flow identifiers and SLA/service requirements along with data packets into network [I-D.li-6man-app-aware-ipv6-network] and make the network aware of applications and their requirements in order to provide corresponding network services and guarantee their SLA requirements. The ever-emerging network services such as network slicing and iOAM can be further enhanced with the application awareness in the network enabled by APN. Since with APN the Application-aware Information (App-Info) such as application/user/flow identifiers and SLA/service requirements are conveyed along with the data packets into network, APN has been challenged that it may potentially impose privacy and security issues. This document describes the privacy and security considerations of APN. 2. Terminologies AI: Artificial Intelligence APN: Application-aware Networking BNG: Broadband Network Gateway CPE: Customer Premise Equipment DPI: Deep Packet Inspection OS: Operating System RG: Residential Gateway UPF: User Plane Function 5GC: 5G Core Peng, et al. Expires April 4, 2021 [Page 3] Internet-Draft APN Security and Privacy October 2020 3. Adding Points of Application-aware Information 3.1. APN Framework The APN framework is introduced in [I-D.li-apn-framework], as shown in the Figure 1. +-----+ +-----+ |App x|-\ /-|App x| +-----+ | +-----+ +-----------------------+ +-----+ | +-----+ \-|App- | | Application-aware | |App- |-/ |aware|---| Network |---|aware| /-|Edge | | Service Provisioning | |Edge |-\ +-----+ | +-----+ +-----------------------+ +-----+ | +-----+ |App y|-/ | | \-|App y| +-----+ |<--- Network Operator Controlled --->| +-----+ Figure 1. APN6 Framework With APN, the application-aware information is added to the data packets (e.g. in the IPv6 extensions headers [I-D.li-6man-app-aware-ipv6-network]) and delivered to the network, wherein, according to the carried app-info, the application-aware network services such as application-aware network slicing are provisioned. The app-info can be added either directly by the application (e.g. App x in the Figure 1) or at the network edge devices (i.e. App- aware Edge in the Figure 1). 3.2. App-info added by the application The app-info can be added directly by the application, which is called as the host-side solution. With the host-side solution, after the app-info is obtained by the corresponding application, it will be added to the data packets during its encapsulation process going through the protocol stack in the OS. The host-side solution may require an update of the underlying operating system in order to allow the application element to pass the app-info to the socket service when building the packet header. 3.3. App-info added by the Network Edge Device The app-info can be added by the network edge device, which is called as the network-side solution. With the network-side solution, the app-info is added according to the configured policy at the network edge device, which is under the control of the network operator. Peng, et al. Expires April 4, 2021 [Page 4] Internet-Draft APN Security and Privacy October 2020 4. Privacy Considerations In this section the privacy aspects of APN are evaluated according to the most common scenarios where APN could be deployed. 4.1. Network Operator Self-Operating Application Nowadays, more and more network operators start operating their own applications. In this scenario, the network operators control and manage both, their own networks and their own applications. Typically, the steering of application traffic is triggered at the packet source (within the operator domain) and ends at the egress point of the operator's network which implies that the APN scheme is confined within the operator's domain. When the APN information is inserted, used and removed in/from the data packet inside the operator's domain, no additional security and privacy issues are introduced other than the usual ones when carrying metadata within a controlled domain (e.g. SFC). 4.2. Application Providers Self-Operating Network Similarly, more and more application providers start building and operating their own networks. In this way, the application providers control and manage both their own networks and their own applications. This scenario is actually the same as the previous one, which is, the APN scheme is confined within a controlled domain owned by the application provider. In this way, no additional security and privacy issues are introduced other than the usual ones when carrying metadata within a controlled domain (e.g. SFC). 4.3. Network Operator's Limited Controlled Domain In this case, the App-Info is only used within the network operator's controlled limited domain. A limited domain is intended as a portion of the operator infrastructure where APN is deployed. When the application packet reaches the boundary of the limited domain, the app-info is added to the packet, used in order to steer the packet within the limited domain and then removed when the packet leaves the limited domain. No matter what kind of app info is tagged from outside, within the APN network domain, the App-Info is added at the ingress node and removed from the egress node. In the APN network domain, the App- Info only serves for the application-aware network service Peng, et al. Expires April 4, 2021 [Page 5] Internet-Draft APN Security and Privacy October 2020 provisioning, and there is no harm for the outside of the APN network domain. This case is a sub-case of the previous one where the operator controls the whole infrastructure and applies APN only on a limited part of it. Similarly, the privacy aspects related to APN are no different from the existing mechanisms already used in order to tag and forward data packets. 4.4. Network Operator Controlled Edge Devices In this case, it is assumed that the App-Info is added by the network edge device [I-D.li-apn-framework] based on a matching policy, which is configured by the network operator. The matching policy can be directly based on the port being used (e.g., QinQ) or derived through other mechanisms (e.g., AI (Artificial Intelligence)) and not through mechanisms like DPI (Deep Packet Inspection) which may incur privacy issues in some cases. Although, in this way, the level of granularity may not be as good. No additional privacy issues are introduced than any other policy based solution where the packet is inspected, tagged and steered according to a preconfigured policy. 4.5. Encrypted App-Info carried in the data packets Here, the App-info is added directly by the applications and it is encrypted. In this case, 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 nodes along the path won't be able to infringe the privacy of the application's user. The traffic steering at the network headend/ingress can be simply based on the encrypted App-info if it is what the network operator installed in its forwarding table. If the traffic steering needs to be based on the decrypted App-info, a key should be shared between the encryption source node and the decryption destination node, which is based on a trustworthy agreement. 4.6. Explicit App-Info carried in the data packets 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. Peng, et al. Expires April 4, 2021 [Page 6] Internet-Draft APN Security and Privacy October 2020 APN is based on the trust relationship between the users, the network operators and the application providers. If the users want to enjoy the application-aware network services, such as game acceleration provided by the network operator, they will need to sign the trustworthy agreement with the network operator. If it is the network operator or application provider that owns both the network and application as in 4.1 and 4.2, it makes the trust relationship more easily to be set up, that is, if the users sign the agreement with them the relationship is established. 5. Security Considerations In this section the security aspects of APN are evaluated in the following scenarios. 5.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. Since the servers generating the traffic often belong to certain enterprise, the source and the destination of the traffic and the path used are known. There is no need for doing the access control even when APN is deployed in this scenario. To be more general, the Inter-DC traffic 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. 5.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, as shown in Figure 2. Peng, et al. Expires April 4, 2021 [Page 7] Internet-Draft APN Security and Privacy October 2020 +----+ +-------+ +-------+ | PC | \ | Cloud | | Cloud | +----+ \---\ +---|---+ +---|---+ +----+ \+------+ +-------+ +---|---+ +-----|-----+ | PC |------| CPE |------| BNG |-----| Core |-----| Internet | +----+ /+------+ +-------+ +-------+ +-----------+ +-----+ /---/ |Phone|/ +-----+ Figure 2. Enterprise Scenario Therefore, there will be no additional security issue introduced by APN in the Enterprise scenario. 5.3. Broadband Scenarios APN may only introduce security issues when the users access the operators' networks from an untrusted domain. However, as shown in Figure 3, the user traffic from the home broadband will be checked and authorized by the BNG, while as shown in Figure 4, the user traffic from the mobile broadband will be authorized by the 5GC function. In the home broadband 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. +----+ +-------+ +-------+ | PC | \ | Cloud | | Cloud | +----+ \---\ +---|---+ +---|---+ +-----+ \+------+ +-------+ +---|---+ +-----|-----+ | STB |-----| RG |------| BNG |-----| Core |-----| Internet | +-----+ /+------+ +-------+ +-------+ +-----------+ +-----+ /---/ |Phone|/ +-----+ Figure 3. Home Broadband Scenario Peng, et al. Expires April 4, 2021 [Page 8] Internet-Draft APN Security and Privacy October 2020 In the mobile broadband 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. +----+ +-------+ +-------+ | PC | | Cloud | | 5GC | +----+ +---|---+ +---|---+ +----+ +------+ +-------+ +---|---+ +---|---+ | UE | --- | gNB |------| ACC |-----| AGG |-----| UPF | +----+ +------+ +-------+ +-------+ +-------+ +-----+ | CPE | +-----+ Figure 4. Mobile Broadband Scenario 6. Potential Security Issues and Mitigations There are potentially four scenarios where APN might introducing security issues. 6.1. One application within one terminal An application in one terminal (UE) may add arbitrary App-Info including its requirements on the network. This issue can be tackled or resolved via the OS. If the App-Info is eventually sent out along with the data packets, it can still be blocked by the BNG or 5GC since it violates the already-signed agreements between the users and the network operators. Note that this is not different from any service/SLA selection scheme where the application/user traffic may be marked but anyway checked at ingress for correctness of the marking. Peng, et al. Expires April 4, 2021 [Page 9] Internet-Draft APN Security and Privacy October 2020 6.2. Two different applications within one terminal One application in the terminal (UE) may add the App-Info of another application in the same terminal. For example, the Email App attempts to forge the high-level SLA guarantee of the Live Video Streaming App. This issue can be tackled or resolved via the OS. If the App-Info is eventually sent out along with the data packets, it can still be blocked by the BNG or 5GC since it violates the already-signed agreements between the users and the network operators. 6.3. The same applications in two terminals An application in one terminal may forge the App-Info of the same App running in another terminal. Once the App-Info is sent out along with the data packets, the existing network security mechanisms such as HMAC can be utilized to validate the source of the forged App-Info being sent out from. 6.4. App-info tampered along the way The App-Info may be tampered along the way between the App-Info Encapsulator and the Network Boarder Node. Once the App-Info is sent out along with the data packets, the existing network security mechanisms such as HMAC can be utilized to validate the tampered App-Info. 7. IANA Considerations There are no IANA considerations in this document. 8. Contributors Chongfeng Xie China Telecom China Email: xiechf@chinatelecom.cn Liang Geng China Mobile China Email: gengliang@chinamobile.com Peng, et al. Expires April 4, 2021 [Page 10] Internet-Draft APN Security and Privacy October 2020 Shuai Zhang China Unicom China Email: zhangs366@chinaunicom.cn 9. Normative References [I-D.li-6man-app-aware-ipv6-network] Li, Z., Peng, S., Li, C., Xie, C., Voyer, D., Li, X., Liu, P., Liu, C., and K. Ebisawa, "Application-aware IPv6 Networking (APN6) Encapsulation", draft-li-6man-app-aware- ipv6-network-02 (work in progress), July 2020. [I-D.li-apn-framework] Li, Z., Peng, S., Voyer, D., Li, C., Geng, L., Cao, C., Ebisawa, K., Previdi, S., and J. Guichard, "Application- aware Networking (APN) Framework", draft-li-apn- framework-01 (work in progress), September 2020. [I-D.li-apn-problem-statement-usecases] Li, Z., Peng, S., Voyer, D., Xie, C., Liu, P., Qin, Z., Ebisawa, K., Previdi, S., and J. Guichard, "Problem Statement and Use Cases of Application-aware Networking (APN)", draft-li-apn-problem-statement-usecases-01 (work in progress), September 2020. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . Authors' Addresses Shuping Peng Huawei Technologies Beijing China Email: pengshuping@huawei.com Zhenbin Li Huawei Technologies Beijing China Email: lizhenbin@huawei.com Peng, et al. Expires April 4, 2021 [Page 11] Internet-Draft APN Security and Privacy October 2020 Daniel Voyer Bell Canada Canada Email: daniel.voyer@bell.ca Cong Li China Telecom China Email: licong@chinatelecom.cn Peng Liu China Mobile China Email: liupengyjy@chinamobile.com Chang Cao China Unicom China Email: caoc15@chinaunicom.cn Peng, et al. Expires April 4, 2021 [Page 12]