draft-ietf-dtn-bpsec-20.txt   draft-ietf-dtn-bpsec-21.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: August 10, 2020 February 7, 2020 Expires: September 2, 2020 March 1, 2020
Bundle Protocol Security Specification Bundle Protocol Security Specification
draft-ietf-dtn-bpsec-20 draft-ietf-dtn-bpsec-21
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 August 10, 2020. This Internet-Draft will expire on September 2, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 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
skipping to change at page 2, line 15 skipping to change at page 2, line 15
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Supported Security Services . . . . . . . . . . . . . . . 3 1.1. Supported Security Services . . . . . . . . . . . . . . . 3
1.2. Specification Scope . . . . . . . . . . . . . . . . . . . 4 1.2. Specification Scope . . . . . . . . . . . . . . . . . . . 4
1.3. Related Documents . . . . . . . . . . . . . . . . . . . . 5 1.3. Related Documents . . . . . . . . . . . . . . . . . . . . 5
1.4. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 1.4. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6
2. Design Decisions . . . . . . . . . . . . . . . . . . . . . . 7 2. Design Decisions . . . . . . . . . . . . . . . . . . . . . . 7
2.1. Block-Level Granularity . . . . . . . . . . . . . . . . . 7 2.1. Block-Level Granularity . . . . . . . . . . . . . . . . . 7
2.2. Multiple Security Sources . . . . . . . . . . . . . . . . 8 2.2. Multiple Security Sources . . . . . . . . . . . . . . . . 8
2.3. Mixed Security Policy . . . . . . . . . . . . . . . . . . 8 2.3. Mixed Security Policy . . . . . . . . . . . . . . . . . . 9
2.4. User-Defined Security Contexts . . . . . . . . . . . . . 9 2.4. User-Defined Security Contexts . . . . . . . . . . . . . 9
2.5. Deterministic Processing . . . . . . . . . . . . . . . . 9 2.5. Deterministic Processing . . . . . . . . . . . . . . . . 10
3. Security Blocks . . . . . . . . . . . . . . . . . . . . . . . 9 3. Security Blocks . . . . . . . . . . . . . . . . . . . . . . . 10
3.1. Block Definitions . . . . . . . . . . . . . . . . . . . . 9 3.1. Block Definitions . . . . . . . . . . . . . . . . . . . . 10
3.2. Uniqueness . . . . . . . . . . . . . . . . . . . . . . . 10 3.2. Uniqueness . . . . . . . . . . . . . . . . . . . . . . . 10
3.3. Target Multiplicity . . . . . . . . . . . . . . . . . . . 11 3.3. Target Multiplicity . . . . . . . . . . . . . . . . . . . 11
3.4. Target Identification . . . . . . . . . . . . . . . . . . 12 3.4. Target Identification . . . . . . . . . . . . . . . . . . 12
3.5. Block Representation . . . . . . . . . . . . . . . . . . 12 3.5. Block Representation . . . . . . . . . . . . . . . . . . 13
3.6. Abstract Security Block . . . . . . . . . . . . . . . . . 12 3.6. Abstract Security Block . . . . . . . . . . . . . . . . . 13
3.7. Block Integrity Block . . . . . . . . . . . . . . . . . . 15 3.7. Block Integrity Block . . . . . . . . . . . . . . . . . . 16
3.8. Block Confidentiality Block . . . . . . . . . . . . . . . 16 3.8. Block Confidentiality Block . . . . . . . . . . . . . . . 17
3.9. Block Interactions . . . . . . . . . . . . . . . . . . . 17 3.9. Block Interactions . . . . . . . . . . . . . . . . . . . 18
3.10. Parameter and Result Identification . . . . . . . . . . . 18 3.10. Parameter and Result Identification . . . . . . . . . . . 19
3.11. BSP Block Examples . . . . . . . . . . . . . . . . . . . 19 3.11. BSP Block Examples . . . . . . . . . . . . . . . . . . . 20
3.11.1. Example 1: Constructing a Bundle with Security . . . 19 3.11.1. Example 1: Constructing a Bundle with Security . . . 20
3.11.2. Example 2: Adding More Security At A New Node . . . 20 3.11.2. Example 2: Adding More Security At A New Node . . . 21
4. Canonical Forms . . . . . . . . . . . . . . . . . . . . . . . 22 4. Canonical Forms . . . . . . . . . . . . . . . . . . . . . . . 23
5. Security Processing . . . . . . . . . . . . . . . . . . . . . 23 5. Security Processing . . . . . . . . . . . . . . . . . . . . . 24
5.1. Bundles Received from Other Nodes . . . . . . . . . . . . 23 5.1. Bundles Received from Other Nodes . . . . . . . . . . . . 24
5.1.1. Receiving BCBs . . . . . . . . . . . . . . . . . . . 23 5.1.1. Receiving BCBs . . . . . . . . . . . . . . . . . . . 24
5.1.2. Receiving BIBs . . . . . . . . . . . . . . . . . . . 24 5.1.2. Receiving BIBs . . . . . . . . . . . . . . . . . . . 25
5.2. Bundle Fragmentation and Reassembly . . . . . . . . . . . 25 5.2. Bundle Fragmentation and Reassembly . . . . . . . . . . . 26
6. Key Management . . . . . . . . . . . . . . . . . . . . . . . 25 6. Key Management . . . . . . . . . . . . . . . . . . . . . . . 26
7. Security Policy Considerations . . . . . . . . . . . . . . . 25 7. Security Policy Considerations . . . . . . . . . . . . . . . 26
8. Security Considerations . . . . . . . . . . . . . . . . . . . 27 8. Security Considerations . . . . . . . . . . . . . . . . . . . 28
8.1. Attacker Capabilities and Objectives . . . . . . . . . . 27 8.1. Attacker Capabilities and Objectives . . . . . . . . . . 28
8.2. Attacker Behaviors and BPSec Mitigations . . . . . . . . 28 8.2. Attacker Behaviors and BPSec Mitigations . . . . . . . . 29
8.2.1. Eavesdropping Attacks . . . . . . . . . . . . . . . . 28 8.2.1. Eavesdropping Attacks . . . . . . . . . . . . . . . . 29
8.2.2. Modification Attacks . . . . . . . . . . . . . . . . 29 8.2.2. Modification Attacks . . . . . . . . . . . . . . . . 30
8.2.3. Topology Attacks . . . . . . . . . . . . . . . . . . 30 8.2.3. Topology Attacks . . . . . . . . . . . . . . . . . . 31
8.2.4. Message Injection . . . . . . . . . . . . . . . . . . 31 8.2.4. Message Injection . . . . . . . . . . . . . . . . . . 32
9. Security Context Considerations . . . . . . . . . . . . . . . 31 9. Security Context Considerations . . . . . . . . . . . . . . . 32
9.1. Mandating Security Contexts . . . . . . . . . . . . . . . 31 9.1. Mandating Security Contexts . . . . . . . . . . . . . . . 32
9.2. Identification and Configuration . . . . . . . . . . . . 32 9.2. Identification and Configuration . . . . . . . . . . . . 33
9.3. Authorship . . . . . . . . . . . . . . . . . . . . . . . 33 9.3. Authorship . . . . . . . . . . . . . . . . . . . . . . . 34
10. Defining Other Security Blocks . . . . . . . . . . . . . . . 34 10. Defining Other Security Blocks . . . . . . . . . . . . . . . 35
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36
11.1. Bundle Block Types . . . . . . . . . . . . . . . . . . . 36 11.1. Bundle Block Types . . . . . . . . . . . . . . . . . . . 37
11.2. Security Context Identifiers . . . . . . . . . . . . . . 36 11.2. Security Context Identifiers . . . . . . . . . . . . . . 37
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 36 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 37
12.1. Normative References . . . . . . . . . . . . . . . . . . 36 12.1. Normative References . . . . . . . . . . . . . . . . . . 37
12.2. Informative References . . . . . . . . . . . . . . . . . 37 12.2. Informative References . . . . . . . . . . . . . . . . . 38
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 38 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 39
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39
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.
The Bundle Protocol specification [I-D.ietf-dtn-bpbis] defines DTN as The Bundle Protocol specification [I-D.ietf-dtn-bpbis] defines DTN as
referring to "a networking architecture providing communications in referring to "a networking architecture providing communications in
and/or through highly stressed environments" where "BP may be viewed and/or through highly stressed environments" where "BP may be viewed
as sitting at the application layer of some number of constituent as sitting at the application layer of some number of constituent
networks, forming a store-carry-forward overlay network". The term networks, forming a store-carry-forward overlay network". The term
"stressed" environment refers to multiple challenging conditions "stressed" environment refers to multiple challenging conditions
including intermittent connectivity, large and/or variable delays, including intermittent connectivity, large and/or variable delays,
asymmetric data rates, and high bit error rates. asymmetric data rates, and high bit error rates.
The BP might be deployed such that portions of the network cannot be It should be presumed that the BP will be deployed such that the
trusted, posing the usual security challenges related to network cannot be trusted, posing the usual security challenges
confidentiality and integrity. However, the stressed nature of the related to confidentiality and integrity. However, the stressed
BP operating environment imposes unique conditions where usual nature of the BP operating environment imposes unique conditions
transport security mechanisms may not be sufficient. For example, where usual transport security mechanisms may not be sufficient. For
the store-carry-forward nature of the network may require protecting example, the store-carry-forward nature of the network may require
data at rest, preventing unauthorized consumption of critical protecting data at rest, preventing unauthorized consumption of
resources such as storage space, and operating without regular critical resources such as storage space, and operating without
contact with a centralized security oracle (such as a certificate regular contact with a centralized security oracle (such as a
authority). certificate authority).
An end-to-end security service is needed that operates in all of the An end-to-end security service is needed that operates in all of the
environments where the BP operates. environments where the BP operates.
1.1. Supported Security Services 1.1. Supported Security Services
BPSec provides integrity and confidentiality services for BP bundles, BPSec provides integrity and confidentiality services for BP bundles,
as defined in this section. as defined in this section.
Integrity services ensure that changes to target data within a bundle Integrity services ensure that changes to target data within a bundle
skipping to change at page 5, line 9 skipping to change at page 5, line 9
not address threats which share computing resources with the DTN and/ not address threats which share computing resources with the DTN and/
or BPSec software implementations. These threats may be malicious or BPSec software implementations. These threats may be malicious
software or compromised libraries which intend to intercept data or software or compromised libraries which intend to intercept data or
recover cryptographic material. Here, it is the responsibility of recover cryptographic material. Here, it is the responsibility of
the BPSec implementer to ensure that any cryptographic material, the BPSec implementer to ensure that any cryptographic material,
including shared secret or private keys, is protected against access including shared secret or private keys, is protected against access
within both memory and storage devices. within both memory and storage devices.
This specification addresses neither the fitness of externally- This specification addresses neither the fitness of externally-
defined cryptographic methods nor the security of their defined cryptographic methods nor the security of their
implementation. Different networking conditions and operational implementation. Completely trusted networks are extremely uncommon.
considerations require varying strengths of security mechanism such Amongst untrusted networks, different networking conditions and
that mandating a cipher suite in this specification may result in too operational considerations require varying strengths of security
much security for some networks and too little security in others. mechanism. Mandating a cipher suite in this specification may result
It is expected that separate documents will be standardized to define in too much security for some networks and too little security in
security contexts and cipher suites compatible with BPSec, to include others. It is expected that separate documents will be standardized
those that should be used to assess interoperability and those fit to define security contexts and cipher suites compatible with BPSec,
for operational use in various network scenarios. A sample security to include those that should be used to assess interoperability and
context has been defined ([I-D.ietf-dtn-bpsec-interop-sc]) to support those fit for operational use in various network scenarios. A sample
interoperability testing and serve as an exemplar for how security security context has been defined ([I-D.ietf-dtn-bpsec-interop-sc])
contexts should be defined for this specification. to support interoperability testing and serve as an exemplar for how
security contexts should be defined for this specification.
This specification does not address the implementation of security This specification does not address the implementation of security
policy and does not provide a security policy for the BPSec. Similar policy and does not provide a security policy for the BPSec. Similar
to cipher suites, security policies are based on the nature and to cipher suites, security policies are based on the nature and
capabilities of individual networks and network operational concepts. capabilities of individual networks and network operational concepts.
This specification does provide policy considerations when building a This specification does provide policy considerations when building a
security policy. security policy.
With the exception of the Bundle Protocol, this specification does With the exception of the Bundle Protocol, this specification does
not address how to combine the BPSec security blocks with other not address how to combine the BPSec security blocks with other
skipping to change at page 7, line 29 skipping to change at page 7, line 35
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.
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, policies at that must consider physical properties of the network (such as
each node, application security requirements, and current and future connectivity and propagation times), policies at each node,
threat environments. This section identifies those desirable application security requirements, and current and future threat
properties that guide design decisions for this specification and are environments. This section identifies those desirable properties
necessary for understanding the format and behavior of the BPSec that guide design decisions for this specification and are necessary
protocol. for understanding the format and behavior of the BPSec protocol.
2.1. Block-Level Granularity 2.1. Block-Level Granularity
Security services within this specification must allow different Security services within this specification must allow different
blocks within a bundle to have different security services applied to blocks within a bundle to have different security services applied to
them. them.
Blocks within a bundle represent different types of information. The Blocks within a bundle represent different types of information. The
primary block contains identification and routing information. The primary block contains identification and routing information. The
payload block carries application data. Extension blocks carry a payload block carries application data. Extension blocks carry a
skipping to change at page 8, line 33 skipping to change at page 8, line 37
consistent with its security policy. consistent with its security policy.
When a waypoint adds a security service to the bundle, the waypoint When a waypoint adds a security service to the bundle, the waypoint
is the security source for that service. The security block(s) which is the security source for that service. The security block(s) which
represent that service in the bundle may need to record this security represent that service in the bundle may need to record this security
source as the bundle destination might need this information for source as the bundle destination might need this information for
processing. processing.
For example, a bundle source may choose to apply an integrity service For example, a bundle source may choose to apply an integrity service
to its plain text payload. Later a waypoint node, representing a to its plain text payload. Later a waypoint node, representing a
gateway to an insecure portion of the DTN, may receive the bundle and gateway to another portion of the DTN, may receive the bundle and
choose to apply a confidentiality service. In this case, the choose to apply a confidentiality service. In this case, the
integrity security source is the bundle source and the integrity security source is the bundle source and the
confidentiality security source is the waypoint node. confidentiality security source is the waypoint node.
In cases where the security source and security acceptor are not the
bundle source and bundle destination, it is possible that the bundle
will reach the bundle destination prior to reaching a security
acceptor. In cases where this may be a practical problem, it is
recommended that solutions such as bundle encapsulation can be used
to ensure that a bundle be delivered to a security acceptor prior to
being delivered to the bundle destination. Generally, if a bundle
reaches a waypoint that has the appropriate configuration and policy
to act as a security acceptor for a security service in the bundle,
then the waypoint should act as that security acceptor.
2.3. Mixed Security Policy 2.3. Mixed Security Policy
The security policy enforced by nodes in the DTN may differ. The security policy enforced by nodes in the DTN may differ.
Some waypoints might not be security aware and will not be able to Some waypoints might not be security aware and will not be able to
process security blocks. Therefore, security blocks must have their process security blocks. Therefore, security blocks must have their
processing flags set such that the block will be treated processing flags set such that the block will be treated
appropriately by non-security-aware waypoints. appropriately by non-security-aware waypoints.
Some waypoints will have security policies that require evaluating Some waypoints will have security policies that require evaluating
skipping to change at page 10, line 30 skipping to change at page 10, line 49
3.2. Uniqueness 3.2. Uniqueness
Security operations in a bundle MUST be unique; the same security Security operations in a bundle MUST be unique; the same security
service MUST NOT be applied to a security target more than once in a service MUST NOT be applied to a security target more than once in a
bundle. Since a security operation is represented as a security bundle. Since a security operation is represented as a security
block, this limits what security blocks may be added to a bundle: if block, this limits what security blocks may be added to a bundle: if
adding a security block to a bundle would cause some other security adding a security block to a bundle would cause some other security
block to no longer represent a unique security operation then the new block to no longer represent a unique security operation then the new
block MUST NOT be added. block MUST NOT be added.
The uniqueness requirement imposed by this specification implies that
the security source for some security target is providing the initial
service for that target. This is the case when the security source
is also the source of the target. This can also occur when the
security source is adding the service to a pre-existing target for
the first time. If more complex security combinations are required,
this specification allows for the definition of custom security
contexts (Section 9) and other security blocks (Section 10).
A security operation may be removed from a bundle as part of A security operation may be removed from a bundle as part of
processing a security block and, once removed, the same security processing a security block and, once removed, the same security
operation may be re-applied by adding a new security block into the operation may be re-applied by adding a new security block into the
bundle. In this case, conflicting security blocks never co-exist in bundle. In this case, conflicting security blocks never co-exist in
the bundle at the same time. the bundle at the same time.
It is important to note that any cipher text integrity mechanism It is important to note that any cipher text integrity mechanism
supplied by the BCB is considered part of the confidentiality service supplied by the BCB is considered part of the confidentiality service
and, therefore, unique from the plain text integrity service provided and, therefore, unique from the plain text integrity service provided
by the BIB. by the BIB.
skipping to change at page 13, line 17 skipping to change at page 13, line 48
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
this array. this array. The order of elements in this list has no semantic
meaning outside of the context of this block. Within the
block, the ordering of targets must match the ordering of
results associated with these targets.
Security Context Id: Security Context Id:
This field identifies the security context used to implement This field identifies the security context used to implement
the security service represented by this block and applied to the security service represented by this block and applied to
each security target. This field SHALL be represented by a each security target. This field SHALL be represented by a
CBOR unsigned integer. The values for this Id should come from CBOR unsigned integer. The values for this Id should come from
the registry defined in Section 11.2 the registry defined in Section 11.2
Security Context Flags: Security Context Flags:
This field identifies which optional fields are present in the This field identifies which optional fields are present in the
skipping to change at page 22, line 44 skipping to change at page 23, line 44
exceptions. exceptions.
o If the service being applied is a confidentiality service, then o If the service being applied is a confidentiality service, then
the block type code, block number, block processing control flags, the block type code, block number, block processing control flags,
CRC type and CRC field (if present), and the length indication of CRC type and CRC field (if present), and the length indication of
the block-type-specific-data field MUST NOT be included in a the block-type-specific-data field MUST NOT be included in a
canonical form. Confidentiality services are used solely to canonical form. Confidentiality services are used solely to
convert block data in the block-type-specific-data field from convert block data in the block-type-specific-data field from
plain text to cipher text. plain text to cipher text.
o Reserved flags in the block processing control flags field MUST o Reserved flags in the block processing control flags field MUST be
NOT be included in a canonical form as it is not known if those set to 0 in a canonical form as it is not known if those flags
flags will change in transit. will change in transit.
Cipher suites and security contexts MAY define their own Cipher suites and security contexts MAY define their own
canonicalization algorithms and require the use of those algorithms canonicalization algorithms and require the use of those algorithms
over the ones provided in this specification. In the event of over the ones provided in this specification. In the event of
conflicting canonicalization algorithms, those algorithms take conflicting canonicalization algorithms, those algorithms take
precedence over this specification. precedence over this specification.
5. Security Processing 5. Security Processing
This section describes the security aspects of bundle processing. This section describes the security aspects of bundle processing.
skipping to change at page 31, line 33 skipping to change at page 32, line 33
prevent other activities). prevent other activities).
BPSec relies on cipher suite capabilities to prevent replay or forged BPSec relies on cipher suite capabilities to prevent replay or forged
message attacks. A BCB used with appropriate cryptographic message attacks. A BCB used with appropriate cryptographic
mechanisms may provide replay protection under certain circumstances. mechanisms may provide replay protection under certain circumstances.
Alternatively, application data itself may be augmented to include Alternatively, application data itself may be augmented to include
mechanisms to assert data uniqueness and then protected with a BIB, a mechanisms to assert data uniqueness and then protected with a BIB, a
BCB, or both along with other block data. In such a case, the BCB, or both along with other block data. In such a case, the
receiving node would be able to validate the uniqueness of the data. receiving node would be able to validate the uniqueness of the data.
For example, a BIB may be used to validate the integrity of a
bundle's primary block, which includes a timestamp and lifetime for
the bundle. If a bundle is replayed outside of its lifetime, then
the replay attack will fail as the bundle will be discarded.
Similarly, additional blocks such as the Bundle Age may be signed and
validated to identify replay attacks. Finally, security context
parameters within BIB and BCB blocks may include anti-replay
mechanisms such as session identifiers, nonces, and dynamic passwords
as supported by network characteristics.
9. Security Context Considerations 9. Security Context Considerations
9.1. Mandating Security Contexts 9.1. Mandating Security Contexts
Because of the diversity of networking scenarios and node Because of the diversity of networking scenarios and node
capabilities that may utilize BPSec there is no one security context capabilities that may utilize BPSec there is no one security context
mandated for every possible BPSec implementation. For example, a mandated for every possible BPSec implementation. For example, a
security context appropriate for a resource-constrained node with security context appropriate for a resource-constrained node with
limited connectivity may be inappropriate for use in a well- limited connectivity may be inappropriate for use in a well-
resourced, well connected node. resourced, well connected node.
skipping to change at page 37, line 10 skipping to change at page 38, line 10
12. References 12. References
12.1. Normative References 12.1. Normative References
[I-D.ietf-dtn-bpbis] [I-D.ietf-dtn-bpbis]
Burleigh, S., Fall, K., and E. Birrane, "Bundle Protocol Burleigh, S., Fall, K., and E. Birrane, "Bundle Protocol
Version 7", draft-ietf-dtn-bpbis-22 (work in progress), Version 7", draft-ietf-dtn-bpbis-22 (work in progress),
February 2020. February 2020.
[I-D.ietf-dtn-bpsec-interop-sc]
Birrane, E., "BPSec Interoperability Security Contexts",
draft-ietf-dtn-bpsec-interop-sc-01 (work in progress),
February 2020.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[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>.
skipping to change at page 37, line 40 skipping to change at page 38, line 45
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
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.
[I-D.ietf-dtn-bpsec-interop-sc]
Birrane, E., "BPSec Interoperability Security Contexts",
draft-ietf-dtn-bpsec-interop-sc-01 (work in progress),
February 2020.
[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
Networking Architecture", RFC 4838, DOI 10.17487/RFC4838, Networking Architecture", RFC 4838, DOI 10.17487/RFC4838,
April 2007, <https://www.rfc-editor.org/info/rfc4838>. April 2007, <https://www.rfc-editor.org/info/rfc4838>.
[RFC6257] Symington, S., Farrell, S., Weiss, H., and P. Lovell, [RFC6257] Symington, S., Farrell, S., Weiss, H., and P. Lovell,
"Bundle Security Protocol Specification", RFC 6257, "Bundle Security Protocol Specification", RFC 6257,
DOI 10.17487/RFC6257, May 2011, DOI 10.17487/RFC6257, May 2011,
<https://www.rfc-editor.org/info/rfc6257>. <https://www.rfc-editor.org/info/rfc6257>.
Appendix A. Acknowledgements Appendix A. Acknowledgements
The following participants contributed technical material, use cases, The following participants contributed technical material, use cases,
and useful thoughts on the overall approach to this security and useful thoughts on the overall approach to this security
specification: Scott Burleigh of the Jet Propulsion Laboratory, Amy specification: Scott Burleigh of the Jet Propulsion Laboratory,
Alford and Angela Hennessy of the Laboratory for Telecommunications Angela Hennessy of the Laboratory for Telecommunications Sciences,
Sciences, and Angela Dalton and Cherita Corbett of the Johns Hopkins and Amy Alford, Angela Dalton, and Cherita Corbett of the Johns
University Applied Physics Laboratory. Hopkins University Applied Physics Laboratory.
Authors' Addresses Authors' Addresses
Edward J. Birrane, III Edward J. Birrane, III
The Johns Hopkins University Applied Physics Laboratory The Johns Hopkins University Applied Physics Laboratory
11100 Johns Hopkins Rd. 11100 Johns Hopkins Rd.
Laurel, MD 20723 Laurel, MD 20723
US US
Phone: +1 443 778 7423 Phone: +1 443 778 7423
 End of changes. 18 change blocks. 
85 lines changed or deleted 119 lines changed or added

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