1. 
   

   [Technical] The LS asserts that “neither approach is currently achievable” for IMS Data Channel LI, but it provides no concrete analysis of where the current keying/encryption (e.g., DTLS-SRTP, E2E vs hop-by-hop, key ownership/termination points) prevents delivery of CC or decryption parameters, making the conclusion unverifiable and hard for SA2/SA4 to act on.

   
   


2. 
   

   [Technical] The “required (if preferred not feasible)” framing (access to encryption parameters) is potentially incompatible with LI security principles unless tightly scoped (who provides keys, under what authorization, how protected, auditability); the LS should reference the exact TS 33.126 clauses and clarify whether it expects IRI/CC delivery of session keys, key escrow, or network-terminated encryption.

   
   


3. 
   

   [Technical] Roaming cases “S8HR/N9HR model” are cited, but those are EPC/5GC roaming models and not directly an IMS/IMS Data Channel architectural term; the LS needs to map the roaming scenario to IMS entities (P-CSCF/S-CSCF/IBCF/TrGW) and identify which operator is expected to perform LI and where encryption terminates.

   
   


4. 
   

   [Technical] The interoperability gap scenario (one CSP supports IMS Data Channel, the other does not, target on the non-Data-Channel CSP) is underspecified: it’s unclear whether the session is negotiated as MSRP/SIP MESSAGE fallback, rejected, or transcoded/translated at an interconnect function, and without that call flow it’s not possible to conclude LI is impossible.

   
   


5. 
   

   [Technical] “Direct communications between two users” is ambiguous in IMS context (still network-routed SIP with media/data path via IP, or true P2P/E2E); LI feasibility depends critically on whether the data channel is end-to-end encrypted at the application layer versus protected only on access legs.

   
   


6. 
   

   [Technical] Mid-session interception is mentioned, but the LS does not specify which mid-session events break LI (e.g., re-keying, ICE restart, DTLS renegotiation, path change, handover, inter-PSAP transfer), nor what LI function fails (CC duplication, correlation, key update delivery).

   
   


7. 
   

   [Technical] The LS references TS 26.114 Figure 6.2.10.1-1 for “Data Channel Workflow,” but does not identify which nodes in that figure would need LI mediation/duplication or key access; without pinpointing the interception points, SA4/SA2 cannot derive normative architectural changes.

   
   


8. 
   

   [Technical] The request “Develop a solution and architecture for secured IMS Data Channel that enables CSPs to meet LI requirements” is too open-ended; it should propose candidate solution directions (e.g., network-terminated DTLS at SBC/TrGW, LI-friendly key management hooks, standardized key export to MDF under warrant) to avoid divergent interpretations across groups.

   
   


9. 
   

   [Technical] The LS does not address whether the LI requirement applies to both CC and IRI for IMS Data Channel, and how correlation identifiers (SIP dialog identifiers, data channel identifiers, 5-tuple changes) would be maintained—this is often the practical blocker in multi-leg/interconnect scenarios.

   
   


10. 
    

    [Editorial] The document cites TS 33.126 requirements by IDs (R6.4-160/170/180/190) but does not quote or summarize them; readers outside SA3-LI may not know what each requirement mandates, weakening the clarity and actionability of the LS.

    
    


11. 
    

    [Editorial] Terminology is inconsistent/unclear: “CSP” is used without definition (operator, service provider, or IMS network provider), and “IMS without IMS Data Channel feature” should be aligned to the exact feature name and spec references in SA4/CT (e.g., IMS Data Channel per TS 26.114/related stage 2/3).

    
    


12. 
    

    [Editorial] The LS claims “major complications for CSPs to respect their national regulations” but does not separate regulatory obligation from 3GPP requirement compliance; it would be better to state the specific 3GPP compliance risk (non-fulfilment of TS 33.126 LI requirements) and the impacted deployment scenarios.

    
    

1) Technical Accuracy

1.1 “Current encryption architecture prevents meeting TS 33.126 R6.4-160/170/180/190”

• Questionable claim without evidence. The LS asserts non-compliance with specific TS 33.126 requirements but does not:


• quote the exact requirement text,


• map each requirement to IMS Data Channel procedures in TS 26.114 / related specs,


• identify which LI interface deliverables (IRI/CC) fail and at which interception point(s).


• Risk of mis-scoping: TS 33.126 is an architecture and requirements spec for LI; compliance depends on the overall system (network functions, mediation, handover), not only “IMS Data Channel encryption architecture”. The LS reads as if encryption design alone determines compliance, which is not technically rigorous.

1.2 “Two acceptable approaches for LI: plaintext copy preferred; otherwise provide encryption parameters”

• Potentially misleading framing.


• In 3GPP LI, the expectation is typically that the operator can provide CC in a form usable by LEA, but the exact mechanism (plaintext vs keys vs operator-side decryption) is constrained by national law and 3GPP security principles.


