Request for Comments: 3924 B. Foster
Category: Informational C. Sharp
Cisco Systems
October 2004
Cisco Architecture for Lawful Intercept in IP Networks
Status of this Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2004).
IESG Note
This RFC is not a candidate for any level of Internet Standard. The
IETF disclaims any knowledge of the fitness of this RFC for any
purpose, and in particular notes that the decision to publish is not
based on IETF review for such things as security, congestion control
or inappropriate interaction with deployed protocols. The RFC Editor
has chosen to publish this document at its discretion. Readers of
this document should exercise caution in evaluating its value for
implementation and deployment.
Abstract
For the purposes of this document, lawful intercept is the lawfully
authorized interception and monitoring of communications. Service
providers are being asked to meet legal and regulatory requirements
for the interception of voice as well as data communications in IP
networks in a variety of countries worldwide. Although requirements
vary from country to country, some requirements remain common even
though details such as delivery formats may differ. This document
describes Cisco’s Architecture for supporting lawful intercept in IP
networks. It provides a general solution that has a minimum set of
common interfaces. This document does not attempt to address any of
the specific legal requirements or obligations that may exist in a
particular country.
Table of Contents
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Motivating the Architecture . . . . . . . . . 3
1.2. Document Organization. . . . . . . . . . . . . . . . . . . 4
2. Reference Model . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Reference Model Components . . . . . . . . . . . . . . . . 6
2.2. Operational Considerations . . . . . . . . . . . . . . . . 7
3. Interfaces. . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.1. Content Intercept Request Interface. . . . . . . . . . . . 9
3.2. Intercept Content Interface (f). . . . . . . . . . . . . . 10
4. Applying the Reference Model. . . . . . . . . . . . . . . . . . 11
4.1. Voice over IP networks . . . . . . . . . . . . . . . . . . 11
4.1.1. Interception of Voice over IP Services. . . . . . . 11
4.1.2. Local Voice Services. . . . . . . . . . . . . . . . 12
4.2. Data Services. . . . . . . . . . . . . . . . . . . . . . . 13
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 13
5.1. Content Request Interface (d) - SNMPv3 Control . . . . . . 14
6. Informative References. . . . . . . . . . . . . . . . . . . . . 14
7. Acronyms. . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
8. Authors’ Addresses. . . . . . . . . . . . . . . . . . . . . . . 17
9. Full Copyright Statement. . . . . . . . . . . . . . . . . . . . 18
1. Introduction
For the purposes of this document, lawful intercept is the lawfully
authorized interception and monitoring of communications of an
intercept subject. The term "intercept subject", "subject", "target
subscriber" or "target" in this document refers to the subscriber of
a telecommunications service whose communications and/or intercept
related information (IRI) has been lawfully authorized to be
intercepted and delivered to some agency. Note that although the
term "Law Enforcement Agency" (LEA) is used throughout this document,
this may refer to any agency that is able to request lawfully
authorized interception.
By intercept related information (IRI) we mean information related to
the IP traffic of interest. There is currently no standardized
definition for IRI for IP traffic. IRI has been defined for a few
services that might run over IP (e.g., Voice over IP) or that IP runs
on top of (e.g., GPRS). For example, IRI for voice over IP could be
the called and calling phone numbers. The definition of IRI from
[14] is shown below:
Intercept Related Information: collection of
information or data associated with
telecommunication services involving the target
identity, specifically communication associated
information or data (e.g., unsuccessful
communication attempts), service associated
information or data and location
information.
Service providers are being asked to meet legal and regulatory
requirements for the interception of voice as well as data
communications in IP networks in a variety of countries worldwide.
Although requirements vary from country to country, some requirements
remain common even though details such as delivery formats may
differ. This document describes Cisco’s Architecture for supporting
lawful intercept in IP networks. It provides a general solution that
has a minimum set of common interfaces. This document does not deal
with legal requirements or obligations.
This document describes one method for supporting lawful intercept.
Other methods may be available.
The IESG wishes to draw the reader’s attention to RFC 2804 [15] for a
description of why architectures such as these are vendor-specific,
rather than a topic of standardization for the IETF.
1.1. Requirements Motivating the Architecture
The purpose of the following list of requirements is to provide an
understanding of the motivation behind the architecture and some of
the requirements imposed on components and interfaces that are
described in the later sections of the document. This does not imply
any legal requirements on service providers or equipment vendors
although such requirements may coincide.
Note that there are a variety of requirements that have been defined
for lawfully authorized intercept throughout the world. Some of
these have been defined by standards bodies (e.g., [13]), while
others are country specific. The following itemized list is a
distillation of some of these, although a given item may or may not
apply to a specific country:
* Lawful Intercept (LI) should be undetectable by the intercept
subject.
* Mechanisms should be in place to limit unauthorized personnel from
performing or knowing about lawfully authorized intercepts.
* There is often a requirement (especially for telecommunications
services) to provide intercept related information (IRI)
separately from the actual Internet Protocol (IP) traffic (or
content) of interest (Note: some authorizations may be restricted
to IRI).
* If IRI is delivered separately from content, there should be some
means to correlate the IRI and the content with each other.
* If the information being intercepted is encrypted by the service
provider and the service provider has access to the keys, then the
information should be decrypted before delivery to the Law
Enforcement Agency (LEA) or the encryption keys should be passed
to the Law Enforcement Agency to allow them to decrypt the
information.
* If the information being intercepted is encrypted by the intercept
subject and its associate and the service provider has access to
the keys, then the service provider may deliver the keys to the
LEA.
* There is often a requirement for a service provider to be able to
do multiple simultaneous intercepts on a single subject. The fact
that there are multiple intercepts should be transparent to the
LEAs.
* There is often a requirement that the service provider should not
deliver any unauthorized information to the LEA.
The architecture and interfaces described in this document attempts
to address these requirements.
1.2. Document Organization
Section 1 of this document lists requirements motivating the
architecture. Section 2 of this document describes a reference model
along with some operation considerations. Section 3 provides more
detailed requirements on the interfaces related to content
interception. Section 4 applies the reference model to voice over IP
and data intercepts and Section 5 examines security considerations.
2. Reference Model
This section describes a generic reference model (Figure 1) for
lawful intercept.
+--------------------+ +-----+
| LI Administration | HI1(a) | |
| Function |<--------------| |
+--------------------+ | |
| | |
| MD Provisioning | |
| Interface(b) | LEA |
v | |
+-----------+ +--------------------+ | |
| |<---(c)----| | | |
| IRI IAP |--IRI(e)-->| Mediation |----HI2(g)--->| |
| | | Device (MD) | | |
+-----------+ | |----HI3(h)--->| |
+--------------------+ +-----+
| ^
Intercept | | Intercepted
Request(d) | | Content(f)
| |
v |
+--------------------+
User | Content | User
------->| IAP |-------->
Content +--------------------+ Content
Figure 1: Intercept Architecture
A brief description of the interfaces is included in table 1 below.
For a more detailed description of the interfaces refer to section 3.
For a description of the components refer to section 2.1.
Table 1 LI Interfaces
Interface Description
--------------------- -------------------------------------------
(a) HI1 Handover Interface 1 - Administration
Interface: The LEA provides intercept
information to the service provider
administration function.
(b) MD Provisioning Mediation Device provisioning interface.
Parameters include: target identifier,
duration of intercept, type of intercept,
etc.
(c) IRI IAP Provisioning Specifies Target identifier, duration,
etc. for provisioning of delivery of
Intercept Related Information (IRI).
(d) Content Intercept Provisioning of the Content IAP.
Provisioning
(e) IRI to MD Internal interface between IRI Intercept
Access Point (IAP) and Mediation device
(MD) for delivery of IRI.
(f) Content to MD Internal interface between content
IAP and MD for delivery of Content.
(g) HI2 Handover Interface 2: Interface between
the MD and LEA for delivering IRI. This
interface may vary from country to
country.
(h) HI3 Handover Interface 3: Interface between
the MD and LEA for delivering Content.
This interface may vary from country to
country.
2.1. Reference Model Components
A brief description of the key components in the reference model is
as follows:
Lawful Intercept (LI) Administration Function:
This function provides the (typically manual) provisioning
interface for the intercept as a result of a court order or
warrant delivered by the Law Enforcement Agency (LEA). It could
involve separate provisioning interfaces for several components,
but more typically is a single interface to the Mediation Device
(MD), which then takes care of provisioning of other components in
the network. Because of the requirement in some laws to limit
accessibility to authorized personnel, the provisioning interface
has to be strictly controlled. In many cases, the identity of the
subject received from the LEA has to be translated into an
identity that can be used by the network to enable the intercept.
Intercept Access Point (IAP):
An IAP is a device within the network that is used for
intercepting lawfully authorized intercept information. It may be
an existing device that has intercept capability or it could be a
special device that is provided for that purpose. Two types of
IAP’s are discussed here: IAP’s that provide content; and IAP’s
that provide intercept related information (IRI).
Content IAP:
A content IAP is an IAP that is used to intercept the IP traffic
of interest.
IRI IAP: This is an IAP that is used to provide intercept related
information (IRI).
Law Enforcement Agency (LEA):
This is the agency that has requested the intercept and to which
the service provider delivers the information.
Mediation Device (MD):
The MD requests intercepts from IAPs through interfaces (c) and
(d) in Figure 1. The Mediation Device receives the data from the
IAP, packages it in the correct format (which may vary from
country to country) and delivers it to the LEA. In the case where
multiple law enforcement agencies are intercepting the same
subject, the mediation device may replicate the information
multiple times. The assumption is that the service provider
operates the MD (via specially authorized personnel) and that the
LEA only has access to interfaces (a), (g) and (h) in Figure 1.
2.2. Operational Considerations
In a typical operation, a lawfully authorized surveillance request
arrives for a specified intercept subject. Authorized personnel
provision the intercept using interface (b) in Figure 1, which may be
for content only, IRI only or both. Once the intercept is
provisioned, the IAP’s send the IRI and/or content to the MD, which
formats the information into the appropriate format for delivery to
the LEA. Some operational issues that need to be considered:
* Location and Address Information for Content Intercepts: In some
cases where the location and/or addressing information for the
intercept is not known until the subject registers (or makes a
call in the case of voice), the IRI may provide needed information
in order to do the content tap (e.g., the IP address and port for
the content streams).
* Content Encryption: If the intercept content is encrypted and the
service provider has access to the encryption keys (e.g., receives
keys in Session Description Protocol for Voice over IP), then the
keys can be sent via IRI. It is, however, possible for end-users
to exchange keys by some other means without any knowledge of the
service provider in which case the service provider will not be
able to provide the keys. Content transformations could make
decryption at the LEA impossible. This is why the original
packets are provided on interface (f) rather than attempting to
convert them to some other format.
* Detection by the Intercept Subject: One requirement is to ensure
that the intercept subject is unable to detect that they are being
intercepted. This document assumes a sophisticated subject:
- Able to check IP addresses, use traceroute, etc.
- Able to check if any unusual signaling is occurring on their
customer premises equipment (CPE).
- Able to detect degradation or interruptions in service.
This is why the intercept mechanism described here does not
involve special requests to the CPE, re-routing of packets or
end-to-end changes in IP addresses. Instead, content intercept is
done on a device along the normal content path (i.e., no re-
routing has occurred) that is within the service provider’s
network. A convenient content IAP is a router or switch at the
edge of the service provider’s network to which the intercept
subject connects. This is illustrated in Figure 2.
|
Customer Premises | Service Provider’s Network
|
+-------+
+-----+ | |
| CPE |-------------| Router|----------
+-----+ | (IAP) |
| |
+-------+
Figure 2 Content IAP - Router
Another possibility of course is to provide a special device along
the path to provide the content IAP capabilities.
Note that in the case where there is multi-homing (two or more
routers connected to provide access for the CPE), intercept taps
may have to be installed on more than one access router. If the
CPE is multi-homed to multiple service providers, then the
intercept will have to be installed on each service provider
separately and the LEA will have to correlate the data.
* Unauthorized Creation and Detection: Another concern is the
prevention of unauthorized creation and detection of intercepts.
This is particularly important when a network element such as a
router is used as a content IAP. Those routers that have the
capability should be carefully controlled with access to intercept
capability and information only via authorized personnel. In one
approach using the reference model in Figure 1, the MD is in a
controlled environment and the MD does the intercept request to
the content IAP over an encrypted link. Logging and auditing are
used to detect unauthorized attempts to access the intercept
capability.
* Capacity: Support for lawful intercept on a network element
supporting customers consumes resources on that equipment.
Therefore, support for lawful intercept requires capacity planning
and engineering to ensure that revenue-producing services are not
adversely affected.
3. Interfaces
This section provides a brief description of the interfaces in the
reference model (Figure 1). A list of these interfaces is included
in Table 1 in Section 2.
One of the objectives in defining these interfaces is to keep the
internal interfaces (b to f) the same regardless of country-specific
requirements. The MD then formats the IRI and the content to meet
the country specific requirements for interfaces (g) and (h).
3.1. Content Intercept Request Interface
This section describes some of the requirements for the content
intercept request interface (d) in Figure 1. It makes use of a
common request protocol (SNMPv3) regardless of the type of
application (e.g., voice, data) and suggests the usage of a TAP-MIB,
which is defined in a separate document [1]. Some of the
considerations that lead to the use of SNMPv3 and to the definition
of the specific Management Information Base (MIB) defined in [1] are