A.2 FTP

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

A.2.1 Introduction

At HI2 interface FTP is used over internet protocol stack for the delivery of the IRI. The FTP is defined in IETF STD 9 [13]. The IP is defined in IETF STD0005 [15]. The TCP is defined in IETF STD0007 [16].

FTP supports reliable delivery of data. The data may be temporarily buffered in the mediation function (MF) in case of link failure. FTP is independent of the payload data it carries.

A.2.2 Usage of the FTP

The MF acts as the FTP client and the 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 MF may buffer files.

Several records may be gathered into 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;

– frequency of transfer, based on volume trigger, e.g. X octets.

Every file shall contain only complete IRI records. The single IRI record shall not be divided into several files.

There are two possible ways as to 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 (see: "File naming method A)"). The other way is to multiplex all the intercepted data that MF receives to the same sequence of general purpose interception files sent by the MF (see: "File naming method B)").

File naming:

The names for the files transferred to a LEA are formed according to one of the 2 available formats, 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 MF (as in method B).

The maximum set of allowed characters in interception file names are "a"…"z", "A"…"Z", "-", "_", ".", and decimals "0"…"9".

File naming method A):

<LIID>_<seq>.<ext>

LIID = See clause 7.1.

seq = integer ranging between [0..2^64-1], in ASCII form (not exceeding 20 ASCII digits), identifying the sequence number for file transfer from this node per a specific target.

ext = ASCII integer ranging between ["1".."8"] (in hex: 31H…38H), identifying the file type. The possible file types are shown in table A.1. Type "1" is reserved for IRI data files and type "8" is reserved for data files according to a national requirement by using the same file naming concept.

Table A.1: Possible file types

File types that the LEA may get	Intercepted data types
"1" (in binary: 0011 0001)	IRI / as option HI1 notifications
"2" (in binary: 0011 0010)	CC (MO) (see clause C.2.2)
"4" (in binary: 0011 0100)	CC (MT) (see clause C.2.2)
"6" (in binary: 0011 0110)	CC (MO&MT) (see clause C.2.2)
"7" (in binary: 0011 0111)	IRI + CC (MO&MT) (see clause C.2.2)
"8" (in binary: 0011 1000)	for national use

This alternative A is used when each target’s IRI is gathered per observed target to dedicated delivery files. This method provides the result of interception in a very refined form to the LEAs, but requires somewhat more resources in the MF than alternative B. With this method, the data sorting and interpretation tasks of the LEMF are considerably easier to facilitate in near real time than in alternative B.

File naming method B):

The other choice is to use monolithic fixed format file names (with no trailing file type part in the file name):

<filenamestring> (e.g. ABXY00041014084400001)

where:

ABXY = Source node identifier part, used for all files by the mobile network operator "AB" from this MF node named "XY".

00 = year 2000

04 = month April

10= day 10

14 = hour

08 = minutes

44 = seconds

0000 = extension

ext = file type. The type "1" is reserved for IRI data files and type "8" is reserved for national use. (Codings "2" = CC(MO), "4" = CC(MT), "6" = CC(MO&MT) are reserved for HI3).

This alternative B is used when several targets’ intercepted data is gathered to common delivery files. This method does not provide the result of interception in as refined form to the LEAs as the alternative A, but it is faster in performance for the MF point of view. With this method, the MF does not need to keep many files open like in alternative A.

A.2.3 Profiles (informative)

As there are several ways (usage profiles) how data transfer can be arranged by using the FTP, this chapter contains practical considerations how the communications can be set up. Guidance is given for client-server arrangements, session establishments, time outs, the handling of the files (in RAM or disk). Example batch file is described for the case that the sending FTP client uses files. If instead (logical) files are sent directly from the client’s RAM memory, then the procedure can be in principle similar though no script file would then be needed.

At the LEMF side, FTP server process is run, and at MF, FTP client. No FTP server (which could be accessed from outside the operator network) shall run in the MF. The FTP client can be implemented in many ways, and here the FTP usage is presented with an example only. The FTP client can be implemented by a batch file or a file sender program that uses FTP via an API. The login needs to occur only once per e.g. <destaddr> & <leauser> -pair. Once the login is done, the files can then be transferred just by repeating ‘mput’ command and checking the transfer status (e.g. from the API routine return value). To prevent inactivity timer triggering, a dummy command (e.g. ‘pwd’) can be sent every T seconds (T should be less than L, the actual idle time limit). If the number of FTP connections is wanted to be as minimised as possible, the FTP file transfer method "B" is to be preferred to the method A (though the method A helps more the LEMF by pre-sorting the data sent).

Simple example of a batch file extract:

FTP commands usage scenario for transferring a list of files:

To prevent FTP cmd line buffer overflow the best way is to use wild-carded file names, and let the FTP implementation do the file name expansion (instead of shell). The number of files for one mput is not limited this way:

ftp <flags> <destaddr>

user <leauser> <leapasswd>

cd <destpath>

lcd <srcpath>

bin

mput <files>

nlist <lastfile> <checkfile>

close

EOF

This set of commands opens an FTP connection to a LEA site, logs in with a given account (auto-login is disabled), transfers a list of files in binary mode, and checks the transfer status in a simplified way.

Brief descriptions for the FTP commands used in the example:

