Lawful Interception

From TBwiki
Revision as of 23:52, 16 October 2016 by William Wong (Talk | contribs)
Jump to: navigation, search

A feature provided by service providers to law enforcement agencies (FBI, Interpol, RCMP, etc.) that allowing law enforcement agencies to intercept calls by receiving a copy of the audio of both parties and call information records.

Contents

Overview

Schematic showing interception of a call already routed with a Tmedia
  • Lawful Interception (process of intercepting a target's conversation)
  • Interception target (someone under investigation by law enforcement agency, and whom the agency wants to intercept calls)
  • Law enforcement agency ( an agency that has, by law, the power to request the interception of calls toward or from targets)
  • A law enforcement agency sends, to the service provider, a list of targets to intercept (phone numbers)
  • Service provider configures its equipments to intercept the targets, based on phone numbers
  • When service provider equipments detect a call that involves a target to intercept, it
    • Forwards a copy of call audio (both directions) to the agency through forked calls (Content of Communication link (CC link) - a call toward the agency, carrying intercepted audio)
    • Sends information records (IRI records) to the agency)
  • Telcobridges Lawful Interception implementation is based on specification ETSI ES 201 671 v2.1.1 (2001-09), and not CALEA, PCES, and ANSI T1.678

Lawful Interception Requirements

  • Detecting target
    • Law enforcement agency provides a list of targets (Type of intercepted targets can be from: PSTN, ISDN, GSM (CS), TETRA, GPRS (PD), UMTS (CS))
      • LIID (Lawful Intercept Identifier, unique identifier assigned to a target by an agency) for the target
      • Phone number of the target
      • Start/end date and time for the interception
    • Service provider updates targets in its equipment and equipments detect a matching calling or called number, and activates the interception
  • Intercepting targets
    • In a call, each call leg can be an interception target
    • When a leg is an interception target, it's intercepted:
      • Audio <<from>> this leg is forked to a new outgoing call
      • Audio <<to>> this leg is forked to a new outgoing call
      • IRI records are generated for this interception
  • Intercepting multiple targets
    • Both legs may be independently and simultaneously intercepted
      • 2 pairs of forked audio outgoing calls
      • 2 sets of IRI records

Intercepting Audio

  • For each direction (audio <<from>> and <<to>> the target):
    • A new outgoing call leg is made, toward the agency
    • Audio is <<forked>> (half-duplex joined)
  • These outgoing call legs are made toward:
    • An outgoing NAP explicitly assigned to the agency
    • optionally, using specified calling/called numbers
  • Forking does NOT require DSPs
  • Audio forking is done as soon as possible
    • Immediately for the audio <<from>> the target (this may include even the ring back tone, or may include audio from incoming call during ringing)
    • Upon joining with other active leg for the audio <<to>> the target

IRI records

The call data (known as Intercept Related Information or IRI in Europe and Call Data or CD in the US) consists of information about the targeted communications, including destination of a voice call (e.g., called party’s telephone number), source of a call (caller’s phone number), time of the call, duration, etc. Intercept Related Information record (IRI record) is a CDR-style record that contains IRI information on an intercepted call

Types of IRI records

  • 1. IRI-BEGIN: Indicate that the interception is starting at first event of the communication attempt, opening the IRI transaction
  • 2. IRI-CONTINUE: Indicate call state change at any time during the communication attempt within the IRI transaction
  • 3. IRI-END: Indicate the end of the interception at the end of the communication attempt, closing the IRI transaction
  • 4. IRI-REPORT: General use for any non-communication related events

For information related to an existing communication case, the record types 1 to 3 shall be used. They form an IRI transaction for each communication case or communication attempt, which corresponds directly to the communication phase (set-up, active or release).

For some packet oriented data services such as GPRS, the first event of a communication attempt shall be the Packet Data Protocol (PDP) context activation or a similar event and an IRI-BEGIN record shall be issued. The end of the communication attempt shall be the PDP context deactivation or a similar event and an IRI-END record shall be issued. While a PDP context is active, IRI-CONTINUE records shall be used for CC relevant IRI data records, IRI-REPORT records otherwise.

Record type 4 is used for non-communication related subscriber action, like Subscriber Controlled Input (SCI) for service activation. For simple cases, it can also be applicable for reporting unsuccessful communication attempts.
The record type is an explicit part of the record. The 4 record types are defined independently of target communication events. The actual indication of one or several communication events, which caused the generation of an IRI record, is part of further parameters within the record's, information content. Consequently, the record types of the IRI transactions are not related to specific messages of the signalling protocols of a communication case, and are therefore independent of future enhancements of the intercepted services, of network specific features, etc. Any transport level information (i.e. higher-level services) on the target communication-state or other target communication related information is contained within the information content of the IRI records.

