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

Versions: 00

Delay-Tolerant Networking Working Group                     S. Burleigh
Internet Draft                          JPL, Calif. Inst. Of Technology
Intended status: Standards Track                          June 22, 2017
Expires: December 2017


                      Bundle-in-Bundle Encapsulation
                     draft-burleigh-dtn-bibect-00.txt


Status of this Memo

   This Internet-Draft is submitted 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 24, 2017.

Copyright Notice

   Copyright (c) 2017 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 Simplified BSD License.




Burleigh                Expires December 2017                  [Page 1]


Internet-Draft      Bundle-in-Bundle Encapsulation            June 2017


Abstract

   This document describes Bundle-in-Bundle Encapsulation (BIBE), a
   Delay-Tolerant Networking (DTN) Bundle Protocol (BP) "convergence
   layer" protocol that tunnels BP "bundles" through encapsulating
   bundles.  The services provided by the BIBE convergence-layer
   protocol adapter encapsulate an outbound BP "bundle" in a BIBE
   convergence-layer protocol data unit for transmission as the payload
   of a bundle.  Security measures applied to the encapsulating bundle
   may augment those applied to the encapsulated bundle.  The protocol
   includes a mechanism for recovery from loss of an encapsulating
   bundle, called "custody transfer".  This mechanism is adapted from
   the custody transfer procedures described in the experimental Bundle
   Protocol specification developed by the Delay-Tolerant Networking
   Research group of the Internet Research Task Force and documented in
   RFC 5050.

Table of Contents


   1. Introduction...................................................2
   2. Conventions used in this document..............................4
   3. BIBE Design Elements...........................................4
      3.1. BIBE Endpoints............................................4
      3.2. BIBE Protocol Data Units..................................4
      3.3. Custody Signals...........................................5
      3.4. Custody Transfer Status Reports...........................7
   4. BIBE Procedures................................................7
      4.1. BPDU Transmission.........................................7
      4.2. BPDU Reception............................................8
      4.3. Retransmission Timer Expiration...........................9
      4.4. Custody Signal Reception.................................10
   5. Security Considerations.......................................10
   6. IANA Considerations...........................................10
   7. Acknowledgments.....................Error! Bookmark not defined.
   8. References....................................................10
      8.1. Normative References.....................................10
      8.2. Informative References...................................11
   9. Acknowledgments...............................................11
   Appendix A. For More Information.................................12
   Appendix B. CDDL expression......................................13

1. Introduction

   This document describes Bundle-in-Bundle Encapsulation (BIBE), a
   Delay-Tolerant Networking (DTN) Bundle Protocol (BP) [RFC5050]



Burleigh                Expires December 2017                  [Page 2]


