DTN Research Group S. Symington Internet-Draft The MITRE Corporation Intended status: Experimental February 17, 2009 Expires: August 21, 2009 Delay-Tolerant Networking Metadata Extension Block draft-irtf-dtnrg-bundle-metadata-block-01 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on August 21, 2009. Copyright Notice Copyright (c) 2009 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. Symington Expires August 21, 2009 [Page 1] Internet-Draft DTN Metadata Extension Block February 2009 Abstract This document defines an extension block that may be used with the Bundle Protocol [refs.DTNBP] within the context of a Delay-Tolerant Network architecture [refs.DTNarch]. 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 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 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 6.1. Normative References . . . . . . . . . . . . . . . . . . . 10 6.2. Informative References . . . . . . . . . . . . . . . . . . 10 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11 Symington Expires August 21, 2009 [Page 2] Internet-Draft DTN Metadata Extension Block February 2009 1. Introduction The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [refs.RFC2119]. The DTN bundle protocol [refs.DTNBP] 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, and -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. Symington Expires August 21, 2009 [Page 3] Internet-Draft DTN Metadata Extension Block February 2009 2. Metadata Block Format The Metadata Block uses the Canonical Bundle Block Format as defined in the bundle protocol [refs.DTNBP]. 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 documents. - 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: Symington Expires August 21, 2009 [Page 4] Internet-Draft DTN Metadata Extension Block February 2009 Metadata Block Format: +-----+------+--------------------+------+----------+----------| |Type |Flags |EID Reference count |Len | Ontology | Metadata | | |(SDNV)| and list (opt) |(SDNV)| | | +-----+------+--------------------+------+----------+----------+ Figure 1 Symington Expires August 21, 2009 [Page 5] Internet-Draft DTN Metadata Extension Block February 2009 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). Symington Expires August 21, 2009 [Page 6] Internet-Draft DTN Metadata Extension Block February 2009 4. Security Considerations The DTN Security Overview [refs.DTNsecOver] and the Bundle Security Protocol [refs.DTNBPsec] 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 [refs.DTNBPsec] 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 encryption. 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 Symington Expires August 21, 2009 [Page 7] Internet-Draft DTN Metadata Extension Block February 2009 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. Symington Expires August 21, 2009 [Page 8] Internet-Draft DTN Metadata Extension Block February 2009 5. IANA Considerations 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. Symington Expires August 21, 2009 [Page 9] Internet-Draft DTN Metadata Extension Block February 2009 6. References 6.1. Normative References [refs.RFC2119] Bradner, S. and J. Reynolds, "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, October 1997. [refs.DTNBP] Scott, K. and S. Burleigh, "Bundle Protocol Specification", RFC 5050, November 2007. [refs.DTNBPsec] Symington, S., Farrell, S., and H. Weiss, "Bundle Security Protocol Specification", draft-irtf-dtnrg-bundle-security-06.txt, work-in-progress, November 2008. 6.2. Informative References [refs.DTNarch] 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. [refs.DTNsecOver] Farrell, S., Symington, S., and H. Weiss, "Delay-Tolerant Network Security Overview", draft-irtf-dtnrg-sec-overview-05.txt, work-in-progress, November 2008. Symington Expires August 21, 2009 [Page 10] Internet-Draft DTN Metadata Extension Block February 2009 Author's Address Susan Flynn Symington The MITRE Corporation 7515 Colshire Drive McLean, VA 22102 US Phone: +1 (703) 983-7209 Email: susan@mitre.org URI: http://mitre.org/ Symington Expires August 21, 2009 [Page 11]