Internet Engineering Task Force Fred Baker Internet Draft Bill Foster Document: Chip Sharp Category: Informational April 2003 Cisco Support 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. 1.0. Abstract Service providers are being asked to meet lawful intercept requirements of IP networks for voice as well as data in a variety of countries worldwide. Service Provider requirements vary from country to country but some requirements remain common even though details such as delivery formats may differ. The objective of this document is to describe how a Service Provider can support lawful intercept with a general solution that has a minimum set of common interfaces. This document does not deal with legal requirements or obligations. Any comments on this document should be sent to: li-comment@external.cisco.com 2.0 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 RFC-2119. Baker et al Expires September 30, 2003 [Page 1] Support for Lawful Intercept April 2003 Table of Contents 1.0. Abstract.........................................................1 2.0 Conventions used in this document.................................1 3. Introduction.......................................................2 3.1. Key Requirements................................................3 3.2. Document Organization...........................................3 4.0. Reference Model..................................................4 4.1. Reference Model Components......................................4 4.2. Operational Considerations......................................5 5.0. Interfaces.......................................................8 5.1. PacketCable(TM) Interfaces......................................8 5.2. Content Intercept Request Interface.............................9 5.3 Intercept Content Interface (e).................................10 6.0. Applying the Reference Model....................................10 6.1. Voice over IP networks.........................................10 6.1.1. Interception of Voice over IP Services.....................10 6.1.2. Local Voice Services.......................................11 6.2. Data Services..................................................12 7.0. Security Considerations.........................................12 7.1. Content Request Interface (c) - SNMPv3 Control.................13 8.0. References......................................................13 9.0. Authors' Addresses..............................................14 10.0. Full Copyright Statement.......................................15 3. Introduction Service providers are being asked to meet lawful intercept requirements of IP networks for voice as well as data in a variety of countries worldwide. Service Provider requirements vary from country to country but some requirements remain common even though details such as delivery formats may differ. The objective of this document is to describe how a Service Provider can support lawful intercept with a general solution that has a minimum set of common interfaces. This document does not deal with legal requirements or obligations. For the purposes of this document, lawful intercept is the lawfully authorized interception and monitoring of communications for a particular subject (intercept subject). This document describes one method for supporting lawful intercept. Other methods may be available. The requirements described in this document 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. Baker et al Expires September 30, 2003 [Page 2] Support for Lawful Intercept April 2003 3.1. Key Requirements 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. * If multiple Law Enforcement Agencies are intercepting the same subject, they MUST NOT be aware of each other. * 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 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. This document attempts to address the majority of these requirements. 3.2. Document Organization Section 3 of this document looked at some of the key requirements. Section 4 of this document looks at a reference model along with some operation considerations. Section 5 provides more detailed requirements on the interfaces related to content interception. Section 6 looks at applying the reference model to voice over IP and data intercepts and Section 7 looks at security considerations. Baker et al Expires September 30, 2003 [Page 3] Support for Lawful Intercept April 2003 4.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 | | LEA | +-----------+ | |-Content(g)-->| | +--------------------+ +-----+ | ^ Intercept | | Intercepted Request(c) | | Content(e) | | v | +--------------------+ User | Content | User ------->| IAP |--------> Content +--------------------+ Content Figure 1: Intercept Architecture 4.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 written request from 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 to limit accessibility to authorized personnel, as well as the requirement that LEA's not know about each other, this interface must be strictly controlled. The personnel who provision the intercepts are specially authorized to do so and are often employed either directly or indirectly by the service provider whose facilities are being tapped. 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 Expires September 30, 2003 [Page 4] Support for Lawful Intercept April 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., VoIP) or that IP runs on top of (e.g., GPRS). The definition of IRI from ETSI 33.108 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 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. 4.2. Operational Considerations In a typical operation, a lawfully authorized surveillance request arrives for a specified intercept subject. Authorized personnel provision the intercept, 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: Baker et al Expires September 30, 2003 [Page 5] Support for Lawful Intercept April 2003 * 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 to the extent that decryption at the LEA is not possible. 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 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 Expires September 30, 2003 [Page 6] Support for Lawful Intercept April 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. * 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 Expires September 30, 2003 [Page 7] Support for Lawful Intercept April 2003 5.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 below. 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 IRI. (c) Content Intercept Provisioning of content intercept. (d) IRI to MD Internal interface between IRI IAP and MD for delivery of Intercept Related Information (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. 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). 5.1. PacketCable(TM) Interfaces Packetcable has defined some of these interfaces for Voice over IP on Cable networks: * 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). Baker et al Expires September 30, 2003 [Page 8] Support for Lawful Intercept April 2003 * 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]. 5.2. Content Intercept Request Interface This document does not define any of interfaces (a), (b) or (d) to (f) although these interfaces may be defined in future documents. This document proposes a protocol for interface (c) that more closely follows the reference model in Figure 1. This is described in more detail in this section. This section looks at some of the requirements for the content intercept request interface (c) in Figure 1. It recommends the use of a common request protocol (SNMPv3Error! Reference source not found.) 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. Baker et al Expires September 30, 2003 [Page 9] Support for Lawful Intercept April 2003 5.3 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 [2]. Note, however, that the interface defined in [2] is based on UDP and is therefore unreliable. If a more reliable transport mechanism 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]. 6.0. Applying the Reference Model This section looks at the application of the reference model to some example applications. 6.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. 6.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 looks at how intercept might be done using the reference model described 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. Baker et al Expires September 30, 2003 [Page 10] Support for Lawful Intercept April 2003 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. 6.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 Baker et al Expires September 30, 2003 [Page 11] Support for Lawful Intercept April 2003 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). 6.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. 7.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 Baker et al Expires September 30, 2003 [Page 12] Support for Lawful Intercept April 2003 replay attacks. Given privacy and confidentiality considerations, the solution SHOULD allow the use of encryption. Logging and auditing SHOULD be used to detect unauthorized usage of the LI capability. The content and IRI IAPs also MUST protect the identity of the intercept subject and the existence of an intercept. 7.1. Content Request Interface (c) - SNMPv3 Control SNMPv3 control requires all of the above requirements, but places new requirements on the IAP as well. 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]. 8.0. References [1] F. Baker, Cisco Lawful Intercept Control MIB, draft-baker- slem-mib-00 [2] PacketCableTM Electronic Surveillance Specification, http://www.packetcable.com/specifications.html [3] PacketCable Event Messages Specification, http://www.packetcable.com/specifications.html [4] PacketCable, Dynamic Quality if Service Specification, http://www.packetcable.com/specifications.html [5] PacketCable PSTN Gateway Call Signaling Protocol Specification, http://www.packetcable.com/specifications.html [6] 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. [7] B. Wijnen et al, View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP), STD 62, RFC 3415 December 2002 [8] E. Warnicke, DNS Resolution of Networks and Gateways, IETF Draft draft-warnicke-network-dns-resolution-01.txt Baker et al Expires September 30, 2003 [Page 13] Support for Lawful Intercept April 2003 [9] 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. [10] F. Andreasen, B. Foster, Media Gateway Control Protocol (MGCP) Version 1.0, January 2003 [11] ITU-T, Gateway Control Protocol H.248, ITU-T [12] ITU-T, Packet-based Multimedia Communications Systems H.323, ITU-T [13] ITU-T, Control Protocol for Multimedia Communications H.245, ITU_T [14] M. Handley, V, Jacobson, SDP: Session Description Protocol, RFC 2327 April 1998 [15] RTP Retransmission Payload Format, draft-ietf-avt-rtp- retransmission-06.txt 9.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 Expires September 30, 2003 [Page 14] Support for Lawful Intercept April 2003 10.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 Expires September 30, 2003 [Page 15]