• Stating “preferred plaintext copy without confidentiality protection” is normatively loaded and may conflict with end-to-end security expectations and privacy/security requirements in other 3GPP specs. If the IMS Data Channel is designed to be E2E-protected, “plaintext copy” at the operator may be impossible by design.


• “Access to encryption parameters that enable decryption” is also underspecified: does it mean session keys, key derivation material, or something else? If keys are endpoint-derived (e.g., E2EE), the network may not possess them.

1.3 Roaming references: “S8HR/N9HR model”

• Terminology mismatch / unclear applicability.


• S8HR/N9HR are EPC/5GC roaming models primarily discussed in the context of user plane anchoring and home routing. IMS roaming for VoLTE/VoNR has its own models (e.g., LBO vs home-routed IMS, visited/home IMS interconnect).


• The LS does not explain how S8HR/N9HR specifically impacts IMS Data Channel keying, media anchoring, or LI interception points. As written, it appears to conflate roaming models across domains without a clear technical chain.

1.4 “Interoperability case: one CSP uses IMS Data Channel, other does not; target on CSP without Data Channel; cannot intercept content”

• Not demonstrated and may be incorrect depending on architecture.


• If the far-end CSP does not support IMS Data Channel, the session may:
  
  
  • fall back to MSRP/SIP MESSAGE/other IMS media, or
  
  
  • fail to establish the data channel.
  
  
  
  


• If it falls back, LI may be possible via existing IMS LI mechanisms. If it fails, there is no content to intercept.


• If interworking exists via gateways, interception feasibility depends on where media terminates/anchors. The LS provides no call flow or interworking assumptions.

1.5 “Direct communications between two users (when at least one is an LI target)”

• Ambiguous. “Direct communications” could mean:


• IMS peer-to-peer media (still via network), or


• device-to-device / sidelink / local breakout, or


• E2EE application-layer channel over IMS signaling.

Each has different LI implications. The LS does not define the scenario.

2) Completeness

2.1 Missing normative references and scope definition

• The LS references TS 26.114 Figure 6.2.10.1-1 only. That is insufficient to support LI compliance claims.


• Missing references likely needed:


• TS 33.126 (exact clauses for R6.4-160/170/180/190)


• IMS security/key management specs relevant to IMS Data Channel (if any exist in SA3/SA4 scope)


• IMS media transport specs (e.g., SRTP/DTLS-SRTP/MSRP/TLS, depending on what “Data Channel” uses)


• LI handover/interface specs (e.g., TS 33.108/33.128 family, depending on the LI architecture used)


• Any SA4 specs defining IMS Data Channel security procedures (if in TS 26.114 or related).

2.2 No problem decomposition by interception type

• LI requirements typically distinguish:


• IRI (signaling-related information),


• CC (content),


• interception points and mediation.


• The LS does not state whether the gap is:


• inability to obtain CC at all,


• inability to associate CC with IRI,


• inability to perform mid-session activation,


• inability to deliver CC in required format,


• inability to intercept in roaming/interconnect due to anchoring.

2.3 No call flows / keying flows / trust model

• For an encryption-related LI gap, the LS should include at least one of:


• call flow showing where encryption is applied/terminated,


• key establishment flow (who has keys),


• whether encryption is hop-by-hop (operator-terminating) or end-to-end (UE-to-UE),


• where LI interception function would sit.

2.4 “Mid-session interception” not analyzed

• The LS mentions mid-session interception but provides no analysis of:


• whether keys rotate,


• whether re-keying is possible,


• whether LI activation triggers any re-negotiation,


• whether buffering/duplication is feasible.

2.5 No explicit requirements to SA2/SA4

• “Develop a solution and architecture” is too broad.


• Missing: concrete asks such as:


• define an interception point for IMS Data Channel media,


• define a key escrow / network-terminated security option,


• define interworking behavior when one side lacks feature support,


• define roaming anchoring requirements for LI.

3) Impact Assessment

3.1 Potential cross-spec impact is high but not acknowledged

If SA2/SA4 were to “enable LI” for an encrypted data channel, possible impacts include:

- Architecture changes (SA2): anchoring, media path requirements, interconnect assumptions, roaming models.

- Codec/media framework changes (SA4): security profiles, key management, transport selection, fallback behavior.

- Security architecture changes (SA3): if network access to plaintext or keys is introduced, it may:

- weaken confidentiality guarantees,

- create new attack surfaces,

- require new trust assumptions and compliance controls.

The LS does not discuss these trade-offs.

3.2 Backward compatibility and deployment impact not addressed

• If new LI-enabling mechanisms require:


• new SIP/SDP attributes,


• new key management procedures,


• new network functions (media relays/anchors),


• new UE behavior,
  
  then existing deployments may break or require upgrades. The LS does not assess this.

3.3 Inter-operator implications

