ETSI TR 101 876-2001 Telecommunications Security Lawful Interception (LI) Description of GPRS HI3 (V1 1 1)《通信安全 合法侦听(LI) GPRS HI3描述(版本1 1 1)》.pdf

《ETSI TR 101 876-2001 Telecommunications Security Lawful Interception (LI) Description of GPRS HI3 (V1 1 1)《通信安全 合法侦听(LI) GPRS HI3描述(版本1 1 1)》.pdf》由会员分享，可在线阅读，更多相关《ETSI TR 101 876-2001 Telecommunications Security Lawful Interception (LI) Description of GPRS HI3 (V1 1 1)《通信安全 合法侦听(LI) GPRS HI3描述(版本1 1 1)》.pdf（15页珍藏版）》请在麦多课文档分享上搜索。

1、ETSI TR 1 O1 876 1.1.1 (2001-01) Technical Report Telecommun cat ions security; Lawful Interception (LI); Description of GPRS HI3 2 ETSI TR 1 O1 876 V1.l.l (2001-01) Tt- Reference DTWSEC-003012 Keywords GPRS, security ETSI 650 Route des Lucioles F-O6921 Sophia Antipolis Cedex - FRANCE Tel.: +33 4 92

2、 94 42 O0 Fax: +33 4 93 65 47 16 Siret No 348 623 562 00017 - NAF 742 C Association but non lucratif enregistre la Sous-prfecture de Grasse (06) No 7803/88 Important notice Individual copies of the present document can be downloaded from: present document may be made available in more than one elect

3、ronic version or in print. In any case of existing perceived difference in contents between such versions, the reference version is the Portable Document Format (PDF). In case of dispute, the reference shall be the printing on ETSI printers of the PDF version kept on a specific network drive within

4、ETSI Secretariat. Users of the present document should be aware that the document may be subject to revision or change of status. Information on the current status of this and other ETSI documents is available at :/.$./$/ If you find errors in the present document, send your comment to: editor etsi.

5、fr Copyright Notification No part may be reproduced except as authorized by written permission. The copyright and the foregoing restriction extend to reproduction in all media. 8 European Telecommunications Standards Institute 2001. All rights reserved. ETSI 3 ETSI TR 1 O1 876 V1.l.l (2001-01) Conte

