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

Versions: 00 01 02 03 04 05 06 07 08 09 10 11 12 RFC 6259

DTN Research Group                                          S. Symington
Internet-Draft                                     The MITRE Corporation
Intended status: Experimental                              June 11, 2009
Expires: December 13, 2009


         Delay-Tolerant Networking Previous Hop Insertion Block
             draft-irtf-dtnrg-bundle-previous-hop-block-07

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 December 13, 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 in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.









Symington               Expires December 13, 2009               [Page 1]

Internet-Draft      DTN Previous Hop Insertion Block           June 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 Previous Hop Insertion
   Block is designed to be inserted by a forwarding node to provide the
   endpoint identifier (EID) of an endpoint of which the forwarding node
   is a member so that this EID may be conveyed to the next-hop
   receiving node.  Knowledge of an EID of an endpoint of which a
   previous-hop node is a member may be required in some circumstances
   to support certain routing protocols (e.g., flood routing).  The
   Previous Hop Insertion block is always removed from the bundle by the
   receiving node so that its duration within the bundle lasts for
   exactly one hop.  This document defines the format and processing of
   this Previous Hop Insertion Block.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Previous Hop Insertion Block Format  . . . . . . . . . . . . .  5
   3.  Previous Hop Insertion Block Processing  . . . . . . . . . . .  7
     3.1.  Bundle Transmission  . . . . . . . . . . . . . . . . . . .  7
     3.2.  Bundle Forwarding  . . . . . . . . . . . . . . . . . . . .  7
     3.3.  Bundle Reception . . . . . . . . . . . . . . . . . . . . .  7
   4.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 10
   6.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
     6.1.  Normative References . . . . . . . . . . . . . . . . . . . 11
     6.2.  Informative References . . . . . . . . . . . . . . . . . . 11
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12




















Symington               Expires December 13, 2009               [Page 2]

Internet-Draft      DTN Previous Hop Insertion Block           June 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.  This document defines an optional bundle block
   called a Previous Hop Insertion Block.  This Previous Hop Insertion
   Block is designed to be inserted into a bundle by a forwarding node
   to provide the endpoint ID (EID) of an endpoint of which the
   forwarding node is a member so that this EID may be conveyed to the
   next-hop receiving node.  This previous-hop EID information may be
   required in some circumstances to support various routing protocols
   (e.g., flood routing).  Although there may be some situations in
   which a node that receives a bundle may be able to infer the EID of
   an endpoint of which the node that forwarded the bundle to it is a
   member, there are other situations in which the EID of such an
   endpoint will not be able to be inferred by the receiving node.  In
   these situations, if there is a requirement that the receiving node
   be able to determine the EID of an endpoint of which the forwarding
   node is a member, the forwarding node must provide this information
   in the bundle.  This specification defines a mechanism, i.e. the
   Previous Hop Insertion Block, whereby a node can insert such an EID
   into a bundle before forwarding it.  If the EID of an endpoint of
   which the forwarding node is a member is already in the dictionary
   field of the bundle's Primary Bundle Block, the Previous Hop
   Insertion Block MAY identify this EID using its Block EID reference
   count and EID references field.  Otherwise, the Previous Hop Block
   MUST identify this EID by providing the EID in its block-type-
   specific data field.

   The lifetime of the Previous Hop Insertion Block is always exactly
   one hop in the DTN.  If a bundle containing a Previous Hop Insertion
   Block is received, the receiving node is assured that this block was
   inserted by the previous node, assuming all nodes are operating
   correctly; likewise, this block is not retained with the bundle when
   the bundle is forwarded.  If the bundle is forwarded with a Previous
   Hop Insertion Block, this block must identify the EID of an endpoint
   of which the forwarding node is a member.

   This document defines the format and processing of the Previous Hop
   Insertion Block.  The capabilities described in this document are
   OPTIONAL for deployment with the Bundle Protocol.  Bundle Protocol
   implementations claiming to support Previous Hop Insertion Blocks
   MUST be capable of:




Symington               Expires December 13, 2009               [Page 3]

Internet-Draft      DTN Previous Hop Insertion Block           June 2009


      -Generating a Previous Hop Insertion Block and inserting it into a
      bundle,

      -Receiving bundles containing a Previous Hop Insertion Block and
      making the information contained in this Previous Hop Insertion
      Block available for use, e.g., in forwarding decisions.

      -Deleting a Previous Hop Insertion Block from a bundle

   as defined in this document.









































