[要約] RFC 6257は、過酷な通信環境向けのバンドルプロトコル（RFC 5050）において、メッセージの真正性、完全性、および機密性を確保するための拡張仕様「Bundle Security Protocol (BSP)」を定義しています。「蓄積交換」を行う中継ノード間、あるいはエンドツーエンドでのセキュリティ保護を実現するための、デジタル署名や暗号化ブロックの形式と処理手順を規定しています（後にRFC 9172によって上書きされました）。
Internet Research Task Force (IRTF) S. Symington
Request for Comments: 6257 The MITRE Corporation
Category: Experimental S. Farrell
ISSN: 2070-1721 Trinity College Dublin
H. Weiss
P. Lovell
SPARTA, Inc.
May 2011
Bundle Security Protocol Specification
バンドルセキュリティプロトコル仕様
Abstract
概要
This document defines the bundle security protocol, which provides data integrity and confidentiality services for the Bundle Protocol. Separate capabilities are provided to protect the bundle payload and additional data that may be included within the bundle. We also describe various security considerations including some policy options.
このドキュメントでは、バンドルプロトコルのデータの整合性と機密性サービスを提供するバンドルセキュリティプロトコルを定義します。バンドルペイロードとバンドル内に含まれる可能性のある追加データを保護するための個別の機能が提供されます。また、いくつかのポリシーオプションを含むさまざまなセキュリティ上の考慮事項についても説明します。
This document is a product of the Delay-Tolerant Networking Research Group and has been reviewed by that group. No objections to its publication as an RFC were raised.
このドキュメントは、遅延耐性ネットワーキング研究グループの製品であり、そのグループによってレビューされています。RFCとしての出版に対する異議は提起されませんでした。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
このドキュメントは、インターネット標準の追跡仕様ではありません。試験、実験的実装、および評価のために公開されています。
This document defines an Experimental Protocol for the Internet community. This document is a product of the Internet Research Task Force (IRTF). The IRTF publishes the results of Internet-related research and development activities. These results might not be suitable for deployment. This RFC represents the consensus of the Delay-Tolerant Networking Research Group of the Internet Research Task Force (IRTF). Documents approved for publication by the IRSG are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、インターネットコミュニティの実験プロトコルを定義しています。このドキュメントは、インターネット研究タスクフォース（IRTF）の製品です。IRTFは、インターネット関連の研究開発活動の結果を公開しています。これらの結果は、展開に適していない場合があります。このRFCは、インターネット研究タスクフォース（IRTF）の遅延耐性ネットワーキング研究グループのコンセンサスを表しています。IRSGによって公開されたことが承認された文書は、インターネット標準のレベルの候補者ではありません。RFC 5741のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6257.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc6257で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2011 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
Table of Contents
目次
1. Introduction ....................................................4
1.1. Related Documents ..........................................4
1.2. Terminology ................................................5
2. Security Blocks .................................................8
2.1. Abstract Security Block ....................................9
2.2. Bundle Authentication Block ...............................13
2.3. Payload Integrity Block ...................................15
2.4. Payload Confidentiality Block .............................16
2.5. Extension Security Block ..................................20
2.6. Parameters and Result Fields ..............................21
2.7. Key Transport .............................................23
2.8. PIB and PCB Combinations ..................................24
3. Security Processing ............................................25
3.1. Nodes as Policy Enforcement Points ........................26
3.2. Processing Order of Security Blocks .......................26
3.3. Security Regions ..........................................29
3.4. Canonicalization of Bundles ...............................31
3.5. Endpoint ID Confidentiality ...............................37
3.6. Bundles Received from Other Nodes .........................38
3.7. The At-Most-Once-Delivery Option ..........................39
3.8. Bundle Fragmentation and Reassembly .......................40
3.9. Reactive Fragmentation ....................................41
3.10. Attack Model .............................................42
4. Mandatory Ciphersuites .........................................42
4.1. BAB-HMAC ..................................................42
4.2. PIB-RSA-SHA256 ............................................43
4.3. PCB-RSA-AES128-PAYLOAD-PIB-PCB ............................44
4.4. ESB-RSA-AES128-EXT ........................................48
5. Key Management .................................................51
6. Default Security Policy ........................................51
7. Security Considerations ........................................53
8. Conformance ....................................................55
9. IANA Considerations ............................................56
9.1. Bundle Block Types ........................................56
9.2. Ciphersuite Numbers .......................................56
9.3. Ciphersuite Flags .........................................56
9.4. Parameters and Results ....................................57
10. References ....................................................58
10.1. Normative References .....................................58
10.2. Informative References ...................................59
This document defines security features for the Bundle Protocol [DTNBP] intended for use in delay-tolerant networks, in order to provide Delay-Tolerant Networking (DTN) security services.
このドキュメントでは、遅延耐性ネットワーク（DTN）セキュリティサービスを提供するために、遅延トレラントネットワークで使用することを目的としたバンドルプロトコル[DTNBP]のセキュリティ機能を定義します。
The Bundle Protocol is used in DTNs that overlay multiple networks, some of which may be challenged by limitations such as intermittent and possibly unpredictable loss of connectivity, long or variable delay, asymmetric data rates, and high error rates. The purpose of the Bundle Protocol is to support interoperability across such stressed networks. The Bundle Protocol is layered on top of underlay-network-specific convergence layers, on top of network-specific lower layers, to enable an application in one network to communicate with an application in another network, both of which are spanned by the DTN.
バンドルプロトコルは、複数のネットワークをオーバーレイするDTNSで使用されます。これらの一部は、断続的で予測不可能な接続の損失、長いまたは変動遅延、非対称データレート、高いエラー率などの制限によって挑戦される可能性があります。バンドルプロトコルの目的は、そのような強力なネットワーク全体で相互運用性をサポートすることです。バンドルプロトコルは、ネットワーク固有の下層レイヤーの上にあるアンダーレイネットワーク固有の収束層の上に層状になっており、あるネットワーク内のアプリケーションがDTNによって範囲されている別のネットワーク内のアプリケーションと通信できるようにします。
Security will be important for the Bundle Protocol. The stressed environment of the underlying networks over which the Bundle Protocol will operate makes it important for the DTN to be protected from unauthorized use, and this stressed environment poses unique challenges for the mechanisms needed to secure the Bundle Protocol. Furthermore, DTNs may very likely be deployed in environments where a portion of the network might become compromised, posing the usual security challenges related to confidentiality, integrity, and availability.
セキュリティはバンドルプロトコルにとって重要です。バンドルプロトコルが動作する基礎となるネットワークのストレスのある環境により、DTNが不正使用から保護されることが重要になり、このストレスのある環境は、バンドルプロトコルを保護するために必要なメカニズムに独自の課題をもたらします。さらに、DTNSは、ネットワークの一部が侵害される可能性がある環境に展開される可能性が非常に高いため、機密性、整合性、可用性に関連する通常のセキュリティ上の課題を提起します。
Different security processing applies to the payload and extension blocks that may accompany it in a bundle, and different rules apply to various extension blocks.
さまざまなセキュリティ処理がペイロードブロックと拡張ブロックに適用され、バンドルに付随する可能性があり、さまざまなルールがさまざまな拡張ブロックに適用されます。
This document describes both the base Bundle Security Protocol (BSP) and a set of mandatory ciphersuites. A ciphersuite is a specific collection of various cryptographic algorithms and implementation rules that are used together to provide certain security services.
このドキュメントでは、ベースバンドルセキュリティプロトコル（BSP）と一連の必須暗号剤の両方について説明します。Ciphersuiteは、特定のセキュリティサービスを提供するために一緒に使用されるさまざまな暗号化アルゴリズムと実装ルールの特定のコレクションです。
The Bundle Security Protocol applies, by definition, only to those nodes that implement it, known as "security-aware" nodes. There MAY be other nodes in the DTN that do not implement BSP. All nodes can interoperate with the exception that BSP security operations can only happen at security-aware nodes.
バンドルセキュリティプロトコルは、定義上、それを実装する「セキュリティ認識（security-aware）」ノードとして知られるノードにのみ適用されます。DTNには、BSPを実装していない他のノードが存在してもよいです (MAY)。BSPセキュリティ操作がセキュリティ認識ノードでのみ発生できることを除いて、すべてのノードが相互運用できます。
This document is best read and understood within the context of the following other DTN documents:
このドキュメントは、次の他のDTNドキュメントのコンテキスト内で最もよく読まれ、理解されています。
"Delay-Tolerant Networking Architecture" [DTNarch] defines the architecture for delay-tolerant networks, but does not discuss security at any length.
「遅延耐性ネットワークアーキテクチャ」[DTNARCH]は、遅延耐性ネットワークのアーキテクチャを定義しますが、セキュリティについては議論していません。
The DTN Bundle Protocol [DTNBP] defines the format and processing of the blocks used to implement the Bundle Protocol, excluding the security-specific blocks defined here.
DTNバンドルプロトコル[DTNBP]は、ここに定義されているセキュリティ固有のブロックを除くバンドルプロトコルの実装に使用されるブロックの形式と処理を定義します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
このドキュメントのキーワード "MUST"、"MUST NOT"、"REQUIRED"、"SHALL"、"SHALL NOT"、"SHOULD"、"SHOULD NOT"、"RECOMMENDED"、"NOT RECOMMENDED"、"MAY"、および "OPTIONAL" は、[RFC2119] で説明されているように解釈されるものとします。
We introduce the following terminology for purposes of clarity:
明確さの目的のために、次の用語を紹介します。
source - the bundle node from which a bundle originates
ソース - バンドルが発生するバンドルノード
destination - the bundle node to which a bundle is ultimately destined
宛先 - バンドルが最終的に運命づけられるバンドルノード
forwarder - the bundle node that forwarded the bundle on its most recent hop
フォワーダー - 最新のホップにバンドルを転送したバンドルノード
intermediate receiver or "next hop" - the neighboring bundle node to which a forwarder forwards a bundle.
中間レシーバーまたは「次のホップ」 - フォワーダーがバンドルを転送する隣接するバンドルノード。
path - the ordered sequence of nodes through which a bundle passes on its way from source to destination
パス - バンドルがソースから宛先に向かう途中で通過するノードの順序付けられたシーケンス
In the figure below, which is adapted from figure 1 in the Bundle Protocol Specification [DTNBP], four bundle nodes (denoted BN1, BN2, BN3, and BN4) reside above some transport layer(s). Three distinct transport and network protocols (denoted T1/N1, T2/N2, and T3/N3) are also shown.
以下の図では、バンドルプロトコル仕様[DTNBP]の図1から採用されているため、4つのバンドルノード（BN1、BN2、BN3、およびBN4を示します）は、いくつかの輸送層の上にあります。3つの異なるトランスポートおよびネットワークプロトコル（T1/N1、T2/N2、およびT3/N3）も示されています。
+---------v-| +->>>>>>>>>>v-+ +->>>>>>>>>>v-+ +-^---------+
| BN1 v | | ^ BN2 v | | ^ BN3 v | | ^ BN4 |
+---------v-+ +-^---------v-+ +-^---------v-+ +-^---------+
| T1 v | + ^ T1/T2 v | + ^ T2/T3 v | | ^ T3 |
+---------v-+ +-^---------v-+ +-^---------v + +-^---------+
| N1 v | | ^ N1/N2 v | | ^ N2/N3 v | | ^ N3 |
+---------v-+ +-^---------v + +-^---------v-+ +-^---------+
| >>>>>>>>^ >>>>>>>>>>^ >>>>>>>>^ |
+-----------+ +------------+ +-------------+ +-----------+
| | | |
|<-- An Internet --->| |<--- An Internet --->|
| | | |
BN = "Bundle Node" as defined in the Bundle Protocol Specification
bn = "バンドルプロトコル仕様で定義されている「バンドルノード」
Figure 1: Bundle Nodes Sit at the Application Layer of the Internet Model
図1：インターネットモデルのアプリケーションレイヤーにバンドルノードが配置されます
Bundle node BN1 originates a bundle that it forwards to BN2. BN2 forwards the bundle to BN3, and BN3 forwards the bundle to BN4. BN1 is the source of the bundle and BN4 is the destination of the bundle. BN1 is the first forwarder, and BN2 is the first intermediate receiver; BN2 then becomes the forwarder, and BN3 the intermediate receiver; BN3 then becomes the last forwarder, and BN4 the last intermediate receiver, as well as the destination.
バンドルノードBN1は、BN2に転送するバンドルを発信します。BN2はバンドルをBN3に転送し、BN3はバンドルをBN4に転送します。BN1はバンドルのソースであり、BN4はバンドルの宛先です。BN1は最初のフォワーダーであり、BN2は最初の中間レシーバーです。BN2はフォワーダーになり、BN3は中間受信機になります。BN3は最後のフォワーダーになり、BN4は最後の中間レシーバーと宛先になります。
If node BN2 originates a bundle (for example, a bundle status report or a custodial signal), which is then forwarded on to BN3, and then to BN4, then BN2 is the source of the bundle (as well as being the first forwarder of the bundle) and BN4 is the destination of the bundle (as well as being the final intermediate receiver).
ノードBN2がバンドル（たとえば、バンドルステータスレポートまたは管理信号など）を発信し、BN3に転送し、BN4に転送する場合、BN2はバンドルのソースです（およびバンドル）とBN4は、バンドルの宛先です（最終的な中間レシーバーです）。
We introduce the following security-specific DTN terminology:
次のセキュリティ固有のDTN用語を紹介します。
security-source - a bundle node that adds a security block to a bundle
セキュリティソース - バンドルにセキュリティブロックを追加するバンドルノード
security-destination - a bundle node that processes a security block of a bundle
セキュリティ廃止 - バンドルのセキュリティブロックを処理するバンドルノード
security path - the ordered sequence of security-aware nodes through which a bundle passes on its way from the security-source to the security-destination
セキュリティパス - バンドルがセキュリティソースからセキュリティ廃止に向かう途中で通過するセキュリティ認識ノードの順序付けられたシーケンス
Referring to Figure 1 again:
図1をもう一度参照してください：
If the bundle that originates at BN1 is given a security block by BN1, then BN1 is the security-source of this bundle with respect to that security block, as well as being the source of the bundle.
BN1で発生するバンドルにBN1によってセキュリティブロックが与えられた場合、BN1はそのセキュリティブロックに関してこのバンドルのセキュリティソースであり、バンドルのソースです。
If the bundle that originates at BN1 is given a security block by BN2, then BN2 is the security-source of this bundle with respect to that security block, even though BN1 is the source.
BN1で発生するバンドルにBN2によってセキュリティブロックが与えられている場合、BN2がソースであるにもかかわらず、BN2はそのセキュリティブロックに関するこのバンドルのセキュリティソースです。
If the bundle that originates at BN1 is given a security block by BN1 that is intended to be processed by BN3, then BN1 is the security-source and BN3 is the security-destination with respect to this security block. The security path for this block is BN1 to BN3.
BN1で発生するバンドルにBN1がBN3によって処理することを目的としたセキュリティブロックが与えられた場合、BN1はセキュリティソースであり、BN3はこのセキュリティブロックに関するセキュリティ境界です。このブロックのセキュリティパスは、BN1からBN3です。
A bundle MAY have multiple security blocks. The security-source of a bundle, with respect to a given security block in the bundle, MAY be the same as or different from the security-source of the bundle with respect to a different security block in the bundle. Similarly, the security-destination of a bundle, with respect to each of that bundle's security blocks, MAY be the same or different. Therefore, the security paths for various blocks MAY be, and often will be, different.
バンドルは複数のセキュリティブロックを持ってもよいです (MAY)。バンドル内の特定のセキュリティブロックに関するバンドルのセキュリティソースは、バンドル内の異なるセキュリティブロックに関するバンドルのセキュリティソースと同じであっても異なっていてもよいです (MAY)。同様に、各セキュリティブロックに関するバンドルのセキュリティ宛先は、同じであっても異なっていてもよいです (MAY)。したがって、さまざまなブロックのセキュリティパスは異なっていてもよく (MAY)、多くの場合異なります。
If the bundle that originates at BN1 is given a security block by BN1 that is intended to be processed by BN3, and BN2 adds a security block with security-destination BN4, the security paths for the two blocks overlap but not completely. This problem is discussed further in Section 3.3.
BN1で発生するバンドルに、BN3によって処理されることを目的としたBN1によってセキュリティブロックが与えられ、BN2がセキュリティ境界BN4を備えたセキュリティブロックを追加する場合、2つのブロックのセキュリティパスは重複しますが完全ではありません。この問題については、セクション3.3でさらに説明します。
As required in [DTNBP], forwarding nodes MUST transmit blocks in a bundle in the same order in which they were received. This requirement applies to all DTN nodes, not just ones that implement security processing. Blocks in a bundle MAY be added or deleted according to the applicable specification, but those blocks that are both received and transmitted MUST be transmitted in the same order that they were received.
[DTNBP]で要求されているように、転送ノードはバンドル内のブロックを受信したのと同じ順序で送信しなければなりません (MUST)。この要件は、セキュリティ処理を実装するノードだけでなく、すべてのDTNノードに適用されます。バンドル内のブロックは適用される仕様に従って追加または削除されてもよいですが (MAY)、受信と送信の両方が行われるブロックは受信したのと同じ順序で送信されなければなりません (MUST)。
If a node is not security-aware, then it forwards the security blocks in the bundle unchanged unless the bundle's block processing flags specify otherwise. If a network has some nodes that are not security-aware, then the block processing flags SHOULD be set such that security blocks are not discarded at those nodes solely because they cannot be processed there. Except for this, the non-security-aware nodes are transparent relay points and are invisible as far as security processing is concerned.
ノードがセキュリティを認識していない場合、バンドルのブロック処理フラグに別の指定がない限り、バンドル内のセキュリティブロックを変更せずに転送します。ネットワーク内にセキュリティを認識していないノードがいくつか存在する場合、ブロック処理フラグは、それらのノードで単に処理できないという理由だけでセキュリティブロックが破棄されないように設定されるべきです (SHOULD)。これを除けば、セキュリティ非認識ノードは透過的な中継ポイントであり、セキュリティ処理に関する限り不可視です。
The block sequence also indicates the order in which certain significant actions have affected the bundle, and therefore the sequence in which actions MUST occur in order to produce the bundle at its destination.
また、ブロックシーケンスは、特定の重要なアクションがバンドルに影響を与えた順序を示しており、したがって、宛先でバンドルを生成するためにアクションが発生しなければならない (MUST) シーケンスを示しています。
There are four types of security blocks that MAY be included in a bundle. These are the Bundle Authentication Block (BAB), the Payload Integrity Block (PIB), the Payload Confidentiality Block (PCB), and the Extension Security Block (ESB).
バンドルに含まれてもよい (MAY) セキュリティブロックには4つのタイプがあります。これらは、バンドル認証ブロック（BAB）、ペイロード完全性ブロック（PIB）、ペイロード機密性ブロック（PCB）、および拡張セキュリティブロック（ESB）です。
The BAB is used to ensure the authenticity and integrity of the bundle along a single hop from forwarder to intermediate receiver. Since security blocks are only processed at security-aware nodes, a "single hop" from a security-aware forwarder to the next security-aware intermediate receiver might be more than one actual hop. This situation is discussed further in Section 2.2.
BABは、フォワーダーから中間レシーバーへの1回のホップに沿ってバンドルの信ity性と整合性を確保するために使用されます。セキュリティブロックはセキュリティ認識ノードでのみ処理されるため、セキュリティ対応のフォワーダーから次のセキュリティ対象の中間レシーバーまでの「シングルホップ」は、実際のホップを複数超える場合があります。この状況については、セクション2.2でさらに説明します。
The PIB is used to ensure the authenticity and integrity of the payload from the PIB security-source, which creates the PIB, to the PIB security-destination, which verifies the PIB authenticator. The authentication information in the PIB MAY (if the ciphersuite allows) be verified by any node in between the PIB security-source and the PIB security-destination that has access to the cryptographic keys and revocation status information required to do so.
PIBは、PIBを作成するPIBセキュリティソースから、PIB認証子を検証するPIBセキュリティ宛先までのペイロードの真正性と完全性を保証するために使用されます。PIB内の認証情報は、（暗号スイートで許可されている場合）必要な暗号鍵と失効ステータス情報へのアクセス権を持つ、PIBセキュリティソースとPIBセキュリティ宛先の間の任意のノードによって検証されてもよいです (MAY)。
Since a BAB protects a bundle on a "hop-by-hop" basis and other security blocks MAY be protecting over several hops or end-to-end, whenever both are present, the BAB MUST form the "outer" layer of protection -- that is, the BAB MUST always be calculated and added to the bundle after all other security blocks have been calculated and added to the bundle.
BABは「ホップバイホップ」ベースでバンドルを保護し、他のセキュリティブロックは複数ホップまたはエンドツーエンドで保護してもよいため (MAY)、両方が存在する場合は常に、BABが保護の「外側」層を形成しなければならず (MUST) ―― すなわち、他のすべてのセキュリティブロックが計算されてバンドルに追加された後に、BABが常に計算されてバンドルに追加されなければなりません (MUST)。
The PCB indicates that the payload has been encrypted, in whole or in part, at the PCB security-source in order to protect the bundle content while in transit to the PCB security-destination.
PCBは、PCBセキュリティ廃止に渡ってバンドルコンテンツを保護するために、PCBセキュリティソースでペイロードが全体または一部に暗号化されていることを示しています。
PIB and PCB protect the payload and are regarded as "payload-related" for purposes of the security discussion in this document. Other blocks are regarded as "non-payload" blocks. Of course, the primary block is unique and has separate rules.
PIBとPCBはペイロードを保護し、このドキュメントのセキュリティディスカッションの目的で「ペイロード関連」と見なされます。他のブロックは、「非支払い」ブロックと見なされます。もちろん、プライマリブロックは一意であり、個別のルールがあります。
The ESB provides security for non-payload blocks in a bundle. Therefore, ESB is not applied to PIBs or PCBs and, of course, is not appropriate for either the payload block or primary block.
ESBは、バンドル内の非支払いブロックのセキュリティを提供します。したがって、ESBはPIBまたはPCBに適用されず、もちろん、ペイロードブロックまたはプライマリブロックのいずれにも適していません。
Each of the security blocks uses the Canonical Bundle Block Format as defined in the Bundle Protocol Specification. That is, each security block is comprised of the following elements:
各セキュリティブロックは、バンドルプロトコル仕様で定義されているように、標準的なバンドルブロック形式を使用します。つまり、各セキュリティブロックは次の要素で構成されています。
o Block-type code
o ブロックタイプのコード
o Block processing control flags
o ブロック処理制御フラグ
o Block EID-reference list (OPTIONAL)
o ブロックEID参照リスト (OPTIONAL)
o Block data length
o データの長さをブロックします
o Block-type-specific data fields
o ブロックタイプ固有のデータフィールド
Since the four security blocks have most fields in common, we can shorten the description of the Block-type-specific data fields of each security block if we first define an abstract security block (ASB) and then specify each of the real blocks in terms of the fields that are present/absent in an ASB. Note that no bundle ever contains an actual ASB, which is simply a specification artifact.
4つのセキュリティブロックにはほとんどのフィールドが共通しているため、抽象セキュリティブロック（ASB）を最初に定義し、次に実際の各ブロックを用語で指定した場合、各セキュリティブロックのブロック型固有のデータフィールドの説明を短縮できます。ASBに存在する/存在しないフィールドの。実際のASBが含まれているバンドルはないことに注意してください。これは単なる仕様アーティファクトです。
Many of the fields below use the "SDNV" type defined in [DTNBP]. SDNV stands for Self-Delimiting Numeric Value.
以下のフィールドの多くは、[DTNBP]で定義された「SDNV」タイプを使用しています。SDNVは、自己削減数値の値を表しています。
An ASB consists of the following mandatory and optional fields:
ASBは、次の必須およびオプションのフィールドで構成されています。
o Block-type code (one byte) - as in all bundle protocol blocks except the primary bundle block. The block-type codes for the security blocks are:
o ブロックタイプのコード（1バイト） - プライマリバンドルブロックを除くすべてのバンドルプロトコルブロックのように。セキュリティブロックのブロック型コードは次のとおりです。
BundleAuthenticationBlock - BAB: 0x02
BundleAuthenticationBlock -bab：0x02
PayloadIntegrityBlock - PIB: 0x03
PayloadIntegrityBlock -PIB：0x03
PayloadConfidentialityBlock - PCB: 0x04
PayloadConfidentivelideBlock -PCB：0x04
ExtensionSecurityBlock - ESB: 0x09
ExtensionSecurityBlock -ESB：0x09
o Block processing control flags (SDNV) - defined as in all bundle protocol blocks except the primary bundle block (as described in the Bundle Protocol Specification [DTNBP]). SDNV encoding is described in the Bundle Protocol. There are no general constraints on the use of the block processing control flags, and some specific requirements are discussed later.
o ブロック処理制御フラグ（SDNV） - プライマリバンドルブロックを除くすべてのバンドルプロトコルブロックのように定義されています（バンドルプロトコル仕様[DTNBP]で説明されています）。SDNVエンコーディングは、バンドルプロトコルで説明されています。ブロック処理制御フラグの使用に関する一般的な制約はなく、いくつかの特定の要件については後で説明します。
o EID-references - composite field defined in [DTNBP] containing references to one or two endpoint identifiers (EIDs). Presence of the EID-reference field is indicated by the setting of the "Block contains an EID-reference field" (EID_REF) bit of the block processing control flags. If one or more references are present, flags in the ciphersuite ID field, described below, specify which.
o Eid -References- 1つまたは2つのエンドポイント識別子（EIDS）への参照を含む[DTNBP]で定義された複合フィールド。Eid-Referenceフィールドの存在は、ブロック処理制御フラグの「BlockにEID -Referenceフィールドが含まれている」（EID_REF）ビットの設定によって示されます。1つ以上の参照が存在する場合、以下で説明するCiphersuite IDフィールドのフラグは、どのを指定します。
If no EID fields are present, then the composite field itself MUST be omitted entirely and the EID_REF bit MUST be unset. A count field of zero is not permitted.
EIDフィールドが存在しない場合、複合フィールド自体を完全に省略しなければならず (MUST)、EID_REFビットを未設定（unset）にしなければなりません (MUST)。0のカウントフィールドは許可されません。
o The possible EIDs are:
o 可能なEidsは次のとおりです。
* (OPTIONAL) Security-source - specifies the security-source for the block. If this is omitted, then the source of the bundle is assumed to be the security-source unless otherwise indicated.
* (OPTIONAL) セキュリティソース - ブロックのセキュリティソースを指定します。これが省略された場合、特に明記されていない限り、バンドルの送信元がセキュリティソースであるとみなされます。
* (OPTIONAL) Security-destination - specifies the security-destination for the block. If this is omitted, then the destination of the bundle is assumed to be the security-destination unless otherwise indicated.
* (OPTIONAL) セキュリティ宛先 - ブロックのセキュリティ宛先を指定します。これが省略された場合、特に明記されていない限り、バンドルの宛先がセキュリティ宛先であるとみなされます。
If two EIDs are present, security-source is first and security-destination comes second.
2つのEIDが存在する場合、セキュリティソースが最初で、セキュリティ境界が2番目になります。
o Block data length (SDNV) - as in all bundle protocol blocks except the primary bundle block. SDNV encoding is described in the Bundle Protocol.
o ブロックデータ長（SDNV） - プライマリバンドルブロックを除くすべてのバンドルプロトコルブロックと同様に。SDNVエンコーディングは、バンドルプロトコルで説明されています。
o Block-type-specific data fields as follows:
o 次のように、ブロック型固有のデータフィールド：
* Ciphersuite ID (SDNV)
* ciphersuiteID（SDNV）
* Ciphersuite flags (SDNV)
* ciphersuiteフラグ（SDNV）
* (OPTIONAL) Correlator - when more than one related block is inserted, then this field MUST have the same value in each related block instance. This is encoded as an SDNV. See the note in Section 3.8 with regard to correlator values in bundle fragments.
* (OPTIONAL) Correlator - 複数の関連ブロックが挿入される場合、このフィールドは各関連ブロックインスタンスで同じ値を持たなければなりません (MUST)。これはSDNVとしてエンコードされます。バンドルフラグメントにおけるcorrelatorの値に関するセクション3.8の注記を参照してください。
* (OPTIONAL) Ciphersuite-parameters - compound field of the next two items
* (OPTIONAL) Ciphersuite-parameters - 次の2つの項目の複合フィールド
+ Ciphersuite-parameters length - specifies the length of the following Ciphersuite-parameters data field and is encoded as an SDNV.
+ Ciphersuite-Parametersの長さ - 次のCiphersuite-Parametersデータフィールドの長さを指定し、SDNVとしてエンコードされています。
+ Ciphersuite-parameters data - parameters to be used with the ciphersuite in use, e.g., a key identifier or initialization vector (IV). See Section 2.6 for a list of potential parameters and their encoding rules. The particular set of parameters that is included in this field is defined as part of the ciphersuite specification.
+ Ciphersuite -Parametersデータ - 使用中のCiphersuiteで使用するパラメーター、例えば、キー識別子または初期化ベクトル（IV）。潜在的なパラメーターとそのエンコードルールのリストについては、セクション2.6を参照してください。このフィールドに含まれる特定のパラメーターセットは、Ciphersuite仕様の一部として定義されます。
* (OPTIONAL) Security-result - compound field of the next two items
* (OPTIONAL) Security-result - 次の2つの項目の複合フィールド
+ Security-result length - contains the length of the next field and is encoded as an SDNV.
+ セキュリティ結果の長さ - 次のフィールドの長さを含み、SDNVとしてエンコードされます。
+ Security-result data - contains the results of the appropriate ciphersuite-specific calculation (e.g., a signature, Message Authentication Code (MAC), or ciphertext block key).
+ Security-Result Data-適切なCiphersuite固有の計算（署名、メッセージ認証コード（MAC）、または暗号文ブロックキーなど）の結果が含まれています。
Although the diagram hints at a 32-bit layout, this is purely for the purpose of exposition. Except for the "type" field, all fields are variable in length.
図は32ビットのレイアウトを示唆していますが、これは純粋に博覧会の目的のためです。「タイプ」フィールドを除き、すべてのフィールドの長さは変動します。
+----------------+----------------+----------------+----------------+
| type | flags (SDNV) | EID-ref list(comp) |
+----------------+----------------+----------------+----------------+
| length (SDNV) | ciphersuite (SDNV) |
+----------------+----------------+----------------+----------------+
| ciphersuite flags (SDNV) | correlator (SDNV) |
+----------------+----------------+----------------+----------------+
|params len(SDNV)| ciphersuite params data |
+----------------+----------------+----------------+----------------+
|res-len (SDNV) | security-result data |
+----------------+----------------+----------------+----------------+
Figure 2: Abstract Security Block Structure
図2：抽象的なセキュリティブロック構造
Some ciphersuites are specified in Section 4, which also specifies the rules that MUST be satisfied by ciphersuite specifications. Additional ciphersuites MAY be defined in separate specifications. Ciphersuite IDs not specified are reserved. Implementations of the Bundle Security Protocol decide which ciphersuites to support, subject to the requirements of Section 4. It is RECOMMENDED that implementations that allow additional ciphersuites permit ciphersuite ID values at least up to and including 127, and they MAY decline to allow larger ID values.
一部の暗号スイートはセクション4で規定されており、そこでは暗号スイート仕様が満たさなければならない (MUST) 規則も規定されています。追加の暗号スイートが別個の仕様で定義されてもよいです (MAY)。規定されていない暗号スイートIDは予約されています。Bundle Security Protocolの実装は、セクション4の要件に従って、どの暗号スイートをサポートするかを決定します。追加の暗号スイートを許可する実装は、少なくとも127以下の暗号スイートID値を許可することが推奨され (RECOMMENDED)、より大きなID値の許可を拒否してもよいです (MAY)。
The structure of the ciphersuite flags field is shown in Figure 3. In each case, the presence of an optional field is indicated by setting the value of the corresponding flag to one. A value of zero indicates the corresponding optional field is missing. Presently, there are five flags defined for the field; for convenience, these are shown as they would be extracted from a single-byte SDNV. Future additions may cause the field to grow to the left so, as with the flags fields defined in [DTNBP], the description below numbers the bit positions from the right rather than the standard RFC definition, which numbers bits from the left.
Ciphersuiteフラグフィールドの構造を図3に示します。それぞれの場合、対応するフラグの値を1に設定することにより、オプションフィールドの存在が示されます。ゼロの値は、対応するオプションフィールドが欠落していることを示します。現在、フィールドには5つのフラグが定義されています。便利なため、これらは単一バイトのSDNVから抽出されるように示されています。将来の追加により、フィールドが左に成長する可能性があるため、[dtnbp]で定義されているフラグフィールドのように、以下の説明は、左からの数字が標準のRFC定義ではなく右からビット位置を数字します。
src - bit 4 indicates whether the EID-reference field of the ASB contains the optional reference to the security-source.
SRC-BIT 4は、ASBのEID-Referenceフィールドに、セキュリティソースへのオプションの参照が含まれているかどうかを示します。
dest - bit 3 indicates whether the EID-reference field of the ASB contains the optional reference to the security-destination.
DEST-3は、ASBのEID-Referenceフィールドに、セキュリティ境界へのオプションの参照が含まれているかどうかを示します。
parm - bit 2 indicates whether or not the ciphersuite-parameters length and ciphersuite-parameters data fields are present.
PARM-BIT 2は、Ciphersuite-Parametersの長さとCiphersuite-Parametersデータフィールドが存在するかどうかを示します。
corr - bit 1 indicates whether or not the ASB contains an optional correlator.
Corr -Bit 1は、ASBにオプションの相関器が含まれているかどうかを示します。
res - bit 0 indicates whether or not the ASB contains the security-result length and security-result data fields.
res-bit 0は、ASBにセキュリティ結果の長さとセキュリティ対応データフィールドが含まれているかどうかを示します。
bits 5-6 are reserved for future use.
ビット5-6は、将来の使用のために予約されています。
Bit Bit Bit Bit Bit Bit Bit
6 5 4 3 2 1 0
+-----+-----+-----+-----+-----+-----+-----+
| reserved | src |dest |parm |corr |res |
+-----+-----+-----+-----+-----+-----+-----+
Figure 3: Ciphersuite Flags
図3：Ciphersuiteフラグ
A little bit more terminology: if the block is a PIB, when we refer to the PIB-source, we mean the security-source for the PIB as represented by the EID-reference in the EID-reference field. Similarly, we may refer to the "PCB-dest", meaning the security-destination of the PCB, again as represented by an EID reference. For example, referring to Figure 1 again, if the bundle that originates at BN1 is given a Payload Confidentiality Block (PCB) by BN1 that is protected using a key held by BN3, and it is given a Payload Integrity Block (PIB) by BN1, then BN1 is both the PCB-source and the PIB-source of the bundle, and BN3 is the PCB-destination of the bundle.
もう少し用語：ブロックがPIBの場合、PIBソースを参照するとき、EID-ReferenceフィールドのEID -Referenceで表されるPIBのセキュリティソースを意味します。同様に、EIDリファレンスで表されるように、再びPCBのセキュリティ脱出を意味する「PCB-DEST」を参照する場合があります。たとえば、図1を参照してください。BN1で発生するバンドルに、BN3が保持しているキーを使用して保護されているBN1によってペイロード機密性のブロック（PCB）が与えられ、BN1によってペイロード整合性ブロック（PIB）が与えられます。、次に、BN1はBundleのPCBソースとPIBソースの両方であり、BN3はバンドルのPCB脱出です。
The correlator field is used to associate several related instances of a security block. This can be used to place a BAB that contains the ciphersuite information at the "front" of a (probably large) bundle, and another correlated BAB that contains the security-result at the "end" of the bundle. This allows even very memory-constrained nodes to be able to process the bundle and verify the BAB. There are similar use cases for multiple related instances of PIB and PCB as will be seen below.
相関器フィールドは、セキュリティブロックのいくつかの関連インスタンスを関連付けるために使用されます。これを使用して、（おそらく大きな）バンドルの「フロント」に暗号化された情報を含むBABと、バンドルの「終了」にセキュリティ反応を含む別の相関BABを配置するために使用できます。これにより、非常にメモリが制約したノードでもバンドルを処理してBABを検証できるようになります。以下に示すように、PIBとPCBの複数の関連インスタンスには同様のユースケースがあります。
The ciphersuite specification MUST make it clear whether or not multiple block instances are allowed, and if so, under what conditions. Some ciphersuites can, of course, leave flexibility to the implementation, whereas others might mandate a fixed number of instances.
暗号スイート仕様は、複数のブロックインスタンスが許可されるかどうか、また許可される場合はどのような条件下であるかを明確にしなければなりません (MUST)。もちろん、一部の暗号スイートは実装に柔軟性を残すことができますが、他の暗号スイートは固定数のインスタンスを義務付ける場合があります。
For convenience, we use the term "first block" to refer to the initial block in a group of correlated blocks or to the single block if there are no others in the set. Obviously, there can be several unrelated groups in a bundle, each containing only one block or more than one, and each having its own "first block".
便宜上、「最初のブロック」という用語を使用して、セットに他のブロックがない場合は、相関ブロックのグループの初期ブロックまたは単一ブロックを参照します。明らかに、バンドルにはいくつかの無関係なグループがあり、それぞれに1つまたは複数のブロックしか含まれておらず、それぞれに独自の「最初のブロック」があります。
In this section, we describe typical BAB field values for two scenarios -- where a single instance of the BAB contains all the information and where two related instances are used, one "up front", which contains the ciphersuite, and another following the payload, which contains the security-result (e.g., a MAC).
このセクションでは、2つのシナリオの典型的なBABフィールド値について説明します。BABの単一のインスタンスには、すべての情報が含まれており、2つの関連するインスタンスが使用されている場合、1つは「前面」を使用します。、セキュリティの反応（たとえば、Mac）を含む。
For the case where a single BAB is used:
単一のBABが使用される場合：
The block-type code field value MUST be 0x02.
ブロックタイプコードフィールドの値は0x02でなければなりません (MUST)。
The block processing control flags value can be set to whatever values are required by local policy. Ciphersuite designers should carefully consider the effect of setting flags that either discard the block or delete the bundle in the event that this block cannot be processed.
ブロック処理制御フラグの値は、ローカルポリシーで必要な値に設定できます。Ciphersuiteの設計者は、このブロックを処理できない場合にブロックを破棄するか、バンドルを削除するフラグを設定する効果を注意深く考慮する必要があります。
The ciphersuite ID MUST be documented as a hop-by-hop authentication-ciphersuite that requires one instance of the BAB.
暗号スイートIDは、BABの1つのインスタンスを必要とするホップバイホップ認証暗号スイートとして文書化されなければなりません (MUST)。
The correlator field MUST NOT be present.
correlatorフィールドは存在してはなりません (MUST NOT)。
The ciphersuite-parameters field MAY be present, if so specified in the ciphersuite specification.
ciphersuite-parametersフィールドは、暗号スイート仕様でそのように指定されている場合、存在してもよいです (MAY)。
An EID-reference to the security-source MAY be present. The security-source can also be specified as part of key-information described in Section 2.6 or another block such as the Previous-Hop Insertion Block [PHIB]. The security-source might also be inferred from some implementation-specific means such as the convergence layer.
セキュリティソースへのEID参照が存在してもよいです (MAY)。セキュリティソースは、セクション2.6で説明されているキー情報の一部として、またはPrevious-Hop Insertion Block [PHIB]などの別のブロックとして指定することもできます。セキュリティソースは、コンバージェンス層などの実装固有の手段から推測される場合もあります。
An EID-reference to the security-destination MAY be present and is useful to ensure that the bundle has been forwarded to the correct next-hop node.
セキュリティ宛先へのEID参照が存在してもよく (MAY)、バンドルが正しいネクストホップノードに転送されたことを確認するのに役立ちます。
The security-result MUST be present as it is effectively the "output" from the ciphersuite calculation (e.g., the MAC or signature) applied to the (relevant parts of the) bundle (as specified in the ciphersuite definition).
セキュリティ結果は、（暗号スイート定義で指定されているように）バンドルの（関連部分）に適用された暗号スイート計算からの事実上の「出力」（例えばMACまたは署名）であるため、存在しなければなりません (MUST)。
For the case using two related BAB instances, the first instance is as defined above, except the ciphersuite ID MUST be documented as a hop-by-hop authentication ciphersuite that requires two instances of the BAB. In addition, the correlator MUST be present and the security-result length and security-result fields MUST be absent. The second instance of the BAB MUST have the same correlator value present and MUST contain security-result length and security-result data fields. The other optional fields MUST NOT be present. Typically, this second instance of a BAB will be the last block of the bundle.
2つの関連するBABインスタンスを使用する場合、最初のインスタンスは上記のように定義されますが、暗号スイートIDはBABの2つのインスタンスを必要とするホップバイホップ認証暗号スイートとして文書化されなければなりません (MUST)。さらに、correlatorが存在しなければならず (MUST)、security-result長およびsecurity-resultフィールドは存在してはなりません (MUST)。BABの2番目のインスタンスには、同じcorrelator値が存在しなければならず (MUST)、security-result長およびsecurity-resultデータフィールドを含まなければなりません (MUST)。その他のオプションのフィールドは存在してはなりません (MUST NOT)。通常、このBABの2番目のインスタンスはバンドルの最後のブロックになります。
The details of key transport for BAB are specified by the particular ciphersuite. In the absence of conflicting requirements, the following should be noted by implementors:
BABの鍵輸送の詳細は、特定の暗号化されたものによって指定されています。矛盾する要件がない場合、以下は実装者によって注意する必要があります。
o the key-information item in Section 2.6 is OPTIONAL, and if not provided, then the key SHOULD be inferred from the source-destination tuple, being the previous key used, a key created from a key-derivation function, or a pre-shared key.
o セクション2.6の鍵情報項目は任意であり (OPTIONAL)、提供されない場合、鍵は送信元と宛先のタプル、以前に使用された鍵、鍵導出関数から作成された鍵、または事前共有鍵から推測されるべきです (SHOULD)。
o if all the nodes are security-aware, the capabilities of the underlying convergence layer might be useful for identifying the security-source.
o すべてのノードがセキュリティ認識の場合、基礎となる収束層の機能は、セキュリティソースを識別するのに役立つ可能性があります。
o depending upon the key mechanism used, bundles can be signed by the sender, or authenticated for one or more recipients, or both.
o 使用される重要なメカニズムに応じて、バンドルは送信者によって署名されたり、1人以上の受信者またはその両方に対して認証されたりすることができます。
A PIB is an ASB with the following additional restrictions:
PIBは、次の追加の制限を伴うASBです。
The block-type code value MUST be 0x03.
ブロックタイプコード値は0x03でなければなりません (MUST)。
The block processing control flags value can be set to whatever values are required by local policy. Ciphersuite designers should carefully consider the effect of setting flags that either discard the block or delete the bundle in the event that this block cannot be processed.
ブロック処理制御フラグの値は、ローカルポリシーで必要な値に設定できます。Ciphersuiteの設計者は、このブロックを処理できない場合にブロックを破棄するか、バンドルを削除するフラグを設定する効果を注意深く考慮する必要があります。
The ciphersuite ID MUST be documented as an end-to-end authentication-ciphersuite or as an end-to-end error-detection-ciphersuite.
暗号スイートIDは、エンドツーエンド認証暗号スイート、またはエンドツーエンド誤り検出暗号スイートとして文書化されなければなりません (MUST)。
The correlator MUST be present if the ciphersuite requires that more than one related instance of a PIB be present in the bundle. The correlator MUST NOT be present if the ciphersuite only requires one instance of the PIB in the bundle.
暗号スイートがバンドル内にPIBの複数の関連インスタンスが存在することを要求する場合、correlatorが存在しなければなりません (MUST)。暗号スイートがバンドル内にPIBの1つのインスタンスのみを要求する場合、correlatorは存在してはなりません (MUST NOT)。
The ciphersuite-parameters field MAY be present.
ciphersuite-parametersフィールドは存在してもよいです (MAY)。
An EID-reference to the security-source MAY be present. The security-source can also be specified as part of key-information described in Section 2.6.
セキュリティソースへのEID参照が存在してもよいです (MAY)。セキュリティソースは、セクション2.6で説明されている鍵情報の一部として指定することもできます。
An EID-reference to the security-destination MAY be present.
セキュリティ宛先へのEID参照が存在してもよいです (MAY)。
The security-result is effectively the "output" from the ciphersuite calculation (e.g., the MAC or signature) applied to the (relevant parts of the) bundle. As in the case of the BAB, this field MUST be present if the correlator is absent. If more than one related instance of the PIB is required, then this is handled in the same way as described for the BAB above.
security-resultは、事実上、（暗号スイート定義で指定されているように）バンドルの（関連部分）に適用された暗号スイート計算からの「出力」（例えばMACまたは署名）です。BABの場合と同様に、correlatorが存在しない場合は、このフィールドが存在しなければなりません (MUST)。PIBの複数の関連インスタンスが必要な場合、これは上記のBABについて説明したのと同じ方法で処理されます。
The ciphersuite MAY process less than the entire original bundle payload. This might be because it is defined to process some subset of the bundle, or perhaps because the current payload is a fragment of an original bundle. For whatever reason, if the ciphersuite processes less than the complete, original bundle payload, the ciphersuite-parameters of this block MUST specify which bytes of the bundle payload are protected.
暗号スイートは、元のバンドルペイロード全体より少ない部分を処理してもよいです (MAY)。これは、バンドルのサブセットを処理するように定義されているため、あるいは現在のペイロードが元のバンドルのフラグメントであるためかもしれません。どのような理由であれ、暗号スイートが完全な元のバンドルペイロードより少ない部分を処理する場合、このブロックのciphersuite-parametersは、バンドルペイロードのどのバイトが保護されているかを指定しなければなりません (MUST)。
For some ciphersuites, (e.g., those using asymmetric keying to produce signatures or those using symmetric keying with a group key), the security information can be checked at any hop on the way to the security-destination that has access to the required keying information. This possibility is further discussed in Section 3.6.
一部のciphersuites（例えば、非対称キーイングを使用して署名を作成した人、またはグループキーを使用して対称キーイングを使用している人）の場合、セキュリティ情報は、必要なキーイング情報にアクセスできるセキュリティデステーションに向かう途中のホップでチェックできます。。この可能性については、セクション3.6でさらに説明します。
The use of a generally available key is RECOMMENDED if custodial transfer is employed and all nodes SHOULD verify the bundle before accepting custody.
保管責任転送（custodial transfer）が採用されている場合、一般に利用可能な鍵の使用が推奨され (RECOMMENDED)、すべてのノードは保管責任を受け入れる前にバンドルを検証すべきです (SHOULD)。
Most asymmetric PIB ciphersuites will use the PIB-source to indicate who the signer is and will not require the PIB-dest field because the key needed to verify the PIB authenticator will be a public key associated with the PIB-source.
ほとんどの非対称PIB暗号剤は、PIBソースを使用して、PIB認証器を確認するために必要なキーがPIBソースに関連する公開鍵になるため、署名者が誰であるか、PIB-DESTフィールドを必要としません。
A typical confidentiality ciphersuite will encrypt the payload using a randomly generated bundle encrypting key (BEK) and will use a key-information item in the PCB security-parameters to carry the BEK encrypted with some long-term key encryption key (KEK) or well-known public key. If neither the destination nor security-destination resolves the key to use for decryption, the key-information item in the ciphersuite-parameters field can also be used to indicate the decryption key with which the BEK can be recovered. If the bundle already contains PIBs and/or PCBs, these SHOULD also be encrypted using this same BEK, as described just below for "super-encryption". The encrypted block is encapsulated into a new PCB that replaces the original block at the same place in the bundle.
典型的な機密性暗号スイートは、ランダムに生成されたバンドル暗号化鍵（BEK）を使用してペイロードを暗号化し、PCBのsecurity-parameters内の鍵情報項目を使用して、長期鍵暗号化鍵（KEK）またはよく知られた公開鍵で暗号化されたBEKを伝達します。宛先もセキュリティ宛先も復号に使用する鍵を解決しない場合、ciphersuite-parametersフィールド内の鍵情報項目を使用して、BEKを復元できる復号鍵を示すこともできます。バンドルにすでにPIBやPCBが含まれている場合、これらも以下の「二重暗号化（super-encryption）」で説明するように、この同じBEKを使用して暗号化されるべきです (SHOULD)。暗号化されたブロックは、バンドル内の同じ場所にある元のブロックを置き換える新しいPCBにカプセル化されます。
It is strongly RECOMMENDED that a data integrity mechanism be used in conjunction with confidentiality, and that encryption-only ciphersuites NOT be used. AES-Galois/Counter Mode (AES-GCM) satisfies this requirement. The "authentication tag" or "integrity check value" is stored into the security-result rather than being appended to the payload as is common in some protocols since, as described below, it is important that there be no change in the size of the payload.
データの完全性メカニズムを機密性と併せて使用し、暗号化のみの暗号スイートを使用しないことが強く推奨されます (RECOMMENDED)。AES-Galois/Counter Mode (AES-GCM) はこの要件を満たします。以下で説明するように、ペイロードのサイズに変更がないことが重要であるため、「認証タグ」または「完全性チェック値」は、一部のプロトコルで一般的であるようにペイロードに追加されるのではなく、security-resultに格納されます。
The payload is encrypted "in-place", that is, following encryption, the payload block payload field contains ciphertext, not plaintext. The payload block processing control flags are unmodified.
ペイロードは「インプレース」と暗号化されます。つまり、暗号化に続いて、ペイロードブロックペイロードフィールドには、プレーンテキストではなく暗号文が含まれています。ペイロードブロック処理制御フラグは変更されていません。
The "in-place" encryption of payload bytes is to allow bundle payload fragmentation and reassembly, and custody transfer, to operate without knowledge of whether or not encryption has occurred and, if so, how many times.
ペイロードバイトの「インプレース」暗号化は、バンドルペイロードの断片化と再組み立て、および監護権の移転を、暗号化が発生したかどうか、そしてもしそうなら、何回かという知識なしに動作できるようにすることです。
Fragmentation, reassembly, and custody transfer are adversely affected by a change in size of the payload due to ambiguity about what byte range of the original payload is actually in any particular fragment. Ciphersuites SHOULD place any payload expansion, such as authentication tags (integrity check values) and any padding generated by a block-mode cipher, into an integrity check value item in the security-result field (see Section 2.6) of the confidentiality block.
断片化、再組み立て、および保管責任転送（custody transfer）は、元のペイロードのどのバイト範囲が実際に特定のフラグメントにあるかについての曖昧さのため、ペイロードのサイズの変化によって悪影響を受けます。暗号スイートは、認証タグ（完全性チェック値）やブロックモード暗号によって生成されるパディングなどのペイロード拡張を、機密性ブロックのsecurity-resultフィールド（セクション2.6を参照）の完全性チェック値項目に配置すべきです (SHOULD)。
Payload super-encryption is allowed, that is, encrypting a payload that has already been encrypted, perhaps more than once. Ciphersuites SHOULD define super-encryption such that, as well as re-encrypting the payload, it also protects the parameters of earlier encryption. Failure to do so may represent a vulnerability in some circumstances.
ペイロードの二重暗号化（super-encryption）は許可されています。すなわち、おそらく複数回、すでに暗号化されているペイロードを暗号化することです。暗号スイートは、ペイロードを再暗号化するだけでなく、以前の暗号化のパラメータも保護するように二重暗号化を定義すべきです (SHOULD)。そうしないと、状況によっては脆弱性をもたらす可能性があります。
Confidentiality is normally applied to the payload, and possibly to additional blocks. It is RECOMMENDED to apply a Payload Confidentiality ciphersuite to non-payload blocks only if these SHOULD be super-encrypted with the payload. If super-encryption of the block is not desired, then protection of the block SHOULD be done using the Extension Security Block mechanism rather than PCB.
機密性は通常、ペイロードに適用され、場合によっては追加のブロックにも適用されます。ペイロード機密性暗号スイートを非ペイロードブロックに適用するのは、それらがペイロードとともに二重暗号化されるべきである (SHOULD) 場合にのみ行うことが推奨されます (RECOMMENDED)。ブロックの二重暗号化が望ましくない場合、ブロックの保護はPCBではなくExtension Security Blockメカニズムを使用して行われるべきです (SHOULD)。
Multiple related PCB instances are required if both the payload and PIBs and PCBs in the bundle are to be encrypted. These multiple PCB instances require correlators to associate them with each other since the key-information is provided only in the first PCB.
バンドル内のペイロードとPIBとPCBの両方を暗号化する場合、複数の関連するPCBインスタンスが必要です。これらの複数のPCBインスタンスは、キー情報が最初のPCBでのみ提供されるため、相互に関連する相関者を互いに関連付ける必要があります。
There are situations where more than one PCB instance is required but the instances are not "related" in the sense that requires correlators. One example is where a payload is encrypted for more than one security-destination so as to be robust in the face of routing uncertainties. In this scenario, the payload is encrypted using a BEK. Several PCBs contain the BEK encrypted using different KEKs, one for each destination. These multiple PCB instances are not "related" and SHOULD NOT contain correlators.
複数のPCBインスタンスが必要であるが、相関子を必要とするという意味でインスタンスが「関連」していない状況があります。一例は、ルーティングの不確実性に直面しても堅牢であるように、ペイロードが複数のセキュリティ宛先に対して暗号化される場合です。このシナリオでは、ペイロードはBEKを使用して暗号化されます。いくつかのPCBには、宛先ごとに異なるKEKを使用して暗号化されたBEKが含まれています。これらの複数のPCBインスタンスは「関連」しておらず、correlatorを含めるべきではありません (SHOULD NOT)。
The ciphersuite MAY apply different rules to confidentiality for non-payload blocks.
暗号スイートは、非ペイロードブロックの機密性に異なる規則を適用してもよいです (MAY)。
A PCB is an ASB with the following additional restrictions:
PCBは、次の追加の制限を伴うASBです。
The block-type code value MUST be 0x04.
ブロックタイプコード値は0x04でなければなりません (MUST)。
The block processing control flags value can be set to whatever values are required by local policy, except that a PCB "first block" MUST have the "replicate in every fragment" flag set. This flag SHOULD NOT be set otherwise. Ciphersuite designers should carefully consider the effect of setting flags that either discard the block or delete the bundle in the event that this block cannot be processed.
ブロック処理制御フラグの値は、PCBの「第1ブロック」に「すべてのフラグメントに複製」フラグが設定されなければならない (MUST) ことを除き、ローカルポリシーで要求される任意の値に設定できます。このフラグは、それ以外の場合には設定すべきではありません (SHOULD NOT)。暗号スイート設計者は、このブロックが処理できない場合にブロックを破棄するかバンドルを削除するフラグを設定する影響を慎重に検討すべきです。
The ciphersuite ID MUST be documented as a confidentiality ciphersuite.
暗号スイートIDは、機密性暗号スイートとして文書化されなければなりません (MUST)。
The correlator MUST be present if there is more than one related PCB instance. The correlator MUST NOT be present if there are no related PCB instances.
複数の関連するPCBインスタンスが存在する場合、correlatorが存在しなければなりません (MUST)。関連するPCBインスタンスが存在しない場合、correlatorは存在してはなりません (MUST NOT)。
If a correlator is present, the key-information MUST be placed in the PCB "first block".
correlatorが存在する場合、鍵情報はPCBの「第1ブロック」に配置されなければなりません (MUST)。
Any additional bytes generated as a result of encryption and/or authentication processing of the payload SHOULD be placed in an "integrity check value" field (see Section 2.6) in the security-result of the first PCB.
ペイロードの暗号化および/または認証処理の結果として生成された追加のバイトは、最初のPCBのsecurity-result内の「完全性チェック値」フィールド（セクション2.6を参照）に配置すべきです (SHOULD)。
The ciphersuite-parameters field MAY be present.
ciphersuite-parametersフィールドは存在してもよいです (MAY)。
An EID-reference to the security-source MAY be present. The security-source can also be specified as part of key-information described in Section 2.6.
セキュリティソースへのEID参照が存在してもよいです (MAY)。セキュリティソースは、セクション2.6で説明されている鍵情報の一部として指定することもできます。
An EID-reference to the security-destination MAY be present.
セキュリティ宛先へのEID参照が存在してもよいです (MAY)。
The security-result MAY be present and normally contains fields such as an encrypted bundle encryption key, authentication tag, or the encrypted versions of bundle blocks other than the payload block.
security-resultは存在してもよく (MAY)、通常は暗号化されたバンドル暗号化鍵、認証タグ、またはペイロードブロック以外のバンドルブロックの暗号化されたバージョンなどのフィールドを含みます。
The ciphersuite MAY process less than the entire original bundle payload, either because the current payload is a fragment of the original bundle or just because it is defined to process some subset. For whatever reason, if the ciphersuite processes less than the complete, original bundle payload, the "first" PCB MUST specify, as part of the ciphersuite-parameters, which bytes of the bundle payload are protected.
現在のペイロードが元のバンドルのフラグメントであるため、または単に一部のサブセットを処理するように定義されているために、暗号スイートは元のバンドルペイロード全体より少ない部分を処理してもよいです (MAY)。理由の如何を問わず、暗号スイートが完全な元のバンドルペイロードより少ない部分を処理する場合、「第1」PCBは、ciphersuite-parametersの一部として、バンドルペイロードのどのバイトが保護されているかを指定しなければなりません (MUST)。
PCB ciphersuites MUST specify which blocks are to be encrypted. The specification MAY be flexible and be dependent upon block type, security policy, various data values, and other inputs, but it MUST be deterministic. The determination of whether or not a block is to be encrypted MUST NOT be ambiguous.
PCB暗号スイートは、どのブロックを暗号化するかを指定しなければなりません (MUST)。仕様は柔軟であり、ブロックタイプ、セキュリティポリシー、さまざまなデータ値、およびその他の入力に依存してもよいですが (MAY)、決定論的でなければなりません (MUST)。ブロックを暗号化するかどうかの決定は、曖昧であってはなりません (MUST NOT)。
As was the case for the BAB and PIB, if the ciphersuite requires more than one instance of the PCB, then the "first block" MUST contain any optional fields (e.g., security-destination, etc.) that apply to all instances with this correlator. These MUST be contained in the first instance and MUST NOT be repeated in other correlated blocks. Fields that are specific to a particular instance of the PCB MAY appear in that PCB. For example, security-result fields MAY (and probably will) be included in multiple related PCB instances, with each result being specific to that particular block. Similarly, several PCBs might each contain a ciphersuite-parameters field with an IV specific to that PCB instance.
BABおよびPIBの場合と同様に、暗号スイートがPCBの複数のインスタンスを必要とする場合、「第1ブロック」は、このcorrelatorを持つすべてのインスタンスに適用される任意のフィールド（例えばセキュリティ宛先など）を含まなければなりません (MUST)。これらは第1インスタンスに含まれなければならず (MUST)、他の相関ブロックで繰り返されてはなりません (MUST NOT)。PCBの特定のインスタンスに固有のフィールドは、そのPCBに現れてもよいです (MAY)。例えば、security-resultフィールドは複数の関連するPCBインスタンスに含まれてもよく (MAY) （おそらく含まれるでしょう）、各結果はその特定のブロックに固有のものとなります。同様に、いくつかのPCBはそれぞれ、そのPCBインスタンスに固有のIVを持つciphersuite-parametersフィールドを含んでもよいです。
Put another way: when confidentiality will generate multiple blocks, it MUST create a "first" PCB with the required ciphersuite ID, parameters, etc., as specified above. Typically, this PCB will appear early in the bundle. This "first" PCB contains the parameters that apply to the payload and also to the other correlated PCBs. The correlated PCBs follow the "first" PCB and MUST NOT repeat the ciphersuite-parameters, security-source, or security-destination fields from the first PCB. These correlated PCBs need not follow immediately after the "first" PCB, and probably will not do so. Each correlated block, encapsulating an encrypted PIB or PCB, is at the same place in the bundle as the original PIB or PCB.
別の言い方をすれば、機密性が複数のブロックを生成する場合、上記で指定されたように、必要な暗号スイートIDやパラメータなどを持つ「第1」PCBを作成しなければなりません (MUST)。通常、このPCBはバンドルの前半に現れます。この「第1」PCBには、ペイロードおよび他の相関PCBに適用されるパラメータが含まれます。相関PCBは「第1」PCBの後に続き、第1のPCBからのciphersuite-parameters、セキュリティソース、またはセキュリティ宛先フィールドを繰り返してはなりません (MUST NOT)。これらの相関PCBは「第1」PCBの直後に続く必要はなく、おそらくそうはならないでしょう。暗号化されたPIBまたはPCBをカプセル化する各相関ブロックは、バンドル内の元のPIBまたはPCBと同じ場所にあります。
A ciphersuite MUST NOT mix payload data and a non-payload block in a single PCB.
暗号スイートは、単一のPCB内でペイロードデータと非ペイロードブロックを混在させてはなりません (MUST NOT)。
Even if a to-be-encrypted block has the "discard" flag set, whether or not the PCB's "discard" flag is set is an implementation/policy decision for the encrypting node. (The "discard" flag is more properly called the "Discard if block can't be processed" flag.)
暗号化されたブロックに「破棄」フラグが設定されている場合でも、PCBの「破棄」フラグが設定されているかどうかは、暗号化ノードの実装/ポリシー決定です。（「廃棄」フラグは、「ブロックを処理できない場合は破棄」と呼ばれます。）
Any existing EID-list in the to-be-encapsulated original block remains exactly as-is, and is copied to become the EID-list for the replacing block. The encapsulation process MUST NOT replace or remove the existing EID-list entries. This is critically important for correct updating of entries at the security-destination.
カプセル化対象の元のブロック内の既存のEIDリストは完全にそのまま残され、置換ブロックのEIDリストとなるようにコピーされます。カプセル化プロセスは、既存のEIDリストエントリを置換または削除してはなりません (MUST NOT)。これは、セキュリティ宛先でエントリを正しく更新するために極めて重要です。
At the security-destination, either the specific destination or the bundle-destination, the processes described above are reversed. The payload is decrypted "in-place" using the salt, IV, and key values in the first PCB, including verification using the ICV. These values are described in Section 2.6. Each correlated PCB is also processed at the same destination, using the salt and key values from the first PCB and the block-specific IV item. The encapsulated block item in the security-result is decrypted and validated, using also the tag that SHOULD have been appended to the ciphertext of the original block data. Assuming the validation succeeds, the resultant plaintext, which is the entire content of the original block, replaces the PCB at the same place in the bundle. The block type reverts to that of the original block prior to encapsulation, and the other block-specific data fields also return to their original values. Implementors are cautioned that this "replacement" process requires delicate stitchery, as the EID-list contents in the decapsulated block are invalid. As noted above, the EID-list references in the original block were preserved in the "replacing" PCB, and will have been updated as necessary as the bundle has toured the DTN. The references from the PCB MUST replace the references within the EID-list of the newly decapsulated block. Caveat implementor.
特定の宛先またはバンドル宛先のいずれかのセキュリティ宛先において、上記のプロセスが逆に実行されます。ペイロードは、ICVを使用した検証を含め、第1のPCB内のソルト、IV、および鍵の値を使用して「インプレース」で復号されます。これらの値はセクション2.6で説明されています。各相関PCBも同じ宛先で処理され、第1のPCBからのソルトおよび鍵の値と、ブロック固有のIV項目を使用します。security-result内のカプセル化ブロック項目は復号および検証され、元のブロックデータの暗号文に追加されているべきであった (SHOULD) タグも使用されます。検証が成功したと仮定すると、元のブロックのコンテンツ全体である結果の平文が、バンドル内の同じ場所にあるPCBを置き換えます。ブロックタイプはカプセル化前の元のブロックのタイプに戻り、他のブロック固有のデータフィールドも元の値に戻ります。カプセル解除されたブロック内のEIDリストの内容は無効であるため、この「置換」プロセスには繊細な縫合が必要であることに実装者は注意してください。上記のように、元のブロック内のEIDリスト参照は「置換」PCBに保持され、バンドルがDTNを巡回するにつれて必要に応じて更新されています。PCBからの参照は、新しくカプセル解除されたブロックのEIDリスト内の参照を置き換えなければなりません (MUST)。実装者は注意してください。
Extension security blocks provide protection for non-payload-related portions of a bundle. ESBs MUST NOT be used for the primary block or payload, including payload-related security blocks (PIBs and PCBs).
拡張セキュリティブロックは、バンドルの非ペイロード関連部分の保護を提供します。ESBは、ペイロード関連のセキュリティブロック（PIBおよびPCB）を含むプライマリブロックまたはペイロードに使用してはなりません (MUST NOT)。
It is sometimes desirable to protect certain parts of a bundle in ways other than those applied to the bundle payload. One such example is bundle metadata that might specify the kind of data in the payload but not the actual payload detail, as described in [DTNMD].
バンドルペイロードに適用されるもの以外に、バンドルの特定の部分を保護することが望ましい場合があります。そのような例の1つは、[DTNMD]で説明されているように、実際のペイロードの詳細をペイロード内のデータの種類を指定する可能性のあるバンドルメタデータです。
ESBs are typically used to apply confidentiality protection. While it is possible to create an integrity-only ciphersuite, the block protection is not transparent and makes access to the data more difficult. For simplicity, this discussion describes the use of a confidentiality ciphersuite.
ESBは通常、機密保護を適用するために使用されます。整合性のみのciphersuiteを作成することは可能ですが、ブロック保護は透明ではなく、データへのアクセスがより困難になります。簡単にするために、この議論では、機密性ciphersuiteの使用について説明しています。
The protection mechanisms in ESBs are similar to other security blocks with two important differences:
ESBの保護メカニズムは、2つの重要な違いを持つ他のセキュリティブロックに似ています。
o different key values are used (using the same key as that for payload would defeat the purpose)
o さまざまなキー値が使用されます（ペイロードと同じキーを使用すると、目的を打ち負かす）
o the block is not encrypted or super-encrypted with the payload
o ブロックは、ペイロードで暗号化されていないか、スーパーインクリクト化されていません
A typical ESB ciphersuite will encrypt the extension block using a randomly generated ephemeral key and will use the key-information item in the security-parameters field to carry the key encrypted with some long-term key encryption key (KEK) or well-known public key. If neither the destination nor security-destination resolves the key to use for decryption, the key-information item in the ciphersuite-parameters field can be used also to indicate the decryption key with which the BEK can be recovered.
典型的なESB Ciphersuiteは、ランダムに生成された短命キーを使用して拡張ブロックを暗号化し、セキュリティパラメータフィールドのキー情報項目を使用して、長期キー暗号化キー（KEK）または有名な公開で暗号化されたキーを運びます鍵。宛先もセキュリティ拘留も復号化に使用するキーを解決しない場合、Ciphersuite-Parametersフィールドのキー情報項目を使用して、BEKを回復できる復号化キーを示すこともできます。
It is strongly RECOMMENDED that a data integrity mechanism be used in conjunction with confidentiality, and that encryption-only ciphersuites NOT be used. AES-GCM satisfies this requirement.
データの完全性メカニズムを機密性と併せて使用し、暗号化のみの暗号スイートを使用しないことが強く推奨されます (RECOMMENDED)。AES-GCMはこの要件を満たします。
The ESB is placed in the bundle in the same position as the block being protected. That is, the entire original block is processed (encrypted, etc.) and encapsulated in a "replacing" ESB-type block, and this appears in the bundle at the same sequential position as the original block. The processed data is placed in the security-result field.
ESBは、保護されているブロックと同じ位置にバンドルに配置されます。つまり、元のブロック全体が処理され（暗号化など）、ESBタイプのブロックを「交換」してカプセル化され、これは元のブロックと同じシーケンシャル位置のバンドルに表示されます。処理されたデータは、セキュリティ対応フィールドに配置されます。
The process is reversed at the security-destination with the recovered plaintext block replacing the ESB that had encapsulated it. Processing of EID-list entries, if any, is described in Section 2.4, and this MUST be followed in order to correctly recover EIDs.
このプロセスはセキュリティ宛先で逆に実行され、復元された平文ブロックがそれをカプセル化していたESBを置き換えます。EIDリストエントリの処理（存在する場合）はセクション2.4で説明されており、EIDを正しく復元するためにはこれに従わなければなりません (MUST)。
An ESB is an ASB with the following additional restrictions:
ESBは、次の追加の制限を伴うASBです。
The block type is 0x09.
ブロックタイプは0x09です。
Ciphersuite flags indicate which fields are present in this block. Ciphersuite designers should carefully consider the effect of setting flags that either discard the block or delete the bundle in the event that this block cannot be processed.
Ciphersuiteフラグは、このブロックにどのフィールドが存在するかを示します。Ciphersuiteの設計者は、このブロックを処理できない場合にブロックを破棄するか、バンドルを削除するフラグを設定する効果を注意深く考慮する必要があります。
EID-references MUST be stored in the EID-reference list.
EID参照はEID参照リストに格納されなければなりません (MUST)。
The security-source MAY be present. The security-source can also be specified as part of key-information described in Section 2.6. If neither is present, then the bundle-source is used as the security-source.
セキュリティソースは存在してもよいです (MAY)。セキュリティソースは、セクション2.6で説明されている鍵情報の一部として指定することもできます。どちらも存在しない場合、バンドル送信元がセキュリティソースとして使用されます。
The security-destination MAY be present. If not present, then the bundle-destination is used as the security-destination.
セキュリティ宛先は存在してもよいです (MAY)。存在しない場合、バンドル宛先がセキュリティ宛先として使用されます。
The security-parameters MAY optionally contain a block-type code field to indicate the type of the encapsulated block. Since this replicates a field in the encrypted portion of the block, it is a slight security risk, and its use is therefore OPTIONAL.
security-parametersには、カプセル化されたブロックのタイプを示すブロックタイプコードフィールドがオプションで含まれてもよいです (MAY)。これはブロックの暗号化された部分のフィールドを複製するため、わずかなセキュリティリスクであり、したがってその使用は任意です (OPTIONAL)。
Various ciphersuites include several items in the security-parameters and/or security-result fields. Which items MAY appear is defined by the particular ciphersuite description. A ciphersuite MAY support several instances of the same type within a single block.
さまざまな暗号スイートが、security-parametersおよび/またはsecurity-resultフィールドにいくつかの項目を含めます。どの項目が現れてもよいか (MAY) は、特定の暗号スイートの説明によって定義されます。暗号スイートは、単一ブロック内で同じタイプの複数のインスタンスをサポートしてもよいです (MAY)。
Each item is represented as a type-length-value. Type is a single byte indicating which item this is. Length is the count of data bytes to follow, and is an SDNV-encoded integer. Value is the data content of the item.
各アイテムは、タイプ長価値として表されます。タイプは、これがどのアイテムであるかを示す単一のバイトです。長さは、従うべきデータバイトのカウントであり、SDNVエンコードされた整数です。値はアイテムのデータコンテンツです。
Item types are
アイテムタイプはです
0: reserved
0：予約済み
1: initialization vector (IV)
1：初期化ベクトル（IV）
2: reserved
2：予約済み
3: key-information
3：キー情報
4: fragment-range (offset and length as a pair of SDNVs)
4：フラグメントレンジ（SDNVのペアとしてのオフセットと長さ）
5: integrity signature
5：整合性署名
6: unassigned
6：割り当てられていない
7: salt
7：塩
8: PCB integrity check value (ICV)
8：PCB整合性チェック値（ICV）
9: reserved
9：予約済み
10: encapsulated block
10：カプセル化されたブロック
11: block type of encapsulated block
11：カプセル化されたブロックのブロックタイプ
12 - 191: reserved
12-191：予約済み
192 - 250: private use
192-250：私的使用
251 - 255: reserved
251-255：予約
The following descriptions apply to the usage of these items for all ciphersuites. Additional characteristics are noted in the discussion for specific suites.
以下の説明は、すべての暗号条件のこれらのアイテムの使用に適用されます。特定のスイートの議論では、追加の特性が記載されています。
o initialization vector (IV): random value, typically eight to sixteen bytes.
o 初期化ベクトル（IV）：ランダム値、通常8〜16バイト。
o key-information: key material encoded or protected by the key management system and used to transport an ephemeral key protected by a long-term key. This item is discussed further in Section 2.7.
o キー情報：キー管理システムによってエンコードまたは保護され、長期キーによって保護されたはかないキーを輸送するために使用されるキー資料。この項目については、セクション2.7でさらに説明します。
o fragment-range: pair of SDNV values (offset then length) specifying the range of payload bytes to which a particular operation applies. This is termed "fragment-range" since that is its typical use, even though sometimes it describes a subset range that is not a fragment. The offset value MUST be the offset within the original bundle, which might not be the offset within the current bundle if the current bundle is already a fragment.
o fragment-range: 特定の操作が適用されるペイロードバイトの範囲を指定するSDNV値のペア（オフセット、次いで長さ）。これは典型的な用途であるため「fragment-range」と呼ばれますが、フラグメントではないサブセット範囲を記述することもあります。オフセット値は元のバンドル内のオフセットでなければならず (MUST)、現在のバンドルがすでにフラグメントである場合は、現在のバンドル内のオフセットとは異なる可能性があります。
o integrity signature: result of BAB or PIB digest or signing operation. This item is discussed further in Section 2.7.
o 整合性署名：BABまたはPIBダイジェストまたは署名操作の結果。この項目については、セクション2.7でさらに説明します。
o salt: an IV-like value used by certain confidentiality suites.
o 塩：特定の機密保持スイートで使用されるIVのような価値。
o PCB integrity check value (ICV): output from certain confidentiality ciphersuite operations to be used at the destination to verify that the protected data has not been modified.
o PCB整合性チェック値（ICV）：特定の機密性からの出力Ciphersuite操作は、保護されたデータが変更されていないことを確認するために宛先で使用されます。
o encapsulated block: result of confidentiality operation on certain blocks, contains the ciphertext of the block and MAY also contain an integrity check value appended to the ciphertext; MAY also contain padding if required by the encryption mode; used for non-payload blocks only.
o encapsulated block: 特定のブロックに対する機密性操作の結果であり、ブロックの暗号文を含み、暗号文に追加された完全性チェック値を含んでもよいです (MAY)。また、暗号化モードで必要な場合はパディングを含んでもよく (MAY)、非ペイロードブロックにのみ使用されます。
o block type of encapsulated block: block-type code for a block that has been encapsulated in ESB.
o ブロックタイプのカプセル化ブロック：ESBでカプセル化されたブロックのブロック型コード。
This specification endeavors to maintain separation between the security protocol and key management. However, these two interact in the transfer of key-information, etc., from security-source to security-destination. The intent of the separation is to facilitate the use of a variety of key management systems without needing to tailor a ciphersuite to each individually.
この仕様は、セキュリティプロトコルと主要な管理の分離を維持するために努力しています。ただし、これら2つは、セキュリティソースからセキュリティ境界への主要な情報などの転送に相互作用します。分離の意図は、各衝突器を個別に調整する必要なく、さまざまな主要な管理システムの使用を促進することです。
The key management process deals with such things as long-term keys, specifiers for long-term keys, certificates for long-term keys, and integrity signatures using long-term keys. The ciphersuite itself SHOULD NOT require a knowledge of these, and separation is improved if it treats these as opaque entities to be handled by the key management process.
鍵管理プロセスは、長期鍵、長期鍵の指定子、長期鍵の証明書、および長期鍵を使用した完全性署名などを扱います。暗号スイート自体はこれらの知識を必要とすべきではなく (SHOULD NOT)、これらを鍵管理プロセスによって処理される不透明なエンティティとして扱うことで分離が向上します。
The key management process deals specifically with the content of two of the items defined in Section 2.6: key-information (item type 3) and integrity signature (item type 5). The ciphersuite MUST define the details and format for these items. To facilitate interoperability, it is strongly RECOMMENDED that the implementations use the appropriate definitions from the Cryptographic Message Syntax (CMS) [RFC5652] and related RFCs.
鍵管理プロセスは、セクション2.6で定義されている項目のうち、鍵情報（項目タイプ3）と完全性署名（項目タイプ5）の2つの内容を具体的に扱います。暗号スイートは、これらの項目の詳細と形式を定義しなければなりません (MUST)。相互運用性を促進するために、実装は暗号メッセージ構文（CMS）[RFC5652]および関連RFCからの適切な定義を使用することが強く推奨されます (RECOMMENDED)。
Many situations will require several pieces of key-information. Again, ciphersuites MUST define whether they accept these packed into a single key-information item and/or separated into multiple instances of key-information. For interoperability, it is RECOMMENDED that ciphersuites accept these packed into a single key-information item, and that they MAY additionally choose to accept them sent as separate items.
多くの状況で、複数個の鍵情報が必要になります。ここでも、暗号スイートはこれらを単一の鍵情報項目にパックして受け入れるか、および/または鍵情報の複数のインスタンスに分離して受け入れるかを定義しなければなりません (MUST)。相互運用性のために、暗号スイートはこれらを単一の鍵情報項目にパックして受け入れることが推奨され (RECOMMENDED)、別々の項目として送信されたものを受け入れることを追加で選択してもよいです (MAY)。
Given the above definitions, nodes are free to combine applications of PIB and PCB in any way they wish -- the correlator value allows for multiple applications of security services to be handled separately. Since PIB and PCB apply to the payload and ESB to non-payload blocks, combinations of ESB with PIB and/or PCB are not considered.
上記の定義を考えると、ノードはPIBとPCBのアプリケーションを希望する方法で自由に組み合わせることができます。相関者値により、セキュリティサービスの複数のアプリケーションを個別に処理できます。PIBとPCBはペイロードとESBに非支払いブロックに適用されるため、ESBとPIBおよび/またはPCBの組み合わせは考慮されません。
There are some obvious security problems that could arise when applying multiple services. For example, if we encrypted a payload but left a PIB security-result containing a signature in the clear, payload guesses could be confirmed.
複数のサービスを適用するときに発生する可能性のあるいくつかの明らかなセキュリティの問題があります。たとえば、ペイロードを暗号化したが、明確なペイロード推測を確認することができるPIBセキュリティ結果を残した場合、確認できます。
We cannot, in general, prevent all such problems since we cannot assume that every ciphersuite definition takes account of every other ciphersuite definition. However, we can limit the potential for such problems by requiring that any ciphersuite that applies to one instance of a PIB or PCB MUST be applied to all instances with the same correlator.
すべての暗号スイート定義が他のすべての暗号スイート定義を考慮していると仮定することはできないため、一般にこのような問題をすべて防ぐことはできません。しかし、PIBまたはPCBの1つのインスタンスに適用される暗号スイートは、同じcorrelatorを持つすべてのインスタンスに適用されなければならない (MUST) と要求することにより、そのような問題の可能性を制限することができます。
We now list the PIB and PCB combinations that we envisage as being useful to support:
ここで、サポートするのに役立つと考えているPIBとPCBの組み合わせをリストします。
Encrypted tunnels - a single bundle MAY be encrypted many times en route to its destination. Clearly, it has to be decrypted an equal number of times, but we can imagine each encryption as representing the entry into yet another layer of tunnel. This is supported by using multiple instances of PCB, but with the payload encrypted multiple times, "in-place". Depending upon the ciphersuite definition, other blocks can and should be encrypted, as discussed above and in Section 2.4 to ensure that parameters are protected in the case of super-encryption.
暗号化トンネル - 単一のバンドルは、宛先に向かう途中で何度も暗号化されてもよいです (MAY)。明らかに同数回復号される必要がありますが、各暗号化はさらに別のトンネル層への進入を表すものとして考えることができます。これはPCBの複数のインスタンスを使用することでサポートされますが、ペイロードは「インプレース」で複数回暗号化されます。暗号スイートの定義に応じて、二重暗号化の場合にパラメータが保護されるように、上記およびセクション2.4で説明したように、他のブロックも暗号化できますし、暗号化されるべきです。
Multiple parallel authenticators - a single security-source might wish to protect the integrity of a bundle in multiple ways. This could be required if the bundle's path is unpredictable and if various nodes might be involved as security-destinations. Similarly, if the security-source cannot determine in advance which algorithms to use, then using all might be reasonable. This would result in uses of PIB that, presumably, all protect the payload, and which cannot in general protect one another. Note that this logic can also apply to a BAB, if the unpredictable routing happens in the convergence layer, so we also envisage support for multiple parallel uses of BAB.
複数の並列認証機 - 単一のセキュリティソースは、バンドルの整合性を複数の方法で保護したい場合があります。これは、バンドルのパスが予測不可能であり、さまざまなノードがセキュリティ断熱として関与している場合に必要な場合があります。同様に、セキュリティソースが使用するアルゴリズムを事前に決定できない場合、すべてを使用することが妥当かもしれません。これにより、おそらくすべてがペイロードを保護し、一般的に互いに保護できないPIBの使用が得られます。このロジックは、収束層で予測不可能なルーティングが発生した場合、BABにも適用できることに注意してください。したがって、BABの複数の並列使用のサポートも想定しています。
Multiple sequential authenticators - if some security-destination requires assurance about the route that bundles have taken, then it might insist that each forwarding node add its own PIB. More likely, however, would be that outbound "bastion" nodes would be configured to sign bundles as a way of allowing the sending "domain" to take accountability for the bundle. In this case, the various PIBs will likely be layered, so that each protects the earlier applications of PIB.
複数のシーケンシャル認証器 - 一部のセキュリティ拘留に、バンドルがとったルートに関する保証が必要な場合、各転送ノードが独自のPIBを追加することを主張するかもしれません。ただし、おそらく、送信「ドメイン」がバンドルの説明責任を負うようにする方法としてバンドルに署名するようにアウトバウンド「バスティオン」ノードが構成される可能性が高いでしょう。この場合、さまざまなPIBがレイヤー化される可能性が高いため、それぞれがPIBの以前のアプリケーションを保護します。
Authenticated and encrypted bundles - a single bundle MAY require both authentication and confidentiality. Some specifications first apply the authenticator and follow this by encrypting the payload and authenticator. As noted previously in the case where the authenticator is a signature, there are security reasons for this ordering. (See the PCB-RSA-AES128-PAYLOAD-PIB-PCB ciphersuite defined in Section 4.3.) Others apply the authenticator after encryption, that is, to the ciphertext. This ordering is generally RECOMMENDED and minimizes attacks that, in some cases, can lead to recovery of the encryption key.
認証および暗号化されたバンドル - 単一のバンドルに認証と機密性の両方が要求されてもよいです (MAY)。一部の仕様は、最初に認証子を適用し、ペイロードと認証子の両方を暗号化することによってこれに準拠します。前述のように、認証子が署名である場合、この順序付けにはセキュリティ上の理由があります（セクション4.3で定義されている PCB-RSA-AES128-PAYLOAD-PIB-PCB 暗号スイートを参照）。他の仕様では暗号化後認証、すなわち暗号化の後に認証子を適用する方法が使用されます。この順序付けは一般に推奨され (RECOMMENDED)、暗号化鍵の回復につながる可能性のある攻撃を最小限に抑えます。
There are, no doubt, other valid ways to combine PIB and PCB instances, but these are the "core" set supported in this specification. Having said that, as will be seen, the mandatory ciphersuites defined here are quite specific and restrictive in terms of limiting the flexibility offered by the correlator mechanism. This is primarily designed to keep this specification as simple as possible, while at the same time supporting the above scenarios.
間違いなく、PIBとPCBインスタンスを組み合わせる他の有効な方法がありますが、これらはこの仕様でサポートされている「コア」セットです。見られるように、ここで定義されている必須のciphersuitesは、相関器メカニズムによって提供される柔軟性を制限するという点で非常に具体的かつ制限的です。これは主に、この仕様を可能な限りシンプルに保つように設計されていますが、同時に上記のシナリオをサポートしています。
This section describes the security aspects of bundle processing.
このセクションでは、バンドル処理のセキュリティの側面について説明します。
All nodes are REQUIRED to have and enforce their own configurable security policies, whether these policies be explicit or default, as defined in Section 6.
セクション6で定義されているように、すべてのノードは、これらのポリシーが明示的であるかデフォルトであるかにかかわらず、独自の設定可能なセキュリティポリシーを持ち、それを適用することが要求されます (REQUIRED)。
All nodes serve as Policy Enforcement Points (PEPs) insofar as they enforce polices that MAY restrict the permissions of bundle nodes to inject traffic into the network. Policies MAY apply to traffic that originates at the current node, traffic that terminates at the current node, and traffic that is to be forwarded by the current node to other nodes. If a particular transmission request, originating either locally or remotely, satisfies the node's policy or policies and is therefore accepted, then an outbound bundle can be created and dispatched. If not, then in its role as a PEP, the node will not create or forward a bundle. Error handling for such cases is currently considered out of scope for this document.
すべてのノードは、バンドルノードがネットワークにトラフィックを注入するパーミッションを制限してもよい (MAY) ポリシーを強制する限りにおいて、ポリシー適用ポイント（PEP）として機能します。ポリシーは、自ノードで発生するトラフィック、自ノードで終了するトラフィック、および自ノードによって他のノードに転送されるトラフィックに適用されてもよいです (MAY)。ローカルまたはリモートで発信された特定の送信要求がノードのポリシーを満たし、したがって受け入れられる場合、送信バンドルが作成されて送出されます。そうでない場合、PEPとしての役割において、ノードはバンドルを作成または転送しません。このような場合のエラー処理は、現在本文書の範囲外とみなされています。
Policy enforcing code MAY override all other processing steps described here and elsewhere in this document. For example, it is valid to implement a node that always attempts to attach a PIB. Similarly, it is also valid to implement a node that always rejects all requests that imply the use of a PIB.
ポリシー強制コードは、本文書および本文書の他の場所で説明されている他のすべての処理ステップを上書きしてもよいです (MAY)。例えば、常にPIBの添付を試みるノードを実装することは有効です。同様に、PIBの使用を暗示するすべての要求を常に拒否するノードを実装することも有効です。
Nodes MUST consult their security policy to determine the criteria that a received bundle ought to meet before it will be forwarded. These criteria MUST include a determination of whether or not the received bundle MUST include a valid BAB, PIB, PCB, or ESB. If the bundle does not meet the node's policy criteria, then the bundle MUST be discarded and processed no further; in this case, a bundle status report indicating the failure MAY be generated.
ノードは、受信したバンドルが転送される前に満たすべき基準を決定するために、自らのセキュリティポリシーを参照しなければなりません (MUST)。これらの基準には、受信したバンドルが有効なBAB、PIB、PCB、またはESBを含まなければならない (MUST) かどうかの判断を含まなければなりません (MUST)。バンドルがノードのポリシー基準を満たさない場合、そのバンドルは破棄されなければならず (MUST)、それ以上処理されてはなりません。この場合、障害を示すバンドルステータスレポートが生成されてもよいです (MAY)。
The node's policy MAY call for the node to add or subtract some security blocks. For example, it might require that the node attempt to encrypt (parts of) the bundle for some security-destination or that it add a PIB. If the node's policy requires a BAB to be added to the bundle, it MUST be added last so that the calculation of its security-result MAY take into consideration the values of all other blocks in the bundle.
ノードのポリシーは、ノードに一部のセキュリティブロックの追加または削除を要求してもよいです (MAY)。例えば、特定のセキュリティ宛先に対してバンドルの（一部を）暗号化することをノードが試みることや、PIBを追加することを要求する場合があります。ノードのポリシーがバンドルへのBABの追加を要求する場合、BABは最後に追加されなければならず (MUST)、これによりそのsecurity-resultの計算がバンドル内の他のすべてのブロックの値を考慮に入れてもよいようになります (MAY)。
The processing order of security actions for a bundle is critically important for the actions to complete successfully. In general, the actions performed at the originating node MUST be executed in the reverse sequence at the destination. There are variations and exceptions, and these are noted below.
バンドルに対するセキュリティアクションの処理順序は、アクションが正常に完了するために極めて重要です。一般に、送信元ノードで実行されたアクションは、宛先で逆の順序で実行されなければなりません (MUST)。バリエーションや例外があり、これらは以下に記載されています。
The sequence is maintained in the ordering of security blocks in the bundle. It is for this reason that blocks MUST NOT be rearranged at forwarding nodes, whether or not they support the security protocols. The only blocks that participate in this ordering are the primary and payload blocks, and the PIB and PCB security blocks themselves. All other extension blocks, including ESBs, are ignored for purposes of determining the processing order.
シーケンスは、バンドル内のセキュリティブロックの順序付けで維持されます。セキュリティプロトコルをサポートしているかどうかにかかわらず、転送ノードでブロックを並べ替えてはならない (MUST NOT) のは、この理由によるものです。この順序付けに関与する唯一のブロックは、プライマリブロックとペイロードブロック、およびPIBとPCBのセキュリティブロック自体です。ESBを含む他のすべての拡張ブロックは、処理順序を決定する目的では無視されます。
The security blocks are added to and removed from a bundle in a last-in-first-out (LIFO) manner, with the top of the stack immediately after the primary block. A newly created bundle has just the primary and payload blocks, and the stack is empty. As security actions are requested for the bundle, security blocks are pushed onto the stack immediately after the primary block. The early actions have security blocks close to the payload, later actions have blocks nearer to the primary block. The actions deal with only those blocks in the bundle at the time, so, for example, the first to be added processes only the payload and primary blocks, the next might process the first if it chooses and the payload and primary, and so on. The last block to be added can process all the blocks.
セキュリティブロックは、プライマリブロックの直後にスタックの上部にある、最後のファーストアウト（LIFO）の方法でバンドルに追加され、削除されます。新しく作成されたバンドルには、プライマリブロックとペイロードブロックのみがあり、スタックは空です。バンドルのセキュリティアクションが要求されるため、プライマリブロックの直後にセキュリティブロックがスタックに押し込まれます。初期のアクションには、ペイロードに近いセキュリティブロックがあり、後のアクションにはプライマリブロックに近いブロックがあります。アクションは、当時のバンドル内のこれらのブロックのみを扱うため、たとえば、最初に追加されたのはペイロードとプライマリブロックのみを処理し、次は選択した場合に最初のプロセスを処理する可能性があります。。追加する最後のブロックは、すべてのブロックを処理できます。
When the bundle is received, this process is reversed and security processing begins at the top of the stack, immediately after the primary block. The security actions are performed, and the block is popped from the stack. Processing continues with the next security block until finally only the payload and primary blocks remain.
バンドルを受信すると、このプロセスが逆転し、プライマリブロックの直後に、スタックの上部からセキュリティ処理が開始されます。セキュリティアクションが実行され、ブロックがスタックからポップされます。最終的にペイロードとプライマリブロックのみが残るまで、次のセキュリティブロックで処理が続きます。
The simplicity of this description is undermined by various real-world requirements. Nonetheless, it serves as a helpful initial framework for understanding the bundle security process.
この説明の単純さは、さまざまな現実世界の要件によって損なわれています。それにもかかわらず、それはバンドルセキュリティプロセスを理解するための役立つ初期フレームワークとして機能します。
The first issue is a very common one and easy to handle. The bundle may be sent indirectly to its destination, requiring several forwarding hops to finally arrive there. Security processing happens at each node, assuming that the node supports bundle security. For the following discussion, we assume that a bundle is created and that confidentiality, then payload integrity, and finally bundle authentication are applied to it. The block sequence would therefore be primary-BAB-PIB-PCB-payload. Traveling from source to destination requires going through one intermediate node, so the trip consists of two hops.
最初の問題は非常に一般的で、扱いやすい問題です。バンドルは間接的に目的地に送られる場合があり、最終的にそこに到着するにはいくつかの転送ホップが必要です。セキュリティ処理は、ノードがバンドルセキュリティをサポートしていると仮定して、各ノードで行われます。以下の議論では、バンドルが作成され、その機密性、ペイロードの整合性、そして最後にバンドル認証が適用されると想定しています。したがって、ブロックシーケンスはプライマリバブ-PIB-PCB-PAYLOADになります。ソースから目的地への移動には、1つの中間ノードを通過する必要があるため、旅行は2つのホップで構成されています。
When the bundle is received at the intermediate node, the receive processing validates the BAB and pops it from the stack. However, the PIBs and PCBs have the final destination as their security-destination, so these cannot be processed and removed. The intermediate node then begins the send process with the four remaining blocks in the bundle. The outbound processing adds any security blocks required by local policy, and these are pushed on the stack immediately after the primary block, ahead of the PIB. In this example, the intermediate node adds a PIB as a signature that the bundle has passed through the node.
中間ノードでバンドルを受信すると、受信処理がBABを検証し、スタックからポップします。ただし、PIBSとPCBにはセキュリティ境界として最終目的地があるため、これらを処理して削除することはできません。中間ノードは、バンドルに残りの4つのブロックを使用して送信プロセスを開始します。アウトバウンド処理は、ローカルポリシーに必要なセキュリティブロックを追加し、これらはPIBの前にプライマリブロックの直後にスタックに押し付けられます。この例では、中間ノードは、バンドルがノードを通過した署名としてPIBを追加します。
The receive processing at the destination first handles the intermediate node's PIB and pops it, next is the originator's PIB, also popped, and finally the originator's confidentiality block that allows the payload to be decrypted and the bundle handled for delivery.
宛先の受信処理は、中間ノードのPIBを最初に処理してポップします。次に、オリジネーターのPIBがポップされ、最後にペイロードを復号化し、バンドルを配信用に処理できるオリジネーターの機密性ブロックがポップされます。
In practice, DTNs are likely to be more complex. The security policy for a node specifies the security requirements for a bundle. The policy will possibly cause one or more security operations to be applied to the bundle at the current node, each with its own security-destination. Application of policy at subsequent nodes might cause additional security operations, each with a security-destination. The list of security-destinations in the security blocks (BAB, PIB and PCB, not ESB) creates a partial-ordering of nodes that MUST be visited en route to the bundle-destination.
実際には、DTNはより複雑になる可能性があります。ノードのセキュリティポリシーは、バンドルのセキュリティ要件を指定します。このポリシーにより、現在のノードにおいてバンドルに1つ以上のセキュリティ操作が適用される可能性があり、それぞれに独自のセキュリティ宛先が存在します。後続のノードでポリシーを適用すると、それぞれセキュリティ宛先を持つ追加のセキュリティ操作が発生する可能性があります。セキュリティブロック（ESBではなくBAB、PIB、およびPCB）内のセキュリティ宛先のリストは、バンドル宛先に向かう途中で訪問しなければならない (MUST) ノードの部分順序を作成します。
The bundle security scheme does not deal with security paths that overlap partially but not completely. The security policy for a node MUST avoid specifying, for a bundle, a security-destination that causes a conflict with any existing security-destination in that bundle. This is discussed further in Section 3.3.
バンドルセキュリティスキームは、部分的であるが完全には重複しないセキュリティパスを扱いません。ノードのセキュリティポリシーは、あるバンドルに対して、そのバンドル内の既存のセキュリティ宛先との競合を引き起こすセキュリティ宛先を指定することを回避しなければなりません (MUST)。これについてはセクション3.3でさらに説明します。
The second issue relates to the reversibility of certain security process actions. In general, the actions fall into two categories: those that do not affect other parts of the bundle and those that are fully reversible. Creating a bundle signature, for example, does not change the bundle content except for the result. The encryption performed as part of the confidentiality processing does change the bundle, but the reverse processing at the destination restores the original content.
2番目の問題は、特定のセキュリティプロセスアクションの可逆性に関連しています。一般に、アクションは2つのカテゴリに分類されます。バンドルの他の部分に影響を与えないカテゴリと完全に可逆的なカテゴリです。たとえば、バンドル署名を作成しても、結果を除いてバンドルコンテンツは変更されません。機密性処理の一部として実行される暗号化はバンドルを変更しますが、宛先での逆処理により元のコンテンツが復元されます。
The third category is the one where the bundle content has changed slightly and in a non-destructive way, but there is no mechanism to reverse the change. The simplest example is the addition of an EID-reference to a security block. The addition of the reference causes the text to be added to the bundle's dictionary. The text may also be used by other references, so removal of the block and this specific EID-reference does not cause removal of the text from the dictionary. This shortcoming is of no impact to the "sequential" or "wrapping" security schemes described above, but does cause failures with "parallel" authentication mechanisms. Solutions for this problem are implementation specific and typically involve multi-pass processing such that blocks are added at one stage and the security-results calculated at a later stage of the overall process.
3番目のカテゴリは、バンドルコンテンツがわずかに変化し、非破壊的な方法で変更されたカテゴリですが、変更を逆転させるメカニズムはありません。最も簡単な例は、セキュリティブロックへのEID参照の追加です。参照を追加すると、テキストがバンドルの辞書に追加されます。テキストは他の参照でも使用される場合があるため、ブロックを削除し、この特定のEid -Referenceは辞書からテキストを削除することはありません。この欠点は、上記の「シーケンシャル」または「ラッピング」セキュリティスキームに影響を与えませんが、「並列」認証メカニズムで障害を引き起こします。この問題のソリューションは実装固有であり、通常、1つの段階でブロックが追加され、プロセス全体の後期段階でセキュリティ反応が計算されるようにマルチパス処理が含まれます。
Certain ciphersuites have sequence requirements for their correct operation, most notably the bundle authentication ciphersuites. Processing for bundle authentication is required to happen after all other sending operations, and prior to any receive operations at the next-hop node. Therefore, it follows that BABs MUST always be pushed onto the stack after all others.
特定の暗号スイートには、正しい動作のための順序要件があり、特にバンドル認証暗号スイートにおいて顕著です。バンドル認証の処理は、他のすべての送信操作の後、およびネクストホップノードでの受信操作の前に発生することが要求されます。したがって、BABは常に他のすべての後にスタックにプッシュされなければなりません (MUST)。
Although we describe the security block list as a stack, there are some blocks that are placed after the payload and therefore are not part of the stack. The BundleAuthentication ciphersuite #1 ("BA1") requires a second, correlated block to contain the security-result, and this block is placed after the payload, usually as the last block in the bundle. We can apply the stack rules even to these blocks by specifying that they be added to the end of the bundle at the same time that their "owner" or "parent" block is pushed on the stack. In fact, they form a stack beginning at the payload but growing in the other direction. Also, not all blocks in the main stack have a corresponding entry in the trailing stack. The only blocks that MUST follow the payload are those mandated by ciphersuites as correlated blocks for holding a security-result. No other blocks are required to follow the payload block and it is NOT RECOMMENDED that they do so.
セキュリティブロックリストをスタックとして説明していますが、ペイロードの後に配置されるためスタックの一部ではないブロックもいくつか存在します。BundleAuthentication暗号スイート#1（「BA1」）は、security-resultを保持するために2番目の相関ブロックを必要とし、このブロックはペイロードの後、通常はバンドルの最後のブロックとして配置されます。それらの「所有者」または「親」ブロックがスタックにプッシュされると同時にバンドルの末尾に追加されることを指定することにより、これらのブロックにもスタックルールを適用できます。実際、それらはペイロードから始まりますが反対方向に成長するスタックを形成します。また、メインスタック内のすべてのブロックが末尾スタックに対応するエントリを持つわけではありません。ペイロードの後に続かなければならない (MUST) 唯一のブロックは、security-resultを保持するための相関ブロックとして暗号スイートによって義務付けられているブロックです。ペイロードブロックの後に続くことが要求される他のブロックはなく、そのようにすることは推奨されません (NOT RECOMMENDED)。
ESBs are effectively placeholders for the blocks they encapsulate and, since those do not form part of the processing sequence described above, ESBs themselves do not either. ESBs MAY be correlated, however, so the "no reordering" requirement applies to them as well.
ESBはカプセル化するブロックの事実上のプレースホルダーであり、それらは上記で説明した処理シーケンスの一部を形成しないため、ESB自体も形成しません。ただし、ESBは相関付けられてもよいため (MAY)、「並べ替え不可」の要件はそれらにも同様に適用されます。
Each security block has a security path, as described in the discussion for Figure 1, and the paths for various blocks are often different.
図1の説明で説明されているように、各セキュリティブロックにはセキュリティパスがあり、さまざまなブロックのパスはしばしば異なります。
BABs are always for a single hop, and these restricted paths never cause conflict.
バブは常に1回のホップにあり、これらの制限されたパスは紛争を引き起こすことはありません。
The paths for PIBs and PCBs are often from bundle-source to bundle-destination, to provide end-to-end protection. A bundle-source-to-bundle-destination path likewise never causes a problem.
PIBとPCBのパスは、エンドツーエンドの保護を提供するために、多くの場合、バンドルソースからバンドスティーンまでのものです。同様に、バンドルソースからバンドルへの捨てパスが問題を引き起こすことはありません。
Another common scenario is for gateway-to-gateway protection of traffic between two sub-networks ("tunnel-mode").
もう1つの一般的なシナリオは、2つのサブネットワーク（「トンネルモード」）間のトラフィックのゲートウェイからゲートウェイへの保護です。
Looking at Figure 1 and the simplified version shown in Figure 4, we can regard BN2 and BN3 as gateways connecting the two sub-networks labeled "An internet". As long as they provide security for the BN2- BN3 path, all is well. Problems begin, for example, when BN2 adds blocks with BN4 as the security-destination, and the originating node BN1 has created blocks with BN3 as security-destination. We now have two paths, and neither is a subset of the other.
図1と図4に示す単純化されたバージョンを見ると、「インターネット」とラベル付けされた2つのサブネットワークを接続するゲートウェイと見なすことができます。BN2-BN3パスのセキュリティを提供する限り、すべてが順調です。問題は、たとえば、BN2がセキュリティ境界としてBN4を持つブロックを追加すると、セキュリティ境界としてBN3を使用してブロックを作成したときに発生します。現在、2つのパスがあり、どちらも他のパスのサブセットではありません。
This scenario should be prevented by node BN2's security policy being aware of the already existing block with BN3 as the security-destination. This policy SHOULD NOT specify a security-destination that is further distant than any existing security-destination.
このシナリオは、ノードBN2のセキュリティポリシーが、セキュリティ宛先としてBN3を持つ既存のブロックを認識していることによって防止されるべきです。このポリシーは、既存のセキュリティ宛先よりも遠いセキュリティ宛先を指定すべきではありません (SHOULD NOT)。
+---------v-| +->>>>>>>>>>v-+ +->>>>>>>>>>v-+ +-^---------+
| BN1 v | | ^ BN2 v | | ^ BN3 v | | ^ BN4 |
+---------v-+ +-^---------v-+ +-^---------v-+ +-^---------+
>>>>>>>>^ >>>>>>>>>>^ >>>>>>>>^
<------------- BN1 to BN3 path ------------>
<------------- BN2 to BN4 path ------------>
Figure 4: Overlapping Security Paths
図4：セキュリティパスの重複
Consider the case where the security concern is for data integrity, so the blocks are PIBs. BN1 creates one ("PIa") along with the new bundle, and BN2 pushes its own PIB "PIb" on the stack, with security-destination BN4. When this bundle arrives at BN3, the bundle blocks are
セキュリティの懸念がデータの整合性に関する場合を考慮して、ブロックがPIBになるようにしてください。BN1は新しいバンドルとともに1つ（「PIA」）を作成し、BN2はセキュリティ境界BN4を使用して、スタックに独自のPIB「PIB」を押します。このバンドルがBN3に到着すると、バンドルブロックは
primary - PIb - PIa - payload
Block PIb is not destined for this node BN3, so it has to be forwarded. This is the security-destination for block PIa so, after validation, it should be removed from the bundle; however, that will invalidate the PIb signature when the block is checked at the final destination. The PIb signature includes the primary block, PIb itself, PIa and the payload block, so PIa MUST remain in the bundle. This is why security blocks are treated as a stack and add/remove operations are permitted only at the top-of-stack.
ブロックPIbはこのノードBN3宛てではないため、転送される必要があります。ここがブロックPIaのセキュリティ宛先であるため、検証後にバンドルから削除されるべきです。しかし、そうすると最終宛先でブロックがチェックされるときにPIbの署名が無効になります。PIbの署名にはプライマリブロック、PIb自体、PIa、およびペイロードブロックが含まれるため、PIaはバンドル内に残らなければなりません (MUST)。これが、セキュリティブロックがスタックとして扱われ、追加/削除操作がスタックトップでのみ許可される理由です。
The situation would be worse if the security concern is confidentiality, and PCBs are employed, using the confidentiality ciphersuite #3 ("PC3") described in Section 4.3. In this scenario, BN1 would encrypt the bundle with BN3 as security-destination, BN2 would create an overlapping security path by super-encrypting the payload and encapsulating the PC3 block for security-destination BN4. BN3 forwards all the blocks without change. BN4 decrypts the payload from its super-encryption and decapsulates the PC3 block, only to find that it should have been processed earlier. Assuming that BN4 has no access to BN3's key store, BN4 has no way to decrypt the bundle and recover the original content.
セキュリティの懸念が機密性があり、PCBがセクション4.3で説明されている機密性ciphersuite＃3（ "PC3"）を使用してPCBを採用している場合、状況は悪化します。このシナリオでは、BN1はセキュリティ脱出としてBN3を使用してバンドルを暗号化し、BN2はペイロードをスーパー暗号化し、セキュリティ脱出BN4のPC3ブロックをカプセル化することにより、重複するセキュリティパスを作成します。BN3は、すべてのブロックを変更せずに転送します。BN4は、スーパーエクサイプからペイロードを復号化し、PC3ブロックを脱カプセル化しますが、以前に処理されるべきであることがわかります。BN4がBN3のキーストアにアクセスできないと仮定すると、BN4にはバンドルを復号化して元のコンテンツを回復する方法がありません。
As mentioned above, authors of security policy need to use care to ensure that their policies do not cause overlaps. These guidelines should prove helpful.
上記のように、セキュリティポリシーの著者は、ポリシーが重複を引き起こさないようにケアを使用する必要があります。これらのガイドラインは役立つはずです。
The originator of a bundle can always specify the bundle-destination as the security-destination and should be cautious about doing otherwise.
バンドルの創始者は、常にセキュリティ境界としてバンドスティーンを指定することができ、そうでないことに注意する必要があります。
In the "tunnel-mode" scenario where two sub-networks are connected by a tunnel through a network, the gateways can each specify the other as security-destination and should be cautious about doing otherwise.
2つのサブネットワークがネットワークを介してトンネルで接続されている「トンネルモード」シナリオでは、ゲートウェイはそれぞれをセキュリティ境界として指定し、そうでないことに注意する必要があります。
BAB is never a problem because it is always only a single hop.
バブは常に単一のホップにすぎないため、決して問題ではありません。
PIB for a bundle without PCB will usually specify the bundle-destination as security-destination.
PCBを使用しないバンドル用PIBは、通常、セキュリティ拘束としてバンドル照明を指定します。
PIB for a bundle containing a PCB should specify as its security-destination the security-destination of the PCB (outermost PCB if there are more than one).
PCBを含むバンドル用のPIBは、セキュリティ境界としてPCBのセキュリティ脱出を指定する必要があります（複数の場合、最も外側のPCB）。
In order to verify a signature or MAC on a bundle, the exact same bits, in the exact same order, MUST be input to the calculation upon verification as were input upon initial computation of the original signature or MAC value. Consequently, a node MUST NOT change the encoding of any URI [RFC3986] in the dictionary field, e.g., changing the DNS part of some HTTP URL from lower case to upper case. Because bundles MAY be modified while in transit (either correctly or due to implementation errors), a canonical form of any given bundle (that contains a BAB or PIB) MUST be defined.
バンドル上の署名またはMACを検証するためには、元の署名またはMAC値の初期計算時に入力されたのとまったく同じ順序で、まったく同じビットが検証時の計算に入力されなければなりません (MUST)。したがって、ノードは辞書フィールド内のURI [RFC3986]のエンコーディングを変更してはなりません (MUST NOT) （例えば、あるHTTP URLのDNS部分を小文字から大文字に変更するなど）。バンドルは転送中に（正しく、または実装エラーのために）変更される可能性があるため (MAY)、（BABまたはPIBを含む）任意の特定のバンドルの正規形式を定義しなければなりません (MUST)。
This section defines bundle canonicalization algorithms used in Sections 4.1 and 4.2 ciphersuites. Other ciphersuites can use these or define their own canonicalization procedures.
このセクションでは、セクション4.1および4.2の衝突物で使用されているバンドルCanonicalization Algorithmsを定義します。他のciphersuitesはこれらを使用したり、独自の正規化手順を定義したりできます。
The first algorithm that can be used permits no changes at all to the bundle between the security-source and the security-destination. It is mainly intended for use in BAB ciphersuites. This algorithm conceptually catenates all blocks in the order presented, but omits all security-result data fields in blocks of this ciphersuite type. That is, when a BAB ciphersuite specifies this algorithm, we omit all BAB security-results for all BAB ciphersuites. When a PIB ciphersuite specifies this algorithm, we omit all PIB security-results for all PIB ciphersuites. All security-result length fields are included, even though their corresponding security-result data fields are omitted.
使用できる最初のアルゴリズムでは、セキュリティソースとセキュリティデスティネーションの間のバンドルに変更がまったく許可されません。主にBab Ciphersuitesで使用することを目的としています。このアルゴリズムは、提示された順序ですべてのブロックを概念的に変化させますが、このciphersuiteタイプのブロックですべてのセキュリティ結果データフィールドを省略します。つまり、Bab Ciphersuiteがこのアルゴリズムを指定すると、すべてのBAB CiphersuitesのすべてのBABセキュリティ反応を省略します。PIB ciphersuiteがこのアルゴリズムを指定すると、すべてのPIB ciphersuitesのすべてのPIBセキュリティ反応を省略します。対応するセキュリティ対応データフィールドは省略されていても、すべてのセキュリティ応答の長さフィールドが含まれています。
Notes:
ノート：
o In the above, we specify that security-result data is omitted. This means that no bytes of the security-result data are input. We do not set the security-result length to zero. Rather, we assume that the security-result length will be known to the module that implements the ciphersuite before the security-result is calculated, and require that this value be in the security-result length field even though the security-result data itself will be omitted.
o 上記では、セキュリティ対応データが省略されていることを指定します。これは、セキュリティ結果データのバイトが入力されないことを意味します。セキュリティと結果の長さをゼロに設定しません。むしろ、セキュリティの結果が計算される前に、セキュリティの表現の長さがciphersuiteを実装するモジュールに対して知られていると仮定し、セキュリティ結果データ自体がセキュリティ結果の長さフィールドにあることを要求します省略します。
o The 'res' bit of the ciphersuite ID, which indicates whether or not the security-result length and security-result data field are present, is part of the canonical form.
o セキュリティ結果の長さとセキュリティ対応データフィールドが存在するかどうかを示すCiphersuite IDの「res」ビットは、標準形式の一部です。
o The value of the block data length field, which indicates the length of the block, is also part of the canonical form. Its value indicates the length of the entire bundle when the bundle includes the security-result data field.
o ブロックの長さを示すブロックデータの長さフィールドの値も、標準形式の一部です。その値は、バンドルにセキュリティ対応データフィールドが含まれている場合のバンドル全体の長さを示します。
o BABs are always added to bundles after PIBs, so when a PIB ciphersuite specifies this strict canonicalization algorithm and the PIB is received with a bundle that also includes one or more BABs, application of strict canonicalization as part of the PIB security-result verification process requires that all BABs in the bundle be ignored entirely.
o PIBの後、BABは常にバンドルに追加されます。したがって、PIB暗号化がこの厳格な標準化アルゴリズムを指定すると、PIBが1つ以上のBABを含むバンドルで受信されます。バンドルのすべてのバブが完全に無視されること。
This algorithm is intended to protect parts of the bundle that SHOULD NOT be changed in transit. Hence, it omits the mutable parts of the bundle.
このアルゴリズムは、転送中に変更されるべきではない (SHOULD NOT) バンドルの部分を保護することを目的としています。したがって、バンドルの変更可能な部分を省略します。
The basic approach is to define a canonical form of the primary block and catenate it with the security (PIBs and PCBs only) and payload blocks in the order that they will be transmitted. This algorithm ignores all other blocks, including ESBs, because it cannot be determined whether or not they will change as the bundle transits the network. In short, this canonicalization protects the payload, payload-related security blocks, and parts of the primary block.
基本的なアプローチは、プライマリブロックの標準形式を定義し、セキュリティ（PIBSとPCBのみ）とペイロードブロックを送信する順にカテン化することです。このアルゴリズムは、ESBを含む他のすべてのブロックを無視します。これは、バンドルがネットワークを通過すると変更されるかどうかを決定できないためです。要するに、この標準化は、ペイロード、ペイロード関連のセキュリティブロック、およびプライマリブロックの一部を保護します。
Many fields in various blocks are stored as variable-length SDNVs. These are canonicalized in unpacked form, as eight-byte fixed-width fields in network byte order. The size of eight bytes is chosen because implementations MAY handle larger values as invalid, as noted in [DTNBP].
さまざまなブロック内の多くのフィールドは、可変長のSDNVとして格納されています。これらは、ネットワークバイト順の8バイト固定幅フィールドとして、展開された形式で正規化されます。[DTNBP]で言及されているように、実装はより大きな値を無効として処理してもよいため (MAY)、8バイトのサイズが選択されています。
The canonical form of the primary block is shown in Figure 5. Essentially, it de-references the dictionary block, adjusts lengths where necessary, and ignores flags that MAY change in transit.
プライマリブロックの正規形式を図5に示します。基本的には、辞書ブロックの参照を解決し、必要に応じて長さを調整し、転送中に変更されてもよい (MAY) フラグを無視します。
+----------------+----------------+----------------+----------------+
| Version | Processing flags (incl. COS and SRR) |
+----------------+----------------+---------------------------------+
| Canonical primary block length |
+----------------+----------------+---------------------------------+
| Destination endpoint ID length |
+----------------+----------------+---------------------------------+
| |
| Destination endpoint ID |
| |
+----------------+----------------+---------------------------------+
| Source endpoint ID length |
+----------------+----------------+----------------+----------------+
| |
| Source endpoint ID |
| |
+----------------+----------------+---------------------------------+
| Report-to endpoint ID length |
+----------------+----------------+----------------+----------------+
| |
| Report-to endpoint ID |
| |
+----------------+----------------+----------------+----------------+
| |
+ Creation Timestamp (2 x SDNV) +
| |
+---------------------------------+---------------------------------+
| Lifetime |
+----------------+----------------+----------------+----------------+
Figure 5: The Canonical Form of the Primary Bundle Block
図5：プライマリバンドルブロックの標準形式
The fields shown in Figure 5 are as follows:
図5に示すフィールドは次のとおりです。
The version value is the single-byte value in the primary block.
バージョン値は、プライマリブロックのシングルバイト値です。
The processing flags value in the primary block is an SDNV, and includes the class-of-service (COS) and status report request (SRR) fields. For purposes of canonicalization, the SDNV is unpacked into a fixed-width field, and some bits are masked out. The unpacked field is ANDed with mask 0x0000 0000 0007 C1BE to set to zero all reserved bits and the "bundle is a fragment" bit.
プライマリブロックの処理フラグ値はSDNVであり、Class-of-Service（COS）およびStatus Report Request（SRR）フィールドが含まれます。標準化の目的のために、SDNVは固定幅フィールドに開梱され、一部のビットはマスクされています。未貼りのフィールドは、マスク0x0000 0000 0007 C1BEでAndedであり、予約されたすべてのビットをゼロに設定し、「バンドルはフラグメント」ビットです。
The canonical primary block length value is a four-byte value containing the length (in bytes) of this structure, in network byte order.
標準的なプライマリブロック長い値は、ネットワークバイト順に、この構造の長さ（バイト）を含む4バイト値です。
The destination endpoint ID length and value are the length (as a four-byte value in network byte order) and value of the destination endpoint ID from the primary bundle block. The URI is simply copied from the relevant part(s) of the dictionary block and is not itself canonicalized. Although the dictionary entries contain "null-terminators", the null-terminators are not included in the length or the canonicalization.
宛先エンドポイントIDの長さと値は、プライマリバンドルブロックからの宛先エンドポイントIDの長さ（ネットワークバイトの4バイト値として）と値です。URIは、辞書ブロックの関連部分から単純にコピーされているだけでなく、それ自体が正規化されていません。辞書エントリには「ヌルターミネーター」が含まれていますが、ヌルターミネーターは長さまたは標準化に含まれていません。
The source endpoint ID length and value are handled similarly to the destination.
ソースエンドポイントIDの長さと値は、宛先と同様に処理されます。
The report-to endpoint ID length and value are handled similarly to the destination.
レポートツーエンドポイントIDの長さと値は、宛先と同様に処理されます。
The creation timestamp (2 x SDNV) and lifetime (SDNV) are simply copied from the primary block, with the SDNV values being represented as eight-byte unpacked values.
作成タイムスタンプ（2 x SDNV）とLifetime（SDNV）は、プライマリブロックから単純にコピーされ、SDNV値は8バイトの解放値として表されます。
Fragment offset and total application data unit length are ignored, as is the case for the "bundle is a fragment" bit mentioned above. If the payload data to be canonicalized is less than the complete, original bundle payload, the offset and length are specified in the security-parameters.
フラグメントオフセットと合計アプリケーションデータユニットの長さは無視されます。「バンドルはフラグメントである」ビットの場合と同様に、上記のビットです。標準化されるペイロードデータが完全な元のバンドルペイロードよりも少ない場合、オフセットと長さはセキュリティパラメーターで指定されます。
For non-primary blocks being included in the canonicalization, the block processing control flags value used for canonicalization is the unpacked SDNV value with reserved and mutable bits masked to zero. The unpacked value is ANDed with mask 0x0000 0000 0000 0077 to zero reserved bits and the "last block" flag. The "last block" flag is ignored because BABs and other security blocks MAY be added for some parts of the journey but not others, so the setting of this bit might change from hop to hop.
正規化に含まれる非プライマリブロックの場合、正規化に使用されるブロック処理制御フラグ値は、予約済みビットおよび変更可能ビットが0にマスクされた展開済みSDNV値です。展開された値は、予約済みビットおよび「最終ブロック」フラグを0にするために、マスク0x0000 0000 0000 0077とAND演算されます。「最終ブロック」フラグが無視されるのは、経路の一部にはBABや他のセキュリティブロックが追加されてもよいが (MAY) 他の部分には追加されない場合があり、このビットの設定がホップごとに変化する可能性があるためです。
Endpoint ID references in security blocks are canonicalized using the de-referenced text form in place of the reference pair. The reference count is not included, nor is the length of the endpoint ID text.
セキュリティブロックのエンドポイントID参照は、参照ペアの代わりに再参照されたテキストフォームを使用して正規化されます。参照カウントは含まれておらず、エンドポイントIDテキストの長さも含まれていません。
The block-length is canonicalized as an eight-byte unpacked value in network byte order. If the payload data to be canonicalized is less than the complete, original bundle payload, this field contains the size of the data being canonicalized (the "effective block") rather that the actual size of the block.
ブロック長は、ネットワークバイトの順序で8バイトの解放値として正規化されています。カノニカル化されるペイロードデータが完全な元のバンドルペイロードよりも少ない場合、このフィールドには、ブロックの実際のサイズではなく、正規化されているデータ（「有効ブロック」）のサイズが含まれています。
Payload blocks are generally canonicalized as-is, with the exception that, in some instances, only a portion of the payload data is to be protected. In such a case, only those bytes are included in the canonical form, and additional ciphersuite-parameters are required to specify which part of the payload is protected, as discussed further below.
ペイロードブロックは一般に、そのまま正統化されていますが、場合によっては、場合によってはペイロードデータの一部のみが保護されることを除きます。そのような場合、これらのバイトのみが標準的な形式に含まれており、以下で説明するように、ペイロードのどの部分が保護されているかを指定するには、追加のciphersuite-parametersが必要です。
Security blocks are handled likewise, except that the ciphersuite will likely specify that the "current" security block security-result field not be considered part of the canonical form. This differs from the strict canonicalization case since we might use the mutable canonicalization algorithm to handle sequential signatures such that signatures cover earlier ones.
同様に、セキュリティブロックは処理されますが、Ciphersuiteが「現在の」セキュリティブロックセキュリティ対応フィールドが標準形式の一部とは見なされないことを指定する可能性が高いことを除きます。これは、可変性の標準化アルゴリズムを使用して、シグネチャが以前の署名をカバーするように順次署名を処理する可能性があるため、厳密な標準化の場合とは異なります。
ESBs MUST NOT be included in the canonicalization.
ESBは正規化に含まれてはなりません (MUST NOT)。
Notes:
ノート：
o The canonical form of the bundle is not transmitted. It is simply an artifact used as input to digesting.
o バンドルの標準形式は送信されません。これは、消化するために入力として使用される単なるアーティファクトです。
o We omit the reserved flags because we cannot determine if they will change in transit. The masks specified above will have to be revised if additional flags are defined and they need to be protected.
o 予約されたフラグが転送中に変化するかどうかを判断できないため、省略します。上記のマスクは、追加のフラグが定義され、保護する必要がある場合は改訂する必要があります。
o Our URI encoding does not preserve the null-termination convention from the dictionary field, nor do we separate the scheme and the scheme-specific part (SSP) as is done there.
o 私たちのURIエンコーディングは、辞書フィールドからヌル終了条約を保存するものではなく、スキームとスキーム固有の部分（SSP）をそこにあるように分離することもありません。
o The URI encoding will cause errors if any node rewrites the dictionary content (e.g., changing the DNS part of an HTTP URL from lower case to upper case). This could happen transparently when a bundle is synched to disk using one set of software and then read from disk and forwarded by a second set of software. Because there are no general rules for canonicalizing URIs (or IRIs), this problem may be an unavoidable source of integrity failures.
o URIエンコーディングは、辞書コンテンツを書き換えた場合にuriエンコードが発生します（たとえば、http URLのDNS部分を小文字から大文字に変更するなど）。これは、バンドルが1つのソフトウェアを使用してディスクに同期し、ディスクから読み取り、2番目のソフトウェアセットで転送されると、透過的に発生する可能性があります。標準化URI（またはIRIS）に関する一般的な規則がないため、この問題は避けられない整合性障害の原因である可能性があります。
o All SDNV fields here are canonicalized as eight-byte unpacked values in network byte order. Length fields are canonicalized as four-byte values in network byte order. Encoding does not need optimization since the values are never sent over the network.
o ここのすべてのSDNVフィールドは、ネットワークバイトの順序で8バイトの解放値として標準化されています。長さフィールドは、ネットワークバイトの順序で4バイト値として正規化されます。値がネットワーク上に送信されることはないため、エンコードは最適化を必要としません。
If a bundle is fragmented before the PIB is applied, then the PIB applies to a fragment and not the entire bundle. However, the protected fragment could be subsequently further fragmented, which would leave the verifier unable to know which bytes were protected by the PIB. Even in the absence of fragmentation, the same situation applies if the ciphersuite is defined to allow protection of less than the entire, original bundle payload.
PIBが適用される前にバンドルが断片化されている場合、PIBはバンドル全体ではなくフラグメントに適用されます。ただし、保護されたフラグメントはその後さらに断片化される可能性があり、これにより、どのバイトがPIBによって保護されているかを検証者が知ることができなくなります。フラグメンテーションがない場合でも、ciphersuiteが定義されている場合、同じ状況が適用されます。
For this reason, PIB ciphersuites that support applying a PIB to less than the complete, original bundle payload MUST specify, as part of the ciphersuite-parameters, which bytes of the bundle payload are protected. When verification occurs, only the specified range of the payload bytes are input to PIB verification. It is valid for a ciphersuite to be specified so as to only apply to entire bundles and not to fragments. A ciphersuite MAY be specified to apply to only a portion of the payload, regardless of whether the payload is a fragment or the complete, original bundle payload.
このため、完全な元のバンドルペイロード全体より少ない部分へのPIBの適用をサポートするPIB暗号スイートは、ciphersuite-parametersの一部として、バンドルペイロードのどのバイトが保護されているかを指定しなければなりません (MUST)。検証が行われる際、ペイロードバイトの指定された範囲のみがPIB検証に入力されます。フラグメントには適用されずバンドル全体にのみ適用されるように暗号スイートを指定することは有効です。ペイロードがフラグメントであるか完全な元のバンドルペイロードであるかにかかわらず、ペイロードの一部にのみ適用されるように暗号スイートを指定してもよいです (MAY)。
The same fragmentation issue applies equally to PCB ciphersuites. Ciphersuites that support applying confidentiality to fragments MUST specify, as part of the ciphersuite-parameters, which bytes of the bundle payload are protected. When decrypting a fragment, only the specified bytes are processed. It is also valid for a confidentiality ciphersuite to be specified so as to only apply to entire bundles and not to fragments.
同じフラグメンテーションの問題は、PCB暗号スイートにも等しく適用されます。フラグメントへの機密性の適用をサポートする暗号スイートは、ciphersuite-parametersの一部として、バンドルペイロードのどのバイトが保護されているかを指定しなければなりません (MUST)。フラグメントを復号する際、指定されたバイトのみが処理されます。また、フラグメントには適用されずバンドル全体にのみ適用されるように機密性暗号スイートを指定することも有効です。
This definition of mutable canonicalization assumes that endpoint IDs themselves are immutable and is unsuitable for use in environments where that assumption might be violated.
この可変標準化のこの定義は、エンドポイントID自体が不変であり、その仮定が違反される可能性のある環境での使用には適さないことを前提としています。
The canonicalization applies to a specific bundle and not a specific payload. If a bundle is forwarded in some way, the recipient is not able to verify the original integrity signature since the source EID will be different, and possibly other fields.
標準化は、特定のペイロードではなく、特定のバンドルに適用されます。バンドルが何らかの方法で転送された場合、受信者はソースEIDが異なるため、おそらく他のフィールドになるため、元の整合性署名を検証できません。
The solution for either of these issues is to define and use a PIB ciphersuite having an alternate version of mutable canonicalization any fields from the primary block.
これらの問題のいずれかの解決策は、プライマリブロックからの可変カノニカル化任意のフィールドの代替バージョンを持つPIB ciphersuiteを定義および使用することです。
Every bundle MUST contain a primary block that contains the source and destination endpoint IDs, and possibly other EIDs (in the dictionary field), and that cannot be encrypted. If endpoint ID confidentiality is required, then bundle-in-bundle encapsulation can solve this problem in some instances.
すべてのバンドルは、送信元および宛先エンドポイントID、および場合によっては他のEID（辞書フィールド内）を含み、暗号化できないプライマリブロックを含まなければなりません (MUST)。エンドポイントIDの機密性が必要な場合、バンドルインバンドル（bundle-in-bundle）カプセル化によって一部のインスタンスでこの問題を解決できます。
Similarly, confidentiality requirements MAY also apply to other parts of the primary block (e.g., the current-custodian), and that is supported in the same manner.
同様に、機密性要件はプライマリブロックの他の部分（例えばcurrent-custodian）にも適用されてもよく (MAY)、同じ方法でサポートされます。
Nodes implementing this specification SHALL consult their security policy to determine whether or not a received bundle is required by policy to include a BAB. If the bundle has no BAB, and one is not required, then BAB processing on the received bundle is complete, and the bundle is ready to be further processed for PIB/PCB/ESB handling or delivery or forwarding.
本文書を実装するノードは、受信したバンドルにBABを含めることがポリシーによって要求されているかどうかを判断するために、自らのセキュリティポリシーを参照しなければなりません (SHALL)。バンドルにBABがなく、BABが要求されていない場合、受信したバンドルに対するBAB処理は完了し、バンドルはPIB/PCB/ESBの処理、配信、または転送のためにさらに処理される準備が整います。
If the bundle is required to have a BAB but does not, then the bundle MUST be discarded and processed no further. If the bundle is required to have a BAB but all of its BABs identify a node other than the receiving node as the BAB security-destination, then the bundle MUST be discarded and processed no further.
バンドルがBABを持つことが要求されているにもかかわらず持っていない場合、そのバンドルは破棄されなければならず (MUST)、それ以上処理されてはなりません。バンドルがBABを持つことが要求されているが、そのすべてのBABが受信ノード以外のノードをBABセキュリティ宛先として識別している場合、そのバンドルは破棄されなければならず (MUST)、それ以上処理されてはなりません。
If the bundle is required to have a BAB, and has one or more BABs that identify the receiving node as the BAB security-destination, or for which there is no security-destination, then the value in the security-result field(s) of the BAB(s) MUST be verified according to the ciphersuite specification. If, for all such BABs in the bundle, either the BAB security source cannot be determined or the security-result value check fails, the bundle has failed to authenticate, and the bundle MUST be discarded and processed no further. If any of the BABs present verify, or if a BAB is not required, the bundle is ready for further processing as determined by extension blocks and/or policy.
バンドルがBABを持つことが要求されており、受信ノードをBABセキュリティ宛先として識別する1つ以上のBABがある場合、またはセキュリティ宛先がないBABがある場合、BABのsecurity-resultフィールドの値は暗号スイート仕様に従って検証されなければなりません (MUST)。バンドル内のそのようなすべてのBABについて、BABセキュリティソースを特定できないか、security-result値のチェックが失敗した場合、バンドルの認証は失敗したことになり、そのバンドルは破棄されなければならず (MUST)、それ以上処理されてはなりません。存在するいずれかのBABが検証に成功した場合、またはBABが要求されていない場合、バンドルは拡張ブロックおよび/またはポリシーによって決定されるさらなる処理の準備が整います。
BABs received in a bundle MUST be stripped before the bundle is forwarded. New BABs MAY be added as required by policy. This MAY require correcting the "last block" field of the to-be-forwarded bundle.
バンドル内で受信されたBABは、バンドルが転送される前に削除されなければなりません (MUST)。ポリシーで要求される場合、新しいBABが追加されてもよいです (MAY)。これにより、転送されるバンドルの「最終ブロック」フィールドの修正が必要になる場合があります (MAY)。
Further processing of the bundle MUST take place in the order indicated by the various blocks from the primary block to the payload block, except as defined by an applicable specification.
バンドルのさらなる処理は、適用される仕様で定義されている場合を除き、プライマリブロックからペイロードブロックまでのさまざまなブロックによって示される順序で行われなければなりません (MUST)。
If the bundle has a PCB and the receiving node is the PCB-destination for the bundle (either because the node is listed as the bundle's PCB-destination or because the node is listed as the bundle-destination and there is no PCB-dest), the node MUST decrypt the relevant parts of the bundle in accordance with the ciphersuite specification. The PCB SHALL be deleted. If the relevant parts of the bundle cannot be decrypted (i.e., the decryption key cannot be deduced or decryption fails), then the bundle MUST be discarded and processed no further; in this case, a bundle deletion status report (see the Bundle Protocol Specification [DTNBP]) indicating the decryption failure MAY be generated. If the PCB security-result included the ciphertext of a block other than the payload block, the recovered plaintext block MUST be placed in the bundle at the location from which the PCB was deleted.
バンドルにPCBがあり、受信ノードがそのバンドルのPCB宛先である場合（ノードがバンドルのPCB宛先としてリストされているか、またはノードがバンドル宛先としてリストされておりPCB宛先が存在しないため）、ノードは暗号スイート仕様に従ってバンドルの関連部分を復号しなければなりません (MUST)。PCBは削除されなければなりません (SHALL)。バンドルの関連部分を復号できない場合（すなわち復号鍵を導出できないか復号に失敗した場合）、バンドルは破棄されなければならず (MUST)、それ以上処理されてはなりません。この場合、復号の失敗を示すバンドル削除ステータスレポート（Bundle Protocol仕様[DTNBP]を参照）が生成されてもよいです (MAY)。PCBのsecurity-resultにペイロードブロック以外のブロックの暗号文が含まれていた場合、復元された平文ブロックは、PCBが削除された場所でバンドル内に配置されなければなりません (MUST)。
If the bundle has one or more PIBs for which the receiving node is the bundle's PIB-destination (either because the node is listed in the bundle's PIB-destination or because the node is listed as the bundle-destination and there is no PIB-dest), the node MUST verify the value in the PIB security-result field(s) in accordance with the ciphersuite specification. If all the checks fail, the bundle has failed to authenticate and the bundle SHALL be processed according to the security policy. A bundle status report indicating the failure MAY be generated. Otherwise, if the PIB verifies, the bundle is ready to be processed for either delivery or forwarding. Before forwarding the bundle, the node SHOULD remove the PIB from the bundle, subject to the requirements of Section 3.2, unless it is likely that some downstream node will also be able to verify the PIB.
受信ノードがバンドルのPIB宛先である1つ以上のPIBがバンドルにある場合（ノードがバンドルのPIB宛先にリストされているか、またはノードがバンドル宛先としてリストされておりPIB宛先が存在しないため）、ノードは暗号スイート仕様に従ってPIBのsecurity-resultフィールドの値を検証しなければなりません (MUST)。すべてのチェックが失敗した場合、バンドルは認証に失敗したことになり、バンドルはセキュリティポリシーに従って処理されなければなりません (SHALL)。失敗を示すバンドルステータスレポートが生成されてもよいです (MAY)。そうではなくPIBが検証された場合、バンドルは配信または転送のいずれかの処理を行う準備が整います。下流のノードもPIBを検証できる可能性が高い場合を除き、バンドルを転送する前に、ノードはセクション3.2の要件に従ってバンドルからPIBを削除すべきです (SHOULD)。
If the bundle has a PIB and the receiving node is not the bundle's PIB-dest, the receiving node MAY attempt to verify the value in the security-result field. If it is able to check and the check fails, the node SHALL discard the bundle and it MAY send a bundle status report indicating the failure.
バンドルにPIBがあり、受信ノードがバンドルのPIB宛先でない場合、受信ノードはsecurity-resultフィールドの値の検証を試みてもよいです (MAY)。チェックを実行でき、そのチェックが失敗した場合、ノードはバンドルを破棄しなければならず (SHALL)、障害を示すバンドルステータスレポートを送信してもよいです (MAY)。
If the bundle has an ESB and the receiving node is the ESB-destination for the bundle (either because the node is listed as the bundle's ESB-destination or because the node is listed as the bundle-destination and there is no ESB-destination), the node MUST decrypt and/or decapsulate the encapsulated block in accordance with the ciphersuite specification. The decapsulated block replaces the ESB in the bundle block sequence, and the ESB is thereby deleted. If the content cannot be decrypted (i.e., the decryption key cannot be deduced or decryption fails), then the bundle MAY be discarded and processed no further unless the security policy specifies otherwise. In this case, a bundle deletion status report (see the Bundle Protocol Specification [DTNBP]) indicating the decryption failure MAY be generated.
バンドルにESBがあり、受信ノードがバンドルのESB宛先である場合（ノードがバンドルのESB宛先としてリストされているか、またはノードがバンドル宛先としてリストされておりESB宛先が存在しないため）、ノードは暗号スイート仕様に従ってカプセル化されたブロックを復号および/またはカプセル解除しなければなりません (MUST)。カプセル解除されたブロックはバンドルブロックシーケンス内のESBを置き換え、それによりESBは削除されます。コンテンツを復号できない場合（すなわち復号鍵を導出できないか復号に失敗した場合）、セキュリティポリシーに別段の指定がない限り、バンドルは破棄され、それ以上処理されなくてもよいです (MAY)。この場合、復号の失敗を示すバンドル削除ステータスレポート（Bundle Protocol仕様[DTNBP]を参照）が生成されてもよいです (MAY)。
An application MAY request (in an implementation-specific manner) that a node be registered as a member of an endpoint and that received bundles destined for that endpoint be delivered to that application.
アプリケーションは、（実装固有の方法で）ノードがエンドポイントのメンバーとして登録され、そのエンドポイント宛てに受信されたバンドルがそのアプリケーションに配信されることを要求してもよいです (MAY)。
An option for use in such cases is known as "at-most-once-delivery". If this option is chosen, the application indicates that it wants the node to check for duplicate bundles, discard duplicates, and deliver at most one copy of each received bundle to the application. If this option is not chosen, the application indicates that it wants the node to deliver all received bundle copies to the application. If this option is chosen, the node SHALL deliver at most one copy of each received bundle to the application. If the option is not chosen, the node SHOULD, subject to policy, deliver all bundles.
このような場合に使用されるオプションは「最大1回配信（at-most-once-delivery）」として知られています。このオプションが選択された場合、アプリケーションは、ノードが重複バンドルをチェックし、重複を破棄し、受信した各バンドルの最大1個のコピーをアプリケーションに配信することを望んでいることを示します。このオプションが選択されない場合、アプリケーションは、ノードがすべての受信バンドルコピーをアプリケーションに配信することを望んでいることを示します。このオプションが選択された場合、ノードは受信した各バンドルの最大1個のコピーをアプリケーションに配信しなければなりません (SHALL)。このオプションが選択されない場合、ノードはポリシーに従ってすべてのバンドルを配信すべきです (SHOULD)。
To enforce this, the node MUST look at the source/timestamp pair value of each complete (reassembled, if necessary) bundle received and determine if this pair, which uniquely identifies a bundle, has been previously received. If it has, then the bundle is a duplicate. If it has not, then the bundle is not a duplicate. The source/ timestamp pair SHALL be added to the list of pair values already received by that node.
これを強制するために、ノードは受信した完全な（必要に応じて再組み立てされた）各バンドルの送信元/タイムスタンプのペア値を調べ、バンドルを一意に識別するこのペアが以前に受信されたかどうかを判断しなければなりません (MUST)。受信されていた場合、そのバンドルは重複です。受信されていなかった場合、そのバンドルは重複ではありません。送信元/タイムスタンプのペアは、そのノードによってすでに受信されたペア値のリストに追加されなければなりません (SHALL)。
Each node implementation MAY decide how long to maintain a table of pair value state.
各ノードの実装は、ペア値の状態のテーブルをどのくらいの期間維持するかを決定してもよいです (MAY)。
If it is necessary for a node to fragment a bundle and security services have been applied to that bundle, the fragmentation rules described in [DTNBP] MUST be followed. As defined there and repeated here for completeness, only the payload MAY be fragmented; security blocks, like all extension blocks, can never be fragmented. In addition, the following security-specific processing is REQUIRED:
ノードがバンドルを断片化する必要があり、そのバンドルにセキュリティサービスが適用されている場合、[DTNBP]で説明されている断片化規則に従わなければなりません (MUST)。そこで定義され、完全性のためにここで繰り返されているように、ペイロードのみが断片化されてもよく (MAY)、すべての拡張ブロックと同様にセキュリティブロックは決して断片化できません。さらに、以下のセキュリティ固有の処理が要求されます (REQUIRED)。
The security policy requirements for a bundle MUST be applied individually to all the bundles resulting from a fragmentation event.
バンドルのセキュリティポリシー要件は、断片化イベントから生じるすべてのバンドルに個別に適用されなければなりません (MUST)。
If the original bundle contained a PIB, then each of the PIB instances MUST be included in some fragment.
元のバンドルにPIBが含まれていた場合、各PIBインスタンスはあるフラグメントに含まれなければなりません (MUST)。
If the original bundle contained one or more PCBs, then any PCB instances containing a key-information item MUST have the "replicate in every fragment" flag set, and thereby be replicated in every fragment. This is to ensure that the canonical block-sequence can be recovered during reassembly.
元のバンドルに1つ以上のPCBが含まれていた場合、鍵情報項目を含むすべてのPCBインスタンスは「すべてのフラグメントに複製」フラグが設定されていなければならず (MUST)、それによってすべてのフラグメントで複製されなければなりません。これは、再組み立て中に正規のブロックシーケンスを復元できるようにするためです。
If the original bundle contained one or more correlated PCBs not containing a key-information item, then each of these MUST be included in some fragment, but SHOULD NOT be sent more than once. They MUST be placed in a fragment in accordance with the fragmentation rules described in [DTNBP].
元のバンドルに鍵情報項目を含まない1つ以上の相関PCBが含まれていた場合、これらの各々は特定のフラグメントに含まれなければなりません (MUST) が、複数回送信されるべきではありません (SHOULD NOT)。それらは[DTNBP]で説明されている断片化規則に従ってフラグメント内に配置されなければなりません (MUST)。
Note: various fragments MAY have additional security blocks added at this or later stages, and it is possible that correlators will collide. In order to facilitate uniqueness, ciphersuites SHOULD include the fragment-offset of the fragment as a high-order component of the correlator.
注: さまざまなフラグメントにおいて、この段階または後の段階で追加のセキュリティブロックが追加されてもよく (MAY)、correlatorが衝突する可能性があります。一意性を促進するために、暗号スイートはcorrelatorの上位コンポーネントとしてフラグメントのfragment-offsetを含めるべきです (SHOULD)。
When a partial bundle has been received, the receiving node SHALL consult its security policy to determine if it MAY fragment the bundle, converting the received portion into a bundle fragment for further forwarding. Whether or not reactive fragmentation is permitted SHALL depend on the security policy and the ciphersuite used to calculate the BAB authentication information, if required. (Some BAB ciphersuites, i.e., the mandatory BAB-HMAC (Hashed Message Authentication Code) ciphersuite defined in Section 4.1, do not accommodate reactive fragmentation because the security-result in the BAB requires that the entire bundle be signed. It is conceivable, however, that a BAB ciphersuite could be defined such that multiple security-results are calculated, each on a different segment of a bundle, and that these security-results could be interspersed between bundle payload segments such that reactive fragmentation could be accommodated.)
部分的なバンドルが受信されたとき、受信ノードはセキュリティポリシーを参照して、バンドルを断片化し、受信した部分をさらなる転送のためにバンドルフラグメントに変換してもよいか (MAY) を決定しなければなりません (SHALL)。リアクティブフラグメンテーションが許可されるかどうかは、セキュリティポリシーおよび（必要な場合に）BAB認証情報の計算に使用された暗号スイートに依存しなければなりません (SHALL)。（一部のBAB暗号スイート、すなわちセクション4.1で定義されている必須のBAB-HMAC（Hashed Message Authentication Code）暗号スイートは、BAB内のsecurity-resultがバンドル全体に署名されることを要求するため、リアクティブフラグメンテーションに対応しません。しかしながら、バンドルの異なるセグメントごとに複数のsecurity-resultが計算され、リアクティブフラグメンテーションに対応できるようにこれら複数のsecurity-resultがバンドルペイロードセグメントの間に散りばめられるようなBAB暗号スイートを定義することは考えられます。）
If the bundle is reactively fragmented by the intermediate receiver and the BAB-ciphersuite is of an appropriate type (e.g., with multiple security-results embedded in the payload), the bundle MUST be fragmented immediately after the last security-result value in the partial payload that is received. Any data received after the last security-result value MUST be dropped.
バンドルが中間受信者によってリアクティブに断片化され、BAB暗号スイートが適切なタイプである場合（例えばペイロード内に複数のsecurity-resultが埋め込まれている場合）、バンドルは受信された部分ペイロード内の最後のsecurity-result値の直後で断片化されなければなりません (MUST)。最後のsecurity-result値の後に受信されたデータはすべて破棄されなければなりません (MUST)。
If a partial bundle is received at the intermediate receiver and is reactively fragmented and forwarded, only the part of the bundle that was not received MUST be retransmitted, though more of the bundle MAY be retransmitted. Before retransmitting a portion of the bundle, it SHALL be changed into a fragment and, if the original bundle included a BAB, the fragmented bundle MUST also, and its BAB SHALL be recalculated.
中間受信者で部分的なバンドルが受信され、リアクティブに断片化されて転送される場合、受信されなかったバンドルの部分のみが再送信されなければなりません (MUST) が、バンドルのより多くの部分が再送信されてもよいです (MAY)。バンドルの一部を再送信する前に、それはフラグメントに変更されなければならず (SHALL)、元のバンドルにBABが含まれていた場合は断片化されたバンドルにもBABが含まれなければならず (MUST)、そのBABは再計算されなければなりません (SHALL)。
This specification does not define any ciphersuite that can handle this reactive fragmentation case.
この仕様では、この反応性断片化ケースを処理できる暗号外観を定義しません。
An interesting possibility is a ciphersuite definition such that the transmission of a follow-up fragment would be accompanied by the signature for the payload up to the restart point.
興味深い可能性は、フォローアップフラグメントの送信に、再起動ポイントまでのペイロードの署名が伴うように、ciphersuiteの定義です。
An evaluation of resilience to cryptographic attack necessarily depends upon the algorithms chosen for bulk data protection and for key transport. The mandatory ciphersuites described in the following section use AES, RSA, and SHA algorithms in ways that are believed to be reasonably secure against ciphertext-only, chosen-ciphertext, known-plaintext, and chosen-plaintext attacks.
暗号化攻撃に対する回復力の評価は、必然的に、バルクデータ保護と鍵輸送に選択されたアルゴリズムに依存します。次のセクションで説明されている必須のciphersuitesは、ciphertextのみ、選択されたciphertext、既知のプレーンテキスト、および選択されたプラントテキスト攻撃に対して合理的に安全であると考えられている方法で、AE、RSA、およびSHAアルゴリズムを使用します。
The design has carefully preserved the resilience of the algorithms against attack. For example, if a message is encrypted, then any message integrity signature is also encrypted so that guesses cannot be confirmed.
このデザインは、攻撃に対するアルゴリズムの回復力を慎重に保存しています。たとえば、メッセージが暗号化されている場合、メッセージの整合性署名も暗号化されているため、推測を確認できません。
This section defines the mandatory ciphersuites for this specification. There is currently one mandatory ciphersuite for use with each of the security block types BAB, PIB, PCB, and ESB. The BAB ciphersuite is based on shared secrets using HMAC. The PIB ciphersuite is based on digital signatures using RSA with SHA-256. The PCB and ESB ciphersuites are based on using RSA for key transport and AES for bulk encryption.
このセクションでは、この仕様のための必須のciphersuitesを定義します。現在、それぞれのセキュリティブロックタイプBAB、PIB、PCB、およびESBで使用するための必須のCiphersuiteが1つあります。Bab Ciphersuiteは、HMACを使用した共有秘密に基づいています。PIB Ciphersuiteは、SHA-256を使用したRSAを使用したデジタル署名に基づいています。PCBおよびESBのciphersuitesは、キートランスポートにRSAを使用し、バルク暗号化にAESを使用することに基づいています。
In all uses of CMS eContent in this specification, the relevant eContentType to be used is id-data as specified in [RFC5652].
この仕様のCMSエコネントのすべての使用において、使用される関連するeContentTypeは[RFC5652]で指定されているID-DATAです。
The ciphersuites use the mechanisms defined in Cryptographic Message Syntax (CMS) [RFC5652] for packaging the keys, signatures, etc., for transport in the appropriate security block. The data in the CMS object is not the bundle data, as would be the typical usage for CMS. Rather, the "message data" packaged by CMS is the ephemeral key, message digest, etc., used in the core code of the ciphersuite.
Ciphersuitesは、適切なセキュリティブロックでの輸送に、キー、署名などをパッケージ化するために、暗号メッセージ構文（CMS）[RFC5652]で定義されているメカニズムを使用します。CMSオブジェクトのデータは、CMSの典型的な使用法と同様に、バンドルデータではありません。むしろ、CMSによってパッケージ化された「メッセージデータ」は、Ciphersuiteのコアコードで使用されるはかないキー、メッセージダイジェストなどです。
In all cases where we use CMS, implementations SHOULD NOT include additional attributes whether signed or unsigned, authenticated or unauthenticated.
CMSを使用するすべての場合において、実装は、署名付きか非署名か、認証済みか未認証かにかかわらず、追加の属性を含めるべきではありません (SHOULD NOT)。
The BAB-HMAC ciphersuite has ciphersuite ID value 0x001.
Bab-Hmac ciphersuiteには、ciphersuite id value 0x001があります。
BAB-HMAC uses the strict canonicalization algorithm in Section 3.4.1.
BAB-HMACは、セクション3.4.1で厳密な標準化アルゴリズムを使用しています。
Strict canonicalization supports digesting of a fragment-bundle. It does not permit the digesting of only a subset of the payload, but only the complete contents of the payload of the current bundle, which might be a fragment. The fragment-range item for security-parameters is not used to indicate a fragment, as this information is digested within the primary block.
厳密な標準化は、フラグメントバンドルの消化をサポートします。ペイロードのサブセットのみの消化は許可されませんが、現在のバンドルのペイロードの完全な内容のみがフラグメントである可能性があります。この情報はプライマリブロック内で消化されるため、セキュリティパラメーター用のフラグメント範囲のアイテムはフラグメントを示すために使用されません。
The variant of HMAC to be used is HMAC-SHA1 as defined in [RFC2104].
使用するHMACのバリアントは、[RFC2104]で定義されているHMAC-Sha1です。
This ciphersuite requires the use of two related instances of the BAB. It involves placing the first BAB instance (as defined in Section 2.2) just after the primary block. The second (correlated) instance of the BAB MUST be placed after all other blocks (except possibly other BAB blocks) in the bundle.
この暗号スイートは、BABの2つの関連するインスタンスの使用を要求します。これには、プライマリブロックの直後に（セクション2.2で定義されている）第1のBABインスタンスを配置することが含まれます。BABの第2の（相関）インスタンスは、バンドル内の他のすべてのブロック（おそらく他のBABブロックを除く）の後に配置されなければなりません (MUST)。
This means that, normally, the BAB will be the second and last blocks of the bundle. If a forwarder wishes to apply more than one correlated BAB pair, then this can be done. There is no requirement that each application "wrap" the others, but the forwarder MUST insert all the "up front" BABs, and their "at back" "partners" (without any security-result), before canonicalizing.
これは、通常、BABがバンドルの2番目と最後のブロックになることを意味します。転送者が複数の相関BABペアを適用することを希望する場合、これを行うことができます。各適用が他方を「ラップ」するという要件はありませんが、転送者は、正規化する前に、すべての「前方」BABおよびその「後方」「パートナー」（security-resultなし）を挿入しなければなりません (MUST)。
Inserting more than one correlated BAB pair would be useful if the bundle could be routed to more than one potential "next hop" or if both an old and a new key were valid at sending time, with no certainty about the situation that will obtain at reception time.
複数の相関したBABペアを挿入することは、バンドルを複数の潜在的な「次のホップ」にルーティングできる場合、または古いキーと新しいキーの両方が送信時に有効であった場合に有用です。受信時間。
The security-result is the output of the HMAC-SHA1 calculation with the input being the result of running the entire bundle through the strict canonicalization algorithm. Both required BAB instances MUST be included in the bundle before canonicalization.
security-resultは、バンドル全体を厳密な正規化アルゴリズムに通した結果を入力とするHMAC-SHA1計算の出力です。要求される両方のBABインスタンスは、正規化の前にバンドルに含まれなければなりません (MUST)。
Security-parameters are OPTIONAL with this scheme, but if used, then the only field that can be present is key-information (see Section 2.6).
このスキームにおいてsecurity-parametersは任意ですが (OPTIONAL)、使用される場合、存在できる唯一のフィールドは鍵情報です（セクション2.6を参照）。
In the absence of key-information, the receiver is expected to be able to find the correct key based on the sending identity. The sending identity MAY be known from the security-source field or the content of a previous-hop block in the bundle. It MAY also be determined using implementation-specific means such as the convergence layer.
鍵情報が存在しない場合、受信者は送信側アイデンティティに基づいて正しい鍵を見つけられることが期待されます。送信側アイデンティティは、セキュリティソースフィールドまたはバンドル内のprevious-hopブロックの内容から分かってもよいです (MAY)。また、コンバージェンス層などの実装固有の手段を使用して決定されてもよいです (MAY)。
The PIB-RSA-SHA256 ciphersuite has ciphersuite ID value 0x02.
PIB-RSA-SHA256 CIPHERSUITEには、CipherSuite ID値0x02があります。
PIB-RSA-SHA256 uses the mutable canonicalization algorithm in Section 3.4.2, with the security-result data field for only the "current" block being excluded from the canonical form. The resulting canonical form of the bundle is the input to the signing process. This ciphersuite requires the use of a single instance of the PIB.
PIB-RSA-SHA256は、セクション3.4.2の可変正規化アルゴリズムを使用し、標準形式から除外される「電流」ブロックのみのセキュリティ結果データフィールドを使用します。結果として得られるバンドルの標準形式は、署名プロセスへの入力です。このciphersuiteには、PIBの単一インスタンスを使用する必要があります。
Because the signature field in SignedData SignatureValue is a security-result field, the entire key-information item MUST be placed in the block's security-result field, rather than security-parameters.
SignedData SignatureValue内の署名フィールドはsecurity-resultフィールドであるため、鍵情報項目全体はsecurity-parametersではなくブロックのsecurity-resultフィールドに配置されなければなりません (MUST)。
If the bundle being signed has been fragmented before signing, then we have to specify which bytes were signed in case the signed bundle is subsequently fragmented for a second time. If the bundle is a fragment, then the ciphersuite-parameters MUST include a fragment-range field, as described in Section 2.6, specifying the offset and length of the signed fragment. If the entire bundle is signed, then these numbers MUST be omitted.
署名されるバンドルが署名前に断片化されていた場合、署名されたバンドルがその後2回目の断片化を行われた場合に備えて、どのバイトが署名されたかを指定する必要があります。バンドルがフラグメントである場合、ciphersuite-parametersは、セクション2.6で説明されているように、署名されたフラグメントのオフセットと長さを指定するfragment-rangeフィールドを含まなければなりません (MUST)。バンドル全体が署名されている場合、これらの数値は省略されなければなりません (MUST)。
Implementations MUST support the use of the "SignedData" type as defined in [RFC5652], Section 5.1, with SignerInfo type SignerIdentifier containing the issuer and serial number of a suitable certificate. The data to be signed is the output of the SHA256 mutable canonicalization process.
実装は、[RFC5652]のセクション5.1で定義されている「SignedData」タイプの使用をサポートしなければならず (MUST)、適切な証明書の発行者およびシリアル番号を含むSignerInfoタイプのSignerIdentifierを伴います。署名されるデータは、SHA256変更可能正規化プロセスの出力です。
RSA is used with SHA256 as specified for the id-sha256 signature scheme in [RFC4055], Section 5. The output of the signing process is the SignatureValue field for the PIB.
RSAは、[RFC4055]、セクション5のID-SHA256署名スキームに指定されているSHA256で使用されます。署名プロセスの出力は、PIBの署名値フィールドです。
"Commensurate strength" cryptography is generally held to be a good idea. A combination of RSA with SHA-256 is reckoned to require a 3076-bit RSA key according to this logic. Few implementations will choose this length by default (and probably some just will not support such long keys). Since this is an experimental protocol, we expect that 1024- or 2048-bit RSA keys will be used in many cases, and that this will be fine since we also expect that the hash function "issues" will be resolved before any standard would be derived from this protocol.
「相応の強さ」暗号化は、一般的に良い考えであると考えられています。RSAとSHA-256の組み合わせは、このロジックに従って3076ビットRSAキーを必要とすると考えられています。デフォルトでこの長さを選択する実装はほとんどありません（おそらく、そのような長いキーをサポートしないものもあります）。これは実験的なプロトコルであるため、1024または2048ビットのRSAキーが多くの場合使用され、ハッシュ関数の「問題」が標準になる前に解決されると予想されるため、これは問題ないと予想しています。このプロトコルから導出されました。
The PCB-RSA-AES128-PAYLOAD-PIB-PCB ciphersuite has ciphersuite ID value 0x003.
PCB-RSA-AES128-PAYLOAD-PIB-PCB CIPHERSUITEには、CipherSuite ID値0x003があります。
This scheme encrypts PIBs, PCBs, and the payload. The key size for this ciphersuite is 128 bits.
このスキームは、PIB、PCB、およびペイロードを暗号化します。このCiphersuiteのキーサイズは128ビットです。
Encryption is done using the AES algorithm in Galois/Counter Mode (GCM) as described in [RFC5084]. Note: parts of the following description are borrowed from [RFC4106].
暗号化は、[RFC5084]で説明されているように、Galois/Counter Mode（GCM）のAESアルゴリズムを使用して行われます。注：次の説明の一部は[RFC4106]から借用されています。
The choice of GCM avoids expansion of the payload, which causes problems with fragmentation/reassembly and custody transfer. GCM also includes authentication, essential in preventing attacks that can alter the decrypted plaintext or even recover the encryption key.
GCMの選択により、ペイロードの拡大を回避し、断片化/再組み立てと監護権の移転の問題を引き起こします。GCMには、復号化されたプレーンテキストを変更したり、暗号化キーを回復したりする可能性のある攻撃を防ぐために不可欠な認証も含まれています。
GCM is a block cipher mode of operation providing both confidentiality and data integrity. The GCM encryption operation has four inputs: a secret key, an initialization vector (IV), a plaintext, and an input for additional authenticated data (AAD), which is not used here. It has two outputs, a ciphertext whose length is identical to the plaintext, and an authentication tag, also known as the integrity check value (ICV).
GCMは、機密性とデータの整合性の両方を提供するブロック暗号動作モードです。GCM暗号化操作には、4つの入力があります。シークレットキー、初期化ベクトル（IV）、プレーンテキスト、および追加の認証データ（AAD）の入力（AAD）はここでは使用されません。2つの出力があり、その長さがプレーンテキストと同一の暗号文と、整合性チェック値（ICV）とも呼ばれる認証タグがあります。
For consistency with the description in [RFC5084], we refer to the GCM IV as a nonce. The same key and nonce combination MUST NOT be used more than once. The nonce has the following layout:
[RFC5084]の記述との一貫性のために、GCMのIVをナンス（nonce）と呼びます。同じ鍵とナンスの組み合わせを複数回使用してはなりません (MUST NOT)。ナンスは以下のレイアウトを持ちます:
+----------------+----------------+----------------+----------------+
| salt |
+----------------+----------------+----------------+----------------+
| |
| initialization vector |
| |
+----------------+----------------+----------------+----------------+
Figure 6: Nonce Format for PCB-RSA-AES128-PAYLOAD-PIB-PCB
図6：PCB-RSA-AES128-PAYLOAD-PIB-PCBのNonCe形式
The salt field is a four-octet value, usually chosen at random. It MUST be the same for all PCBs that have the same correlator value. The salt need not be kept secret.
saltフィールドは4オクテットの値であり、通常はランダムに選択されます。これは、同じcorrelator値を持つすべてのPCBで同じでなければなりません (MUST)。ソルトは秘密にしておく必要はありません。
The initialization vector (IV) is an eight-octet value, usually chosen at random. It MUST be different for all PCBs that have the same correlator value. The value need not be kept secret.
初期化ベクトル（IV）は8オクテットの値であり、通常はランダムに選択されます。これは、同じcorrelator値を持つすべてのPCBで異なっていなければなりません (MUST)。この値は秘密にしておく必要はありません。
The key (bundle encryption key, BEK) is a 16-octet (128 bits) value, usually chosen at random. The value MUST be kept secret, as described below.
鍵（バンドル暗号化鍵、BEK）は16オクテット（128ビット）の値であり、通常はランダムに選択されます。以下で説明するように、この値は秘密にしておかなければなりません (MUST)。
The integrity check value is a 16-octet value used to verify that the protected data has not been altered. The value need not be kept secret.
整合性チェック値は、保護されたデータが変更されていないことを確認するために使用される16オクテットの値です。価値を秘密にする必要はありません。
This ciphersuite requires the use of a single PCB instance to deal with payload confidentiality. If the bundle already contains PIBs or PCBs, then the ciphersuite will create additional correlated blocks to protect these PIBs and PCBs. These "additional" blocks replace the original blocks on a one-to-one basis, so the number of blocks remains unchanged. All of these related blocks MUST have the same correlator value. The term "first PCB" in this section refers to the single PCB if there is only one or, if there are several, then to the one containing the key-information. This MUST be the first of the set.
この暗号スイートは、ペイロードの機密性を処理するために単一のPCBインスタンスを使用することを要求します。バンドルにすでにPIBまたはPCBが含まれている場合、暗号スイートはこれらのPIBおよびPCBを保護するために追加の相関ブロックを作成します。これらの「追加の」ブロックは元のブロックを1対1で置き換えるため、ブロック数は変更されません。これらすべての関連ブロックは、同じcorrelator値を持たなければなりません (MUST)。本セクションにおける「第1のPCB」という用語は、PCBが1つしかない場合はその単一のPCBを指し、複数ある場合は鍵情報を含むものを指します。これはセットの最初のものでなければなりません (MUST)。
First PCB - the first PCB MAY contain a correlator value, and MAY specify security-source and/or security-destination in the EID-list. If not specified, the bundle-source and bundle-destination, respectively, are used for these values, as with other ciphersuites. The block MUST contain security-parameters and security-result fields. Each field MAY contain several items formatted as described in Section 2.6.
第1のPCB - 第1のPCBはcorrelator値を含んでもよく (MAY)、EIDリスト内にセキュリティソースおよび/またはセキュリティ宛先を指定してもよいです (MAY)。指定されない場合、他の暗号スイートと同様に、これらの値にはそれぞれバンドル送信元およびバンドル宛先が使用されます。ブロックはsecurity-parametersおよびsecurity-resultフィールドを含まなければなりません (MUST)。各フィールドには、セクション2.6で説明されているようにフォーマットされた複数の項目が含まれてもよいです (MAY)。
Security-parameters
セキュリティパラメーター
key-information
キー情報
salt
塩
IV (this instance applies only to payload)
IV（このインスタンスはペイロードにのみ適用されます）
fragment offset and length, if bundle is a fragment
バンドルがフラグメントの場合、フラグメントオフセットと長さ
Security-result
セキュリティ結果
ICV
ICV
Subsequent PCBs MUST contain a correlator value to link them to the first PCB. Security-source and security-destination are implied from the first PCB; however, see the discussion in Section 2.4 concerning EID-list entries. They MUST contain security-parameters and security-result fields as follows:
後続のPCBは、第1のPCBにリンクするためにcorrelator値を含まなければなりません (MUST)。セキュリティソースおよびセキュリティ宛先は第1のPCBから暗示されますが、EIDリストエントリに関するセクション2.4の議論を参照してください。これらは以下のようにsecurity-parametersおよびsecurity-resultフィールドを含まなければなりません (MUST) :
Security-parameters
セキュリティパラメーター
IV for this specific block
この特定のブロックのIV
Security-result
セキュリティ結果
encapsulated block
カプセル化されたブロック
The security-parameters and security-result fields in the subsequent PCBs MUST NOT contain any items other than these two. Items such as key and salt are supplied in the first PCB and MUST NOT be repeated.
後続のPCB内のsecurity-parametersおよびsecurity-resultフィールドには、これら2つ以外の項目を含めてはなりません (MUST NOT)。鍵やソルトなどの項目は第1のPCBで提供されるため、繰り返してはなりません (MUST NOT)。
Implementations MUST support use of "enveloped-data" type as defined in [RFC5652], Section 6, with RecipientInfo type KeyTransRecipientInfo containing the issuer and serial number of a suitable certificate. They MAY support additional RecipientInfo types. The "encryptedContent" field in EncryptedContentInfo contains the encrypted BEK that protects the payload and certain security blocks of the bundle.
実装は、[RFC5652]のセクション6で定義されている「enveloped-data」タイプの使用をサポートしなければならず (MUST)、適切な証明書の発行者およびシリアル番号を含むRecipientInfoタイプのKeyTransRecipientInfoを伴います。実装は追加のRecipientInfoタイプをサポートしてもよいです (MAY)。EncryptedContentInfo内の「encryptedContent」フィールドには、バンドルのペイロードおよび特定のセキュリティブロックを保護する暗号化されたBEKが含まれます。
The Integrity Check Value from the AES-GCM encryption of the payload is placed in the security-result field of the first PCB.
ペイロードのAES-GCM暗号化からの整合性チェック値は、最初のPCBのセキュリティ対応フィールドに配置されます。
If the bundle being encrypted is a fragment-bundle, we have to specify which bytes are encrypted in case the bundle is subsequently fragmented again. If the bundle is a fragment, the ciphersuite-parameters MUST include a fragment-range field, as described in Section 2.6, specifying the offset and length of the encrypted fragment. Note that this is not the same pair of fields that appear in the primary block as "offset and length". The "length" in this case is the length of the fragment, not the original length. If the bundle is not a fragment, then this field MUST be omitted.
暗号化されるバンドルがフラグメントバンドルである場合、バンドルがその後さらに断片化された場合に備えて、どのバイトが暗号化されているかを指定する必要があります。バンドルがフラグメントである場合、ciphersuite-parametersは、セクション2.6で説明されているように、暗号化されたフラグメントのオフセットと長さを指定するfragment-rangeフィールドを含まなければなりません (MUST)。これは、プライマリブロックに「オフセットおよび長さ」として現れるフィールドのペアとは同じではないことに注意してください。この場合の「長さ」は元の長さではなく、フラグメントの長さです。バンドルがフラグメントでない場合、このフィールドは省略されなければなりません (MUST)。
The confidentiality processing for payload and other blocks is different, mainly because the payload might be fragmented later at some other node.
主にペイロードが他のノードで後で断片化される可能性があるため、ペイロードおよびその他のブロックの機密性処理は異なります。
For the payload, only the bytes of the bundle payload field are affected, being replaced by ciphertext. The salt, IV, and key values specified in the first PCB are used to encrypt the payload, and the resultant authentication tag (ICV) is placed in an ICV item in the security-result field of that first PCB. The other bytes of the payload block, such as type, flags, and length, are not modified.
ペイロードの場合、バンドルペイロードフィールドのバイトのみが影響を受け、暗号文に置き換えられます。最初のPCBで指定された塩、IV、およびキー値は、ペイロードを暗号化するために使用され、結果の認証タグ（ICV）は、その最初のPCBのセキュリティ対応フィールドのICVアイテムに配置されます。タイプ、フラグ、長さなどのペイロードブロックの他のバイトは変更されていません。
For each PIB or PCB to be protected, the entire original block is encapsulated in a "replacing" PCB. This replacing PCB is placed in the outgoing bundle in the same position as the original block, PIB or PCB. As mentioned above, this is one-to-one replacement, and there is no consolidation of blocks or mixing of data in any way.
PIBまたはPCBが保護されるごとに、元のブロック全体が「交換」PCBにカプセル化されています。この交換PCBは、元のブロック、PIB、またはPCBと同じ位置に発信バンドルに配置されます。上記のように、これは1対1の代替品であり、ブロックの統合やデータの混合は何らかの形でありません。
The encryption process uses AES-GCM with the salt and key values from the first PCB, and an IV unique to this PCB. The process creates ciphertext for the entire original block and an authentication tag for validation at the security-destination. For this encapsulation process, unlike the processing of the bundle payload, the authentication tag is appended to the ciphertext for the block, and the combination is stored into the encapsulated block item in the security-result.
暗号化プロセスでは、最初のPCBの塩とキー値を備えたAES-GCM、およびこのPCBに固有のIVを使用します。このプロセスは、元のブロック全体の暗号文と、セキュリティ境界での検証のための認証タグを作成します。このカプセル化プロセスでは、バンドルペイロードの処理とは異なり、認証タグはブロックの暗号文に追加され、組み合わせはセキュリティ対応のカプセル化されたブロックアイテムに保存されます。
The replacing block, of course, also has the same correlator value as the first PCB with which it is associated. It also contains the block-specific IV in security-parameters, and the combination of original-block-ciphertext and authentication tag, stored as an encapsulated block item in the security-result.
もちろん、交換ブロックには、関連する最初のPCBと同じ相関者値もあります。また、セキュリティパラメーターにブロック固有のIVと、セキュリティ対応にカプセル化されたブロックアイテムとして保存されている元のブロックカイフェートテキストと認証タグの組み合わせも含まれています。
If the payload was fragmented after encryption, then all those fragments MUST be present and reassembled before decryption. This process might be repeated several times at different destinations if multiple fragmentation actions have occurred.
暗号化後にペイロードが断片化された場合、復号の前にこれらすべてのフラグメントが存在し、再組み立てされなければなりません (MUST)。複数の断片化アクションが発生した場合、このプロセスは異なる宛先で数回繰り返される可能性があります。
The size of the GCM counter field limits the payload size to 2^39 - 256 bytes, about half a terabyte. A future revision of this specification will address the issue of handling payloads in excess of this size.
GCMカウンターフィールドのサイズは、ペイロードサイズを2^39-256バイト、約半分のテラバイトに制限します。この仕様の将来の改訂は、このサイズを超えるペイロードを処理する問題に対処します。
The ESB-RSA-AES128-EXT ciphersuite has ciphersuite ID value 0x004.
ESB-RSA-AES128-EXT CIPHERSUITEには、CipherSuite ID値0x004があります。
This scheme encrypts non-payload-related blocks. It MUST NOT be used to encrypt PIBs, PCBs, or primary or payload blocks. The key size for this ciphersuite is 128 bits.
このスキームは非ペイロード関連ブロックを暗号化します。PIB、PCB、またはプライマリブロックやペイロードブロックを暗号化するために使用してはなりません (MUST NOT)。この暗号スイートの鍵サイズは128ビットです。
Encryption is done using the AES algorithm in Galois/Counter Mode (GCM) as described in [RFC5084]. Note: parts of the following description are borrowed from [RFC4106].
暗号化は、[RFC5084]で説明されているように、Galois/Counter Mode（GCM）のAESアルゴリズムを使用して行われます。注：次の説明の一部は[RFC4106]から借用されています。
GCM is a block cipher mode of operation providing both confidentiality and data origin authentication. The GCM authenticated encryption operation has four inputs: a secret key, an initialization vector (IV), a plaintext, and an input for additional authenticated data (AAD), which is not used here. It has two outputs, a ciphertext whose length is identical to the plaintext, and an authentication tag, also known as the Integrity Check Value (ICV).
GCMは、機密性とデータ起源認証の両方を提供するブロック暗号操作モードです。GCM認証された暗号化操作には、4つの入力があります。シークレットキー、初期化ベクトル（IV）、プレーンテキスト、および追加の認証データ（AAD）の入力（AAD）はここでは使用されません。2つの出力があり、その長さがプレーンテキストと同一の暗号文と、整合性チェック値（ICV）とも呼ばれる認証タグがあります。
For consistency with the description in [RFC5084], we refer to the GCM IV as a nonce. The same key and nonce combination MUST NOT be used more than once. The nonce has the following layout:
[RFC5084]の記述との一貫性のために、GCMのIVをナンス（nonce）と呼びます。同じ鍵とナンスの組み合わせを複数回使用してはなりません (MUST NOT)。ナンスは以下のレイアウトを持ちます:
+----------------+----------------+---------------------------------+
| salt |
+----------------+----------------+---------------------------------+
| |
| initialization vector |
| |
+----------------+----------------+---------------------------------+
Figure 7: Nonce Format for ESB-RSA-AES128-EXT
図7：ESB-RSA-AES128-EXTのNonCE形式
The salt field is a four-octet value, usually chosen at random. It MUST be the same for all ESBs that have the same correlator value. The salt need not be kept secret.
saltフィールドは4オクテットの値であり、通常はランダムに選択されます。これは、同じcorrelator値を持つすべてのESBで同じでなければなりません (MUST)。ソルトは秘密にしておく必要はありません。
The initialization vector (IV) is an eight-octet value, usually chosen at random. It MUST be different for all ESBs that have the same correlator value. The value need not be kept secret.
初期化ベクトル（IV）は8オクテットの値であり、通常はランダムに選択されます。これは、同じcorrelator値を持つすべてのESBで異なっていなければなりません (MUST)。この値は秘密にしておく必要はありません。
The data encryption key is a 16-octet (128 bits) value, usually chosen at random. The value MUST be kept secret, as described below.
データ暗号化鍵は16オクテット（128ビット）の値であり、通常はランダムに選択されます。以下で説明するように、この値は秘密にしておかなければなりません (MUST)。
The integrity check value is a 16-octet value used to verify that the protected data has not been altered. The value need not be kept secret.
整合性チェック値は、保護されたデータが変更されていないことを確認するために使用される16オクテットの値です。価値を秘密にする必要はありません。
This ciphersuite replaces each BP extension block to be protected with a "replacing" ESB, and each can be individually specified.
このciphersuiteは、各BP拡張ブロックを「交換」ESBで保護するために置き換えられ、それぞれを個別に指定できます。
If a number of related BP extension blocks are to be protected, they can be grouped as a correlated set and protected using a single key. These blocks replace the original blocks on a one-to-one basis, so the number of blocks remains unchanged. All these related blocks MUST have the same correlator value. The term "first ESB" in this section refers to the single ESB if there is only one or, if there are several, then to the one containing the key or key-identifier. This MUST be the first of the set. If the blocks are individually specified, then there is no correlated set and each block is its own "first ESB".
関連する多数のBP拡張ブロックを保護する場合、それらを相関セットとしてグループ化し、単一の鍵を使用して保護することができます。これらのブロックは元のブロックを1対1で置き換えるため、ブロック数は変更されません。これらすべての関連ブロックは、同じcorrelator値を持たなければなりません (MUST)。本セクションにおける「第1のESB」という用語は、ESBが1つしかない場合はその単一のESBを指し、複数ある場合は鍵または鍵識別子を含むものを指します。これはセットの最初のものでなければなりません (MUST)。ブロックが個別に指定されている場合、相関セットは存在せず、各ブロックが独自の「第1のESB」となります。
First ESB - the first ESB MAY contain a correlator value, and MAY specify security-source and/or security-destination in the EID-list. If not specified, the bundle-source and bundle-destination, respectively, are used for these values, as with other ciphersuites. The block MUST contain security-parameters and security-result fields. Each field MAY contain several items formatted as described in Section 2.6.
第1のESB - 第1のESBはcorrelator値を含んでもよく (MAY)、EIDリスト内にセキュリティソースおよび/またはセキュリティ宛先を指定してもよいです (MAY)。指定されない場合、他の暗号スイートと同様に、これらの値にはそれぞれバンドル送信元およびバンドル宛先が使用されます。ブロックはsecurity-parametersおよびsecurity-resultフィールドを含まなければなりません (MUST)。各フィールドには、セクション2.6で説明されているようにフォーマットされた複数の項目が含まれてもよいです (MAY)。
Security-parameters
セキュリティパラメーター
key-information
キー情報
salt
塩
IV for this specific block
この特定のブロックのIV
block type of encapsulated block (OPTIONAL)
カプセル化されたブロックのブロックタイプ (OPTIONAL)
Security-result
セキュリティ結果
encapsulated block
カプセル化されたブロック
Subsequent ESBs MUST contain a correlator value to link them to the first ESB. Security-source and security-destination are implied from the first ESB; however, see the discussion in Section 2.4 concerning EID-list entries. Subsequent ESBs MUST contain security-parameters and security-result fields as follows:
後続のESBは、第1のESBにリンクするためにcorrelator値を含まなければなりません (MUST)。セキュリティソースおよびセキュリティ宛先は第1のESBから暗示されますが、EIDリストエントリに関するセクション2.4の議論を参照してください。後続のESBは、以下のようにsecurity-parametersおよびsecurity-resultフィールドを含まなければなりません (MUST) :
Security-parameters
セキュリティパラメーター
IV for this specific block
この特定のブロックのIV
block type of encapsulated block (OPTIONAL)
カプセル化されたブロックのブロックタイプ (OPTIONAL)
Security-result
セキュリティ結果
encapsulated block
カプセル化されたブロック
The security-parameters and security-result fields in the subsequent ESBs MUST NOT contain any items other than those listed. Items such as key-information and salt are supplied in the first ESB and MUST NOT be repeated.
後続のESB内のsecurity-parametersおよびsecurity-resultフィールドには、リストされたもの以外の項目を含めてはなりません (MUST NOT)。鍵情報やソルトなどの項目は第1のESBで提供されるため、繰り返してはなりません (MUST NOT)。
Implementations MUST support the use of "enveloped-data" type as defined in [RFC5652], Section 6, with RecipientInfo type KeyTransRecipientInfo containing the issuer and serial number of a suitable certificate. They MAY support additional RecipientInfo types. The "encryptedContent" field in EncryptedContentInfo contains the encrypted BEK used to encrypt the content of the block being protected.
実装は、[RFC5652]のセクション6で定義されている「enveloped-data」タイプの使用をサポートしなければならず (MUST)、適切な証明書の発行者およびシリアル番号を含むRecipientInfoタイプのKeyTransRecipientInfoを伴います。実装は追加のRecipientInfoタイプをサポートしてもよいです (MAY)。EncryptedContentInfo内の「encryptedContent」フィールドには、保護対象のブロックのコンテンツを暗号化するために使用される暗号化されたBEKが含まれます。
For each block to be protected, the entire original block is encapsulated in a "replacing" ESB. This replacing ESB is placed in the outgoing bundle in the same position as the original block. As mentioned above, this is one-to-one replacement, and there is no consolidation of blocks or mixing of data in any way.
各ブロックを保護するために、元のブロック全体が「交換」ESBにカプセル化されています。この交換ESBは、元のブロックと同じ位置に発信バンドルに配置されます。上記のように、これは1対1の代替品であり、ブロックの統合やデータの混合は何らかの形でありません。
The encryption process uses AES-GCM with the salt and key values from the first ESB and an IV unique to this ESB. The process creates ciphertext for the entire original block, and an authentication tag for validation at the security-destination. The authentication tag is appended to the ciphertext for the block and the combination is stored into the encapsulated block item in security-result.
暗号化プロセスでは、最初のESBの塩とキー値を備えたAES-GCMとこのESBに固有のIVを使用します。このプロセスは、元のブロック全体の暗号文と、セキュリティ境界での検証のための認証タグを作成します。認証タグは、ブロックの暗号文に追加され、組み合わせはセキュリティ対応のカプセル化されたブロックアイテムに保存されます。
The replacing block, of course, also has the same correlator value as the first ESB with which it is associated. It also contains the block-specific IV in security-parameters, and the combination of original-block-ciphertext and authentication tag, stored as an encapsulated block item in security-result.
もちろん、交換ブロックには、関連する最初のESBと同じ相関者値もあります。また、セキュリティパラメーターにブロック固有のIVと、セキュリティ対応にカプセル化されたブロックアイテムとして保存されているオリジナルブロックカイフェートテキストと認証タグの組み合わせも含まれています。
Key management in delay-tolerant networks is recognized as a difficult topic and is one that this specification does not attempt to solve. However, solely in order to support implementation and testing, implementations SHOULD support:
遅延耐性ネットワークにおける鍵管理は困難なトピックとして認識されており、本文書が解決を試みるものではありません。しかし、実装およびテストをサポートするためだけに、実装は以下をサポートすべきです (SHOULD) :
o The use of well-known RSA public keys for all ciphersuites.
o すべてのciphersuitesの有名なRSAパブリックキーの使用。
o Long-term pre-shared-symmetric keys for the BAB-HMAC ciphersuite.
o BAB-HMAC Ciphersuiteの長期的な恥ずかしさ対称キー。
Since endpoint IDs are URIs and URIs can be placed in X.509 [RFC5280] public key certificates (in the subjectAltName extension), implementations SHOULD support this way of distributing public keys. RFC 5280 does not insist that implementations include revocation checking. In the context of a DTN, it is reasonably likely that some nodes would not be able to use revocation checking services (either Certificate Revocation Lists (CRLs) or the Online Certificate Status Protocol (OCSP)) and deployments SHOULD take this into account when planning any public key infrastructure to support this specification.
エンドポイントIDはURIであり、URIはX.509 [RFC5280]公開鍵証明書（subjectAltName拡張内）に配置できるため、実装は公開鍵を配布するこの方法をサポートすべきです (SHOULD)。RFC 5280は実装に失効チェックを含めることを要求していません。DTNのコンテキストでは、一部のノードが失効チェックサービス（証明書失効リスト（CRL）またはオンライン証明書ステータスプロトコル（OCSP）のいずれか）を使用できない可能性が十分にあり、配備はこの仕様をサポートする公開鍵基盤を計画する際にこれを考慮に入れるべきです (SHOULD)。
Every node serves as a Policy Enforcement Point insofar as it enforces some policy that controls the forwarding and delivery of bundles via one or more convergence layer protocol implementation. Consequently, every node SHALL have and operate according to its own configurable security policy, whether the policy be explicit or default. The policy SHALL specify:
すべてのノードは、1つ以上のコンバージェンス層プロトコル実装を介したバンドルの転送および配信を制御する何らかのポリシーを強制する限りにおいて、ポリシー適用ポイントとして機能します。したがって、すべてのノードは、ポリシーが明示的であるかデフォルトであるかにかかわらず、独自の設定可能なセキュリティポリシーを持ち、それに従って運用されなければなりません (SHALL)。ポリシーは以下を指定しなければなりません (SHALL) :
Under what conditions received bundles SHALL be forwarded.
どのような条件下で受信したバンドルが転送されなければならないか (SHALL)。
Under what conditions received bundles SHALL be required to include valid BABs.
どのような条件下で受信したバンドルに有効なBABを含めることが要求されなければならないか (SHALL)。
Under what conditions the authentication information provided in a bundle's BAB SHALL be deemed adequate to authenticate the bundle.
どのような条件下でバンドルのBABにおいて提供される認証情報が、バンドルを認証するのに適切であるとみなされなければならないか (SHALL)。
Under what conditions received bundles SHALL be required to have valid PIBs and/or PCBs.
どのような条件下で受信したバンドルが有効なPIBおよび/またはPCBを持つことを要求されなければならないか (SHALL)。
Under what conditions the authentication information provided in a bundle's PIB SHALL be deemed adequate to authenticate the bundle.
どのような条件下でバンドルのPIBにおいて提供される認証情報が、バンドルを認証するのに適切であるとみなされなければならないか (SHALL)。
Under what conditions a BAB SHALL be added to a received bundle before that bundle is forwarded.
どのような条件下で、バンドルが転送される前に受信したバンドルにBABが追加されなければならないか (SHALL)。
Under what conditions a PIB SHALL be added to a received bundle before that bundle is forwarded.
どのような条件下で、バンドルが転送される前に受信したバンドルにPIBが追加されなければならないか (SHALL)。
Under what conditions a PCB SHALL be added to a received bundle before that bundle is forwarded.
どのような条件下で、バンドルが転送される前に受信したバンドルにPCBが追加されなければならないか (SHALL)。
Under what conditions an ESB SHALL be applied to one or more blocks in a received bundle before that bundle is forwarded.
どのような条件下で、バンドルが転送される前に受信したバンドル内の1つ以上のブロックにESBが適用されなければならないか (SHALL)。
The actions that SHALL be taken in the event that a received bundle does not meet the receiving node's security policy criteria.
受信したバンドルが受信ノードのセキュリティポリシー基準を満たさない場合に取られなければならない (SHALL) アクション。
This specification does not address how security policies get distributed to nodes. It only REQUIRES that nodes have and enforce security policies.
この仕様では、セキュリティポリシーがノードに分散される方法には対応していません。ノードにはセキュリティポリシーがあることのみが必要です。
If no security policy is specified at a given node, or if a security policy is only partially specified, that node's default policy regarding unspecified criteria SHALL consist of the following:
特定のノードでセキュリティポリシーが指定されていない場合、またはセキュリティポリシーが部分的にしか指定されていない場合、不特定の基準に関するそのノードのデフォルトポリシーは以下で構成されなければなりません (SHALL) :
Bundles that are not well-formed do not meet the security policy criteria.
よく形成されていないバンドルは、セキュリティポリシーの基準を満たしていません。
The mandatory ciphersuites MUST be used.
必須の暗号スイートが使用されなければなりません (MUST)。
All bundles received MUST have a BAB that MUST be verified to contain a valid security-result. If the bundle does not have a BAB, then the bundle MUST be discarded and processed no further; a bundle status report indicating the authentication failure MAY be generated.
受信されたすべてのバンドルは、有効なsecurity-resultを含むことが検証されなければならない (MUST) BABを持たなければなりません (MUST)。バンドルにBABがない場合、そのバンドルは破棄されなければならず (MUST)、それ以上処理されてはなりません。認証の失敗を示すバンドルステータスレポートが生成されてもよいです (MAY)。
No received bundles SHALL be required to have a PIB; if a received bundle does have a PIB, however, the PIB can be ignored unless the receiving node is the PIB-destination, in which case the PIB MUST be verified.
受信したバンドルがPIBを持つことは要求されてはならず (SHALL)、ただし、受信したバンドルにPIBがある場合、受信ノードがPIB宛先でない限りPIBは無視できますが、PIB宛先である場合はPIBが検証されなければなりません (MUST)。
No received bundles SHALL be required to have a PCB; if a received bundle does have a PCB, however, the PCB can be ignored unless the receiving node is the PCB-destination, in which case the PCB MUST be processed. If processing a PCB yields a PIB, that PIB SHALL be processed by the node according to the node's security policy.
受信したバンドルがPCBを持つことは要求されてはならず (SHALL)、ただし、受信したバンドルにPCBがある場合、受信ノードがPCB宛先でない限りPCBは無視できますが、PCB宛先である場合はPCBが処理されなければなりません (MUST)。PCBの処理によってPIBが得られた場合、そのPIBはノードのセキュリティポリシーに従ってノードによって処理されなければなりません (SHALL)。
A PIB SHALL NOT be added to a bundle before sourcing or forwarding it.
バンドルの発信または転送の前に、PIBがバンドルに追加されてはなりません (SHALL NOT)。
A PCB SHALL NOT be added to a bundle before sourcing or forwarding it.
バンドルの発信または転送の前に、PCBがバンドルに追加されてはなりません (SHALL NOT)。
A BAB MUST always be added to a bundle before that bundle is forwarded.
バンドルが転送される前に、常にBABがバンドルに追加されなければなりません (MUST)。
If a destination node receives a bundle that has a PIB-destination but the value in that PIB-destination is not the EID of the destination node, the bundle SHALL be delivered at that destination node.
宛先ノードがPIB宛先を持つバンドルを受信したが、そのPIB宛先の値が宛先ノードのEIDではない場合、バンドルはその宛先ノードで配信されなければなりません (SHALL)。
If a destination node receives a bundle that has an ESB-destination but the value in that ESB-destination is not the EID of the destination node, the bundle SHALL be delivered at that destination node.
宛先ノードがESB宛先を持つバンドルを受信したが、そのESB宛先の値が宛先ノードのEIDではない場合、バンドルはその宛先ノードで配信されなければなりません (SHALL)。
If a received bundle does not satisfy the node's security policy for any reason, then the bundle MUST be discarded and processed no further; in this case, a bundle deletion status report (see the Bundle Protocol Specification [DTNBP]) indicating the failure MAY be generated.
受信したバンドルが何らかの理由でノードのセキュリティポリシーを満たさない場合、そのバンドルは破棄されなければならず (MUST)、それ以上処理されてはなりません。この場合、障害を示すバンドル削除ステータスレポート（Bundle Protocol仕様[DTNBP]を参照）が生成されてもよいです (MAY)。
The Bundle Security Protocol builds upon much work of others, in particular, "Cryptographic Message Syntax (CMS)" [RFC5652] and "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile" [RFC5280]. The security considerations in these two documents apply here as well.
バンドルセキュリティプロトコルは、特に「暗号メッセージ構文（CMS）」[RFC5652]および「インターネットX.509公開キーインフラストラクチャ証明書および証明書取消リスト（CRL）プロファイル」[RFC5280]の多くの作業に基づいています。これら2つのドキュメントのセキュリティ上の考慮事項もここにも適用されます。
Several documents specifically consider the use of Galois/Counter Mode (GCM) and of AES and are important to consider when building ciphersuites. These are "The Use of Galois/Counter Mode (GCM) in IPsec Encapsulating Security Payload (ESP)" [RFC4106] and "Using AES-CCM and AES-GCM Authenticated Encryption in the Cryptographic Message Syntax (CMS)" [RFC5084]. Although the BSP is not identical, many of the security issues considered in these documents also apply here.
いくつかのドキュメントは、Galois/Counter Mode（GCM）およびAEの使用を具体的に検討しており、暗号筋を構築する際に考慮することが重要です。これらは、「セキュリティペイロード（ESP）をカプセル化するIPSECでのガロア/カウンターモード（GCM）の使用」[RFC4106]および「暗号化メッセージSyntax（CMS）（CMS）でAES-CCMおよびAES-GCM認証暗号化」[RFC5084]です。BSPは同一ではありませんが、これらのドキュメントで検討されているセキュリティ問題の多くもここにも適用されます。
Certain applications of DTN need to both sign and encrypt a message, and there are security issues to consider with this.
DTNの特定のアプリケーションは、メッセージに署名して暗号化する必要があり、これを考慮すべきセキュリティの問題があります。
If the intent is to provide an assurance that a message did, in fact, come from a specific source and has not been changed, then it should be signed first and then encrypted. A signature on an encrypted message does not establish any relationship between the signer and the original plaintext message.
実際、メッセージが特定のソースから来て、変更されていないという保証を提供することである場合、最初に署名してから暗号化する必要があります。暗号化されたメッセージの署名は、署名者と元のプレーンテキストメッセージとの関係を確立しません。
On the other hand, if the intent is to reduce the threat of denial-of-service attacks, then signing the encrypted message is appropriate. A message that fails the signature check will not be processed through the computationally intensive decryption pass. A more extensive discussion of these points is in S/MIME 3.2 Message Specification [RFC5751], especially in Section 3.6.
一方、意図がサービス拒否攻撃の脅威を減らすことである場合、暗号化されたメッセージに署名することが適切です。署名チェックに失敗したメッセージは、計算集中的な復号化パスを介して処理されません。これらのポイントのより広範な議論は、S/MIME 3.2メッセージ仕様[RFC5751]、特にセクション3.6です。
Additional details relating to these combinations can be found in Section 2.8 where it is RECOMMENDED that the encrypt-then-sign combination is usually appropriate for usage in a DTN.
これらの組み合わせに関する追加の詳細はセクション2.8に記載されており、そこでは暗号化後署名（encrypt-then-sign）の組み合わせがDTNでの使用において通常適切であることが推奨されています (RECOMMENDED)。
In a DTN, encrypt-then-sign potentially allows intermediate nodes to verify a signature (over the ciphertext) and thereby apply policy to manage possibly scarce storage or other resources at intermediate nodes in the path the bundle takes from source to destination EID.
DTNでは、エンクリプトトゥエンサインでは、中間ノードが署名を検証することができ、それにより、バンドルがソースから宛先EIDへのパスの中間ノードで希少なストレージまたは他のリソースを管理するためのポリシーを適用します。
An encrypt-then-sign scheme does not further expose identity in most cases since the BP mandates that the source EID (which is commonly expected to be the security-source) is already exposed in the primary block of the bundle. Should exposure of either the source EID or the signerInfo be considered an interesting vulnerability, then some form of bundle-in-bundle encapsulation would be required as a mitigation.
BPは、ソースEID（一般的にセキュリティソースであると予想される）がバンドルの主要なブロックにすでに公開されていることをBPが義務付けているため、暗号化 - then-Signスキームはほとんどの場合、アイデンティティをさらに公開しません。ソースEidまたはsignerInfoのいずれかの露出が興味深い脆弱性と見なされる場合、緩和として何らかの形のバンドルインバンドルカプセル化が必要になります。
If a BAB ciphersuite uses digital signatures but doesn't include the security-destination (which for a BAB is the next host), then this allows the bundle to be sent to some node other than the intended adjacent node. Because the BAB will still authenticate, the receiving node might erroneously accept and forward the bundle. When asymmetric BAB ciphersuites are used, the security-destination field SHOULD therefore be included in the BAB.
BAB暗号スイートがデジタル署名を使用しているにもかかわらずセキュリティ宛先（BABの場合はネクストホスト）を含まない場合、意図した隣接ノード以外のノードにバンドルが送信されることが可能になってしまいます。BABは依然として認証されるため、受信ノードが誤ってバンドルを受け入れて転送してしまう可能性があります。したがって、非対称BAB暗号スイートが使用される場合、セキュリティ宛先フィールドがBABに含まれるべきです (SHOULD)。
If a bundle's PIB-destination is not the same as its destination, then some node other than the destination (the node identified as the PIB-destination) is expected to validate the PIB security-result while the bundle is en route. However, if for some reason the PIB is not validated, there is no way for the destination to become aware of this. Typically, a PIB-destination will remove the PIB from the bundle after verifying the PIB and before forwarding it. However, if there is a possibility that the PIB will also be verified at a downstream node, the PIB-destination will leave the PIB in the bundle. Therefore, if a destination receives a bundle with a PIB that has a PIB-destination (which isn't the destination), this might, but does not necessarily, indicate a possible problem.
バンドルのPIB拘束が宛先と同じでない場合、宛先（PIB拘束として識別されたノード）以外のノードは、バンドルが途中である間にPIBセキュリティ結果を検証することが期待されます。ただし、何らかの理由でPIBが検証されていない場合、目的地がこれを認識する方法はありません。通常、PIBを確認した後、PIBを確認した後、PIBをバンドルから除去します。ただし、PIBも下流ノードで検証される可能性がある場合、PIB destinationはPIBをバンドルに残します。したがって、目的地がPIB輝合（目的地ではない）を持つPIBでバンドルを受け取る場合、これは必ずしも問題を示す可能性がありますが、必ずしもそうではありません。
If a bundle is fragmented after being forwarded by its PIB-source but before being received by its PIB-destination, the payload in the bundle MUST be reassembled before validating the PIB security-result in order for the security-result to validate correctly. Therefore, if the PIB-destination is not capable of performing payload reassembly, its utility as a PIB-destination will be limited to validating only those bundles that have not been fragmented since being forwarded from the PIB-source. Similarly, if a bundle is fragmented after being forwarded by its PIB-source but before being received by its PIB-destination, all fragments MUST be received at that PIB-destination in order for the bundle payload to be able to be reassembled. If not all fragments are received at the PIB-destination node, the bundle will not be able to be authenticated, and will therefore never be forwarded by this PIB-destination node.
バンドルがそのPIBソースによって転送された後、そのPIB宛先によって受信される前に断片化された場合、security-resultが正しく検証されるためには、PIBのsecurity-resultを検証する前にバンドル内のペイロードが再組み立てされなければなりません (MUST)。したがって、PIB宛先がペイロードの再組み立てを実行できない場合、PIB宛先としてのその実用性は、PIBソースから転送されて以降断片化されていないバンドルのみを検証することに限定されます。同様に、バンドルがそのPIBソースによって転送された後、そのPIB宛先によって受信される前に断片化された場合、バンドルペイロードを再組み立てできるようにするために、すべてのフラグメントがそのPIB宛先で受信されなければなりません (MUST)。すべてのフラグメントがPIB宛先ノードで受信されない場合、バンドルを認証することはできず、したがってこのPIB宛先ノードによって転送されることは決してありません。
Specification of a security-destination other than the bundle-destination creates a routing requirement that the bundle somehow be directed to the security-destination node on its way to the final destination. This requirement is presently private to the ciphersuite, since routing nodes are not required to implement security processing.
バンドル照明以外のセキュリティ境界の仕様は、バンドルが最終目的地に向かう途中で何らかの形でセキュリティ廃止ノードに向けられるというルーティング要件を作成します。この要件は、セキュリティ処理を実装するためにルーティングノードが必要ないため、現在、Ciphersuiteのプライベートです。
If a security target were to generate reports in the event that some security validation step fails, then that might leak information about the internal structure or policies of the DTN containing the security target. This is sometimes considered bad security practice, so it SHOULD only be done with care.
セキュリティ検証ステップが失敗した場合にセキュリティターゲットがレポートを生成すると、セキュリティターゲットを含むDTNの内部構造やポリシーに関する情報が漏洩する可能性があります。これはセキュリティ上好ましくない慣習とみなされることがあるため、慎重にのみ行われるべきです (SHOULD)。
As indicated above, this document describes both BSP and ciphersuites. A conformant implementation MUST implement both BSP support and the four ciphersuites described in Section 4. It MAY also support other ciphersuites.
上記で示したように、本文書はBSPと暗号スイートの両方を説明しています。適合する実装は、BSPのサポートとセクション4で説明されている4つの暗号スイートの両方を実装しなければなりません (MUST)。他の暗号スイートもサポートしてもよいです (MAY)。
Implementations that support BSP but not all four mandatory ciphersuites MUST claim only "restricted compliance" with this specification, even if they provide other ciphersuites.
BSPをサポートするが4つの必須暗号スイートのすべてをサポートしていない実装は、他の暗号スイートを提供している場合であっても、本仕様に対して「制限付き適合（restricted compliance）」のみを主張しなければなりません (MUST)。
All implementations are strongly RECOMMENDED to provide at least a BAB ciphersuite. A relay node, for example, might not deal with end-to-end confidentiality and data integrity, but it SHOULD exclude unauthorized traffic and perform hop-by-hop bundle verification.
すべての実装は、少なくともBAB暗号スイートを提供することが強く推奨されます (RECOMMENDED)。例えば、中継ノードはエンドツーエンドの機密性やデータ完全性を扱わないかもしれませんが、不正なトラフィックを排除し、ホップバイホップのバンドル検証を実行すべきです (SHOULD)。
This protocol has fields that have been registered by IANA.
このプロトコルには、IANAによって登録されたフィールドがあります。
This specification allocates four codepoints from the existing "Bundle Block Types" registry defined in [RFC6255].
この仕様には、[RFC6255]で定義されている既存の「バンドルブロックタイプ」レジストリから4つのコードポイントが割り当てられます。
Additional Entries for the Bundle Block-Type Codes Registry:
+-------+--------------------------------------+----------------+
| Value | Description | Reference |
+-------+--------------------------------------+----------------+
| 2 | Bundle Authentication Block | This document |
| 3 | Payload Integrity Block | This document |
| 4 | Payload Confidentiality Block | This document |
| 9 | Extension Security Block | This document |
+-------+--------------------------------------+----------------+
This protocol has a ciphersuite number field and certain ciphersuites are defined. An IANA registry has been set up as follows.
このプロトコルには暗号化された数字フィールドがあり、特定の暗号網が定義されています。IANAレジストリは次のように設定されています。
The registration policy for this registry is: Specification Required
このレジストリの登録ポリシーは次のとおりです。
The Value range is: Variable Length
値範囲は次のとおりです
Ciphersuite Numbers Registry:
+-------+--------------------------------------+----------------+
| Value | Description | Reference |
+-------+--------------------------------------+----------------+
| 0 | unassigned | This document |
| 1 | BAB-HMAC | This document |
| 2 | PIB-RSA-SHA256 | This document |
| 3 | PCB-RSA-AES128-PAYLOAD-PIB-PCB | This document |
| 4 | ESB-RSA-AES128-EXT | This document |
| >4 | Reserved | This document |
+-------+--------------------------------------+----------------+
This protocol has a ciphersuite flags field and certain flags are defined. An IANA registry has been set up as follows.
このプロトコルにはciphersuiteフラグフィールドがあり、特定のフラグが定義されています。IANAレジストリは次のように設定されています。
The registration policy for this registry is: Specification Required
このレジストリの登録ポリシーは次のとおりです。
The Value range is: Variable Length
値範囲は次のとおりです
Ciphersuite Flags Registry:
+-----------------+----------------------------+----------------+
| Bit Position | Description | Reference |
| (right to left) | | |
+-----------------+----------------------------+----------------+
| 0 | Block contains result | This document |
| 1 | Block contains correlator | This document |
| 2 | Block contains parameters | This document |
| 3 | Destination EIDref present | This document |
| 4 | Source EIDref present | This document |
| >4 | Reserved | This document |
+-----------------+----------------------------+----------------+
This protocol has fields for ciphersuite-parameters and results. The field is a type-length-value triple and a registry is required for the "type" sub-field. The values for "type" apply to both the ciphersuite-parameters and the ciphersuite results fields. Certain values are defined. An IANA registry has been set up as follows.
このプロトコルには、Ciphersuiteパラメーターと結果のフィールドがあります。フィールドはタイプ長値トリプルであり、「タイプ」サブフィールドにはレジストリが必要です。「タイプ」の値は、Ciphersuite-ParametersとCiphersuiteの結果フィールドの両方に適用されます。特定の値が定義されています。IANAレジストリは次のように設定されています。
The registration policy for this registry is: Specification Required
このレジストリの登録ポリシーは次のとおりです。
The Value range is: 8-bit unsigned integer
値範囲は次のとおりです。8ビットの符号なし整数です
Ciphersuite-Parameters and Results Type Registry:
+---------+------------------------------------+----------------+
| Value | Description | Reference |
+---------+------------------------------------+----------------+
| 0 | reserved | This document |
| 1 | initialization vector (IV) | This document |
| 2 | reserved | This document |
| 3 | key-information | This document |
| 4 | fragment-range (pair of SDNVs) | This document |
| 5 | integrity signature | This document |
| 6 | unassigned | This document |
| 7 | salt | This document |
| 8 | PCB integrity check value (ICV) | This document |
| 9 | reserved | This document |
| 10 | encapsulated block | This document |
| 11 | block type of encapsulated block | This document |
| 12-191 | reserved | This document |
| 192-250 | private use | This document |
| 251-255 | reserved | This document |
+-------+--------------------------------------+----------------+
[DTNBP] Scott, K. and S. Burleigh, "Bundle Protocol Specification", RFC 5050, November 2007.
[DTNBP] Scott、K。およびS. Burleigh、「バンドルプロトコル仕様」、RFC 5050、2007年11月。
[DTNMD] Symington, S., "Delay-Tolerant Networking Metadata Extension Block", RFC 6258, May 2011.
[DTNMD] Symington、S。、「遅延耐性ネットワークメタデータ拡張ブロック」、RFC 6258、2011年5月。
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[RFC2104] Krawczyk、H.、Bellare、M。、およびR. CaNetti、「HMAC：メッセージ認証のためのキー付きハッシング」、RFC 2104、1997年2月。
[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月。
[RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional Algorithms and Identifiers for RSA Cryptography for use in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 4055, June 2005.
[RFC4055] Schaad、J.、Kaliski、B。、およびR. Housley、「インターネットで使用するRSA暗号化の追加アルゴリズムと識別子X.509公開鍵インフラストラクチャ証明書および証明書取消リスト（CRL）プロファイル」、RFC 4055、2005年6月。
[RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode (GCM) in IPsec Encapsulating Security Payload (ESP)", RFC 4106, June 2005.
[RFC4106] Viega、J。およびD. McGrew、「セキュリティペイロードをカプセル化するIPSEC（ESP）でのガロア/カウンターモード（GCM）の使用」、RFC 4106、2005年6月。
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008.
[RFC5280] Cooper、D.、Santesson、S.、Farrell、S.、Boeyen、S.、Housley、R.、およびW. Polk、 "Internet X.509公開キーインフラストラクチャ証明書および証明書失効リスト（CRL）プロファイル"、RFC 5280、2008年5月。
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, September 2009.
[RFC5652] Housley、R。、「暗号メッセージ構文（CMS）」、STD 70、RFC 5652、2009年9月。
[RFC6255] Blanchet, M., "Delay-Tolerant Networking (DTN) Bundle Protocol IANA Registries", RFC 6255, May 2011.
[RFC6255] Blanchet、M。、「遅延耐性ネットワーキング（DTN）バンドルプロトコルIANAレジストリ」、RFC 6255、2011年5月。
[DTNarch] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst, R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant Networking Architecture", RFC 4838, April 2007.
[DTNARCH] Cerf、V.、Burleigh、S.、Hooke、A.、Torgerson、L.、Durst、R.、Scott、K.、Fall、K。、およびH. Weiss、「遅延耐性ネットワーキングアーキテクチャ」、RFC 4838、2007年4月。
[PHIB] Symington, S., "Delay-Tolerant Networking Previous-Hop Insertion Block", RFC 6259, May 2011.
[Phib] Symington、S。、「遅延耐性ネットワーク前ホップ挿入ブロック」、RFC 6259、2011年5月。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC3986] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「Uniform Resource Identifier（URI）：Generic Syntax」、Std 66、RFC 3986、2005年1月。
[RFC5084] Housley, R., "Using AES-CCM and AES-GCM Authenticated Encryption in the Cryptographic Message Syntax (CMS)", RFC 5084, November 2007.
[RFC5084] Housley、R。、「暗号メッセージ構文（CMS）でAES-CCMおよびAES-GCM認証暗号化を使用して」、RFC 5084、2007年11月。
[RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification", RFC 5751, January 2010.
[RFC5751] Ramsdell、B。およびS. Turner、「Secure/Multipurpose Internet Mail Extensions（S/MIME）バージョン3.2メッセージ仕様」、RFC 5751、2010年1月。
Authors' Addresses
著者のアドレス
Susan Flynn Symington The MITRE Corporation 7515 Colshire Drive McLean, VA 22102 US
スーザン・フリン・シミントン・ザ・マイター・コーポレーション7515コルシャー・ドライブ・マクリーン、バージニア州22102 US
Phone: +1 (703) 983-7209
EMail: susan@mitre.org
URI: http://mitre.org/
Stephen Farrell Trinity College Dublin Distributed Systems Group Department of Computer Science Trinity College Dublin 2 Ireland
スティーブンファレルトリニティカレッジダブリン分散システムグループコンピュータサイエンストリニティカレッジダブリン2アイルランド
Phone: +353-1-896-2354
EMail: stephen.farrell@cs.tcd.ie
Howard Weiss SPARTA, Inc. 7110 Samuel Morse Drive Columbia, MD 21046 US
ハワード・ワイス・スパルタ・インク7110サミュエル・モールス・ドライブコロンビア、メリーランド州21046米国
Phone: +1-443-430-8089
EMail: howard.weiss@sparta.com
Peter Lovell SPARTA, Inc. 7110 Samuel Morse Drive Columbia, MD 21046 US
Peter Lovell Sparta、Inc。7110 Samuel Morse Drive Columbia、MD 21046 US
Phone: +1-443-430-8052
EMail: dtnbsp@gmail.com