idnits 2.17.1 draft-peng-apn-security-privacy-consideration-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (June 17, 2021) is 1037 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.li-6man-app-aware-ipv6-network' is defined on line 270, but no explicit reference was found in the text == Outdated reference: A later version (-07) exists of draft-li-apn-framework-02 == Outdated reference: A later version (-08) exists of draft-li-apn-problem-statement-usecases-01 == Outdated reference: A later version (-06) exists of draft-yang-apn-sd-wan-usecase-01 Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Peng 3 Internet-Draft Z. Li 4 Intended status: Informational Huawei Technologies 5 Expires: December 19, 2021 D. Voyer 6 Bell Canada 7 C. Li 8 China Telecom 9 P. Liu 10 China Mobile 11 C. Cao 12 China Unicom 13 June 17, 2021 15 APN Security and Privacy Considerations 16 draft-peng-apn-security-privacy-consideration-02 18 Abstract 20 Application-aware Networking (APN) aims to convey Application-aware 21 Information (APN attribute) including APN ID and APN parameters 22 indicating application group-level and user group-level requirements 23 along with the data packets into the network and enable the network 24 to provide corresponding fine-granular network services. 26 There have been challenges of the privacy and security issues that 27 could potentially be introduced by conveying the APN attribute into 28 the network. This document describes the security and privacy 29 considerations of APN in various possible scenarios wherein APN will 30 be deployed. 32 Requirements Language 34 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 35 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 36 document are to be interpreted as described in RFC 2119 [RFC2119]. 38 Status of This Memo 40 This Internet-Draft is submitted in full conformance with the 41 provisions of BCP 78 and BCP 79. 43 Internet-Drafts are working documents of the Internet Engineering 44 Task Force (IETF). Note that other groups may also distribute 45 working documents as Internet-Drafts. The list of current Internet- 46 Drafts is at https://datatracker.ietf.org/drafts/current/. 48 Internet-Drafts are draft documents valid for a maximum of six months 49 and may be updated, replaced, or obsoleted by other documents at any 50 time. It is inappropriate to use Internet-Drafts as reference 51 material or to cite them other than as "work in progress." 53 This Internet-Draft will expire on December 19, 2021. 55 Copyright Notice 57 Copyright (c) 2021 IETF Trust and the persons identified as the 58 document authors. All rights reserved. 60 This document is subject to BCP 78 and the IETF Trust's Legal 61 Provisions Relating to IETF Documents 62 (https://trustee.ietf.org/license-info) in effect on the date of 63 publication of this document. Please review these documents 64 carefully, as they describe your rights and restrictions with respect 65 to this document. Code Components extracted from this document must 66 include Simplified BSD License text as described in Section 4.e of 67 the Trust Legal Provisions and are provided without warranty as 68 described in the Simplified BSD License. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 73 2. Terminologies . . . . . . . . . . . . . . . . . . . . . . . . 3 74 3. APN Framework . . . . . . . . . . . . . . . . . . . . . . . . 3 75 4. Privacy Considerations . . . . . . . . . . . . . . . . . . . 4 76 5. Security Considerations . . . . . . . . . . . . . . . . . . . 4 77 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 78 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 6 79 8. Normative References . . . . . . . . . . . . . . . . . . . . 7 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 82 1. Introduction 84 Application-aware Networking (APN) is introduced in 85 [I-D.li-apn-framework] and [I-D.li-apn-problem-statement-usecases]. 86 APN conveys Application-aware Information (APN attribute) along with 87 data packets into network and make the network aware of applications' 88 requirements in order to provide corresponding network services. The 89 ever-emerging network services such as network slicing and iOAM can 90 be further enhanced with the application awareness in the network 91 enabled by APN. 93 Since APN conveys an APN attribute along with the data packets into 94 network, APN has been challenged that it may potentially impose 95 privacy and security issues. 97 This document describes the privacy and security considerations of 98 APN. 100 2. Terminologies 102 AI: Artificial Intelligence 104 APN: Application-aware Networking 106 BNG: Broadband Network Gateway 108 CPE: Customer Premise Equipment 110 DPI: Deep Packet Inspection 112 OS: Operating System 114 RG: Residential Gateway 116 UPF: User Plane Function 118 5GC: 5G Core 120 3. APN Framework 122 The APN framework is introduced in [I-D.li-apn-framework], as shown 123 in the Figure 1. 125 +-----+ +-----+ 126 |App x|-\ /-|App x| 127 +-----+ | +-----+ +-----------------------+ +-----+ | +-----+ 128 \-|APN | | Application-aware | |APN |-/ 129 |- |---| Network |---|- | 130 /-|Edge | | Service Provisioning | |Edge |-\ 131 +-----+ | +-----+ +-----------------------+ +-----+ | +-----+ 132 |App y|-/ | | \-|App y| 133 +-----+ |<--- Network Operator Controlled --->| +-----+ 135 Figure 1. APN6 Framework 137 With APN, the APN attribute is acquired based on the existing 138 information in the packet header such as 5-tuple and/or QinQ (S-VLAN 139 and C-VLAN) at the edge devices of the APN domain (i.e. APN-Edge in 140 the Figure 1), added to the data packets in the tunnel encapsulation, 141 and delivered to the network, wherein, according to the carried APN 142 attribute, the fine-granular network services are provisioned. 144 The APN attribute is added by the edge device of an APN domain 145 according to the local policy at the network edge device (i.e. APN- 146 Edge), which is under the control of the network operator. 148 4. Privacy Considerations 150 The APN attribute is only used within the network operator's 151 controlled limited domain. A limited domain is intended as a portion 152 of the operator infrastructure where APN is deployed. When a packet 153 reaches the boundary of the limited domain, an APN attribute is added 154 to the packet, used in order to steer the packet within the limited 155 domain and then removed when the packet leaves the limited domain. 157 Within the APN network domain, the APN attribute is added at the 158 ingress node and removed from the egress node. In the APN network 159 domain, the APN attribute only serves for the fine-granular network 160 service provisioning, and there is no harm for the outside of the APN 161 network domain. 163 5. Security Considerations 165 There are two typical scenarios besides the SD-WAN scenario described 166 in the draft [I-D.yang-apn-sd-wan-usecase]: the home broadband 167 scenario and the mobile broadband scenario. 169 In the home broadband scenario, generally a home broadband user is 170 authorized by the BNG. If the validation is passed and the access 171 control is released, so the user group can start enjoying the value- 172 added service. With APN, when the traffic traverses the metro 173 network, the traffic flow can be indicated by the APN attribute that 174 is added/removed at the edge devices of the Metro Network (APN 175 domain) based on the mapping from the existing information (e.g. the 176 QinQ which is composed of C-VLAN and S-VLAN) in the packet header and 177 then carried in the tunnel encapsulation header. The APN attribute 178 will facilitate the fine-granular service in the APN domain. Once 179 the packets leave the APN domain, the APN attribute will be removed 180 together with the tunnel encapsulation header. 182 |---- APN Domain ---| 183 +----+ .-----. 184 | PC | \ ( ) 185 +----+ \--\ .--( )--. 186 +-----+ \+----+ +----+ ( ) +-------+ 187 | STB |----| RG |--| AN |----( Metro Network )-----| BNG |---> 188 +-----+ /+----+ +----+ ( ) +-------+ 189 +-----+ /--/ '--( )--' 190 |Phone|/ ( ) 191 +-----+ '-----' 192 QinQ QinQ 193 |----|---- Tunnel ----|----| 195 Figure 2. Home Broadband Scenario 197 In the mobile broadband scenario, a UE is authorized by the 5GC 198 function, and the traffic steering and QoS policy are enforced by the 199 UPF (User Plane Function) node. If the validation is passed and the 200 access control is released, so the user can start enjoying the value- 201 added service. With APN, when the traffic traverses the mobile 202 transport network, the traffic flow can be indicated by the APN 203 attribute that is added at the edge devices of the mobile transport 204 network (APN domain) based on mapping from the existing information 205 (e.g. GTP-u tunnel encapsulation information) in the packet header 206 and then carried in the tunnel encapsulation header. The APN 207 attribute will facilitate the fine-granular service in the APN 208 domain. Once the packets leave the APN domain, the APN attribute 209 will be removed together with the tunnel encapsulation header. In 210 fact, the APN attribute can also be acquired at the gNB based on the 211 mapping of the existing information of the packet header (e.g. 212 5-tuple information) and carried along with the GTP-u tunnel 213 encapsulation. The mobile transport network can provide the 214 corresponding service according to the APN attribute. When the 215 packet leaves the UPF, the APN attribute can be removed together with 216 the GTP-u tunnel encapsulation. 218 |-- APN Domain ---| 220 +----+ .-----. 221 | PC | ( ) 222 +----+ .--( )--. 223 +----+ +------+ ( ) +-------+ 224 | UE | --- | gNB |------( Mobile Transport )------| UPF |----> 225 +----+ +------+ ( Network ) +-------+ 226 +-----+ '--( )--' 227 | CPE | ( ) 228 +-----+ '-----' 230 |---- Tunnel ----| 232 |--------- GTP-u Tunnel --------| 234 Figure 3. Mobile Broadband Scenario 236 In the typical APN scenarios like the home broadband scenario and the 237 mobile broadband scenario, before the traffic is delivered to the 238 network domain, the end user must be authenticated and authorized 239 firstly to guarantee the security of the network domain. When the 240 traffic traverses the APN domain, the APN attribute is added and 241 removed at the edge of the APN domain along with the tunnel 242 encapsulation. That is, the APN attribute is only used locally in 243 the APN domain and will not introduce the extra security issues. 245 6. IANA Considerations 247 There are no IANA considerations in this document. 249 7. Contributors 251 Chongfeng Xie 252 China Telecom 253 China 255 Email: xiechf@chinatelecom.cn 257 Liang Geng 258 China Mobile 259 China 261 Email: gengliang@chinamobile.com 262 Shuai Zhang 263 China Unicom 264 China 266 Email: zhangs366@chinaunicom.cn 268 8. Normative References 270 [I-D.li-6man-app-aware-ipv6-network] 271 Li, Z., Peng, S., Li, C., Xie, C., Voyer, D., Li, X., Liu, 272 P., Cao, C., and K. Ebisawa, "Application-aware IPv6 273 Networking (APN6) Encapsulation", draft-li-6man-app-aware- 274 ipv6-network-03 (work in progress), February 2021. 276 [I-D.li-apn-framework] 277 Li, Z., Peng, S., Voyer, D., Li, C., Liu, P., Cao, C., 278 Ebisawa, K., Previdi, S., and J. N. Guichard, 279 "Application-aware Networking (APN) Framework", draft-li- 280 apn-framework-02 (work in progress), February 2021. 282 [I-D.li-apn-problem-statement-usecases] 283 Li, Z., Peng, S., Voyer, D., Xie, C., Liu, P., Qin, Z., 284 Ebisawa, K., Previdi, S., and J. N. Guichard, "Problem 285 Statement and Use Cases of Application-aware Networking 286 (APN)", draft-li-apn-problem-statement-usecases-01 (work 287 in progress), September 2020. 289 [I-D.yang-apn-sd-wan-usecase] 290 Yang, F., Cheng, W., Peng, S., and Z. Li, "Usage scenarios 291 of Application-aware Networking (APN) for SD-WAN", draft- 292 yang-apn-sd-wan-usecase-01 (work in progress), February 293 2021. 295 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 296 Requirement Levels", BCP 14, RFC 2119, 297 DOI 10.17487/RFC2119, March 1997, 298 . 300 Authors' Addresses 302 Shuping Peng 303 Huawei Technologies 304 Beijing 305 China 307 Email: pengshuping@huawei.com 308 Zhenbin Li 309 Huawei Technologies 310 Beijing 311 China 313 Email: lizhenbin@huawei.com 315 Daniel Voyer 316 Bell Canada 317 Canada 319 Email: daniel.voyer@bell.ca 321 Cong Li 322 China Telecom 323 China 325 Email: licong@chinatelecom.cn 327 Peng Liu 328 China Mobile 329 China 331 Email: liupengyjy@chinamobile.com 333 Chang Cao 334 China Unicom 335 China 337 Email: caoc15@chinaunicom.cn