Symington               Expires December 13, 2009               [Page 4]

Internet-Draft      DTN Previous Hop Insertion Block           June 2009


2.  Previous Hop Insertion Block Format

   The Previous Hop Insertion 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 (one byte) - defined as in all bundle protocol
      blocks except the primary bundle block (as described in
      [refs.DTNBP]).  The block type code for the Previous Hop Insertion
      Block is 0x05.

      -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).  The following block processing
      control flag MUST be set:

         -Discard block if it can't be processed.

      -Block EID reference count and EID references (optional) -
      composite field defined in [refs.DTNBP] containing a count of EID
      references (expressed as an SDNV) followed by an EID reference
      (expressed as a pair of SDNVs).  Whether or not this field may be
      present in the block is determined by whether or not the EID of an
      endpoint of which the node inserting the block is a member is
      already in the Dictionary Field of the Primary Bundle Block (e.g.,
      whether this EID is the EID of the bundle's source, current
      custodian, or report-to endpoint, or of some other endpoint in the
      dictionary that is referenced by another block in the bundle).  If
      the EID of an endpoint of which the inserting node is a member is
      already in the dictionary, this field MAY be present in the block.
      If this field is present in the block, the value of the EID
      reference count MUST be one, meaning that the field contains
      exactly one EID reference, which MUST be a reference to the EID of
      an endpoint of which the inserting node is a member.  Presence of
      this field MUST be indicated by a set "block contains an EID
      reference field" flag in the block processing control flags.  If
      the EID of an endpoint of which the inserting node is a member is
      not in the dictionary, this field MUST NOT be present in the
      block, which MUST be indicated by an unset "block contains an EID
      reference field" flag in the block processing control flags

      -Block data length (SDNV) - defined as in all bundle protocol
      blocks except the primary bundle block.  SDNV encoding is
      described in the Bundle Protocol.  If this value is zero, there
      are no block-type-specific data fields.  In this case, the EID of
      an endpoint of which the inserting node is a member must be in the
      dictionary and it MUST be referenced in the Block EID reference
      count and EID references field as described above.



Symington               Expires December 13, 2009               [Page 5]

Internet-Draft      DTN Previous Hop Insertion Block           June 2009


      -Block-type-specific data fields (optional) as follows:

         -Inserting Node's EID Scheme Name - A null-terminated array of
         bytes that comprises the scheme name of the EID of an endpoint
         of which the node inserting this Previous Hop Insertion Block
         is a member.

         -Inserting Node's EID SSP - A null-terminated array of bytes
         that comprises the scheme-specific part (SSP) of the EID of an
         endpoint of which the node inserting this Previous Hop
         Insertion Block is a member.

      If the Block EID reference count and EID references field is not
      present in the block, the above two EID scheme name and SSP block-
      type-specific data fields MUST be present.  If the Block EID
      reference count and EID references field is present in the block,
      the above two EID scheme name and SSP block-type-specific data
      fields MUST NOT be present.

   The Structure of a Previous Hop Insertion Block is as follows:

   Previous Hop Insertion Block Format:
   +----+------------+--------------------------------- -+-------------+
   |type|flags (SDNV)|EID ref count and list (comp) (opt)|length (SDNV)|
   +----+------------+-----------------------------------+-------------+
   | Inserting Node EID Scheme Name (opt)| Inserting Node EID SSP (opt)|
   +-------------------------------------------------------------------+

                                 Figure 1






















Symington               Expires December 13, 2009               [Page 6]

Internet-Draft      DTN Previous Hop Insertion Block           June 2009


3.  Previous Hop Insertion Block Processing

   The following are the processing steps that a bundle node must take
   relative to generation, reception, and processing of Previous Hop
   Insertion 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 a Previous Hop Insertion Block (as defined in this
   specification).