Internet-Draft      Bundle-in-Bundle Encapsulation            June 2017


   "convergence layer" protocol that tunnels BP "bundles" through
   encapsulating bundles.

   Conformance to the bundle-in-bundle encapsulation (BIBE)
   specification is OPTIONAL for BP nodes.  Each BP node that conforms
   to the BIBE specification provides a BIBE convergence-layer adapter
   (CLA) that is implemented within the administrative element of the
   BP node's application agent.  Like any convergence-layer adapter,
   the BIBE CLA provides:

     . A transmission service that sends an outbound bundle (from the
        bundle protocol agent) to a peer CLA.  In the case of BIBE, the
        sending CLA and receiving peer CLA are both BP nodes.
     . A reception service that delivers to the bundle protocol agent
        an inbound bundle that was sent by a peer CLA (itself a BP
        node) via the BIBE convergence layer protocol.

   The BIBE CLA performs these services by:

     . Encapsulating outbound bundles in BIBE protocol data units,
        which take the form of Bundle Protocol administrative records
        as described later.
     . Requesting that the bundle protocol agent transmit bundles
        whose payloads are BIBE protocol data units.
     . Taking delivery of BIBE protocol data units that are the
        payloads of bundles received by the bundle protocol agent.
     . Delivering to the bundle protocol agent the bundles that are
        encapsulated in delivered BIBE protocol data units.

   Bundle-in-bundle encapsulation may have broad utility, but the
   principal motivating use case is the deployment of "cross domain
   solutions" in secure communications.  Under some circumstances a
   bundle may arrive at a node that is on the frontier of a region of
   network topology in which augmented security is required, from which
   the bundle must egress at some other designated node.  In that case,
   the bundle may be encapsulated within a bundle to which the
   requisite additional BP Security (BPSEC) [bpsec] extension block(s)
   can be attached, whose source is the point of entry into the
   insecure region (the "security source") and whose destination is the
   point of egress from the insecure region (the "security
   destination").

   Note that:

     . If the payload of the encapsulating bundle is protected by a
        Bundle Confidentiality Block (BCB), then the source and



Burleigh                Expires December 2017                  [Page 3]


Internet-Draft      Bundle-in-Bundle Encapsulation            June 2017


        destination of the encapsulated bundle are encrypted, providing
        defense against traffic analysis that BPSEC alone cannot offer.
     . Bundles whose payloads are BIBE protocol data units may
        themselves be forwarded via a BIBE convergence-layer adapter,
        enabling nested bundle encapsulation to arbitrary depth as
        required by security policy.
     . Moreover, in the event that no single point of egress from an
        insecure region of network topology can be determined at the
        moment a bundle is to be encapsulated, multiple copies of the
        bundle may be encapsulated individually and forwarded to all
        candidate points of egress.

   The protocol includes a mechanism for recovery from loss of an
   encapsulating bundle, called "custody transfer".  This mechanism is
   adapted from the custody transfer procedures described in the
   experimental Bundle Protocol specification developed by the Delay-
   Tolerant Networking Research group of the Internet Research Task
   Force and documented in RFC 5050.  Custody transfer is a convention
   by which the loss or corruption of BIBE encapsulating bundles can be
   mitigated by the exchange of other bundles, which are termed
   "custody signals".

2. Conventions used in this document

   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 [RFC2119].

   In this document, these words will appear with that interpretation
   only when in ALL CAPS. Lower case uses of these words are not to be
   interpreted as carrying RFC-2119 significance.

3. BIBE Design Elements

3.1. BIBE Endpoints

   BIBE convergence-layer protocol endpoints, also known as BIBE
   convergence-layer adapters (BCLAs), are the Administrative Elements
   of Bundle Protocol nodes that conform to the BIBE protocol
   specification.  The node of which a given BCLA is one component is
   termed the BCLA's "local node".

3.2. BIBE Protocol Data Units

   A BIBE protocol data unit (BPDU) is defined as a Bundle Protocol
   administrative record whose record type code is 7 (i.e., bit pattern
   0111) constructed as follows.


Burleigh                Expires December 2017                  [Page 4]


Internet-Draft      Bundle-in-Bundle Encapsulation            June 2017


   Each BPDU SHALL be represented as a CBOR array. The number of
   elements in the array SHALL be 2.

   The first item of the BPDU array SHALL be a flag indicating whether
   or not Custody Transfer is requested for this BPDU, represented as a
   CBOR Boolean value.

   The second item of the content array SHALL be a single BP bundle,
   termed the "encapsulated bundle", represented as a CBOR byte string.

3.3. Custody Signals

   A "custody signal" is defined as a Bundle Protocol administrative
   record whose record type code is 2 (i.e., bit pattern 0010)
   constructed as follows.

   Each custody signal SHALL be represented as a CBOR array. The number
   of elements in the array SHALL be 6 (if the bundle to which the
   custody signal refers is a fragment) or 4 (otherwise).

   The first item of the custody signal array SHALL be a signal type
   code represented as a CBOR unsigned integer. Valid custody signal
   types are defined as follows:

   +---------+--------------------------------------------+

   | Value   |                  Meaning                   |

   +=========+============================================+

   |    0    | Custody acceptance.  The reporting node    |

   |         | accepted custody of the bundle.            |

   +---------+--------------------------------------------+

   |    1    | Custody refusal.  The reporting node       |

   |         | refused custody of the bundle.             |

   +---------+--------------------------------------------+

   | (other) | Reserved for future use.                   |

   +---------+--------------------------------------------+

                    Figure 1: Custody Signal Type Codes


Burleigh                Expires December 2017                  [Page 5]


Internet-Draft      Bundle-in-Bundle Encapsulation            June 2017


   The second item of the custody signal array SHALL be a custody
   signal reason code, represented as a CBOR unsigned integer. Valid
   custody signal reason codes are defined as follows:

   +---------+--------------------------------------------+

   | Value   |                  Meaning                   |

   +=========+============================================+

   |    0    | No additional information.                 |

   +---------+--------------------------------------------+

   |    1    | Reserved for future use.                   |

   +---------+--------------------------------------------+

   |    2    | Reserved for future use.                   |

   +---------+--------------------------------------------+

   |    3    | Redundant (reception by a node that        |

   |         | already has a copy of this bundle).        |

   +---------+--------------------------------------------+

   |    4    | Depleted storage.                          |

   +---------+--------------------------------------------+

   |    5    | Destination endpoint ID unintelligible.    |

   +---------+--------------------------------------------+

   |    6    | No known route destination from here.      |

   +---------+--------------------------------------------+

   |    7    | No timely contact with next node on route. |

   +---------+--------------------------------------------+

   |    8    | Block unintelligible.                      |

   +---------+--------------------------------------------+


Burleigh                Expires December 2017                  [Page 6]


Internet-Draft      Bundle-in-Bundle Encapsulation            June 2017


   | (other) | Reserved for future use.                   |

   +---------+--------------------------------------------+

                   Figure 2: Custody Signal Reason Codes

   The third item of the custody signal array SHALL be the node ID
   identifying the source of the encapsulated bundle to which the
   custody signal pertains, termed the "subject bundle", represented as
   described in the Bundle Protocol specification, a work in progress.

   The fourth item of the custody signal array SHALL be the creation
   timestamp of the subject bundle, represented as described in
   BPpbis].

   The fifth item of the custody signal array SHALL be present if and
   only if the subject bundle is a fragment.  If present, it SHALL be
   the subject bundle's fragment offset represented as a CBOR unsigned
   integer.

   The sixth item of the custody signal array SHALL be present if and
   only if the subject bundle is a fragment.  If present, it SHALL be
   the length of the subject bundle's payload represented as a CBOR
   unsigned integer.

