G.3 HI3 delivery methods

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

G.3.1 Use of TCP/IP

At the HI3 interface, the user data packets with the ULIC header, version 1, shall be sent to the LEMF over Transmission Control Protocol (TCP), which uses the Internet Protocol (IP).

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

G.3.1.1 Normal Procedures

G.3.1.1.0 Introduction

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

G.3.1.1.1 Usage of TCP/IP when MF/DF initiates TCP Connections

The MF/DF shall initiate TCP connections to the LEMF for the purpose of delivering CC. Once a TCP connection is established, the MF/DF will send CC messages to the LEMF via TCP.

CC messages shall be sent over TCP connections established specifically to deliver CC. A minimum of one TCP connection shall be established per LEMF to deliver CC associated with one or more targets. The MF/DF initiates the establishment of TCP connections to the LEMF equipment designated by the LEA. Optionally, the MF/DF may use more than one TCP connection per LEMF for the purpose of delivering CC associated with the target to minimize the effects of congestion or facility failures. For example, if more than one TCP connection is used, CC messages may be uniformly distributed across the connections. If delays are detected on one TCP connection, the MF/DF 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.

If delivery of CC for only a single target is supported per TCP connection, then after the TCP connection establishment procedure, the MF/DF shall send the connectionStatus message including the lawfulInterceptionIdentifier parameter to the LEMF. The delivery of the lawful interception identifier to the LEMF after the TCP connection establishment procedure will assist the LEMF in correlating the TCP connection, established for delivering content of communication, with a particular surveillance and the target.

If delivery of CC for multiple targets is supported per TCP connection, then the connectionStatus message including a lawfulInterceptionIdentifier parameter is not sent to the LEMF. Moreover, in this case, the ULIC v1 parameter shall include the lawful interception identifier (LIID).

G.3.1.1.2 Use of TPKT

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

Since the upper-layer protocols are not self-describing, ITOT, also referred to as TPKT, as defined in RFC 1006 [27] and later updated by RFC 2126 [28] is used to encapsulate the CC and connectionStatus messages before handing them off to TCP.

Therefore, TPKT shall be required and used in the transport stack of the CC delivery interface (e.g. CC 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.3.1.1.3 Sending of Content of Communication Messages

After the TCP connection has been established and the connectionStatus message has been sent, the MF shall send the CC messages (including the ULIC header, v1) defined in clause C.1 using TPKT to the LEMF.

In all cases, CC 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 connectionStatus message including the keep-Alive parameter shall be sent from the MF to the LEMF when no CC message has been sent for a configurable amount of time in minutes (e.g. 5 minutes), indicating to the LEMF that the TCP connection is still up. If a keep-alive capability is supported, a keep-Alive 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 CC messages and the connectionStatus message shall be encapsulated using TPKT, as defined in clause G.3.1.1.2, before sending them from the MF to the LEMF using TCP/IP.

G.3.1.2 ASN.1 for HI3 Mediation Function Messages

DEFINITIONS IMPLICIT TAGS ::=

ConnectionStatus ::= CHOICE

{

keep-Alive [0] Null,

lawfulInterceptionIdentifier [1] LawfulInterceptionIdentifier,

…

}

G.3.1.3 Error Procedures

Upon detection of the "User Timeout" condition, as defined in IETF STD0007 [16], if the surveillance is still active and user data packets with the ULIC header, v1 are available for delivery to the LEMF, 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.3.1.4 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.