For some packet oriented data services such as GPRS, if Lawful Interception (LI) is being activated during an already established PDP context or similar, an IRI-BEGIN record will mark the start of the interception. If LI is being deactivated during an established PDP context or similar, no IRI-END record will be transmitted. The end of interception can be communicated to the LEA by other means Handover Interface Port 1 (for Administrative Information)(HI1) (whereas Handover Interface Port 2 (HT2) transports IRI information and Handover Interface Port 3 (HT3) transports Content of Communication information).

Typical information found in an IRI record

  • Record type (Start, Continue, End, Report)
  • LIID
  • CIN (communication identity number)
  • Operator identifier
  • Direction (target is originating, or terminating)
  • Call state (idle, setup, connected)
  • Duration of ring and conversation states
  • Calling / called party numbers
  • Release reason
  • CC link state (setup, active, released, lack of resources)
  • CC link release reason

IRI records generating

  • IRI records are generated at various states of the interception
  • They provide information on the interception, and call state
  • In a call, each call leg can be an interception target
  • When a leg is an interception target, it’s intercepted:
    • Audio «from» this leg is forked to a new outgoing call toward the agency
    • Audio «to» this leg is forked to a new outgoing call toward the agency
    • IRI records are generated for this interception
  • Both legs may be independently and simultaneously intercepted
    • 2 pairs of forked audio outgoing calls
    • 2 sets of IRI records

IRI records encoding

  • IRI records are encoded in ASN.1 (a binary encoding standard that is used by IRI records) format
  • ASN.1 IDs and objects hierarchy for encoding IRI records is provided by ETSI specifications

IRI records values and files specification

  • IRI records values can be
    • Mandatory in each record
    • In one record only for the whole call
    • optional (in some records only, or none at all)
  • IRI record files can
    • Contain only one IRI record (one file per record)
    • Contain multiple IRI records (grouped)

IRI records uploading to the agency

  • As files, using the FTP protocol
  • Telcobridges also supports SFTP as file transfer method

Configuring Lawful Interception

  • Configure Lawful Agencies
    • Summary of information required
      • NAP to use for CC links
      • FTP (or SFTP) server info (IP, port, user, password, folder)
      • IRI upload mode (per record, grouped)
    • Multiple agencies can be configured
    • Note: SFTP requires password-less login to be configured (through exchange of keys between servers)
  • Provide the list of intercepted targets
    • The list of intercepted targets is provided as a CSV file
      • Uploaded in the <<File DB>> section of the Web Portal
      • Required columns:
        • liid
        • number
      • Optional columns
        • start
        • end
    • Example
liid,number,start,end
John Smith,555-0001,2012-10-24T00:00:00-05:00,2012-10-24T23:59:59-05:00
Joe Dalton,333-3007,2012-01-01T00:00:00-05:00,2012-12-31T23:59:59-05:00
Ben Laden,022-44-66-33-11
Ben Yi,450-621-1990
  • Enable Lawful Interception in routing scripts
    • The <<lawful interception>> routing script filter is provided with toolpack
    • Users only need to <<include>> it in their current routing script
require 'lawful_intercept'
(...)
   include LawfulIntercept
(...)
   after_filter :method => :enable_lawful_intercept

Lawful Interception Statistics

  • Live statistics and statistics history
    • The Web Portal provides Lawful Interception statistics
      • Global
      • Per agency
    • Available statistics are
      • Total / current intercepted calls
      • Total IRI records generated
      • Total IRI records dropped
      • Total failed interceptions
      • IRI records upload queue length and state
      • ... and a few more

Testing Lawful Interception

  • Using Test Generator
    • We have implemented automated Lawful Interception tests using Test Generator
      • Lawful Intercept behavior
      • FTP server built into Test Generator
      • IRI record parser and validator
    • To prepare a test:
      • Create a Lawful Interception agency
        • FTP server pointing to Test Generator's IP, with port => gw_port+1000
      • Provide lawful targets CSV file that contains called numbers to intercept
      • Add <<lawful_intercept>> behavior to Test Generator config
      • Add <<liidList>> attribute to phone numbers in Test Generator config
    • Run Test Generator
      • Will make the test calls
      • Lawful Intercept routing script will detect target called numbers, tell Gateway application to intercept
      • Gateway application will intercept by
        • Creating 2 <<CC-link>> outgoing calls
        • Generating the IRI records, upload using FTP
      • Test Generator will
        • Accept, answer, validate the << CC-link>> forked calls
        • Receive and validate the IRI records

Implementation