user <user-name> <password> Identify the client to the remote FTP server.

cd <remote-directory> Change the working directory on the remote machine to remote-directory.

lcd <directory> Change the working directory on the local machine.

bin Set the file transfer type to support binary image transfer.

mput <local-files> Expand wild cards in the list of local files given as arguments and do a put for each file in the resulting list. Store each local file on the remote machine.

nlist <remote-directory> <local-file> Print a list of the files in a directory on the remote machine. Send the output to local-file.

close Terminate the FTP session with the remote server, and return to the command interpreter. Any defined macros are erased.

The parameters are as follows:

<flags> contains the FTP command options, e.g. "-i -n -V -p" which equals to ‘interactive prompting off’, ‘auto-login disabled’, ‘verbose mode disabled’, and ‘passive mode enabled’. (These are dependent on the used ftp- version.)

<destaddr> contains the IP address or DNS address of the destination (LEA).

<leauser> contains the receiving (LEA) username.

<leapasswd> contains the receiving (LEA) user’s password.

<destpath> contains the destination path.

<srcpath> contains the source path.

<files> wildcarded file specification (matching the files to be transferred).

<lastfile> the name of the last file to be transferred.

<checkfile> is a (local) file to be checked upon transfer completion; if it exists then the transfer is considered successful.

The FTP application should to do the following things if the checkfile is not found:

– keep the failed files.

– raise ‘file transfer failure’ error condition (i.e. send alarm to the corresponding LEA).

– the data can be buffered for a time that the buffer size allows. If that would finally be exhausted, DF would start dropping the corresponding target’s data until the transfer failure is fixed.

– the transmission of the failed files is retried until the transfer eventually succeeds. Then the DF would again start collecting the data.

– upon successful file transfer the sent files are deleted from the DF.

The FTP server at LEMF shall not allow anonymous login of an FTP client.

It is required that FTP implementation guarantees that LEMF will start processing data only after data transfer is complete.

The following implementation example addresses a particular issue of FTP implementation. It is important however to highlight that there are multiple ways of addressing the problem in question, and therefore the given example does not in any way suggest being the default one.

MF sends data with a filename, which indicates that the file is temporary. Once data transfer is complete, MF renames temporary file into ordinary one (as defined in C.2.2).

The procedure for renaming filename should be as follow:

1) open FTP channel (if not already open) from MF to LEMF;

2) sends data to LEMF using command "put" with temporary filename;

3) after MF finished to send the file, renaming it as ordinary one with command "ren".

Brief descriptions for the FTP commands used in the example:

ren <from-name> <to-name> renaming filename from-name to to-name.

If the ftp-client want to send file to LEMF using the command "mput" (e.g. MF stored many IRI files and want to send all together with one command), every filename transferred successfully has to be renamed each after command "mput" ended.

A.2.4 File content

The file content is in method A relating to only one target.

In the file transfer method B, the file content may relate to any targets whose intercept records are sent to the particular LEMF address.

Individual IRI records shall not be fragmented into separate files at the FTP layer.

A.2.5 Exceptional procedures

Overflow at the receiving end (LEMF) is avoided due to the nature of the protocol.

In case the transit network or receiving end system (LEMF) is down for a reasonably short time period, the local buffering at the MF will be sufficient as a delivery reliability backup procedure.

In case the transit network or receiving end system (LEMF) is down for a very long period, the local buffering at the MF may have to be terminated. Then the following intercepted data coming from the intercepting nodes to the MF would be discarded, until the transit network or LEMF is up and running again.

A.2.6 Other considerations

The FTP protocol mode parameters used:

Transmission Mode: stream

Format: non-print

Structure: file-structure

Type: binary

The FTP client (=user -FTP process at the MF) uses e.g. the default standard FTP ports 20 (for data connection) and 21 (for control connection), ‘passive’ mode is supported. The data transfer process listens to the data port for a connection from a server-FTP process.

For the file transfer from the MF to the LEMF(s) e.g. the following data transfer parameters are provided for the FTP client (at the MF):

– transfer destination (IP) address, e.g. "194.89.205.4";

– transfer destination username, e.g. "LEA1";

– transfer destination directory path, e.g. "/usr/local/LEA1/1234-8291";

– transfer destination password;

– interception file type, "1" (this is needed only if the file naming method A is used).

LEMF may use various kind directory structures for the reception of interception files. It is strongly recommended that at the LEMF machine the structure and access and modification rights of the storage directories are adjusted to prevent unwanted directory operations by a FTP client.

Timing considerations for the HI2 FTP transmission

The MF and LEMF sides control the timers to ensure reliable, near-real time data transfer. The transmission related timers are defined within the lower layers of the used protocol and are out of scope of this document.

The following timers may be used within the LI application:

Table A.2: Timing considerations

Name	Controlled by	Units	Description
T1 inactivity timer	LEMF	Seconds	Triggered by no activity within the FTP session (no new files). The FTP session is torn down when the T1 expires. To send another file the new connection will be established. The timer avoids the FTP session overflow at the LEMF side.
T2 send file trigger	MF	Milliseconds	Forces the file to be transmitted to the LEMF (even if the size limit has not been reached yet in case of volume trigger active). If the timer is set to 0 the only trigger to send the file is the file size parameter (See C.2.2).