--- 1/draft-ietf-dtn-bibect-01.txt 2019-08-04 14:13:10.406695396 -0700 +++ 2/draft-ietf-dtn-bibect-02.txt 2019-08-04 14:13:10.438696211 -0700 @@ -1,17 +1,17 @@ Delay-Tolerant Networking Working Group S. Burleigh Internet Draft JPL, Calif. Inst. Of Technology -Intended status: Standards Track January 31, 2019 -Expires: August 2019 +Intended status: Standards Track August 4, 2019 +Expires: February 5, 2020 Bundle-in-Bundle Encapsulation - draft-ietf-dtn-bibect-01.txt + draft-ietf-dtn-bibect-02.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. @@ -20,39 +20,37 @@ 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 4, 2019. + This Internet-Draft will expire on February 5, 2020. Copyright Notice Copyright (c) 2019 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. -Internet-Draft Bundle-in-Bundle Encapsulation January 20199 - 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 @@ -82,26 +80,24 @@ 7. References....................................................11 7.1. Normative References.....................................11 7.2. Informative References...................................11 8. Acknowledgments...............................................11 Appendix A. For More Information.................................13 Appendix B. CDDL expression......................................14 1. Introduction This document describes Bundle-in-Bundle Encapsulation (BIBE), a - Delay-Tolerant Networking (DTN) Bundle Protocol (BP) [RFC5050] + Delay-Tolerant Networking (DTN) Bundle Protocol (BP) [BP] "convergence layer" protocol that tunnels BP "bundles" through encapsulating bundles. -Internet-Draft Bundle-in-Bundle Encapsulation January 20199 - 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. @@ -135,40 +131,37 @@ destination"). Note that: . If the payload of the encapsulating bundle is protected by a Bundle Confidentiality Block (BCB), then the source and 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, - -Internet-Draft Bundle-in-Bundle Encapsulation January 20199 - 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". + Force and documented in RFC 5050 [RFC5050]. 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. @@ -179,34 +172,31 @@ 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 Notionally, a BCLA is assumed to implement in some way, for each - neighboring node to which the local node issues BIBE Protocol Data + custodial node to which the local node issues BIBE Protocol Data Units (BPDUs), the following two data resources: 1. A "custodial transmission count" (CTC). A CTC is a monotonically increasing integer indicating the number of "custodial" BPDUs - that is, BPDUs for which custody transfer - -Internet-Draft Bundle-in-Bundle Encapsulation January 20199 - - was requested - that have been issued to the neighboring node - by the local node since instantiation of the local node. + was requested - that have been issued to the custodial node by + the local node since instantiation of the local node. 2. A "custodial transmission database" (CTDB), a notional array of "custodial transmission items" (CTIs). The CTDB contains one - CTI for each custodial BPDU issued to the neighboring node, by + CTI for each custodial BPDU issued to the custodial node, by the local node, for which (a) no custody disposition has yet been received in any custody signal (as discussed later) and (b) the bundle encapsulated in that BPDU has not yet been destroyed due to, e.g., time-to-live expiration. Each CTI notionally contains: a. A reference to the bundle encapsulated in the corresponding BPDU. b. The "transmission ID" of the corresponding BPDU, as discussed below. c. A "retransmission time" indicating the time by which @@ -235,22 +225,20 @@ requested SHALL take the form of a "DTN Time" as defined in the Bundle Protocol specification; determination of the value of retransmission time is an implementation matter that is beyond the scope of this specification and may be dynamically responsive to changes in connectivity. The third item of the BPDU array SHALL be a single BP bundle, termed the "encapsulated bundle", represented as a CBOR byte string of definite length. -Internet-Draft Bundle-in-Bundle Encapsulation January 20199 - 3.3. Custody Signals A "custody signal" is a Bundle Protocol administrative record whose record type code is 4 (i.e., bit pattern 0100) and whose content is constructed as follows. The content of each custody signal SHALL be represented as a CBOR array. The number of elements in the array SHALL be 2. The first item of the custody signal content array SHALL be a @@ -283,23 +271,20 @@ | 4 | Depleted storage. | +---------+--------------------------------------------+ | 5 | Destination endpoint ID unintelligible. | +---------+--------------------------------------------+ | 6 | No known route destination from here. | - -Internet-Draft Bundle-in-Bundle Encapsulation January 20199 - +---------+--------------------------------------------+ | 7 | No timely contact with next node on route. | +---------+--------------------------------------------+ | 8 | Block unintelligible. | +---------+--------------------------------------------+ @@ -329,22 +314,20 @@ of all bundles that were encapsulated in the indicated BPDUs. Otherwise the source of the custody signal has refused custody of all bundles that were encapsulated in the indicated BPDUs, for the indicated reason. 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. -Internet-Draft Bundle-in-Bundle Encapsulation January 20199 - 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 @@ -379,22 +362,20 @@ 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. 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): -Internet-Draft Bundle-in-Bundle Encapsulation January 20199 - . If Custody Transfer was requested for this BPDU (as indicated by a non-zero value of transmission ID): 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 add the BPDU's transmission ID to the disposition scope report of a pending outbound custody signal, destined for the node that was the @@ -428,23 +409,20 @@ 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 whose reason code is the same as the pending outbound custody signal's disposition SHOULD be generated, destined for the report-to endpoint of the encapsulating bundle. . If Custody Transfer was NOT requested for this BPDU, or if Custody Transfer was requested for this BPDU and custody transfer succeeded, then the encapsulated bundle SHALL be - -Internet-Draft Bundle-in-Bundle Encapsulation January 20199 - 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. Note that the manner in which pending outbound custody signals are managed, disposition scope reports are aggregated, and custody signal transmission is initiated is an implementation matter that is beyond the scope of this specification. Note, however, that @@ -478,23 +456,20 @@ (destroying the associated retransmission timer, if any). . Otherwise (custody refusal), for each transmission ID in the custody signal's disposition scope report: o The corresponding CTI MUST be removed from the CTDB (destroying the associated retransmission timer, if any). o Any further 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 notify the bundle protocol agent that custodial transmission of - -Internet-Draft Bundle-in-Bundle Encapsulation January 20199 - the indicated bundle failed. If the reason code was "Redundant reception", on the other hand, this might cause the BCLA simply to instruct the bundle protocol agent to remove the retention constraint "Custody accepted" on the bundle referenced by the corresponding CTI and to revise its algorithm for computing retransmission time. 5. Security Considerations An adversary on a DTN-based network that can delete bundles could @@ -513,75 +488,71 @@ 6. IANA Considerations The BIBE specification requires IANA registration of the new BIBE administrative records (type codes 3 and 4) defined above. 7. References 7.1. Normative References + [BP] Burleigh, S., Fall, K., and E. Birrane, "Bundle Protocol + Version 7", Work In Progress, August 2019. + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 7.2. Informative References [RFC5050] Scott, K. 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, - -Internet-Draft Bundle-in-Bundle Encapsulation January 20199 - 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 and Howard Weiss of SPARTA, Inc., and Manikantan Ramadas of Ohio University. The custody transfer procedures defined in this specification are adapted from the Aggregate Custody Signals draft specification authored in 2010-2012 by Sebastian Kuzminsky and Andrew Jenkins, then of the University of Colorado at Boulder. Although the BIBE specification diverges in some ways from the original Bundle-in-Bundle Encapsulation Internet Draft authored by Susan 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. -Internet-Draft Bundle-in-Bundle Encapsulation January 20199 - 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) 2019 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). -Internet-Draft Bundle-in-Bundle Encapsulation January 20199 - 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.