Network Working Group F. Baker
Request for Comments: 3924 B. Foster
Category: Informational C. Sharp
Cisco Systems
October 2004
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
IP网络中合法拦截的Cisco体系结构
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).
版权所有（C）互联网协会（2004年）。
IESG Note
IESG注释
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.
本RFC不适用于任何级别的互联网标准。IETF不承认本RFC适用于任何目的的任何知识，特别注意到，发布决定并非基于IETF对安全、拥塞控制或与已部署协议的不当交互等事项的审查。RFC编辑已自行决定发布本文件。本文档的读者在评估其实施和部署价值时应谨慎。
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.
就本文件而言，合法拦截是指合法授权的通信拦截和监控。服务提供商被要求满足全球多个国家IP网络中语音和数据通信拦截的法律和监管要求。尽管各国的要求各不相同，但有些要求仍然很常见，即使交付格式等细节可能有所不同。本文档描述了Cisco在IP网络中支持合法拦截的体系结构。它提供了一个通用解决方案，该解决方案具有最少的公共接口集。本文件不试图解决特定国家可能存在的任何具体法律要求或义务。
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. . . . . . . . . . . . . . . . . . . . . . . . . . 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
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.
就本文件而言，合法截取是指合法授权截取和监控截取主体的通信。本文件中的术语“截取主体”、“主体”、“目标订户”或“目标”是指其通信和/或截取相关信息（IRI）已被合法授权截取并交付给某机构的电信服务订户。请注意，尽管本文件中使用了术语“执法机构”（LEA），但这可能指的是能够请求合法授权拦截的任何机构。
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:
拦截相关信息（IRI）是指与感兴趣的IP流量相关的信息。目前，IP流量的IRI没有标准化定义。IRI是为一些可能通过IP（如IP语音）或IP（如GPRS）运行的服务定义的。例如，IP语音的IRI可以是被叫和主叫电话号码。[14]中IRI的定义如下所示：
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.
服务提供商被要求满足全球多个国家IP网络中语音和数据通信拦截的法律和监管要求。尽管各国的要求各不相同，但有些要求仍然很常见，即使交付格式等细节可能有所不同。本文档描述了Cisco在IP网络中支持合法拦截的体系结构。它提供了一个通用解决方案，该解决方案具有最少的公共接口集。本文件不涉及法律要求或义务。
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.
IESG希望提请读者注意RFC 2804[15]，以说明此类体系结构为何是特定于供应商的，而不是IETF的标准化主题。
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:
请注意，对于全球范围内的合法授权拦截，已经定义了各种各样的要求。其中一些是由标准机构定义的（如[13]），而另一些是针对具体国家的。以下分项清单是其中一些项目的精髓，尽管某一特定项目可能适用于某一特定国家，也可能不适用于某一特定国家：
* Lawful Intercept (LI) should be undetectable by the intercept subject.
* 合法拦截（LI）应由拦截主体检测不到。
* 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).
* 通常要求（特别是对于电信服务）提供与感兴趣的实际互联网协议（IP）流量（或内容）分开的截取相关信息（IRI）（注：某些授权可能仅限于IRI）。
* If IRI is delivered separately from content, there should be some means to correlate the IRI and the content with each other.
* 如果IRI与内容分开交付，则应该有一些方法将IRI与内容相互关联。
* 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.
* 如果被截获的信息由服务提供商加密，且服务提供商有权访问密钥，则应在将信息交付给执法机构（LEA）之前对其进行解密，或将加密密钥传递给执法机构，以允许其对信息进行解密。
* 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.
* 如果被截取的信息由截取主体及其关联方加密，并且服务提供商可以访问密钥，则服务提供商可以将密钥交付给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.
* 通常要求服务提供商能够对单个主题同时执行多个截取。存在多个拦截的事实应该对LEAs透明。
* There is often a requirement that the service provider should not deliver any unauthorized information to the LEA.
* 通常要求服务提供商不得向LEA提供任何未经授权的信息。
The architecture and interfaces described in this document attempts to address these requirements.
本文档中描述的体系结构和接口试图解决这些需求。
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.
本文档第1节列出了激发体系结构的需求。本文档第2节介绍了参考模型以及一些操作注意事项。第3节提供了与内容拦截相关的接口的更详细的要求。第4节将参考模型应用于IP语音和数据截获，第5节检查安全注意事项。
This section describes a generic reference model (Figure 1) for lawful intercept.
本节描述了合法拦截的通用参考模型（图1）。
+--------------------+ +-----+
| 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
+--------------------+ +-----+
| 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
图1：拦截架构
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.
下面的表1对接口进行了简要说明。有关接口的更详细说明，请参阅第3节。有关组件的说明，请参阅第2.1节。
Table 1 LI Interfaces
表1 LI接口
Interface Description
--------------------- -------------------------------------------
(a) HI1 Handover Interface 1 - Administration
Interface: The LEA provides intercept
information to the service provider
administration function.
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.
(b) MD配置中介设备配置接口。参数包括：目标标识符、截获持续时间、截获类型等。
(c) IRI IAP Provisioning Specifies Target identifier, duration, etc. for provisioning of delivery of Intercept Related Information (IRI).
(c) IRI IAP Provisioning指定提供截获相关信息（IRI）的目标标识符、持续时间等。
(d) Content Intercept Provisioning of the Content IAP. Provisioning
(d) 内容IAP的内容截获配置。供应
(e) IRI to MD Internal interface between IRI Intercept Access Point (IAP) and Mediation device (MD) for delivery of IRI.
(e) IRI到MD IRI拦截接入点（IAP）和中介设备（MD）之间的内部接口，用于传递IRI。
(f) Content to MD Internal interface between content IAP and MD for delivery of Content.
(f) 内容到MD内容IAP和MD之间用于交付内容的内部接口。
(g) HI2 Handover Interface 2: Interface between the MD and LEA for delivering IRI. This interface may vary from country to country.
(g) HI2移交接口2：MD和LEA之间用于交付IRI的接口。此接口可能因国家而异。
(h) HI3 Handover Interface 3: Interface between the MD and LEA for delivering Content. This interface may vary from country to country.
(h) HI3移交接口3：MD和LEA之间用于交付内容的接口。此接口可能因国家而异。
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.
合法拦截（LI）管理功能：该功能为执法机构（LEA）发出的法院命令或授权提供拦截（通常为手动）设置接口。它可能涉及多个组件的单独配置接口，但更典型的是到中介设备（MD）的单个接口，然后中介设备负责网络中其他组件的配置。由于某些法律要求限制授权人员的访问权限，因此必须严格控制供应接口。在许多情况下，必须将从LEA接收的对象的身份转换为网络可用于启用截获的身份。
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
拦截接入点（IAP）：IAP是网络中用于拦截合法授权的拦截信息的设备。它可能是具有拦截能力的现有设备，也可能是
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).
为此目的而提供的特殊装置。这里讨论了两种类型的IAP：提供内容的IAP；以及提供截获相关信息（IRI）的IAP。
Content IAP: A content IAP is an IAP that is used to intercept the IP traffic of interest.
内容IAP：内容IAP是用于拦截感兴趣的IP流量的IAP。
IRI IAP: This is an IAP that is used to provide intercept related information (IRI).
IRI IAP：这是一个IAP，用于提供截获相关信息（IRI）。
Law Enforcement Agency (LEA): This is the agency that has requested the intercept and to which the service provider delivers the information.
执法机构（LEA）：这是请求拦截的机构，服务提供商向其提供信息。
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.
中介设备（MD）：MD请求通过图1中的接口（c）和（d）从IAP截获。中介设备从IAP接收数据，以正确的格式（可能因国家而异）进行打包，并将其交付给LEA。在多个执法机构截获同一主体的情况下，调解设备可以多次复制该信息。假设服务提供商（通过特别授权人员）操作MD，LEA只能访问图1中的（a）、（g）和（h）接口。
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:
在典型操作中，合法授权的监视请求到达指定的拦截对象。授权人员使用图1中的接口（b）提供拦截，该接口可能仅用于内容、IRI或两者。一旦设置了截取，IAP将IRI和/或内容发送给MD，MD将信息格式化为适当的格式，以交付给LEA。需要考虑的一些操作问题：
* 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).
* 内容截取的位置和地址信息：在某些情况下，截取的位置和/或地址信息直到对象注册（或在语音情况下拨打电话）才为人所知，IRI可能会提供所需信息以进行内容点击（例如，内容流的IP地址和端口）。
* 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
* 内容加密：如果拦截内容是加密的，并且服务提供商可以访问加密密钥（例如，接收IP语音会话描述协议中的密钥），则可以通过IRI发送密钥。然而，最终用户可以在不知道密码的情况下通过其他方式交换密钥
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.
在这种情况下，服务提供商将无法提供密钥。内容转换可能使LEA无法解密。这就是为什么原始数据包在接口（f）上提供，而不是试图将其转换为其他格式。
* 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.
- 能够检查IP地址，使用跟踪路由等。
- Able to check if any unusual signaling is occurring on their customer premises equipment (CPE).
- 能够检查客户场所设备（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.
这就是为什么这里描述的拦截机制不涉及对CPE的特殊请求、分组的重新路由或IP地址的端到端更改。相反，内容截获是沿着服务提供商网络内的正常内容路径（即，没有发生重新路由）在设备上完成的。方便的内容IAP是一个路由器或交换机，位于服务提供商的网络边缘，截获主体连接到该网络。如图2所示。
|
Customer Premises | Service Provider's Network
|
+-------+
+-----+ | |
| CPE |-------------| Router|----------
+-----+ | (IAP) |
| |
+-------+
|
Customer Premises | Service Provider's Network
|
+-------+
+-----+ | |
| CPE |-------------| Router|----------
+-----+ | (IAP) |
| |
+-------+
Figure 2 Content IAP - Router
图2内容IAP-路由器
Another possibility of course is to provide a special device along the path to provide the content IAP capabilities.
当然，另一种可能性是沿路径提供特殊设备，以提供内容IAP功能。
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.
注意，如果存在多主（两个或多个路由器连接以提供对CPE的访问），则可能必须在多个访问路由器上安装截取抽头。如果CPE是多个服务提供商的多址，则必须在每个服务提供商上分别安装拦截，并且LEA必须关联数据。
* 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.
* 未经授权的创建和检测：另一个问题是防止未经授权的创建和检测拦截。当诸如路由器之类的网络元件用作内容IAP时，这一点尤其重要。应小心控制具有该能力的路由器，仅通过授权人员访问拦截能力和信息。在使用图1中的参考模型的一种方法中，MD处于受控环境中，MD通过加密链接向内容IAP发出截获请求。日志记录和审核用于检测访问拦截功能的未经授权的尝试。
* 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.
* 容量：支持在网元上合法拦截，支持客户消耗该设备上的资源。因此，支持合法拦截需要能力规划和工程设计，以确保创收服务不会受到不利影响。
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.
本节简要描述了参考模型中的接口（图1）。这些接口的列表包含在第2节的表1中。
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).
定义这些接口的目标之一是保持内部接口（b到f）相同，而不考虑国家特定的要求。MD然后对IRI和内容进行格式化，以满足接口（g）和（h）的国家特定要求。
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.
本节描述了图1中内容截获请求接口（d）的一些需求。它使用公共请求协议（SNMPv3），而不考虑应用程序的类型（例如，语音、数据），并建议使用TAP-MIB，该协议在单独的文档[1]中定义。这里提供了导致使用SNMPv3和定义[1]中定义的特定管理信息库（MIB）的一些注意事项。
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:
为了提供用于截取、复制、封装和向MD传输内容包的通用接口，内容截取接口（图1中的（d））应指定：
* A Filter specification for classifying the packets to be intercepted.
* 用于对要截获的数据包进行分类的筛选器规范。
* The destination address of the MD (where to send the packets).
* MD的目标地址（发送数据包的位置）。
* 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.
此外，还应指定截取的超时值。这定义了截取的有限生存期，因此失败不会导致截取剩余时间超过其授权生存期。如果MD发生故障，无法为超时提供刷新，则在超时过期后，截获将停止存在。类似地，如果IAP重新引导，则除非IAP能够确定将继续满足拦截寿命要求，否则拦截将无法在重新引导后继续。
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.
为了使其工作，中介设备必须能够意识到IAP中存在故障，从而必须重新建立拦截。这可以是审计的形式（从MD到IAP），也可以是内容流中心跳机制的形式，或者两者兼而有之。
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.
封装方法应保留原始数据包中的所有信息（源和目标地址以及有效负载），并提供一个标识符，用于将数据包与IRI关联。[2]第4节描述了一种满足这些要求的封装。对于非语音截获，[2]表1中的“截获信息”字段包含原始截获的IP数据包。
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.
但是，请注意，[2]中定义的接口基于UDP，UDP是一种不可靠且无序的传输协议（即，在检测错误时不提供重传，也不提供数据排序）。如果使用这种传输，底层网络（第1-3层）的设计应满足内容交付的总体可靠性要求。
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].
如果需要更可靠的传输协议，则应使用一种机制，该机制可提供及时交付，并限制内容IAP的负担（处理和缓冲）。满足这些要求的一种机制是基于[12]的面向NACK的重传方案。
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.
如果使用[12]，则呼叫内容信道标识符可放置在封装RTP分组的SSRC字段中。有效载荷类型可用于识别封装在RTP中的分组的类型（例如，IP、PPP、以太网MAC）。请注意，[12]的用法仍在调查中，可能需要进一步规范。在内容IAP中使用[12]会给内容IAP带来比基于UDP的截取更大的处理负担，并且会影响内容IAP的容量。
This section applies the reference model to some example applications.
本节将参考模型应用于一些示例应用程序。
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.
本节将以本地语音服务为具体服务示例，探讨围绕IP语音呼叫拦截的一些问题。图1中的参考模型将与独立于使用中的呼叫信令协议的一组公共接口一起应用。
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:
IP语音有多种体系结构（例如集中式和分布式）以及各种协议（SIP[6]、H.323[9]、MGCP[7]、H.248[8]）。还可以提供多种服务：
* Local Voice Services (i.e., service to a user that has an IP phone or a phone connected to a gateway)
* 本地语音服务（即，为具有IP电话或连接到网关的电话的用户提供的服务）
* 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.
本文档不涉及服务提供商可能或可能不必支持拦截的任何义务。它简单地描述了如何使用图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.
注意，在截取主体通过非IP端点（例如TDM）访问网络的服务的情况下，可检测性问题不那么严重（例如，重新路由数据包以在特殊设备中截取它们是一种可能的选择），因为截取主体没有访问IP地址或跟踪路由的权限。
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端到端语音呼叫）的截获必须沿着其正常路由被截获，以便不被检测到。此外，通常作为本地服务功能提供的呼叫转发功能使得拦截变得更加困难：如果调用呼叫转发，则打算在拦截主题上终止的呼叫可以在网络中的任何位置转发，从而导致媒体流绕过原始内容IAP（在画外音中）
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.
IP，媒体流直接从端到端传输）。此外，由于呼叫转移通常可以逐个呼叫建立，因此在建立呼叫之前，通常不知道内容IAP的位置。
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).
本小节将介绍一种特定情况，即受监视的截获对象由同样提供网络访问的提供商提供本地语音服务（例如，控制边缘路由器或交换机）。这是一个重要的假设，因为在VoIP中，提供呼叫控制的实体（例如SIP服务器）可以与提供网络访问的实体（例如，操作边缘路由器）完全分离。
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).
假设订阅本地（例如，住宅）语音服务的用户是合法授权监视的目标。提供这些服务的系统的一部分是用户数据库，其中包括关于用户的寻址信息以及关于有效功能的信息（例如，呼叫转发）。一些呼叫控制实体（CCE）访问该数据库以提供本地服务。例如，如果主题调用了呼叫转移，则该事实（以及在何处转发呼叫）将在订户数据库中指示。到达“拥有”该用户的CCE的呼叫然后可以采取适当的操作（例如，转发呼叫）。
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).
“拥有”目标订户（可能是H.323网守、SIP代理或媒体网关控制器）的CCE配备有截获参数（例如，主体标识信息，如电话号码和IRI的交付地点）。这个CCE的供应可以通过图1中的接口（c）实现。所讨论的CCE是IRI IAP，一旦设置，它将IRI传递给MD。在所讨论的场景中，CCE通常在整个呼叫中保持在信令路径中，即使在呼叫转发情况下也是如此。它传递给MD的IRI的一部分是媒体信令信息（即SDP[11]或H.245[10]），其中包括媒体（内容）流的端点IP地址和端口信息。利用该媒体地址信息，MD可以确定内容IAP（例如，[5]），并通过接口（d）发出请求。该请求基于在呼叫信令中接收到的信息（即IP地址和UDP端口号）识别要截获的语音流。
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
注意，在IP语音的情况下，内容IAP可以是边缘路由器或PSTN网关（例如，从PSTN转发到PSTN的呼叫）。可以使用SIP、H.323、MGCP或H.248呼叫信令协议。但是，用于接口的协议（SNMPv3[1]）
(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).
（d） ，不依赖于所使用的呼叫信令协议的类型；封装格式和传输协议（接口“f”）也是如此。具有相同接口的相同参考模型（图1）可用于合法授权的监视，无论信令协议和所提供的服务类型如何（注意：即使在本例中使用了本地语音服务，其他语音服务也可以使用相同的模型和接口）。
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.
同样的模型（图1）也可以用于数据服务。在这种情况下，IRI IAP可以是充当数据服务的注册、身份验证和授权点的服务器（例如RADIUS服务器）。如果潜在的IRI IAP没有可用的接口（c）和（e），则MD可能必须在注册信令上进行内容点击以获得IRI。
The IRI in the case of a data service could include:
对于数据服务，IRI可包括：
* 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).
* 用户注册或注销服务的时间。*寻址信息（即，给定用户身份，可以在接口（d）中使用哪些IP地址或其他信息来进行内容点击）。
Once suitable addressing information is available in order to do content tapping the MD can invoke the tap via interface (d).
一旦合适的寻址信息可用以进行内容点击，MD可以通过接口（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.
显然，数据的IRI接口（c、e、g）与语音服务的IRI接口不同。然而，内容IAP通常是相同的（边缘路由器）。接口（d、f和h）也可以相同。
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.
鉴于合法拦截（LI）的敏感性质——从保护敏感数据以及隐藏拦截对象身份的角度来看，LI解决方案应能够提供严格的安全措施，以应对诸如假冒MD、隐私和保密违规等威胁，以及邮件伪造和重播攻击。
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.
虽然本文档没有在LI解决方案的主体中讨论物理安全、操作系统或应用程序强化问题，但它们显然很重要。特别是，MD服务器将被视为攻击的主要目标。
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.
一般来说，所有接口都应该能够提供强大的加密身份验证来建立主体的身份，并且能够将主体的身份与其试图执行的操作关联起来。所有接口都应该能够执行某种加密消息完整性检查，例如HMAC-MD5。消息完整性检查也可用于对抗重播攻击。出于隐私和保密考虑，可能还需要使用加密。
The content and IRI IAPs also should also provide protection of the identity of the intercept subject and the existence of an intercept.
内容和IRI IAP还应保护拦截主体的身份和拦截的存在。
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:
对于接口（d），使用本机SNMPv3安全模块机制。附加要求是IAP应支持保护TAP MIB[1]不被未经授权的USM[3]用户泄露或控制的能力。VACM[4]提供了必要的工具，将视图限制在特定的USM用户，但也有一些特殊的注意事项：
* 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.
* 限制只有那些建立了密钥并定义了正确的VACM视图的SNMPv3 USM用户访问适当TAP MIB的能力。
* Segregation of the TAP MIB such that only operators of sufficient privilege level can create VACM views that include the TAP MIB [1].
* 分离TAP MIB，以便只有具有足够权限级别的操作员才能创建包含TAP MIB的VACM视图[1]。
[1] Baker, F., "Cisco Lawful Intercept Control MIB", Work in Progress, April 2004.
[1] Baker，F.，“思科合法拦截控制MIB”，正在进行的工作，2004年4月。
[2] PacketCable(TM) Electronic Surveillance Specification, PKT-SP-
ESP-I04-040723, http://www.packetcable.com/specifications/
[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.
[3] Blumenthal，U.和B.Wijnen，“简单网络管理协议（SNMPv3）第3版的基于用户的安全模型（USM）”，STD 62，RFC 3414，2002年12月。
[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.
[4] Wijnen，B.，Presuhn，R.，和K.McCloghrie，“用于简单网络管理协议（SNMP）的基于视图的访问控制模型（VACM）”，STD 62，RFC 3415，2002年12月。
[5] Warnicke, E., "A Suggested Scheme for DNS Resolution of Networks and Gateways", Work in Progress.
[5] Warnicke，E.“网络和网关DNS解析的建议方案”，正在进行中。
[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.
[6] Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[7] Andreasen, F. and B. Foster, "Media Gateway Control Protocol (MGCP) Version 1.0", RFC 3435, January 2003.
[7] Andreasen，F.和B.Foster，“媒体网关控制协议（MGCP）1.0版”，RFC 3435，2003年1月。
[8] ITU-T Recommendation H.248.1, Gateway Control Protocol: Version 2, May 2002.
[8] ITU-T建议H.248.1，网关控制协议：版本2，2002年5月。
[9] ITU-T Recommendation H.323, Packet-based Multimedia Communications Systems, July 2003.
[9] ITU-T建议H.323，基于分组的多媒体通信系统，2003年7月。
[10] ITU-T Recommendation H.245, Control Protocol for Multimedia Communications, July 2003.
[10] ITU-T建议H.245，多媒体通信控制协议，2003年7月。
[11] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
[11] Handley，M.和V.Jacobson，“SDP：会话描述协议”，RFC 2327，1998年4月。
[12] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. Hakenber, "RTP Retransmission Payload Format", Work in Progress.
[12] Rey，J.，Leon，D.，Miyazaki，A.，Varsa，V.，和R.Hakenber，“RTP重传有效载荷格式”，工作正在进行中。
[13] ETSI TS 101 331, Telecommunications security; Lawful Interception (LI); Requirements of law enforcement agencies.
[13] ETSI TS 101 331，电信安全；合法拦截（LI）；执法机构的要求。
[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).
[14] ETSI TS 33.108 v6.7.0，第三代合作伙伴项目；技术规范组服务和系统方面；3G安全；合法拦截的切换接口（版本6）。
[15] IAB and IESG, "IETF Policy on Wiretapping", RFC 2804, May 2000.
[15] IAB和IESG，“IETF关于窃听的政策”，RFC 2804，2000年5月。
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
CCE呼叫控制实体CMTS电缆调制解调器终端系统CPE客户场所设备ETSI欧洲电信标准协会GPRS通用分组无线业务HMAC-MD5基于散列的消息认证码-消息摘要5 IAP拦截接入点IETF互联网工程任务组IRI拦截相关信息ITU-T国际电信联盟-电信部门LEA执法机构LI合法截获MGCP媒体网关控制协议MD中介设备MIB管理信息库NACK否定应答PSTN公共交换电信网络RFC征求意见RTP实时传输协议SDP会话描述协议SIP会话发起协议SSRC同步源TDM时分复用UDP用户数据报协议USM用户服务模型VACM基于视图的访问控制模型VoIP IP语音
Fred Baker Cisco Systems 1121 Via Del Rey Santa Barbara, CA 93117 US
Fred Baker Cisco Systems 1121 Via Del Rey Santa Barbara，加利福尼亚州，美国93117
Phone: +1-408-526-4257
Fax: +1-413-473-2403
EMail: fred@cisco.com
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
加拿大不列颠哥伦比亚省温哥华西彭德街21501050号比尔·福斯特思科系统公司套房，V6E 3S7
Phone: +1-604-647-2315
EMail: bfoster@cisco.com
Phone: +1-604-647-2315
EMail: bfoster@cisco.com
Chip Sharp Cisco Systems 7025 Kit Creek Road RTP, NC 27709 USA
Chip Sharp Cisco Systems 7025 Kit Creek Road RTP，美国北卡罗来纳州27709
Tel:+1.919.392.3121
EMail: chsharp@cisco.com
Tel:+1.919.392.3121
EMail: chsharp@cisco.com
Copyright (C) The Internet Society (2004).
版权所有（C）互联网协会（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.
本文件受BCP 78和www.rfc-editor.org中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
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.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关ISOC文件中权利的ISOC程序信息，请参见BCP 78和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.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为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.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。