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
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と、この文書（http://trustee.ietf.org/license-info）の発行日に有効なIETFドキュメントに関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。
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規格は、さまざまなサービスのための送信方法の範囲をサポートします。この文書では、文書はまたのためのリンク層セキュリティのための動機を提供RFC 4326で定義されている（ULE）脅威の分析を提供し、単方向ライト級カプセル化を使用してインターネットのネットワーク層をサポートするために、トランスポートストリーム、TSを使用する場合のセキュリティ要件を導出します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
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）が広く、デジタルTVサービスを提供するための、だけでなく、IPネットワークを構築するためのサブネットワーク技術としてだけではなく、受け入れられてきました。 RFC 4326 [RFC4326]は直接TSプライベートデータとしてISO MPEG-2トランスポートストリーム上のIPv4とIPv6データグラムと他のネットワーク・プロトコル・パケットを輸送するための一方向軽量カプセル化（ULE）メカニズムを説明しています。 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.放送TVおよびラジオ配信。これは、この文書の範囲内ではありません。
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.
D.データキャストオーバーレイ。これは、既存のIPベースのインターネットサービスを補完するために、このような単方向マルチキャストなどの追加の接続性を提供するために、MPEG-2の物理層およびリンク層を採用しています。
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].
そのようなネットワークは、無線リンクの使用に関連する通常のセキュリティ上の問題を有線ネットワークを使用していない場合、MPEG-2伝送ネットワークにおけるセキュリティ要件の初期分析は、例えば、RFC 4259.の「セキュリティの考慮事項」の項に提示されていますインターネットトラフィックの輸送のための[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.
異なるビルディングブロックとインタフェース定義を説明セキュアULEネットワークの展開のためのセキュリティフレームワークは、付録Aに示されています
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].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" は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.
ATSC：高度テレビジョンシステム委員会。フレームワークおよび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：デジタルビデオ放送。フレームワークとISO MPEG2規格[ISO-MPEG2]を使用して、関連するビデオ、オーディオを伝送するため、欧州電気通信標準化機構（ETSI）によって公開されている標準、およびデータのセット。
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）を受信し、TSパケットのストリームとして出力するためのペイロードユニット（SNDUsとしてここでは知られている）にこれらをフォーマットするネットワーク装置。
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.
LLC：論理リンク制御[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]。デジタルストレージメディアコマンドおよびコントロール（DSM-CC）テーブルのセクションを形成し、PDUをカプセル化する仕組み。各セクションは、単一の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]).
MPEG2：国際標準化機構（ISO / IEC 13818-1）[ISO-MPEG2]でモーション・ピクチャー・エキスパート・グループ（MPEG）で指定し、標準化標準のセット、およびITU H.222でのITU-T（[ -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伝送ネットワーク内（IEEE媒体アクセス制御アドレスに似ている）、6バイトの宛先アドレスを参照。
PDU: Protocol Data Unit. Examples of a PDU include Ethernet frames, IPv4 or IPv6 Datagrams, and other network packets.
PDU：プロトコルデータユニット。 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パケットは[ISO-MPEG2]属するTS論理チャネルを識別するために使用されます。表セクションの部分を形成するTSパケットは、パケット化エレメンタリ・ストリーム（PES）、または他のペイロード・ユニットはすべて同じPID値を運ばなければなりません。すべてゼロのPIDが0x0000の、ならびに他のPID値は、特定のPSI / SIテーブル[ISO-MPEG2]のために予約されています。すべてのものPID値0x1FFFのはNULL 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表のすべてのセクションでは、論理チャネル[ISO-MPEG2]単一TS上で実行されなければなりません。
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）の設定、および送信周波数で送信）、または別のプロトコル層（例えば、イーサネット（登録商標）、又はIPオーバーRTP）によって提供されるカプセルであってもよいです。同じTS論理チャネルは、（おそらく異なるPID値に関連付けられた）複数のTS多重[RFC4259]の上に繰り返されてもよいです。例えば2つの地上波TV送信セルに同一のマルチキャストコンテンツを再配布します。
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多重[ISO-MPEG2]を介して送信されるデータの固定長188バイト単位。各TSパケットは、TS関連する論理チャネルのセットを同期させるために4バイトのヘッダに加え、アダプテーションフィールドを含む任意のオーバーヘッド、暗号化の詳細、およびタイムスタンプ情報を運びます。
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ストリーム：MPEG-2 TSのみULEは、PDUをカプセル化運ぶ論理チャネル。 ULEストリームはSI / PSI [ISO-MPEG2]中のstream_typeの定義によって同定することができます。
+------------+ +------------+
| 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：（[RFC4259]から適合）MPEG-2オーバーIPトランスポートの一方向サービスの構成例
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:
（[RFC4259]のセクション3.3）上記の図1に示すように、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 Modulators
モジュレーターO（再マルチプレクサを含む）O TSマルチプレクサ
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パケットは、通常、いくつかの連続したが、無関係な、TSパケットのバイトをインタリーブ順方向誤り訂正（FEC）コーディングを含む物理層の上にReceiverに搬送されます。 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の伝送ネットワークにおける受信機は、L2源[RFC4259]によって送信されたPDUのフラグメントを再構成するTS論理チャネル（またはMPEG-2エレメンタリストリーム）を識別する必要があります。 MPEG2 TSにおいて、この関連付けは、パケット識別子PID [ISO-MPEG2]を介して行われます。送信側では、各ソースは、それが発信する各ストリームをPID値のローカルで一意のセットを関連付けます。しかし、そこに送信者に使用されるPID値との間に必要な関係はなく、それは、受信機で受信されました。ネットワークデバイスは、入力間のマルチプレクサで衝突を防止するために、1つ以上のTS論理チャネル（例えば、ULEストリーム）に関連付けられた再番号PID値は、PMT内のエントリを更新する（異なる入力多重に担持同じPIDでストリームすることができます[ISO- MPEG2]、及びPID値を参照する他のSIテーブル）。デバイスは、また、変更および/または（また、それらのPID値によって識別されるTSパケットとして送信される）制御プレーンに新しいSIデータを挿入することができます。ただし、PID値に結合し、各MPEG-2エレメンタリーストリームのためのデータの唯一の有効なソースがあります。 （この観察は、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伝送ネットワークでは、これらのメッセージは（NO暗号化または完全性チェック）クリアで放送されています。これらのメッセージの整合性だけでなく、信憑性が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 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.
ULEストリームセキュリティはULEカプセル化ゲートウェイ（ULEカプセル化機能）と受信機の間の安全保障に関するものです。多くの展開シナリオではULEストリームのユーザーは、他のネットワークリンクがULEリンクに加えて、利用されているので、リンクを超えて通信を保護する必要があります。したがって、すなわちエンドポイントの認証は、IPソースは、要求された場合、またはユーザーが機密性、完全性、またはその通信データの真正性の喪失を懸念している、彼らは、エンドツーエンドのネットワーク・セキュリティ・メカニズム、例えばを採用する必要があります、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リンクは、2つの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 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リプレイ攻撃：侵入者がReceiverにいくつかの古い（本物の）メッセージを送信するとき。ブロードキャストリンクの場合は、前回の放送データへのアクセスが容易です。
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.
サービス拒否（DoS）攻撃O：エンティティは、その適切な機能を実行するから、他のエンティティを防ぐように、その適切な機能または行為を実行するために失敗した場合。
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氏]のための主要なセキュリティ上の懸念です。このような攻撃は実際にはMPEG-2の放送リンクのための非常に困難です一方マスカレードとIPパケットの変更は、インターネット環境では比較的簡単です。これは、例えば、ではなく、同期リンクのために、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伝送ネットワークのトポロジー的なシナリオを分析し、セキュリティ上の脅威は3例に抽象化することができます。
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：モニタリング（受動的脅威）。ここで、侵入者は、（宛先NPAアドレスを監視することにより）ULEデータ及び/又は通信相手を追跡アイデンティティについての情報を得るために、ULEブロードキャストを監視します。このシナリオでは、対策が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.
ケース2 O：ローカルMPEG-TSの多重化に積極的な攻撃を行います。ここでは、侵入者は、ULEカプセル化ゲートウェイから元の送信を無効にし、（一社のサイトで、例えば）単一ULEあるいは受信の小グループにMPEG-TS伝送の修正版をお届けするために十分に洗練されたと仮定されます。 MPEG-2伝送ネットワークオペレータは、このような攻撃を認識していない可能性があります。対策は、ULEデータの整合性と信頼性を確保するために取られ、古いメッセージのリプレイを防止する必要があります。
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伝送多重を上書きすることができ、洗練された侵入者を想定しています。要件は、MPEG-2伝送ネットワークオペレータは、通常、そのような攻撃を識別し、元の送信を復元するために是正措置を提供することができる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.
入出力アウトサイダー攻撃、秘密の材料の知識がなく敵から、すなわち、アクティブな攻撃。
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.
L2 NPAアドレスの必須2.保護はオプションです。ブロードキャストネットワークでは、この保護は、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.
ULEストリームデータの必須3.完全性保護およびソース認証はオプションです。これらは、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. L2 ULEソースとレシーバの認証は任意です。 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：データの機密性（必須1）は、（例えばユーザ情報やIPアドレスなど）ULEデータの監視を防止するために設けられなければなりません。 NPAアドレス（必須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の要件に加えて、新たな対策は、完全性保護およびソースを提供するためにそのような認証メッセージ認証コードを使用してスキーム、デジタル署名、または時限効率ストリーム損失トレラント認証（テスラ）[RFC4082]として実装することができます認証（要求数3及び5）。また、シーケンス番号（必須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 | | | | | | |
---------------------------------------------------------------
Table 1: Security techniques to mitigate network threats
in ULE Networks
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.
セキュリティサービスは、セキュリティ要件に基づいてプロファイルにグループ化することができる、例えば、また、リプレイ攻撃元の認証と保護を提供するために、これを延びる第2のプロファイル（ペイロード暗号化とアイデンティティ保護）基本プロファイル。特定のセキュリティ技術の使用はオプションですが、受信装置は、すべてのプロファイルの相互運用性を確保するために、第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セキュリティのモジュラー設計は、それが使用できるようにすると、このようなグループセキュア協会の鍵管理プロトコル（GSAKMP）[RFC4535]とIETFによって定義された通訳（GDOI）のグループドメイン[RFC3547]のような既存の鍵管理プロトコルから利益を得ることができますマルチキャストセキュリティ（MSEC）ワーキンググループ。これは、これがより適切であるシナリオでは、他のキー管理方式の使用を排除するものではありません。
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]もジェネリックストリーム（GS）として知られている（一般的なモードのために設計された単方向リンクカプセル化、ULE、[RFC4326]と汎用ストリームカプセル化（GSE）と共に使用することができるつの新しい拡張ヘッダを記述し）、[GSE]第二世代のDVB物理層によって提供されます。
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.
ブリッジネットワーク環境でのLAN FCSの除去に関連したO整合性の問題。ブリッジフレームの除去は、エンカプスレータおよび/または受信機によって処理されている間潜在未検出腐敗へのトラフィックを公開します。
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レシーバは、2つの長さフィールドで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（アバディーン大学）からの助けやアドバイスを認めます。著者らはまた、ローレンスDuquerroyとステファン・クームズ（ESA）、そしてイム楽しい胡（ブラッドフォード大学）からの貢献を認めます。
[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] "情報技術 - 動画及び関連するオーディオ情報システムの一般的なコーディング、パートI"、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]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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]、RFC 4326 "MPEG-2トランスポートストリーム（TS）上のIPデータグラムの送信の一方向軽量カプセル化（ULE）" Fairhurst、G.およびB. Collini-Nocker、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氏、 "TCP / IPプロトコルスイートのセキュリティ問題"、コンピュータコミュニケーションレビュー2：19、PP。32-48、1989年4月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]ボーダー、J.、古城、M.、Griner、J.、モンテネグロ、G.、およびZ.シェルビー、 "プロキシのパフォーマンスの向上は、リンク関連の劣化を軽減することを目的"、RFC 3135、2001年6月。
[RFC3547] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The Group Domain of Interpretation", RFC 3547, July 2003.
[RFC3547] Baugher、M.、ヴァイス、B.、Hardjono、T.、およびH.ハーニー、 "解釈のグループドメイン"、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.ディクソン、 "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]カーン、P.編、ボルマン、C.、Fairhurst、G.、グロスマン、D.、ルートヴィヒ、R.、Mahdavi、J.、モンテネグロ、G.、タッチ、J.、およびL.ウッド、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.、歌、D.、カネッティ、R.、Tygar、J.、およびB.ブリスコウ、 "時限効率ストリーム損失トレラント認証（テスラ）：マルチキャスト発信元認証は、はじめの変換"、RFC 4082、 2005年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.リンダー、 "MPEG-2ネットワークの上のIPデータグラムの送信のためのフレームワーク"、RFC 4259 、2005年11月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301]ケント、S.とK. Seo、 "インターネットプロトコルのためのセキュリティアーキテクチャ"、RFC 4301、2005年12月。
[RFC4535] Harney, H., Meth, U., Colegrove, A., and G. Gross, "GSAKMP: Group Secure Association Key Management Protocol", RFC 4535, June 2006.
[RFC4535]はハーニー、H.、メタ、U.、Colegrove、A.、およびG.グロスは、：RFC 4535、2006年6月、 "GSAKMPグループは、協会の鍵管理プロトコルをセキュア"。
[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、RFC 4947、2007年7月 "MPEG-2ネットワーク上でIPデータグラムのための解決メカニズムアドレス"。
[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 5163、2008年4月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246]ダークス、T.およびE.レスコラ、 "トランスポート層セキュリティ（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]ヴァイス、B.、グロス、G.、およびD. Ignjatic、 "インターネットプロトコルのためのセキュリティー体系へのマルチキャスト拡張機能"、RFC 5374、2008年11月。
Appendix A. ULE Security Framework
付録A. ULEセキュリティフレームワーク
This section describes a security framework for the deployment of secure ULE networks.
このセクションでは、セキュアULEネットワークの展開のためのセキュリティフレームワークについて説明します。
A.1. Building Blocks
A.1。ビルディングブロック
This ULE Security framework describes the following building blocks as shown in Figure 2 below:
下の図2に示すように、このULEセキュリティフレームワークは、以下のビルディングブロックを説明します。
o The Key Management Block
キー管理ブロックO
o The ULE Security Extension Header Block
ULEセキュリティ拡張ヘッダブロックO
o The ULE Databases Block
ULEデータベースのブロック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データプレーンで起こります。セキュリティデータベースのブロックがグループのメンバとサーバ側の両方に存在し、図2に示すように、ULEセキュリティデータベースブロックは、鍵管理ブロック（制御プレーン）とULEセキュリティヘッダブロック（ULEデータプレーン）との間のインタフェースとして機能します。しかし、それだけで明確にするため、図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 | |
+-----------------+ \ /
-----
Figure 2: Secure ULE Framework Building Blocks
図2：セキュアULE Frameworkのビルディングブロック
A.1.1. Key Management Block
A.1.1。キー管理ブロック
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]）または鍵材料の手動挿入のいずれかを使用することができます。
A.1.2. ULE Security Databases Block
A.1.2。 ULEセキュリティデータベースのブロック
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.
ULE-SAD O：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]のために定義された2つのデータベースに基づいています。これらのデータベースは、（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.1.3. ULE Extension Header Block
A.1.3。 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プロトコルのための新しいセキュリティ拡張ヘッダは、データの機密性、アイデンティティの保護、データの整合性、データ認証、およびリプレイ攻撃を防ぐためのメカニズムのセキュリティ機能を提供するために必要とされます。鍵材料のセキュリティは、このドキュメントのセクション4で詳細に記述されたセキュリティ要件を満たすために使用される（暗号化/復号、MAC生成、等）異なるセキュリティアルゴリズムに使用されます。
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|
+-------+------+-------------------------------+------+
Figure 3: ULE Security Extension Header Placement
図3：ULEセキュリティ拡張ヘッダの配置
A.2. Interface Definition
A.2。インタフェース定義
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のデータベース・ブロックの中にキー、セキュリティアソシエーション、およびポリシーを挿入するために、キー管理ブロックで使用されているが、第2のインタフェースは、セキュリティの世代のためのキーとポリシー材料を得るために、ULEセキュリティ拡張ヘッダブロックで使用されています拡張ヘッダ。
A.2.1. Key Management <-> ULE Security Databases
A.2.1。キー管理< - > 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クライアント）と（図2に示されている）ULEセキュリティデータベース・ブロックの間にあります。キー管理GMエンティティはGCKSと通信して、関連するセキュリティ情報（キー、暗号モード、セキュリティサービス、ULE_Security_ID、およびその他の関連する鍵素材だけでなく、ポリシー）を取得し、ULEセキュリティデータベースのブロックにこのデータを挿入します。鍵管理（例えば、GSAKMP [RFC4535]またはGDOI [RFC3547]）自動化され得るか、セキュリティ情報は、手動で、このインタフェースを使用して挿入することができます。
Examples of interface functions are:
インターフェイス機能の例は以下のとおりです。
o Insert_record_database (char * Database, char * record, char * Unique_ID);
O Insert_record_database（CHAR *データベース、CHAR *レコードのchar * UNIQUE_ID）。
o Update_record_database (char * Database, char * record, char * Unique_ID);
O Update_record_database（CHAR *データベース、CHAR *レコードのchar * UNIQUE_ID）。
o Delete_record_database (char * Database, char * Unique_ID);
O Delete_record_database（CHAR *データベース、CHAR * UNIQUE_ID）。
The definitions of the variables are as follows:
次のように変数の定義は以下のとおりです。
o Database - This is a pointer to the ULE Security databases o record - This is the rows of security attributes to be entered or modified in the above databases
Oデータベース - これは、レコードO ULE Securityデータベースへのポインタである - これは、上記のデータベースに入力されたか、変更するセキュリティの行を属性れます
o Unique_ID - This is the primary key to look up records (rows of security attributes) in the above databases
UNIQUE_ID O - これは、上記のデータベース内のレコード（セキュリティ属性の行）を検索する主キーです
A.2.2. ULE Security Databases <-> ULE Security Header
A.2.2。 ULEセキュリティデータベース< - > ULEセキュリティヘッダー
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:
図2に示すように、このインターフェースは、トラフィックを送信する場合、ULEカプセル化は、見つけるためにL3の送信元および宛先アドレスとして送信先アドレス、PID、および場合によっては他の情報を使用してULEセキュリティデータベースとULEセキュリティ拡張ヘッダブロックとの間でありますULEセキュリティデータベース内の関連するセキュリティレコード。その後、ULEセキュリティ拡張ヘッダを作成するには、レコード内のデータを使用しています。受信トラフィックの場合、セキュリティデータベースから該当するレコードを取得するために、セキュリティ拡張機能にULEカプセル化によって挿入された宛先アドレス、PID、およびULEセキュリティIDを使用しますULE SNDUを受けた上ULEのカプセル化を解きます。次に、ULE拡張ヘッダを復号化するためにこの情報を使用します。送信側と受信側との間の主な違いは、交通の流れの方向であるため、ケース（トラフィックを送信または受信のいずれか）の両方のために1つのインタフェースだけが必要です。次のようにそのようなインタフェースの例です。
o Get_record_database (char * Database, char * record, char * Unique_ID);
O Get_record_database（CHAR *データベース、CHAR *レコードのchar * UNIQUE_ID）。
Appendix B. Motivation for ULE Link-Layer Security
ULEリンク・レイヤ・セキュリティのための付録B.モチベーション
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伝送ネットワーク内のセキュリティを提供する必要があることを示しています。このセクションでは、異なる層におけるセキュリティ機能の配置を比較します。
B.1. Security at the IP Layer (Using IPsec)
B.1。 IPレイヤでのセキュリティ（IPsecを使用）
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層でのトラフィックのためのセキュリティ・サービスについて説明します。このアーキテクチャは、主にインターネットプロトコル（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.
ULEストリームを保護するためにIPsecを使用することが可能です。 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:
IPsecがULEストリームを保護するために使用される場合、MPEG-2伝送リンクの文脈では、次いで、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は、このサービスを提供するのに適していません。また、これらのデバイスのインタフェースは、必ずしも（彼らはL2デバイスすることができます）IPアドレスを持っていません。
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]は唯一の手動キーを持つ2つのIPsecデバイス間のペアワイズトンネルを定義します。仕事は、マルチキャストのために必要な追加の詳細を定義し、効率的なマルチキャストを可能にするアドレス保存してトンネルモードを使用するように進行中です。詳細については、[RFC5374]を参照。
B.2. Link Security below the Encapsulation Layer
B.2。封入層下のリンクセキュリティ
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.
リンク・レイヤ・セキュリティは、（ULE以下）MPEG-2 TS層で提供することができます。 MPEG-2 TSの暗号化は、すべてが特定のPID値で送信されたTSパケット暗号化します。しかしながら、MPEG-2 TSは、典型的には、多重いくつかのIPフローは、一般的なPIDを使用して、異なるユーザに属することができます。したがって、すべての多重化トラフィックは同じセキュリティキーを共有します。
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.
PIDは、複数のユーザ間で共有される場合、O、各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.
PIDは、複数のユーザー間で共有されている場合は、O、ULEレシーバは、彼らが共通PIDと鍵を共有しているため、他のULEレシーバ宛のプライベートトラフィックにアクセスできるようになります。
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ベースのシステムでは使用されません。そのようなシステム内の既存のアクセス制御メカニズムは、キー及びキー更新の使用を制御するという点で柔軟性が限られています。キーが侵害された場合そのため、これにはいくつかのULEレシーバに影響を与えます。
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セキュリティシステムがあります。デジタルテレビ放送のための条件付きアクセスは一例です。しかし、このアプローチは、TVサービス向けに最適化され、IPパケット伝送によく適していません。いくつかの他のシステムは、MPE [ETSI-DAT]などの規格に規定されているが、既知の実装が現在存在しないと、これらの方法は、GSEには適用できません。
B.3. Link Security as a Part of the Encapsulation Layer
B.3。カプセル化層の一部としてリンクセキュリティ
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.
IPアドレスを含む完全なULEプロトコルデータユニット（PDU）の保護O。保護は、IPフローごとまたはReceiver NPAアドレスごとのいずれかを適用することができます。
o Ability to protect the identity of the Receiver within the MPEG-2 transmission network at the IP layer and also at L2.
IP層で、またL2にMPEG-2伝送ネットワーク内の受信機のアイデンティティを保護する能力をO。
o Efficient protection of IP multicast over ULE links.
ULEリンク上でIPマルチキャストのO効率的な保護。
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.
ULEリンク上で送信されたパケットを検査し、変更する機能を必要とするネットワークアドレス変換器（NAT）[RFC3715]とTCP性能向上プロキシ（PEP）[RFC3135]、使用する透明O。
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（又はTLS L4に[RFC5246]）でのIPsecの使用を排除するものではありません。 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エンドツーエンドのセキュリティは、部分的にこれらの技術のみTCPカプセル化IPsecパケット交換を担持TCPパケットに適用することができるので、（PEP、圧縮、等の使用）上記の利点を否定するが、なるのではない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
h.cruickshank@surrey.ac.uk：サリー州ギルフォード、サリーの通信システム研究（CCSR）大学、GU2 7XH英国の電子メールのHaithamクルックシャンクセンター
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
プラシャント・ピライモバイルとエンジニアリングの衛星通信研究センター（MSCRC）学校、ブラッドフォードリッチモンド道路の設計と技術大学、ブラッドフォードBD7 1DPイギリスのEメール：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
マイケルNoisternigマルチメディアコム。グループ、のDpt。ザルツブルクヤコブHaringer-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
スニル・アイアンガースペース・防衛ロジカスプリングドライブレザーサリーKT22 7LP英国のEメール：sunil.iyengar@logica.com