[要約] RFC 5458は、Unidirectional Lightweight Encapsulation (ULE) プロトコルのセキュリティ要件に関するものであり、ULEプロトコルのセキュリティ強化を目的としています。
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.
Copyright（c）2009 IETF Trustおよび文書著者として特定された人。全著作権所有。
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 Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
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の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
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 Transport Stream（TS）は、デジタルTVサービスを提供するだけでなく、IPネットワークを構築するためのサブネットワークテクノロジーとしても広く受け入れられています。RFC 4326 [RFC4326]は、IPv4およびIPv6データグラムおよびその他のネットワークプロトコルパケットのISO MPEG-2輸送ストリームをTSプライベートデータとして直接直接輸送するための単方向の軽量カプセル化（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.放送テレビとラジオ配信。これは、このドキュメントの範囲内ではありません。
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.データキャストオーバーレイ。これにより、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はエラーやセキュリティの脅威に堅牢でなければならないと述べています。また、セキュリティは、上記のシナリオの双方向（eおよびf）リンクと同様に、単方向（a、b、c、およびd）の両方を考慮する必要があります。
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 MPEG-2標準[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.
Encapsurator：プロトコルデータユニット（PDU）を受信し、これらを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.
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]。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：Motion Picture Experts Group（MPEG）によって指定され、International Standards Organization（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：プロトコルデータユニット。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]。テーブルセクションの部分を形成するTSパケット、パケット化された初等ストリーム（PES）、またはその他のペイロードユニットはすべて同じPID値を搭載する必要があります。All-Zeros PID 0x0000およびその他のPID値は、特定のPSI/SIテーブル[ISO-MPEG2]に予約されています。すべてのPID値0x1FFFは、TSマルチプレックスの一定のビットレートを維持するために導入されたNULL 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マルチプレックスで運ばれるサービスに関する情報を伝えるために別の標準団体によって定義されているテーブルについて説明しています。テーブルは、1つ以上のテーブルセクションで構成されている場合があります。ただし、特定の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 Multiplex：このドキュメントでは、この用語では、単一の低層接続で送信されたMPEG-2 TS論理チャネルのセットを定義します。これは、一般的な物理リンク（つまり、指定されたシンボルレート、フォワードエラー補正（FEC）設定、および伝送周波数での伝送）または別のプロトコル層（例：イーサネット、またはIPを介したRTP）によって提供されるカプセル化などです。同じTS論理チャネルは、複数のTSマルチプレックス（おそらく異なるPID値に関連付けられている可能性がある）で繰り返される場合があります[RFC4259]。たとえば、同じマルチキャストコンテンツを2つの陸生テレビ伝送セルに再配布します。
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 Multiplex [ISO-MPEG2]を介して送信されたデータの固定長188バイト単位。各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]の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：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 capsator）
o SI-Table signalling generator (input to the multiplexer)
o Si-Tableシグナリングジェネレーター（マルチプレクサへの入力）
o Receivers (the endpoints for ULE Streams)
o 受信機（uleストリームのエンドポイント）
o TS multiplexers (including re-multiplexers) o Modulators
o TSマルチプレクサ（remultiplexerを含む）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パケットの注入が非常に困難になります。一連のパケットの置換も困難ですが、可能です（セクション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基本ストリーム）を特定する必要があります。MPEG-2 TSでは、この関連付けはパケット識別子であるPID [ISO-MPEG2]を介して行われます。送信者では、各ソースは、局所的に一意のPID値のセットを、それが発生する各ストリームに関連付けます。ただし、送信者で使用されるPID値と受信者で受け取ったPID値との間に必要な関係はありません。ネットワークデバイスは、1つ以上のTS論理チャネル（ULEストリームなど）に関連付けられているPID値を再番号付けして、異なる入力マルチプレックスで運ばれる同じPIDの入力ストリーム間のマルチプレクサでの衝突を防ぐことができます（PMTのエントリを更新します[iso-MPEG2]、およびPID値を参照する他のSIテーブル）。デバイスは、新しいSIデータを制御プレーンに変更および/または挿入することもできます（PID値によって識別されたTSパケットとしても送信されます）。ただし、PID値にバインドされた各MPEG-2基本ストリームに有効なデータソースは1つだけです。（この観察結果は、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ネットワークでは、L2コントロールプレーンを形成するには、一連のシグナリングメッセージ[RFC4947]をブロードキャストする必要がある場合があります（例：カプセル化ゲートウェイまたは他のデバイスによって）。シグナリングメッセージの例には、プログラムアソシエーションテーブル（PAT）、プログラムマップテーブル（PMT）、およびネットワーク情報表（NIT）が含まれます。既存のMPEG-2トランスミッションネットワークでは、これらのメッセージはクリアでブロードキャストされます（暗号化または整合性チェックなし）。これらのメッセージの整合性と信頼性は、ULEネットワークの正しい動作、つまり機密性と整合性に加えて、可用性の分野でのセキュリティ目標をサポートするために重要です。最近提案された1つの方法[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 Cancapsator）と受信機の間のセキュリティのみに関係しています。多くの展開シナリオでは、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エンドポイントが中央制御下にない通信にも使用できます（たとえば、パブリックWebサイトを閲覧する場合）。これらの場合、エンドツーエンドのセキュリティメカニズムを実施することは不可能かもしれません。しかし、一般的な目的は、ユーザーが有線リンク[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 Link-Layer Securityは、機密性と完全性の唯一のプロバイダーになる可能性があります。このシナリオでは、セキュリティの高い保証（政府の使用など）を必要とするユーザーは、承認された暗号化機器（例：ネットワークレイヤー）を採用する必要があります。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などの広く利用可能な低コストの物理層インターフェイスを利用するもの）では、受動的な脅威が大きな脅威です。1つの例は、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伝送ネットワークのトポロジーシナリオを分析すると、セキュリティの脅威は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：監視（パッシブの脅威）。ここでは、侵入者はULEブロードキャストを監視して、ULEデータに関する情報を取得したり、通信当事者のIDを追跡したりします（宛先NPAアドレスを監視します）。このシナリオでは、ULEペイロードデータとULEレシーバーのIDを保護するための措置を講じる必要があります。
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トランスミッションネットワークオペレーターは、そのような攻撃を認識していない可能性があります。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トランスミッションマルチプレックス全体をオーバーライドできる洗練された侵入者を想定しています。要件はケース2に似ています。MPEG-2トランスミッションネットワークオペレーターは通常、そのような攻撃を特定し、元の伝送を復元するための是正措置を提供できます。
For both Cases 2 and 3, there can be two sub-cases:
どちらの場合も2と3に、2つのサブケースがあります。
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.
REQ 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.
Req 2. L2 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.
Req 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.
Req 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.
Req 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.
GERQ（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）アルゴリズムの俊敏性をサポートする必要があります。システムの全体的なセキュリティに影響を与えることなく、Cryptoアルゴリズムとハッシュを更新することが可能であるはずです。
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をセキュリティ拡張ヘッダーの処理時に破棄する必要がある状況を回避しますが、前のヘッダーはすでに評価されています。1つの例外は、セキュリティ拡張ヘッダー[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：ULEデータ（ユーザー情報やIPアドレスなど）の監視を防ぐために、データの機密性（REQ 1）を提供する必要があります。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]を使用した認証スキームなど、新しい測定値が実装される場合があります。（Reqs 3および5）。さらに、リプレイ攻撃から保護するために、シーケンス番号（REQ 4）を使用できます。アウトサイダー攻撃の観点から、メッセージ認証コードを使用したグループ認証は、必要なレベルのセキュリティを提供できます（REQ 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
表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.
セキュリティサービスは、セキュリティ要件、たとえばベースプロファイル（ペイロード暗号化とアイデンティティ保護を備えた）と、これを拡張してリプレイ攻撃に対するソース認証と保護も提供する2番目のプロファイルに基づいてプロファイルにグループ化できます。特定のセキュリティ手法の使用はオプションですが、受信機デバイスは、すべてのプロファイルの相互運用性を確保するために、セクション4のREQ 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]は、単方向リンクカプセル化、ULE、[RFC4326]および一般的なモード用に設計された一般的なストリームカプセル化（GSE）で使用できる3つの新しい拡張ヘッダーを説明しています（一般的なストリーム（GS））、第2世代DVB物理層[GSE]によって提供されます。
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レシーバーID保護を提供する必要があります。このフレームワークは、リンク層認証と整合性の保証を提供するオプションの機能、および古い（重複した）データの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レシーバーID（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]).
Link-Layer（L2）IPトラフィックの暗号化は、一般的に放送/無線リンクで使用され、エンドツーエンドのセキュリティをサプリメントします（たとえば、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 FCの除去に関連する整合性の問題。ブリッジ型フレームの除去は、エンコープカプレータやレシーバーによって処理されている間、トラフィックを潜在的に検出されない腐敗にさらします。
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).
著者は、ゴリー・フェアハースト（アバディーン大学）からの助けとアドバイスを認めています。著者はまた、ローレンス・デュケロイとステファン・クーム（ESA）、Yim Fun Hu（ブラッドフォード大学）からの貢献を認めています。
[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] 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、「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）プロトコル、 "欧州通信基準、Institute（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、「情報技術、移動写真と関連するオーディオ情報システムの一般的なコーディング」、International Telecommunication Union、（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.、Montenegro、G。、およびZ. Shelby、「リンク関連の劣化を緩和することを目的としたプロキシを向上させるパフォーマンス」、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.、Weis、B.、Hardjono、T。、およびH. Harney、「The Group Domain of Strettation」、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-Networkアドレス翻訳（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.、Montenegro、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 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、ed。、「The Secure Shell（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 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] Harney、H.、Meth、U.、Colegrove、A。、およびG. Gross、 "GSAKMP：Group Secure Association Key Management Protocol"、RFC 4535、2006年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 5163、2008年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、「The Transport Layer Security（TLS）Protocolバージョン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.
このセクションでは、Secure ULEネットワークの展開に関するセキュリティフレームワークについて説明します。
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 ULEデータベースブロック
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セキュリティデータベースは、図2に示すように、キー管理ブロック（コントロールプレーン）と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フレームワークビルディングブロック
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 Cankapsulatorがキー管理グループサーバーとしても機能する場合に発生します。展開は、自動化されたキー管理プロトコル（GSAKMP [RFC4535]など）またはキーイング材料の手動挿入のいずれかを使用する場合があります。
There needs to be two databases, i.e., similar to the IPsec databases.
2つのデータベース、つまり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 Security Associationデータベースには、現在さまざまな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 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セキュリティデータベースブロックからキーイングマテリアルおよびポリシー情報を使用して、Secure ULE拡張ヘッダーを生成するか、Secure ULE拡張ヘッダーを解読してULEペイロードを取得します。ULEヘッダーとペイロードとともに、ULEセキュリティ拡張ヘッダー形式の概要の例を以下の図3に示します。
+-------+------+-------------------------------+------+
| 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に示すように、ブロック間で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セキュリティ拡張ヘッダーブロックによって使用され、セキュリティの生成のためのキーとポリシー資料を取得します拡張ヘッダー。
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エンティティは、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 * database、char * record、char * siquire_id）;
o Update_record_database (char * Database, char * record, char * Unique_ID);
o update_record_database（char * database、char * record、char * inquire_id）;
o Delete_record_database (char * Database, char * Unique_ID);
o delete_record_database（char * database、char * inquire_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 データベース - これはULEセキュリティデータベース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:
このインターフェイスは、図2に示すように、ULEセキュリティデータベースとULEセキュリティエクステンションヘッダーブロックの間にあります。トラフィックを送信する場合、ULEカプセレータは宛先アドレス、PID、および場合によってはL3ソースおよび宛先アドレスなどのその他の情報を使用して、ULEセキュリティデータベース内の関連するセキュリティレコード。次に、レコード内のデータを使用して、ULEセキュリティ拡張ヘッダーを作成します。受信したトラフィックの場合、ULE SNDUを受信したULE脱カプセレーターは、宛先アドレス、PID、およびULEエンコイプレーターによって挿入されたULEセキュリティIDをセキュリティ拡張機能に使用して、セキュリティデータベースから関連するレコードを取得します。次に、この情報を使用して、ULE拡張ヘッダーを復号化します。どちらの場合も（トラフィックを送信または受信）、送信者と受信機の主な違いはトラフィックの流れの方向であるため、1つのインターフェイスのみが必要です。そのようなインターフェイスの例は次のとおりです。
o Get_record_database (char * Database, char * record, char * Unique_ID);
o get_record_database（char * database、char * record、char * siquire_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レイヤーでのトラフィックのセキュリティサービスについて説明しています。このアーキテクチャは、主にインターネットプロトコル（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レシーバーのID（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]は、手動キーイングを備えた2つの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レイヤー（ULE以下）で提供できます。MPEG-2 TS暗号化は、特定のPID値で送信されたすべてのTSパケットを暗号化します。ただし、MPEG-2 TSは通常、一般的な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レシーバーは、すべてのMPEG-2 TSパケットを一致するPIDで復号化する必要があります。したがって、個々の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レシーバーは、共通の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セキュリティシステムはほとんどありません。デジタルテレビ放送の条件付きアクセスは一例です。ただし、このアプローチはテレビサービスに最適化されており、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 IPアドレスを含む完全なULEプロトコルデータユニット（PDU）の保護。保護は、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トランスミッションネットワーク内の受信機のIDを保護する能力。
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（またはL4でのTLS [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エンドツーエンドのセキュリティは、上記の利点（PEP、圧縮などの使用）を部分的に否定します。これらの手法は、TCPにカプセル化されたIPSECパケット交換を持つTCPパケットにのみ適用できますが、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
Haitham Cruickshank Center for Communications System Research（CCSR）Surrey University of Surrey Guildford、Surrey、Gu2 7XH UKメール：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 Mobile and Satellite Communications Research Center（MSCRC）エンジニアリング、デザインおよびテクノロジースクールブラッドフォードリッチモンドロード、ブラッドフォードBD7 1dp UKメール：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 Noisternig Multimedia Comm。グループ、DPT。ザルツブルク大学ヤコブ・ハリンジャー-Strのコンピュータ科学の2 5020 Salzburg Austriaメール：mnoist@cosy.sbg.ac.at
Sunil Iyengar Space & Defence Logica Springfield Drive Leatherhead Surrey KT22 7LP UK EMail: sunil.iyengar@logica.com
Sunil Iyengar Space＆Defense Logica Springfield Drive Leatherhead Surrey KT22 7LP UKメール：sunil.iyengar@logica.com