Internet Research Task Force (IRTF) S. Burleigh
Request for Comments: 6260 Jet Propulsion Laboratory,
Category: Experimental California Institute of Technology
ISSN: 2070-1721 May 2011
Internet Research Task Force (IRTF) S. Burleigh
Request for Comments: 6260 Jet Propulsion Laboratory,
Category: Experimental California Institute of Technology
ISSN: 2070-1721 May 2011
Compressed Bundle Header Encoding (CBHE)
压缩包头编码（CBHE）
Abstract
摘要
This document describes a convention by which Delay-Tolerant Networking (DTN) Bundle Protocol (BP) "convergence-layer" adapters may represent endpoint identifiers in a compressed form within the primary blocks of bundles, provided those endpoint identifiers conform to the structure prescribed by this convention.
本文档描述了一种约定，根据该约定，容错网络（DTN）捆绑协议（BP）“汇聚层”适配器可以在捆绑包的主要块内以压缩形式表示端点标识符，前提是这些端点标识符符合本约定规定的结构。
Compressed Bundle Header Encoding (CBHE) compression is a convergence-layer adaptation. It is opaque to bundle processing. Therefore, it has no impact on the interoperability of different Bundle Protocol implementations, but instead affects only the interoperability of different convergence-layer adaptation implementations.
压缩包头编码（CBHE）压缩是一种收敛层自适应。捆绑处理是不透明的。因此，它不会影响不同捆绑协议实现的互操作性，而只会影响不同融合层自适应实现的互操作性。
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/rfc6260.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6260.
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 ....................................................2
1.1. Requirements Language ......................................3
2. Compression Convention ..........................................3
2.1. Constraints ................................................3
2.2. Method .....................................................6
3. Specification ...................................................7
3.1. Transmission ...............................................7
3.2. Reception ..................................................7
4. IANA Considerations .............................................8
5. Security Considerations ........................................10
6. References .....................................................11
6.1. Normative References ......................................11
6.2. Informative References ....................................11
Appendix A. Acknowledgments .......................................12
1. Introduction ....................................................2
1.1. Requirements Language ......................................3
2. Compression Convention ..........................................3
2.1. Constraints ................................................3
2.2. Method .....................................................6
3. Specification ...................................................7
3.1. Transmission ...............................................7
3.2. Reception ..................................................7
4. IANA Considerations .............................................8
5. Security Considerations ........................................10
6. References .....................................................11
6.1. Normative References ......................................11
6.2. Informative References ....................................11
Appendix A. Acknowledgments .......................................12
This document describes a convention by which Delay-Tolerant Networking (DTN) Bundle Protocol (BP) [RFC5050] "convergence-layer" adapters may represent endpoint identifiers (EIDs) in a compressed form within the primary blocks of bundles, provided those endpoint identifiers conform to the structure prescribed by this convention.
本文档描述了一种约定，根据该约定，容错网络（DTN）捆绑协议（BP）[RFC5050]“汇聚层”适配器可以在捆绑包的主要块内以压缩形式表示端点标识符（EID），前提是这些端点标识符符合本约定规定的结构。
Each DTN bundle's primary block contains the following four BP endpoint identifiers, of which any two, any three, or even all four may be lexically identical: the endpoint identifiers of the bundle's source, destination, report-to endpoint, and current custodian. Each EID is a Uniform Record Identifier (URI) as defined by [RFC3986]. More specifically, each BP EID is a URI consisting of a "scheme name" followed by ":", followed by a sequence of characters -- historically, termed the "scheme-specific part" (SSP) in DTN specifications -- conforming to URI syntax as defined by RFC 3986.
每个DTN捆绑包的主块包含以下四个BP端点标识符，其中任意两个、任意三个，甚至所有四个端点标识符在词汇上可能相同：捆绑包的源、目标、报告到端点和当前托管的端点标识符。每个EID都是[RFC3986]定义的统一记录标识符（URI）。更具体地说，每个BP EID是一个URI，包含一个“方案名称”，后跟“：”，后跟一系列字符——历史上称为DTN规范中的“方案特定部分”（SSP）——符合RFC 3986定义的URI语法。
A degree of block compression is provided by the design of the primary block: the scheme names and scheme-specific parts of the four endpoints' IDs -- up to eight NULL-terminated strings -- are concatenated at the end of the block in a variable-length character array called a "dictionary", enabling each EID to be represented by a pair of integers indicating the offsets (within the dictionary) of the EID's scheme name and scheme-specific part. Duplicate strings may be omitted from the dictionary, so the actual number of concatenated NULL-terminated strings in the dictionary may be less than eight, and two or more of the scheme name or scheme-specific part offsets in the block may have the same value. Moreover, the eight offsets in the primary block are encoded as Self-Delimiting Numeric Values (SDNVs), which shrink to fit the encoded values; when the total length of the dictionary is less than 127 bytes, all eight offsets can be encoded into just eight bytes.
主块的设计提供了一定程度的块压缩：四个端点ID的方案名称和方案特定部分（最多八个以NULL结尾的字符串）在块的末尾连接在一个称为“字典”的可变长度字符数组中，使每个EID由一对整数表示，表示EID的方案名称和方案特定部分的偏移量（在字典中）。可以从字典中省略重复字符串，因此字典中连接的以NULL结尾的字符串的实际数量可能少于8个，并且块中的两个或更多方案名称或方案特定部分偏移量可能具有相同的值。此外，主块中的八个偏移被编码为自定界数值（SDNV），其收缩以适合编码值；当字典的总长度小于127字节时，所有八个偏移量都可以编码为八个字节。
However, these strategems do not prevent the scheme names and especially the scheme-specific parts themselves from being lengthy strings of ASCII text. It is therefore still possible for the length of a bundle's primary header to be a very large fraction of the total length of the bundle when the bundle's payload is relatively small, as is anticipated for a number of DTN applications such as space flight operations (and as is in any case true of bundles carrying BP administrative records).
然而，这些策略并不能阻止方案名称，特别是方案特定部分本身成为ASCII文本的长字符串。因此，当捆绑包的有效载荷相对较小时，捆绑包的主头长度仍有可能占捆绑包总长度的很大一部分，这是许多DTN应用（如航天飞行操作）的预期结果（在任何情况下，携带BP管理记录的捆绑包也是如此）。
The Compressed Bundle Header Encoding (CBHE) convention was developed to improve DTN transmission efficiency for such applications by further reducing the number of bytes used by convergence-layer adapters to represent EIDs in the primary blocks of bundles.
开发压缩包头编码（CBHE）约定是为了通过进一步减少聚合层适配器在包的主要块中表示EID所使用的字节数，提高此类应用程序的DTN传输效率。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
The only valid scheme name for BP EIDs identified to date is "dtn". Although no specification of valid SSP syntax for URIs composed within the "dtn" scheme has yet been formally defined, the syntax on which rough agreement has been reached in practice is unsuitable for CBHE's compression procedures. For the purposes of CBHE, then, this document defines an additional URI scheme named "ipn". As noted in Section 4, IANA has registered this new URI scheme.
迄今为止确定的BP EID的唯一有效方案名称是“dtn”。虽然尚未正式定义“dtn”方案中组成的URI的有效SSP语法规范，但在实践中达成大致一致的语法不适用于CBHE的压缩过程。因此，为了CBHE的目的，本文定义了一个名为“ipn”的附加URI方案。如第4节所述，IANA已经注册了这个新的URI方案。
Compressed Bundle Header Encoding (CBHE) is possible only when all endpoint IDs in the primary block of a given bundle are "CBHE conformant". The following two forms of endpoint ID are CBHE conformant: (a) the null endpoint ID "dtn:none" and (b) any endpoint ID formed within the "ipn" scheme.
只有当给定束的主块中的所有端点ID都是“符合CBHE”时，压缩束头编码（CBHE）才可能实现。以下两种形式的端点ID符合CBHE：（a）空端点ID“dtn:none”和（b）在“ipn”方案中形成的任何端点ID。
The SSP of every URI formed within the "ipn" scheme must comprise:
“ipn”方案中形成的每个URI的SSP必须包括：
1. A sequence of ASCII numeric digits representing an integer in the range 1 to (2^64 - 1), termed the "node number" of the URI.
1. 表示1到（2^64-1）范围内的整数的ASCII数字序列，称为URI的“节点号”。
2. An ASCII period ('.') character.
2. ASCII句点（'.'）字符。
3. A sequence of ASCII numeric digits representing an integer in the range 0 to (2^64 - 1), termed the "service number" of the URI.
3. 表示0到（2^64-1）范围内的整数的ASCII数字序列，称为URI的“服务编号”。
The node number notionally identifies a BP node. However, since CBHE is not used universally in Delay-Tolerant Networking, it must not be assumed that all BP nodes are identified by node numbers.
节点编号在概念上标识一个BP节点。然而，由于CBHE在延迟容忍网络中没有普遍使用，因此不能假设所有BP节点都是通过节点号识别的。
Negative integers and integers larger than (2^64 - 1) cannot be used as node numbers because they cannot be encoded into the SDNVs that are used for representation of scheme name and SSP offsets in the primary blocks of bundles and therefore could not be compressed as described later in this specification. Node number zero is reserved for representation of the null endpoint ID in the compressed form described later; decompressing a compressed null EID must always yield the standard null endpoint ID URI "dtn:none".
负整数和大于（2^64-1）的整数不能用作节点号，因为它们不能编码到SDNV中，SDNV用于表示捆绑包主块中的方案名称和SSP偏移量，因此不能按照本规范后面的描述进行压缩。节点编号0保留为空端点ID的压缩表示形式（稍后描述）；解压缩压缩的null EID必须始终生成标准的null端点ID URI“dtn:none”。
The service number notionally functions as a de-multiplexing token. When the bundle payload is a protocol data unit of some protocol that has its own de-multiplexing identifiers, the service number may function in a manner similar to that of the protocol number in an IP packet, characterizing the encapsulated protocol; alternatively, the service number may function in a manner similar to that of the port number in a UDP datagram. Service numbers enable inbound bundles' application data units to be de-multiplexed to instances of application functionality that are designed to process them, so that effective communication relationships can be developed between bundle producers and consumers.
服务号码名义上起到解复用令牌的作用。当捆绑有效载荷是具有其自己的解复用标识符的某个协议的协议数据单元时，服务号码可以类似于IP分组中的协议号码的方式工作，表征封装的协议；或者，服务号可以类似于UDP数据报中的端口号的方式工作。服务编号使入站捆绑包的应用程序数据单元能够被解复用到设计用于处理它们的应用程序功能实例，从而可以在捆绑包生产者和消费者之间建立有效的通信关系。
A service number must not be negative or exceed (2^64 - 1) for the same reason that a node number must not do so.
服务编号不能为负数或超过（2^64-1），原因与节点编号不能为负数或超过（2^64-1）的原因相同。
For example, "ipn:9.37" would be a CBHE-conformant endpoint ID.
例如，“ipn:9.37”将是符合CBHE的端点ID。
Conversion of a CBHE-conformant EID to and from a tuple of two integers is therefore straightforward: all characters in the EID other than the node number and service number are constant (as defined by the "ipn" scheme definition), and the node number and service number are taken as the two integers of the tuple. This ease of conversion enables an array of pairs of integers to serve the same function as a dictionary of ASCII string EIDs.
因此，将符合CBHE的EID与两个整数的元组进行转换非常简单：EID中除节点号和服务号以外的所有字符都是常量（由“ipn”方案定义定义），节点号和服务号被视为元组的两个整数。这种易于转换的特性使成对整数的数组能够充当ASCII字符串EID字典的相同功能。
Note, however, that CBHE decompression cannot faithfully recreate the dictionary of a compressed primary block from an array of integer pairs unless the order of the scheme names and scheme-specific part strings in the dictionary of the original, uncompressed block is known. (The Bundle Protocol Specification does not require that the strings in the dictionary appear in any particular order and does not require that redundant strings be omitted from the dictionary.) Therefore, a further precondition to CBHE compression is that the strings in the dictionary of the bundle to be compressed must be exactly as follows, in this order and without addition:
但是，请注意，除非已知原始未压缩块的字典中的方案名称和方案特定部分字符串的顺序，否则CBHE解压缩无法从整数对数组忠实地重新创建压缩主块的字典。（捆绑协议规范不要求字典中的字符串以任何特定顺序出现，也不要求字典中省略冗余字符串。）因此，CBHE压缩的另一个先决条件是，要压缩的捆绑字典中的字符串必须完全如下所示：，按此顺序且不添加：
1. The scheme name of the destination endpoint ID.
1. 目标终结点ID的方案名称。
2. The scheme-specific part of the destination endpoint ID.
2. 目标终结点ID的方案特定部分。
3. The scheme name of the source endpoint ID, if and only if different from any prior string in the dictionary.
3. 源终结点ID的方案名称，当且仅当与字典中的任何先前字符串不同时。
4. The scheme-specific part of the source endpoint ID, if and only if different from any prior string in the dictionary.
4. 源端点ID的特定于方案的部分，当且仅当与字典中的任何先前字符串不同时。
5. The scheme name of the report-to endpoint ID, if and only if different from any prior string in the dictionary.
5. 报告到端点ID的方案名称，当且仅当与字典中的任何先前字符串不同时。
6. The scheme-specific part of the report-to endpoint ID, if and only if different from any prior string in the dictionary.
6. 报告到端点ID的方案特定部分，当且仅当与字典中的任何先前字符串不同时。
7. The scheme name of the current custodian endpoint ID, if and only if different from any prior string in the dictionary.
7. 当前托管端点ID的方案名称，当且仅当与字典中的任何先前字符串不同时。
8. The scheme-specific part of the current custodian endpoint ID, if and only if different from any prior string in the dictionary.
8. 当前托管端点ID的方案特定部分，当且仅当与字典中的任何先前字符串不同时。
Note: this constraint implies that a bundle that includes any extension blocks containing EID-references to endpoint IDs other than the block's destination, source, report-to, and current custodian cannot be CBHE compressed since such compression would result in a dictionary that would deviate from this structure.
注意：此约束意味着不能压缩包含对端点ID（而不是块的目的地、源、报告对象和当前保管者）的EID引用的任何扩展块的捆绑包，因为这种压缩将导致字典偏离此结构。
When the constraints enumerated above are met, the CBHE block compression method can be applied by the convergence-layer adapter (CLA) at the time the bundle is transmitted via a convergence-layer protocol. In a CBHE-compressed primary block, the eight SDNVs that normally contain EIDs' scheme name and SSP offsets within the dictionary are instead used to contain the eight integer values listed below, in the order shown:
当满足上述约束条件时，在通过汇聚层协议传输包时，汇聚层适配器（CLA）可以应用CBHE块压缩方法。在CBHE压缩主块中，字典中通常包含EID方案名称和SSP偏移量的八个SDNV用于包含以下列出的八个整数值，顺序如下所示：
1. The node number of the destination endpoint ID, or zero if the destination endpoint is the null endpoint.
1. 目标端点ID的节点号，如果目标端点为空端点，则为零。
2. The service number of the destination endpoint ID, or zero if the destination endpoint is the null endpoint.
2. 目标端点ID的服务编号，如果目标端点为空端点，则为零。
3. The node number of the source endpoint ID, or zero if the source endpoint is the null endpoint.
3. 源终结点ID的节点号，如果源终结点为空终结点，则为零。
4. The service number of the source endpoint ID, or zero if the source endpoint is the null endpoint.
4. 源终结点ID的服务编号，如果源终结点为空终结点，则为零。
5. The node number of the report-to endpoint ID, or zero if the report-to endpoint is the null endpoint.
5. 报告到端点ID的节点号，如果报告到端点为空端点，则为零。
6. The service number of the report-to endpoint ID, or zero if the report-to endpoint is the null endpoint.
6. report to endpoint ID的服务编号，如果report to endpoint是空端点，则为零。
7. The node number of the current custodian endpoint ID, or zero if the current custodian endpoint is the null endpoint.
7. 当前托管端点ID的节点号，如果当前托管端点为空端点，则为零。
8. The service number of the current custodian endpoint ID, or zero if the current custodian endpoint is the null endpoint.
8. 当前托管端点ID的服务编号，如果当前托管端点为空端点，则为零。
Further, the dictionary is omitted from the primary block and the primary block's dictionary length is set to zero.
此外，从主块中省略字典，并且主块的字典长度设置为零。
Upon reception, the receiving convergence-layer adaptation de-compresses the block by simply reversing the process so that the bundle presented to the bundle protocol agent has the standard form (i.e., the dictionary is reconstituted).
在接收时，接收汇聚层适配通过简单地反转过程来对块进行去压缩，使得呈现给捆绑协议代理的捆绑具有标准形式（即，重构字典）。
CBHE compression is a convergence-layer adaptation. It is opaque to bundle processing. Therefore, it has no impact on the interoperability of different Bundle Protocol implementations, but instead affects only the interoperability of different convergence-layer adaptation implementations.
CBHE压缩是一种收敛层自适应。捆绑处理是不透明的。因此，它不会影响不同捆绑协议实现的互操作性，而只会影响不同融合层自适应实现的互操作性。
Bundle Protocol convergence-layer adapters that conform to the CBHE specification must implement the following procedures.
符合CBHE规范的捆绑协议聚合层适配器必须实现以下过程。
When and only when required by the bundle protocol agent to transmit a bundle whose primary block's endpoint IDs satisfy the constraints identified in Section 2.1, the CLA MAY encode the primary block of the bundle in accordance with the CBHE compression convention described in Section 2.2 UNLESS the CLA to which the bundle is to be transmitted is known not to be CBHE conformant. Note that CBHE compression may be applied only if the receiving CLA is known or presumed to be CBHE conformant, i.e., able to decode the encoded primary block. Knowledge as to whether or not a receiving CLA is (or might be) CBHE conformant may be asserted by node administration and/or may be inferred from reception of a CBHE-compressed bundle as noted in Section 3.2.
当且仅当捆绑协议代理要求传输其主块的端点ID满足第2.1节中确定的约束的捆绑时，CLA可以根据第2.2节中描述的CBHE压缩约定对包的主要块进行编码，除非已知包要传输到的CLA不符合CBHE。注意，仅当接收CLA已知或假定为CBHE符合，即能够解码编码的主块时，才可以应用CBHE压缩。关于接收CLA是否符合（或可能符合）CBHE的知识可由节点管理断言和/或可从接收CBHE压缩包推断，如第3.2节所述。
Upon receiving a bundle whose dictionary length is zero (and only in this circumstance), a CBHE-conformant convergence-layer adapter:
在接收字典长度为零的包时（仅在这种情况下），CBHE一致收敛层适配器：
1. MAY infer that the CLA from which the bundle was received is CBHE conformant.
1. 可以推断接收到束的CLA符合CBHE。
2. MUST decode the primary block of the bundle in accordance with the CBHE compression convention described in Section 2.2 before delivering it to the bundle protocol agent.
2. 必须根据第2.2节中描述的CBHE压缩约定对捆绑包的主块进行解码，然后再将其交付给捆绑包协议代理。
Note that when a CLA that is not CBHE conformant receives a bundle whose dictionary length is zero, it has no choice but to pass it to the bundle agent without modification. In this case, the bundle protocol agent will be unable to dispatch the received bundle, because it will be unable to determine the destination endpoint; the bundle will be judged to be malformed. The behavior of the bundle protocol agent in this circumstance is an implementation matter.
请注意，当不符合CBHE的CLA接收到字典长度为零的bundle时，它别无选择，只能将其传递给bundle代理而不进行修改。在这种情况下，bundle协议代理将无法分派收到的bundle，因为它将无法确定目标端点；该捆绑包将被判断为格式不正确。捆绑协议代理在这种情况下的行为是一个实现问题。
IANA has registered a provisional registration (per [RFC4395]) for a URI scheme for CBHE, with the string "ipn" as the scheme name, as follows:
IANA已为CBHE的URI方案注册了临时注册（根据[RFC4395]），方案名称为字符串“ipn”，如下所示：
URI scheme name: "ipn"
URI方案名称：“ipn”
Status: provisional
现状：临时
URI scheme syntax:
URI方案语法：
This specification uses the Augmented Backus-Naur Form (ABNF) notation of [RFC5234], including the core ABNF syntax rule for DIGIT defined by that specification.
本规范使用[RFC5234]的增广巴科斯诺尔形式（ABNF）表示法，包括该规范定义的数字的核心ABNF语法规则。
ipn-uri = "ipn:" ipn-hier-part
ipn-hier-part = node-nbr nbr-delim service-nbr ; a path-rootless
node-nbr = 1*DIGIT
nbr-delim = "."
service-nbr = 1*DIGIT
ipn-uri = "ipn:" ipn-hier-part
ipn-hier-part = node-nbr nbr-delim service-nbr ; a path-rootless
node-nbr = 1*DIGIT
nbr-delim = "."
service-nbr = 1*DIGIT
None of the reserved characters defined in the generic URI syntax are used as delimiters within URIs of the IPN scheme.
在通用URI语法中定义的保留字符中没有一个用作IPN方案的URI内的分隔符。
URI scheme semantics: URIs of the IPN scheme are used as endpoint identifiers in the Delay-Tolerant Networking (DTN) Bundle Protocol (BP) [RFC5050] as described in Section 2.1.
URI方案语义：IPN方案的URI用作延迟容忍网络（DTN）捆绑协议（BP）[RFC5050]中的端点标识符，如第2.1节所述。
Encoding considerations: URIs of the IPN scheme are encoded exclusively in US-ASCII characters.
编码注意事项：IPN方案的URI仅以US-ASCII字符编码。
Applications and/or protocols that use this URI scheme name: the Delay-Tolerant Networking (DTN) Bundle Protocol (BP) [RFC5050].
使用此URI方案名称的应用程序和/或协议：延迟容忍网络（DTN）捆绑协议（BP）[RFC5050]。
Interoperability considerations: as noted above, URIs of the IPN scheme are encoded exclusively in US-ASCII characters.
互操作性注意事项：如上所述，IPN方案的URI仅以US-ASCII字符编码。
Security considerations:
安全考虑：
o Reliability and consistency: none of the BP endpoints identified by the URIs of the IPN scheme are guaranteed to be reachable at any time, and the identity of the processing entities operating on those endpoints is never guaranteed by the Bundle Protocol itself. Bundle authentication as defined by the Bundle Security Protocol is required for this purpose.
o 可靠性和一致性：IPN方案的URI标识的任何BP端点都不能保证在任何时候都可以访问，并且捆绑协议本身也不能保证在这些端点上运行的处理实体的身份。为此，需要捆绑包安全协议定义的捆绑包身份验证。
o Malicious construction: malicious construction of a conformant IPN-scheme URI is limited to the malicious selection of node numbers and the malicious selection of service numbers. That is, a maliciously constructed IPN-scheme URI could be used to direct a bundle to an endpoint that might be damaged by the arrival of that bundle or, alternatively, to declare a false source for a bundle and thereby cause incorrect processing at a node that receives the bundle. In both cases (and indeed in all bundle processing), the node that receives a bundle should verify its authenticity and validity before operating on it in any way.
o 恶意构造：符合IPN方案URI的恶意构造仅限于恶意选择节点号和恶意选择服务号。也就是说，恶意构造的IPN方案URI可用于将包定向到可能因该包的到达而损坏的端点，或者，为包声明错误源，从而导致在接收该包的节点上进行错误处理。在这两种情况下（事实上，在所有包处理中），接收包的节点都应该在以任何方式对其进行操作之前验证其真实性和有效性。
o Back-end transcoding: the limited expressiveness of URIs of the IPN scheme effectively eliminates the possibility of threat due to errors in back-end transcoding.
o 后端转码：IPN方案URI的有限表达能力有效地消除了由于后端转码错误而造成威胁的可能性。
o Rare IP address formats: not relevant, as IP addresses do not appear anywhere in conformant IPN-scheme URIs.
o 罕见的IP地址格式：不相关，因为IP地址不会出现在符合IPN方案URI的任何位置。
o Sensitive information: because IPN-scheme URIs are used only to represent the identities of Bundle Protocol endpoints, the risk of disclosure of sensitive information due to interception of these URIs is minimal. Examination of IPN-scheme URIs could be used to support traffic analysis; where traffic analysis is a plausible danger, bundles should be conveyed by secure convergence-layer protocols that do not expose endpoint IDs.
o 敏感信息：由于IPN方案URI仅用于表示捆绑协议端点的身份，因此由于截获这些URI而泄露敏感信息的风险最小。IPN方案URI的检查可用于支持流量分析；如果流量分析是一种可能的危险，那么捆绑包应该通过不公开端点ID的安全聚合层协议进行传输。
o Semantic attacks: the simplicity of IPN-scheme URI syntax minimizes the possibility of misinterpretation of a URI by a human user.
o 语义攻击：IPN方案URI语法的简单性将人类用户误解URI的可能性降至最低。
Contact: Scott Burleigh Jet Propulsion Laboratory, California Institute of Technology scott.c.burleigh@jpl.nasa.gov +1 (800) 393-3353
联系人：加州理工学院斯科特·伯利喷气推进实验室斯科特·c。burleigh@jpl.nasa.gov +1 (800) 393-3353
Author/Change controller: Scott Burleigh Jet Propulsion Laboratory, California Institute of Technology scott.c.burleigh@jpl.nasa.gov +1 (800) 393-3353
作者/变更控制人：加州理工学院斯科特·伯利喷气推进实验室斯科特·c。burleigh@jpl.nasa.gov +1 (800) 393-3353
References: S. Burleigh, "Compressed Bundle Header Encoding (CBHE)", RFC 6260, May 2011.
参考文献：S.Burleigh，“压缩包头编码（CBHE）”，RFC6260，2011年5月。
The Bundle Security Protocol (BSP) may, under some conditions, insert additional endpoint ID strings into the dictionary of a bundle and reference those strings in BSP extension blocks. Because a bundle that includes any extension blocks containing EID-references to endpoint IDs other than the block's destination, source, report-to, and current custodian cannot be CBHE compressed, bundles cannot be compressed under those conditions.
在某些情况下，捆绑包安全协议（BSP）可能会在捆绑包的字典中插入其他端点ID字符串，并在BSP扩展块中引用这些字符串。由于无法压缩包含对端点ID（而不是块的目标、源、报告对象和当前保管者）的EID引用的任何扩展块的捆绑包，因此在这些条件下无法压缩捆绑包。
Specifically, the specification detailed above implies that a bundle cannot be CBHE compressed when the security-source endpoint for the Bundle Authentication Block (BAB) is noted in the dictionary (typically, because there is no other way for the receiving bundle protocol agent to determine the security-source endpoint); when the security-destination endpoint for the BAB is noted in the dictionary (in the rare case that the receiving endpoint is not the security-destination endpoint); when the security-source endpoint for the Payload Integrity Block (PIB), Payload Confidentiality Block (PCB), or Extension Security Block (ESB) is not the source endpoint; or when the security-destination endpoint for the PIB, PCB, or ESB is not the destination endpoint.
具体地说，上面详述的规范意味着，当在字典中注明捆绑认证块（BAB）的安全源端点时（通常，因为接收捆绑协议代理没有其他方法来确定安全源端点），无法对捆绑进行CBHE压缩；当字典中注明BAB的安全目标端点时（在接收端点不是安全目标端点的罕见情况下）；当有效负载完整性块（PIB）、有效负载机密性块（PCB）或扩展安全块（ESB）的安全源端点不是源端点时；或者当PIB、PCB或ESB的安全目标端点不是目标端点时。
Also, the CBHE-conformance inference mechanism identified in Section 3.2 introduces a possible denial-of-service attack. Malicious code could issue a CHBE-compressed bundle whose source EID falsely identifies the bundle origin as some node whose CLA is not CBHE conformant; a CBHE-conformant CLA receiving this bundle might incorrectly infer that the CLA at the purported source node was CBHE conformant and might then begin CBHE compressing all bundles that it sends to that node, thus preventing those bundles from being dispatched by the node's bundle protocol agent. Nodes can defend against such an attack by requiring Bundle Authentication Blocks and discarding any inference of CBHE conformance for the CLAs at nodes from which inauthentic bundles are received.
此外，第3.2节中确定的CBHE一致性推断机制引入了可能的拒绝服务攻击。恶意代码可能发出CHBE压缩包，其源EID错误地将包源标识为CLA不符合CBHE的某个节点；接收此捆绑包的符合CBHE的CLA可能会错误地推断声称的源节点处的CLA是符合CBHE的，然后可能开始压缩它发送到该节点的所有捆绑包，从而阻止节点的捆绑协议代理发送这些捆绑包。节点可以通过要求捆绑包身份验证块并在接收到不真实捆绑包的节点上放弃对CLA的CBHE一致性的任何推断来抵御这种攻击。
These caveats aside, CBHE introduces no new security considerations beyond those discussed in the DTN Bundle Protocol RFC 5050 [RFC5050] and Bundle Security Protocol RFC 6257 [RFC6257] Specifications.
撇开这些警告不谈，CBHE除了DTN捆绑协议RFC 5050[RFC5050]和捆绑安全协议RFC 6257[RFC6257]规范中讨论的内容外，没有引入任何新的安全注意事项。
[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月。
[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月。
[RFC5050] Scott, K. and S. Burleigh, "Bundle Protocol Specification", RFC 5050, November 2007.
[RFC5050]Scott，K.和S.Burleigh，“捆绑协议规范”，RFC 50502007年11月。
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234]Crocker，D.和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，2008年1月。
[RFC6257] Symington, S., Farrell, S., Weiss, H., and P. Lovell, "Bundle Security Protocol Specification", RFC 6257, May 2011.
[RFC6257]Symington，S.，Farrell，S.，Weiss，H.，和P.Lovell，“捆绑包安全协议规范”，RFC 6257，2011年5月。
[RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and Registration Procedures for New URI Schemes", BCP 35, RFC 4395, February 2006.
[RFC4395]Hansen，T.，Hardie，T.，和L.Masinter，“新URI方案的指南和注册程序”，BCP 35，RFC 4395，2006年2月。
This research was carried out at the Jet Propulsion Laboratory, California Institute of Technology, under a contract with the National Aeronautics and Space Administration. Government sponsorship acknowledged.
这项研究是在加利福尼亚理工学院喷气推进实验室根据与美国国家航空航天局的合同进行的。承认政府的赞助。
Author's Address
作者地址
Scott Burleigh Jet Propulsion Laboratory, California Institute of Technology 4800 Oak Grove Drive, m/s 301-490 Pasadena, CA 91109 USA
美国加利福尼亚州帕萨迪纳市橡树林大道4800号斯科特·伯利喷气推进实验室，邮编：91109
Phone: +1 818 393 3353
EMail: Scott.C.Burleigh@jpl.nasa.gov
Phone: +1 818 393 3353
EMail: Scott.C.Burleigh@jpl.nasa.gov