C.3 ETSI TS 102 232-1 and ETSI TS 102 232-7

33.1083G Security3GPPHandover interface for Lawful Interception (LI)Release 17TS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

C.3.1 General

Functions having an HI3 interface may support the use of ETSI TS 102 232-1 [104] and ETSI TS 102 232-7 [105] to realise the interface.

In the event of a conflict between either specification and the present document, the terms of the present document shall apply.

C.3.2 Usage for realising HI3The CC sent over HI3 is structured as a header and a payload. The header contains general information like LIID, timestamp, correlation information (as for example defined in ETSI TS 102 232-1 [104]). The payload contains content of communication based on information that the MF has received from sources in the network. CC defined as passing over the HI3 interface shall be passed as described in ETSI TS 102 232-7 [105] clauses 5 and 6.

NOTE: ETSI TS 102 232-1 [104] specifies in clause 6.4 a transport layer based on TCP. However, based on agreement between network operator and LEA, in scenarios where it may not be possible to achieve the necessary LI data rates based on the transport layer based on single TCP connection, alternative profiles may be considered (e.g. based on UDP, multi path TCP or other protocols). Any alternative profile needs to ensure that LI reliability, security and completeness requirements as specified in TS 33.126 [106] are met.

Annex D (informative):
LEMF requirements – handling of unrecognised fields and parameters

During decoding of a record at the LEA, the following exceptional situations may occur:

1) Unrecognized parameter: The parameter layout can be recognized, but its name is not recognized:
The parameter shall be ignored, the processing of the record proceeds.

2) The parameter content or value is not recognized or not allowed:
The parameter shall be ignored, the processing of the record proceeds.

3) The record cannot be decoded (e.g. it seems to be corrupted):
The whole record shall be rejected ignored.

NOTE: In cases 2 and 3, the LEMF may wish to raise an alarm to the operator (NO/AN/SP) administration centre. For case 1, no special error or alarm procedures need be started at the LEA, because the reason may be the introduction of a new version of the specification in the network, not be an error as such security aspects.

Annex E (informative):
Bibliography

The following material, though not specifically referenced in the body of the present document (or not publicly available), gives supporting information.

1. ITU‑T Recommendation X.25: "Interface between Data Terminal Equipment (DTE) and Data Circuit-terminating Equipment (DCE) for terminals operating in the packet mode and connected to public data networks by dedicated circuit".

2. Void.

3. Void.

4. EN 300 061‑1: "Integrated Services Digital Network (ISDN); Subaddressing (SUB) supplementary service; Digital Subscriber Signalling System No. one (DSS1) protocol; Part 1: Protocol specification".

5. EN 300 097‑1 including Amendment 1: "Integrated Services Digital Network (ISDN); Connected Line Identification Presentation (COLP) supplementary service; Digital Subscriber Signalling System No. one (DSS1) protocol; Part 1: Protocol specification".

6. EN 300 098‑1: "Integrated Services Digital Network (ISDN); Connected Line Identification Restriction (COLR) supplementary service; Digital Subscriber Signalling System No. one (DSS1) protocol; Part 1: Protocol specification".

7. EN 300 130‑1: "Integrated Services Digital Network (ISDN); Malicious Call Identification (MCID) supplementary service; Digital Subscriber Signalling System No. one (DSS1) protocol; Part 1: Protocol specification".

8. EN 300 138‑1 including Amendment 1: "Integrated Services Digital Network (ISDN); Closed User Group (CUG) supplementary service; Digital Subscriber Signalling System No. one (DSS1) protocol; Part 1: Protocol specification".

9. EN 300 185‑1: "Integrated Services Digital Network (ISDN); Conference call, add-on (CONF) supplementary service; Digital Subscriber Signalling System No. one (DSS1) protocol; Part 1: Protocol specification".

10. ETS 300 188‑1: "Integrated Services Digital Network (ISDN); Three-Party (3PTY) supplementary service; Digital Subscriber Signalling System No. one (DSS1) protocol; Part 1: Protocol specification".

11. EN 300 207‑1 (V1.2): "Integrated Services Digital Network (ISDN); Diversion supplementary services; Digital Subscriber Signalling System No. one (DSS1) protocol; Part 1: Protocol specification".

12. EN 300 286‑1: "Integrated Services Digital Network (ISDN); User-to-User Signalling (UUS) supplementary service; Digital Subscriber Signalling System No. one (DSS1) protocol; Part 1: Protocol specification".

13. EN 300 369‑1 (V1.2): "Integrated Services Digital Network (ISDN); Explicit Call Transfer (ECT) supplementary service; Digital Subscriber Signalling System No. one (DSS1) protocol; Part 1: Protocol specification".

