One document matched: draft-baker-slem-architecture-01.txt
Differences from draft-baker-slem-architecture-00.txt
Internet Engineering Task Force Fred Baker
Internet Draft Bill Foster
Document: <draft-baker-slem-architecture-01.txt> Chip Sharp
Category: Informational June 2003
Cisco Architecture for Lawful Intercept In IP Networks
Status of this Document
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet- Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
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.
Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC2119.
Baker et al Informational [Page 1]
Architecture for Lawful Intercept June 2003
Table of Contents
Abstract..............................................................1
Conventions used in this document.....................................1
1. Introduction.......................................................2
1.1. Key Requirements................................................3
1.2. Document Organization...........................................3
2.0. Reference Model..................................................4
2.1. Reference Model Components......................................5
2.2. Operational Considerations......................................7
3.0. Interfaces.......................................................9
3.1. Content Intercept Request Interface.............................9
3.2. Intercept Content Interface (e).................................9
3.3. PacketCable(TM) Interfaces.....................................10
4.0. 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.0. Security Considerations.........................................13
5.1. Content Request Interface (c) - SNMPv3 Control.................14
6.0. References......................................................14
7.0. Acronyms........................................................15
8.0. Authors' Addresses..............................................16
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 has been lawfully authorized to be intercepted
and delivered to a Law Enforcement Agency (LEA).
Service providers are being asked to meet legal and regulatory
requirements for the interception 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.
Baker et al Informational [Page 2]
Architecture for Lawful Intercept June 2003
1.1. Key Requirements
There are a variety of requirements that have been defined for
lawfully authorized intercept throughout the world. Some of these
requirements have been defined by standards bodies (e.g. [16]), while
others are country specific. The requirements described in this
document are a distillation of some of these requirements, although a
given requirement may or may not apply to a specific country. The
requirements laid out in this document do not imply any legal
requirements on service providers or equipment vendors although such
requirements might be coincident. The procedures described in this
document address the following requirements:
* Lawful Intercept (LI) MUST be undetectable by the intercept
subject.
* Mechanisms MUST 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 MUST 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 MUST be decrypted before delivery to the Law
Enforcement Agency (LEA) or the encryption keys MUST 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.
This document attempts to address these requirements.
1.2. Document Organization
Section 1 of this document lists some of the key requirements.
Section 2 of this document describes a reference model along with
Baker et al Informational [Page 3]
Architecture for Lawful Intercept June 2003
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.0. Reference Model
This section describes a generic reference model (Figure 1) for
lawful intercept.
+--------------------+
| LI Administration |
| Function |
+--------------------+
|
| Authorization
| Interface(a)
|
+-----------+ +--------------------+
| |<---(b)----| | +-----+
| IRI IAP |--IRI(d)-->| Mediation |----IRI(f)--->| |
| | | Device (MD) | | LEA |
+-----------+ | |-Content(g)-->| |
+--------------------+ +-----+
| ^
Intercept | | Intercepted
Request(c) | | Content(e)
| |
v |
+--------------------+
User | Content | User
------->| IAP |-------->
Content +--------------------+ Content
Figure 1: Intercept Architecture
Baker et al Informational [Page 4]
Architecture for Lawful Intercept June 2003
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) LI Provisioning LI Administrative provisioning interface;
parameters include target identifier;
duration of intercept, type of intercept,
etc.
(b) IRI Target Specifies Target identifier, duration, etc.
for provisioning of delivery of Intercept
Related Information (IRI).
(c) Content Intercept Provisioning of content intercept.
(d) IRI to MD Internal interface between IRI Intercept
Access Point (IAP) and Mediation device
(MD) for delivery of IRI.
(e) Content to MD Internal interface between content
IAP and MD for delivery of Content.
(f) IRI to LEA Interface between the MD and LEA for
delivering IRI. This may vary from country
to country.
(g) Content to LEA Interface between the MD and LEA for
delivering Content. This 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 Authorization Interface
(a) in Figure 1 MUST 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.
Baker et al Informational [Page 5]
Architecture for Lawful Intercept June 2003
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). IRI is 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 [17]
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 (e.g. service profile
management by subscriber) and location
information.
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 (b) and
(c) 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 (f) and (g) in Figure 1.
Baker et al Informational [Page 6]
Architecture for Lawful Intercept June 2003
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 (a) 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. In
any case, content formatting at the MD SHOULD NOT modify the
original intercepted information such that it would make
decryption at the LEA impossible. This is why in the case of
voice over IP intercepts for example, it is RECOMMENDED that
the original voice packets be sent to the LEA rather than
attempting to convert them to some other format (TDM for
example).
* Detection by the Intercept Subject: One of the key
requirements 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 implies that the intercept mechanism MUST NOT involve
special requests to the CPE, re-routing of packets or end-to-
end changes in IP addresses. This in turn implies that the
content intercept MUST be done on a device along the normal
content path (i.e. no re-routing has occurred) that is within
the service provider (rather than the customer'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.
Baker et al Informational [Page 7]
Architecture for Lawful Intercept June 2003
|
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 multihomed 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 MUST be carefully controlled
with access to intercept capability and information only via
authorized personnel. The approach RECOMMENDED in this
document is illustrated in the reference model in Figure 1.
In this approach the MD is in a controlled environment and
the MD does the intercept request to the content IAP over an
encrypted link. In addition, logging and auditing MUST be
used to detect unauthorized attempts to access the intercept
capability.
* Maintenance & Management: The lawful intercept solution
SHOULD minimally interfere with normal maintenance and
management procedures.
* 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.
Baker et al Informational [Page 8]
Architecture for Lawful Intercept June 2003
3.0. 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 (a to e) the same regardless of country-specific
requirements. The MD then formats the IRI and the content to meet the
country specific requirements for interfaces (f) and (g).
3.1. Content Intercept Request Interface
This section describes some of the requirements for the content
intercept request interface (c) in Figure 1. It recommends the 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
provided here.
In order to provide a generic interface for intercepting,
replicating, encapsulating and transporting content packets to the
MD, the content intercept interface ((c) in Figure 1) MUST specify:
* A Filter specification for classifying the packets to be
intercepted.
* The destination address of the MD (where to send the packets).
* Encapsulation and Transport parameters.
In addition, a timeout value for the intercept SHOULD be specified.
This defines a limited lifetime for the intercept. If a failure of
the MD occurs such that it is not able to supply the refresh to the
timeout, then the intercept SHOULD cease to exist after the timeout
expires. Similarly, if the IAP re-boots, then the intercept SHOULD
not survive the re-boot unless the IAP is capable of ascertaining
that the intercept lifetime requirements will continue to be met.
In order for this to work, it MUST be possible for the mediation
device to realize that there is a failure in the IAP such that it
must re-establish the intercept. This MAY be in the form of an audit
(from the MD to the IAP), or in the form of a heartbeat mechanism in
the content stream, or both.
3.2. Intercept Content Interface (e)
The encapsulation method SHOULD retain all of the information in the
original packets (source and destination addresses as well as
payload) and provide an identifier for correlating the packets with
the IRI. One encapsulation that meets those requirements is described
in Section 4 of [2]. For non-voice intercepts, the ææIntercepted
Baker et al Informational [Page 9]
Architecture for Lawful Intercept June 2003
InformationÆÆ field in Table 1 of [2] contains the original
intercepted IP packet.
Note, however, that the interface defined in [2] is based on UDP
which is an unreliable and unordered transport protocol (i.e.,
provides neither retransmission on detection of errors nor ordering
of data). If this transport is used, the underlying network (Layers
1 - - 3) should be engineered to meet the overall reliability
requirements for delivery of content.
If a more reliable transport protocol is required, then a mechanism
that provides timely delivery as well as limits the burden (both
processing and buffering) on the Content IAP should be used. One
mechanism that meets these requirements is a NACK-oriented
retransmission scheme based on [15].
If [15] is used, the call content channel identifier may be placed in
the SSRC field of the encapsulating RTP packet. The payload type may
be used to identify the type of packet encapsulated in RTP (e.g., IP,
PPP, Ethernet MAC). Usage of [15] is still under investigation and
may need further specification. Usage of [15] in the content IAP
places more processing burden on the content IAP than a UDP-based
intercept and can affect the capacity of the content IAP.
3.3. PacketCable(TM) Interfaces
PacketCable is a trademark of Cable Television Laboratories, Inc.
Although this document does define interfaces (a), (b) or (d) to (f),
some of these interfaces have been defined by Packetcable for Voice
over IP on Cable networks. Packetcable also uses a different
reference model for interface (c):
* For content intercept provisioning - interface (c), two
interfaces have been defined using two different protocols:
one for the Cable Modem Termination System (CMTS) [4] and one
for PSTN gateways [5]. These requests are performed by a call
control element rather than the MD (so follow a different
reference model that the one described in Figure 1).
* The IRI interface to the MD (d) is defined in Appendix A of
[3].
* The content interface to the MD (e) is the same as the
content interface to the LEA (g) and is defined in [2].
* The IRI interface to the LEA (f) is defined in [2].
Baker et al Informational [Page 10]
Architecture for Lawful Intercept June 2003
4.0. Applying the Reference Model
This section applies the reference model to some example
applications.
4.1. Voice over IP networks
This section will look at some of the issues surrounding interception
of voice over IP calls, taking local voice services as a specific
service example. The reference model from Figure 1 will be applied
with the use of a common set of interfaces that are independent of
the call signaling protocols in use.
4.1.1. Interception of Voice over IP Services
There are a variety of architectures in use for voice over IP (e.g.,
centralized versus distributed) as well as various protocols (SIP
[9], H.323 [12], MGCP [10], H.248 [11]). There are also a variety of
services that may be offered:
* Local Voice Services (i.e. service to a user that has an IP
phone or a phone connected to a gateway)
* Transit services
* Long distance access services (e.g. calling/debit card).
This document does not address any obligations that a service
provider might or might not have to support intercepts. It simply
describes how intercept might be done using the reference model in
Figure 1.
Note that in the case of services where the intercept subject
accesses the network via a non-IP endpoint (e.g., TDM), the
detectability issue is less acute (e.g. re-routing of packets to
intercept them in a special device is a possible option), since the
intercept subject does not have access to the IP addresses or to
traceroute.
However, in the case of local services, this is a much more difficult
problem. The intercept for a call originating and terminating on-net
(i.e. a call that is voice over IP end-to-end) has to be intercepted
along its normal route in order to be undetectable. In addition, the
call-forwarding feature that is often provided as a local service
feature makes interception even more difficult: If call forwarding is
invoked, a call that was intended to terminate on the intercept
subject may be forwarded anywhere in the network resulting in the
media stream bypassing the original content IAP (since in voice over
IP, the media stream goes directly from end-to-end). Also, since call
forwarding can often be set up on a call-by-call basis, the location
of the content IAP will often not be known until the call is set up.
Baker et al Informational [Page 11]
Architecture for Lawful Intercept June 2003
4.1.2. Local Voice Services
This sub-section will look at the specific case in which the
intercept subject under surveillance is being provided with a local
voice service by the same provider that also provides the network
access (e.g., controls the edge router or switch). This is an
important assumption, since in VoIP the entity providing call control
(e.g., SIP server) can be totally separate from the entity providing
network access (e.g., operates edge routers).
Suppose that a subscriber that subscribes to a local (e.g.
residential) voice service is a target for a lawfully authorized
surveillance. Part of the system providing these services is a
subscriber database that includes addressing information about the
subscriber as well information on what features are in effect (e.g.
call forwarding). Some call control entity (CCE) accesses that
database in order to provide local services. For example, if the
subject has call forwarding invoked, that fact (and where to forward
the call) is indicated in the subscriber database. A call arriving at
the CCE that "owns" that subscriber can then take the appropriate
action (e.g. forward the call).
The CCE that "owns" the target subscriber (which could be an H.323
gatekeeper, a SIP proxy or a Media Gateway Controller) is provisioned
with the intercept parameters (e.g. subject identification
information such as the telephone number and where to deliver the
IRI). The provisioning of this CCE could be through interface (b) in
Figure 1. The CCE in question is the IRI IAP and once provisioned, it
passes the IRI to the MD. In the scenario being discussed, the CCE
typically remains in the signaling path throughout the call, even in
the call-forwarding case. Part of the IRI it passes to the MD is the
media signaling information (i.e. SDP [14] or H.245 [13]), which
includes endpoint IP address and port information for the media
(content) streams. Armed with this media address information, the MD
can determine the content IAP (e.g. [8]) and make the request via
interface (c). The request identifies the voice stream to be
intercepted based on information received in the call signaling
(i.e., IP addresses and UDP port numbers).
Note that the content IAP in the case of voice over IP could be an
edge router or a PSTN gateway (e.g. a call from the PSTN forwarded to
the PSTN). SIP, H.323, MGCP or H.248 call signaling protocols could
be used. However, the protocol (SNMPv3 [1]) used for interface (c),
is not dependent on the type of call signaling protocol used; nor is
the encapsulation format and transport protocol (interface "e"). The
same reference model (Figure 1) with the same interfaces can be used
for lawfully authorized surveillance, regardless of the signaling
protocol and regardless of the type of service being provided (Note:
even though a local voice service was used in this example, other
voice services could use the same model and interfaces).
Baker et al Informational [Page 12]
Architecture for Lawful Intercept June 2003
4.2. Data Services
The same model (Figure 1) can also be used for data services. In this
case the IRI IAP could be a server that acts as registration,
authentication and authorization point for the data service (e.g. a
RADIUS server). If a potential IRI IAP does not have the available
interfaces (b) and (d), the MD may have to do a content tap on
registration signaling in order to obtain the IRI.
The IRI in the case of a data service could include:
* The time that the user registered or de-registered for the
service.
* Addressing information (i.e. given the user identity, what IP
address or other information is available that could be used in
interface (c) to do the content tap).
Once suitable addressing information is available in order to do
content tapping the MD can invoke the tap via interface (c).
Clearly the IRI interfaces (b, d, f) are different for data than they
are for voice services. However, the content IAP is typically the
same (an edge router). Interfaces (c, e, and g) may also be the same.
5.0. Security Considerations
Given the sensitive nature of lawful intercept (LI) -- both from the
standpoint of the need to protect sensitive data, as well as conceal
the identities of the intercept subjects, the LI solution must
contain stringent security measures to combat threats such as
impersonation of MD's, privacy and confidentiality breaches, as well
as message forgery and replay attacks.
While this document doesnÆt discuss issues of physical security,
operating system, or application hardening within the principals of
the LI solution, they are clearly important. In particular, the MD
server must be considered a prime target for attacks.
In general, all interfaces MUST have the capability of providing
strong cryptographic authentication to establish the identity of the
principals, and MUST correlate the identity of the principal with the
action they are attempting to perform. All interfaces MUST perform
some sort of cryptographic message integrity checking such as, for
example, HMAC-MD5. Message integrity checking MUST also counter
replay attacks. Given privacy and confidentiality considerations, the
solution SHOULD allow the use of encryption.
Every usage of LI MUST be authorized and logged.
The content and IRI IAPs also MUST protect the identity of the
intercept subject and the existence of an intercept.
Baker et al Informational [Page 13]
Architecture for Lawful Intercept June 2003
5.1. Content Request Interface (c) - SNMPv3 Control
Native SNMPv3 security module mechanism MUST be used. The additional
requirement is that the IAP MUST support the ability to protect the
TAP MIB's [1] from disclosure or control by unauthorized USM [6]
users. VACM [7] provides the necessary tools to limit the views to
particular USM users, but there are also special considerations:
* There SHOULD NOT be any access to the appropriate TAP MIB's by
anything other than SNMPv3 USM users which have keys established
and the proper VACM views defined.
* The TAP MIB SHOULD be segregated such that only operators of
sufficient privilege level can create VACM views that include
the TAP MIB [1].
6.0. References
[1] F. Baker, Cisco Lawful Intercept Control MIB, draft-baker-
slem-mib-00, (work in progress)
[2] PacketCable(TM) Electronic Surveillance Specification, PKT-
SP-ESP-I01-991229, http://www.packetcable.com/specifications/
[3] PacketCable(TM) Event Messages Specification, PKT-SP-EM-I06-
030415, http://www.packetcable.com/specifications/
[4] PacketCable (TM) Dynamic Quality-of-Service Specification,
PKT-SP-DQOS-I06-030415,
http://www.packetcable.com/specifications/
[5] PacketCable(TM) PSTN Gateway Call Signaling Protocol
Specification, PKT-SP-TGCP-I04-021127,
http://www.packetcable.com/specifications/
[6] Blumenthal, U. and B. Wijnen, User-based Security Model(USM)
for version 3 of the Simple Network Management Protocol
(SNMPv3), STD 62, RFC3414, December 2002.
[7] B. Wijnen, et al, View-based Access Control Model (VACM) for
the Simple Network Management Protocol (SNMP), STD62, RFC3415
December 2002
[8] E. Warnicke, DNS Resolution of Networks and Gateways, IETF
Draft draft-warnicke-network-dns-resolution-01.txt (work in
progress)
[9] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M. and E. Schooler, SIP:
Session Initiation Protocol, RFC3261, June 2002.
[10] F. Andreasen, B. Foster, Media Gateway Control Protocol
(MGCP) Version 1.0, RFC3435, January 2003
Baker et al Informational [Page 14]
Architecture for Lawful Intercept June 2003
[11] ITU-T Recommendation H.248.1, Gateway Control Protocol:
Version 2, May 2002
[12] ITU-T Recommendation H.323, Packet-based Multimedia
Communications Systems, November 2000
[13] ITU-T Recommendation H.245, Control Protocol for Multimedia
Communications, February 2003
[14] M. Handley, V, Jacobson, SDP: Session Description Protocol,
RFC2327 April 1998
[15] J. Rey, D. Leon, A. Miyazaki, V. Varsa, R. Hakenber, RTP
Retransmission Payload Format, draft-ietf-avt-rtp-
retransmission-07.txt (work in progress)
[16] ETSI TS 101 331, Telecommunications security; Lawful
Interception (LI); Requirements of law enforcement agencies.
[17] ETSI TS 33.108 v1.0.0, 3rd Generation Partnership Project;
Technical Specification Group Services and System Aspects; 3G
Security; Handover Interface for Lawful Interception.
7.0. Acronyms
CCE Call Control Entity
CMTS Cable Modem Termination System
CPE Customer Premises Equipment
ETSI European Telecommunications Standards Institute
GPRS Generalized Packet Radio Service
HMAC-MD5 Hash-based Message Authentication Code - -
Message Digest 5
IAP Intercept Access Point
IETF Internet Engineering Task Force
IRI Intercept Related Information
ITU-T International Telecommunications Union - -
Telecommunications Sector
LEA Law Enforcement Agency
LI Lawful Intercept
MGCP Media Gateway Control Protocol
MD Mediation Device
MIB Management Information Base
NACK Negative Acknowledgement
PSTN Public Switched Telecommunications Network
RFC Request for Comment
RTP Real-time Transport Protocol
SDP Session Description Protocol
SIP Session Initiation Protocol
SSRC Synchronization Source
TDM Time Division Protocol
UDP User Datagram Protocol
USM User Service Model
VACM View-based Access Control Model
VoIP Voice over IP
Baker et al Informational [Page 15]
Architecture for Lawful Intercept June 2003
8.0. Authors' Addresses
Fred Baker
Cisco Systems
1121 Via Del Rey
Santa Barbara, CA 93117
US
Phone: +1-408-526-4257
Fax: +1-413-473-2403
EMail: fred@cisco.com
Bill Foster
Cisco Systems
Email: bfoster@cisco.com
Chip Sharp
Cisco Systems
Email: chsharp@cisco.com
Baker et al Informational [Page 16]
Architecture for Lawful Intercept June 2003
9.0. Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Baker et al Informational [Page 17]
| PAFTECH AB 2003-2026 | 2026-04-23 20:00:27 |