3.2.  Bundle Forwarding

   Before forwarding a bundle, the node SHALL delete the Previous Hop
   Insertion Block that was in the bundle when it was received (if any).
   As described in the Bundle Protocol, the node MAY delete all strings
   (scheme names and scheme-specific parts--SSPs) in the bundle's
   dictionary to which no endpoint ID references in the bundle currently
   refer (if any).

   The node MAY insert a Previous Hop Insertion Block into the bundle
   before forwarding it, as dictated by local policy.  If there are
   already strings (scheme names and SSPs) in the bundle's dictionary
   that denote the EID of an endpoint of which the inserting node is a
   member, the Previous Hop Insertion Block MAY reference these strings
   and, if it does, it MUST NOT include any block-type-specific data
   fields.  The inserting node MUST NOT insert strings into the bundle's
   dictionary in order that they may be referenced by only the Previous
   Hop Insertion Block.  If the Previous Hop Insertion Block is
   constructed such that it does not reference any strings from the
   dictionary, the inserting node MUST include the scheme name and SSP
   of an EID of an endpoint of which it is a member as the block's
   block-type-specific data fields.

3.3.  Bundle Reception

   If the bundle includes a Previous Hop Insertion Block, the EID
   identified in this block SHALL be made available for use at this node
   (e.g., in forwarding decisions).  If the EID is identified both by a
   reference in the block's Block EID reference count and EID references
   field and by a scheme name and SSP in the block-type-specific fields,
   the block is not considered to be well-formed.  In the case of
   reception of such an ill-formed block, if the identified EIDs are the
   same, the receiving node MAY process the block as if it were well-
   formed.  However, if the identified EIDs differ, the receiving node
   MUST NOT process the block and must take action on the block as



Symington               Expires December 13, 2009               [Page 7]

Internet-Draft      DTN Previous Hop Insertion Block           June 2009


   specified by the block's Block Processing Control Flags.


















































Symington               Expires December 13, 2009               [Page 8]

Internet-Draft      DTN Previous Hop Insertion Block           June 2009


4.  Security Considerations

   The DTN Bundle Security Protocol [refs.DTNBPsec] defines 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 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
   Previous Hop Insertion Block and would include that block in the
   calculation of their security result.  In particular, bundles
   including the optional Previous Hop Insertion Block would be
   protected in their entirety for the duration of a single hop, from a
   forwarding node to an adjacent receiving node, using the BAB-HMAC
   ciphersuite defined in the Bundle Security Protocol.  Ciphersuites
   that use the mutable canonicalisation algorithm to calculate and
   verify security results (e.g., the PIB-RSA-SHA256 ciphersuite and
   most end-to-end authentication ciphersuites) will (correctly) omit
   the Previous Hop Insertion Block from their calculation.  The fact
   that several different instantiations of this block may be added to
   and deleted from the bundle as the bundle transits the network will
   not interfere with end-to-end security protection when using
   ciphersuites that use mutable canonicalisation.  Lastly, the Previous
   Hop Insertion Block will not be encrypted by the PCB-RSA-AES128-
   PAYLOAD-PIB-PCB end-to-end confidentiality ciphersuite, which only
   allows for payload and PSH encryption.  If encryption of this block
   is desired, the Extension Security Block (ESB) could be used for this
   purpose.

   Nodes receiving bundles with Previous Hop Insertion Blocks should be
   aware that forwarding nodes that insert Previous Hop Insertion Blocks
   might lie about the EIDs of endpoints of which they are members.
   Lying in this way could provide a mechanism for subverting routing
   strategies that base routing decisions on EID information in the
   Previous Hop Insertion Block.

   Note that if some Bundle Protocol implementation does not support the
   Previous Hop Insertion Block but does not properly implement the
   "Discard block if it can't be processed" flag, then a Previous Hop
   Insertion Block may unexpectedly persist for longer than a single
   hop.








Symington               Expires December 13, 2009               [Page 9]

Internet-Draft      DTN Previous Hop Insertion Block           June 2009


5.  IANA Considerations

   If the bundle protocol becomes a standards track protocol, then we
   may want to consider having IANA establish a register of block types,
   of which the Previous Hop Insertion Block would be one.














































Symington               Expires December 13, 2009              [Page 10]

Internet-Draft      DTN Previous Hop Insertion Block           June 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., Weiss, H., and P. Lovell,
              "Bundle Security Protocol Specification",
              draft-irtf-dtnrg-bundle-security-08.txt, work-in-progress,
              March 2009.

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.



























Symington               Expires December 13, 2009              [Page 11]

Internet-Draft      DTN Previous Hop Insertion Block           June 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 December 13, 2009              [Page 12]


Html markup produced by rfcmarkup 1.108, available from http://tools.ietf.org/tools/rfcmarkup/