A carrier may choose to deploy the full target list at all POIs, such that when a UE arrives in the network and commences registration, the POI is fully armed and in position to recognize if the target identifier is in the target list. The choice to push the full list to every node is the simplest, and arguably the riskiest, since the compromise of any node will leak the complete target list.

A Communication Service Provider (CSP) may choose to selectively distribute specific target identifiers to specific POIs, rather than distributing the full target list to all POIs. This choice introduces a race condition. When the UE appears, the POI shall query the ADMF/LICF to find out if the user identifier is part of the target list. As the registration sequence progresses, the NF POI is waiting for a response from the ADMF/LICF. When the reply arrives, the POI can take action if the reply is positive. If the reply is negative, the POI's involvement ends. If the reply is positive, depending on how long the POI-(ADMF/LICF)-POI round trip for the query/reply took, it is possible that some reportable events are missed. To mitigate this there are two further alternatives:

1. the carrier may choose to delay completion of the registration for all users for the time it takes the ADMF/LICF to answer, thus inducing a registration delay in all registrations, whether the user is a target or not, or
2. the carrier may choose to cache the reportable registration events while the POI-(ADMF/LICF)-POI query is running, and either report them if the answer is positive, or delete them if the answer is negative.

These are choices at the discretion of the CSP, but the trade-off cannot be avoided.

When a new target is provisioned in the LI system, after the target is already registered in the CSP network, the CSP will be faced with the race condition consequences of the implementation choice made as described in clauses 8.2.1 and 8.2.2. The ADMF has a choice to either wholesale pre-arm every POI with the new target (and expect every POI to immediately start interception on the new target, as in clause 8.2.1), or, the ADMF can poll every serving UDM POI for all target UEs, and arm the associated POI (and start interception, as in clause 8.1.2) only if a target UE is discovered to be served by that particular NF. The second approach would take comparatively longer and would be expected to miss more of the on-going target interactions with the network than the first approach.

The ADMF is responsible for overall management of the LI system as defined in clause 5.3.2.4. The ADMF is responsible for creating and managing intermediate, client and root certificates used for both identity verification and establishing encrypted communications between LI components.

The ADMF shall implement an LI Certificate Authority (LI CA) which shall be used as the issuing CA for all LI components. By default, the LI CA shall be a sub-CA of the CSP root CA, and may issue intermediate certificates. The LI CA shall be responsible for creating, maintaining and revoking all identity verification and encryption certificates and root keys used by LI components communicating on LI_X interfaces. It may also be responsible for issuing certificates and root keys for LI_HI interfaces if these are not issued by the LEA/LEMF. For virtualised implementations, the LICF shall support automated certificate enrolment for POIs, TFs and MDFs. For non-virtualised deployments, support for automatic certificate enrolment is optional. The LICF shall maintain a list of all valid LI components for which the LI CA has generated certificates. The LICF shall instruct the LI CA to revoke any certificate belonging to LI components that are removed from the system (e.g. de-instantiated). The LI CA shall provide a single certificate for each LI component. The LI component shall generate individual session keys for each LI_X link.

This clause provides requirements and deployment constraints relating to the virtualisation of LI in 3GPP networks.

NFVIs hosting LI functions defined in the present document, shall provide functionality for protecting sensitive functions as defined in ETSI GS NFV-SEC 012 [29] or equivalent specification.

LI functions as defined in the present document when virtualised shall include the use of one or more HMEEs as defined in ETSI GS NFV-SEC 012 [29] or equivalent specification, to protect as a minimum:

• LI target lists.
• Any LI dynamic selectors used internally within the NF to select target communications to be intercepted.
• Any cryptographic keys and LI_X1/LI_X2/LI_X3 end points.

During runtime, NFs containing LI functions should not share NFVI hosts with any other NF, VNF or VNFC. During runtime, NFs containing LI functions shall not share NFVI hosts with any other NF, VNF or VNFC which does not contain other authorised LI functions. The NF runtime restriction requirements do not prevent hosts being used for different NFs over the lifetime of the NFVI, following termination of the previous VNF instances. However, both where hosts are newly allocated for LI use and when subsequently released, host memory and storage secure erase procedures as defined in ETSI GS NFV-SEC 012 [29] or equivalent specification shall be used.

Where containers are used for implementing LI functionality, and when images corresponding to those containers are required to be stored at runtime in a system wide container cache, the LI Controller shall ensure that each time the container image is retrieved from the cache, the integrity of the image is validated. In addition, when the image is no longer required by a live running Network Function, the image is erased from the cache.

This clause provides deployment considerations for Lawful Interception.

This clause introduces CC-PAG (CC-POI Aggregator) as an architectural extension that is located between the MDF3 and CC-POI. The CC-PAG performs the function of aggregating the xCC from different CC-POIs towards the MDF3 and is shown in Figure 8.6-1.

The CC-PAG is an optional LI function and may be deployed in networks that need aggregation of xCC from potentially large number of different CC-POIs towards the MDF3. The CC-PAG may be deployed closer to the UPFs, to reduce the impact of latencies, packet drops, and buffering on UPFs for lawful interception of highspeed user plane traffic. The system resources such as hardware interfaces, CPUs and memory for the CC-PAG node may be tuned to balance the forwarding/reception capabilities of CC-POI and MDF3. As shown in Figure 8.6-1, the CC-POI is triggered by the CC-TF to deliver the xCC (on a per flow basis) to the CC-PAG (via LI_X3A interface) or to the MDF3 (via LI_X3 interface as described in clause 6.2.3). In the option where CC-PAG is involved, the LIPF configures the CC-PAG with the appropriate MDF3 address. The CC-PAG address is provided to the CC-POI using one of the two methods:

1. pre-provisioned (e.g. by LIPF over LI_X0 interface) while instructed to use the pre-provisioned address over LI_X1;
2. as a part of the CC intercept trigger by the CC-TF which in turn is provisioned by the LIPF over LI_X1.

The CC-PAG aggregates the xCC received from different CC-POIs before forwarding the same to the MDF3. The xCC is not modified. The LI_X3A interface is the same as LI_X3 interface on the application level but may be used with other transport protocol options as described in ETSI TS 103 221-2 [16].