draft-ietf-dtn-bpsec-25.txt   draft-ietf-dtn-bpsec-26.txt 
Delay-Tolerant Networking E. Birrane Delay-Tolerant Networking E. Birrane
Internet-Draft K. McKeever Internet-Draft K. McKeever
Intended status: Standards Track JHU/APL Intended status: Standards Track JHU/APL
Expires: June 4, 2021 December 1, 2020 Expires: July 12, 2021 January 8, 2021
Bundle Protocol Security Specification Bundle Protocol Security Specification
draft-ietf-dtn-bpsec-25 draft-ietf-dtn-bpsec-26
Abstract Abstract
This document defines a security protocol providing data integrity This document defines a security protocol providing data integrity
and confidentiality services for the Bundle Protocol. and confidentiality services for the Bundle Protocol.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
skipping to change at page 1, line 31 skipping to change at page 1, line 31
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on June 4, 2021. This Internet-Draft will expire on July 12, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 28 skipping to change at page 2, line 28
3. Security Blocks . . . . . . . . . . . . . . . . . . . . . . . 10 3. Security Blocks . . . . . . . . . . . . . . . . . . . . . . . 10
3.1. Block Definitions . . . . . . . . . . . . . . . . . . . . 10 3.1. Block Definitions . . . . . . . . . . . . . . . . . . . . 10
3.2. Uniqueness . . . . . . . . . . . . . . . . . . . . . . . 10 3.2. Uniqueness . . . . . . . . . . . . . . . . . . . . . . . 10
3.3. Target Multiplicity . . . . . . . . . . . . . . . . . . . 12 3.3. Target Multiplicity . . . . . . . . . . . . . . . . . . . 12
3.4. Target Identification . . . . . . . . . . . . . . . . . . 13 3.4. Target Identification . . . . . . . . . . . . . . . . . . 13
3.5. Block Representation . . . . . . . . . . . . . . . . . . 13 3.5. Block Representation . . . . . . . . . . . . . . . . . . 13
3.6. Abstract Security Block . . . . . . . . . . . . . . . . . 13 3.6. Abstract Security Block . . . . . . . . . . . . . . . . . 13
3.7. Block Integrity Block . . . . . . . . . . . . . . . . . . 16 3.7. Block Integrity Block . . . . . . . . . . . . . . . . . . 16
3.8. Block Confidentiality Block . . . . . . . . . . . . . . . 17 3.8. Block Confidentiality Block . . . . . . . . . . . . . . . 17
3.9. Block Interactions . . . . . . . . . . . . . . . . . . . 18 3.9. Block Interactions . . . . . . . . . . . . . . . . . . . 18
3.10. Parameter and Result Identification . . . . . . . . . . . 20 3.10. Parameter and Result Identification . . . . . . . . . . . 19
3.11. BSP Block Examples . . . . . . . . . . . . . . . . . . . 20 3.11. BSP Block Examples . . . . . . . . . . . . . . . . . . . 20
3.11.1. Example 1: Constructing a Bundle with Security . . . 20 3.11.1. Example 1: Constructing a Bundle with Security . . . 20
3.11.2. Example 2: Adding More Security At A New Node . . . 21 3.11.2. Example 2: Adding More Security At A New Node . . . 21
4. Canonical Forms . . . . . . . . . . . . . . . . . . . . . . . 23 4. Canonical Forms . . . . . . . . . . . . . . . . . . . . . . . 23
5. Security Processing . . . . . . . . . . . . . . . . . . . . . 24 5. Security Processing . . . . . . . . . . . . . . . . . . . . . 24
5.1. Bundles Received from Other Nodes . . . . . . . . . . . . 24 5.1. Bundles Received from Other Nodes . . . . . . . . . . . . 24
5.1.1. Receiving BCBs . . . . . . . . . . . . . . . . . . . 24 5.1.1. Receiving BCBs . . . . . . . . . . . . . . . . . . . 24
5.1.2. Receiving BIBs . . . . . . . . . . . . . . . . . . . 25 5.1.2. Receiving BIBs . . . . . . . . . . . . . . . . . . . 25
5.2. Bundle Fragmentation and Reassembly . . . . . . . . . . . 26 5.2. Bundle Fragmentation and Reassembly . . . . . . . . . . . 26
6. Key Management . . . . . . . . . . . . . . . . . . . . . . . 27 6. Key Management . . . . . . . . . . . . . . . . . . . . . . . 27
7. Security Policy Considerations . . . . . . . . . . . . . . . 27 7. Security Policy Considerations . . . . . . . . . . . . . . . 27
7.1. Security Reason Codes . . . . . . . . . . . . . . . . . . 28 7.1. Security Reason Codes . . . . . . . . . . . . . . . . . . 28
8. Security Considerations . . . . . . . . . . . . . . . . . . . 29 8. Security Considerations . . . . . . . . . . . . . . . . . . . 30
8.1. Attacker Capabilities and Objectives . . . . . . . . . . 30 8.1. Attacker Capabilities and Objectives . . . . . . . . . . 30
8.2. Attacker Behaviors and BPSec Mitigations . . . . . . . . 31 8.2. Attacker Behaviors and BPSec Mitigations . . . . . . . . 31
8.2.1. Eavesdropping Attacks . . . . . . . . . . . . . . . . 31 8.2.1. Eavesdropping Attacks . . . . . . . . . . . . . . . . 31
8.2.2. Modification Attacks . . . . . . . . . . . . . . . . 32 8.2.2. Modification Attacks . . . . . . . . . . . . . . . . 32
8.2.3. Topology Attacks . . . . . . . . . . . . . . . . . . 33 8.2.3. Topology Attacks . . . . . . . . . . . . . . . . . . 33
8.2.4. Message Injection . . . . . . . . . . . . . . . . . . 33 8.2.4. Message Injection . . . . . . . . . . . . . . . . . . 34
9. Security Context Considerations . . . . . . . . . . . . . . . 34 9. Security Context Considerations . . . . . . . . . . . . . . . 34
9.1. Mandating Security Contexts . . . . . . . . . . . . . . . 34 9.1. Mandating Security Contexts . . . . . . . . . . . . . . . 34
9.2. Identification and Configuration . . . . . . . . . . . . 35 9.2. Identification and Configuration . . . . . . . . . . . . 35
9.3. Authorship . . . . . . . . . . . . . . . . . . . . . . . 36 9.3. Authorship . . . . . . . . . . . . . . . . . . . . . . . 37
10. Defining Other Security Blocks . . . . . . . . . . . . . . . 37 10. Defining Other Security Blocks . . . . . . . . . . . . . . . 38
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39
11.1. Bundle Block Types . . . . . . . . . . . . . . . . . . . 39 11.1. Bundle Block Types . . . . . . . . . . . . . . . . . . . 39
11.2. Bundle Status Report Reason Codes . . . . . . . . . . . 39 11.2. Bundle Status Report Reason Codes . . . . . . . . . . . 40
11.3. Security Context Identifiers . . . . . . . . . . . . . . 40 11.3. Security Context Identifiers . . . . . . . . . . . . . . 40
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 40 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 41
12.1. Normative References . . . . . . . . . . . . . . . . . . 40 12.1. Normative References . . . . . . . . . . . . . . . . . . 41
12.2. Informative References . . . . . . . . . . . . . . . . . 41 12.2. Informative References . . . . . . . . . . . . . . . . . 42
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 41 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 42
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 42 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 42
1. Introduction 1. Introduction
This document defines security features for the Bundle Protocol (BP) This document defines security features for the Bundle Protocol (BP)
[I-D.ietf-dtn-bpbis] and is intended for use in Delay Tolerant [I-D.ietf-dtn-bpbis] and is intended for use in Delay Tolerant
Networks (DTNs) to provide security services between a security Networks (DTNs) to provide security services between a security
source and a security acceptor. When the security source is the source and a security acceptor. When the security source is the
bundle source and when the security acceptor is the bundle bundle source and when the security acceptor is the bundle
destination, the security service provides end-to-end protection. destination, the security service provides end-to-end protection.
skipping to change at page 5, line 43 skipping to change at page 5, line 43
"Delay-Tolerant Networking Architecture" [RFC4838] defines the "Delay-Tolerant Networking Architecture" [RFC4838] defines the
architecture for DTNs and identifies certain security assumptions architecture for DTNs and identifies certain security assumptions
made by existing Internet protocols that are not valid in a DTN. made by existing Internet protocols that are not valid in a DTN.
The Bundle Protocol [I-D.ietf-dtn-bpbis] defines the format and The Bundle Protocol [I-D.ietf-dtn-bpbis] defines the format and
processing of bundles, defines the extension block format used to processing of bundles, defines the extension block format used to
represent BPSec security blocks, and defines the canonical block represent BPSec security blocks, and defines the canonical block
structure used by this specification. structure used by this specification.
The Concise Binary Object Representation (CBOR) format [RFC7049] The Concise Binary Object Representation (CBOR) format [RFC8949]
defines a data format that allows for small code size, fairly small defines a data format that allows for small code size, fairly small
message size, and extensibility without version negotiation. The message size, and extensibility without version negotiation. The
block-specific-data associated with BPSec security blocks are encoded block-specific-data associated with BPSec security blocks are encoded
in this data format. in this data format.
The Bundle Security Protocol [RFC6257] and Streamlined Bundle The Bundle Security Protocol [RFC6257] and Streamlined Bundle
Security Protocol [I-D.birrane-dtn-sbsp] documents introduced the Security Protocol [I-D.birrane-dtn-sbsp] documents introduced the
concepts of using BP extension blocks for security services in a DTN. concepts of using BP extension blocks for security services in a DTN.
The BPSec is a continuation and refinement of these documents. The BPSec is a continuation and refinement of these documents.
skipping to change at page 6, line 46 skipping to change at page 6, line 46
o Intermediate Receiver, Waypoint, or Next Hop - any node that o Intermediate Receiver, Waypoint, or Next Hop - any node that
receives a bundle from a Forwarder that is not the Bundle receives a bundle from a Forwarder that is not the Bundle
Destination. Also, the Node ID of the BPA at any such node. Destination. Also, the Node ID of the BPA at any such node.
o Path - the ordered sequence of nodes through which a bundle passes o Path - the ordered sequence of nodes through which a bundle passes
on its way from Source to Destination. The path is not on its way from Source to Destination. The path is not
necessarily known in advance by the bundle or any BPAs in the DTN. necessarily known in advance by the bundle or any BPAs in the DTN.
o Security Acceptor - a bundle node that processes and dispositions o Security Acceptor - a bundle node that processes and dispositions
one or more security blocks in a bundle. Also, the Node ID of one or more security blocks in a bundle. Security acceptors act
that node. as the endpoint of a security service represented in a security
block. They remove the security blocks they act upon as part of
processing and disposition. Also, the Node ID of that node.
o Security Block - a BPSec extension block in a bundle. o Security Block - a BPSec extension block in a bundle.
o Security Context - the set of assumptions, algorithms, o Security Context - the set of assumptions, algorithms,
configurations and policies used to implement security services. configurations and policies used to implement security services.
o Security Operation - the application of a given security service o Security Operation - the application of a given security service
to a security target, notated as OP(security service, security to a security target, notated as OP(security service, security
target). For example, OP(bcb-confidentiality, payload). Every target). For example, OP(bcb-confidentiality, payload). Every
security operation in a bundle MUST be unique, meaning that a security operation in a bundle MUST be unique, meaning that a
skipping to change at page 7, line 28 skipping to change at page 7, line 28
services for plain text integrity (bib-integrity), and services for plain text integrity (bib-integrity), and
authenticated plain text confidentiality with additional authenticated plain text confidentiality with additional
authenticated data (bcb-confidentiality). authenticated data (bcb-confidentiality).
o Security Source - a bundle node that adds a security block to a o Security Source - a bundle node that adds a security block to a
bundle. Also, the Node ID of that node. bundle. Also, the Node ID of that node.
o Security Target - the block within a bundle that receives a o Security Target - the block within a bundle that receives a
security service as part of a security operation. security service as part of a security operation.
o Security Verifier - a bundle node that verifies the correctness of
one or more security blocks in a bundle. Unlike security
acceptors, security verifiers do not act as the endpoint of a
security service and do not remove verified security blocks.
Also, the Node ID of that node.
2. Design Decisions 2. Design Decisions
The application of security services in a DTN is a complex endeavor The application of security services in a DTN is a complex endeavor
that must consider physical properties of the network (such as that must consider physical properties of the network (such as
connectivity and propagation times), policies at each node, connectivity and propagation times), policies at each node,
application security requirements, and current and future threat application security requirements, and current and future threat
environments. This section identifies those desirable properties environments. This section identifies those desirable properties
that guide design decisions for this specification and are necessary that guide design decisions for this specification and are necessary
for understanding the format and behavior of the BPSec protocol. for understanding the format and behavior of the BPSec protocol.
skipping to change at page 13, line 47 skipping to change at page 13, line 50
The structure of the security-specific portions of a security block The structure of the security-specific portions of a security block
is identical for both the BIB and BCB Block Types. Therefore, this is identical for both the BIB and BCB Block Types. Therefore, this
section defines an Abstract Security Block (ASB) data structure and section defines an Abstract Security Block (ASB) data structure and
discusses the definition, processing, and other constraints for using discusses the definition, processing, and other constraints for using
this structure. An ASB is never directly instantiated within a this structure. An ASB is never directly instantiated within a
bundle, it is only a mechanism for discussing the common aspects of bundle, it is only a mechanism for discussing the common aspects of
BIB and BCB security blocks. BIB and BCB security blocks.
The fields of the ASB SHALL be as follows, listed in the order in The fields of the ASB SHALL be as follows, listed in the order in
which they must appear. which they must appear. The encoding of these fields MUST be in
accordance with the canonical forms provided in Section 4.
Security Targets: Security Targets:
This field identifies the block(s) targeted by the security This field identifies the block(s) targeted by the security
operation(s) represented by this security block. Each target operation(s) represented by this security block. Each target
block is represented by its unique Block Number. This field block is represented by its unique Block Number. This field
SHALL be represented by a CBOR array of data items. Each SHALL be represented by a CBOR array of data items. Each
target within this CBOR array SHALL be represented by a CBOR target within this CBOR array SHALL be represented by a CBOR
unsigned integer. This array MUST have at least 1 entry and unsigned integer. This array MUST have at least 1 entry and
each entry MUST represent the Block Number of a block that each entry MUST represent the Block Number of a block that
exists in the bundle. There MUST NOT be duplicate entries in exists in the bundle. There MUST NOT be duplicate entries in
skipping to change at page 14, line 33 skipping to change at page 14, line 38
security block. This field SHALL be represented as a CBOR security block. This field SHALL be represented as a CBOR
unsigned integer whose contents shall be interpreted as a bit unsigned integer whose contents shall be interpreted as a bit
field. Each bit in this bit field indicates the presence (bit field. Each bit in this bit field indicates the presence (bit
set to 1) or absence (bit set to 0) of optional data in the set to 1) or absence (bit set to 0) of optional data in the
security block. The association of bits to security block data security block. The association of bits to security block data
is defined as follows. is defined as follows.
Bit 0 (the least-significant bit, 0x01): Security Context Bit 0 (the least-significant bit, 0x01): Security Context
Parameters Present Flag. Parameters Present Flag.
Bit 1 (0x02): Security Source Present Flag. Bit >0 Reserved
Bit >1 Reserved
Implementations MUST set reserved bits to 0 when writing this Implementations MUST set reserved bits to 0 when writing this
field and MUST ignore the values of reserved bits when reading field and MUST ignore the values of reserved bits when reading
this field. For unreserved bits, a value of 1 indicates that this field. For unreserved bits, a value of 1 indicates that
the associated security block field MUST be included in the the associated security block field MUST be included in the
security block. A value of 0 indicates that the associated security block. A value of 0 indicates that the associated
security block field MUST NOT be in the security block. security block field MUST NOT be in the security block.
Security Source (Optional): Security Source:
This field identifies the Endpoint that inserted the security This field identifies the Endpoint that inserted the security
block in the bundle. If the security source field is not block in the bundle. This field SHALL be represented by a CBOR
present then the source MUST be inferred from other array in accordance with [I-D.ietf-dtn-bpbis] rules for
information, such as the bundle source, previous hop, or other representing Endpoint Identifiers (EIDs).
values defined by security policy. This field SHALL be
represented by a CBOR array in accordance with
[I-D.ietf-dtn-bpbis] rules for representing Endpoint
Identifiers (EIDs).
Security Context Parameters (Optional): Security Context Parameters (Optional):
This field captures one or more security context parameters This field captures one or more security context parameters
that should be used when processing the security service that should be used when processing the security service
described by this security block. This field SHALL be described by this security block. This field SHALL be
represented by a CBOR array. Each entry in this array is a represented by a CBOR array. Each entry in this array is a
single security context parameter. A single parameter SHALL single security context parameter. A single parameter SHALL
also be represented as a CBOR array comprising a 2-tuple of the also be represented as a CBOR array comprising a 2-tuple of the
id and value of the parameter, as follows. id and value of the parameter, as follows.
skipping to change at page 17, line 5 skipping to change at page 16, line 49
The block-type-specific-data field follows the structure of the The block-type-specific-data field follows the structure of the
ASB. ASB.
A security target listed in the Security Targets field MUST NOT A security target listed in the Security Targets field MUST NOT
reference a security block defined in this specification (e.g., a reference a security block defined in this specification (e.g., a
BIB or a BCB). BIB or a BCB).
The Security Context MUST utilize an authentication mechanism or The Security Context MUST utilize an authentication mechanism or
an error detection mechanism. an error detection mechanism.
The EID of the security source MAY be present. If this field is
not present, then the security source of the block SHOULD be
inferred according to security policy and MAY default to the
bundle source. The security source MAY be specified as part of
security context parameters described in Section 3.10.
Notes: Notes:
o Designers SHOULD carefully consider the effect of setting flags o Designers SHOULD carefully consider the effect of setting flags
that either discard the block or delete the bundle in the event that either discard the block or delete the bundle in the event
that this block cannot be processed. that this block cannot be processed.
o Since OP(bib-integrity, target) is allowed only once in a bundle o Since OP(bib-integrity, target) is allowed only once in a bundle
per target, it is RECOMMENDED that users wishing to support per target, it is RECOMMENDED that users wishing to support
multiple integrity mechanisms for the same target define a multi- multiple integrity mechanisms for the same target define a multi-
result security context. Such a context could generate multiple result security context. Such a context could generate multiple
skipping to change at page 18, line 24 skipping to change at page 18, line 15
Any Security Context used by a BCB MUST utilize a confidentiality Any Security Context used by a BCB MUST utilize a confidentiality
cipher that provides authenticated encryption with associated data cipher that provides authenticated encryption with associated data
(AEAD). (AEAD).
Additional information created by a cipher suite (such as an Additional information created by a cipher suite (such as an
authentication tag) can be placed either in a security result authentication tag) can be placed either in a security result
field or in the generated cipher text. The determination of where field or in the generated cipher text. The determination of where
to place this information is a function of the cipher suite and to place this information is a function of the cipher suite and
security context used. security context used.
The EID of the security source MAY be present. If this field is
not present, then the security source of the block SHOULD be
inferred according to security policy and MAY default to the
bundle source. The security source MAY be specified as part of
security context parameters described in Section 3.10.
The BCB modifies the contents of its security target(s). When a BCB The BCB modifies the contents of its security target(s). When a BCB
is applied, the security target body data are encrypted "in-place". is applied, the security target body data are encrypted "in-place".
Following encryption, the security target block-type-specific-data Following encryption, the security target block-type-specific-data
field contains cipher text, not plain text. field contains cipher text, not plain text.
Notes: Notes:
o It is RECOMMENDED that designers carefully consider the effect of o It is RECOMMENDED that designers carefully consider the effect of
setting flags that delete the bundle in the event that this block setting flags that delete the bundle in the event that this block
cannot be processed. cannot be processed.
skipping to change at page 23, line 40 skipping to change at page 23, line 40
block-type-specific-data field is a CBOR byte string existing within block-type-specific-data field is a CBOR byte string existing within
the CBOR array containing the fields of the extension block. The the CBOR array containing the fields of the extension block. The
entire CBOR byte string is considered the canonical block-type- entire CBOR byte string is considered the canonical block-type-
specific-data field. The CBOR array framing is not considered part specific-data field. The CBOR array framing is not considered part
of the field. of the field.
The canonical form of the primary block is as specified in The canonical form of the primary block is as specified in
[I-D.ietf-dtn-bpbis] with the following constraint. [I-D.ietf-dtn-bpbis] with the following constraint.
o CBOR values from the primary block MUST be canonicalized using the o CBOR values from the primary block MUST be canonicalized using the
rules for Canonical CBOR, as specified in [RFC7049]. Canonical rules for Deterministically Encoded CBOR, as specified in
CBOR generally requires that integers and type lengths are encoded [RFC8949].
to be as small as possible, that map values be sorted, and that
indefinite-length items be made into definite-length items.
All non-primary blocks share the same block structure and are All non-primary blocks share the same block structure and are
canonicalized as specified in [I-D.ietf-dtn-bpbis] with the following canonicalized as specified in [I-D.ietf-dtn-bpbis] with the following
constraints. constraints.
o CBOR values from the non-primary block MUST be canonicalized using o CBOR values from the non-primary block MUST be canonicalized using
the rules for Canonical CBOR, as specified in [RFC7049]. the rules for Deterministically Encoded CBOR, as specified in
[RFC8949].
o Only the block-type-specific-data field may be provided to a o Only the block-type-specific-data field may be provided to a
cipher suite for encryption as part of a confidentiality security cipher suite for encryption as part of a confidentiality security
service. Other fields within a non-primary-block MUST NOT be service. Other fields within a non-primary-block MUST NOT be
encrypted or decrypted and MUST NOT be included in the canonical encrypted or decrypted and MUST NOT be included in the canonical
form used by the cipher suite for encryption and decryption. form used by the cipher suite for encryption and decryption.
These other fields MAY have an integrity protection mechanism These other fields MAY have an integrity protection mechanism
applied to them by treating them as associated authenticated data. applied to them by treating them as associated authenticated data.
o Reserved and unassigned flags in the block processing control o Reserved and unassigned flags in the block processing control
skipping to change at page 28, line 50 skipping to change at page 28, line 50
Bundle protocol agents (BPAs) must process blocks and bundles in Bundle protocol agents (BPAs) must process blocks and bundles in
accordance with both BP policy and BPSec policy. The decision to accordance with both BP policy and BPSec policy. The decision to
receive, forward, deliver, or delete a bundle may be communicated to receive, forward, deliver, or delete a bundle may be communicated to
the report-to address of the bundle, in the form of a status report, the report-to address of the bundle, in the form of a status report,
as a method of tracking the progress of the bundle through the as a method of tracking the progress of the bundle through the
network. The status report for a bundle may be augmented with a network. The status report for a bundle may be augmented with a
"reason code" explaining why the particular action was taken on the "reason code" explaining why the particular action was taken on the
bundle. bundle.
This section describes a set of reason codes associated with the This section describes a set of reason codes associated with the
security processing of a bundle. Security reason codes are assigned security processing of a bundle. The communication of security-
in accordance with Section 11.2. related status reports might reduce the security of a network if
these reports are intercepted by unintended recipients. BPSec policy
SHOULD specify the conditions in which sending security reason codes
are appropriate. Examples of appropriate conditions for the use of
security reason codes could include the following.
o When the report-to address is verified as unchanged from the
bundle source. This can occur by placing an appropriate BIB on
the bundle primary block.
o When the block containing a status report with a security reason
code is encrypted by a BCB.
o When a status report containing a security reason code is only
sent for security issues relating to bundles and/or blocks
associated with non-operational user data or otherwise with test
data.
o When a status report containing a security reason code is only
sent for security issues associated with non-operational security
contexts, or security contexts using non-operational
configurations, such as test keys.
Security reason codes are assigned in accordance with Section 11.2
and are as described below.
Missing Security Operation: Missing Security Operation:
This reason code indicates that a bundle was missing one or This reason code indicates that a bundle was missing one or
more required security operations. This reason code is more required security operations. This reason code is
typically used by a security verifier or security acceptor. typically used by a security verifier or security acceptor.
Unknown Security Operation: Unknown Security Operation:
This reason code indicates that one or more security operations This reason code indicates that one or more security operations
present in a bundle cannot be understood by the security present in a bundle cannot be understood by the security
verifier or security acceptor for the operation. For example, verifier or security acceptor for the operation. For example,
skipping to change at page 37, line 47 skipping to change at page 38, line 26
block. This information MAY include the block type code, block block. This information MAY include the block type code, block
number, CRC Type and CRC field (if present or if missing and number, CRC Type and CRC field (if present or if missing and
unlikely to be added later), and possibly certain block processing unlikely to be added later), and possibly certain block processing
control flags. Designers should input these fields as additional control flags. Designers should input these fields as additional
data for integrity protection when these fields are expected to data for integrity protection when these fields are expected to
remain unchanged over the path the block will take from the remain unchanged over the path the block will take from the
security source to the security acceptor. Security contexts security source to the security acceptor. Security contexts
considering block header information MUST describe expected considering block header information MUST describe expected
behavior when these fields fail their integrity verification. behavior when these fields fail their integrity verification.
o Handling CRC Fields. Security contexts may include algorithms
that alter the contexts of their security target block, such as
the case when encrypting the block-type-specific data of a target
block as part oF a BCB confidentiality service. Security context
specifications SHOULD address how preexisting CRC-Type and CRC-
Value fields be handled. For example, a BCB security context
could remove the plain-text CRC value from its target upon
encryption and replace or recalculate the value upon decryption.
10. Defining Other Security Blocks 10. Defining Other Security Blocks
Other security blocks (OSBs) may be defined and used in addition to Other security blocks (OSBs) may be defined and used in addition to
the security blocks identified in this specification. Both the usage the security blocks identified in this specification. Both the usage
of BIB, BCB, and any future OSBs can co-exist within a bundle and can of BIB, BCB, and any future OSBs can co-exist within a bundle and can
be considered in conformance with BPSec if each of the following be considered in conformance with BPSec if each of the following
requirements are met by any future identified security blocks. requirements are met by any future identified security blocks.
o Other security blocks (OSBs) MUST NOT reuse any enumerations o Other security blocks (OSBs) MUST NOT reuse any enumerations
identified in this specification, to include the block type codes identified in this specification, to include the block type codes
skipping to change at page 41, line 14 skipping to change at page 41, line 50
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
Text on Security Considerations", BCP 72, RFC 3552, Text on Security Considerations", BCP 72, RFC 3552,
DOI 10.17487/RFC3552, July 2003, DOI 10.17487/RFC3552, July 2003,
<https://www.rfc-editor.org/info/rfc3552>. <https://www.rfc-editor.org/info/rfc3552>.
[RFC6255] Blanchet, M., "Delay-Tolerant Networking Bundle Protocol [RFC6255] Blanchet, M., "Delay-Tolerant Networking Bundle Protocol
IANA Registries", RFC 6255, DOI 10.17487/RFC6255, May IANA Registries", RFC 6255, DOI 10.17487/RFC6255, May
2011, <https://www.rfc-editor.org/info/rfc6255>. 2011, <https://www.rfc-editor.org/info/rfc6255>.
[RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049,
October 2013, <https://www.rfc-editor.org/info/rfc7049>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", STD 94, RFC 8949,
DOI 10.17487/RFC8949, December 2020,
<https://www.rfc-editor.org/info/rfc8949>.
12.2. Informative References 12.2. Informative References
[I-D.birrane-dtn-sbsp] [I-D.birrane-dtn-sbsp]
Birrane, E., Pierce-Mayer, J., and D. Iannicca, Birrane, E., Pierce-Mayer, J., and D. Iannicca,
"Streamlined Bundle Security Protocol Specification", "Streamlined Bundle Security Protocol Specification",
draft-birrane-dtn-sbsp-01 (work in progress), October draft-birrane-dtn-sbsp-01 (work in progress), October
2015. 2015.
[RFC4838] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst, [RFC4838] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst,
R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant
 End of changes. 25 change blocks. 
53 lines changed or deleted 76 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/