RFC 3924
Cisco Architecture for Lawful Intercept in IP Networks
RFC 3924: Cisco Architecture for Lawful Intercept in IP Networks 🎀
Request for Comments: 3924 🦋 Stream: Network Working Group Authors: F. Baker, B. Foster, C. Sharp, all from Cisco Systems Category: Informational Date: October 2004 Obsoletes / Updates: The header doesn't list anything this RFC obsoletes or updates. ✨
Status of This Memo 📝
Okay so this memo is just giving information to the Internet community, bestie 💖 It does not specify an Internet standard of any kind. Distribution of this memo is unlimited, so share it with whoever 🫶
Copyright Notice ©️
Copyright (C) The Internet Society (2004). Iconic, we're protected 💅
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.
Translation: this one's not a standard and the IETF isn't vouching for it, so be careful before you build anything on it 😭 The RFC Editor picked to publish it at their discretion, and it wasn't reviewed by the IETF for things like security, congestion control, or messing with protocols that are already out there. Read with caution, periodt. 🙈
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.
So the abstract is basically: providers across lots of countries have to do this stuff, the rules are different everywhere, but some bits are the same. This doc describes Cisco's setup with a general solution and a minimum set of common interfaces. It does not try to cover any one country's laws 🌸
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. . . . . . . . . . . . . . . . . . . . 181. Introduction 🌸
For the purposes of this document, lawful intercept is the lawfully authorized interception and monitoring of communications of an intercept subject. The term "intercept subject", "subject", "target subscriber" or "target" in this document refers to the subscriber of a telecommunications service whose communications and/or intercept related information (IRI) has been lawfully authorized to be intercepted and delivered to some agency. Note that although the term "Law Enforcement Agency" (LEA) is used throughout this document, this may refer to any agency that is able to request lawfully authorized interception.
By intercept related information (IRI) we mean information related to the IP traffic of interest. There is currently no standardized definition for IRI for IP traffic. IRI has been defined for a few services that might run over IP (e.g., Voice over IP) or that IP runs on top of (e.g., GPRS). For example, IRI for voice over IP could be the called and calling phone numbers. The definition of IRI from [14] is shown below:
Intercept Related Information: collection of
information or data associated with
telecommunication services involving the target
identity, specifically communication associated
information or data (e.g., unsuccessful
communication attempts), service associated
information or data and location
information.Service providers are being asked to meet legal and regulatory requirements for the interception of voice as well as data communications in IP networks in a variety of countries worldwide. Although requirements vary from country to country, some requirements remain common even though details such as delivery formats may differ. This document describes Cisco's Architecture for supporting lawful intercept in IP networks. It provides a general solution that has a minimum set of common interfaces. This document does not deal with legal requirements or obligations.
This document describes one method for supporting lawful intercept. Other methods may be available. 🦋
The IESG wishes to draw the reader's attention to RFC 2804 [15] for a description of why architectures such as these are vendor-specific, rather than a topic of standardization for the IETF. 👑
1.1. Requirements Motivating the Architecture 💅
The purpose of the following list of requirements is to provide an understanding of the motivation behind the architecture and some of the requirements imposed on components and interfaces that are described in the later sections of the document. This does not imply any legal requirements on service providers or equipment vendors although such requirements may coincide.
Note that there are a variety of requirements that have been defined for lawfully authorized intercept throughout the world. Some of these have been defined by standards bodies (e.g., [13]), while others are country specific. The following itemized list is a distillation of some of these, although a given item may or may not apply to a specific country:
- Lawful Intercept (LI) should be undetectable by the intercept subject. 🙈
- Mechanisms should be in place to limit unauthorized personnel from performing or knowing about lawfully authorized intercepts. 🔒
- There is often a requirement (especially for telecommunications services) to provide intercept related information (IRI) separately from the actual Internet Protocol (IP) traffic (or content) of interest (Note: some authorizations may be restricted to IRI).
- If IRI is delivered separately from content, there should be some means to correlate the IRI and the content with each other. 🔗
- If the information being intercepted is encrypted by the service provider and the service provider has access to the keys, then the information should be decrypted before delivery to the Law Enforcement Agency (LEA) or the encryption keys should be passed to the Law Enforcement Agency to allow them to decrypt the information.
- If the information being intercepted is encrypted by the intercept subject and its associate and the service provider has access to the keys, then the service provider may deliver the keys to the LEA.
- There is often a requirement for a service provider to be able to do multiple simultaneous intercepts on a single subject. The fact that there are multiple intercepts should be transparent to the LEAs. 🫥
- There is often a requirement that the service provider should not deliver any unauthorized information to the LEA. 🚫
The architecture and interfaces described in this document attempts to address these requirements. ✨
1.2. Document Organization 🧚
Section 1 of this document lists requirements motivating the architecture. Section 2 of this document describes a reference model along with some operation considerations. Section 3 provides more detailed requirements on the interfaces related to content interception. Section 4 applies the reference model to voice over IP and data intercepts and Section 5 examines security considerations. 🍓
2. Reference Model ✨
okay bestie, this section gives us a generic reference model (Figure 1) for lawful intercept 🕵️♀️ it's basically the whole cast and how they talk to each other 💅
+--------------------+ +-----+
| 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 +--------------------+ ContentFigure 1: Intercept Architecture
okay so here's the interface cheat sheet 📋 the brief version is in table 1 below, and if you want the full tea, check out section 3. for what each component actually is, see section 2.1.
Table 1 LI Interfaces
Interface Description
--------------------- -------------------------------------------
(a) HI1 Handover Interface 1 - Administration
Interface: The LEA provides intercept
information to the service provider
administration function.
(b) MD Provisioning Mediation Device provisioning interface.
Parameters include: target identifier,
duration of intercept, type of intercept,
etc.
(c) IRI IAP Provisioning Specifies Target identifier, duration,
etc. for provisioning of delivery of
Intercept Related Information (IRI).
(d) Content Intercept Provisioning of the Content IAP.
Provisioning
(e) IRI to MD Internal interface between IRI Intercept
Access Point (IAP) and Mediation device
(MD) for delivery of IRI.
(f) Content to MD Internal interface between content
IAP and MD for delivery of Content.
(g) HI2 Handover Interface 2: Interface between
the MD and LEA for delivering IRI. This
interface may vary from country to
country.
(h) HI3 Handover Interface 3: Interface between
the MD and LEA for delivering Content.
This interface may vary from country to
country.2.1. Reference Model Components
quick tour of the cast 🎭
Lawful Intercept (LI) Administration Function: this is the provisioning interface, usually run by hand 🖊️, for an intercept that came from a court order or warrant delivered by the Law Enforcement Agency (LEA). it could have separate provisioning interfaces for several components, but it's more typically one interface to the Mediation Device (MD), which then handles provisioning of the other components in the network. some laws limit who can access this stuff to authorized personnel, so the provisioning interface has to be strictly controlled 🔒 and in lots of cases, the identity of the subject the LEA hands over has to be translated into an identity the network can actually use to enable the intercept.
Intercept Access Point (IAP): an IAP is a device inside the network that's used for intercepting lawfully authorized intercept information ✨ it could be an existing device that already has intercept capability, or a special device made just for that job. two types of IAPs are discussed here: IAPs that provide content, and IAPs that provide intercept related information (IRI).
Content IAP: a content IAP is an IAP used to intercept the IP traffic of interest 🌊
IRI IAP: this is an IAP used to provide intercept related information (IRI) 🧾
Law Enforcement Agency (LEA): this is the agency that requested the intercept, and the one the service provider delivers the information to 🚓
Mediation Device (MD): the MD requests intercepts from IAPs through interfaces (c) and (d) in Figure 1 💜 it 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. when multiple law enforcement agencies are intercepting the same subject, the mediation device may replicate the information multiple times 👯 the assumption here is that the service provider runs 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
here's how a typical operation goes 🎬 a lawfully authorized surveillance request shows up 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 IAPs 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 to keep in mind:
- Location and Address Information for Content Intercepts: in some cases, the location and/or addressing information for the intercept isn't known until the subject registers (or makes a call, in the case of voice). the IRI may provide the 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 won't 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 make sure the intercept subject is unable to detect that they're being intercepted 🙈 this document assumes a sophisticated subject who is:
- 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, the one the intercept subject connects to. 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 of 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 🌸 and if the CPE is multi-homed to multiple service providers, 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 preventing unauthorized creation and detection of intercepts 🚨 this is especially important when a network element such as a router is used as a content IAP. 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 sits in a controlled environment and the MD makes 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 that supports customers eats up resources on that equipment 🍓 so supporting lawful intercept requires capacity planning and engineering, making sure revenue-producing services aren't adversely affected.
3. Interfaces 🎀
this section gives a brief description of the interfaces in the reference model (Figure 1) 🦋 the list of these interfaces is in Table 1 in Section 2.
one of the goals in defining these interfaces is to keep the internal interfaces (b to f) the same no matter what the country-specific requirements are 🌈 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 🎀
okay so this section is about the content intercept request interface, which is (d) in Figure 1 💅 It uses one common request protocol (SNMPv3) no matter what kind of application it is, like voice or data 🦋 It also suggests using a TAP-MIB, which is defined in a separate document [1]. The reasons SNMPv3 and that specific MIB from [1] got picked are explained here too, so you know the why 🧚
so to give you 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.
also, a timeout value for the intercept should be specified too ⏳ this gives the intercept a limited lifetime, so failures won't leave intercepts hanging around past their authorized lifetime 🙈 if the MD fails in a way where it can't supply the refresh to the timeout, the intercept will cease to exist once the timeout expires. and if the IAP re-boots, the intercept will not survive the re-boot unless the IAP can figure out that the intercept lifetime requirements will still be met 💀
for this to work, the mediation device has to be able to realize there's a failure in the IAP, so it knows it has to re-establish the intercept 😭 this can be an audit (from the MD to the IAP), or a heartbeat mechanism in the content stream, or both ✨
3.2. Intercept Content Interface (f) 🌸
the encapsulation method should keep all of the information in the original packets (source and destination addresses as well as payload) and give you an identifier for correlating the packets with the IRI 🔥 one encapsulation that does this is described in Section 4 of [2]. for non-voice intercepts, the "Intercepted Information" field in Table 1 of [2] holds the original intercepted IP packet 🍓
BUT ngl, the interface defined in [2] is based on UDP, which is an unreliable and unordered transport protocol (i.e., it gives you neither retransmission when errors are detected nor ordering of data) 😬 if you use this transport, the underlying network (Layers 1 - 3) should be engineered to meet the overall reliability requirements for delivery of content.
if you need a more reliable transport protocol, you should use a mechanism that gives timely delivery and also limits the burden (both processing and buffering) on the Content IAP. 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 🙈 and usage of [12] in the content IAP puts more processing burden on the content IAP than a UDP-based intercept does, and it can affect the capacity of the content IAP 😭
4. Applying the Reference Model 🦋
this section applies the reference model to some example applications, so we can see it in action ✨
4.1. Voice over IP networks 📞
this section looks at some of the issues around intercepting voice over IP calls, using local voice services as a specific service example 💖 the reference model from Figure 1 gets applied with 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 bunch of architectures in use for voice over IP (e.g., centralized versus distributed) and a bunch of protocols too (SIP [6], H.323 [9], MGCP [7], H.248 [8]) 🌈 there are also different 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 doesn't address any obligations a service provider might or might not have to support intercepts 🙅♀️ it just describes how intercept might be done using the reference model in Figure 1 ✨
note that when the intercept subject accesses the network via a non-IP endpoint (e.g., TDM), the detectability issue is less acute 🦋 (for example, re-routing packets to intercept them in a special device is a possible option), since the intercept subject doesn't have access to the IP addresses or to traceroute 🧚
but with local services, this is a much harder problem 😩 an intercept for a call that starts and ends on-net (i.e., a call that's voice over IP end-to-end) has to be intercepted along its normal route in order to be undetectable 🫠 and call forwarding, which is often a local service feature, makes interception even harder 💀 if call forwarding is invoked, a call that was meant to terminate on the intercept subject can get forwarded anywhere in the network, so the media stream bypasses the original content IAP (because in voice over IP, the media stream goes directly end-to-end) 🙈 also, since call forwarding can often be set up on a call-by-call basis, the location of the content IAP often won't be known until the call is set up 🍓
4.1.2. Local Voice Services 🎀
this sub-section looks at the specific case where the intercept subject is getting a local voice service from the same provider that also provides the network access (e.g., controls the edge router or switch) 💅 this is an important assumption, because 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) 👑
say a subscriber 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 with addressing information about the subscriber, plus info on which features are in effect (e.g., call forwarding) 🌸 some call control entity (CCE) accesses that database to provide local services 🫶 for example, if the subject has call forwarding invoked, that fact (and where to forward the call) is listed in the subscriber database 💖 a call arriving at the CCE that "owns" that subscriber can then take the right 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 info such as the telephone number and where to deliver the IRI) 🧚 the provisioning of this CCE could go through interface (c) in Figure 1 🦋 the CCE in question is the IRI IAP, and once it's provisioned, it passes the IRI to the MD 🔥 in this scenario, the CCE typically stays in the signaling path for the whole 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 the endpoint IP address and port info for the media (content) streams 💜 armed with this media address info, the MD can figure out the content IAP (e.g., [5]) and make the request via interface (d) 🍓 the request identifies the voice stream to be intercepted based on info received in the call signaling (i.e., IP addresses and UDP port numbers) 👑
note that the content IAP in the voice over IP case 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 🫶 but the protocol used for interface (d) (SNMPv3 [1]) doesn't depend on which call signaling protocol you use, and neither do 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, no matter the signaling protocol or 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 the registration, authentication and authorization point for the data service (e.g., a RADIUS server) 🧚 if a potential IRI IAP doesn't have the available interfaces (c) and (e), the MD may have to do a content tap on registration signaling to get 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 info is available for 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 how sensitive lawful intercept (LI) is -- both because sensitive data needs protecting and because the identities of the intercept subjects need concealing -- the LI solution should be able to provide stringent security measures to fight off threats like impersonation of MDs, privacy and confidentiality breaches, as well as message forgery and replay attacks 😱
while this document doesn't discuss physical security, or operating system or application hardening within the principals of the LI solution, those things are clearly important 🚨 in particular, the MD server would be considered a prime target for attacks 💀
in general, all interfaces should be able to provide strong cryptographic authentication to establish the identity of the principals, and to correlate the identity of the principal with the action they're trying to perform 🔥 all interfaces should be capable of some sort of cryptographic message integrity checking, such as 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 ✨
okay bestie, for interface (d,) we just use the native SNMPv3 security module mechanism 🔐 no need to reinvent anything. 💅 The extra thing the IAP should support is protecting the TAP MIB's [1] from anyone who shouldn't be poking at it, meaning disclosure or control by unauthorized USM [3] users. 🙈 VACM [4] gives us the tools to limit views to particular USM users, but there are a couple of special considerations that make it lowkey tricky:
- 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]. 👑 Only the high-privilege operators get to build those views, periodt.
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 IP8. 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.com9. 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. ✨
📦 where this page comes from
- ietf: rfc3924 2004-11
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms