provided here.
In order to provide a generic interface for intercepting,
replicating, encapsulating and transporting content packets to the
MD, the content intercept interface ((d) in Figure 1) should 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 also be
specified. This defines a limited lifetime for the intercept so that
failures will not result in intercepts remaining beyond their
authorized lifetime. If a failure of the MD occurs such that it is
not able to supply the refresh to the timeout, then the intercept
will cease to exist after the timeout expires. Similarly, if the IAP
re-boots, then the intercept will 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 (f)
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 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 [12].
If [12] 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). Note that usage of [12] is still under
investigation and may need further specification. Usage of [12] 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.
4. 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
[6], H.323 [9], MGCP [7], H.248 [8]). 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.
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 (c) 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 [11] or H.245 [10]), 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., [5]) and make the request via
interface (d). 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
(d), is not dependent on the type of call signaling protocol used;
nor is the encapsulation format and transport protocol (interface
"f"). 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).
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 (c) and (e), 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 (d) 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 (d).
Clearly the IRI interfaces (c, e, g) are different for data than they
are for voice services. However, the content IAP is typically the
same (an edge router). Interfaces (d, f, and h) may also be the
same.
5. 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 should have
the ability to provide 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 would be considered a prime target for attacks.
In general, all interfaces should have the capability of providing
strong cryptographic authentication to establish the identity of the
principals, and be able to correlate the identity of the principal
with the action they are attempting to perform. All interfaces
should be capable of performing some sort of cryptographic message
integrity checking such as, for example, HMAC-MD5. Message integrity
checking can also be used to counter replay attacks. Privacy and
confidentiality considerations, may also require the use of
encryption.
The content and IRI IAPs also should also provide protection of the
identity of the intercept subject and the existence of an intercept.
5.1. Content Request Interface (d) - SNMPv3 Control
For interface (d,) native SNMPv3 security module mechanism is used.
The additional requirement is that the IAP should support the ability
to protect the TAP MIB’s [1] from disclosure or control by
unauthorized USM [3] users. VACM [4] provides the necessary tools to
limit the views to particular USM users, but there are also special
considerations:
* The ability to limit access to the appropriate TAP MIB’s by only
those SNMPv3 USM users which have keys established and the proper
VACM views defined.
* Segregation of the TAP MIB such that only operators of sufficient
privilege level can create VACM views that include the TAP MIB
[1].
6. Informative References
[1] Baker, F., "Cisco Lawful Intercept Control MIB", Work in
Progress, April 2004.
[2] PacketCable(TM) Electronic Surveillance Specification, PKT-SP-
ESP-I04-040723, http://www.packetcable.com/specifications/
[3] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM)
for version 3 of the Simple Network Management Protocol
(SNMPv3)", STD 62, RFC 3414, December 2002.
[4] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based Access
Control Model (VACM) for the Simple Network Management Protocol
(SNMP)", STD 62, RFC 3415, December 2002.
[5] Warnicke, E., "A Suggested Scheme for DNS Resolution of Networks
and Gateways", Work in Progress.
[6] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002.
[7] Andreasen, F. and B. Foster, "Media Gateway Control Protocol
(MGCP) Version 1.0", RFC 3435, January 2003.
[8] ITU-T Recommendation H.248.1, Gateway Control Protocol: Version
2, May 2002.
[9] ITU-T Recommendation H.323, Packet-based Multimedia
Communications Systems, July 2003.
[10] ITU-T Recommendation H.245, Control Protocol for Multimedia
Communications, July 2003.
[11] Handley, M. and V. Jacobson, "SDP: Session Description
Protocol", RFC 2327, April 1998.
[12] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. Hakenber,
"RTP Retransmission Payload Format", Work in Progress.
[13] ETSI TS 101 331, Telecommunications security; Lawful
Interception (LI); Requirements of law enforcement agencies.
[14] ETSI TS 33.108 v6.7.0, 3rd Generation Partnership Project;
Technical Specification Group Services and System Aspects; 3G
Security; Handover Interface for Lawful Interception (Release
6).
[15] IAB and IESG, "IETF Policy on Wiretapping", RFC 2804, May 2000.
7. 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 Multiplex
UDP User Datagram Protocol
USM User Service Model
VACM View-based Access Control Model
VoIP Voice over IP
8. 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
Suite 2150
1050 West Pender St.
Vancouver, BC, V6E 3S7
Canada
Phone: +1-604-647-2315
EMail: bfoster@cisco.com
Chip Sharp
Cisco Systems
7025 Kit Creek Road
RTP, NC 27709 USA
Tel:+1.919.392.3121
EMail: chsharp@cisco.com
9. Full Copyright Statement
Copyright (C) The Internet Society (2004).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and at www.rfc-editor.org, and except as set
forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM 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.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the ISOC’s procedures with respect to rights in ISOC Documents can
be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.