diff options
Diffstat (limited to 'doc/rfc/rfc3924.txt')
| -rw-r--r-- | doc/rfc/rfc3924.txt | 1011 |
1 files changed, 1011 insertions, 0 deletions
diff --git a/doc/rfc/rfc3924.txt b/doc/rfc/rfc3924.txt new file mode 100644 index 0000000..240054f --- /dev/null +++ b/doc/rfc/rfc3924.txt @@ -0,0 +1,1011 @@ + + + + + + +Network Working Group F. Baker +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. + + + + + + + +Baker, et al. Informational [Page 1] + +RFC 3924 Architecture for Lawful Intercept October 2004 + + +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: + + + + + + + + +Baker, et al. Informational [Page 2] + +RFC 3924 Architecture for Lawful Intercept October 2004 + + + 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. + + + + + + + +Baker, et al. Informational [Page 3] + +RFC 3924 Architecture for Lawful Intercept October 2004 + + + * 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. + + + + + + + + +Baker, et al. Informational [Page 4] + +RFC 3924 Architecture for Lawful Intercept October 2004 + + +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. + + + +Baker, et al. Informational [Page 5] + +RFC 3924 Architecture for Lawful Intercept October 2004 + + + + (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 + + + + +Baker, et al. Informational [Page 6] + +RFC 3924 Architecture for Lawful Intercept October 2004 + + + 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 + + + +Baker, et al. Informational [Page 7] + +RFC 3924 Architecture for Lawful Intercept October 2004 + + + 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. + + + + +Baker, et al. Informational [Page 8] + +RFC 3924 Architecture for Lawful Intercept October 2004 + + + * 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 + 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). + + + +Baker, et al. Informational [Page 9] + +RFC 3924 Architecture for Lawful Intercept October 2004 + + + * 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. + + + +Baker, et al. Informational [Page 10] + +RFC 3924 Architecture for Lawful Intercept October 2004 + + +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 + + + +Baker, et al. Informational [Page 11] + +RFC 3924 Architecture for Lawful Intercept October 2004 + + + 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 + + + +Baker, et al. Informational [Page 12] + +RFC 3924 Architecture for Lawful Intercept October 2004 + + + (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. + + + + +Baker, et al. Informational [Page 13] + +RFC 3924 Architecture for Lawful Intercept October 2004 + + + 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. + + + + + + +Baker, et al. Informational [Page 14] + +RFC 3924 Architecture for Lawful Intercept October 2004 + + + [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. + + + + + + + + + + + + + + + + + +Baker, et al. Informational [Page 15] + +RFC 3924 Architecture for Lawful Intercept October 2004 + + +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 + + + + + + + + + + + + + + + + + + + + +Baker, et al. Informational [Page 16] + +RFC 3924 Architecture for Lawful Intercept October 2004 + + +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 + + + + + + + + + + + + + + + + + + + + +Baker, et al. Informational [Page 17] + +RFC 3924 Architecture for Lawful Intercept October 2004 + + +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. + + + + + + + +Baker, et al. Informational [Page 18] + |