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
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.
本文档定义了bundle安全协议，该协议为bundle协议提供数据完整性和保密服务。提供了单独的功能来保护捆绑包有效负载和可能包含在捆绑包中的附加数据。我们还描述了各种安全注意事项，包括一些策略选项。
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.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问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.
版权所有（c）2011 IETF信托基金和确定为文件作者的人员。版权所有。
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信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
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
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.
本文档定义了用于延迟容忍网络的捆绑协议[DTNBP]的安全特性，以提供延迟容忍网络（DTN）安全服务。
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.
捆绑协议用于覆盖多个网络的DTN中，其中一些可能受到限制的挑战，例如间歇性和可能不可预测的连接丢失、长时间或可变延迟、不对称数据速率和高错误率。Bundle协议的目的是支持跨此类网络的互操作性。捆绑协议分层在特定于底层网络的汇聚层之上、特定于网络的下层之上，以使一个网络中的应用程序能够与另一个网络中的应用程序通信，这两个网络都由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.
安全性对于Bundle协议非常重要。捆绑协议将在其上运行的底层网络的压力环境使得保护DTN免受未经授权的使用变得非常重要，这种压力环境对保护捆绑协议所需的机制提出了独特的挑战。此外，DTN很可能部署在部分网络可能受到破坏的环境中，从而带来与机密性、完整性和可用性相关的常见安全挑战。
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）和一组强制密码套件。密码套件是各种密码算法和实现规则的特定集合，它们一起用于提供特定的安全服务。
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.
根据定义，Bundle安全协议仅适用于实现它的节点，称为“安全感知”节点。DTN中可能有其他节点未实现BSP。所有节点都可以互操作，但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].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”应按照[RFC2119]中的说明进行解释。
We introduce the following terminology for purposes of clarity:
为了清晰起见，我们引入以下术语：
source - the bundle node from which a bundle originates
source—从中生成捆绑包的捆绑包节点
destination - the bundle node to which a bundle is ultimately destined
destination（目的地）-捆绑包最终目的地的捆绑包节点
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，其中四个捆绑节点（表示为BN1、BN2、BN3和BN4）位于某些传输层之上。还显示了三种不同的传输和网络协议（表示为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 --->|
| | | |
+---------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：捆绑节点位于Internet模型的应用层
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.
Bundle节点BN1发起一个Bundle，并将其转发给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的bundle提供了一个安全块，那么BN1是该bundle相对于该安全块的安全源，也是bundle的源。
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.
如果BN2为源自BN1的捆绑包提供了一个安全块，则BN2是该捆绑包相对于该安全块的安全源，即使BN1是源。
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.
一个捆绑包可能有多个安全块。相对于捆绑包中的给定安全块，捆绑包的安全源可以与相对于捆绑包中不同安全块的捆绑包的安全源相同或不同。类似地，捆绑包的安全目标相对于该捆绑包的每个安全块可能相同或不同。因此，各种块的安全路径可能不同，并且通常会不同。
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处发起的包被BN1提供了一个安全块，该安全块将由BN3处理，并且BN2添加了一个具有安全目的地BN4的安全块，则两个块的安全路径重叠，但不完全重叠。第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]中的要求，转发节点必须以接收块的相同顺序在包中传输块。此要求适用于所有DTN节点，而不仅仅是实现安全处理的节点。可以根据适用的规范添加或删除捆绑包中的块，但接收和发送的块必须按照接收顺序发送。
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.
如果节点不具有安全意识，则除非捆绑包的块处理标志另有规定，否则它将不加更改地转发捆绑包中的安全块。如果网络具有一些不具备安全意识的节点，则应设置块处理标志，以确保安全块不会仅因为无法在这些节点上处理而在这些节点上被丢弃。除此之外，非安全感知节点是透明的中继点，就安全处理而言是不可见的。
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.
块序列还指示某些重要操作影响捆绑包的顺序，以及为在其目的地生成捆绑包而必须执行的操作顺序。
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).
捆绑包中可能包含四种类型的安全块。这些是包身份验证块（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用于确保从转发器到中间接收器的单跳包的真实性和完整性。由于安全块仅在安全感知节点上处理，因此从安全感知转发器到下一个安全感知中间接收器的“单跳”可能不止一个实际跳。第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安全目的地之间的任何节点进行验证，该节点可以访问所需的加密密钥和撤销状态信息。
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在“逐跳”的基础上保护捆绑包，并且其他安全块可能在多个跳或端到端上进行保护，因此无论何时都存在，BAB必须形成“外层”保护层——即，在计算所有其他安全块并将其添加到捆绑包之后，必须始终计算BAB并将其添加到捆绑包中。
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参考列表（可选）
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.
由于这四个安全块具有大多数公共字段，如果我们首先定义一个抽象安全块（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 块类型代码（一个字节）-与除主捆绑包块之外的所有捆绑包协议块相同。安全块的块类型代码为：
BundleAuthenticationBlock - BAB: 0x02
BundleAuthenticationBlock-BAB:0x02
PayloadIntegrityBlock - PIB: 0x03
PayloadIntegrityBlock-PIB:0x03
PayloadConfidentialityBlock - PCB: 0x04
PayloadSecretentityBlock-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引用-在[DTNBP]中定义的复合字段，包含对一个或两个端点标识符（EID）的引用。EID参考字段的存在由块处理控制标志的“块包含EID参考字段”（EID_REF）位的设置指示。如果存在一个或多个引用，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字段，则必须完全忽略复合字段本身，并且必须取消设置EID_REF位。不允许计数字段为零。
o The possible EIDs are:
o 可能的EID包括：
* (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) 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.
* （可选）安全目标-指定块的安全目标。如果省略此项，则假定捆绑包的目的地是安全目的地，除非另有指示。
If two EIDs are present, security-source is first and security-destination comes second.
如果存在两个EID，则安全源是第一个，安全目标是第二个。
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)
* 密码套件ID（SDNV）
* Ciphersuite flags (SDNV)
* 密码套件标志（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.
* （可选）Correlator-插入多个相关块时，此字段在每个相关块实例中必须具有相同的值。这被编码为SDNV。关于束片段中的相关器值，请参见第3.8节中的注释。
* (OPTIONAL) Ciphersuite-parameters - compound field of the next two items
* （可选）Ciphersuite参数-下两项的复合字段
+ Ciphersuite-parameters length - specifies the length of the following Ciphersuite-parameters data field and is encoded as an SDNV.
+ Ciphersuite参数长度-指定以下Ciphersuite参数数据字段的长度，并将其编码为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参数数据-与正在使用的Ciphersuite一起使用的参数，例如密钥标识符或初始化向量（IV）。有关潜在参数及其编码规则的列表，请参见第2.6节。此字段中包含的特定参数集定义为ciphersuite规范的一部分。
* (OPTIONAL) Security-result - compound field of the next two items
* （可选）安全结果-下两项的复合字段
+ 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).
+ 安全结果数据-包含相应密码套件特定计算的结果（例如，签名、消息身份验证码（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 |
+----------------+----------------+----------------+----------------+
+----------------+----------------+----------------+----------------+
| 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节规定了一些密码套件，其中还规定了密码套件规范必须满足的规则。其他密码套件可在单独的规范中定义。未指定的密码套件ID是保留的。Bundle安全协议的实现根据第4节的要求决定支持哪些密码套件。建议允许附加密码套件的实现允许密码套件ID值至少达到并包括127，并且可能会拒绝允许更大的ID值。
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来指示可选字段的存在。值为零表示缺少相应的可选字段。目前，该字段定义了五个标志；为方便起见，这些数据显示为从单字节SDNV中提取的数据。未来的添加可能会导致字段向左增长，因此，与[DTNBP]中定义的标志字段一样，下面的描述从右侧对位位置进行编号，而不是从左侧对位进行编号的标准RFC定义。
src - bit 4 indicates whether the EID-reference field of the ASB contains the optional reference to the security-source.
src-第4位指示ASB的EID引用字段是否包含对安全源的可选引用。
dest - bit 3 indicates whether the EID-reference field of the ASB contains the optional reference to the security-destination.
dest-位3指示ASB的EID引用字段是否包含对安全目标的可选引用。
parm - bit 2 indicates whether or not the ciphersuite-parameters length and ciphersuite-parameters data fields are present.
parm-第2位指示是否存在ciphersuite参数长度和ciphersuite参数数据字段。
corr - bit 1 indicates whether or not the ASB contains an optional correlator.
corr-位1表示ASB是否包含可选的相关器。
res - bit 0 indicates whether or not the ASB contains the security-result length and security-result data fields.
res-位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 |
+-----+-----+-----+-----+-----+-----+-----+
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引用字段中的EID引用表示的PIB的安全源。类似地，我们可以引用“PCB dest”，这意味着PCB的安全目的地，同样由EID引用表示。例如，再次参考图1，如果BN1为源自BN1的捆绑提供了有效负载机密性块（PCB），该块使用BN3持有的密钥进行保护，并且BN1为其提供了有效负载完整性块（PIB），那么BN1既是捆绑的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.
correlator字段用于关联安全块的多个相关实例。这可用于将包含密码套件信息的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.
ciphersuite规范必须明确是否允许多个块实例，如果允许，在什么条件下。当然，有些密码套件可以让实现保持灵活性，而另一些则可能要求固定数量的实例。
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".
为方便起见，我们使用术语“第一块”来指代一组相关块中的初始块，或指代集合中没有其他块时的单个块。显然，在一个包中可以有几个不相关的组，每个组只包含一个或多个块，并且每个组都有自己的“第一块”。
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).
在本节中，我们描述了两种情况下的典型BAB字段值——其中BAB的单个实例包含所有信息，并且使用了两个相关实例，一个“前端”包含密码套件，另一个在有效负载之后，包含安全结果（例如MAC）。
For the case where a single BAB is used:
对于使用单个BAB的情况：
The block-type code field value MUST be 0x02.
块类型代码字段值必须为0x02。
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.
块处理控制标志值可以设置为本地策略所需的任何值。CiffSub设计者应该仔细考虑设置标志的效果，即在无法处理该块的情况下，丢弃块或删除包。
The ciphersuite ID MUST be documented as a hop-by-hop authentication-ciphersuite that requires one instance of the BAB.
密码套件ID必须记录为需要一个BAB实例的逐跳验证密码套件。
The correlator field MUST NOT be present.
相关器字段不得存在。
The ciphersuite-parameters field MAY be present, if so specified in the ciphersuite specification.
如果ciphersuite规范中有规定，则可能存在ciphersuite参数字段。
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引用。还可以将安全源指定为第2.6节中描述的密钥信息的一部分或其他块，例如前一跳插入块[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引用，这有助于确保捆绑包已转发到正确的下一跳节点。
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).
安全结果必须存在，因为它实际上是应用于捆绑包（相关部分）的ciphersuite计算（如MAC或签名）的“输出”（如ciphersuite定义中的规定）。
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.
对于使用两个相关BAB实例的情况，第一个实例如上所述，但密码套件ID必须记录为需要两个BAB实例的逐跳验证密码套件。此外，必须存在相关器，并且必须缺少安全结果长度和安全结果字段。BAB的第二个实例必须具有相同的correlator值，并且必须包含安全结果长度和安全结果数据字段。其他可选字段不得存在。通常，BAB的第二个实例将是包的最后一个块。
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节中的密钥信息项是可选的，如果未提供，则应从源-目标元组推断密钥，即使用的前一个密钥、从密钥派生函数创建的密钥或预共享密钥。
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 根据使用的密钥机制，捆绑包可以由发送方签名，也可以为一个或多个接收方进行身份验证，或者两者都可以。
A PIB is an ASB with the following additional restrictions:
PIB是具有以下附加限制的ASB：
The block-type code value MUST be 0x03.
块类型代码值必须为0x03。
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.
块处理控制标志值可以设置为本地策略所需的任何值。CiffSub设计者应该仔细考虑设置标志的效果，即在无法处理该块的情况下，丢弃块或删除包。
The ciphersuite ID MUST be documented as an end-to-end authentication-ciphersuite or as an end-to-end error-detection-ciphersuite.
密码套件ID必须记录为端到端身份验证密码套件或端到端错误检测密码套件。
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相关实例，则必须存在相关器。如果密码套件只需要捆绑包中的一个PIB实例，则相关器不得存在。
The ciphersuite-parameters field MAY be present.
可能存在ciphersuite参数字段。
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引用。安全源也可以指定为第2.6节所述密钥信息的一部分。
An EID-reference to the security-destination MAY be present.
可能存在对安全目的地的EID引用。
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.
安全结果实际上是应用于捆绑包（相关部分）的ciphersuite计算（例如MAC或签名）的“输出”。与BAB的情况一样，如果没有相关器，则该字段必须存在。如果需要一个以上的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.
密码套件的处理量可能小于整个原始捆绑负载。这可能是因为它被定义为处理捆绑包的某个子集，或者可能是因为当前有效负载是原始捆绑包的一个片段。无论出于何种原因，如果ciphersuite处理的数据少于完整的原始捆绑负载，则此块的ciphersuite参数必须指定捆绑负载的哪些字节受到保护。
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.
对于某些密码套件（例如，使用非对称密钥生成签名的套件或使用组密钥的对称密钥的套件），可以在通往安全目的地的任何一个跃点检查安全信息，该目的地可以访问所需的密钥信息。第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.
如果采用保管转移，则建议使用一般可用的密钥，并且所有节点都应在接受保管之前验证捆绑包。
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 dest字段，因为验证PIB验证器所需的密钥将是与PIB源关联的公钥。
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安全参数中的密钥信息项携带使用某些长期密钥加密密钥（KEK）或众所周知的公钥加密的BEK。如果目标和安全目标均未解析用于解密的密钥，则ciphersuite参数字段中的密钥信息项也可用于指示可用于恢复BEK的解密密钥。如果捆绑包中已经包含PIB和/或PCB，也应使用相同的BEK对其进行加密，如下文“超级加密”所述。加密块被封装到一个新的PCB中，该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.
强烈建议将数据完整性机制与保密性结合使用，并且不要使用仅加密的密码套件。AES伽罗瓦/计数器模式（AES-GCM）满足此要求。“认证标签”或“完整性检查值”被存储到安全结果中，而不是像在一些协议中常见的那样被附加到有效载荷，因为如下所述，有效载荷的大小没有变化是重要的。
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.
由于原始有效负载的字节范围实际上在任何特定片段中的模糊性，有效负载大小的变化会对碎片、重新组装和保管转移产生不利影响。密码套件应将任何有效负载扩展（如身份验证标签（完整性检查值）和块模式密码生成的任何填充）放入机密性块的安全结果字段（见第2.6节）中的完整性检查值项中。
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.
允许有效负载超级加密，即对已经加密的有效负载进行加密，可能不止一次。密码套件应定义超级加密，以便在重新加密有效负载的同时，保护早期加密的参数。在某些情况下，不这样做可能表示存在漏洞。
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.
保密性通常应用于有效载荷，也可能应用于附加块。仅当非有效负载块应使用有效负载进行超级加密时，建议将有效负载保密密码套件应用于非有效负载块。如果不需要对块进行超级加密，则应使用扩展安全块机制而不是PCB对块进行保护。
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实例不“相关”，不应包含相关器。
The ciphersuite MAY apply different rules to confidentiality for non-payload blocks.
密码套件可以对非有效负载块的机密性应用不同的规则。
A PCB is an ASB with the following additional restrictions:
PCB是ASB，具有以下附加限制：
The block-type code value MUST be 0x04.
块类型代码值必须为0x04。
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
块处理控制标志值可以设置为本地策略所需的任何值，但PCB“第一块”必须设置“在每个片段中复制”标志。不应以其他方式设置此标志。密码套件设计者应该
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.
仔细考虑设置标志的效果，即在无法处理此块的情况下，丢弃块或删除包。
The ciphersuite ID MUST be documented as a confidentiality ciphersuite.
密码套件ID必须记录为机密密码套件。
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实例，则必须存在相关器。如果没有相关PCB实例，则相关器不得存在。
If a correlator is present, the key-information MUST be placed in the PCB "first block".
如果存在相关器，则关键信息必须放在PCB“第一块”中。
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安全结果的“完整性检查值”字段中（见第2.6节）。
The ciphersuite-parameters field MAY be present.
可能存在ciphersuite参数字段。
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引用。安全源也可以指定为第2.6节所述密钥信息的一部分。
An EID-reference to the security-destination MAY be present.
可能存在对安全目的地的EID引用。
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.
安全结果可能存在，并且通常包含诸如加密的捆绑包加密密钥、身份验证标签或除有效负载块之外的捆绑包块的加密版本等字段。
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.
ciphersuite处理的负载可能少于整个原始包负载，这可能是因为当前负载是原始包的一个片段，也可能只是因为它被定义为处理某个子集。无论出于何种原因，如果ciphersuite处理的数据少于完整的原始数据包有效负载，“第一个”PCB必须在ciphersuite参数中指定受保护的数据包有效负载字节。
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密码套件必须指定要加密的块。该规范可能是灵活的，并且取决于块类型、安全策略、各种数据值和其他输入，但它必须是确定性的。块是否要加密的确定不能含糊不清。
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实例，“第一个块”必须包含适用于此相关器的所有实例的任何可选字段（例如，安全目的地等）。这些必须包含在第一个实例中，并且不得在其他相关块中重复。特定于PCB特定实例的字段可能会出现在该PCB中。例如，安全结果字段可能（也可能会）包含在多个相关PCB实例中，每个结果特定于该特定块。类似地，几个PCB可能每个都包含一个ciphersuite参数字段，该字段具有特定于该PCB实例的IV。
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、参数等的“第一个”PCB，如上所述。通常，此PCB将在捆绑包的早期出现。此“第一”PCB包含应用于有效负载以及其他相关PCB的参数。相关PCB遵循“第一个”PCB，不得重复第一个PCB的ciphersuite参数、安全源或安全目标字段。这些相关的PCB不需要紧跟在“第一个”PCB之后，而且可能不会这样做。封装加密PIB或PCB的每个相关块与原始PIB或PCB在捆绑包中的位置相同。
A ciphersuite MUST NOT mix payload data and a non-payload block in a single PCB.
密码套件不得在单个PCB中混合有效负载数据和非有效负载块。
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列表项。这对于在安全目的地正确更新条目至关重要。
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
在安全目的地，无论是特定目的地还是捆绑目的地，上述过程都是反向的。有效负载使用第一个PCB中的salt、IV和键值“就地”解密，包括使用ICV进行验证。第2.6节中描述了这些值。每个相关PCB也在同一个目的地进行处理，使用来自第一个PCB和块特定IV项的salt和键值。安全结果中封装的块项将被解密和验证，同时使用应附加到原始块数据密文中的标记。假设验证成功，结果
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.
纯文本是原始块的全部内容，在捆绑包中的同一位置替换PCB。块类型恢复为封装前的原始块类型，其他特定于块的数据字段也恢复为其原始值。实施者需要注意的是，这种“替换”过程需要精细的缝合，因为未封装块中的EID列表内容无效。如上所述，原始块中的EID列表引用保留在“替换”PCB中，并将在包访问DTN时根据需要进行更新。来自PCB的参考必须替换新解封块EID列表中的参考。警告实施者。
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）。
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].
有时需要以应用于捆绑负载的方式以外的方式保护捆绑包的某些部分。一个这样的例子是捆绑元数据，它可能指定有效负载中的数据类型，但不指定实际的有效负载详细信息，如[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通常用于应用保密保护。虽然可以创建仅完整性的密码套件，但块保护是不透明的，这使得访问数据更加困难。为简单起见，本讨论介绍了保密密码套件的使用。
The protection mechanisms in ESBs are similar to other security blocks with two important differences:
ESB中的保护机制与其他安全块类似，但有两个重要区别：
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密码套件将使用随机生成的临时密钥对扩展块进行加密，并使用安全参数字段中的密钥信息项携带使用某种长期密钥加密密钥（KEK）或众所周知的公钥加密的密钥。如果目标和安全目标均未解析用于解密的密钥，则ciphersuite参数字段中的密钥信息项也可用于指示可用于恢复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.
强烈建议将数据完整性机制与保密性结合使用，并且不要使用仅加密的密码套件。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。第2.4节描述了EID列表条目（如果有）的处理，为了正确恢复EID，必须遵循这一点。
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标志指示此块中存在哪些字段。CiffSub设计者应该仔细考虑设置标志的效果，即在无法处理该块的情况下，丢弃块或删除包。
EID-references MUST be stored in the EID-reference list.
EID引用必须存储在EID引用列表中。
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.
安全源可能存在。安全源也可以指定为第2.6节所述密钥信息的一部分。如果两者都不存在，则将捆绑源用作安全源。
The security-destination MAY be present. If not present, then the bundle-destination is used as the security-destination.
安全目的地可能存在。如果不存在，则将捆绑目标用作安全目标。
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.
安全参数可以可选地包含块类型代码字段，以指示封装块的类型。由于这会复制块的加密部分中的字段，因此存在轻微的安全风险，因此其使用是可选的。
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.
各种密码套件在安全参数和/或安全结果字段中包含若干项。可能出现的项目由特定的密码套件描述定义。一个密码套件可以在一个块中支持多个相同类型的实例。
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.
每个项都表示为类型长度值。类型是一个单字节，指示这是哪个项。Length是要跟随的数据字节数，是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 片段范围：一对SDNV值（偏移量然后是长度），指定应用特定操作的有效负载字节范围。这被称为“片段范围”，因为这是它的典型用途，即使有时它描述的子集范围不是片段。偏移量值必须是原始捆绑包中的偏移量，如果当前捆绑包已经是一个片段，则该偏移量可能不是当前捆绑包中的偏移量。
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 salt：某些保密套件使用的类似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）：某些机密性密码套件操作的输出，用于在目的地验证受保护数据是否未被修改。
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 封装块：对某些块进行保密操作的结果，包含块的密文，还可能包含附加到密文的完整性检查值；如果加密模式需要，还可以包含填充；仅用于非有效负载块。
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.
本规范致力于保持安全协议和密钥管理之间的分离。然而，这两者在将密钥信息等从安全源传输到安全目的地的过程中相互作用。分离的目的是促进各种密钥管理系统的使用，而无需为每个系统单独定制密码套件。
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.
密钥管理过程处理长期密钥、长期密钥的说明符、长期密钥的证书以及使用长期密钥的完整性签名。ciphersuite本身不需要了解这些信息，如果它将这些信息视为不透明的实体，并由密钥管理流程处理，则可以改进分离。
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
密钥管理过程专门涉及第2.6节中定义的两个项目的内容：密钥信息（项目类型3）和完整性签名（项目类型5）。密码套件必须定义这些项目的详细信息和格式。促成
interoperability, it is strongly RECOMMENDED that the implementations use the appropriate definitions from the Cryptographic Message Syntax (CMS) [RFC5652] and related RFCs.
互操作性，强烈建议实现使用加密消息语法（CMS）[RFC5652]和相关RFC中的适当定义。
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.
许多情况下需要几条关键信息。同样，密码套件必须定义它们是否接受打包成单个密钥信息项和/或分离成多个密钥信息实例的密钥信息。为了实现互操作性，建议密码套件接受打包到单个密钥信息项中的这些信息，并且还可以选择接受它们作为单独的项发送。
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的应用程序——correlator值允许单独处理安全服务的多个应用程序。由于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.
一般来说，我们无法防止所有此类问题，因为我们不能假设每个ciphersuite定义都考虑了所有其他ciphersuite定义。但是，我们可以通过要求应用于PIB或PCB的一个实例的任何密码套件必须应用于具有相同相关器的所有实例来限制此类问题的可能性。
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.
加密隧道-单个捆绑包在到达目的地的途中可能会多次加密。显然，它必须被解密相同的次数，但我们可以想象每一次加密都代表进入隧道的另一层。这是通过使用多个PCB实例来支持的，但是有效负载经过多次加密，“就地”。根据ciphersuite的定义，其他块可以也应该加密，如上文和第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.
多个并行身份验证程序-单个安全源可能希望以多种方式保护捆绑包的完整性。如果捆绑包的路径不可预测，并且可能涉及各种节点作为安全目标，则可能需要这样做。类似地，如果安全源无法提前确定要使用哪些算法，那么使用all可能是合理的。这将导致PIB的使用，据推测，所有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都保护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.
经过身份验证和加密的捆绑包-单个捆绑包可能需要身份验证和机密性。一些规范首先应用验证器，然后加密有效负载和验证器。如前所述，在验证器是签名的情况下，这种排序有安全原因。（参见第4.3节中定义的PCB-RSA-AES128-PAYLOAD-PIB-PCB密码套件。）其他人在加密后应用验证器，即对密文。通常建议使用此顺序，并将在某些情况下可能导致恢复加密密钥的攻击降至最低。
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实例，但这些是本规范支持的“核心”集。话虽如此，正如将要看到的，这里定义的强制密码套件在限制相关器机制提供的灵活性方面是非常具体和限制性的。这主要是为了使本规范尽可能简单，同时支持上述场景。
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节所定义。
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.
所有节点都充当策略实施点（PEP），因为它们实施的策略可能会限制捆绑节点向网络注入流量的权限。策略可应用于源于当前节点的流量、终止于当前节点的流量以及将由当前节点转发给其他节点的流量。如果本地或远程发起的特定传输请求满足节点的一个或多个策略并因此被接受，则可以创建并调度出站捆绑包。如果不是，则作为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.
策略强制代码可以覆盖此处和本文档其他地方描述的所有其他处理步骤。例如，实现始终尝试连接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.
节点必须参考其安全策略，以确定接收到的捆绑包在转发之前应满足的标准。这些标准必须包括确定接收的捆绑包是否必须包含有效的BAB、PIB、PCB或ESB。如果捆绑包不符合节点的策略标准，则必须丢弃捆绑包，不再进一步处理；在这种情况下，可能会生成指示故障的捆绑状态报告。
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.
节点的策略可能会要求节点添加或减去一些安全块。例如，它可能要求节点尝试为某个安全目标加密捆绑包（部分），或者添加PIB。如果节点的策略要求将BAB添加到捆绑包中，则必须最后添加BAB，以便其安全结果的计算可以考虑捆绑包中所有其他块的值。
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.
捆绑包安全操作的处理顺序对于成功完成操作至关重要。通常，在发起节点执行的操作必须在目标节点以相反的顺序执行。有一些变化和例外情况，如下所述。
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.
序列在捆绑包中安全块的顺序中维护。因此，无论转发节点是否支持安全协议，都不能在转发节点上重新排列块。参与此排序的唯一块是主块和有效负载块，以及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）的方式添加到包中或从包中移除，堆栈顶部紧跟在主块之后。新创建的bundle只有主块和有效负载块，堆栈为空。当为包请求安全操作时，安全块会在主块之后立即推送到堆栈上。早期操作的安全块靠近有效负载，后期操作的安全块靠近主块。这些操作当时只处理捆绑包中的那些块，因此，例如，第一个要添加的操作只处理有效负载和主块，下一个操作可能会处理第一个（如果选择）和有效负载和主块，依此类推。要添加的最后一个块可以处理所有块。
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.
第一个问题很常见，也很容易处理。捆绑包可能被间接发送到其目的地，需要几个转发跃点才能最终到达目的地。安全处理在每个节点上进行，假设该节点支持捆绑安全。在下面的讨论中，我们假设创建了一个bundle，并对其应用了机密性、负载完整性以及最后的bundle身份验证。因此，块序列将是主要的BAB PIB PCB有效载荷。从源到目的地的旅行需要经过一个中间节点，因此旅行由两个跳组成。
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
当在中间节点接收到包时，接收处理将验证BAB并将其从堆栈中弹出。然而，PIB和PCB的最终目的地是它们的安全目的地，因此它们不能被处理和移除。然后，中间节点使用包中剩余的四个块开始发送过程。出站处理添加任何
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.
本地策略所需的安全块，这些安全块在主块之后、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可能更复杂。节点的安全策略指定捆绑包的安全要求。该策略可能会导致对当前节点上的捆绑应用一个或多个安全操作，每个操作都有自己的安全目标。在后续节点上应用策略可能会导致额外的安全操作，每个操作都有一个安全目标。安全块（BAB、PIB和PCB，而不是ESB）中的安全目的地列表创建了节点的偏序，这些节点必须在前往捆绑目的地的途中访问。
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.
捆绑安全方案不处理部分但不完全重叠的安全路径。节点的安全策略必须避免为捆绑包指定导致与该捆绑包中任何现有安全目标冲突的安全目标。这将在第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.
第二个问题涉及某些安全过程操作的可逆性。一般来说，这些操作分为两类：不影响捆绑包其他部分的操作和完全可逆的操作。例如，创建捆绑签名不会更改捆绑内容，结果除外。作为机密性处理的一部分执行的加密确实会更改捆绑包，但目标位置的反向处理会恢复原始内容。
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
第三类是包内容以非破坏性的方式发生了轻微更改，但没有任何机制可以逆转更改。最简单的示例是向安全块添加EID引用。添加引用会将文本添加到捆绑包的字典中。文本也可能被其他引用使用，因此删除块和此特定EID引用不会导致从字典中删除文本。此缺陷对上述“顺序”或“包装”安全方案没有影响，但确实会导致“并行”身份验证机制失败。解决办法
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.
问题是特定于实现的，通常涉及多个过程处理，以便在一个阶段添加块，并在整个过程的稍后阶段计算安全结果。
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必须始终在所有其他BAB之后推到堆栈上。
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”）需要第二个相关块来包含安全结果，该块放在有效负载之后，通常作为捆绑包中的最后一个块。我们甚至可以将堆栈规则应用于这些块，方法是指定在将它们的“所有者”或“父”块推送到堆栈上的同时将它们添加到包的末尾。事实上，它们从有效载荷开始形成一个堆栈，但朝着另一个方向增长。此外，并非主堆栈中的所有块在后续堆栈中都有相应的条目。必须跟随有效负载的唯一块是那些由CipherSuite强制作为相关块来保存安全结果的块。有效负载块之后不需要其他块，因此不建议它们这样做。
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可能相互关联，因此“无重新排序”要求也适用于它们。
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.
BAB总是用于单跳，这些受限路径不会导致冲突。
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").
另一个常见场景是两个子网之间的网关到网关流量保护（“隧道模式”）。
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所示的简化版本，我们可以将BN2和BN3视为连接标记为“internet”的两个子网的网关。只要它们为BN2-BN3路径提供安全性，一切都很好。例如，当BN2添加以BN4作为安全目的地的块，并且发起节点BN1创建了以BN3作为安全目的地的块时，问题就开始了。我们现在有两条路径，它们都不是另一条路径的子集。
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为安全目标的块来防止这种情况。此策略不应指定比任何现有安全目标更远的安全目标。
+---------v-| +->>>>>>>>>>v-+ +->>>>>>>>>>v-+ +-^---------+
| BN1 v | | ^ BN2 v | | ^ BN3 v | | ^ BN4 |
+---------v-+ +-^---------v-+ +-^---------v-+ +-^---------+
>>>>>>>>^ >>>>>>>>>>^ >>>>>>>>^
+---------v-| +->>>>>>>>>>v-+ +->>>>>>>>>>v-+ +-^---------+
| BN1 v | | ^ BN2 v | | ^ BN3 v | | ^ BN4 |
+---------v-+ +-^---------v-+ +-^---------v-+ +-^---------+
>>>>>>>>^ >>>>>>>>>>^ >>>>>>>>^
<------------- BN1 to BN3 path ------------>
<------------- BN1 to BN3 path ------------>
<------------- BN2 to BN4 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与新包一起创建一个（“PIa”），BN2在堆栈上推送自己的PIB“PIB”，安全目标为BN4。当这个包到达BN3时，包块是
primary - PIb - PIa - payload
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必须保留在捆绑包中。这就是为什么安全块被视为堆栈，并且只允许在堆栈顶部进行添加/删除操作。
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
如果安全问题是保密性，并且使用第4.3节所述的保密密码套件3（“PC3”）使用多氯联苯，情况会更糟。在这种情况下，BN1将使用BN3作为安全目标对包进行加密，BN2将通过超级加密有效负载并封装安全目标BN4的PC3块来创建重叠的安全路径。BN3转发所有块，不做任何更改。BN4解密有效载荷
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.
从它的超级加密和解除封装的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.
在“隧道模式”场景中，两个子网络通过网络通过隧道连接，网关可以各自指定另一个作为安全目的地，否则应谨慎。
BAB is never a problem because it is always only a single hop.
BAB从来都不是问题，因为它始终只是一个单跳。
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，则为最外层的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值时输入的位一样。因此，节点不得更改字典字段中任何URI[RFC3986]的编码，例如，将某些HTTP URL的DNS部分从小写改为大写。由于捆绑包在传输过程中可能会被修改（正确或由于实现错误），因此必须定义任何给定捆绑包（包含BAB或PIB）的规范形式。
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节密码套件中使用的束规范化算法。其他密码套件可以使用这些或定义自己的规范化过程。
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密码套件。该算法在概念上按照给出的顺序关联所有块，但省略此密码套件类型块中的所有安全结果数据字段。也就是说，当BAB密码套件指定此算法时，我们会忽略所有BAB密码套件的所有BAB安全结果。当PIB密码套件指定此算法时，我们将忽略所有PIB密码套件的所有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 在上面，我们指定省略安全结果数据。这意味着不会输入任何字节的安全结果数据。我们不会将安全结果长度设置为零。相反，我们假设在计算安全结果之前，实现密码套件的模块将知道安全结果长度，并且要求该值位于安全结果长度字段中，即使安全结果数据本身将被忽略。
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 BAB总是在PIB之后添加到捆绑包中，因此，当PIB密码套件指定此严格规范化算法并且PIB与包含一个或多个BAB的捆绑包一起接收时，作为PIB安全结果验证过程一部分的严格规范化应用要求完全忽略捆绑包中的所有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.
此算法旨在保护捆绑包中不应在传输过程中更改的部分。因此，它省略了包的可变部分。
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.
基本方法是定义主块的标准形式，并按照传输顺序将其与安全（仅限PIB和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字节固定宽度字段。选择8字节的大小是因为实现可能会将较大的值视为无效，如[DTNBP]中所述。
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所示。本质上，它取消引用字典块，在必要时调整长度，并忽略可能在传输过程中更改的标志。
+----------------+----------------+----------------+----------------+
| 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 |
+----------------+----------------+----------------+----------------+
+----------------+----------------+----------------+----------------+
| 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，包括服务类别（COS）和状态报告请求（SRR）字段。为了规范化，SDNV被解压到一个固定宽度的字段中，并且一些位被屏蔽掉。解包字段与掩码0x0000 0000 0007 C1BE进行and运算，将所有保留位和“bundle is a fragment”位设置为零。
The canonical primary block length value is a four-byte value containing the length (in bytes) of this structure, in network byte order.
规范主块长度值是一个四字节值，包含此结构的长度（以字节为单位），按网络字节顺序排列。
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的长度（按网络字节顺序为四字节值）和值。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）和生存期（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.
片段偏移量和总应用程序数据单元长度被忽略，就像上面提到的“bundle是片段”位一样。如果要规范化的有效负载数据小于完整的原始捆绑负载，则在安全参数中指定偏移量和长度。
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.
对于规范化中包含的非主块，用于规范化的块处理控制标志值是未打包的SDNV值，保留位和可变位屏蔽为零。解包值使用掩码0x0000 0077与零保留位和“最后一个块”标志进行and运算。忽略“last block”（最后一个块）标志，因为BABs和其他安全块可能会添加到行程的某些部分，但不会添加到其他部分，因此此位的设置可能会随着跳数的变化而变化。
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参数来指定有效负载的哪一部分受到保护，如下所述。
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。
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 如果任何节点重写字典内容（例如，将HTTP URL的DNS部分从小写改为大写），URI编码将导致错误。当使用一套软件将捆绑包同步到磁盘，然后从磁盘读取并由第二套软件转发时，这种情况可能会透明地发生。由于没有规范化URI（或IRI）的一般规则，因此此问题可能是完整性失败的不可避免的原因。
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字节未打包值。长度字段被规范化为网络字节顺序的四字节值。编码不需要优化，因为值从未通过网络发送。
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
如果在应用PIB之前对捆绑包进行了分段，则PIB将应用于一个片段，而不是整个捆绑包。然而，受保护的片段可能随后进一步分段，这将使验证器无法知道哪些字节受到保护
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提供。即使在没有碎片的情况下，如果密码套件被定义为允许保护少于整个原始捆绑负载，则同样的情况也适用。
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密码套件必须在密码套件参数中指定捆绑负载的哪些字节受到保护。当进行验证时，只有指定范围的有效负载字节被输入到PIB验证。指定的密码套件仅适用于整个捆绑包而不适用于片段是有效的。可以指定密码套件仅应用于有效负载的一部分，而不管有效负载是片段还是完整的原始捆绑负载。
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参数的一部分，支持对片段应用机密性的ciphersuite必须指定捆绑负载的哪些字节受到保护。解密片段时，只处理指定的字节。指定的保密密码套件仅适用于整个捆绑包而不适用于片段也是有效的。
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密码套件，该套件具有可变规范化的替代版本，用于主块中的任何字段。
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（在dictionary字段中），并且不能加密。如果需要端点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.
同样，保密要求也可能适用于主要区块的其他部分（例如，当前托管人），并以相同的方式得到支持。
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。如果捆绑包没有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，但没有，则必须丢弃捆绑包，不再进一步处理。如果捆绑包需要有BAB，但其所有BAB都将接收节点以外的节点标识为BAB安全目的地，则必须丢弃捆绑包，不再进一步处理。
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将接收节点标识为BAB安全目的地，或者没有安全目的地，则必须根据ciphersuite规范验证BAB的安全结果字段中的值。如果对于捆绑包中的所有此类BAB，无法确定BAB安全源或安全结果值检查失败，则捆绑包无法进行身份验证，必须丢弃捆绑包，不再进一步处理。如果存在任何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。可根据政策要求添加新的BAB。这可能需要更正待转发捆绑包的“最后一个块”字段。
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.
捆绑包的进一步处理必须按照从主块到有效负载块的各个块指示的顺序进行，除非适用规范另有规定。
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
如果捆绑包有一个PCB，并且接收节点是捆绑包的PCB目标（因为该节点被列为捆绑包的PCB目标，或者因为该节点被列为捆绑包目标，并且没有PCB目标），则该节点必须根据ciphersuite规范解密捆绑包的相关部分。应删除PCB。如果捆绑包的相关部分无法解密（即无法推导解密密钥或解密失败），则必须丢弃捆绑包，不再进一步处理；在这种情况下，可能会生成指示解密失败的包删除状态报告（请参阅包协议规范[DTNBP]）。如果PCB安全性结果
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的捆绑包中。
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，且接收节点是捆绑包的PIB目的地（因为该节点列在捆绑包的PIB目的地中，或者因为该节点列为捆绑包目的地且没有PIB目的地），则该节点必须验证PIB安全结果字段中的值根据ciphersuite规范。如果所有检查都失败，则捆绑包无法进行身份验证，应根据安全策略处理捆绑包。可能会生成指示故障的捆绑包状态报告。否则，如果PIB进行验证，则捆绑包已准备好进行交付或转发处理。在转发包之前，节点应根据第3.2节的要求从包中移除PIB，除非某些下游节点可能也能够验证PIB。
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 dest，则接收节点可尝试验证安全结果字段中的值。如果能够进行检查，但检查失败，则节点应丢弃捆绑包，并可发送指示故障的捆绑包状态报告。
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目标），节点必须根据ciphersuite规范对封装块进行解密和/或解封。解除封装的块替换捆绑包块序列中的ESB，从而删除ESB。如果无法解密内容（即，无法推导解密密钥或解密失败），则可能会丢弃捆绑包，不再进一步处理，除非安全策略另有规定。在这种情况下，可能会生成指示解密失败的包删除状态报告（请参阅包协议规范[DTNBP]）。
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.
应用程序可以请求（以特定于实现的方式）将节点注册为端点的成员，并将接收到的以该端点为目的地的捆绑包交付给该应用程序。
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.
每个收到的捆绑包最多有一个副本发送给应用程序。如果未选择此选项，则应用程序表示希望节点将所有接收到的捆绑包副本交付给应用程序。如果选择此选项，则节点最多应向应用程序交付每个接收包的一份副本。如果未选择该选项，则节点应根据策略交付所有捆绑包。
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.
为了实现这一点，节点必须查看接收到的每个完整（如有必要，重新组装）捆绑包的源/时间戳对值，并确定之前是否已接收到唯一标识捆绑包的这对值。如果有，则该捆绑包是重复的。如果没有，则该捆绑包不是重复的。源/时间戳对应添加到该节点已接收的对值列表中。
Each node implementation MAY decide how long to maintain a table of pair value state.
每个节点实现可以决定维护一个对值状态表的时间。
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]中描述的分段规则。正如此处所定义并在此处重复的完整性，只有有效载荷可以被分割；与所有扩展块一样，安全块永远不能被分割。此外，还需要以下特定于安全性的处理：
The security policy requirements for a bundle MUST be applied individually to all the bundles resulting from a fragmentation event.
捆绑包的安全策略要求必须单独应用于由碎片事件产生的所有捆绑包。
If the original bundle contained a PIB, then each of the PIB instances MUST be included in some fragment.
如果原始捆绑包包含一个PIB，那么每个PIB实例都必须包含在某个片段中。
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.
如果原始捆绑包包含一个或多个PCB，则包含关键信息项的任何PCB实例都必须设置“在每个片段中复制”标志，从而在每个片段中复制。这是为了确保在重新组装期间可以恢复规范块序列。
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].
如果原始捆绑包包含一个或多个不包含关键信息项的相关PCB，则每个PCB必须包含在某个片段中，但不应发送多次。必须按照[DTNBP]中描述的碎片规则将其放置在碎片中。
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.
注意：在这个阶段或以后的阶段，不同的片段可能会添加额外的安全块，并且相关器可能会发生冲突。为了促进唯一性，密码套件应包括片段的片段偏移量，作为相关器的高阶组件。
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.)
当已接收到部分捆绑包时，接收节点应参考其安全策略，以确定其是否可以分割捆绑包，将接收到的部分转换为捆绑包片段，以便进一步转发。是否允许反应碎片化取决于安全策略和用于计算BAB身份验证信息的密码套件（如需要）。（一些BAB密码套件，即强制性的BAB-HMAC（散列消息认证码）第4.1节中定义的密码套件不适用于反应碎片，因为BAB中的安全结果要求对整个捆绑包进行签名。但是，可以想象，可以定义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密码套件属于适当的类型（例如，有效负载中嵌入了多个安全结果），则必须在收到的部分有效负载中的最后一个安全结果值之后立即分段捆绑包。必须删除在最后一个安全结果值之后接收的任何数据。
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.
如果在中间接收器处接收到部分捆绑包，并且该部分捆绑包被反应性地分段和转发，则只有未接收到的捆绑包部分必须重新传输，尽管该捆绑包的更多部分可以重新传输。在重新传输捆绑包的一部分之前，应将其更改为碎片，如果原始捆绑包包括BAB，则碎片捆绑包也必须更改，并应重新计算其BAB。
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.
一个有趣的可能性是密码套件定义，这样后续片段的传输将伴随有效负载的签名，直到重新启动点。
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.
对密码攻击恢复力的评估必然取决于为批量数据保护和密钥传输选择的算法。下一节中描述的强制密码套件使用AES、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.
本节定义了本规范的强制性密码套件。目前，BAB、PIB、PCB和ESB每种安全块类型都必须使用一个密码套件。BAB密码套件基于使用HMAC的共享机密。PIB密码套件基于使用RSA和SHA-256的数字签名。PCB和ESB密码套件基于使用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 eContent的所有用途中，要使用的相关eContentType是[RFC5652]中规定的id数据。
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.
密码套件使用加密消息语法（CMS）[RFC5652]中定义的机制打包密钥、签名等，以便在适当的安全块中传输。CMS对象中的数据不是捆绑数据，这是CMS的典型用法。相反，CMS打包的“消息数据”是密码套件核心代码中使用的临时密钥、消息摘要等。
In all cases where we use CMS, implementations SHOULD NOT include additional attributes whether signed or unsigned, authenticated or unauthenticated.
在我们使用CMS的所有情况下，实现不应包括附加属性，无论是已签名的还是未签名的、已验证的还是未验证的。
The BAB-HMAC ciphersuite has ciphersuite ID value 0x001.
BAB-HMAC密码套件具有密码套件ID值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的两个相关实例。它涉及将第一个BAB实例（如第2.2节所定义）放置在主块之后。BAB的第二个（相关）实例必须放在包中所有其他块（可能其他BAB块除外）之后。
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将是捆绑包的第二个和最后一个块。如果转发器希望应用多个相关BAB对，则可以这样做。没有要求每个应用程序“包装”其他应用程序，但转发器必须在规范化之前插入所有“前端”BAB及其“后端”合作伙伴（没有任何安全结果）。
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.
安全结果是HMAC-SHA1计算的输出，输入是通过严格规范化算法运行整个包的结果。在规范化之前，必须将两个必需的BAB实例都包含在包中。
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).
此方案中的安全参数是可选的，但如果使用，则唯一可以显示的字段是密钥信息（参见第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.
在缺少密钥信息的情况下，期望接收方能够基于发送标识找到正确的密钥。发送标识可以从安全源字段或捆绑包中前一跳块的内容中得知。还可以使用特定于实现的手段（例如收敛层）来确定。
The PIB-RSA-SHA256 ciphersuite has ciphersuite ID value 0x02.
PIB-RSA-SHA256密码套件具有密码套件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
PIB-RSA-SHA256使用第3.4.2节中的可变规范化算法，仅“当前”块的安全结果数据字段被排除在规范形式之外。这个
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的单个实例。
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中的签名字段是安全结果字段，因此整个密钥信息项必须放在块的安全结果字段中，而不是放在安全参数中。
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.
如果正在签名的捆绑包在签名之前已被分段，那么我们必须指定签名的字节，以防签名的捆绑包随后再次分段。如果捆绑包是一个片段，则ciphersuite参数必须包括一个片段范围字段，如第2.6节所述，指定带符号片段的偏移量和长度。如果整个包都有符号，则必须省略这些数字。
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”类型，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.
根据[RFC4055]第5节中针对id-SHA256签名方案的规定，RSA与SHA256一起使用。签名过程的输出是PIB的SignatureValue字段。
"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密码套件具有密码套件ID值0x003。
This scheme encrypts PIBs, PCBs, and the payload. The key size for this ciphersuite is 128 bits.
该方案加密PIB、PCB和有效负载。此密码套件的密钥大小为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]所述，在伽罗瓦/计数器模式（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加密操作有四个输入：一个密钥、一个初始化向量（IV）、一个明文和一个用于附加认证数据（AAD）的输入，这里不使用。它有两个输出，一个长度与明文相同的密文和一个身份验证标签，也称为完整性检查值（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。同一个键和nonce组合不能使用多次。nonce具有以下布局：
+----------------+----------------+----------------+----------------+
| salt |
+----------------+----------------+----------------+----------------+
| |
| initialization vector |
| |
+----------------+----------------+----------------+----------------+
+----------------+----------------+----------------+----------------+
| 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.
盐场是一个四个八位组的值，通常是随机选择的。对于具有相同相关器值的所有PCB，该值必须相同。盐不必保密。
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）是八个八位组的值，通常是随机选择的。对于具有相同相关器值的所有PCB，它必须不同。价值不需要保密。
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.
密钥（bundle encryption key，BEK）是一个16个八位组（128位）的值，通常是随机选择的。该值必须保密，如下所述。
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
此密码套件需要使用单个PCB实例来处理负载机密性。如果捆绑包已包含PIB或PCB，则密码套件将创建额外的相关块来保护这些PIB和PCB。这些“附加”块以一对一的方式替换原始块，因此块的数量
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”指的是单个PCB，如果只有一个，或者如果有多个PCB，则指包含关键信息的PCB。这一定是第一套。
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.
第一个PCB-第一个PCB可能包含一个相关器值，并且可能在EID列表中指定安全源和/或安全目标。如果未指定，则与其他密码套件一样，分别将捆绑包源和捆绑包目标用于这些值。块必须包含安全参数和安全结果字段。每个字段可能包含多个项目，其格式如第2.6节所述。
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必须包含一个相关器值，以将其链接到第一个PCB。安全源和安全目的地由第一PCB暗示；但是，请参见第2.4节中关于EID列表条目的讨论。它们必须包含安全参数和安全结果字段，如下所示：
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中的安全参数和安全结果字段不得包含除这两项之外的任何项目。钥匙和盐等物品在第一块PCB中提供，不得重复。
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节中定义的“封装数据”类型，RecipientInfo类型KeyTransRecipientInfo包含适当证书的颁发者和序列号。它们可能支持其他RecipientInfo类型。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参数必须包括片段范围字段，如第2.6节所述，指定加密片段的偏移量和长度。请注意，这与主块中显示的“偏移和长度”字段对不同。本例中的“长度”是片段的长度，而不是原始长度。如果bundle不是片段，则必须省略此字段。
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.
对于有效负载，只有bundle payload字段的字节会受到影响，并被密文替换。第一个PCB中指定的salt、IV和key值用于加密有效负载，并且生成的身份验证标签（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放置在输出线束中的相同位置。如上所述，这是一对一的替换，并且没有以任何方式合并块或混合数据。
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.
加密过程使用AES-GCM和来自第一块PCB的salt和密钥值，以及该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.
如果有效负载在加密后被分割，那么在解密之前，所有这些片段都必须存在并重新组装。如果发生了多个碎片化操作，此过程可能会在不同的目标重复数次。
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字节，约半TB。本规范的未来版本将解决处理超过此尺寸的有效载荷的问题。
The ESB-RSA-AES128-EXT ciphersuite has ciphersuite ID value 0x004.
ESB-RSA-AES128-EXT密码套件具有密码套件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或主要或有效负载块。此密码套件的密钥大小为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]所述，在伽罗瓦/计数器模式（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认证加密操作有四个输入：一个密钥、一个初始化向量（IV）、一个明文和一个附加认证数据的输入（AAD），这里不使用。它有两个输出，一个长度与明文相同的密文和一个身份验证标签，也称为完整性检查值（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。同一个键和nonce组合不能使用多次。nonce具有以下布局：
+----------------+----------------+---------------------------------+
| salt |
+----------------+----------------+---------------------------------+
| |
| initialization vector |
| |
+----------------+----------------+---------------------------------+
+----------------+----------------+---------------------------------+
| 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.
盐场是一个四个八位组的值，通常是随机选择的。对于具有相同相关器值的所有ESB，该值必须相同。盐不必保密。
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）是八个八位组的值，通常是随机选择的。对于具有相同相关器值的所有ESB，它必须不同。价值不需要保密。
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位）的值，通常是随机选择的。该值必须保密，如下所述。
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.
此密码套件使用“替换”ESB替换要保护的每个BP扩展块，每个扩展块都可以单独指定。
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扩展块，则可以将它们分组为一个相关集，并使用单个密钥进行保护。这些块以一对一的方式替换原始块，因此块的数量保持不变。所有这些相关块必须具有相同的相关器值。如果只有一个ESB，则本节中的术语“first ESB”指单个ESB；如果有多个ESB，则指包含密钥或密钥标识符的ESB。这一定是第一套。如果块是单独指定的，则不存在相关集，每个块都是自己的“第一个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.
第一个ESB—第一个ESB可能包含一个correlator值，并可能在EID列表中指定安全源和/或安全目标。如果未指定，则与其他密码套件一样，分别将捆绑包源和捆绑包目标用于这些值。块必须包含安全参数和安全结果字段。每个字段可能包含多个项目，其格式如第2.6节所述。
Security-parameters
安全参数
key-information
关键信息
salt
盐
IV for this specific block
IV针对该特定区块
block type of encapsulated block (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必须包含一个correlator值，以将它们链接到第一个ESB。安全源和安全目的地由第一个ESB隐含；但是，请参见第2.4节中关于EID列表条目的讨论。后续ESB必须包含以下安全参数和安全结果字段：
Security-parameters
安全参数
IV for this specific block
IV针对该特定区块
block type of encapsulated block (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中的安全参数和安全结果字段不得包含所列以外的任何项目。密钥信息和salt等项是在第一个ESB中提供的，不能重复。
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节中定义的“封装数据”类型，RecipientInfo类型KeyTransRecipientInfo包含适当证书的颁发者和序列号。它们可能支持其他RecipientInfo类型。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与原始块放在传出包中的相同位置。如上所述，这是一对一的替换，并且没有以任何方式合并块或混合数据。
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.
加密过程使用AES-GCM和来自第一个ESB的salt和密钥值以及此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相同的correlator值。它还包含安全参数中特定于块的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:
延迟容忍网络中的密钥管理被认为是一个难题，本规范并未试图解决这个问题。但是，仅为了支持实施和测试，实施应支持：
o The use of well-known RSA public keys for all ciphersuites.
o 对所有密码套件使用著名的RSA公钥。
o Long-term pre-shared-symmetric keys for the BAB-HMAC ciphersuite.
o BAB-HMAC密码套件的长期预共享对称密钥。
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扩展中），因此实现应该支持这种分发公钥的方式。RFC 5280不坚持实现包括撤销检查。在DTN的上下文中，某些节点很可能无法使用撤销检查服务（证书撤销列表（CRL）或在线证书状态协议（OCSP）），在规划任何公钥基础设施以支持此规范时，部署应考虑到这一点。
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:
每个节点都充当一个策略实施点，因为它通过一个或多个汇聚层协议实现实施一些策略，这些策略控制捆绑包的转发和交付。因此，无论策略是明确的还是默认的，每个节点都应拥有并根据其自己的可配置安全策略进行操作。该政策应规定：
Under what conditions received bundles SHALL be forwarded.
在何种情况下，收到的包裹应被转发。
Under what conditions received bundles SHALL be required to include valid BABs.
在何种条件下，收到的捆包应包括有效的BAB。
Under what conditions the authentication information provided in a bundle's BAB SHALL be deemed adequate to authenticate the bundle.
在何种情况下，捆绑包的BAB中提供的认证信息应被视为足以对捆绑包进行认证。
Under what conditions received bundles SHALL be required to have valid PIBs and/or PCBs.
在何种条件下，收到的捆包应具有有效的PIB和/或PCB。
Under what conditions the authentication information provided in a bundle's PIB SHALL be deemed adequate to authenticate the bundle.
在何种情况下，捆绑包PIB中提供的认证信息应被视为足以对捆绑包进行认证。
Under what conditions a BAB SHALL be added to a received bundle before that bundle is forwarded.
在何种情况下，在转发收到的包之前，应将BAB添加到该包中。
Under what conditions a PIB SHALL be added to a received bundle before that bundle is forwarded.
在何种情况下，应在转发收到的捆绑包之前将PIB添加到该捆绑包中。
Under what conditions a PCB SHALL be added to a received bundle before that bundle is forwarded.
在何种情况下，在转发收到的捆绑包之前，应将PCB添加到该捆绑包中。
Under what conditions an ESB SHALL be applied to one or more blocks in a received bundle before that bundle is forwarded.
在什么条件下，在转发一个已接收包之前，ESB应应用于该包中的一个或多个块。
The actions that SHALL be taken in the event that a received bundle does not meet the receiving node's security policy criteria.
当接收到的捆绑包不符合接收节点的安全策略标准时应采取的措施。
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:
如果给定节点未指定安全策略，或仅部分指定了安全策略，则该节点关于未指定标准的默认策略应包括以下内容：
Bundles that are not well-formed do not meet the security policy criteria.
格式不正确的捆绑包不符合安全策略标准。
The mandatory ciphersuites MUST be used.
必须使用强制密码套件。
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.
收到的所有捆绑包都必须具有BAB，该BAB必须经过验证以包含有效的安全结果。如果捆绑包没有BAB，则必须丢弃捆绑包，不再进一步处理；可能会生成指示身份验证失败的捆绑包状态报告。
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；但是，如果收到的捆绑包确实有PIB，则可以忽略PIB，除非接收节点是PIB目的地，在这种情况下，必须验证PIB。
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；但是，如果接收到的束确实有PCB，则可以忽略PCB，除非接收节点是PCB目标，在这种情况下，必须处理PCB。如果处理PCB产生PIB，则该PIB应由节点根据节点的安全策略进行处理。
A PIB SHALL NOT be added to a bundle before sourcing or forwarding it.
采购或转发前，不得将PIB添加到捆绑包中。
A PCB SHALL NOT be added to a bundle before sourcing or forwarding it.
在采购或转发之前，不得将PCB添加到捆绑包中。
A BAB MUST always be added to a bundle before that bundle is forwarded.
在转发包之前，必须始终将BAB添加到包中。
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，则该捆绑包应在该目标节点处交付。
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，则该捆绑包应在该目标节点上交付。
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.
如果收到的捆绑包由于任何原因不满足节点的安全策略，则必须丢弃该捆绑包，不再进一步处理；在这种情况下，可能会生成指示故障的捆绑包删除状态报告（请参阅捆绑包协议规范[DTNBP]）。
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]和“Internet X.509公钥基础设施证书和证书吊销列表（CRL）配置文件”[RFC5280]。这两个文档中的安全注意事项也适用于此处。
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.
一些文件特别考虑使用伽罗瓦/计数器模式（GCM）和AES，并且在构建密码子时要考虑重要。这些是“在IPsec封装安全有效负载（ESP）中使用Galois/计数器模式（GCM）”[RFC4106]和“在加密消息语法（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节，其中建议加密-然后签名组合通常适合在DTN中使用。
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（通常被认为是安全源）已在捆绑包的主块中公开。如果源EID或signerInfo的暴露被视为一个有趣的漏洞，则需要某种形式的bundle-in-bundle封装作为缓解措施。
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中。
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
如果捆绑包的PIB目的地与其目的地不同，则当捆绑包在路由中时，预期目的地以外的某个节点（标识为PIB目的地的节点）将验证PIB安全结果。但是，如果由于某种原因PIB未被验证，目的地将无法意识到这一点。通常，PIB目的地将在验证PIB后和转发前从捆绑包中删除PIB。但是，如果PIB也有可能在
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的捆绑包，这可能（但不一定）表明可能存在问题。
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目的地接收之前被分割，则必须在验证PIB安全结果之前重新组装捆绑包中的有效负载，以便正确验证安全结果。因此，如果PIB目的地不能执行有效负载重组，则其作为PIB目的地的效用将仅限于验证自从PIB源转发以来未被分段的捆绑包。类似地，如果捆绑包在被其PIB源转发之后但在被其PIB目的地接收之前被分割，则必须在该PIB目的地接收所有片段，以便能够重新组装捆绑包有效负载。如果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.
对包目的地以外的安全目的地的规范创建了一个路由要求，即包在到达最终目的地的途中以某种方式被定向到安全目的地节点。由于不需要路由节点来实现安全处理，因此该要求目前对密码套件是私有的。
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的内部结构或策略的信息。这有时被认为是不好的安全实践，因此必须小心操作。
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节中描述的四个密码套件。它还可以支持其他密码套件。
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但不支持所有四个强制密码套件的实现必须声明仅“受限符合”本规范，即使它们提供其他密码套件。
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密码套件。例如，中继节点可能不处理端到端的机密性和数据完整性，但它应该排除未经授权的流量，并执行逐跳包验证。
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]中定义的现有“Bundle Block Types”注册表中分配四个代码点。
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 |
+-------+--------------------------------------+----------------+
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 |
+-------+--------------------------------------+----------------+
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 |
+-----------------+----------------------------+----------------+
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参数和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 |
+-------+--------------------------------------+----------------+
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 50502007年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，“Internet X.509公钥基础设施证书和证书撤销列表（CRL）配置文件中使用的RSA加密的其他算法和标识符”，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）中使用Galois/计数器模式（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 52802008年5月。
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, September 2009.
[RFC5652]Housley，R.，“加密消息语法（CMS）”，STD 70，RFC 56522009年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 48382007年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，“统一资源标识符（URI）：通用语法”，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，“安全/多用途Internet邮件扩展（S/MIME）版本3.2消息规范”，RFC 57512010年1月。
Authors' Addresses
作者地址
Susan Flynn Symington The MITRE Corporation 7515 Colshire Drive McLean, VA 22102 US
美国弗吉尼亚州麦克莱恩科尔郡大道7515号米特尔公司苏珊·弗林·西明顿邮编：22102
Phone: +1 (703) 983-7209
EMail: susan@mitre.org
URI: http://mitre.org/
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
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
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号，邮编：21046
Phone: +1-443-430-8052
EMail: dtnbsp@gmail.com
Phone: +1-443-430-8052
EMail: dtnbsp@gmail.com