3.4. Custody Transfer Status Reports

   A "custody transfer status report" is a bundle status report with
   the "reporting node attempted custody transfer" flag set to 1.

4. BIBE Procedures

4.1. BPDU Transmission

   When a BCLA is requested by the bundle protocol agent to send a
   bundle to the peer BCLA(s) included in the BP endpoint identified by
   a specified BP endpoint ID:

     . The BCLA SHALL generate, as defined in Section 6.2 of the
        Bundle Protocol specification (a work in progress), a BPDU for
        which the second item of the content array is the bundle that
        is to be transmitted.  Note that any transmission request
        presented to a BCLA MAY request that the transmission be
        subject to Custody Transfer; if and only if Custody Transfer is
        requested, the first item of the BPDU's content array SHALL be
        the Boolean value True.  The destination of the bundle whose
        payload is the BPDU (termed the "encapsulating bundle") SHALL


Burleigh                Expires December 2017                  [Page 7]


Internet-Draft      Bundle-in-Bundle Encapsulation            June 2017


        be the specified BP endpoint.  Selection of the values of the
        parameters governing the forwarding of the encapsulating
        bundle, other than the destination endpoint ID, is an
        implementation matter.  The parameter values governing the
        forwarding of the BPDU's encapsulated bundle MAY be consulted
        for this purpose.
     . If and only if Custody Transfer is requested:
          o The bundle protocol agent MUST add the retention constraint
             "Custody accepted" to the encapsulated bundle.
          o The BCLA MAY establish a retransmission countdown timer for
             the encapsulated bundle.

   Note that the custody transfer retransmission timer mechanism
   provides a means of recovering from loss of an encapsulating bundle
   as indicated by non-arrival of a responding custody signal.
   Computation of the timeout interval for an encapsulating bundle's
   retransmission timer (i.e., determination of the moment at which a
   responding custody signal is expected) is an implementation matter
   and may be dynamically responsive to changes in connectivity.

