Summary of S4-260205: External Resources for DC Applications
Introduction
This contribution from Qualcomm addresses the issue of access to external resources by IMS Data Channel (DC) applications, as raised by GSMA. The document proposes solutions for enabling DC web applications to securely access third-party services while maintaining security and compliance with web standards.
Use Case Description
The document describes a scenario from GSMA NG UPG where:
- A UE-resident web application is delivered by a DC Application Server (DC AS)
- The application integrates an external AI Large Language Model (LLM) hosted at a third-party origin over HTTPS
- Authorization is handled via OAuth 2.0
- After the DC AS serves the UI over the Data Channel, the application must contact external endpoints to:
- Submit prompts
- Stream partial outputs (via WebSockets, Server-Sent Events, or HTTP/2/3)
- Fetch auxiliary sub-resources (scripts, fonts, images, authorization panels)
Potential Solutions
3.1 MF as TLS Tunnel or HTTP(S) Proxy
Rejected Approach:
The document strongly recommends against using the MF as an HTTP(s) proxy that terminates TLS connections, as this:
- Exposes user credentials and application data to the MF
- Creates extreme security risks with potential data leakage
Proxy-Tunnel Approach Analysis:
The document analyzes a proxy-tunnel over IMS Data Channel approach where:
- UE uses DTLS/SCTP association established during call setup
- Application data channels are opened for tunneling to external origins via MF
- Per TS 26.114, each application data channel requires a=dcmap attribute in SDP
- UE sends subsequent SDP offer (via SIP re-INVITE or SIP UPDATE per TS 24.229) to add/update channels
- MF validates requested authority, opens TCP connection to external origin, and confirms tunnel
- UE runs full TLS handshake to origin through tunnel, preserving end-to-end confidentiality
Performance and Scaling Issues:
- One external destination maps to one application data channel
- Each additional channel requires SDP change and new offer/answer round-trip
- P-CSCF and S-CSCF process each update
- Non-trivial delay before application bytes can flow on new stream
UE Implementation Complexity:
- Standard browser/OS HTTP stacks don't expose IMS primitives
- Web application must intercept fetch() and XMLHttpRequest
- Must trigger IMS client to create subsequent SDP offer with new a=dcmap entries
- Must wait for answer before serializing HTTP over SCTP stream
- Must parse response bytes and reconstruct JavaScript Response objects
- Complex error handling spanning Service Worker, SIP offer/answer, SCTP stream state, MF policy, and external origin
- Long-lived responses (e.g., Server-Sent Events) increase fragility
- Service Worker must bridge flow control between browser and SCTP stream
- SCTP reset or mid-call session change truncates stream, requiring recovery logic
Provider-Side Security and Operations Issues:
- OAuth workflows rely on source network and geolocation context
- Provider observes MF's egress address rather than UE's carrier address
- Tokens issued in one network context may appear replayed from another
- Refresh flows validating by IP continuity may fail
- Provider heuristics depending on IP reputation, ASN alignment, or regional consistency can misclassify traffic
- Aggregation behind single MF address collapses attribution
- Rate limiting, quota enforcement, abuse mitigation, and usage-based billing lose per-user fidelity
- Single abusive client can trigger blocks affecting all users sharing the MF
- Geolocation and regulatory controls reflect MF's location instead of UE's, creating false rejections and compliance issues
- Audit trails record MF as caller, complicating incident response and per-user tracing
3.2 CSP Enforced at the UE with CORS at the External Origin
Recommended Approach:
The CSP-centric solution:
- Keeps policy expression at the DC Application Server
- Enforcement at the UE
- Fully compatible with all web browsers
Mechanism:
- DC AS delivers DC web application and declares strict Content-Security-Policy in HTTP response over bootstrap data channel
- Policy starts from "default deny" then allows only required external origins for each resource class
- UE enforces effective CSP locally
- Any fully qualified URL not admitted by policy is blocked before network connection is made
Policy Constraints:
- connect-src constrains connections for data exchange
- Only authorization server and specific API endpoints needed by LLM workflow are listed
- Script execution limited to code authorized by DC AS using per-response nonce or stable hashes
CSP and CORS Integration:
- CSP operates together with CORS
- Even when CSP admits an origin, cross-origin request only proceeds if external server opts in with correct Access-Control-Allow-Origin value
- When credentials are present, external server returns caller origin (no wildcards)
- Keeps OAuth flows predictable
- Tokens sent only to hosts listed in connect-src
- Frames and form submissions restricted to explicit authorization domains
- No network element added
- Preserves end-to-end TLS between UE and external provider
Example Headers:
Baseline CSP with default deny and nonce-based scripts:
Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-<per-response-random>' 'strict-dynamic'; style-src 'self'; img-src 'self' data:; font-src 'self'; connect-src 'self'; frame-src 'none'; object-src 'none'; base-uri 'none'; frame-ancestors 'none'; upgrade-insecure-requests; block-all-mixed-content
LLM integration with OAuth authorization server:
Content-Security-Policy: default-src 'self'; connect-src 'self' https://api.example-llm.com https://auth.example-llm.com; script-src 'self' 'nonce-<per-response-random>' 'strict-dynamic'; style-src 'self'; img-src 'self' data:; font-src 'self'; frame-src https://auth.example-llm.com; form-action 'self' https://auth.example-llm.com; object-src 'none'; base-uri 'none'; frame-ancestors 'none'; upgrade-insecure-requests; block-all-mixed-content
Way Forward
Proposed Approach
Adopt CSP and CORS based approach for secure external resource access by IMS Data Channel web applications because it:
- Keeps standard web security model
- Preserves end-to-end TLS between UE and external origins
- Avoids introducing network intermediaries that terminate TLS or require per-destination IMS signaling
Proposed Clarifications for TR 26.814 (FS_DCE_MED Rel-20)
-
Application Origin: Clarify that DC AS is the application origin for delivered web content, and that UE applies standard same-origin policy
-
External Resource Fetching: Clarify that external resources may be fetched directly by UE over HTTPS, subject to UE enforcement of Content-Security-Policy delivered by DC AS
-
CORS Processing: Clarify that cross-origin requests follow standard CORS processing at external origin, including rules for credentialed requests
-
Informative Examples: Provide informative examples for common patterns including:
- OAuth authorization
- WebSockets
- Server-Sent Events
-
HTTP/2 or HTTP/3 streaming
-
Scope Boundaries: Clarify that:
- 3GPP specifies transport and application delivery over IMS Data Channel
- Trust computation and content source validation follow existing platform and browser security mechanisms, consistent with SA3 feedback
Additional Considerations
Regulation:
- Per SA1 guidance, applicability of telecom regulation to Data Channel applications depends on local regulation and service context
CAPIF Framework:
- If use case requires network-controlled exposure of third-party APIs, CAPIF framework in TS 23.222 can be considered as reference (per SA6 feedback)
- Complementary to CSP and CORS approach for web application resource access
Lawful Intercept (LI):
- Additional incoming liaison statements (e.g., SA3-LI requests on LI requirements for IMS Data Channel) should be tracked under KI#4 of FS_DCE_MED
- SA4 should document which media plane configurations provide:
- Decrypted content at network element (e.g., when MF terminates security association and has access to plaintext)
- No decrypted content at network element (e.g., when MF only forwards encrypted packets, or when DTLS is end-to-end between UEs)
- SA4 should coordinate with SA2 and SA3 on required stage 2 and security updates, including DTLS profile choices and LI related procedures
[Technical] The described “via DC AS” mechanism relies on TS 23.228 allowing an IMS AS to change the endpoint type from P2P to P2A, but the contribution does not specify which SDP attribute/parameter carries this endpoint type (e.g., within
a=3gpp-req-app) nor how the UE is expected to interpret it, leaving the interworking behavior under-defined.[Technical] The claimed misalignment with TS 26.114 6.2.10.3 is plausible, but the contribution stops at identifying the conflict and does not propose concrete normative resolution (e.g., an explicit exception allowing modification of
adc-stream-id-endpointin interworking cases, or an alternate signaling indicator), so it cannot be implemented consistently.[Technical] The statement that the terminating UE “returns bootstrap DC negotiation result with port number zero” when it doesn’t support IMS DC needs validation against the exact AC.7.9 procedure; if this is only one rejection method (vs. omitting m-line, setting port 0, or rejecting attribute), the text risks being incorrect or incomplete for real SDP negotiation behavior.
[Technical] The “DCSF recognizes rejection and establishes bootstrap data channels only between originating UE and MF” is architecturally unclear: if the terminating UE does not support IMS DC, it is not obvious why a bootstrap data channel to MF is still required/usable, and what application-level function it serves without a peer DC endpoint.
[Technical] The “via MF” interworking description says MF performs transcoding “upon DCSF instructions,” but does not specify what is transcoded (data channel content vs. associated RTP media) and how that maps to MTSI/MMTEL media; as written it conflates data channel interworking with media transcoding.
[Technical] The contribution introduces “data channel associated media” and “non-data channel associated media” flows, but does not define the association mechanism (SDP grouping,
mid,bundle, or 3GPP-specific linkage), which is essential for interworking and for the UE to bind DC and RTP streams correctly.[Technical] The “via DC AS: Not specified (e.g., SMS)” path is too hand-wavy for a key issue text: SMS is not an IMS Data Channel media interworking method in TS 26.114 context, and suggesting it without constraints risks misleading conclusions in TR 26.814.
[Technical] The text says DCSF determines interworking “based on session event notification from IMS AS,” but does not identify the relevant interface/procedure (e.g., ISC event package, SIP dialog event, or proprietary notification), making the trigger for switching P2P→P2A non-verifiable.
[Technical] The identified UE need—“capability to identify when interworking mode is enabled”—is correct, but the contribution does not propose where this indication should appear (SDP attribute, SIP header, or application-layer signaling), nor how it interacts with TS 26.114’s constraint on mirroring
a=3gpp-req-app.[Editorial] The document mixes entities and terminology (MF, DC AS, “IMS Data Channel functional entities,” DCSF) without a consistent definition set or reference to the exact TS 23.228 functional model, making it hard to map the described flows to standardized nodes.
[Editorial] Several claims are attributed to TS 23.228 clause “AC.7.9” without quoting the exact step/behavior; for a gap analysis, the contribution should cite the precise subclause text and the exact SDP/attribute behavior to avoid misinterpretation.
[Editorial] The section titles imply TR 26.814 text (“X.2.1”, “X.2.2”), but the contribution summary does not provide the actual proposed wording, so reviewers cannot assess whether the inserted TR text is scoped appropriately and aligned with existing TR structure and terminology.