Internet DRAFT - draft-birrane-dtn-sec-practices
draft-birrane-dtn-sec-practices
Delay-Tolerant Networking E. Birrane
Internet-Draft Johns Hopkins Applied Physics Laboratory
Intended status: Experimental December 29, 2015
Expires: July 1, 2016
DTN Security Best Practices
draft-birrane-dtn-sec-practices-00
Abstract
This document describes best practices associated with achieving a
variety of security use cases with the set of DTN-related standards.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 1, 2016.
Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved.
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. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Birrane Expires July 1, 2016 [Page 1]
Internet-Draft SECP December 2015
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2. Motivation for Application-Layer Security . . . . . . . . 2
1.3. Scope of Security Information . . . . . . . . . . . . . . 3
1.4. Classes of Security Information . . . . . . . . . . . . . 4
1.5. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6
2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2. Bundle Protocol Review . . . . . . . . . . . . . . . . . 6
2.3. Bundle Protocol Security (BPSEC) . . . . . . . . . . . . 6
2.4. Bundle-in-Bundle Encapsulation . . . . . . . . . . . . . 7
3. Policy Considerations . . . . . . . . . . . . . . . . . . . . 8
4. Best Practices . . . . . . . . . . . . . . . . . . . . . . . 9
4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 9
4.2. Bundle Source End-to-End Block Security . . . . . . . . . 9
4.3. Waypoint Block Security . . . . . . . . . . . . . . . . . 10
4.4. Security Destinations . . . . . . . . . . . . . . . . . . 10
4.5. Cascading Operations . . . . . . . . . . . . . . . . . . 11
4.6. Hop by Hop Authentication . . . . . . . . . . . . . . . . 13
4.7. Path Verification . . . . . . . . . . . . . . . . . . . . 14
4.8. Parallel Authenticators/Decrypters . . . . . . . . . . . 15
4.9. Primary Block Integrity . . . . . . . . . . . . . . . . . 16
4.10. Primary Block Privacy . . . . . . . . . . . . . . . . . . 16
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
6. Informative References . . . . . . . . . . . . . . . . . . . 17
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction
1.1. Overview
This document outlines the motivation for an end-to-end, application
layer security capability as the collaborative effect of individual
capabilities. Such a mix-and-match model of applying services allows
for the more effective securing of a diverse set of disparate
challenged internetworking scenarios.
In the context of this document, security refers to providing for the
end-to-end integrity and confidentiality of application data.
1.2. Motivation for Application-Layer Security
Path diversity in a packetized, wireless internetwork increases
resiliency to loss of individual links. However, packetization and
multi-path, multi-hop communication severs the relationship between
user data and a communications link; it is no longer sufficient to
Birrane Expires July 1, 2016 [Page 2]
Internet-Draft SECP December 2015
tightly control a single communication link to provide security for
data exchange. The packets that comprise user data, by definition,
may traverse multiple links as they traverse the network and
accumulate at some user destination.
Securing link layers is not a sufficient mechanism for securing end-
to-end data for two reasons, as follows.
Impractical Coordination of Multiple Links:
Every link and enclave participating in the message path must
coordinate to ensure that a particular data exchange retains all
necessary security services. This is intractable when thousands
of packets representing a single set of user data flow over
multiple links and through multiple enclaves.
Shared Security Access Over Shared Links:
Different users of an internetwork may require different
security considerations. Since the concept of resource sharing
drives the adoption of internetworking, multiple missions will
want to use individual links to amortize the cost of resilient
communications. If security is restricted to links only, then
every user sharing the link must use the same security services
of the link. In such a scenario, there is no mechanism to
finely tune per-user security settings.
1.3. Scope of Security Information
At least three scopes of security exist in a packetized internetwork:
Link, Enclave, and End-to-End. These are based, loosely and
conceptually, on the Unix file permission concept of "User", "Group",
and "Other".
Birrane Expires July 1, 2016 [Page 3]
Internet-Draft SECP December 2015
+------------+------------------------------------------------------+
| Layer | Responsibilities |
+------------+------------------------------------------------------+
| Link | - point-to-point data exchange protected from data |
| | corruption. |
| | |
| | - link-specific security mechanisms at both the |
| | physical and data layers. |
| | |
| | - Ensures transmissions over the link are |
| | authenticated and preserve the integrity and |
| | confidentiality of the message. |
| | |
| | |
| | |
| Enclave | - Bound administrative and/or technical domains. |
| | |
| | - Abstract link details when links within one |
| | enclave behave differently than links in another. |
| | |
| | |
| | |
| End-to-End | - Ensure that application data is secured regardless |
| | of links or enclaves. |
| | |
| | - Remove assumptions based on a particular path of a |
| | packet in the network or other underlying security |
| | mechanisms. |
+------------+------------------------------------------------------+
Logical Security Scopes
1.4. Classes of Security Information
Three types of security-related information are considered by this
document: Security-Related Protocols, Node Security Policy, and
Cipher Suite Support.
Security-Related Protocols:
Protocols identify the data models, model encodings, and control
information associated with the communication and application of
the data model across a network.
Node Security Policy:
Security policy describes how individual nodes within a network
populate the data models associated with the protocols providing
data security. It is possible for multiple nodes in an
internetwork to implement identical protocols but to use
Birrane Expires July 1, 2016 [Page 4]
Internet-Draft SECP December 2015
different features of those protocols based on local or group
policy. This policy may be derived from data directly or
indirectly related to security and, therefore, policy drivers
must be considered separately from security protocols.
Cipher Suite Support:
Separate from protocol features and the policy that determines
what features to apply when, cipher suites generate the data
that is carried by security protocols. Since multiple cipher
suites can be used to generate the data used to populate the
data model of security-related protocols, cipher suite support
must be considered separately from protocols.
1.5. Scope
This document addresses how to achieve a series of application-layer,
end-to-end security functions via combinations of protocols,
policies, and cipher suites. This document does not provide the full
specification for any single protocol, policy, or cipher suite.
Specifically, this specification provides ways to achieve the
following kinds of behavior in an internetwork supporting certain
protocols and implementing certain policies and cipher suites.
Decoupled Routing and Security.
Original transmitters and forwarders of a bundle may wish to
apply security settings based on some envisioned end point for a
security service. However, it is unlikely in a general
internetworking deployment that a node will know the exact path
taken by a bundle through an internetwork. This is particularly
the case when the internetwork spans multiple enclaves with
different administrative policies. Therefore, security services
must be independent of individual message paths.
Make Common Cases Simple and Efficient.
There exists a common set of security services that are applied
to bundles, namely the end-to-end integrity and confidentiality
of message payloads. While there exist many exotic permutations
of security services for various internetworking use cases, this
simple and common case must remain effective and efficient so as
to not penalize simpler networks to accommodate complex
networks, whenever possible.
Provide Security Services Equally.
Messages exchanged within a DTN may have multiple security
services applied to different parts of them. For example,
security services applied to message headers separately from
secondary headers or payloads. To the extent possible, the
Birrane Expires July 1, 2016 [Page 5]
Internet-Draft SECP December 2015
implementation of security functions should be agnostic to the
type of data being secured.
2. Protocol Overview
2.1. Overview
This section provides a brief overview of the protocols considered by
this best practice document. This section covers only those
significant functional aspects necessary to inform the discussion of
how to combine functions for security services. Protocols covered by
this document include the Bundle Protocol (BP) [RFC5050], Bundle
Protocol Security (BPSec) [BPSec], and Bundle-in-Bundle Encapsulation
(BIBE) [BIBE].
2.2. Bundle Protocol Review
The Bundle Protocol (BP) is a packetized, overlay, store-and-forward
protocol proposed for the exchange of data in a variety of challenged
internetworking scenarios. A BP protocol data unit (PDU) is
characterized as a series of variable-length blocks, with two special
blocks required in the bundle and all other blocks optional. The two
required blocks are the primary block (which acts as a message
header) and the payload block, which is a standard payload area.
Additional blocks, called extension blocks and conceptually similar
to secondary headers, may also be added to the bundle. Extension
blocks may be added at any time, and by any node, as the bundle
traverses the internetwork. Bundles are addressed using End Point
Identifiers (EIDs), which identify an overlay destination (endpoint)
in the internetwork. The mapping between EIDs and nodes in the
network is many-to-many, so a node may be associated with several
EIDs, and one EID may be associated with multiple nodes to form a
multi-cast address.
2.3. Bundle Protocol Security (BPSEC)
The security standard currently proposed for BP and DTN is the Bundle
Protocol Security (BPSEC). BPSec defines security services captured
in extension blocks that may be applied to discrete portions of a
bundle. BPSec, as a protocol, operates at the "Group" and "World"
layer, without reliance on link security mechanisms. Policy
decisions on how BPSec services should or should not be applied to a
bundle may or may not choose to consider link layer mechanisms.
BPSec provides two extension blocks that capture integrity and
confidentiality services for other blocks within a bundle, as
follows.
Birrane Expires July 1, 2016 [Page 6]
Internet-Draft SECP December 2015
Block Integrity Blocks (BIB):
BIBs provide an integrity signature over some other block in the
bundle, such that a chance to the contents of the protected
"target" block would be detected by comparing the signature
captured in the BIB with a signature directly computed from the
contents of the target block.
Block Confidentiality Blocks (BCB):
BCBs provide a confidentiality mechanism over some other block
in the bundle. A BCB captured annotative information as to how
a protected, "target" block has been encrypted and the content
of the target block is re-written with ciphertext.
Note, BPSec does not specify the cipher suites used to populate the
BIB and BCB blocks. The selection of cipher suites and keys to
generate necessary data is a matter of policy.
2.4. Bundle-in-Bundle Encapsulation
Typically, the payload of a bundle contains some user or application
data (or a fragmented portion of such data). The BIBE protocol
provides a mechanism by which one bundle can be set as the payload of
another bundle. This introduces the terminology of encapsulated and
encapsulating bundles, as follows.
Encapsulated Bundle:
An encapsulated bundle is a bundle that is serialized, in whole,
as the payload of some other bundle. Once encapsulated, the
bundle is indistinguishable from a block of application payload
on the wire and is not treated as a bundle until it is extracted
at the destination if its encapsulating bundle. At the
encapsulating bundle destination, the encapsulated bundle is
extracted and passed to the destination as if it had been
delivered there directly.
Encapsulating Bundle:
An encapsulating bundle is a bundle which has, as its payload,
an encapsulated bundle. Any extension blocks or policy
decisions made regarding this encapsulating bundle are separate
from the encapsulated bundle. The encapsulated bundle is
treated solely as a payload until the encapsulating bundle
reaches its destination, at which point the encapsulating bundle
is discarded and the encapsulated bundle is reconstituted and
given to the node for processing.
The BIBE mechanism is used to create tunnels with the BP
specification and is a useful way to maintain a separation between
security and routing while allowing some way to introduce required
Birrane Expires July 1, 2016 [Page 7]
Internet-Draft SECP December 2015
security waypoints in a path. Namely, while it is not possible, in
the general case, to tell a single bundle to traverse multiple
specific nodes from end to end, it is possible to establish multiple
tunnels for the bundle to pass through using the BIBE mechanism.
3. Policy Considerations
Policies and configurations must be documented separately from both
implementing protocols and best practices. Since the primary value
of sharing policy and configuration information is to ensure the
interoperability of multiple security services this information
should be standardized whenever possible. Security policy documents
should identify what security services are required in given network
deployments and what actions should be taken when messages do not
adhere to these expectations.
The following policy scenarios are strongly recommended for
consideration in any such documentation relating to standards for DTN
security.
Less Security Than Required:
When the network requires a certain level of security, such as
encrypted payloads or authenticated message exchange and a
message is received without this information, the network must
handle this in a uniform way. Most policies require not
forwarding the message, but the level of logging, error
messaging, and updates to local configurations should be
discussed as a matter of policy.
More Security Than Required:
Similarly, when messages are received that contain
authentication, integrity, or confidentiality when they should
not, a decision must be made as to whether these services will
be honored by the network.
Security Evaluation In Transit:
Some security services may be evaluated at a node, even when the
node is not the bundle destination or a security destination.
For example, a node may choose to validate an integrity
signature of a bundle block. If an integrity check fails to
validate, the intermediate node may choose to ignore the error,
remove the offending block, or remove the entire bundle.
Fragmentation:
Policy must determine how security blocks are distributed
amongst the new bundle fragments, so as to allow received
fragments to be validated at downstream nodes
Birrane Expires July 1, 2016 [Page 8]
Internet-Draft SECP December 2015
Block and Bundle Severability:
Distinct from fragmentation, nodes must decide whether a
security error associated with a block implies a larger security
error associated with the bundle. If blocks and bundles are
considered severable, then an offending block may be omitted
from the bundle. Otherwise, a bundle should be discarded
whenever any of its constituent blocks are discarded.
4. Best Practices
4.1. Overview
Complex security activities are achieved through the combination of
multiple discrete protocols rather than the creation of tightly-
coupled, highly-purposed protocols. Given a set of loosely coupled,
highly cohesive protocols, a set of best-practices can be provided to
implement security operations.
4.2. Bundle Source End-to-End Block Security
4.2.1. Need
This is the common case for block-level security services. In this
case, a bundle source wishes to apply integrity and/or
confidentiality to one or more blocks in a bundle and for these
services to persist until the bundle reaches its destination.
4.2.2. Recommended Practice
This is the common case supported directly by BPSec without
modification. In this case, each block being protected will have an
additional security block (BIB or BCB) added to the bundle. The BIB
and BCB blocks will contain all necessary security information based
on cipher suites which must be selected in accordance with some
policy at the node. Once the BIB and BCB blocks are added to the
bundle, the bundle may be sent through the network and no additional
operations are necessary until the bundle reaches the destination, at
which point BIBs and BCBs are verified and processed in accordance
with the BPSec specification.
4.2.3. Additional Policy Considerations
Transmit Rules:
The originating node must determine, by policy and
configuration, what services are necessary based on the
destination of the bundle.
Key and Cipher Suite Selection:
Birrane Expires July 1, 2016 [Page 9]
Internet-Draft SECP December 2015
The originating node must determine which keys are used to
configure which cipher suites will populate the necessary
blocks.
4.3. Waypoint Block Security
4.3.1. Need
Certain network configurations may require that security services be
added to a bundle by a waypoint node rather than the originator of
the bundle. A motivating example of this need is a network where a
bundle requires only integrity services within an enclave but
requires confidentiality before the bundle leaves the enclave to
route over a more public network. In such cases, a gateway node at
the border of the enclave and the public network may add
confidentiality services to any bundle that does not already have
such services before allowing the bundle to leave the enclave.
4.3.2. Recommended Practice
This is a minor extension to the case where the bundle source adds a
security block. In this case, BPSec blocks (BIB and BCB) are also
added to the bundle, but the security source of these blocks is
listed as the waypoint node adding the block, rather than the bundle
source node. The processing and behavior of the block is, otherwise,
unchanged.
4.3.3. Additional Policy Considerations
The policy considerations for a waypoint adding a security service
are the same as when a bundle source adds a security service.
4.4. Security Destinations
4.4.1. Need
There may be times when a bundle is requested to go through a
specific waypoint node en-route to its destination. From a security
standpoint, this is typically done to ensure that some security
result is achieved, for example ensuring that a bundle goes through a
specific gateway for appending extra security services.
4.4.2. Recommended Practice
The current recommended practice for general networks to accomplish
security-related destinations is to use the BIBE to wrap a bundle
into an encapsulating bundle, and then use the security destination
as the destination of the encapsulating bundle. In this way, the
Birrane Expires July 1, 2016 [Page 10]
Internet-Draft SECP December 2015
routing mechanism used in the network is not coupled to the security
system, and the encapsulated bundle is not burdened with tracking
multiple intermediate destinations.
This is the equivalent of creating a tunnel between the current node
and the security destination. If, at the security destination, a
subsequent security destination is necessary, the process may be
repeated.
4.4.3. Additional Policy Considerations
Security Destination Identification
To require security destinations, there must be some mechanism
by which security destinations are identified and some other
mechanism to associate bundles with those security destinations.
Extension Block Handling
Care must be taken to process, correctly, extension blocks both
in the encapsulated bundle and the encapsulating bundle. There
may exist extension blocks in the encapsulated bundle that wish
to be processed at every hop taken by the bundle, even while it
encapsulated. In such situations it might be possible to carry
these blocks in the encapsulating bundle and merge them back
into the encapsulated bundle at the security destination. Note,
however, there is no standard for this.
4.5. Cascading Operations
4.5.1. Need
Cascading operations are security services that are applied to the
same data multiple times, such as is the case when performing super-
encryption. The BPSec standard does not allow the same security
service to be applied to the same target data multiple times (for
example, a payload cannot be encrypted twice with two BCBs).
There are several reasons for wanting to replace or modify security
services found in a bundle. Policy may require a stronger security
service before a bundle is allowed to leave an enclave.
Alternatively, portions of the network may be configured with
different cipher suite support rendering in-situ integrity checking
impossible unless a new integrity signature in a supported cipher
suite is added. At times, encrypting parts of an existing BCB or BIB
to hide cipher suite details may be required.
Birrane Expires July 1, 2016 [Page 11]
Internet-Draft SECP December 2015
4.5.2. Recommended Practice
When cascading operations are to be applied from the current node to
the bundle destination each of these practices can be applied
directly to the bundle. In cases where cascading operations are only
to be applied from the current node to someplace other than the
bundle destination then, first, Security Destination best practices
must be applied.
There are three recommended ways to satisfy this need in BP networks:
Bundle encapsulation, Block encapsulation, and custom blocks.
Bundle Encapsulation:
There have been many proposals relating to how to stack security
operations amongst blocks in a bundle. However, each of these
results in complex situations regarding the order in which
operations are applied and how to preserve meaning in the
presence of fragmentation.
This approach maintains the BPSec restriction of one security
service per target in a single bundle and use BIBE and
encapsulation. In such a scheme, the existing bundle becomes
the encapsulated bundle. The encapsulating bundle then applies
whatever additional security services are necessary to its
payload, thereby applying them to the encapsulated bundle.
Block Encapsulation
There is, currently, no standard for block encapsulation.
However, the target block and its associated security blocks
may, themselves, be packed into a single new block within the
bundle and new security services may be added to that
encapsulating block.
Custom Security
A set of custom security blocks can be defined by a particular
network that operate orthogonally from the BPSec security
blocks. This proves fine-grained control over security in
specific network deployments. This method is only practical in
closed, highly controlled networks where custom block definition
and processing is both technically feasible and economical.
4.5.3. Additional Policy Considerations
Security Service Identification:
Nodes in the network must be able to identify appropriate
security services and cipher suites to some understood
destination.
Birrane Expires July 1, 2016 [Page 12]
Internet-Draft SECP December 2015
4.6. Hop by Hop Authentication
4.6.1. Need
Hop by hop authentication ensures that a received bundle's last hop
(i.e. most recent forwarder) matches what the bundle claims it's last
hop to be. Checking each hop along a path in the network is one way
to establish a chain of trust. More importantly, verifying the
appropriateness of the node who sent a received bundle is a way of
protecting networks against certain types of attacks. Specifically,
the internals of a network can be protected against resource-
consuming attacks if a gateway node can detect inappropriate traffic
and prevent its ingest into the rest of the network.
4.6.2. Recommended Practice
There are three recommended ways to satisfy this need in BP networks:
Reliable link layers, integrity on ephemeral blocks, and
canonicalized whole-bundle signatures.
Reliable Link Layers:
By definition, link-layer security secures the transmission
between two points (a link) in a network. Wherever hop-by-hop
authentication is required, the network might simply require the
use of a secure point-to-point link layer. In such a case,
there is no need for an application-layer mechanism for hop-by
hop security.
Ephemeral Block Integrity:
Assuming that secure link layers are not guaranteed to be
available, a second practice is to insert a short-lived
(ephemeral) block into a bundle just prior to transmission that
identifies the transmitter of the bundle, sign that block with a
BPSec BIB, and then transmit the bundle.
Such an ephemeral block is defined in the BP specification as a
Prior Hop Notification (PHN) Block and can be used for this
purpose. Alternatively, a user may define their own block type
which can hold any information they wish, to include a signature
calculated over the entire bundle rather than an assertion of
the previous bundle transmitter.
When the bundle is received at the next hop, this ephemeral
block can be verified to ensure that the node that signed the
block is the same as the node referenced in the block. At this
point, the ephemeral block and its associated BIB are no longer
necessary and can be either removed from the bundle or kept for
historical accounting with the bundle.
Birrane Expires July 1, 2016 [Page 13]
Internet-Draft SECP December 2015
Canonicalized Whole-Bundle Signature:
The signing of an ephemeral block such as the PHN does not
provide a guarantee that the contents of the bundle remained
unchanged across the hop. in the extreme case where the entire
contents of the bundle must be authenticated at every hop in the
bundle, a canonicalized form of the bundle must be generated and
signed by the transmitting node and then check at the next hop
of the bundle.
The most straightforward way to achieve this is to use the BIBE
to encapsulate the entire bundle as the payload of an
encapsulating block, place a BIB on the encapsulating block
payload, and then make the next hop the destination of the
encapsulating block.
4.6.3. Additional Policy Considerations
Applicability:
By global policy or by next-hop, a transmitting node must have
some way of determining that hop-by-hop authentication is
necessary and that either a secure link layer, an ephemeral
block, or some other method is needed to protect the
transmission.
Link Layer Identification:
When using secure link layers, the BPA must have some mechanism
of determining if the link layer selected for transmission has
an appropriate security model.
4.7. Path Verification
4.7.1. Need
A common request in a secured internetwork is to provide a signed
listing of each node traversed by a bundle on its way from sender to
receiver.
4.7.2. Recommended Practice
There are three recommended practices for accomplishing this task:
Per-Hop Extension Blocks, a Signed Log, and an Encrypted Log.
Per-Hop Extension Blocks:
A new extension block can be added to the bundle at each node,
and that new block can be integrity signed by BPSec. In
networks using the Previous Hop Notification (PHN) block, the
PHNs can be signed and kept for each hop.
Birrane Expires July 1, 2016 [Page 14]
Internet-Draft SECP December 2015
Signed Log:
A single extension block can be defined to act as a log book of
visited nodes, such that each node visited by the bundle adds a
new, signed data entry into the log.
Encrypted Log:
This approach works similarly to a Signed Log, except that the
extension block is encrypted with a BCB and only those nodes in
the network with the appropriate keys can decrypt and modify the
log.
4.7.3. Additional Policy Considerations
None.
4.8. Parallel Authenticators/Decrypters
4.8.1. Need
Security in the context of multicasting presents challenging
operational concepts for how to validate a received bundle that
carries multiple integrity signatures. In this case, a bundle should
validate a security service if any one of multiple security data
items is verified.
4.8.2. Recommended Practice
It is recommended that a multi-case cipher suite specification be
defined and used to generate multiple signatures (for integrity) or
multiple ciphertexts (for confidentiality). This approach allows
BPSec to operate without modification, as the cipher suite
implementation both generates and verifies security results.
Multiple signatures would be stored directly in the BIB as part of
cipher suite data. Such cipher suites could verify a signature if
any 1 signature matched, if N of M signatures matched, or if all
signatures match, based on policy.
Multiple encryptors could work by encrypted the plaintext multiple
times to generate multiple ciphertexts which, in total, would replace
the plain text in a specific block in the bundle. Additionally, the
bundle source or other identifying information could be encrypted
once per key and stored as additional authenticated data. On
decryption, a node could determine the appropriate ciphertext to use
by decrypting the bundle source from the additional authenticated
data and then decrypting the ciphertext associated with that key.
Birrane Expires July 1, 2016 [Page 15]
Internet-Draft SECP December 2015
4.8.3. Additional Policy Considerations
Key Lists:
Each node that encrypts, decrypts, or authenticates based on a
multi-cast cipher suite would need to keep a list of each key
used.
4.9. Primary Block Integrity
4.9.1. Need
It may be necessary to ensure that the primary block in a bundle has
not changed since the bundle was first transmitted.
4.9.2. Recommended Practice
The BPSec allows the BIB to target the primary block, just as it can
target any other block in a bundle. As such, this capability can be
accomplished by inserting a BIB in the bundle whose target is the
primary block.
4.9.3. Additional Policy Considerations
None.
4.10. Primary Block Privacy
4.10.1. Need
It may be necessary in certain cases to hide the contents of a
primary block for portions of a bundle journey.
4.10.2. Recommended Practice
There are two recommended practices for accomplishing this task:
Encapsulation and Custom Extension Blocks.
Encapsulation:
The most straightforward way to hide portions of the primary
block is to use BIBE to encapsulate the entire bundle. Then,
the encapsulating block can have whatever primary block
information is necessary to get the bundle through the portions
of the network where the original primary block should be
hidden. In this case, the encapsulated bundle should be
encrypted with a BCB from the encapsulating block.
Custom Extension Block
Birrane Expires July 1, 2016 [Page 16]
Internet-Draft SECP December 2015
A custom extension block may be defined to hold the contents of
the primary block. A temporary primary block can be constructed
at various points in the network as part of processing the
custom extension block. This temporary primary block would have
only that information necessary to get the bundle to some next
known node.
4.10.3. Policy Considerations
While there is no specific policy consideration, the concept of
performing surgery on the primary block of a bundle in transit must
be taken with great care.
5. IANA Considerations
This document has no fields registered by IANA.
6. Informative References
[BIBE] Burleigh, S., "Bundle-in-Bundle Encapsulation", draft-
irtf-burleigh-bibe-00 (work in progress), March 2013.
[BPSec] Birrane, E., Mayer, J., and D. Iannicca, "Bundle Protocol
Security", draft-ietf-dtn-bpsec-00 (work in progress),
December 2015.
[RFC5050] Scott, K. and S. Burleigh, "Bundle Protocol
Specification", RFC 5050, DOI 10.17487/RFC5050, November
2007, <http://www.rfc-editor.org/info/rfc5050>.
Author's Address
Edward J. Birrane
Johns Hopkins Applied Physics Laboratory
Email: Edward.Birrane@jhuapl.edu
Birrane Expires July 1, 2016 [Page 17]
