Internet-Draft SCONEPRO Privacy June 2024
Tomar, et al. Expires 29 December 2024 [Page]
Workgroup:
SCONEPRO
Internet-Draft:
draft-tomar-sconepro-privacy-02
Published:
Intended Status:
Informational
Expires:
Authors:
A. Tomar
Meta
W. Eddy
Meta
A. Tiwari
Meta
M. Joras
Meta

SCONEPRO Privacy Properties and Incentives for Abuse

Abstract

This document discusses privacy properties of the SCONEPRO metadata or network-to-host signals. This covers questions that were raised during the IETF 119 BoF and subsequent discussions. It is not intended to be published as a separate RFC but might be incorporated as a part of the security considerations or other content within eventual SCONEPRO RFCs together with other documents covering security considerations. Other documents will address additional aspects of the security considerations for SCONEPRO metadata.

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/.

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 29 December 2024.

Table of Contents

1. Introduction

The general problem statement for Secure Communication of Network Properties (SCONEPRO) is described in the video optimization requirements document [I-D.joras-sconepro-video-opt-requirements], including the shaping or throttling that Communication Service Providers (CSPs) perform [ABR-Video-Shaping].

There were questions rasied at the IETF 119 BoF on SCONEPRO regarding privacy considerations, include:

  1. What are the privacy properties of the SCONE signal? If making the signal available to applications is the goal, does that have unwanted properties?

  2. Can the signal be designed so that there is no incentive to fake it, similar to ECN?

This document provides additional context necessary, and then directly addresses these questions.

2. Conventions and Definitions

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

3. SCONEPRO Context

SCONEPRO is focusing on streaming video optimization use-cases through network-assisted application-level self-adaptation of media/video bit rate. SCONEPRO addresses the following high-level problem statement:

  1. Currently Communication Service Provider (CSP) networks (mainly cellular and satellite networks) perform bit-rate throttling (either shaping or policing) of streaming video flows. The motivation behind throttling may vary across CSPs. For example, the motivation can be:

    • To support different data rates based on the subscribers' data plans;

    • To reduce egress towards radio base-stations in downlink direction;

    • To limit the overall capacity/bandwidth required and to manage capex requirements (e.g. need for more RF spectrum and deployment of more radio base-stations), etc.

  2. To perform throttling, CSP networks need to detect streaming video flows, which uses deep packet inspection and trial decryption of QUIC initial packets in order to decode and read the Server Name Indication (SNI) field present in initial ClientHello messages. This requires significant compute resources. Throttling (shaping or policing) also requires nontrivial compute and memory resources. For details refer to [ABR-Video-Shaping].

  3. Throttling in the CSP network has a significant negative impact on streaming video application quality of experience (QoE), and it also degrades mobile User Equipment (UE) battery performance.

  4. An equivalent reduction in network traffic can be achieved more intelligently via self-adaptation by Content Application Providers (CAPs), because CAPs can actually measure QoE parameters and can tune their self adaptation strategy much more effectively than the QoE-blind approach taken by CSP's network throttlers. Hence, this approach of self-adaptation by CAPs is much superior in terms of end user QoE compared to CSP-led network throttling.

  5. CSPs currently use intentional (artificial) network throttling as a way to create service differentiation between users on different payment plans and to enforce fair usage plans.

  6. CAPs do not and should not have access to subscriber payment plan information.

  7. There is a need for a solution to the above multi-objective optimization problem which achieves both: (a) superior user QoE, and (b) differentiated data limitation consistent with subscriber plans.

  8. One potential solution to this problem is self-adaptation of video sessions by CAPs. Since the subscriber plan information must live within the CSP network domain, the CSP network can abstract out the different traffic profiles suited to different subscriber plans and provide the abstracted information to application-clients running on the UEs for CAP self-adaptation implementations.

For details, refer to the proof of concept trial [SCONEPRO-MASQUE-POC] and YouTube plan aware streaming [YouTube].

The SCONEPRO network rate-limiting information (metadata) and the means of conveying the information is to be defined by the IETF.

4. Privacy Properties

This document section describes the privacy properties of the SCONEPRO signal and considerations with regard to making the signal available to applications.

It is required that the SCONEPRO signal shall not carry information that includes either:

