[Search] [txt|pdfized|bibtex] [Tracker] [WG] [Email] [Nits]
Versions: 00 01 02 03 04 05 06 07 08 09 10 rfc6258
DTN Research Group                                          S. Symington
Internet-Draft                                     The MITRE Corporation
Intended status: Experimental                         September 15, 2008
Expires: March 19, 2009
Delay-Tolerant Networking Metadata Extension Block
draft-irtf-dtnrg-bundle-metadata-block-00
aware will be disclosed, in accordance with Section 6 of BCP 79.
This Internet-Draft will expire on March 19, 2009.
Symington                Expires March 19, 2009                 [Page 1]
Internet-Draft        DTN Metadata Extension Block        September 2008
This document defines an extension block that may be used with the
Bundle Protocol [2] within the context of a Delay-Tolerant Network
architecture [4].  This Metadata Extension Block is designed to be
used to carry metadata that forwarding nodes can use to make routing
and other decisions regarding the bundle.  This block is defined to
enable the actual metadata that is inserted into the block to have
any content and format, providing the format has been documented as a
metadata ontology.  Specific metadata ontologies may be defined in
additional documents.
2.  Metadata Block Format  . . . . . . . . . . . . . . . . . . . .  4
3.  Metadata Block Processing  . . . . . . . . . . . . . . . . . .  6
3.1.  Bundle Transmission  . . . . . . . . . . . . . . . . . . .  6
3.2.  Bundle Forwarding  . . . . . . . . . . . . . . . . . . . .  6
3.3.  Bundle Reception . . . . . . . . . . . . . . . . . . . . .  6
4.  Security Considerations  . . . . . . . . . . . . . . . . . . .  7
5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  9
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11
document are to be interpreted as described in RFC 2119 [1].
The DTN bundle protocol [2] defines the bundle as its protocol data
unit.  A bundle consists of a primary bundle block, which is defined
in the Bundle Protocol, followed by at least one other type of bundle
block.  The Bundle Protocol defines a single other type of bundle
block, called a Bundle Payload block.  This document defines an
additional, optional, bundle block called a Metadata Block.  This
block is designed to be used to carry metadata that is associated
with the bundle so that forwarding nodes can use this metadata to
make routing and other decisions regarding the bundle.
The actual metadata to be inserted into the block may have any
content and format, providing the content and format have been
defined and documented as part of an ontology in order to enable the
metadata to be interpreted.  In this document we define the general
format of and the processing required to support the Metadata Block.
Separate documents will define specific metadata ontologies that are
expected to consist of various record format types.
The capabilities described in this document are OPTIONAL for
deployment with the Bundle Protocol.  Bundle Protocol implementations
claiming to support the Metadata Block MUST be capable of:
-Generating a Metadata Block and inserting it into a bundle,
-Receiving bundles containing a Metadata Block and making the
information contained in this Metadata Block's ontology-specific
metadata field available for use, e.g., in forwarding decisions,
-Modifying the ontology-specific metadata in a received metadata
block and forwarding the modified block with the bundle
as defined in this document.
Bundle Protocol implementations claiming to support a specific
metadata ontology must both support the metadata block as defined
above and be capable of parsing and processing the metadata itself
according to the specific ontology in which the metadata is
expressed.
2.  Metadata Block Format
The Metadata Block uses the Canonical Bundle Block Format as defined
in the bundle protocol [2].  That is, it is comprised of the
following elements:
-Block-type code (1 byte) - defined as in all bundle protocol
blocks except the primary bundle block (as described in the Bundle
Protocol).  The block type code for the Metadata Block is 0x08.
-Block processing control flags (SDNV) - defined as in all bundle
protocol blocks except the primary bundle block.  SDNV encoding is
described in the Bundle Protocol.  There are no constraints on the
use of the Block Processing Control Flags.
-EID references (optional) - composite field defined in the bundle
protocol that is present if and only if the metadata block
references EID elements in the primary block's dictionary.
Presence of this field is indicated by the setting of the "Block
contains an EID-reference field" bit of the block processing
control flags.  If EIDs are referenced in the metadata block, then
their interpretation is defined by the particular ontology that is
being used in this metadata block, as indicated in the metadata
ontology field.
-Block data length (SDNV) - defined as in all bundle protocol
blocks except the primary bundle block.  SDNV encoding is
described in the bundle protocol.
-Block-type-specific data fields as follows:
- Metadata Ontology field (SDNV) - indicates which ontology is
to be used to interpret both the metadata in the metadata field
and the EID references in the optional EID references field (if
present).  Specific ontologies are defined in separate
- Metadata field - contains the metadata itself, formatted
according to the metadata ontology that has been specified for
this block.
The Structure of a Metadata Block is as follows:
Metadata Block Format:
+-----+------+--------------------+------+----------+----------|
|Type |Flags |EID Reference count |Len   | Ontology | Metadata |
|     |(SDNV)|  and list (opt)    |(SDNV)|          |          |
+-----+------+--------------------+------+----------+----------+
3.  Metadata Block Processing
The following are the processing steps that a bundle node must take
relative to generation, reception, and processing of Metadata Blocks.
3.1.  Bundle Transmission
When an outbound bundle is created per the parameters of the bundle
transmission request, this bundle MAY (as influenced by local policy)
include one or more Metadata Blocks (as defined in this
specification).
3.2.  Bundle Forwarding
The node MAY insert one or more Metadata Blocks into the bundle
before forwarding it, as dictated by local policy.  The node MAY
modify the ontology-specific metadata in a received bundle before
forwarding the modified bundle, as dictated by local policy.
3.3.  Bundle Reception
If the bundle includes one or more Metadata Blocks, the metadata
information records in these blocks SHALL be made available for use
at this node (e.g., in forwarding decisions).
The DTN Security Overview [5] and the Bundle Security Protocol [3]
define three security-related blocks to provide hop-by-hop
authentication, end-to-end authentication, and end-to-end
confidentiality of bundles or parts of bundles, as well as a set of
mandatory ciphersuites that may be used to calculate security results
carried in these security blocks.  All ciphersuites that use the
strict canonicalisation algorithm [3] to calculate and verify
security results (e.g., many hop-by-hop authentication ciphersuites)
apply to all blocks in the bundle, and so would apply to bundles that
include an optional Metadata Block and would include that block in
the calculation of their security result.  In particular, bundles
including the optional Metadata Block would be protected in their
entirety for the duration of a single hop, from a forwarding node to
an adjacent receiving node (but not from source to destination),
using the mandatory BAH-HMAC ciphersuite defined in the Bundle
Security Protocol.  Ciphersuites that use the mutable
canonicalisation algorithm to calculate and verify security results
(e.g., the mandatory PSH-RSA-SHA256 ciphersuite and most end-to-end
authentication ciphersuites) will omit the Metadata Block from their
calculation.  The fact that one or more records in the metadata block
may be modified as the bundle transits the network will not interfere
with end-to-end security protection when using ciphersuites that use
mutable canonicalisation.  Lastly, the Metadata Block will not be
encrypted by the mandatory CH-RSA-AES-PAYLOAD-PSH end-to-end
confidentiality ciphersuite, which only allows for payload and PSH
In order to provide the metadata block with confidentiality and
authentication independent of any confidentiality/authentication that
is provided for the payload or other parts of the bundle, new
ciphersuites would need to be defined for this purpose.  In
particular, in order to provide confidentiality for the Metadata
Block in isolation from the rest of the bundle, a new end-to-end
confidentiality ciphersuite for use with the Confidentiality Block
(CB) that encrypts the metadata block and places the encrypted
metadata block in the security result field of the CB would need to
be defined.  In order to provide authentication for the Metadata
Block in isolation from the rest of the bundle, a similar end-to-end
authentication ciphersuite for use with the Payload Security Block
(PSB) that acts only upon the Metadata Block would need to be
defined.  While the definition of these ciphersuites remains to be
specified in a separate security document, the use of such
ciphersuites has been planned for in the design of the Bundle
Security Protocol.
Given that metadata can be modified by forwarding nodes, it may be
desirable to eventually support the ability to audit changes to the
metadata at the individual record level.  No such capability has been
provided in this specification as currently written.
We may want to consider having IANA establish a register of Bundle
Protocol header types, with the Metadata Extension Block header
identified as type 0x08.  In association with the Metadata Extension
block, we may want IANA to establish a separate register of
ontologies.
[1]  Bradner, S. and J. Reynolds, "Key words for use in RFCs to
Indicate Requirement Levels", RFC 2119, October 1997.
[2]  Scott, K. and S. Burleigh, "Bundle Protocol Specification",
[3]  Symington, S., Farrell, S., and H. Weiss, "Bundle Security
Protocol Specification",
draft-irtf-dtnrg-bundle-security-05.txt, work-in-progress,
[4]  Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst, R.,
Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant Network
Architecture", RFC 4838, April 2007.
[5]  Farrell, S., Symington, S., and H. Weiss, "Delay-Tolerant
Network Security Overview",
draft-irtf-dtnrg-sec-overview-04.txt, work-in-progress,
Symington                Expires March 19, 2009                [Page 10]
Susan Flynn Symington
The MITRE Corporation
7515 Colshire Drive
McLean, VA  22102
Email: susan@mitre.org
URI:   http://mitre.org/
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).