Network Working Group H. Cruickshank
Request for Comments: 5458 University of Surrey
Category: Informational P. Pillai
University of Bradford
M. Noisternig
University of Salzburg
S. Iyengar
Logica
March 2009
Network Working Group H. Cruickshank
Request for Comments: 5458 University of Surrey
Category: Informational P. Pillai
University of Bradford
M. Noisternig
University of Salzburg
S. Iyengar
Logica
March 2009
Security Requirements for the Unidirectional Lightweight Encapsulation (ULE) Protocol
单向轻量级封装（ULE）协议的安全要求
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) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2009 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
本文件受BCP 78和IETF信托在本文件出版之日生效的与IETF文件有关的法律规定的约束(http://trustee.ietf.org/license-info). 请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
Abstract
摘要
The MPEG-2 standard defined by ISO 13818-1 supports a range of transmission methods for a variety of services. This document provides a threat analysis and derives the security requirements when using the Transport Stream, TS, to support an Internet network-layer using Unidirectional Lightweight Encapsulation (ULE) defined in RFC 4326. The document also provides the motivation for link-layer security for a ULE Stream. A ULE Stream may be used to send IPv4 packets, IPv6 packets, and other Protocol Data Units (PDUs) to an arbitrarily large number of Receivers supporting unicast and/or multicast transmission.
ISO 13818-1定义的MPEG-2标准支持各种服务的一系列传输方法。本文档提供了威胁分析，并推导了使用传输流TS支持互联网网络层时的安全要求，该层使用RFC 4326中定义的单向轻量级封装（ULE）。该文档还为ULE流的链接层安全性提供了动力。ULE流可用于向支持单播和/或多播传输的任意多个接收机发送IPv4分组、IPv6分组和其他协议数据单元（PDU）。
The analysis also describes applicability to the Generic Stream Encapsulation (GSE) defined by the Digital Video Broadcasting (DVB) Project.
分析还描述了数字视频广播（DVB）项目定义的通用流封装（GSE）的适用性。
Table of Contents
目录
1. Introduction ....................................................3
2. Requirements Notation ...........................................4
3. Threat Analysis .................................................7
3.1. System Components ..........................................7
3.2. Threats ....................................................9
3.3. Threat Cases ..............................................10
4. Security Requirements for IP over MPEG-2 TS ....................11
5. Design Recommendations for ULE Security Extension Header .......14
6. Compatibility with Generic Stream Encapsulation ................15
7. Summary ........................................................15
8. Security Considerations ........................................15
9. Acknowledgments ................................................16
10. References ....................................................16
10.1. Normative References .....................................16
10.2. Informative References ...................................17
Appendix A. ULE Security Framework ................................19
A.1. Building Block ............................................19
A.2. Interface Definition ......................................22
Appendix B. Motivation for ULE Link-Layer Security ................23
B.1. Security at the IP Layer (Using IPsec) ....................23
B.2. Link Security below the Encapsulation Layer ...............24
B.3. Link Security as a Part of the Encapsulation Layer ........25
1. Introduction ....................................................3
2. Requirements Notation ...........................................4
3. Threat Analysis .................................................7
3.1. System Components ..........................................7
3.2. Threats ....................................................9
3.3. Threat Cases ..............................................10
4. Security Requirements for IP over MPEG-2 TS ....................11
5. Design Recommendations for ULE Security Extension Header .......14
6. Compatibility with Generic Stream Encapsulation ................15
7. Summary ........................................................15
8. Security Considerations ........................................15
9. Acknowledgments ................................................16
10. References ....................................................16
10.1. Normative References .....................................16
10.2. Informative References ...................................17
Appendix A. ULE Security Framework ................................19
A.1. Building Block ............................................19
A.2. Interface Definition ......................................22
Appendix B. Motivation for ULE Link-Layer Security ................23
B.1. Security at the IP Layer (Using IPsec) ....................23
B.2. Link Security below the Encapsulation Layer ...............24
B.3. Link Security as a Part of the Encapsulation Layer ........25
The MPEG-2 Transport Stream (TS) has been widely accepted not only for providing digital TV services, but also as a subnetwork technology for building IP networks. RFC 4326 [RFC4326] describes the Unidirectional Lightweight Encapsulation (ULE) mechanism for the transport of IPv4 and IPv6 Datagrams and other network protocol packets directly over the ISO MPEG-2 Transport Stream as TS Private Data. ULE specifies a base encapsulation format and supports an Extension Header format that allows it to carry additional header information to assist in network/Receiver processing. The encapsulation satisfies the design and architectural requirement for a lightweight encapsulation defined in RFC 4259 [RFC4259].
MPEG-2传输流（TS）已被广泛接受，不仅用于提供数字电视服务，而且作为构建IP网络的子网技术。RFC 4326[RFC4326]描述了单向轻量级封装（ULE）机制，用于直接通过ISO MPEG-2传输流将IPv4和IPv6数据报以及其他网络协议数据包传输为TS专用数据。ULE指定基本封装格式，并支持扩展头格式，该格式允许其携带附加头信息以协助网络/接收器处理。封装满足RFC 4259[RFC4259]中定义的轻量级封装的设计和体系结构要求。
Section 3.1 of RFC 4259 presents several topological scenarios for MPEG-2 Transmission Networks. A summary of these scenarios is presented below:
RFC 4259第3.1节介绍了MPEG-2传输网络的几种拓扑方案。这些场景的摘要如下所示：
A. Broadcast TV and Radio Delivery. This is not within the scope of this document.
A.广播电视和无线电广播。这不在本文件的范围内。
B. Broadcast Networks used as an ISP. This resembles scenario A, but includes IP services to access the public Internet.
B.用作ISP的广播网络。这类似于场景A，但包括访问公共互联网的IP服务。
C. Unidirectional Star IP Scenario. This provides a data network delivering a common bit stream to typically medium-sized groups of Receivers.
C.单向星形IP场景。这提供了一个数据网络，向典型的中型接收机组传送公共比特流。
D. Datacast Overlay. This employs MPEG-2 physical and link layers to provide additional connectivity such as unidirectional multicast to supplement an existing IP-based Internet service.
数据广播覆盖。这采用MPEG-2物理层和链路层来提供额外的连接，例如单向多播，以补充现有的基于IP的互联网服务。
E. Point-to-Point Links. This connectivity may be provided using a pair of transmit and receive interfaces.
E.点对点链接。可以使用一对发送和接收接口来提供这种连接。
F. Two-Way IP Networks.
F.双向IP网络。
RFC 4259 states that ULE must be robust to errors and security threats. Security must also consider both unidirectional (A, B, C, and D) as well as bidirectional (E and F) links for the scenarios mentioned above.
RFC 4259指出，ULE必须对错误和安全威胁具有鲁棒性。安全性还必须考虑单向（A，B，C，D）以及双向（E和F）链接的情况下，上面提到的。
An initial analysis of the security requirements in MPEG-2 transmission networks is presented in the "Security Considerations" section of RFC 4259. For example, when such networks are not using a wireline network, the normal security issues relating to the use of wireless links for transport of Internet traffic should be considered [RFC3819].
RFC 4259的“安全注意事项”一节对MPEG-2传输网络中的安全要求进行了初步分析。例如，当此类网络未使用有线网络时，应考虑与使用无线链路传输互联网流量有关的正常安全问题[RFC3819]。
The security considerations of RFC 4259 recommend that any new encapsulation defined by the IETF should allow Transport Stream encryption and should also support optional link-layer authentication of the Subnetwork Data Unit (SNDU) payload. In ULE [RFC4326], it is suggested that this may be provided in a flexible way using Extension Headers. This requires the definition of a mandatory Extension Header, but has the advantage that it decouples specification of the security functions from the encapsulation functions.
RFC 4259的安全考虑建议IETF定义的任何新封装应允许传输流加密，并且还应支持子网数据单元（SNDU）有效载荷的可选链路层认证。在ULE[RFC4326]中，建议使用扩展头以灵活的方式提供。这需要定义一个必需的扩展头，但其优点是它将安全函数的规范与封装函数分离。
This document extends the above analysis and derives in detail the security requirements for ULE in MPEG-2 transmission networks.
本文档扩展了上述分析，并详细推导了MPEG-2传输网络中ULE的安全要求。
A security framework for deployment of secure ULE networks describing the different building blocks and the interface definitions is presented in Appendix A.
附录A中给出了安全ULE网络部署的安全框架，描述了不同的构建块和接口定义。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
Other terms used in this document are defined below:
本文件中使用的其他术语定义如下：
ATSC: Advanced Television Systems Committee. A framework and a set of associated standards for the transmission of video, audio, and data using the ISO MPEG-2 Standard.
先进电视系统委员会。使用ISO MPEG-2标准传输视频、音频和数据的框架和一组相关标准。
DVB: Digital Video Broadcast. A framework and set of associated standards published by the European Telecommunications Standards Institute (ETSI) for the transmission of video, audio, and data using the ISO MPEG-2 Standard [ISO-MPEG2].
DVB：数字视频广播。欧洲电信标准协会（ETSI）发布的一个框架和一组相关标准，用于使用ISO MPEG-2标准[ISO-MPEG2]传输视频、音频和数据。
Encapsulator: A network device that receives Protocol Data Units (PDUs) and formats these into Payload Units (known here as SNDUs) for output as a stream of TS Packets.
封装器：一种网络设备，接收协议数据单元（PDU）并将其格式化为有效负载单元（此处称为SNDU），以作为TS数据包流输出。
GCKS: Group Controller and Key Server. A server that authenticates and provides the policy and keying material to members of a secure group.
GCKS：组控制器和密钥服务器。对安全组的成员进行身份验证并提供策略和密钥材料的服务器。
LLC: Logical Link Control [ISO-8802], [IEEE-802]. A link-layer protocol defined by the IEEE 802 standard, which follows the Ethernet Medium Access Control Header.
逻辑链路控制[ISO-8802]，[IEEE-802]。由IEEE 802标准定义的链路层协议，遵循以太网介质访问控制报头。
MAC: Message Authentication Code.
MAC：消息身份验证代码。
MPE: Multiprotocol Encapsulation [ETSI-DAT]. A scheme that encapsulates PDUs, forming a Digital Storage Media Command and Control (DSM-CC) Table Section. Each Section is sent in a series of TS Packets using a single TS Logical Channel.
MPE：多协议封装[ETSI-DAT]。一种封装PDU的方案，形成数字存储媒体命令和控制（DSM-CC）表部分。每个部分使用单个TS逻辑信道在一系列TS数据包中发送。
MPEG-2: A set of standards specified by the Motion Picture Experts Group (MPEG) and standardised by the International Standards Organisation (ISO/IEC 13818-1) [ISO-MPEG2], and ITU-T (in H.222 [ITU-H222]).
MPEG-2：由电影专家组（MPEG）规定并由国际标准组织（ISO/IEC 13818-1）[ISO-MPEG2]和ITU-T（H.222[ITU-H222]中）标准化的一组标准。
NPA: Network Point of Attachment. In this document, refers to a 6-byte destination address (resembling an IEEE Medium Access Control address) within the MPEG-2 transmission network that is used to identify individual Receivers or groups of Receivers.
NPA：网络连接点。在本文档中，指的是MPEG-2传输网络内的6字节目标地址（类似于IEEE介质访问控制地址），用于识别单个接收机或接收机组。
PDU: Protocol Data Unit. Examples of a PDU include Ethernet frames, IPv4 or IPv6 Datagrams, and other network packets.
协议数据单元。PDU的示例包括以太网帧、IPv4或IPv6数据报以及其他网络数据包。
PID: Packet Identifier [ISO-MPEG2]. A 13-bit field carried in the header of TS Packets. This is used to identify the TS Logical Channel to which a TS Packet belongs [ISO-MPEG2]. The TS Packets forming the parts of a Table Section, Packetised Elementary Stream (PES), or other Payload Unit must all carry the same PID value. The all-zeros PID 0x0000 as well as other PID values are reserved for specific PSI/SI Tables [ISO-MPEG2]. The all-ones PID value 0x1FFF indicates a Null TS Packet introduced to maintain a constant bit rate of a TS Multiplex. There is no required relationship between the PID values used for TS Logical Channels transmitted using different TS Multiplexes.
PID：数据包标识符[ISO-MPEG2]。TS数据包报头中携带的13位字段。这用于标识TS数据包所属的TS逻辑信道[ISO-MPEG2]。构成表格部分、分组基本流（PES）或其他有效负载单元的TS数据包必须全部携带相同的PID值。全零PID 0x0000以及其他PID值保留用于特定PSI/SI表[ISO-MPEG2]。all ones PID值0x1FFF表示为保持TS多路复用的恒定比特率而引入的空TS数据包。使用不同的TS多路复用器传输的TS逻辑信道所用的PID值之间没有必要的关系。
Receiver: Equipment that processes the signal from a TS Multiplex and performs filtering and forwarding of encapsulated PDUs to the network-layer service (or bridging module when operating at the link layer).
接收器：处理来自TS多路复用的信号并对封装的PDU进行过滤和转发到网络层服务（或在链路层操作时桥接模块）的设备。
SI Table: Service Information Table [ISO-MPEG2]. In this document, this term describes a table that is defined by another standards body to convey information about the services carried in a TS Multiplex. A Table may consist of one or more Table Sections; however, all sections of a particular SI Table must be carried over a single TS Logical Channel [ISO-MPEG2].
SI表：服务信息表[ISO-MPEG2]。在本文件中，该术语描述了由另一个标准机构定义的表，以传达关于TS多路复用中承载的服务的信息。一个表格可以由一个或多个表格部分组成；但是，特定SI表的所有部分必须通过单个TS逻辑通道[ISO-MPEG2]传输。
SNDU: SubNetwork Data Unit. An encapsulated PDU sent as an MPEG-2 Payload Unit.
SNDU：子网数据单元。作为MPEG-2有效负载单元发送的封装PDU。
TS: Transport Stream [ISO-MPEG2]. A method of transmission at the MPEG-2 layer using TS Packets; it represents Layer 2 of the ISO/OSI reference model. See also TS Logical Channel and TS Multiplex.
TS：传输流[ISO-MPEG2]。使用TS分组在MPEG-2层进行传输的方法；它代表ISO/OSI参考模型的第2层。另请参见TS逻辑通道和TS多路复用。
TS Multiplex: In this document, this term defines a set of MPEG-2 TS Logical Channels sent over a single lower-layer connection. This may be a common physical link (i.e., a transmission at a specified symbol rate, Forward Error Correction (FEC) setting, and transmission frequency) or an encapsulation provided by another protocol layer (e.g., Ethernet, or RTP over IP). The same TS Logical Channel may be repeated over more than one TS Multiplex (possibly associated with a different PID value) [RFC4259]; for example, to redistribute the same multicast content to two terrestrial TV transmission cells.
TS多路复用：在本文档中，该术语定义了通过单个较低层连接发送的一组MPEG-2 TS逻辑通道。这可以是公共物理链路（即，以指定符号速率的传输、前向纠错（FEC）设置和传输频率）或由另一协议层（例如，以太网或RTP over IP）提供的封装。同一TS逻辑信道可在多个TS多路复用上重复（可能与不同的PID值相关）[RFC4259]；例如，将相同的多播内容重新分发到两个地面电视传输小区。
TS Packet: A fixed-length 188-byte unit of data sent over a TS Multiplex [ISO-MPEG2]. Each TS Packet carries a 4-byte header, plus optional overhead including an Adaptation Field, encryption details, and time stamp information to synchronise a set of related TS Logical Channels.
TS数据包：通过TS多路复用发送的固定长度188字节的数据单位[ISO-MPEG2]。每个TS数据包携带一个4字节的报头，外加可选开销，包括自适应字段、加密细节和时间戳信息，以同步一组相关TS逻辑信道。
ULE Stream: An MPEG-2 TS Logical Channel that carries only ULE encapsulated PDUs. ULE Streams may be identified by definition of a stream_type in SI/PSI [ISO-MPEG2].
ULE流：仅承载ULE封装PDU的MPEG-2 TS逻辑通道。ULE流可通过SI/PSI[ISO-MPEG2]中的流类型定义来识别。
+------------+ +------------+
| IP | | IP |
| End Host | | End Host |
+-----+------+ +------------+
| ^
+------------>+---------------+ |
+ ULE | |
+-------------+ Encapsulator | |
SI-Data | +------+--------+ |
+-------+-------+ |MPEG-2 TS Logical Channel |
| MPEG-2 | | |
| SI Tables | | |
+-------+-------+ ->+------+--------+ |
| -->| MPEG-2 | . . .
+------------>+ Multiplexer | |
MPEG-2 TS +------+--------+ |
Logical Channel |MPEG-2 TS Mux |
| |
Other ->+------+--------+ |
MPEG-2 -->+ MPEG-2 | |
TS --->+ Multiplexer | |
---->+------+--------+ |
|MPEG-2 TS Mux |
| |
+------+--------+ +------+-----+
|Physical Layer | | MPEG-2 |
|Modulator +---------->+ Receiver |
+---------------+ MPEG-2 +------------+
TS Mux
+------------+ +------------+
| IP | | IP |
| End Host | | End Host |
+-----+------+ +------------+
| ^
+------------>+---------------+ |
+ ULE | |
+-------------+ Encapsulator | |
SI-Data | +------+--------+ |
+-------+-------+ |MPEG-2 TS Logical Channel |
| MPEG-2 | | |
| SI Tables | | |
+-------+-------+ ->+------+--------+ |
| -->| MPEG-2 | . . .
+------------>+ Multiplexer | |
MPEG-2 TS +------+--------+ |
Logical Channel |MPEG-2 TS Mux |
| |
Other ->+------+--------+ |
MPEG-2 -->+ MPEG-2 | |
TS --->+ Multiplexer | |
---->+------+--------+ |
|MPEG-2 TS Mux |
| |
+------+--------+ +------+-----+
|Physical Layer | | MPEG-2 |
|Modulator +---------->+ Receiver |
+---------------+ MPEG-2 +------------+
TS Mux
Figure 1: An example configuration for a unidirectional service for IP transport over MPEG-2 (adapted from [RFC4259])
图1:MPEG-2上IP传输的单向服务的示例配置（改编自[RFC4259]）
As shown in Figure 1 above (from Section 3.3 of [RFC4259]), there are several entities within the MPEG-2 transmission network architecture. These include:
如上图1所示（来自[RFC4259]第3.3节），MPEG-2传输网络架构中有多个实体。这些措施包括：
o ULE Encapsulation Gateways (the ULE Encapsulator)
o ULE封装网关（ULE封装器）
o SI-Table signalling generator (input to the multiplexer)
o SI表信号发生器（多路复用器的输入）
o Receivers (the endpoints for ULE Streams)
o 接收器（ULE流的端点）
o TS multiplexers (including re-multiplexers)
o TS多路复用器（包括再多路复用器）
o Modulators
o 调制器
The TS Packets are carried to the Receiver over a physical layer that usually includes Forward Error Correction (FEC) coding that interleaves the bytes of several consecutive, but unrelated, TS Packets. FEC-coding and synchronisation processing makes injection of single TS Packets very difficult. Replacement of a sequence of packets is also difficult, but possible (see Section 3.2).
TS分组通过通常包括前向纠错（FEC）编码的物理层传送到接收机，前向纠错（FEC）编码将几个连续但不相关的TS分组的字节交织。FEC编码和同步处理使得单个TS分组的注入非常困难。数据包序列的替换也很困难，但也是可能的（见第3.2节）。
A Receiver in an MPEG-2 TS transmission network needs to identify a TS Logical Channel (or MPEG-2 Elementary Stream) to reassemble the fragments of PDUs sent by an L2 source [RFC4259]. In an MPEG-2 TS, this association is made via the Packet Identifier, PID [ISO-MPEG2]. At the sender, each source associates a locally unique set of PID values with each stream it originates. However, there is no required relationship between the PID value used at the sender and that received at the Receiver. Network devices may re-number the PID values associated with one or more TS Logical Channels (e.g., ULE Streams) to prevent clashes at a multiplexer between input streams with the same PID carried on different input multiplexes (updating entries in the PMT [ISO-MPEG2], and other SI tables that reference the PID value). A device may also modify and/or insert new SI data into the control plane (also sent as TS Packets identified by their PID value). However, there is only one valid source of data for each MPEG-2 Elementary Stream, bound to a PID value. (This observation could simplify the requirement for authentication of the source of a ULE Stream.)
MPEG-2 TS传输网络中的接收器需要识别TS逻辑信道（或MPEG-2基本流），以重新组装L2源发送的PDU片段[RFC4259]。在MPEG-2ts中，该关联通过分组标识符PID[ISO-MPEG2]进行。在发送方，每个源将一组本地唯一的PID值与它发起的每个流相关联。但是，发送方使用的PID值与接收方接收的PID值之间没有必要的关系。网络设备可以对与一个或多个TS逻辑信道（例如，ULE流）相关联的PID值重新编号，以防止具有在不同输入多路复用器上携带的相同PID的输入流之间在多路复用器处发生冲突（更新PMT[ISO-MPEG2]中的条目，以及参考PID值的其他SI表）。设备还可以修改和/或将新的SI数据插入控制平面（也作为由其PID值标识的TS数据包发送）。然而，每个MPEG-2基本流只有一个有效的数据源，绑定到PID值。（此观察可以简化对ULE流源的身份验证要求。）
In an MPEG-2 network, a set of signalling messages [RFC4947] may need to be broadcast (e.g., by an Encapsulation Gateway or other device) to form the L2 control plane. Examples of signalling messages include the Program Association Table (PAT), Program Map Table (PMT), and Network Information Table (NIT). In existing MPEG-2 transmission networks, these messages are broadcast in the clear (no encryption or integrity checks). The integrity as well as authenticity of these messages is important for correct working of the ULE network, i.e., supporting its security objectives in the area of availability, in addition to confidentiality and integrity. One method recently proposed [RFC5163] encapsulates these messages using ULE. In such cases all the security requirements of this document apply in securing these signalling messages.
在MPEG-2网络中，可能需要广播一组信令消息[RFC4947]（例如，通过封装网关或其他设备）以形成L2控制平面。信令消息的示例包括节目关联表（PAT）、节目映射表（PMT）和网络信息表（NIT）。在现有的MPEG-2传输网络中，这些消息以明文广播（无加密或完整性检查）。这些消息的完整性和真实性对于ULE网络的正确工作非常重要，即除了机密性和完整性之外，还支持其可用性领域的安全目标。最近提出的一种方法[RFC5163]使用ULE封装这些消息。在这种情况下，本文件的所有安全要求适用于保护这些信令消息。
ULE Stream security only concerns the security between the ULE Encapsulation Gateway (ULE Encapsulator) and the Receiver. In many deployment scenarios the user of a ULE Stream has to secure communications beyond the link since other network links are utilised in addition to the ULE link. Therefore, if authentication of the endpoints, i.e., the IP Sources, is required, or users are concerned
ULE流安全性只涉及ULE封装网关（ULE封装器）和接收器之间的安全性。在许多部署场景中，ULE流的用户必须确保链路之外的通信安全，因为除了ULE链路之外还使用其他网络链路。因此，如果需要对端点（即IP源）进行身份验证，或者涉及用户
about loss of confidentiality, integrity, or authenticity of their communication data, they will have to employ end-to-end network security mechanisms, e.g., IPsec or Transport Layer Security (TLS). Governmental users may be forced by regulations to employ specific approved implementations of those mechanisms. Hence, for such cases, the requirements for confidentiality and integrity of the user data will be met by the end-to-end security mechanism and the ULE security measures would focus on providing traffic flow confidentiality either for user data that has already been encrypted or for users who choose not to implement end-to-end security mechanisms.
关于通信数据的机密性、完整性或真实性的损失，他们必须采用端到端网络安全机制，例如IPsec或传输层安全（TLS）。政府用户可能会因法规而被迫采用这些机制的特定核准实施。因此，在这种情况下，端到端安全机制将满足用户数据的机密性和完整性要求，ULE安全措施将侧重于为已经加密的用户数据或选择不实施端到端安全机制的用户提供流量机密性。
ULE links may also be used for communications where the two IP endpoints are not under central control (e.g., when browsing a public web site). In these cases, it may be impossible to enforce any end-to-end security mechanisms. Yet, a common objective is that users may make the same security assumptions as for wired links [RFC3819]. ULE security could achieve this by protecting the vulnerable (in terms of passive attacks) ULE Stream.
ULE链路也可用于两个IP端点不受中央控制的通信（例如，在浏览公共网站时）。在这些情况下，可能无法实施任何端到端安全机制。然而，一个共同的目标是用户可以做出与有线链路相同的安全假设[RFC3819]。ULE安全可以通过保护易受攻击的ULE流（就被动攻击而言）来实现这一点。
In contrast to the above, a ULE Stream can be used to link networks such as branch offices to a central office. ULE link-layer security could be the sole provider of confidentiality and integrity. In this scenario, users requiring high assurance of security (e.g., government use) will need to employ approved cryptographic equipment (e.g., at the network layer). An implementation of ULE Link Security equipment could also be certified for use by specific user communities.
与上述相反，ULE流可用于将诸如分支办公室之类的网络链接到中央办公室。ULE链路层安全性可能是机密性和完整性的唯一提供者。在这种情况下，需要高度安全保证（例如，政府使用）的用户将需要使用经批准的加密设备（例如，在网络层）。ULE链路安全设备的实现也可以通过认证供特定用户社区使用。
The simplest type of network threat is a passive threat. This includes eavesdropping or monitoring of transmissions, with a goal to obtain information that is being transmitted. In broadcast networks (especially those utilising widely available low-cost physical layer interfaces, such as DVB), the passive threats are the major threats. One example is an intruder monitoring the MPEG-2 transmission broadcast and then extracting the data carried within the link. Another example is an intruder trying to determine the identity of the communicating parties and the volume of their traffic by sniffing (L2) addresses. This is a well-known issue in the security field; however, it is more of a problem in the case of broadcast networks such as MPEG-2 transmission networks because of the easy availability of Receiver hardware and the wide geographical span of the networks.
最简单的网络威胁类型是被动威胁。这包括窃听或监控传输，目的是获取正在传输的信息。在广播网络中（特别是那些利用广泛可用的低成本物理层接口的网络，如DVB），被动威胁是主要威胁。一个例子是入侵者监视MPEG-2传输广播，然后提取链路中携带的数据。另一个例子是入侵者试图通过嗅探（L2）地址来确定通信方的身份及其通信量。这是安全领域的一个众所周知的问题；然而，在诸如MPEG-2传输网络之类的广播网络的情况下，这是一个更大的问题，因为接收机硬件的易用性和网络的广泛地理范围。
Active threats (or attacks) are, in general, more difficult to implement successfully than passive threats, and usually require more sophisticated resources and may require access to the transmitter. Within the context of MPEG-2 transmission networks, examples of active attacks are:
主动威胁（或攻击）通常比被动威胁更难成功实施，通常需要更复杂的资源，并且可能需要访问发射机。在MPEG-2传输网络的上下文中，主动攻击的示例包括：
o Masquerading: An entity pretends to be a different entity. This includes masquerading other users and subnetwork control plane messages.
o 伪装：一个实体伪装成另一个实体。这包括伪装其他用户和子网控制平面消息。
o Modification of messages in an unauthorised manner.
o 以未经授权的方式修改消息。
o Replay attacks: When an intruder sends some old (authentic) messages to the Receiver. In the case of a broadcast link, access to previous broadcast data is easy.
o 重播攻击：当入侵者向接收者发送一些旧的（真实的）消息时。在广播链路的情况下，访问先前的广播数据是容易的。
o Denial-of-Service (DoS) attacks: When an entity fails to perform its proper function or acts in a way that prevents other entities from performing their proper functions.
o 拒绝服务（DoS）攻击：当一个实体无法执行其正常功能或其行为方式阻止其他实体执行其正常功能时。
The active threats mentioned above are major security concerns for the Internet community [BELLOVIN]. Masquerading and modification of IP packets are comparatively easy in an Internet environment, whereas such attacks are in fact much harder for MPEG-2 broadcast links. This could, for instance, motivate the mandatory use of sequence numbers in IPsec, but not for synchronous links. This is further reflected in the security requirements for Case 2 and 3 in Section 4 below.
上述主动威胁是互联网社区的主要安全问题[BELLOVIN]。在互联网环境中，伪装和修改IP数据包相对容易，而对于MPEG-2广播链路来说，这种攻击实际上要困难得多。例如，这可能会促使在IPsec中强制使用序列号，但不会用于同步链路。下文第4节案例2和案例3的安保要求进一步反映了这一点。
As explained in Section 3.1, the PID associated with an Elementary Stream can be modified (e.g., in some systems by reception of an updated SI table, or in other systems until the next announcement/discovery data is received). An attacker that is able to modify the content of the received multiplex (e.g., replay data and/or control information) could inject data locally into the received stream with an arbitrary PID value.
如第3.1节所述，可以修改与基本流相关联的PID（例如，在一些系统中，通过接收更新的SI表，或者在其他系统中，直到接收到下一个公告/发现数据）。能够修改接收到的多路复用内容（例如，重播数据和/或控制信息）的攻击者可以使用任意PID值将数据本地注入到接收到的流中。
Analysing the topological scenarios for MPEG-2 Transmission Networks in Section 1, the security threats can be abstracted into three cases:
在第1节中，通过分析MPEG-2传输网络的拓扑场景，可以将安全威胁抽象为三种情况：
o Case 1: Monitoring (passive threat). Here the intruder monitors the ULE broadcasts to gain information about the ULE data and/or tracking the communicating parties identities (by monitoring the destination NPA address). In this scenario, measures must be taken to protect the ULE payload data and the identity of ULE Receivers.
o 案例1：监测（被动威胁）。在此，入侵者监视ULE广播以获取有关ULE数据的信息和/或跟踪通信方身份（通过监视目标NPA地址）。在这种情况下，必须采取措施保护ULE有效载荷数据和ULE接收器的身份。
o Case 2: Locally conducting active attacks on the MPEG-TS multiplex. Here an intruder is assumed to be sufficiently sophisticated to override the original transmission from the ULE Encapsulation Gateway and deliver a modified version of the MPEG-TS transmission to a single ULE Receiver or a small group of Receivers (e.g., in a single company site). The MPEG-2 transmission network operator might not be aware of such attacks. Measures must be taken to ensure ULE data integrity and authenticity and preventing replay of old messages.
o 案例2：对MPEG-TS多路复用进行本地主动攻击。这里，假定入侵者足够复杂，能够覆盖来自ULE封装网关的原始传输，并将修改后的MPEG-TS传输版本传送到单个ULE接收器或一小群接收器（例如，在单个公司站点中）。MPEG-2传输网络运营商可能不知道此类攻击。必须采取措施确保数据的完整性和真实性，并防止重播旧消息。
o Case 3: Globally conducting active attacks on the MPEG-TS multiplex. This assumes a sophisticated intruder able to override the whole MPEG-2 transmission multiplex. The requirements are similar to case 2. The MPEG-2 transmission network operator can usually identify such attacks and provide corrective action to restore the original transmission.
o 案例3：对MPEG-TS多路复用进行全局主动攻击。这假设一个复杂的入侵者能够覆盖整个MPEG-2传输多路复用。这些要求与案例2类似。MPEG-2传输网络运营商通常可以识别此类攻击，并提供纠正措施以恢复原始传输。
For both Cases 2 and 3, there can be two sub-cases:
对于案例2和案例3，可以有两个子案例：
o Insider attacks, i.e., active attacks from adversaries within the network with knowledge of the secret material.
o 内部攻击，即网络内知道秘密材料的对手发起的主动攻击。
o Outsider attacks, i.e., active attacks from adversaries without knowledge of the secret material.
o 外部攻击，即对手在不知道秘密材料的情况下主动发起的攻击。
In terms of priority, Case 1 is considered the major threat in MPEG-2 transmission systems. Case 2 is considered a lesser threat, appropriate to specific network configurations, especially when vulnerable to insider attacks. Case 3 is less likely to be found in an operational network, and is expected to be noticed by the MPEG-2 transmission operator. It will require restoration of the original transmission. The assumption being that physical access to the network components (multiplexers, etc.) and/or connecting physical media is secure. Therefore, Case 3 is not considered further in this document.
就优先级而言，情况1被认为是MPEG-2传输系统中的主要威胁。案例2被认为是较小的威胁，适用于特定的网络配置，特别是当易受内部攻击时。情况3不太可能在操作网络中找到，并且预期会被MPEG-2传输运营商注意到。这将需要恢复原来的传输。假设对网络组件（多路复用器等）和/或连接物理介质的物理访问是安全的。因此，本文件不进一步考虑案例3。
From the threat analysis in Section 3, the following security requirements can be derived:
根据第3节中的威胁分析，可得出以下安全要求：
Req 1. Data confidentiality MUST be provided by a link that supports ULE Stream Security to prevent passive attacks and reduce the risk of active threats.
要求1。数据保密性必须由支持ULE流安全的链路提供，以防止被动攻击并降低主动威胁的风险。
Req 2. Protection of L2 NPA address is OPTIONAL. In broadcast networks, this protection can be used to prevent an intruder tracking the identity of ULE Receivers and the volume of their traffic.
要求2。二级NPA地址的保护是可选的。在广播网络中，这种保护可用于防止入侵者跟踪ULE接收器的身份及其通信量。
Req 3. Integrity protection and source authentication of ULE Stream data are OPTIONAL. These can be used to prevent the active attacks described in Section 3.2.
要求3。ULE流数据的完整性保护和源身份验证是可选的。这些可用于防止第3.2节所述的主动攻击。
Req 4. Protection against replay attacks is OPTIONAL. This is used to counter the active attacks described in Section 3.2.
要求4。防止重播攻击是可选的。这用于对抗第3.2节中描述的主动攻击。
Req 5. L2 ULE Source and Receiver authentication is OPTIONAL. This can be performed during the initial key exchange and authentication phase, before the ULE Receiver can join a secure session with the ULE Encapsulator (ULE source). This could be either unidirectional or bidirectional authentication based on the underlying key management protocol.
要求5。源和接收器身份验证是可选的。这可以在初始密钥交换和身份验证阶段执行，然后ULE接收器可以加入与ULE封装器（ULE源）的安全会话。这可以是基于底层密钥管理协议的单向或双向身份验证。
Other general requirements for all threat cases for link-layer security are:
链路层安全的所有威胁情况的其他一般要求如下：
GReq (a) ULE key management functions MUST be decoupled from ULE security services such as encryption and source authentication. This allows the independent development of both systems.
GReq（a）ULE密钥管理功能必须与ULE安全服务（如加密和源身份验证）分离。这允许两个系统的独立开发。
GReq (b) Support SHOULD be provided for automated as well as manual insertion of keys and policy into the relevant databases.
GReq（b）支持自动和手动将密钥和策略插入相关数据库。
GReq (c) Algorithm agility MUST be supported. It should be possible to update the crypto algorithms and hashes when they become obsolete without affecting the overall security of the system.
必须支持GReq（c）算法的敏捷性。当密码算法和散列过时时，应该可以更新它们，而不会影响系统的整体安全性。
GReq (d) The security extension header MUST be compatible with other ULE extension headers. The method must allow other extension headers (either mandatory or optional) to be used in combination with a security extension. It is RECOMMENDED that these are placed after the security extension header. This permits full protection for all headers. It also avoids situations where the SNDU has to be discarded on processing the security extension header, while preceding headers have already been evaluated. One exception is the Timestamp extension that SHOULD precede the security extension header [RFC5163]. In this case, the timestamp will be unaffected by security services such as data confidentiality and can be decoded without the need for key material.
GReq（d）安全扩展标头必须与其他ULE扩展标头兼容。该方法必须允许将其他扩展头（强制或可选）与安全扩展结合使用。建议将它们放在安全扩展标题之后。这允许对所有收割台进行全面保护。它还避免了在处理安全扩展头时必须丢弃SNDU，而前面的头已经被评估过的情况。一个例外是时间戳扩展，它应该位于安全扩展头[RFC5163]之前。在这种情况下，时间戳将不受诸如数据机密性之类的安全服务的影响，并且可以在不需要关键材料的情况下解码。
Examining the threat cases in Section 3.3, the security requirements for each case can be summarised as:
检查第3.3节中的威胁案例，每个案例的安全要求可总结为：
o Case 1: Data confidentiality (Req 1) MUST be provided to prevent monitoring of the ULE data (such as user information and IP addresses). Protection of NPA addresses (Req 2) MAY be provided to prevent tracking ULE Receivers and their communications.
o 案例1：必须提供数据保密性（Req 1），以防止监控ULE数据（如用户信息和IP地址）。可提供NPA地址保护（Req 2），以防止跟踪ULE接收器及其通信。
o Case 2: In addition to Case 1 requirements, new measures MAY be implemented such as authentication schemes using Message Authentication Codes, digital signatures, or Timed Efficient Stream Loss-Tolerant Authentication (TESLA) [RFC4082] in order to provide integrity protection and source authentication (Reqs 3 and 5). In addition, sequence numbers (Req 4) MAY be used to protect against replay attacks. In terms of outsider attacks, group authentication using Message Authentication Codes can provide the required level of security (Reqs 3 and 5). This will significantly reduce the ability of intruders to successfully inject their own data into the MPEG-TS stream. However, scenario 2 threats apply only in specific service cases, and therefore authentication and protection against replay attacks are OPTIONAL. Such measures incur additional transmission as well as processing overheads. Moreover, intrusion detection systems may also be needed by the MPEG-2 network operator. These should best be coupled with perimeter security policy to monitor common DoS attacks.
o 案例2：除了案例1的要求外，还可以实施新的措施，例如使用消息认证码、数字签名或定时高效流丢失容忍认证（TESLA）[RFC4082]的认证方案，以提供完整性保护和源认证（要求3和5）。此外，序列号（Req 4）可用于防止重播攻击。就外部攻击而言，使用消息身份验证代码的组身份验证可以提供所需的安全级别（要求3和5）。这将大大降低入侵者成功将自己的数据注入MPEG-TS流的能力。但是，场景2的威胁仅适用于特定的服务情况，因此身份验证和防止重播攻击是可选的。这些措施会带来额外的传输和处理开销。此外，MPEG-2网络运营商也可能需要入侵检测系统。最好将其与周边安全策略结合起来，以监控常见的DoS攻击。
o Case 3: As stated in Section 3.3, the requirements here are similar to Case 2, but since the MPEG-2 transmission network operator can usually identify such attacks, the constraints on intrusion detections are less than in Case 2.
o 案例3：如第3.3节所述，此处的要求与案例2类似，但由于MPEG-2传输网络运营商通常可以识别此类攻击，因此入侵检测的限制小于案例2。
Table 1 below shows the threats that are applicable to ULE networks, and the relevant security mechanisms to mitigate those threats.
下表1显示了适用于ULE网络的威胁，以及缓解这些威胁的相关安全机制。
Security Mechanism
-----------------------------------------------
|Data |Data |Source |Data |Intru |Iden |
|Privacy |fresh |Authent|Integ |sion |tity |
| |ness |ication|rity |Dete |Prote |
| | | | |ction |ction |
Threat | | | | | | |
---------------|--------|-------|-------|-------|-------|------|
| Monitoring | X | - | - | - | - | X |
|---------------------------------------------------------------|
| Masquerading | X | - | X | X | - | X |
|---------------------------------------------------------------|
| Replay Attacks| - | X | X | X | X | - |
|---------------------------------------------------------------|
| DoS Attacks | - | X | X | X | X | - |
|---------------------------------------------------------------|
| Modification | - | - | X | X | X | - |
| of Messages | | | | | | |
---------------------------------------------------------------
Security Mechanism
-----------------------------------------------
|Data |Data |Source |Data |Intru |Iden |
|Privacy |fresh |Authent|Integ |sion |tity |
| |ness |ication|rity |Dete |Prote |
| | | | |ction |ction |
Threat | | | | | | |
---------------|--------|-------|-------|-------|-------|------|
| Monitoring | X | - | - | - | - | X |
|---------------------------------------------------------------|
| Masquerading | X | - | X | X | - | X |
|---------------------------------------------------------------|
| Replay Attacks| - | X | X | X | X | - |
|---------------------------------------------------------------|
| DoS Attacks | - | X | X | X | X | - |
|---------------------------------------------------------------|
| Modification | - | - | X | X | X | - |
| of Messages | | | | | | |
---------------------------------------------------------------
Table 1: Security techniques to mitigate network threats in ULE Networks
表1:ULE网络中缓解网络威胁的安全技术
Table 1 may assist in selecting fields within a ULE Security Extension Header framework.
表1可能有助于在ULE安全扩展头框架内选择字段。
Security services may be grouped into profiles based on security requirements, e.g., a base profile (with payload encryption and identity protection) and a second profile that extends this to also provide source authentication and protection against replay attacks. Although the use of specific security techniques is optional, it is RECOMMENDED that receiver devices should implement all the techniques in Reqs 2-5 of Section 4 to ensure interoperability of all profiles.
安全服务可根据安全要求分组为配置文件，例如，基本配置文件（具有有效负载加密和身份保护）和第二配置文件，该配置文件扩展了此配置文件，以提供源身份验证和防止重播攻击。尽管特定安全技术的使用是可选的，但建议接收器设备应实施第4节要求2-5中的所有技术，以确保所有配置文件的互操作性。
A modular design of ULE security may allow it to use and benefit from existing key management protocols, such as the Group Secure Association Key Management Protocol (GSAKMP) [RFC4535] and the Group Domain of Interpretation (GDOI) [RFC3547] defined by the IETF Multicast Security (MSEC) working group. This does not preclude the use of other key management methods in scenarios where this is more appropriate.
ULE安全性的模块化设计可允许其使用现有密钥管理协议并从中受益，如IETF多播安全（MSEC）工作组定义的组安全关联密钥管理协议（GSAKMP）[RFC4535]和组解释域（GDOI）[RFC3547]。这并不排除在更合适的情况下使用其他密钥管理方法。
IPsec [RFC4301] and TLS [RFC5246] also provide a proven security architecture defining key exchange mechanisms and the ability to use a range of cryptographic algorithms. ULE security can make use of these established mechanisms and algorithms. See Appendix A for more details.
IPsec[RFC4301]和TLS[RFC5246]还提供了经验证的安全体系结构，定义了密钥交换机制和使用一系列加密算法的能力。ULE安全性可以利用这些已建立的机制和算法。详见附录A。
RFC 5163 [RFC5163] describes three new Extension Headers that may be used with Unidirectional Link Encapsulation, ULE, [RFC4326] and the Generic Stream Encapsulation (GSE) that has been designed for the Generic Mode (also known as the Generic Stream (GS)), offered by second-generation DVB physical layers [GSE].
RFC 5163[RFC5163]描述了三个新的扩展头，它们可以与单向链路封装、ULE[RFC4326]和通用流封装（GSE）一起使用，通用流封装（GSE）是为第二代DVB物理层[GSE]提供的通用模式（也称为通用流（GS））而设计的。
The security threats and requirements presented in this document are applicable to ULE and GSE encapsulations.
本文件中提出的安全威胁和要求适用于ULE和GSE封装。
This document analyses a set of threats and security requirements. It defines the requirements for ULE security and states the motivation for link security as a part of the Encapsulation layer.
本文件分析了一系列威胁和安全要求。它定义了ULE安全性的要求，并说明了链接安全性作为封装层一部分的动机。
ULE security must provide link-layer encryption and ULE Receiver identity protection. The framework must support the optional ability to provide for link-layer authentication and integrity assurance, as well as protection against insertion of old (duplicated) data into the ULE Stream (i.e., replay protection). This set of features is optional to reduce encapsulation overhead when not required.
ULE安全必须提供链路层加密和ULE接收器身份保护。框架必须支持可选功能，以提供链路层身份验证和完整性保证，以及防止将旧（重复）数据插入ULE流的保护（即重放保护）。这组特性是可选的，可以在不需要时减少封装开销。
ULE Stream security between a ULE Encapsulation Gateway and the corresponding Receiver(s) is considered an additional security mechanism to IPsec, TLS, and application layer end-to-end security, and not as a replacement. It allows a network operator to provide similar functions to that of IPsec, but in addition provides MPEG-2 transmission link confidentiality and protection of ULE Receiver identity (NPA address).
ULE封装网关和相应接收器之间的ULE流安全性被视为IPsec、TLS和应用层端到端安全性的附加安全机制，而不是替代机制。它允许网络运营商提供与IPsec类似的功能，但还提供MPEG-2传输链路机密性和ULE接收器标识（NPA地址）保护。
Appendix A describes a set of building blocks that may be used to realise a framework that provides ULE security functions.
附录A描述了一组可用于实现提供ULE安全功能的框架的构建块。
Link-layer (L2) encryption of IP traffic is commonly used in broadcast/radio links to supplement end-to-end security (e.g., provided by TLS [RFC5246], SSH [RFC4251], IPsec [RFC4301]).
IP通信的链路层（L2）加密通常用于广播/无线电链路，以补充端到端安全性（例如，由TLS[RFC5246]、SSH[RFC4251]、IPsec[RFC4301]提供）。
A common objective is to provide the same level of privacy as wired links. It is recommended that an ISP or user provide end-to-end security services based on well-known mechanisms such as IPsec or TLS.
一个共同的目标是提供与有线链接相同级别的隐私。建议ISP或用户基于众所周知的机制（如IPsec或TLS）提供端到端安全服务。
This document provides a threat analysis and derives the security requirements to provide link encryption and optional link-layer integrity/authentication of the SNDU payload.
本文档提供了威胁分析，并推导了提供SNDU有效负载的链路加密和可选链路层完整性/认证的安全要求。
There are some security issues that were raised in RFC 4326 [RFC4326] that are not addressed in this document (i.e., are out of scope), e.g.:
RFC 4326[RFC4326]中提出的一些安全问题在本文件中没有解决（即超出范围），例如：
o The security issue with un-initialised stuffing bytes. In ULE, these bytes are set to 0xFF (normal practice in MPEG-2).
o 未初始化填充字节的安全问题。在ULE中，这些字节被设置为0xFF（MPEG-2中的正常做法）。
o Integrity issues related to the removal of the LAN FCS in a bridged networking environment. The removal of bridged frames exposes the traffic to potentially undetected corruption while being processed by the Encapsulator and/or Receiver.
o 与在桥接网络环境中移除LAN FCS相关的完整性问题。移除桥接帧会使通信量在被封装器和/或接收器处理时暴露于潜在的未检测到的损坏。
o There is a potential security issue when a Receiver receives a PDU with two Length fields. The Receiver would need to validate the actual length and the Length field and ensure that inconsistent values are not propagated by the network.
o 当接收器接收到具有两个长度字段的PDU时，存在潜在的安全问题。接收器需要验证实际长度和长度字段，并确保网络不会传播不一致的值。
The authors acknowledge the help and advice from Gorry Fairhurst (University of Aberdeen). The authors also acknowledge contributions from Laurence Duquerroy and Stephane Coombes (ESA), and Yim Fun Hu (University of Bradford).
作者感谢Gorry Fairhurst（阿伯丁大学）的帮助和建议。作者还感谢劳伦斯·杜克罗伊（Laurence Duquerroy）和斯蒂芬·库姆斯（Stephane Coombes）（欧空局）以及严文虎（布拉德福德大学）的贡献。
[ISO-MPEG2] "Information technology -- generic coding of moving pictures and associated audio information systems, Part I", ISO 13818-1, International Standards Organisation (ISO), 2000.
[ISO-MPEG2]“信息技术——运动图像和相关音频信息系统的通用编码，第一部分”，ISO 13818-1，国际标准化组织（ISO），2000年。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC4326] Fairhurst, G. and B. Collini-Nocker, "Unidirectional Lightweight Encapsulation (ULE) for Transmission of IP Datagrams over an MPEG-2 Transport Stream (TS)", RFC 4326, December 2005.
[RFC4326]Fairhurst，G.和B.Collini Nocker，“通过MPEG-2传输流（TS）传输IP数据报的单向轻量封装（ULE）”，RFC 4326，2005年12月。
[BELLOVIN] S. Bellovin, "Security Problems in the TCP/IP Protocol
Suite", Computer Communications Review 2:19, pp. 32-48,
April 1989. http://www.cs.columbia.edu/~smb/
[BELLOVIN] S. Bellovin, "Security Problems in the TCP/IP Protocol
Suite", Computer Communications Review 2:19, pp. 32-48,
April 1989. http://www.cs.columbia.edu/~smb/
[ETSI-DAT] EN 301 192, "Digital Video Broadcasting (DVB); DVB Specifications for Data Broadcasting", European Telecommunications Standards Institute (ETSI).
[ETSI-DAT]EN 301 192，“数字视频广播（DVB）；数据广播用DVB规范”，欧洲电信标准协会（ETSI）。
[GSE] TS 102 606, "Digital Video Broadcasting (DVB); Generic Stream Encapsulation (GSE) Protocol, "European Telecommunication Standards, Institute (ETSI), 2007.
[GSE]TS 102 606，“数字视频广播（DVB）；通用流封装（GSE）协议”，欧洲电信标准协会（ETSI），2007年。
[IEEE-802] "Local and metropolitan area networks-Specific requirements Part 2: Logical Link Control", IEEE 802.2, IEEE Computer Society, (also ISO/IEC 8802-2), 1998.
[IEEE-802]“局域网和城域网特定要求第2部分：逻辑链路控制”，IEEE 802.2，IEEE计算机协会（也称ISO/IEC 8802-2），1998年。
[ISO-8802] ISO/IEC 8802.2, "Logical Link Control", International Standards Organisation (ISO), 1998.
[ISO-8802]ISO/IEC 8802.2，“逻辑链路控制”，国际标准组织（ISO），1998年。
[ITU-H222] H.222.0, "Information technology, Generic coding of moving pictures and associated audio information Systems", International Telecommunication Union, (ITU-T), 1995.
[ITU-H222]H.222.0，“信息技术，运动图像和相关音频信息系统的通用编码”，国际电信联盟（ITU-T），1995年。
[RFC3135] Border, J., Kojo, M., Griner, J., Montenegro, G., and Z. Shelby, "Performance Enhancing Proxies Intended to Mitigate Link-Related Degradations", RFC 3135, June 2001.
[RFC3135]Border，J.，Kojo，M.，Griner，J.，黑山，G.，和Z.Shelby，“旨在缓解链路相关降级的性能增强代理”，RFC 31352001年6月。
[RFC3547] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The Group Domain of Interpretation", RFC 3547, July 2003.
[RFC3547]Baugher，M.，Weis，B.，Hardjono，T.，和H.Harney，“解释的集团领域”，RFC 3547，2003年7月。
[RFC3715] Aboba, B. and W. Dixon, "IPsec-Network Address Translation (NAT) Compatibility Requirements", RFC 3715, March 2004.
[RFC3715]Aboba，B.和W.Dixon，“IPsec网络地址转换（NAT）兼容性要求”，RFC 3715，2004年3月。
[RFC3819] Karn, P., Ed., Bormann, C., Fairhurst, G., Grossman, D., Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L. Wood, "Advice for Internet Subnetwork Designers", BCP 89, RFC 3819, July 2004.
[RFC3819]Karn，P.，Ed.，Bormann，C.，Fairhurst，G.，Grossman，D.，Ludwig，R.，Mahdavi，J.，黑山，G.，Touch，J.，和L.Wood，“互联网子网络设计师的建议”，BCP 89，RFC 3819，2004年7月。
[RFC4082] Perrig, A., Song, D., Canetti, R., Tygar, J., and B. Briscoe, "Timed Efficient Stream Loss-Tolerant Authentication (TESLA): Multicast Source Authentication Transform Introduction", RFC 4082, June 2005.
[RFC4082]Perrig，A.，Song，D.，Canetti，R.，Tygar，J.，和B.Briscoe，“定时高效流丢失容忍认证（TESLA）：多播源认证转换介绍”，RFC 40822005年6月。
[RFC4251] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Protocol Architecture", RFC 4251, January 2006.
[RFC4251]Ylonen，T.和C.Lonvick，编辑，“安全外壳（SSH）协议架构”，RFC 4251，2006年1月。
[RFC4259] Montpetit, M.-J., Fairhurst, G., Clausen, H., Collini-Nocker, B., and H. Linder, "A Framework for Transmission of IP Datagrams over MPEG-2 Networks", RFC 4259, November 2005.
[RFC4259]Montpetit，M.-J.，Fairhurst，G.，Clausen，H.，Collini Nocker，B.，和H.Linder，“通过MPEG-2网络传输IP数据报的框架”，RFC 4259，2005年11月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301]Kent，S.和K.Seo，“互联网协议的安全架构”，RFC 43012005年12月。
[RFC4535] Harney, H., Meth, U., Colegrove, A., and G. Gross, "GSAKMP: Group Secure Association Key Management Protocol", RFC 4535, June 2006.
[RFC4535]Harney，H.，Meth，U.，Colegrove，A.，和G.Gross，“GSAKMP：组安全关联密钥管理协议”，RFC 45352006年6月。
[RFC4947] Fairhurst, G. and M. Montpetit, "Address Resolution Mechanisms for IP Datagrams over MPEG-2 Networks", RFC 4947, July 2007.
[RFC4947]Fairhurst，G.和M.Montpetit，“MPEG-2网络上IP数据报的地址解析机制”，RFC 4947，2007年7月。
[RFC5163] Fairhurst, G. and B. Collini-Nocker, "Extension Formats for Unidirectional Lightweight Encapsulation (ULE) and the Generic Stream Encapsulation (GSE)", RFC 5163, April 2008.
[RFC5163]Fairhurst，G.和B.Collini-Nocker，“单向轻量封装（ULE）和通用流封装（GSE）的扩展格式”，RFC 51632008年4月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.2”，RFC 5246，2008年8月。
[RFC5374] Weis, B., Gross, G., and D. Ignjatic, "Multicast Extensions to the Security Architecture for the Internet Protocol", RFC 5374, November 2008.
[RFC5374]Weis，B.，Gross，G.和D.Ignjatic，“互联网协议安全架构的多播扩展”，RFC 5374，2008年11月。
This section describes a security framework for the deployment of secure ULE networks.
本节介绍用于部署安全网络的安全框架。
This ULE Security framework describes the following building blocks as shown in Figure 2 below:
此ULE安全框架描述了以下构建块，如下图2所示：
o The Key Management Block
o 密钥管理块
o The ULE Security Extension Header Block
o ULE安全扩展头块
o The ULE Databases Block
o 数据库块
Within the Key Management Block, the communication between the Group Member entity and the Group Server entity happens in the control plane. The ULE Security Header Block applies security to the ULE SNDU and this happens in the ULE data plane. The ULE Security Databases Block acts as the interface between the Key Management Block (control plane) and the ULE Security Header Block (ULE data plane) as shown in Figure 2. The Security Databases Block exists in both the group member and server sides. However, it has been omitted from Figure 2 just for clarity.
在密钥管理块中，组成员实体和组服务器实体之间的通信发生在控制平面中。ULE安全头块将安全性应用于ULE SNDU，这发生在ULE数据平面中。ULE安全数据库块充当密钥管理块（控制平面）和ULE安全头块（ULE数据平面）之间的接口，如图2所示。安全数据库块同时存在于组成员和服务器端。然而，为了清楚起见，图2中省略了它。
-----
+------+----------+ +----------------+ / \
| Key Management |/---------\| Key Management | |
| Group Member |\---------/| Group Server | |
| Block | | Block | Control
+------+----------+ +----------------+ Plane
| | |
| | |
| | \ /
----------- Key management <-> ULE Security databases -----
| |
\ /
+------+----------+
| ULE |
| SAD / SPD |
| Databases |
| Block |
+------+-+--------+
/ \
| |
----------- ULE Security databases <-> ULE Security Header ----
| | / \
| | |
| | |
+------+-+--------+ ULE Data
| ULE Security | Plane
| Extension Header| |
| Block | |
+-----------------+ \ /
-----
-----
+------+----------+ +----------------+ / \
| Key Management |/---------\| Key Management | |
| Group Member |\---------/| Group Server | |
| Block | | Block | Control
+------+----------+ +----------------+ Plane
| | |
| | |
| | \ /
----------- Key management <-> ULE Security databases -----
| |
\ /
+------+----------+
| ULE |
| SAD / SPD |
| Databases |
| Block |
+------+-+--------+
/ \
| |
----------- ULE Security databases <-> ULE Security Header ----
| | / \
| | |
| | |
+------+-+--------+ ULE Data
| ULE Security | Plane
| Extension Header| |
| Block | |
+-----------------+ \ /
-----
Figure 2: Secure ULE Framework Building Blocks
图2：安全ULE框架构建块
A key management framework is required to provide security at the ULE level using extension headers. This key management framework is responsible for user authentication, access control, and Security Association negotiation (which include the negotiations of the security algorithms to be used and the generation of the different session keys as well as policy material). The key management framework can be either automated or manual. Hence, this key management client entity (shown as the Key Management Group Member Block in Figure 2) will be present in all ULE Receivers as well as at the ULE Encapsulators. The ULE Encapsulator could also be the Key Management Group Server Entity (shown as the Key Management Group Server Block in Figure 2).
需要密钥管理框架来使用扩展头在ULE级别提供安全性。该密钥管理框架负责用户身份验证、访问控制和安全关联协商（包括将要使用的安全算法的协商以及不同会话密钥和策略材料的生成）。密钥管理框架可以是自动的，也可以是手动的。因此，该密钥管理客户端实体（如图2中的密钥管理组成员块所示）将出现在所有ULE接收器以及ULE封装器中。ULE封装器也可以是密钥管理组服务器实体（如图2中的密钥管理组服务器块所示）。
This happens when the ULE Encapsulator also acts as the Key Management Group Server. Deployment may use either automated key management protocols (e.g., GSAKMP [RFC4535]) or manual insertion of keying material.
当ULE封装器同时充当密钥管理组服务器时，会发生这种情况。部署可以使用自动密钥管理协议（如GSAKMP[RFC4535]）或手动插入密钥材料。
There needs to be two databases, i.e., similar to the IPsec databases.
需要有两个数据库，即类似于IPsec数据库。
o ULE-SAD: ULE Security Association Database contains all the Security Associations that are currently established with different ULE peers.
o ULE-SAD:ULE安全关联数据库包含当前与不同ULE对等方建立的所有安全关联。
o ULE-SPD: ULE Security Policy Database contains the policies as described by the system manager. These policies describe the security services that must be enforced.
o ULE-SPD:ULE安全策略数据库包含系统管理器描述的策略。这些策略描述了必须强制执行的安全服务。
While traditionally link-layer security has operated using simple policy mechanisms, it is envisaged that ULE security should provide flexibility comparable to IPsec. The above design is based on the two databases defined for IPsec [RFC4301]. These databases could be used to implement either simple policies (as in traditional link security services) or more complex policies (as in IPsec).
虽然传统的链路层安全性使用简单的策略机制进行操作，但可以设想，ULE安全性应提供与IPsec相当的灵活性。上述设计基于为IPsec[RFC4301]定义的两个数据库。这些数据库可用于实现简单策略（如在传统的链接安全服务中）或更复杂的策略（如在IPsec中）。
The exact details of the header patterns that the SPD and SAD will have to support for all use cases will be described in a separate document. This document only highlights the need for such interfaces between the ULE data plane and the Key Management control plane.
SPD和SAD必须支持的所有用例的头模式的确切细节将在单独的文档中描述。本文件仅强调ULE数据平面和密钥管理控制平面之间需要此类接口。
A new security extension header for the ULE protocol is required to provide the security features of data confidentiality, identity protection, data integrity, data authentication, and mechanisms to prevent replay attacks. Security keying material will be used for the different security algorithms (for encryption/decryption, MAC generation, etc.), which are used to meet the security requirements, described in detail in Section 4 of this document.
ULE协议需要一个新的安全扩展头，以提供数据机密性、身份保护、数据完整性、数据身份验证和防止重播攻击的机制等安全功能。安全密钥材料将用于不同的安全算法（用于加密/解密、MAC生成等），用于满足本文件第4节中详细描述的安全要求。
This block will use the keying material and policy information from the ULE Security Database Block on the ULE payload to generate the secure ULE Extension Header or to decipher the secure ULE extension header to get the ULE payload. An example overview of the ULE Security extension header format along with the ULE header and payload is shown in Figure 3 below.
该块将使用来自ULE有效载荷上的ULE安全数据库块的密钥材料和策略信息来生成安全ULE扩展头或解密安全ULE扩展头以获得ULE有效载荷。ULE安全扩展头格式以及ULE头和有效负载的示例概述如下图3所示。
+-------+------+-------------------------------+------+
| ULE |SEC | Protocol Data Unit | |
|Header |Header| |CRC-32|
+-------+------+-------------------------------+------+
+-------+------+-------------------------------+------+
| ULE |SEC | Protocol Data Unit | |
|Header |Header| |CRC-32|
+-------+------+-------------------------------+------+
Figure 3: ULE Security Extension Header Placement
图3:ULE安全扩展头位置
Two new interfaces have to be defined between the blocks as shown in Figure 2 above. These interfaces are:
必须在块之间定义两个新接口，如上图2所示。这些接口是：
o Key Management Block <-> ULE Security Databases Block
o 密钥管理块<->ULE安全数据库块
o ULE Security Databases Block <-> ULE Security Header Block
o ULE安全数据库块<->ULE安全头块
While the first interface is used by the Key Management Block to insert keys, security associations, and policies into the ULE Database Block, the second interface is used by the ULE Security Extension Header Block to get the keys and policy material for generation of the security extension header.
当密钥管理块使用第一个接口将密钥、安全关联和策略插入ULE数据库块时，ULE安全扩展头块使用第二个接口获取密钥和策略材料，以生成安全扩展头。
This interface is between the Key Management Block of a group member (GM client) and the ULE Security Database Block (shown in Figure 2). The Key Management GM entity will communicate with the GCKS and then get the relevant security information (keys, cipher mode, security service, ULE_Security_ID, and other relevant keying material as well as policy) and insert this data into the ULE Security Database Block. The Key Management could be either automated (e.g., GSAKMP [RFC4535] or GDOI [RFC3547]), or security information could be manually inserted using this interface.
此接口位于组成员（GM客户端）的密钥管理块和ULE安全数据库块（如图2所示）之间。密钥管理GM实体将与GCK通信，然后获取相关安全信息（密钥、密码模式、安全服务、ULE_安全ID和其他相关密钥材料以及策略），并将该数据插入ULE安全数据库块。密钥管理可以是自动化的（例如，GSAKMP[RFC4535]或GDOI[RFC3547]），也可以使用此接口手动插入安全信息。
Examples of interface functions are:
接口功能的示例包括：
o Insert_record_database (char * Database, char * record, char * Unique_ID);
o 插入_记录_数据库（char*数据库，char*记录，char*唯一的_ID）；
o Update_record_database (char * Database, char * record, char * Unique_ID);
o 更新_记录_数据库（char*数据库，char*记录，char*唯一_ID）；
o Delete_record_database (char * Database, char * Unique_ID);
o 删除_记录_数据库（char*数据库，char*唯一的_ID）；
The definitions of the variables are as follows:
变量的定义如下：
o Database - This is a pointer to the ULE Security databases
o 数据库-这是指向ULE安全数据库的指针
o record - This is the rows of security attributes to be entered or modified in the above databases
o 记录-这是要在上述数据库中输入或修改的安全属性行
o Unique_ID - This is the primary key to look up records (rows of security attributes) in the above databases
o Unique_ID-这是在上述数据库中查找记录（安全属性行）的主键
This interface is between the ULE Security Database and the ULE Security Extension Header Block as shown in Figure 2. When sending traffic, the ULE encapsulator uses the Destination Address, the PID, and possibly other information such as L3 source and destination addresses to locate the relevant security record within the ULE Security Database. It then uses the data in the record to create the ULE security extension header. For received traffic, the ULE decapsulator on receiving the ULE SNDU will use the Destination Address, the PID, and a ULE Security ID inserted by the ULE encapsulator into the security extension to retrieve the relevant record from the Security Database. It then uses this information to decrypt the ULE extension header. For both cases (either send or receive traffic) only one interface is needed since the main difference between the sender and receiver is the direction of the flow of traffic. An example of such an interface is as follows:
此接口位于ULE安全数据库和ULE安全扩展头块之间，如图2所示。发送通信量时，ULE封装器使用目标地址、PID以及可能的其他信息（如L3源地址和目标地址）来定位ULE安全数据库中的相关安全记录。然后，它使用记录中的数据创建ULE安全扩展标头。对于接收到的流量，ULE decapsulator在接收ULE SNDU时将使用目标地址、PID和ULE封装器插入安全扩展的ULE安全ID，以从安全数据库检索相关记录。然后，它使用此信息对ULE扩展头进行解密。对于这两种情况（发送或接收流量），只需要一个接口，因为发送方和接收方之间的主要区别是流量的方向。此类接口的示例如下所示：
o Get_record_database (char * Database, char * record, char * Unique_ID);
o 获取\记录\数据库（char*数据库，char*记录，char*唯一\ ID）；
Examination of the threat analysis and security requirements in Sections 3 and 4 has shown that there is a need to provide security in MPEG-2 transmission networks employing ULE. This section compares the placement of security functionalities in different layers.
对第3节和第4节中威胁分析和安全要求的检查表明，需要在采用ULE的MPEG-2传输网络中提供安全性。本节比较安全功能在不同层中的位置。
The security architecture for the Internet Protocol [RFC4301] describes security services for traffic at the IP layer. This architecture primarily defines services for the Internet Protocol (IP) unicast packets, as well as manually configured IP multicast packets.
互联网协议的安全架构[RFC4301]描述了IP层流量的安全服务。此体系结构主要为Internet协议（IP）单播数据包以及手动配置的IP多播数据包定义服务。
It is possible to use IPsec to secure ULE Streams. The major advantage of IPsec is its wide implementation in IP routers and hosts. IPsec in transport mode can be used for end-to-end security transparently over MPEG-2 transmission links with little impact.
可以使用IPsec来保护ULE流。IPsec的主要优点是它在IP路由器和主机中的广泛实现。传输模式下的IPsec可以在MPEG-2传输链路上透明地用于端到端安全，影响很小。
In the context of MPEG-2 transmission links, if IPsec is used to secure a ULE Stream, then the ULE Encapsulator and Receivers are equivalent to the security gateways in IPsec terminology. A security gateway implementation of IPsec uses tunnel mode. Such usage has the following disadvantages:
在MPEG-2传输链路的上下文中，如果使用IPsec保护ULE流，则ULE封装器和接收器相当于IPsec术语中的安全网关。IPsec的安全网关实现使用隧道模式。这种用法有以下缺点：
o There is an extra transmission overhead associated with using IPsec in tunnel mode, i.e., the extra IP header (IPv4 or IPv6).
o 在隧道模式下使用IPsec会带来额外的传输开销，即额外的IP报头（IPv4或IPv6）。
o There is a need to protect the identity (NPA address) of ULE Receivers over the ULE broadcast medium; IPsec is not suitable for providing this service. In addition, the interfaces of these devices do not necessarily have IP addresses (they can be L2 devices).
o 需要通过ULE广播媒体保护ULE接收机的身份（NPA地址）；IPsec不适合提供此服务。此外，这些设备的接口不一定有IP地址（它们可以是L2设备）。
o Multicast is considered a major service over ULE links. The current IPsec specifications [RFC4301] only define a pairwise tunnel between two IPsec devices with manual keying. Work is in progress in defining the extra detail needed for multicast and to use the tunnel mode with address preservation to allow efficient multicasting. For further details refer to [RFC5374].
o 多播被认为是ULE链路上的主要服务。当前的IPsec规范[RFC4301]仅定义了两个IPsec设备之间的成对隧道（使用手动键控）。定义多播所需的额外细节以及使用具有地址保留的隧道模式以实现高效多播的工作正在进行中。有关更多详细信息，请参阅[RFC5374]。
Link layer security can be provided at the MPEG-2 TS layer (below ULE). MPEG-2 TS encryption encrypts all TS Packets sent with a specific PID value. However, an MPEG-2 TS may typically multiplex several IP flows, belonging to different users, using a common PID. Therefore, all multiplexed traffic will share the same security keys.
链路层安全性可在MPEG-2 TS层提供（见下文）。MPEG-2 TS加密使用特定PID值对发送的所有TS数据包进行加密。然而，MPEG-2ts通常可以使用公共PID复用属于不同用户的多个IP流。因此，所有多路复用流量将共享相同的安全密钥。
This has the following advantages:
这有以下优点：
o The bit stream sent on the broadcast network does not expose any L2 or L3 headers, specifically all addresses, type fields, and length fields are encrypted prior to transmission.
o 在广播网络上发送的比特流不公开任何L2或L3报头，具体地说，所有地址、类型字段和长度字段在传输之前都是加密的。
o This method does not preclude the use of IPsec, TLS, or any other form of higher-layer security.
o 此方法不排除使用IPsec、TLS或任何其他形式的高层安全。
However it has the following disadvantages:
但是，它有以下缺点：
o When a PID is shared between several users, each ULE Receiver needs to decrypt all MPEG-2 TS Packets with a matching PID, possibly including those that are not required to be forwarded. Therefore, it does not have the flexibility to separately secure individual IP flows.
o 当一个PID在多个用户之间共享时，每个ULE接收器需要用匹配的PID解密所有MPEG-2 TS数据包，可能包括那些不需要转发的数据包。因此，它不具备单独保护单个IP流的灵活性。
o When a PID is shared between several users, the ULE Receivers will have access to private traffic destined to other ULE Receivers, since they share a common PID and key.
o 当一个PID在多个用户之间共享时，ULE接收器将有权访问发送给其他ULE接收器的专用通信量，因为它们共享一个公共PID和密钥。
o IETF-based key management that is very flexible and secure is not used in existing MPEG-2 based systems. Existing access control mechanisms in such systems have limited flexibility in terms of controlling the use of keying and rekeying. Therefore, if the key is compromised, this will impact several ULE Receivers.
o 基于IETF的密钥管理非常灵活和安全，在现有的基于MPEG-2的系统中没有使用。此类系统中的现有访问控制机制在控制键控和重新键控的使用方面具有有限的灵活性。因此，如果密钥被泄露，这将影响多个接收器。
Currently, there are few deployed L2 security systems for MPEG-2 transmission networks. Conditional access for digital TV broadcasting is one example. However, this approach is optimised for TV services and is not well-suited to IP packet transmission. Some other systems are specified in standards such as MPE [ETSI-DAT], but there are currently no known implementations and these methods are not applicable to GSE.
目前，为MPEG-2传输网络部署的L2安全系统很少。数字电视广播的条件接收就是一个例子。然而，这种方法针对电视服务进行了优化，不适合IP分组传输。MPE[ETSI-DAT]等标准中规定了一些其他系统，但目前还没有已知的实现，这些方法不适用于GSE。
Examining the threat analysis in Section 3 has shown that protection of ULE Stream from eavesdropping and ULE Receiver identity are major requirements.
检查第3节中的威胁分析表明，保护ULE流免受窃听和ULE接收器身份是主要要求。
There are several advantages in using ULE link-layer security:
使用ULE链路层安全性有几个优点：
o The protection of the complete ULE Protocol Data Unit (PDU) including IP addresses. The protection can be applied either per IP flow or per Receiver NPA address.
o 保护完整的ULE协议数据单元（PDU），包括IP地址。保护可以应用于每个IP流或每个接收器NPA地址。
o Ability to protect the identity of the Receiver within the MPEG-2 transmission network at the IP layer and also at L2.
o 能够在IP层和L2层保护MPEG-2传输网络中的接收器身份。
o Efficient protection of IP multicast over ULE links.
o 有效保护ULE链路上的IP多播。
o Transparency to the use of Network Address Translation (NATs) [RFC3715] and TCP Performance Enhancing Proxies (PEP) [RFC3135], which require the ability to inspect and modify the packets sent over the ULE link.
o 使用网络地址转换（NAT）[RFC3715]和TCP性能增强代理（PEP）[RFC3135]的透明度，这需要能够检查和修改通过ULE链路发送的数据包。
This method does not preclude the use of IPsec at L3 (or TLS [RFC5246] at L4). IPsec and TLS provide strong authentication of the endpoints in the communication.
此方法不排除在L3使用IPsec（或在L4使用TLS[RFC5246]）。IPsec和TLS为通信中的端点提供了强大的身份验证。
L3 end-to-end security would partially deny the advantage listed above (use of PEP, compression, etc.), since those techniques could only be applied to TCP packets bearing a TCP-encapsulated IPsec packet exchange, but not the TCP packets of the original applications, which in particular inhibits compression.
L3端到端安全性将部分否认上述优势（使用PEP、压缩等），因为这些技术只能应用于承载TCP封装的IPsec数据包交换的TCP数据包，而不能应用于原始应用程序的TCP数据包，这尤其会抑制压缩。
End-to-end security (IPsec, TLS, etc.) may be used independently to provide strong authentication of the endpoints in the communication. This authentication is desirable in many scenarios to ensure that the correct information is being exchanged between the trusted parties, whereas Layer 2 methods cannot provide this guarantee.
端到端安全性（IPsec、TLS等）可单独用于提供通信中端点的强身份验证。这种身份验证在许多情况下都是可取的，以确保在受信任方之间交换正确的信息，而第2层方法无法提供这种保证。
Authors' Addresses
作者地址
Haitham Cruickshank Centre for Communications System Research (CCSR) University of Surrey Guildford, Surrey, GU2 7XH UK EMail: h.cruickshank@surrey.ac.uk
HithAM CracksHANK通信系统研究中心（CCSR）塞瑞大学吉尔福德，萨里，GU7XXH英国电子邮件：H。cruickshank@surrey.ac.uk
Prashant Pillai Mobile and Satellite Communications Research Centre (MSCRC) School of Engineering, Design and Technology University of Bradford Richmond Road, Bradford BD7 1DP UK EMail: p.pillai@bradford.ac.uk
Prashant Pillai移动和卫星通信研究中心（MSCRC）工程学院，设计和技术布拉德福德大学，里士满路，布拉德福德BD7 1DP英国电子邮件：P.pillai@bradford.ac.uk
Michael Noisternig Multimedia Comm. Group, Dpt. of Computer Sciences University of Salzburg Jakob-Haringer-Str. 2 5020 Salzburg Austria EMail: mnoist@cosy.sbg.ac.at
Michael Noiseternig多媒体通信集团，Dpt。萨尔茨堡计算机科学大学JAKOB-HARANGER STR 2第5020萨尔茨堡奥地利电子邮件：mnoist@cosy.sbg.ac.at
Sunil Iyengar Space & Defence Logica Springfield Drive Leatherhead Surrey KT22 7LP UK EMail: sunil.iyengar@logica.com
Sunil Iyengar航天与国防逻辑公司斯普林菲尔德路萨里郡Leatherhead KT22 7LP英国电子邮件：Sunil。iyengar@logica.com