To help describe the SCONEPRO approach to meet these privacy requirements, as well as to ensure the signal does not have unwanted properties, the next subsections provide an example and then general approach.

4.1. Mobile Network Example

Using a mobile network as a reference, the diagram in Figure 1 explains how CSP networks implement throttling to support different data rates based on the subscribers' data plans.

                 +-----+
                 | HSS |
                 +-----+
                    |
                 +-----+          +------+
                 | MME |          | PCRF |
                /+-----+\         +------+
               /         \            |
              /           \           |         ___  __
             /             \          |        /   )(  \
+----+   +-----+        +------+  +------+    (         )   +-----+
| UE |---| eNB |--------| S-GW |--| P-GW |---( Internet )---| CDN |
+----+   +-----+        +------+  +------+    (        _)   +-----+
                                               (__(___)
Figure 1: Mobile Network Data Flow

In order to perform throttling to enable different data-rates based on the subscribers’ data plans, the CSP network need to support following high-level functionalities:

  1. Detect the streaming video flows.

  2. Identify the bearer associated with the flow.

    • Bearer is a logical pipe between UE (Mobile phone) and P-GW (PDN Gateway) to carry packets belonging to one or more IP flows. IP flows (aka service data flows -SDFs) may belong to one or more services. All the service data flows within a bearer gets the same level of QoS.

  3. Identify the subscriber who is using this service/flow by using mapping between bearer and subscriber ID (IMSI).

  4. Extract the network’s policy associated with a subscriber.

  5. Activate throttling to limit the flow’s bit-rate according to subscribers’ data plans.

This is performed in the network element which is on the data path and has access to the subscriber policies through standard interface with PCRF (Policy Charging and Rule function). In a 4G network this network-element is P-GW (PDN Gateway) and in a 5G network this network-element is UPF (User Plane Function). Note - UPF is not shown in above diagram as above diagram is for 4G mobile network. UPF is equivalent to P-GW in the 5G mobile network.

4.2. SCONEPRO's Approach

To meet the privacy requirements as well as to ensure that signal does not have unwanted properties, SCONEPRO proposes following approach:

  1. Use an on-path interface between the user's application end-point and network element to exchange the SCONEPRO signal. This should be the same on-path interface that has already been established between application end-point and network element to carry the video flow whose bit-rate needs to be regulated. Due to the usage of an on-path interface there is no need to exchange additional subscriber specific information (that could have been otherwise used to identify the subscriber) between CSP network and application end-point to establish association between the flow and scone signaling.

  2. Network element to be involved in SCONEPRO signaling should be on data-path and should have access to the subscriber policies. This network element should calculate the target bit-rate for the specific flow based on subscribers’ data plan, network configuration & capacity and CSP network policy and share only the just enough information (for e.g. video/media bit-rate etc. Exact metadata and data-types to be defined during the solution definition phase of SCONEPRO) with application end-point via SCONEPRO signaling. This would ensure that SCONEPRO signal does not carry the network's policy associated with a subscriber and it does not carry unwanted network information/properties.

Note - Information such as video/media bit-rate, that is required to be shared by a network device with client application end-point using SCONEPRO signal can already be learnt by application end-point currently, through various mechanisms (the effect of on-path throttlers is clearly visible by observing application traffic by third party tools like PCAP). So as part of SCONEPRO scope we are not proposing, network to share any information with application endpoints which can not be known without SCONEPRO, rather objective is that such information be made explicit.

5. Incentives for Abuse

In early discussion, at the IETF 119 BoF session, it was pointed out that possible incentives for abuse need to be considered, and that a good example existing network-to-host signalling case is Explicit Congestion Notification (ECN), for which the impact of both lying/cheating hosts and network devices has been analyzed, and for which there are no strong incentives for either hosts or network devices to unnecessarily forge or tamper with ECN codepoints.

Note, why ECN is not suitable as a method to meet SCONEPRO requirements is a separate topic, discussed in another document [I-D.tomar-sconepro-ecn], while the discussion below is focused on considering ECN operation only as an inspiration for properties SCONEPRO signaling should have.

ECN is an extension to the Internet Protocol. ECN allows end-to-end notification of network congestion without dropping packets. ECN is an optional feature that may be used between two ECN-enabled endpoints when the underlying network infrastructure also supports it. In general both classic ECN [RFC3168] and L4S ECN [RFC9330] [RFC9331] [RFC9332] are mechanisms to send end-to-end notification of network congestion. And it relies on following principles:

  1. Sender to set the ECT code-points correctly for a particular flow.

  2. Receiver to send the feedback back to the sender correctly based on CE value.

  3. Network elements to set the CE bit correctly based on actual congestion conditions in the network.

  4. ECN codepoints are not bleached or remarked within the network, other than to set the CE bit when appropriate.

The case of SCONEPRO is similar in many ways to ECN:

6. Security Considerations

SCONEPRO security considerations are discussed in the other documents covering specific network-to-host signaling methods and their implications. This document provides answers to questions regarding privacy of the SCONEPRO signaling and metadata. There are no additional security considerations raised by this.

Other security considerations for SCONEPRO signalling will be covered in separate Internet-Drafts (such as [SCONEPRO-QUIC]).

7. IANA Considerations

This document has no IANA actions.

8. References

8.1. Normative References

[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/rfc/rfc2119>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/rfc/rfc8174>.

8.2. Informative References

[ABR-Video-Shaping]
Ihlar, M., "ABR Video Shaping", , <https://datatracker.ietf.org/meeting/119/materials/slides-119-sconepro-how-networks-shape-traffic-02>.
[I-D.joras-sconepro-video-opt-requirements]
Joras, M., Tomar, A., Tiwari, A., and A. Frindell, "SCONEPRO Video Optimization Requirements", Work in Progress, Internet-Draft, draft-joras-sconepro-video-opt-requirements-00, , <https://datatracker.ietf.org/doc/html/draft-joras-sconepro-video-opt-requirements-00>.
[I-D.tomar-sconepro-ecn]
Tomar, A., Ihlar, M., Eddy, W., Swett, I., Tiwari, A., and M. Joras, "SCONEPRO Need for Defining A New On-Path Signaling Mechanism", Work in Progress, Internet-Draft, draft-tomar-sconepro-ecn-01, , <https://datatracker.ietf.org/doc/html/draft-tomar-sconepro-ecn-01>.
[RFC3168]
Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, DOI 10.17487/RFC3168, , <https://www.rfc-editor.org/rfc/rfc3168>.
[RFC9330]
Briscoe, B., Ed., De Schepper, K., Bagnulo, M., and G. White, "Low Latency, Low Loss, and Scalable Throughput (L4S) Internet Service: Architecture", RFC 9330, DOI 10.17487/RFC9330, , <https://www.rfc-editor.org/rfc/rfc9330>.
[RFC9331]
De Schepper, K. and B. Briscoe, Ed., "The Explicit Congestion Notification (ECN) Protocol for Low Latency, Low Loss, and Scalable Throughput (L4S)", RFC 9331, DOI 10.17487/RFC9331, , <https://www.rfc-editor.org/rfc/rfc9331>.
[RFC9332]
De Schepper, K., Briscoe, B., Ed., and G. White, "Dual-Queue Coupled Active Queue Management (AQM) for Low Latency, Low Loss, and Scalable Throughput (L4S)", RFC 9332, DOI 10.17487/RFC9332, , <https://www.rfc-editor.org/rfc/rfc9332>.
[SCONEPRO-MASQUE-POC]
Joras, M., "SCONEPRO MASQUE POC", , <https://datatracker.ietf.org/meeting/119/materials/slides-119-sconepro-proof-of-concept-trial-02>.
[SCONEPRO-QUIC]
Joras, M. and M. Ihlar, "SCONEPRO QUIC Protocol", , <https://github.com/mjoras/sconepro-quic-protocol>.
[YouTube]
YouTube, "YouTube Plan Aware Streaming", , <https://datatracker.ietf.org/meeting/119/materials/slides-119-sconepro-youtube-plan-aware-streaming-01>.

Acknowledgments

This document represents collaboration and inputs from others, including:

Authors' Addresses

Anoop Tomar
Meta
Wesley Eddy
Meta
Abhishek Tiwari
Meta
Matt Joras
Meta