[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 09 10 RFC 6258

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

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of 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 March 19, 2009.

Copyright Notice

   Copyright (C) The IETF Trust (2008).














Symington                Expires March 19, 2009                 [Page 1]


Internet-Draft        DTN Metadata Extension Block        September 2008


Abstract

   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.


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
   Intellectual Property and Copyright Statements . . . . . . . . . . 12























Symington                Expires March 19, 2009                 [Page 2]


Internet-Draft        DTN Metadata Extension Block        September 2008


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 [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,
      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 March 19, 2009                 [Page 3]


Internet-Draft        DTN Metadata Extension Block        September 2008


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
         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 March 19, 2009                 [Page 4]


Internet-Draft        DTN Metadata Extension Block        September 2008


   Metadata Block Format:
   +-----+------+--------------------+------+----------+----------|
   |Type |Flags |EID Reference count |Len   | Ontology | Metadata |
   |     |(SDNV)|  and list (opt)    |(SDNV)|          |          |
   +-----+------+--------------------+------+----------+----------+

                                 Figure 1












































Symington                Expires March 19, 2009                 [Page 5]


Internet-Draft        DTN Metadata Extension Block        September 2008


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 March 19, 2009                 [Page 6]


Internet-Draft        DTN Metadata Extension Block        September 2008


4.  Security Considerations

   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
   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 March 19, 2009                 [Page 7]


Internet-Draft        DTN Metadata Extension Block        September 2008


   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 March 19, 2009                 [Page 8]


Internet-Draft        DTN Metadata Extension Block        September 2008


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 March 19, 2009                 [Page 9]


Internet-Draft        DTN Metadata Extension Block        September 2008


6.  References

6.1.  Normative References

   [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",
        RFC 5050, November 2007.

   [3]  Symington, S., Farrell, S., and H. Weiss, "Bundle Security
        Protocol Specification",
        draft-irtf-dtnrg-bundle-security-05.txt, work-in-progress,
        February 2008.

6.2.  Informative References

   [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,
        February 2008.


























Symington                Expires March 19, 2009                [Page 10]


Internet-Draft        DTN Metadata Extension Block        September 2008


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 March 19, 2009                [Page 11]


Internet-Draft        DTN Metadata Extension Block        September 2008


Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Symington                Expires March 19, 2009                [Page 12]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/