[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                          November 12, 2009
Expires: May 16, 2010


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

Abstract

   This document defines an extension block that may be used with the
   DTN Bundle Protocol.  This Previous Hop Insertion Block (PHIB)
   extension 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).  If this
   EID cannot be provided by the convergence layer or other means, the
   PHIB defines the mechanism whereby the EID can be provided with the
   bundle.  Each PHIB is always removed from the bundle by the receiving
   node so that its presence within the bundle is limited to exactly one
   hop.  This document defines the format and processing of this PHIB.
   This document is a product of the Delay Tolerant Networking Research
   Group and has been reviewed by that group.  No objections to its
   publication as an RFC were raised."

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.



Symington                 Expires May 16, 2010                  [Page 1]

Internet-Draft      DTN Previous Hop Insertion Block       November 2009


   This Internet-Draft will expire on May 16, 2010.

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.  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 BSD License.



































Symington                 Expires May 16, 2010                  [Page 2]

Internet-Draft      DTN Previous Hop Insertion Block       November 2009


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 . . . . . . . . . . . . . . . . . . . . .  8
   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 May 16, 2010                  [Page 3]

Internet-Draft      DTN Previous Hop Insertion Block       November 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].

   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].  The DTN Bundle Protocol defines
   the bundle as its protocol data unit.  This document defines an
   optional bundle block called a Previous Hop Insertion Block (PHIB).
   This PHIB 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
   used in some circumstances to support various routing protocols.  For
   example, the PHIB could be helpful when implementing flood routing
   because each receiving node could use the PHIB to determine which EID
   to exclude from the list of adjacent nodes to which it forwards
   received bundles as it does its part in flooding the bundle.  A node
   will flood the bundle to all neighboring nodes except for the node
   from which it received the bundle, as identified in the PHIB.

   In many situations, 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 may be some situations, however, in
   which the EID of such an endpoint will not be able to be inferred by
   the receiving node.  For example, if tunneling DTN bundles across
   some portion of the DTN network, it is not possible for the node at
   the receiving end of the tunnel to determine from the convergence
   layer the EID of the node at the sending end of the tunnel.  The node
   at the receiving end of the tunnel will receive an encapsulating
   bundle from one of its adjacent nodes and it may be able to tell the
   EID of this adjacent node using the convergence layer protocol.
   However, the node at the sending end of the tunnel is most likely not
   adjacent to the node at the receiving end of the tunnel, and so in
   order for the node at the receiving end of the tunnel to be able to
   learn the EID of the node at the sending end of the tunnel, which is
   the previous hop node of the tunneled bundle, the EID must be
   provided within the tunneled bundle.  The PHIB would be a vehicle for
   enabling the node at the sending end of the tunnel to provide its EID
   to the node at the receiving end of the tunnel.  In situations in
   which the EID of the forwarding endpoint cannot be inferred by the
   receiving node, 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 PHIB,



Symington                 Expires May 16, 2010                  [Page 4]

Internet-Draft      DTN Previous Hop Insertion Block       November 2009


   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 PHIB MAY identify this EID using its Block EID
   reference count and EID references field.  Otherwise, the PHIB MUST
   identify this EID by providing the EID in its block-type-specific
   data field.

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

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

      -Generating a PHIB and inserting it into a bundle,

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

      -Deleting a PHIB from a bundle

   as defined in this document.





















Symington                 Expires May 16, 2010                  [Page 5]

Internet-Draft      DTN Previous Hop Insertion Block       November 2009


2.  Previous Hop Insertion Block Format

   The PHIB 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 PHIB 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 PHIB is determined by whether or not the EID of an
      endpoint of which the node inserting the PHIB 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 PHIB.
      If this field is present in the PHIB, 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 PHIB,
      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 May 16, 2010                  [Page 6]

Internet-Draft      DTN Previous Hop Insertion Block       November 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 PHIB 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 PHIB is a member.

      If the Block EID reference count and EID references field is not
      present in the PHIB, 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 PHIB,
      the above two EID scheme name and SSP block-type-specific data
      fields MUST NOT be present.

   The Structure of a PHIB is as follows:

   PHIB 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 May 16, 2010                  [Page 7]

Internet-Draft      DTN Previous Hop Insertion Block       November 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 a PHIB.

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 PHIBs (as defined in this specification).  (PHIB
   insertion is controlled via a bundle agent configuration option.)

3.2.  Bundle Forwarding

   Before forwarding a bundle, the node SHALL delete all PHIBs that were
   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 one or more PHIBs 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 PHIB 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 PHIB.  If the PHIB 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 PHIB's block-type-specific
   data fields.

   The node that is inserting a PHIB into the bundle may have more than
   one endpoint in which it is a member.  In this case, the choice of
   which EID to insert into the PIB SHALL be made as follows:

      - If the inserting node is a member of exactly one singleton
      endpoint, at most one PHIB may be inserted into the bundle and the
      EID of this singleton endpoint is what MUST be inserted into the
      PHIB.

      - If the inserting node is a member of more than one singleton
      endpoint, the EID of the singleton endpoint that is expressed in
      the same URI scheme as the destination of the bundle being
      forwarded is what must be inserted into the PHIB.  If there is
      only one such singleton endpoint expressed in this URI scheme, at
      most one PHIB may be inserted into the bundle and the EID of this



Symington                 Expires May 16, 2010                  [Page 8]

Internet-Draft      DTN Previous Hop Insertion Block       November 2009


      singleton endpoint is what MUST be inserted into the PHIB.

      - If the inserting node is a member of more than one singleton
      endpoint that is expressed in the same URI scheme as the
      destination of the bundle that is being forwarded, the node may
      insert a PHIB into the bundle and the EID of one of these
      singleton EIDs it what MUST be inserted into the PHIB.  The node
      MAY also insert additional PHIBs into the bundle, each of which
      MUST contain a unique one of the node's additional singleton EIDs
      as expressed in this URI scheme.

3.3.  Bundle Reception

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
























Symington                 Expires May 16, 2010                  [Page 9]

Internet-Draft      DTN Previous Hop Insertion Block       November 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 PHIB
   and would include that block in the calculation of their security
   result.  In particular, bundles including the optional PHIB would be
   protected in their entirety for the extent 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 PHIB 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 PHIB 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 PHIBs should be aware that forwarding
   nodes that insert PHIBs 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 PHIB.

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












Symington                 Expires May 16, 2010                 [Page 10]

Internet-Draft      DTN Previous Hop Insertion Block       November 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 PHIB would be one.  The block type code being suggested
   for the PHIB is 0x05.













































Symington                 Expires May 16, 2010                 [Page 11]

Internet-Draft      DTN Previous Hop Insertion Block       November 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 May 16, 2010                 [Page 12]

Internet-Draft      DTN Previous Hop Insertion Block       November 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 May 16, 2010                 [Page 13]


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