6、nts Intellectual Property Rights 4 Foreword 4 1 2 3 3.1 3.2 4 5 6 6.1 6.1.1 6.1.2 6.1.3 6.1.4 6.2 6.2.1 6.2.2 6.2.3 6.2.4 Scope 5 References 5 Definitions and abbreviations 6 Definitions 6 Abbreviations 6 Functional architecture 7 Correlation . 7 HI3 (Delivery Content of Communication (CC) . 8 GTP*

7、8 Introduction . 8 Definition of GTP* Header 8 Exceptional Procedure 9 Other Considerations 10 FTP . 10 Usage of the FTP protocol 10 Exceptional procedures 12 CC Contents for FTP 12 Introduction . 10 6.2.4.1 Fields . 12 6.2.4.2 Information Element Syntax . 13 6.2.5 Other Considerations 14 History .

8、15 ETSI 4 ETSI TR 1 O1 876 V1.l.l (2001-01) Intellectual Property Rights IPRs essential or potentially essential to the present document may have been declared to ETSI. The information pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be foun

9、d in ETSI SR O00 314: “Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in respect of ETSI standards“, which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web server ClattD:/www.etsP.c/iDr. Pursuant to the ETSI IPR Pol

10、icy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee can be given as to the existence of other IPRs not referenced in ETSI SR O00 314 (or the updates on the ETSI Web server) which are, or may be, or may become, essential to the present document. Foreword This Tec

11、hnical Report (TR) has been produced by ETSI Technical Committee Security (SEC). ETSI 5 ETSI TR 1 O1 876 V1.l.l (2001-01) 1 Scope The present document specifies the HI3 (interface for the delivery of CC to the LEMF) for GPRS. This will be an informative annex for GPRS HI3, in ES 201 671 12. 2 Refere

12、nces For the purposes of this Technical Report (TR) the following references apply: u1 GSM 01.04: “Digital cellular telecommunications system (Phase 2+); Abbreviations and acronyms“. 121 GSM 01.33: “Digital cellular telecommunications system (Phase 2+); Lawful Interception requirements for GSM“. GSM

13、 02.33: “Digital cellular telecommunications system (Phase 2+); Lawful Interception stage 1“. GSM 03.33: “Digital cellular telecommunications system (Phase 2+); Lawful Interception stage 2“. GSM 03.60: “Digital cellular telecommunications system (Phase 2+); GPRS Service description stage 2“. GSM 09.

14、02: “Digital cellular telecommunications system (Phase 2+); Mobile Application Part (MAP) specification“. GSM 09.60: “Digital cellular telecommunications system (Phase 2+); General Packet Radio Service (GPRS); GPRS Tunneling Protocol (GTP) across the Gn and Gp Interface“. GSM 12.15: “Digital cellula

15、r telecommunications system (Phase 2+); General Packet Radio Service (GPRS); GPRS Charging“. IETF STD 09: “File Transfer Protocol“ (RFC 0959). IETF STD 05: “Internet Protocol“. : “Empty“. IETF STD 07: “Transmission Control Protocol“. ETSI ES 201 671: “Telecommunications security; Lawful Interception

16、 (LI); Handover interface for the lawful interception of telecommunications traffic“. ETSI TS 132 015: “Digital cellular telecommunications system (Phase 2+) (GSM); Universal Mobile Telecommunications System (UMTS); Telecommunication Management; Charging and billing; 3G call and event data for the P

17、acket Switched (PS) domain; (3GPP TS 32.015 version 3.3.0 Release 1999)“. 131 141 151 161 171 181 191 u01 u11 1121 u31 u41 ETSI TS 129 060: “Digital cellular telecommunications system (Phase 2+) (GSM); Universal Mobile Telecommunications System (UMTS); General Packet Radio Service (GPRS); GPRS Tunne

18、lling Protocol (GTP) across the Gn and Gp Interface; (3GPP TS 29.060 version 3.6.0 Release 1999)“. ETSI 6 ETSI TR 1 O1 876 V1.l.l (2001-01) 3 Definitions and abbreviations 3.1 Def i n it ions See definitions in GSM 02.33 3 and ES 201 671 12. 3.2 Abbreviations See abbreviations in GSM 03.33 4 and ES

19、201 671 12. For the purposes of the present document, the following abbreviations apply: FTP GGSN GSN GTP GTP* xGSN IP LIID MF SGSN TCP TID PDU T-PDU File Transfer Protocol Gateway GPRS Support Node GPRS Support Node GPRS Tunneling Protocol GTP star SGSN or GGSN Internet Protocol Lawful Interception

20、 Identifier Mediation Function Serving GPRS Support Node Transmission Control Protocol Tunnel Identifier tunneled PDU Protocol Data Unit ETSI 7 ETSI TR 1 O1 876 V1.l.l (2001-01) 4 Functional architecture The following picture contains the reference configuration for lawful interception (see GSM 03.3

21、3 4). There is one Administration Function (ADMF) in the network. Together with the delivery functions it is used to hide from the xGSN that there might be multiple activations by different Law Enforcement Agencies (LEAS) on the same target. Figure 1 : Reference configuration NOTE: GGSN interception

22、 is a national option The reference configuration is only a logical representation of the entities involved in lawful interception and does not mandate separate physical entities. This allows for higher levels of integration. A call could be intercepted based on several identities (MSISDN, IMSI, IME

23、I) of the same target. For the delivery of the CC and IN the xGSN provides a correlation number and target identity to the DF2P and DF3P which is used there to select the different LEAS where CC/IN shall be delivered to. 5 Correlation Correlation of ES 201 671 12 IDS to GSM IDS of GSM 03.33 4: - Law

24、ful interception identifier (LIID) 3 Warrant reference number; - Network identifier (NID) 3 xGSN address. ETSI 8 ETSI TR 1 O1 876 V1.l.l (2001-01) Version (O O O) 6 1 Spare 1 1 DIR O HI3 (Delivery Content of Communication (CC) There are two possible methods for delivery 1 content of communication to

25、 the LEMF: - GTP* (see clause 6.1); - FTP (see clause 6.2). According to national requirements al least one of these methods have to be provided. 6.1 GTP* 6.1 .I In trod uction The header and the payload of the communication between the intercepted subscriber and the other party (later called: Infor

26、mation Element) are duplicated. A new header (later called: GTP*-Header, see table 1) is added (see table 3) before it is sent to LEMF. For data transfer over the HI3 interface in GPRS the existing GTP protocol is used in a modified way. The only adaptation to GSM 09.60 7 is to replace the TID by a

27、correlation number identifying the intercepted product (context) unambiguously even in case of SGSN change. The modified protocol will be called GTP*. GTP* could be used via UDP or TCPAP. 6.1.2 Definition of GTP* Header GTP* header contains the following attributes: - Correlation Number; - - Directi

28、on; - Sequence Number; - Length; - Message Type (analogue to GTP a value of 255 is used for H13-PDUs); T-PDU contains the intercepted information. Table 1 : Outline of GTP* header Bits Octets 876543 2 1 1 2 3-4 5-6 7-8 9 10 11 12 13-20 I not used (value 255) I I not used (value 255) I I not used (va

29、lue 255) I I not used (value 255) I I correlation number I ETSI 9 Charging -ID Charging -ID Charging -ID Charging -ID GGSN-ID Octet 1 Octet 2 Octet 3 Octet 4 ETSI TR 1 O1 876 V1.l.l (2001-01) Octet 13-16 Octet 17-20 For interception tunneling the GTP“ header shall be used as follows: Version shall b

30、e set to O to indicate the first version of GTP“. 1-20 21 -n DIR indicates the direction of the T-PDU GTP*-Header Information Element “1“ indicating uplink (from observed mobile user); and “O“ indicating downlink (to observed mobile user). Message Type shall be set to 255 (the unique value that is u

31、sed for T-PDU within GTP 6). Length shall be the length, in octets, of the signaling message excluding the GTP“ header. Bit 8 of octet 3 is the most significant bit and bit 1 of octet 4 is the least significant bit of the length field. Sequence Number is an increasing sequence number for tunneled T-

32、PDUs. Bit 8 of octet 5 is the most significant bit and bit 1 of octet 6 is the least significant bit of the sequence number field. Correlation Number consists of two parts: GGSN-ID identifies the GGSN which creates the Charging-ID. Charging-ID is defined in 7 and assigned unique to each PDP context

33、activation on that GGSN (4 octets). The correlation number consists of 8 octets and guarantees a unique identification of the tunnel to the LEA over a long time. The requirements for this identification are similar to that defined for charging in 7, clause 5.4. Therefore it is proposed to use the Ch

34、arging-ID, defined in 7, clause 5.4 as part of correlation number. The Charging-ID is signaled to the new SGSN in case of SGSN-change so the tunnel identifier could be used “seamless“ for the HI3 interface. Table 2: Outline of correlation number O 1 2 3 The GTP“ header is followed by a subsequent pa

35、yload information element. Only one information element is allowed in a single signaling message. The Information Element contains the header and the payload of the communication between the intercepted subscriber and the other party. 6.1.3 Exceptional Procedure With UDP and GTP“: the delivering nod

36、e doesnt take care about any problems at LEMF. With TCP and GTP“: TCP tries to establish a connection to LEMF and resending (buffering in the sending node) of packets is also supported by TCP. In both cases it might happen that call content gets lost (in case the LEMF or the transit network between

37、MF and LEMF is down for a long time). ETSI 10 ETSI TR 1 O1 876 V1.l.l (2001-01) 6.1.4 Other Considerations The use of Ipsec for this interface is recommended. The required functions in LEMF are: - - collecting and storing of the incoming packets inline with the sequence numbers; correlating of CC to

38、 IRI with the use of the correlation number in the GTP“ header. 6.2 FTP 6.2.1 In trod uction At HI3 interface FTP protocol is used over TCP/IP stack for the delivery of the result of interception. The FTP protocol is defined in the IETF standard STD 09 “File Transfer Protocol“ (RFC 0959). The TCP is

39、 defined in the STD 07 “Transmission Control Protocol“. The IP is defined in the STD 05 “Internet Protocol“. FTP supports reliable delivery of data. The data may be temporarily buffered in the sending node (MF) in case of link failure. FP protocol is independent of the payload data it carries. 6.2.2

40、 Usage of the FTP protocol In the packet data LI the MF acts as the FP client and the receiving node (LEMF) acts as the FTP server. The client pushes the data to the server. The receiving node LEMF stores the received data as files. The sending entity (MF) may buffer files. Several smaller intercept

41、ed data units may be gathered to bigger packages prior to sending, to increase bandwidth efficiency. The following configurable intercept data collection (= transfer package closing / file change) threshold parameters should be supported: - - frequency of transfer, based on send timeout, e.g. X ms;

42、frequency of transfer, based on volume trigger, e.g. X octets. There are two possible ways how the interception data may be sent from the MF to the LEMF. One way is to produce files that contain interception data only for one observed target (ref: “File naming method A)“). The other way is to multip

43、lex all the intercepted data that MF receives to the same sequence of general purpose interception files sent by the MF (ref: “File naming method B)“). The HI2 and HI3 are logically different interfaces, even though in some installations the HI2 and HI3 packet streams might also be delivered via a c