14. EN 300 196‑1 (V1.2): "Integrated Services Digital Network (ISDN); Generic functional protocol for the support of supplementary services; Digital Subscriber Signalling System No. one (DSS1) protocol; Part 1: Protocol specification".

15. ITU‑T Recommendation Q.850: "Usage of cause and location in the Digital Subscriber Signalling System No. 1 and the Signalling System No. 7 ISDN User Part".

16. Void.

17. Void.

18. EN 300 122‑1: "Integrated Services Digital Network (ISDN); Generic keypad protocol for the support of supplementary services; Digital Subscriber Signalling System No. one (DSS1) protocol; Part 1: Protocol specification".

19. ETS 300 392‑1: "Terrestrial Trunked Radio (TETRA); Voice plus Data (V+D); Part 1: General network design".

20. EN 301 344, GSM 03.60: "Digital cellular telecommunications system (Phase 2+); GPRS Service description stage 2".

21. RFC‑2228: "FTP Security Extensions", October 1997.

22. Void.

23. ETSI TR 101 876 "Telecommunications security; Lawful Interception (LI); Description of GPRS HI3".

24. ETSI ES 201 671: "Handover Interface for the lawful interception of telecommunications traffic".

Annex F (informative):
Correlation indications of IMS IRI with GSN CC at the LEMF

This annex is informative and provides some guidelines pertaining to correlating IMS IRI with GSN CC at the LEMF.

For IMS-enabled multimedia communication scenarios involving a target, it will be necessary for the LEMF to be able to correlate the media streams (as provided in the CC intercepted by the GSN) with the specific SIP signaling (as provided in the IRI intercepted by the CSCFs) used to establish those media streams. The principal reason for this is that the SDP content within the SIP signaling may provide the information required to even be able to decode the media streams. In certain cases, for example, the information in the RTP header within the media stream packets may not be sufficient to be able to determine the specific encoding used. The SDP portion of the SIP signaling would need to provide this information. Another important reason is that the SIP signaling provides information about the participants in a SIP session (other than the target) sending and receiving the associated media streams. The LIID parameter in the IMS IRI and GSN CC can be used to correlating all of the IMS IRI and all of the GSN CC associated with a particular target. If a single LIID is used in association all of the target’s IMS identities (as per a NO/AN/SP agreement with the LEA), the process of associating the IMS IRI and GSN CC information is fairly straightforward. If, however, multiple LIIDs are used (e.g. one per IMS identity) then the LEMF needs to be able to associate each of the LIIDs that may be used for the IMS IRI with the LIID used for the CC.

The SIP messsages provided to the LEMF would contain a number of additional items of information that could be relevant with respect to supporting correlations of various types. Their potential role in correlating IMS IRI and GSN CC (or, more specifically, correlating SIP dialogs with media streams) is discussed below:

– Call-ID, From tag, To tag : These SIP headers would identify different SIP messages belonging to the same SIP dialog (a call leg between the target user and a peer SIP user). It should be noted that the Call-ID alone is not sufficient to identify a dialog. Correlating specific SIP dialogs with specific media streams is the principal objective of this discussion.

– P-Charging-Vector (IMS Charging ID): The principal purpose of the IMS Charging ID (ICID) in IMS is to correlate charging information provided by different network entities for the same call. The ICID could be useful in correlating SIP messages belonging to the same call, even if their SIP dialog identifiers are modified (e.g. by a B2BUA application server). It should be noted, however, that the use of the ICID is not necessary for the purpose of correlating SIP dialogs and the corresponding media streams.

– P-Charging-Vector (GPRS Charging ID, GGSN address): GCIDs, along with the GGSN address, may be used as identifiers of the PDP contexts. These identifiers (one for each PDP context used by the SIP session) are made available to the P-CSCF and subsequently to the S-CSCF. They could be used to correlate SIP messages with the PDP context(s) used. For the purpose of correlating SIP dialogs with media streams, this type of correlation would be useful, although not essential.

SDP Connection addresses and ports: The address and port information within the SDP of the SIP messages need to be matched with the addresses and ports corresponding to the media streams as provided in the CC reports. This implies a need to look both at the SDP content of the SIP messages as well as in the packets provided by the GSN. The set of PDP context identifiers included in the P-Charging-Vector could be used to simplify the search for a match. It should also be noted that the SDP contained in the SIP message may also include essential information about the encoding of each of the media streams, without which it may not be possible to decode.

Annex G (informative):
United States lawful interception