Schematic showing how different applications and modules interact for Lawful Interception implementation using Test Generator within Tmedia
  • Available modules
    • Ruby
      • Web Portal section to configire Lawful Interception
      • A new routing script filter
    • Gateway
      • A new call behaviour used in Gateway application
      • ASN.1 IRI Record serialization code
      • Generic FTP or SFTP file uploader module
    • Test Generator
      • A new <<lawful intercept>> behavior
      • FTP server to download IRI records
      • IRI records validator
  • Routing script
    • A new routing script filter has been created
    • Simply requires to be included in active routing script
    • Can be modified if customer wants other behaviors (other csv file columns, other interception rules...)
  • Interception behavior
    • A CTBCAFBehavior that is attached to calls
    • Deals with creation of «CC-link» outgoing calls
    • Hides events from these «CC-link» calls from other behaviors
    • Uses half-duplex «Join» to fork audio to «CC-link» calls
    • Gathers information and generate IRI records
  • ASN.1 encoder
    • ASN.1 defines a hierarchy of objects, each serialized by:
      • A unique identifier (unique among parent, or atomic type)
      • It’s payload length
      • It’s payload data
    • The payload can be
      • An atomic element
        • Integer
        • Octet-string
        • Date/Time
      • A sub-object
    • Our ASN.1 encoding has been designed so it can be reused by other projects
      • Base class ITBCAFAsn1Serializable:
        defines objects that can serialize themselves in ASN.1
      • ASN.1 encoding of atomic elements included in CTBCAFSerialize
    • No automatic code generation
    • But simplification macros defined so implementation of a class that can ASN.1 serialize itself can take only a few lines
      • Example: 
class CTBCAFIRICallContentLinkInformation : public ITBCAFAsn1Serializable
{
public:
  CTBCAFIRICallContentLinkInformation(){;}
   TBCAF_ASN1_SERIALIZABLE_COMMON_PROTOTYPES( 
 CTBCAFIRICallContentLinkInformation );

   CTBCAFIRICallContentLinkCharacteristics mCCLink1Characteristics;
   CTBCAFIRICallContentLinkCharacteristics mCCLink2Characteristics;
};
/*!< See callContentLinkInformation in annex D.5 ETSI ES 201 671 V2.1.1 */
#define TBCAF_IRI_CALL_CONTENT_LINK_INFORMATION( __object )    \
{    \
    { &(__object).mCCLink1Characteristics,      1,        TBX_FALSE },    \
    { &(__object).mCCLink2Characteristics,      2,        TBX_FALSE },    \
}
TBCAF_ASN1_SERIALIZABLE_FCTS_IMPLEMENTATION
( 
CTBCAFIRICallContentLinkInformation,
TBCAF_IRI_CALL_CONTENT_LINK_INFORMATION
)
    • IRI record structures defined as classes based on ITBCAFAsn1Serializable
    • IRI record «top» class provides simplified accessors to set various values in the various sub-structures of the IRI Record ASN.1 hierarchy.
      • Example:
TBX_VOID    CTBCAFIRIContent::SetOperatorIdentifier
(
 IN const CTBCAFString& in_strOperatorIdentifier
)
{  
 Set().mIRIParameters.    
  Set().mCommunicationIdentifier.
   Set().mNetworkIdentifier.
    Set().mOperatorIdentifier.
     Set().mstrOctetString
  = in_strOperatorIdentifier;
}
MyRecord.SetOperatorIdentifier
(  
strNetworkOperatorIdentifier
);
MyRecord.Asn1Serialize( MyCafBuffer );
  • IRI Writer
    • Class that manages writing of IRI record into files
    • Uses background thread for writing to disk
    • Supports coalescing (grouping) IRI records into one file
  • File Upload Manager
    • Class to automatically upload files to a server
    • Uses «dir watch lib» to detect files added to local folder
    • Manages upload queue to server
    • Deletes extra files if count exceeds the specified limit
    • Supports FTP or SFTP protocols
    • Provide uploading stats
  • FTP client
    • Class that implement basic FTP client functionalities
      • Connect
      • Disconnect
      • Upload
      • Cancel
    • Used by File Upload Manager class for FTP servers
    • Implemented using CTBCAFTcpConnection
  • SFTP client
    • Class that implement basic SFTP client functionalities
      • Connect
      • Disconnect
      • Upload
      • Cancel
    • Used by File Upload Manager class for SFTP servers
    • Implemented by launching shell commands (less efficient than the FTP client class)
    • Unix implementation requires password-less login (refuses to have the password provided on the command-line!)
  • FTP server
    • Class that implement basic FTP server
      • Accept connections
      • Login (user/password)
      • cwd
      • list
      • upload
    • Used by Test Generator to receive IRI Records
    • Implemented using CTBCAFTcpConnection

References

Retrieved from "https://docs.telcobridges.com/mediawiki/index.php?title=Lawful_Interception&oldid=22085"
Personal tools