--- 1/draft-ietf-dtn-bibect-02.txt 2020-02-18 13:13:17.790102455 -0800 +++ 2/draft-ietf-dtn-bibect-03.txt 2020-02-18 13:13:17.822103276 -0800 @@ -1,17 +1,17 @@ Delay-Tolerant Networking Working Group S. Burleigh Internet Draft JPL, Calif. Inst. Of Technology -Intended status: Standards Track August 4, 2019 -Expires: February 5, 2020 +Intended status: Standards Track February 18, 2020 +Expires: August 21, 2020 Bundle-in-Bundle Encapsulation - draft-ietf-dtn-bibect-02.txt + draft-ietf-dtn-bibect-03.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,25 +20,25 @@ 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 February 5, 2020. + This Internet-Draft will expire on August 21, 2020. Copyright Notice - Copyright (c) 2019 IETF Trust and the persons identified as the + Copyright (c) 2020 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 @@ -51,59 +51,59 @@ 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 + 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...........................................6 - 3.4. Custody Transfer Status Reports...........................7 + 3.4. Custody Transfer Status Reports...........................8 4. BIBE Procedures................................................8 4.1. BPDU Transmission.........................................8 - 4.2. BPDU Reception............................................8 + 4.2. BPDU Reception............................................9 4.3. Retransmission Timer Expiration..........................10 4.4. Custody Signal Reception.................................10 5. Security Considerations.......................................11 6. IANA Considerations...........................................11 7. References....................................................11 7.1. Normative References.....................................11 - 7.2. Informative References...................................11 - 8. Acknowledgments...............................................11 + 7.2. Informative References...................................12 + 8. Acknowledgments...............................................12 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) [BP] "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: + (CLA) that is implemented by 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: @@ -143,79 +143,84 @@ . 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 + Tolerant Networking Research Group of the Internet Research Task 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. 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". + convergence-layer adapters (BCLAs), are implemented by the + administrative elements of the application agents of BP 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". A BP + node that includes a BCLA is termed a "BIBE node". 3.2. BIBE Protocol Data Units + A BIBE Protocol Data Unit (BPDU) for which custody transfer is + requested is termed a "custodial BPDU". + Notionally, a BCLA is assumed to implement in some way, for each - custodial node to which the local node issues BIBE Protocol Data - Units (BPDUs), the following two data resources: + BIBE node to which the local node issues custodial 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 - was requested - that have been issued to the custodial node by - the local node since instantiation of the local node. + custodial BPDUs that have been issued to this BIBE 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 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: + CTI for each custodial BPDU issued to this BIBE 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 custody disposition for the corresponding BDPU is expected. A BIBE protocol data unit is a Bundle Protocol administrative record - whose record type code is 3 (i.e., bit pattern 0011), constructed as - follows. + whose record type code is 3 (i.e., bit pattern 0011) and whose + representation conforms to the Bundle Protocol specification for + administrative record representation. The content of the record + SHALL be a BPDU message represented as follows. - Each BPDU SHALL be represented as a CBOR array. The number of - elements in the array SHALL be 3. + Each BPDU message SHALL be represented as a CBOR array. The number + of elements in the array SHALL be 3. The first item of the BPDU array SHALL be the "transmission ID" for the BPDU, represented as a CBOR unsigned integer. The transmission ID for a BPDU for which custody transfer is NOT requested SHALL be zero. The transmission ID for a BPDU for which custody transfer IS requested SHALL be the current value of the local node's custodial transmission count, plus 1. The second item of the BPDU array SHALL be the BPDU's retransmission time (i.e., the time by which custody disposition for this BPDU is @@ -228,25 +233,27 @@ 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. 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. + record type code is 4 (i.e., bit pattern 0100) and whose + representation conforms to the Bundle Protocol specification for + administrative record representation. The content of the record + shall be a Custody message represented 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. + Each custody message 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 disposition code represented as a CBOR unsigned integer. Valid disposition codes are defined as follows: +---------+--------------------------------------------+ | Value | Meaning | +=========+============================================+ @@ -288,84 +295,91 @@ +---------+--------------------------------------------+ | (other) | Reserved for future use. | +---------+--------------------------------------------+ Figure 1: Disposition Codes The second item of the custody signal content array SHALL be a - "disposition scope report", represented as a CBOR indefinite-length - array. Each item of the disposition scope report array SHALL be a + "disposition scope report", represented as a CBOR array of definite + length. Each item of the disposition scope report array SHALL be a "disposition scope sequence", represented as a CBOR array of two elements. The first element of each disposition scope sequence array SHALL be the first transmission ID in a sequence of 1 or more consecutive transmission IDs corresponding to BPDUs to which the custody signal's disposition is declared to apply; the second element of each disposition scope sequence array SHALL be the number of transmission IDs in that sequence. Both are represented as CBOR unsigned integers. A custody signal constitutes an assertion by the source of that - administrative bundle that the indicated disposition code applies to + administrative record that the indicated disposition code applies to all BPDUs identified by the transmission IDs enumerated in the custody signal's disposition scope report. If the disposition code is zero, then the source of the custody signal has accepted custody 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. 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: + bundle to the peer BCLA(s) included in the destination 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 third element of the content array is the bundle that - is to be transmitted. The destination of the bundle whose - payload is the BPDU (termed the "encapsulating bundle") SHALL - be the specified BP endpoint. Selection of the values of the + Bundle Protocol specification, a BPDU for which the third + element of the content array is the bundle that is to be + transmitted. The destination of the bundle whose payload is the + BPDU (termed the "encapsulating bundle") SHALL be the specified + destination 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. . Note that any transmission request presented to a BCLA MAY request that the transmission be subject to Custody Transfer, provided that the destination EID of the request identifies a singleton endpoint. . If Custody Transfer is requested: o The first element of the BPDU's content array MUST be the BPDU's transmission ID, which SHALL be 1 more than the current value of the BCLA's CTC for the node that is the sole occupant of the BPDU's destination endpoint. o The second element of the BPDU's content array MUST be the BPDU's retransmission time as discussed in 3.2 above. o The bundle protocol agent MUST add the retention constraint "Custody accepted" to the encapsulated bundle. o The BCLA MAY establish a retransmission timer for the - encapsulated bundle. If a retransmission timer is - established, it MUST be set to expire at the BPDU's - retransmission time. - . Otherwise, the first two elements of the BPDU's content array - MUST both be zero. + corresponding CTI. If a retransmission timer is + established, it MUST be set to expire at the + retransmission time indicated in the BPDU. + . Otherwise: + o The first two elements of the BPDU's content array MUST + both be zero. + o Upon completion of step 2 of Section 6.2 of the Bundle + Protocol specification (i.e., a request for transmission + of the encapsulating bundle has been presented to the + bundle protocol agent), the BCLA SHOULD notify the bundle + protocol agent that transmission of the encapsulated + bundle succeeded. 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): @@ -384,104 +398,102 @@ reception". 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 1, then custody transfer has failed. Custody transfer failure SHALL 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 source of the encapsulating bundle, whose disposition - is the reason code from Figure 2 that indicates the + is the reason code from Figure 1 that indicates the reason for the custody transfer failure. o Otherwise, custody transfer has succeeded: . 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 source of the encapsulating bundle, whose disposition is zero (indicating that custody was accepted). o In each of these three cases: . The pending outbound custody signal MAY then be issued immediately, but alternatively it MAY be issued at some time in the future, possibly enabling additional BPDUs' transmission IDs to be added to the same disposition scope report. - . 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 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 - 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. + delivered from the BCLA to the bundle protocol agent, whereupon + reception of the encapsulated bundle SHALL be performed as + defined in section 5.6 of the Bundle Protocol specification in + the usual manner: 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 + Note that the procedures by which pending outbound custody signals + are managed, disposition scope reports are aggregated, and custody + signal transmission is initiated are implementation matters that + are beyond the scope of this specification. Note, however, that failure to deliver a custody signal prior to the earliest value of retransmission time among all BPDUs enumerated in the custody - signal's disposition scope report may result in unnecessary - retransmission of one or more BPDUs. + signal's disposition scope report may result in the unnecessary + re-forwarding of one or more encapsulated bundles. 4.3. Retransmission Timer Expiration Upon expiration of a retransmission timer, the BCLA SHOULD remove the corresponding CTI from the CTDB (destroying the associated retransmission timer, if any) and notify the bundle protocol agent - that custodial transmission of the indicated bundle failed. This - notification may cause the indicated bundle to be re-forwarded - (possibly on a different route). + that transmission failed for the encapsulated bundle referenced by + that CTI. Note that this notification may cause the encapsulated + bundle to be re-forwarded (possibly on a different route). 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's disposition is 0 (custody acceptance), then for each transmission ID in the custody signal's disposition scope report: o The bundle protocol agent MUST remove the retention - constraint "Custody accepted" on the bundle referenced by - the corresponding CTI. + constraint "Custody accepted" on the encapsulated bundle + referenced by the corresponding CTI. o The corresponding CTI MUST be removed from the CTDB (destroying the associated retransmission timer, if any). + o The BCLA SHOULD notify the bundle protocol agent that + transmission succeeded for the encapsulated bundle + referenced by the corresponding CTI. + . 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 - 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. + the bundle protocol agent that transmission failed for the + encapsulated bundle referenced by the corresponding CTI. + If the reason code was "Redundant reception", on the other + hand, the BCLA might simply instruct the bundle protocol + agent to remove the retention constraint "Custody + accepted" on the encapsulated 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 delete a BIBE custody signal in transit. This could result in - unnecessary custodial retransmission, degrading network performance. + custody transfer failure and the possible re-forwarding of + encapsulated bundles, degrading network performance. Alternatively, an adversary on a DTN-based network that can reorder bundles could cause bundles to be delivered to a BCLA in an order that complicates the efficient construction of disposition scope reports in pending outbound custody signals. This could result in inefficient custody transfer communications, again degrading network performance. Custody transfer in BIBE may be contraindicated in environments characterized by such attacks. @@ -489,21 +501,21 @@ 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. + Version 7", draft-ietf-dtn-bpbis, February 2020. [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 @@ -530,21 +542,21 @@ (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. 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 + Copyright (c) 2020 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). Appendix B. CDDL expression