44、ommon transmission path from a MF to a LEMF. It is possible to correlate HI2 and HI3 packet streams by having common (referencing) data fields embedded in the IRI and the CC packet streams. File naming: The names for the files transferred to a LEA are formed according to one of the 2 available forma

45、ts, depending on the delivery file strategy chosen (e.g. due to national convention or operator preference). Either each file contains data of only one observed target (as in method A) or several targets data is put to files common to all observed target traffic through a particular MF node (as in m

46、ethod B). The maximum set of allowed characters in interception file names are “a“. . .“z“, “A“. . .“Z“, “-“ , “ -I, “.“, and decimals “O“. . .“9“. ETSI File naming method A): “2“ fin binarv: O01 1 O01 O 11 CCfMO ETSI TR 1 O1 876 V1.l.l (2001-01) “4“ (in binary: O01 1 O1 00) LID = as defined in the

47、ES 201 671 12. This field has a character string value, e.g. “ABCD123456“. This is a unique interception request identifier allocated by the ADMF. It will be given by the ADMF to the LEA via the HI1 interface after the ADMF has been authorized to command the start of the interception of a specific t

48、arget. The possible network operator identifier part used should be agreed with (and allocated by) the regulatory organization administrating the local telecommunication practises. Seq = integer ranging between 02“64-1, in ASCII form (not exceeding 20 ASCII digits), identifying the sequence number f

49、or file transfer from this node per a specific target. Ext = ASCII integer ranging between “1“7“. (in hex: 31H . 37H), identifying the file type. The possible file type codings for intercepted data are shown in table 4. But for the HI3 interface, only the types “2“, “4“, and “6“ are possible. CC( MT) Table 4: Possible file types “6“ (in binary: O01 1 O1 1 O) CC(MO O0 = year 2000; 04 = month April; 10 = day 10; 14 =hour; O8 = minutes; 44 = seconds; O000 = extension; ETSI 12 ETSI TR 1 O1 876 V1.l.l (2001-01) 6