idnits 2.17.1 draft-peng-apn-security-privacy-consideration-00.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 (October 1, 2020) is 1304 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-03) exists of draft-li-6man-app-aware-ipv6-network-02 == Outdated reference: A later version (-07) exists of draft-li-apn-framework-01 == Outdated reference: A later version (-08) exists of draft-li-apn-problem-statement-usecases-01 Summary: 0 errors (**), 0 flaws (~~), 5 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: April 4, 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 October 1, 2020 15 APN Security and Privacy Considerations 16 draft-peng-apn-security-privacy-consideration-00 18 Abstract 20 APN (Application-aware Networking) architecture aims to convey 21 Application-aware Information including application/user/flow 22 identifiers and SLA/service requirements along with the data packets 23 into the network and make the network aware of applications and their 24 requirements in order to provide corresponding application-aware 25 network services and guarantee their SLA requirements. 27 There have been challenges of the privacy and security issues that 28 could potentially be introduced by conveying the application-aware 29 information into the network. This document describes the security 30 and privacy considerations of APN in various possible scenarios 31 wherein APN will be deployed. 33 Requirements Language 35 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 36 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 37 document are to be interpreted as described in RFC 2119 [RFC2119]. 39 Status of This Memo 41 This Internet-Draft is submitted in full conformance with the 42 provisions of BCP 78 and BCP 79. 44 Internet-Drafts are working documents of the Internet Engineering 45 Task Force (IETF). Note that other groups may also distribute 46 working documents as Internet-Drafts. The list of current Internet- 47 Drafts is at https://datatracker.ietf.org/drafts/current/. 49 Internet-Drafts are draft documents valid for a maximum of six months 50 and may be updated, replaced, or obsoleted by other documents at any 51 time. It is inappropriate to use Internet-Drafts as reference 52 material or to cite them other than as "work in progress." 54 This Internet-Draft will expire on April 4, 2021. 56 Copyright Notice 58 Copyright (c) 2020 IETF Trust and the persons identified as the 59 document authors. All rights reserved. 61 This document is subject to BCP 78 and the IETF Trust's Legal 62 Provisions Relating to IETF Documents 63 (https://trustee.ietf.org/license-info) in effect on the date of 64 publication of this document. Please review these documents 65 carefully, as they describe your rights and restrictions with respect 66 to this document. Code Components extracted from this document must 67 include Simplified BSD License text as described in Section 4.e of 68 the Trust Legal Provisions and are provided without warranty as 69 described in the Simplified BSD License. 71 Table of Contents 73 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 74 2. Terminologies . . . . . . . . . . . . . . . . . . . . . . . . 3 75 3. Adding Points of Application-aware Information . . . . . . . 4 76 3.1. APN Framework . . . . . . . . . . . . . . . . . . . . . . 4 77 3.2. App-info added by the application . . . . . . . . . . . . 4 78 3.3. App-info added by the Network Edge Device . . . . . . . . 4 79 4. Privacy Considerations . . . . . . . . . . . . . . . . . . . 5 80 4.1. Network Operator Self-Operating Application . . . . . . . 5 81 4.2. Application Providers Self-Operating Network . . . . . . 5 82 4.3. Network Operator's Limited Controlled Domain . . . . . . 5 83 4.4. Network Operator Controlled Edge Devices . . . . . . . . 6 84 4.5. Encrypted App-Info carried in the data packets . . . . . 6 85 4.6. Explicit App-Info carried in the data packets . . . . . . 6 86 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 87 5.1. Inter-DC Scenario . . . . . . . . . . . . . . . . . . . . 7 88 5.2. Enterprise Scenario . . . . . . . . . . . . . . . . . . . 7 89 5.3. Broadband Scenarios . . . . . . . . . . . . . . . . . . . 8 90 6. Potential Security Issues and Mitigations . . . . . . . . . . 9 91 6.1. One application within one terminal . . . . . . . . . . . 9 92 6.2. Two different applications within one terminal . . . . . 10 93 6.3. The same applications in two terminals . . . . . . . . . 10 94 6.4. App-info tampered along the way . . . . . . . . . . . . . 10 95 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 96 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 10 97 9. Normative References . . . . . . . . . . . . . . . . . . . . 11 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 100 1. Introduction 102 Application-aware Networking (APN) is introduced in 103 [I-D.li-apn-framework] and [I-D.li-apn-problem-statement-usecases]. 104 APN conveys Application-aware Information (App-Info) such as 105 application/user/flow identifiers and SLA/service requirements along 106 with data packets into network [I-D.li-6man-app-aware-ipv6-network] 107 and make the network aware of applications and their requirements in 108 order to provide corresponding network services and guarantee their 109 SLA requirements. The ever-emerging network services such as network 110 slicing and iOAM can be further enhanced with the application 111 awareness in the network enabled by APN. 113 Since with APN the Application-aware Information (App-Info) such as 114 application/user/flow identifiers and SLA/service requirements are 115 conveyed along with the data packets into network, APN has been 116 challenged that it may potentially impose privacy and security 117 issues. 119 This document describes the privacy and security considerations of 120 APN. 122 2. Terminologies 124 AI: Artificial Intelligence 126 APN: Application-aware Networking 128 BNG: Broadband Network Gateway 130 CPE: Customer Premise Equipment 132 DPI: Deep Packet Inspection 134 OS: Operating System 136 RG: Residential Gateway 138 UPF: User Plane Function 140 5GC: 5G Core 142 3. Adding Points of Application-aware Information 144 3.1. APN Framework 146 The APN framework is introduced in [I-D.li-apn-framework], as shown 147 in the Figure 1. 149 +-----+ +-----+ 150 |App x|-\ /-|App x| 151 +-----+ | +-----+ +-----------------------+ +-----+ | +-----+ 152 \-|App- | | Application-aware | |App- |-/ 153 |aware|---| Network |---|aware| 154 /-|Edge | | Service Provisioning | |Edge |-\ 155 +-----+ | +-----+ +-----------------------+ +-----+ | +-----+ 156 |App y|-/ | | \-|App y| 157 +-----+ |<--- Network Operator Controlled --->| +-----+ 159 Figure 1. APN6 Framework 161 With APN, the application-aware information is added to the data 162 packets (e.g. in the IPv6 extensions headers 163 [I-D.li-6man-app-aware-ipv6-network]) and delivered to the network, 164 wherein, according to the carried app-info, the application-aware 165 network services such as application-aware network slicing are 166 provisioned. 168 The app-info can be added either directly by the application (e.g. 169 App x in the Figure 1) or at the network edge devices (i.e. App- 170 aware Edge in the Figure 1). 172 3.2. App-info added by the application 174 The app-info can be added directly by the application, which is 175 called as the host-side solution. With the host-side solution, after 176 the app-info is obtained by the corresponding application, it will be 177 added to the data packets during its encapsulation process going 178 through the protocol stack in the OS. 180 The host-side solution may require an update of the underlying 181 operating system in order to allow the application element to pass 182 the app-info to the socket service when building the packet header. 184 3.3. App-info added by the Network Edge Device 186 The app-info can be added by the network edge device, which is called 187 as the network-side solution. With the network-side solution, the 188 app-info is added according to the configured policy at the network 189 edge device, which is under the control of the network operator. 191 4. Privacy Considerations 193 In this section the privacy aspects of APN are evaluated according to 194 the most common scenarios where APN could be deployed. 196 4.1. Network Operator Self-Operating Application 198 Nowadays, more and more network operators start operating their own 199 applications. In this scenario, the network operators control and 200 manage both, their own networks and their own applications. 201 Typically, the steering of application traffic is triggered at the 202 packet source (within the operator domain) and ends at the egress 203 point of the operator's network which implies that the APN scheme is 204 confined within the operator's domain. 206 When the APN information is inserted, used and removed in/from the 207 data packet inside the operator's domain, no additional security and 208 privacy issues are introduced other than the usual ones when carrying 209 metadata within a controlled domain (e.g. SFC). 211 4.2. Application Providers Self-Operating Network 213 Similarly, more and more application providers start building and 214 operating their own networks. In this way, the application providers 215 control and manage both their own networks and their own 216 applications. 218 This scenario is actually the same as the previous one, which is, the 219 APN scheme is confined within a controlled domain owned by the 220 application provider. In this way, no additional security and 221 privacy issues are introduced other than the usual ones when carrying 222 metadata within a controlled domain (e.g. SFC). 224 4.3. Network Operator's Limited Controlled Domain 226 In this case, the App-Info is only used within the network operator's 227 controlled limited domain. A limited domain is intended as a portion 228 of the operator infrastructure where APN is deployed. When the 229 application packet reaches the boundary of the limited domain, the 230 app-info is added to the packet, used in order to steer the packet 231 within the limited domain and then removed when the packet leaves the 232 limited domain. 234 No matter what kind of app info is tagged from outside, within the 235 APN network domain, the App-Info is added at the ingress node and 236 removed from the egress node. In the APN network domain, the App- 237 Info only serves for the application-aware network service 238 provisioning, and there is no harm for the outside of the APN network 239 domain. 241 This case is a sub-case of the previous one where the operator 242 controls the whole infrastructure and applies APN only on a limited 243 part of it. Similarly, the privacy aspects related to APN are no 244 different from the existing mechanisms already used in order to tag 245 and forward data packets. 247 4.4. Network Operator Controlled Edge Devices 249 In this case, it is assumed that the App-Info is added by the network 250 edge device [I-D.li-apn-framework] based on a matching policy, which 251 is configured by the network operator. The matching policy can be 252 directly based on the port being used (e.g., QinQ) or derived through 253 other mechanisms (e.g., AI (Artificial Intelligence)) and not through 254 mechanisms like DPI (Deep Packet Inspection) which may incur privacy 255 issues in some cases. Although, in this way, the level of 256 granularity may not be as good. 258 No additional privacy issues are introduced than any other policy 259 based solution where the packet is inspected, tagged and steered 260 according to a preconfigured policy. 262 4.5. Encrypted App-Info carried in the data packets 264 Here, the App-info is added directly by the applications and it is 265 encrypted. In this case, while the packets carrying the App-Info are 266 being delivered along the path, the privacy-related information that 267 may be exposed by the original plain App-Info won't be leaked since 268 it is already encrypted. The nodes along the path won't be able to 269 infringe the privacy of the application's user. 271 The traffic steering at the network headend/ingress can be simply 272 based on the encrypted App-info if it is what the network operator 273 installed in its forwarding table. If the traffic steering needs to 274 be based on the decrypted App-info, a key should be shared between 275 the encryption source node and the decryption destination node, which 276 is based on a trustworthy agreement. 278 4.6. Explicit App-Info carried in the data packets 280 If the App-info is added directly by the applications but it is not 281 encrypted, the privacy-related information of the application's user 282 might be exposed along the path. 284 There might be privacy issues introduced by the APN in this scenario. 285 Mechanisms on the proper encoding of the App-Info would be required. 287 APN is based on the trust relationship between the users, the network 288 operators and the application providers. If the users want to enjoy 289 the application-aware network services, such as game acceleration 290 provided by the network operator, they will need to sign the 291 trustworthy agreement with the network operator. If it is the 292 network operator or application provider that owns both the network 293 and application as in 4.1 and 4.2, it makes the trust relationship 294 more easily to be set up, that is, if the users sign the agreement 295 with them the relationship is established. 297 5. Security Considerations 299 In this section the security aspects of APN are evaluated in the 300 following scenarios. 302 5.1. Inter-DC Scenario 304 In order to reduce the IT investment, most enterprises have moved 305 some of their applications and data into the Cloud. For the large- 306 scale enterprises, generally their applications and data are 307 distributed across multiple clouds. The communication in between 308 clouds and datacenters represents most of the inter-DC traffic. 309 Since the servers generating the traffic often belong to certain 310 enterprise, the source and the destination of the traffic and the 311 path used are known. There is no need for doing the access control 312 even when APN is deployed in this scenario. 314 To be more general, the Inter-DC traffic is usually originated and 315 destined within the domain, and steered according to inter-DC 316 policies. The presence (or not) of APN information in data packets 317 does not interfere with the inter-DC traffic scheme and does not 318 require any additional security measure. 320 5.2. Enterprise Scenario 322 The enterprise traffic often accesses from CPE (Customer Premise 323 Equipment) towards the Internet or Clouds along the paid leased lines 324 through the controlled BNG (Broadband Network Gateway) interfaces, 325 which means that the enterprise traffic is going to be validated and 326 authorized by the BNG, as shown in Figure 2. 328 +----+ +-------+ +-------+ 329 | PC | \ | Cloud | | Cloud | 330 +----+ \---\ +---|---+ +---|---+ 331 +----+ \+------+ +-------+ +---|---+ +-----|-----+ 332 | PC |------| CPE |------| BNG |-----| Core |-----| Internet | 333 +----+ /+------+ +-------+ +-------+ +-----------+ 334 +-----+ /---/ 335 |Phone|/ 336 +-----+ 338 Figure 2. Enterprise Scenario 340 Therefore, there will be no additional security issue introduced by 341 APN in the Enterprise scenario. 343 5.3. Broadband Scenarios 345 APN may only introduce security issues when the users access the 346 operators' networks from an untrusted domain. However, as shown in 347 Figure 3, the user traffic from the home broadband will be checked 348 and authorized by the BNG, while as shown in Figure 4, the user 349 traffic from the mobile broadband will be authorized by the 5GC 350 function. 352 In the home broadband scenario, generally a home broadband user is 353 authorized using the MAC address of the RG (Residential Gateway), the 354 VLAN/QinQ, and the input port on the BNG. Whether the home broadband 355 user has bought a value-added service like game acceleration will be 356 checked further. With APN, the value-added service can be indicated 357 by the App-Info carried in the packets, and it will be checked 358 against the one that the operator has configured in the BNG. If the 359 carried App-Info matches the corresponding policy entry for the user, 360 the validation is passed and the access control is released, so the 361 user can start enjoying the acceleration service for its application. 363 +----+ +-------+ +-------+ 364 | PC | \ | Cloud | | Cloud | 365 +----+ \---\ +---|---+ +---|---+ 366 +-----+ \+------+ +-------+ +---|---+ +-----|-----+ 367 | STB |-----| RG |------| BNG |-----| Core |-----| Internet | 368 +-----+ /+------+ +-------+ +-------+ +-----------+ 369 +-----+ /---/ 370 |Phone|/ 371 +-----+ 373 Figure 3. Home Broadband Scenario 375 In the mobile broadband scenario, a UE is authorized by the 5GC 376 function, and the traffic steering and QoS policy are enforced by the 377 UPF (User Plane Function) node. Whether the user has bought a value- 378 added service like game acceleration will be checked against the 379 configured policies. With APN, the value-added service can be 380 indicated by the App-Info carried in the packets, and it will be 381 checked against the one that the operator has configured in the UPF 382 node. If the carried App-Info matches the corresponding policy 383 entry, the validation is passed and the access control is released, 384 so the user can start enjoying the acceleration service for its 385 application. 387 +----+ +-------+ +-------+ 388 | PC | | Cloud | | 5GC | 389 +----+ +---|---+ +---|---+ 390 +----+ +------+ +-------+ +---|---+ +---|---+ 391 | UE | --- | gNB |------| ACC |-----| AGG |-----| UPF | 392 +----+ +------+ +-------+ +-------+ +-------+ 393 +-----+ 394 | CPE | 395 +-----+ 397 Figure 4. Mobile Broadband Scenario 399 6. Potential Security Issues and Mitigations 401 There are potentially four scenarios where APN might introducing 402 security issues. 404 6.1. One application within one terminal 406 An application in one terminal (UE) may add arbitrary App-Info 407 including its requirements on the network. 409 This issue can be tackled or resolved via the OS. If the App-Info is 410 eventually sent out along with the data packets, it can still be 411 blocked by the BNG or 5GC since it violates the already-signed 412 agreements between the users and the network operators. 414 Note that this is not different from any service/SLA selection scheme 415 where the application/user traffic may be marked but anyway checked 416 at ingress for correctness of the marking. 418 6.2. Two different applications within one terminal 420 One application in the terminal (UE) may add the App-Info of another 421 application in the same terminal. For example, the Email App 422 attempts to forge the high-level SLA guarantee of the Live Video 423 Streaming App. 425 This issue can be tackled or resolved via the OS. If the App-Info is 426 eventually sent out along with the data packets, it can still be 427 blocked by the BNG or 5GC since it violates the already-signed 428 agreements between the users and the network operators. 430 6.3. The same applications in two terminals 432 An application in one terminal may forge the App-Info of the same App 433 running in another terminal. 435 Once the App-Info is sent out along with the data packets, the 436 existing network security mechanisms such as HMAC can be utilized to 437 validate the source of the forged App-Info being sent out from. 439 6.4. App-info tampered along the way 441 The App-Info may be tampered along the way between the App-Info 442 Encapsulator and the Network Boarder Node. 444 Once the App-Info is sent out along with the data packets, the 445 existing network security mechanisms such as HMAC can be utilized to 446 validate the tampered App-Info. 448 7. IANA Considerations 450 There are no IANA considerations in this document. 452 8. Contributors 454 Chongfeng Xie 455 China Telecom 456 China 458 Email: xiechf@chinatelecom.cn 460 Liang Geng 461 China Mobile 462 China 464 Email: gengliang@chinamobile.com 465 Shuai Zhang 466 China Unicom 467 China 469 Email: zhangs366@chinaunicom.cn 471 9. Normative References 473 [I-D.li-6man-app-aware-ipv6-network] 474 Li, Z., Peng, S., Li, C., Xie, C., Voyer, D., Li, X., Liu, 475 P., Liu, C., and K. Ebisawa, "Application-aware IPv6 476 Networking (APN6) Encapsulation", draft-li-6man-app-aware- 477 ipv6-network-02 (work in progress), July 2020. 479 [I-D.li-apn-framework] 480 Li, Z., Peng, S., Voyer, D., Li, C., Geng, L., Cao, C., 481 Ebisawa, K., Previdi, S., and J. Guichard, "Application- 482 aware Networking (APN) Framework", draft-li-apn- 483 framework-01 (work in progress), September 2020. 485 [I-D.li-apn-problem-statement-usecases] 486 Li, Z., Peng, S., Voyer, D., Xie, C., Liu, P., Qin, Z., 487 Ebisawa, K., Previdi, S., and J. Guichard, "Problem 488 Statement and Use Cases of Application-aware Networking 489 (APN)", draft-li-apn-problem-statement-usecases-01 (work 490 in progress), September 2020. 492 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 493 Requirement Levels", BCP 14, RFC 2119, 494 DOI 10.17487/RFC2119, March 1997, 495 . 497 Authors' Addresses 499 Shuping Peng 500 Huawei Technologies 501 Beijing 502 China 504 Email: pengshuping@huawei.com 506 Zhenbin Li 507 Huawei Technologies 508 Beijing 509 China 511 Email: lizhenbin@huawei.com 512 Daniel Voyer 513 Bell Canada 514 Canada 516 Email: daniel.voyer@bell.ca 518 Cong Li 519 China Telecom 520 China 522 Email: licong@chinatelecom.cn 524 Peng Liu 525 China Mobile 526 China 528 Email: liupengyjy@chinamobile.com 530 Chang Cao 531 China Unicom 532 China 534 Email: caoc15@chinaunicom.cn