• Interoperability across CSPs implies interconnect agreements and possibly standardized interconnect security profiles.


• If LI requires media anchoring in a particular domain, that can conflict with interconnect models and commercial arrangements. Not discussed.

4) Feasibility

4.1 Feasibility depends entirely on whether encryption is E2EE or hop-by-hop

• If IMS Data Channel is end-to-end encrypted with keys only at UEs, then:


• “provide plaintext copy” is infeasible without redesigning security goals.


• “provide encryption parameters” is infeasible unless keys are escrowed or derivable by the network—both are major security/policy changes.


• If it is hop-by-hop (e.g., UE–P-CSCF/AS/media relay), then LI may be feasible by intercepting at the termination point, but the LS does not clarify.

4.2 Mid-session LI feasibility requires explicit re-key / duplication strategy

• Practical LI activation mid-session typically requires:


• ability to start duplicating media at an anchor,


• or ability to obtain keys for the current session epoch,


• or forcing re-negotiation.
  
  None is described.

4.3 Roaming feasibility requires clear anchoring model

• In roaming, LI responsibilities can be home/visited dependent. Without specifying whether IMS Data Channel media is home-routed, visited-routed, or direct, feasibility cannot be assessed.

5) Weaknesses

5.1 Assertions without substantiation

• The LS makes strong compliance claims (“critical gaps”, “neither approach achievable”) without:


• evidence,


• flows,


• spec citations beyond a figure reference.

5.2 Conflation of regulatory requirement with technical mechanism

• The LS implicitly assumes LI must be satisfied by plaintext or key access. 3GPP typically specifies capabilities and interfaces; national regulation determines what is required. The LS should be careful not to mandate a particular “preferred” approach without grounding in 3GPP normative text.

5.3 Unclear scope and terminology

• “IMS Data Channel” is not defined in the LS (transport, security, termination points).


• “Direct communications” and the roaming models are ambiguous.

5.4 No threat/security impact discussion

• Any LI-enabling change to encryption/key handling has significant security implications. The LS does not acknowledge or propose mitigations (audit, access control, key protection, lawful authorization handling, etc.).

6) Suggestions for Improvement

6.1 Add a structured gap analysis table

For each cited TS 33.126 requirement (R6.4-160/170/180/190):

- quote the requirement text (or summarize precisely with clause reference),

- state the IMS Data Channel feature behavior (with TS 26.114 clause references),

- identify the failing point (e.g., no interception point, no key access, no association to IRI),

- specify whether the gap is for IRI, CC, or both,

- indicate whether the gap is specific to roaming/interconnect/mid-session.

6.2 Provide at least two concrete call flows

Include message/media/keying flows for:

1) Roaming (clearly specify: IMS home-routed vs LBO; and how data channel media is routed)

2) Inter-CSP interconnect (both sides support vs one side does not)

Mark:

- where encryption is applied/terminated,

- where an operator could realistically duplicate content,

- where LI mediation would obtain CC/IRI.

6.3 Clarify the security model of IMS Data Channel

Explicitly state:

- transport protocol (e.g., RTP/RTCP, SCTP/DTLS, MSRP, QUIC, etc.),

- security protocol (DTLS-SRTP, TLS, etc.),

- key establishment (SDP offer/answer, certificates, identity binding),

- whether keys are UE-only or network-terminated.

Without this, SA2/SA4 cannot act.

6.4 Narrow and make the “Action Requested” implementable

Instead of “develop a solution”, propose specific study items/questions, e.g.:

- Define an operator-controlled media anchoring option for IMS Data Channel to enable LI (with clear interoperability rules).

- Define fallback/interworking behavior when the peer network does not support IMS Data Channel (and LI expectations in fallback).

- Define mid-session LI activation handling (e.g., re-key triggers, duplication start, buffering).

- Define roaming/interconnect responsibilities (home vs visited interception, where CC is obtained).

6.5 Address security/privacy trade-offs explicitly

Add a section assessing:

- impact on confidentiality and threat model,

- key protection requirements if any key material is exposed to network functions,

- audit and authorization controls aligned with LI principles.

6.6 Identify impacted specs and propose ownership

List candidate specs likely impacted and which group should lead:

- SA2: architecture/roaming/interconnect anchoring

- SA4: media transport/security profiles and interworking

- SA3: security requirements and LI alignment (and ensure no contradiction with security objectives)

6.7 Validate the roaming terminology

If S8HR/N9HR is truly relevant, explain the mapping to IMS Data Channel routing and LI points. Otherwise, replace with correct IMS roaming models and references.

Bottom line

The LS raises a plausible concern (LI vs encrypted IMS Data Channel), but in its current form it is too assertion-based and underspecified to drive actionable work in SA2/SA4. Strengthening it with precise requirement mapping, concrete flows, and a clear security/termination model is necessary before meaningful specification impact or feasibility can be evaluated.