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,
<https://www.rfc-editor.org/info/rfc2119>.
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]