4.2. BPDU Reception

   When a BCLA receives a BPDU from the bundle protocol agent (that is,
   upon delivery of the payload of an encapsulating bundle):

     . If and only if Custody Transfer was requested for this BPDU:
          o If the encapsulated bundle has the same source node ID,
             creation timestamp, and (if that bundle is a fragment)
             fragment offset and payload length as another bundle that
             is currently retained at the BCLA's local node, then
             custody transfer redundancy MUST be handled as follows:
               . The BCLA SHALL generate a custody signal of type 1
                  (custody refusal) referencing the encapsulated
                  bundle, destined for the node that was the source of
                  the encapsulating bundle.  The reason code for the
                  custody signal SHALL be "Redundant reception".
               . If the "request reporting of custody transfer
                  attempted" flag in the encapsulating bundle's status
                  report request field is set to 1, and status
                  reporting is enabled, a custody transfer status
                  report with the same reason code SHOULD be generated,
                  destined for the report-to endpoint of the
                  encapsulating bundle.
          o  Otherwise, if the BCLA determines that its local node can
             neither deliver nor forward the encapsulated bundle for
             any of the reasons listed in Figure 2, then custody



Burleigh                Expires December 2017                  [Page 8]


Internet-Draft      Bundle-in-Bundle Encapsulation            June 2017


             transfer has failed.  Custody transfer failure SHALL be
             handled as follows:
               . The BCLA SHALL generate a custody signal of type 1
                  (custody refusal) referencing the encapsulated
                  bundle, destined for the node that was the source of
                  the encapsulating bundle.  The reason code for the
                  custody signal SHALL be the reason code from Figure 2
                  that indicates the reason for the custody transfer
                  failure.
               . If the "request reporting of custody transfer
                  attempted" flag in the encapsulating bundle's status
                  report request field is set to 1, and status
                  reporting is enabled, a custody transfer status
                  report with the same reason code SHOULD be generated,
                  destined for the report-to endpoint of the
                  encapsulating bundle.
     . Otherwise:
          o The encapsulated bundle SHALL be delivered from the
             convergence layer adapter to the bundle protocol agent,
             whereupon bundle reception SHALL be performed as defined
             in section 5.6 of the Bundle Protocol specification (a
             work in progress) as usual: the encapsulated bundle may be
             forwarded, delivered, etc.
          o If and only if Custody Transfer was requested for this
             BPDU:
               . The BCLA SHALL generate a custody signal of type 0
                  (custody acceptance) referencing the encapsulated
                  bundle, destined for the node that was the source of
                  the encapsulating bundle.
               . If the "request reporting of custody transfer
                  attempted" flag in the bundle's status report request
                  field is set to 1, and status reporting is enabled, a
                  custody transfer status report with reason code 0
                  SHOULD be generated, destined for the report-to
                  endpoint of the encapsulating bundle.

4.3. Retransmission Timer Expiration

   Upon expiration of a retransmission countdown timer, the BCLA SHOULD
   destroy the retransmission timer, request that the BPDU be re-
   forwarded (possibly on a different route), and possibly establish a
   new retransmission timer.







Burleigh                Expires December 2017                  [Page 9]


Internet-Draft      Bundle-in-Bundle Encapsulation            June 2017


4.4. Custody Signal Reception

   When a BCLA receives a custody signal from the bundle protocol agent
   (that is, upon delivery of the payload of a custody-signal-bearing
   bundle):

     . If the custody signal type is 0 (custody acceptance):
          o Any retransmission timer established for the referenced
             encapsulated bundle SHOULD be destroyed.
          o The bundle protocol agent MUST remove the retention
             constraint "Custody accepted" on the referenced
             encapsulated bundle.
     . Otherwise (custody refusal):
          o  Any retransmission timer established for the referenced
             encapsulated bundle SHOULD be destroyed.
          o The action taken by the BCLA is implementation-specific and
             may depend on the reason code cited for the refusal. For
             example, if the custody signal's reason code was "Depleted
             storage", the BCLA might choose to request that the BPDU
             be re-forwarded (possibly on a different route) and
             possibly establish a new retransmission timer. If the
             reason code was "Redundant reception", on the other hand,
             this might cause the BCLA to instruct the bundle protocol
             agent to remove the retention constraint "Custody
             accepted" on the referenced encapsulated bundle and to
             revise its algorithm for computing countdown intervals for
             retransmission timers.

