Intercepting SIP Calls

Intercepting SIP Calls

The following discussion applies solely to VoIP using the SIP protocol. H.323 and MGCP are widely used, but they present different isuues when considering call interception.

Many ITSP's are being confronted with the requirement that they provide telephone call interception facilities for Law Enforcement and national security agencies. Worldwide, it is a common requirement that telecom carriiers be able to action a telephone interception warrants. There will be other occasions when it will be convenient to have the ability to tap into a call, for testing or quality purposes. There are many legal issues with regard to call interception, which won't be discussed here. This page discusses only technical issues.

There are broadly two classes of call interception: calls made to a service; and calls made from a service. Normally, an Interception Warrant will specify all calls, both originating and received, for a given telephone service but in some special cases (wheres the service is shared) it may differentiate. The legal authority (usually a superior court Judge) who issues the Interception Warrant will usely require that only calls made by the target of the Warrant will be intercepted. Usually there is an assumption that a particular telephone number is associated with a single person. With SIP, icoming calls on a given number may cause a number of SIP phones to ring, and unlike a traditional PABX, these phones may be anywhere in the world. Equally it could be, that any of these SIP phones are identified with the same PSTN number when making outgoing calls. So when confronted with an interception warrant it may be necessary approach th Judge in writing (usually through the Judges' Associate), and inform them that multiple people are associated with the specified number(s).

The Mechanics of Intercepting a Call


IP calls can be intercepted by redirecting the call to a "man-in-the-middle" proxy which is configured to monitor the call. Typicallly, an Asterisk server which has been configured to record the call (see (Asterisk cmd Monitor)) and pass the call through to the recipient.

A SIP call is initiated using the INVITE method. The calling SIP UA send "INVITE sip:destua@sip.proxy SIP/20" to the SIP proxy server. Normally the SIp proxy server would respond with a 3xx response redirecting the calling UA to the IP address of the "destua" UA. To intercept the call, the calling UA is redirected not to "destua" but a "man-in-the-middle" system which in turn establishes an call to "destua" and impersonates the callig UA.

This approach assumes that the call is not encrypted. If the call is encrypted, it may be possible to impersonate the caller, provided that the caller soes not validate the S/MIME certificate chains, or the UA has been preloaded with a trusted signing certificate which is available to the local Law Enforcement agency.

If either end of the call is located on the PSTN, then the call can be intercepted using the existing PSTN telco facilities.

Lawful Interception (LI) and Session Border Controllers

Lawful Interception (LI) places several demands on VoIP networks in terms of its execution. The presence of an intercept must not affect other users of the public network in any way. Also, it must not be possible for an intercept target to detect that an intercept is active, this may be through change of path, latency or any other detectable feature of the call. This implies that rerouting intercept calls is not practical as this is easily detected. This implies that interception of calls must be done using existing network elements.

There are very few points in VoIP networks where both signalling and media can be accessed in a consistent fashion. Warrants may require the delivery of just Intercept Related Information (IRI), i.e. the signalling or Contents of Communications (CC) i.e. the media stream(s).

Today's service providers are already deploying Session Border Controllers SBCs in both the access and interconnect sides of the networks for a host of reasons: security, NAT traversal, protection from DoS attacks and so on. SBCs sit in the path of both media and signalling and provide ideal points to implement the interception Function.

The Intercept Function is just one part of the overall LI infrastructure, this is administered by a Administration Function (ADMF) and delivers the intercept information to the Law Enforcement Agency (LEA) via a Mediation Function (MF). It is the job of these two latter elements to provide a standardised interface to the Law Enforcement Monitoring Function (LEMF), this handover is done over two Handover Interfaces, HI2 - Intercept Related Information, and HI3 - Contents of Communications.

Further Reading

The basic LI architectural concepts are summarised in the White Paper Lawful Interception Overview which draws on the ETSI standards as a reference.

Much of the descriptions above are based on the ETSI publications of the TC LI group. A good place to start is the LI Summary page, in particular I recommend the following:

  • TR 101 943 Telecommunications Security; Lawful Interception (LI); Concepts of Interception in a Generic Network Architecture.

  • TS 101 331 Telecommunications Security; Lawful Interception (LI); Requirements of Law Enforcement Agencies

  • TS 101 671 Telecommunications Security; Lawful Interception (LI); Handover interface for the lawful interception of telecommunications traffic.

These can be downloaded from the LI Status Report Page (you can download up to three publications by registering your email address)

An additional report that may be of interest is "Security Implications of Applying the Communications Assistance for Law Enforcement Act to Voice over IP". This report discusses drawbacks of applying an architected intercept regime such as CALEA to VoIP communications.

Potential problems include the difficulty of determining where the traffic is coming from (the VoIP provider enables the connection but may not provide the services for the actual conversation), the difficulty of ensuring safe transport of the signals to the law-enforcement facility, the risk of introducing new vulnerabilities into Internet communications, and the difficulty of ensuring proper minimization. VOIP implementations vary substantially across the Internet making it impossible to implement CALEA uniformly. Mobility and the ease of creating new identities on the Internet exacerbate the problem.

A futher point is that the CALEA legislation applies to all communications, not just VoIP. Any intercept regime will have to cover all data, not just voice traffic.

CALEA is based on the major misconception that telco's are large oraginizations. This assumption was true in the days of the PSTN, but is no longer true when a VoIP network can be built by a group of school kids.
Intercepting SIP Calls

The following discussion applies solely to VoIP using the SIP protocol. H.323 and MGCP are widely used, but they present different isuues when considering call interception.

Many ITSP's are being confronted with the requirement that they provide telephone call interception facilities for Law Enforcement and national security agencies. Worldwide, it is a common requirement that telecom carriiers be able to action a telephone interception warrants. There will be other occasions when it will be convenient to have the ability to tap into a call, for testing or quality purposes. There are many legal issues with regard to call interception, which won't be discussed here. This page discusses only technical issues.

There are broadly two classes of call interception: calls made to a service; and calls made from a service. Normally, an Interception Warrant will specify all calls, both originating and received, for a given telephone service but in some special cases (wheres the service is shared) it may differentiate. The legal authority (usually a superior court Judge) who issues the Interception Warrant will usely require that only calls made by the target of the Warrant will be intercepted. Usually there is an assumption that a particular telephone number is associated with a single person. With SIP, icoming calls on a given number may cause a number of SIP phones to ring, and unlike a traditional PABX, these phones may be anywhere in the world. Equally it could be, that any of these SIP phones are identified with the same PSTN number when making outgoing calls. So when confronted with an interception warrant it may be necessary approach th Judge in writing (usually through the Judges' Associate), and inform them that multiple people are associated with the specified number(s).

The Mechanics of Intercepting a Call


IP calls can be intercepted by redirecting the call to a "man-in-the-middle" proxy which is configured to monitor the call. Typicallly, an Asterisk server which has been configured to record the call (see (Asterisk cmd Monitor)) and pass the call through to the recipient.

A SIP call is initiated using the INVITE method. The calling SIP UA send "INVITE sip:destua@sip.proxy SIP/20" to the SIP proxy server. Normally the SIp proxy server would respond with a 3xx response redirecting the calling UA to the IP address of the "destua" UA. To intercept the call, the calling UA is redirected not to "destua" but a "man-in-the-middle" system which in turn establishes an call to "destua" and impersonates the callig UA.

This approach assumes that the call is not encrypted. If the call is encrypted, it may be possible to impersonate the caller, provided that the caller soes not validate the S/MIME certificate chains, or the UA has been preloaded with a trusted signing certificate which is available to the local Law Enforcement agency.

If either end of the call is located on the PSTN, then the call can be intercepted using the existing PSTN telco facilities.

Lawful Interception (LI) and Session Border Controllers

Lawful Interception (LI) places several demands on VoIP networks in terms of its execution. The presence of an intercept must not affect other users of the public network in any way. Also, it must not be possible for an intercept target to detect that an intercept is active, this may be through change of path, latency or any other detectable feature of the call. This implies that rerouting intercept calls is not practical as this is easily detected. This implies that interception of calls must be done using existing network elements.

There are very few points in VoIP networks where both signalling and media can be accessed in a consistent fashion. Warrants may require the delivery of just Intercept Related Information (IRI), i.e. the signalling or Contents of Communications (CC) i.e. the media stream(s).

Today's service providers are already deploying Session Border Controllers SBCs in both the access and interconnect sides of the networks for a host of reasons: security, NAT traversal, protection from DoS attacks and so on. SBCs sit in the path of both media and signalling and provide ideal points to implement the interception Function.

The Intercept Function is just one part of the overall LI infrastructure, this is administered by a Administration Function (ADMF) and delivers the intercept information to the Law Enforcement Agency (LEA) via a Mediation Function (MF). It is the job of these two latter elements to provide a standardised interface to the Law Enforcement Monitoring Function (LEMF), this handover is done over two Handover Interfaces, HI2 - Intercept Related Information, and HI3 - Contents of Communications.

Further Reading

The basic LI architectural concepts are summarised in the White Paper Lawful Interception Overview which draws on the ETSI standards as a reference.

Much of the descriptions above are based on the ETSI publications of the TC LI group. A good place to start is the LI Summary page, in particular I recommend the following:

  • TR 101 943 Telecommunications Security; Lawful Interception (LI); Concepts of Interception in a Generic Network Architecture.

  • TS 101 331 Telecommunications Security; Lawful Interception (LI); Requirements of Law Enforcement Agencies

  • TS 101 671 Telecommunications Security; Lawful Interception (LI); Handover interface for the lawful interception of telecommunications traffic.

These can be downloaded from the LI Status Report Page (you can download up to three publications by registering your email address)

An additional report that may be of interest is "Security Implications of Applying the Communications Assistance for Law Enforcement Act to Voice over IP". This report discusses drawbacks of applying an architected intercept regime such as CALEA to VoIP communications.

Potential problems include the difficulty of determining where the traffic is coming from (the VoIP provider enables the connection but may not provide the services for the actual conversation), the difficulty of ensuring safe transport of the signals to the law-enforcement facility, the risk of introducing new vulnerabilities into Internet communications, and the difficulty of ensuring proper minimization. VOIP implementations vary substantially across the Internet making it impossible to implement CALEA uniformly. Mobility and the ease of creating new identities on the Internet exacerbate the problem.

A futher point is that the CALEA legislation applies to all communications, not just VoIP. Any intercept regime will have to cover all data, not just voice traffic.

CALEA is based on the major misconception that telco's are large oraginizations. This assumption was true in the days of the PSTN, but is no longer true when a VoIP network can be built by a group of school kids.
Created by: papafox, Last modification: Thu 15 of Jun, 2006 (11:35 UTC)
Please update this page with new information, just login and click on the "Edit" or "Discussion" tab. Get a free login here: Register Thanks! - Find us on Google+