G.2 HI2 delivery methods

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

G.2.1 TPKT/TCP/IP

G.2.1.1 Introduction

The protocol used by the "LI application" for the encoding of IRI data and the sending of IRI data between the MF and the LEMF is based on already standardized data transmission protocols. At the HI2 interface, the "LI application" protocol is used directly over the Transmission Control Protocol (TCP), which uses the Internet Protocol (IP) for the delivery of the IRI. IP is defined in IETF STD0005 [15]. TCP is defined in IETF STD0007 [16].

TCP/IP supports reliable delivery of data. TCP is independent of the payload data it carries.

G.2.1.2 Normal Procedures

G.2.1.2.0 General

The MF/DF initiates the TCP connection as detailed in G.2.1.2.1.

G.2.1.2.1 Usage of TCP/IP when MF initiates TCP Connections

The MF shall initiate TCP connections to the LEMF for LI purposes. Once a TCP connection is established, the MF shall send the LI application messages defined in clause G.2.1.3. The MF shall not receive TCP data.

The "LI application" messages may be sent over a single TCP connection per LEMF. A TCP/IP connection shall be capable of transporting "LI application" messages for multiple surveillance cases to a single LEA. The MF initiates the establishment of TCP connections to the LEMF equipment designated by the LEA. Optionally, the MF may use more than one TCP connection per LEMF for the purpose of delivering "LI application" messages to minimize the effects of congestion or facility failures. For example, if more than one TCP connection was used "LI application" messages may be uniformly distributed across the connections. If delays are detected on one TCP connection, the MF could begin to transmit more messages on the other TCP connections. The number of TCP connections supported to the LEMF shall be less than or equal to the provisioned maximum number of such connections.

G.2.1.2.2 Use of TPKT

The individual IRI parameters are coded using ASN.1 and the basic encoding rules (BER). The individual IRI parameters are conveyed to the LEMF in "LI application" messages or IRI data records.

TCP is a stream-based protocol and has no inherent message delineation capability.

Since the upper-layer protocols are not self-describing, ISO Transport Service on top of TCP (ITOT), also referred to as TPKT, as defined in RFC 1006 [27] and later updated by RFC 2126 [28] is used to encapsulate the "LI application" messages before handing them off to TCP.

Therefore, TPKT shall be required and used in the transport stack of the IRI delivery interface (i.e. "LI application" messages/TPKT/TCP/IP). Only protocol class 0 defined in RFC 2126 [28] shall be supported. However, the TPKT connection establishment and negotiation mechanisms shall not be used. The maximum TPDU size to be supported is the default maximum TPDU size specified in [28] and is not negotiated. Consequently, the segmentation and reassembly procedures associated with TPKT will not be used.

In case the TPKT connection establishment is not provided, based on agreement between the Operator and LEA, the TPDU header included in the TPKT payload (TPDU field defined in RFC 2126 [28]) may be omitted.

G.2.1.2.3 Sending of LI messages

After the TCP connection has been established, the MF shall send the "LI application" messages defined in clause G.2.1.3 to the LEMF, when applicable events have been detected and such messages are formulated.

The basic "LI application" message is called LawfulIntercept message. When sending IRI, a LawfulIntercept message shall be used and the IRI shall be encoded within the IRIContent parameter. Multiple IRIContent parameters may be included within a single LawfulIntercept message. When sending the optional keep-Alive indication, the LawfulIntercept shall be coded with the keep-Alive parameter.

In all cases, LawfulIntercept messages are only sent from the MF to the LEMF. All transfer of packets other than those operationally required to maintain the connection has to be from the MF to the LEMF only. At no time may the LEMF equipment send unsolicited packets from the LEMF equipment to the MF.

If supported, a LawfulIntercept message including a keep-Alive parameter shall be sent when no LawfulIntercept message has been sent for a configurable amount of time in minutes (e.g. 5 minutes), indicating to the LEMF that the LI connection is still up. The keep-alive-time parameter shall be settable in increments of 1 minute, from 1 minute up to a maximum of 5 minutes, with a default value of 5 minutes.

The "LI application" messages shall be encapsulated using TPKT, as defined in clause G.2.1.2.2, before sending them from the MF to the LEMF using TCP/IP.

G.2.1.3 ASN.1 for HI2 Mediation Function Messages

DEFINITIONS IMPLICIT TAGS ::=

LawfulIntercept ::= CHOICE

{

keep-Alive [0] NULL,

envelopedIRIContent [1] EnvelopedIRIContent,

…

}

EnvelopedIRIContent ::= SEQUENCE OF UmtsIRIContent

— The above format for EnvelopedIRIContent can be used with UmtsIRIContent, EpsIRIContent or any

— other IRI content from any of the ASN.1 of Annex B. The object identifier embedded within the

— IRI-Parameters allows for unique identification of the specific IRI being sent (e.g. UMTS or

— EPS).

G.2.1.4 Error Procedures

Upon detection of the "User Timeout" condition, as defined in IETF STD0007 [16], if the surveillance is still active, the MF shall take action to re-establish the TCP connection with the LEMF. Due to this condition, any information that TCP was not able to deliver is lost unless it is buffered.

Therefore, the MF should be able to buffer any information that is to be delivered to the LEMF during a period of User Timeout detection until the re-establishment of the TCP connection. If the MF is not able to establish the TCP connection, the MF may discard the buffered information. If the connection is re-established, the MF shall hand off (transmit) the information stored in its buffer to TCP before sending any new information.

G.2.1.5 Security Considerations

Security considerations shall be taken into account in designing the interface between the MF and the LEMF. At a minimum, the MF shall use a source IP address known to the LEMF. To protect against address spoofing and other security concerns, it is recommended that the MF and the LEMF utilize IPSec.