5. Security Considerations

   The BIBE specification introduces no new security considerations.

6. IANA Considerations

   The BIBE specification requires IANA registration of the new BIBE
   administrative record (type code 7) defined above.

7. References

7.1. Normative References

   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
   Requirement Levels", BCP 14, RFC 2119, March 1997.






Burleigh                Expires December 2017                 [Page 10]


Internet-Draft      Bundle-in-Bundle Encapsulation            June 2017


7.2. Informative References

   [RFC5050] Scott, M. and S. Burleigh, "Bundle Protocol
   Specification", RFC 5050, November 2007.

8. Acknowledgments

   This work is freely adapted from [RFC5050], which was an effort of
   the Delay Tolerant Networking Research Group. The following DTNRG
   participants contributed significant technical material and/or
   inputs to that document: Dr. Vinton Cerf of Google, Scott Burleigh,
   Adrian Hooke, and Leigh Torgerson of the Jet Propulsion Laboratory,
   Michael Demmer of the University of California at Berkeley, Robert
   Durst, Keith Scott, and Susan Symington of The MITRE Corporation,
   Kevin Fall of Carnegie Mellon University, Stephen Farrell of Trinity
   College Dublin, Peter Lovell of SPARTA, Inc., Manikantan Ramadas of
   Ohio University, and Howard Weiss of SPARTA, Inc.

   Although the BIBE specification diverges in some ways from the
   original Bundle-in-Bundle Encapsulation Internet Draft authored by
   usan Symington, Bob Durst, and Keith Scott of The MITRE Corporation
   (draft-irtf-dtnrg-bundle-encapsulation-06, 2009), the influence of
   that earlier document is gratefully acknowledged.

   This document was prepared using 2-Word-v2.0.template.dot.
























Burleigh                Expires December 2017                 [Page 11]


Internet-Draft      Bundle-in-Bundle Encapsulation            June 2017


Appendix A.                 For More Information

   Please refer comments to dtn@ietf.org. The Delay Tolerant Networking
   Research Group (DTNRG) Web site is located at http://www.dtnrg.org.

   Copyright (c) 2017 IETF Trust and the persons identified as authors
   of the code. All rights reserved.

   Redistribution and use in source and binary forms, with or without
   modification, is permitted pursuant to, and subject to the license
   terms contained in, the Simplified BSD License set forth in Section
   4.c of the IETF Trust's Legal Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info).




































Burleigh                Expires December 2017                 [Page 12]


Internet-Draft      Bundle-in-Bundle Encapsulation            June 2017


Appendix B.                  CDDL expression

   For informational purposes, Carsten Bormann has kindly provided an
   expression of the Bundle Protocol specification in the CBOR Data
   Definition Language (CDDL).  Portions of CDDL expression that bear
   on the custody transfer extension are presented below, somewhat
   edited by the authors.  Note that wherever the CDDL expression is in
   disagreement with the textual representation of the BP specification
   presented in the earlier sections of this document, the textual
   representation rules.

   bundleflagbits /= &(

     custody-transfer-status-reports-are-requested: 9

     custody-transfer-is-requested: 3)

   extension-block-choice /= current-custodian-block

   current-custodian-block = [5, canonical-block-common, eid]

   admin-record-choice /= custody-signal

   custody-signal = [2, [custody-signal-type-code: uint,

                         custody-signal-information,

                         admin-common]]

   custody-signal-information = custody-reason-code: uint / delegation-
   information

   delegation-information = (

                   next-hop-node: eid,

                   seconds-until-forwarding: uint)

Authors' Address

   Scott Burleigh
   Jet Propulsion Laboratory, California Institute of Technology
   4800 Oak Grove Dr.
   Pasadena, CA 91109-8099
   US
   Phone: +1 818 393 3353
   Email: Scott.Burleigh@jpl.nasa.gov


Burleigh                Expires December 2017                 [Page 13]


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