idnits 2.17.1 draft-burleigh-dtn-bibect-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 20, 2018) is 2168 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Delay-Tolerant Networking Working Group S. Burleigh 2 Internet Draft JPL, Calif. Inst. Of Technology 3 Intended status: Standards Track May 20, 2018 4 Expires: November 2018 6 Bundle-in-Bundle Encapsulation 7 draft-burleigh-dtn-bibect-01.txt 9 Status of this Memo 11 This Internet-Draft is submitted in full conformance with the 12 provisions of BCP 78 and BCP 79. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months and may be updated, replaced, or obsoleted by other documents 21 at any time. It is inappropriate to use Internet-Drafts as 22 reference material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html 30 This Internet-Draft will expire on November 21, 2018. 32 Copyright Notice 34 Copyright (c) 2018 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents 39 (http://trustee.ietf.org/license-info) in effect on the date of 40 publication of this document. Please review these documents 41 carefully, as they describe your rights and restrictions with 42 respect to this document. Code Components extracted from this 43 document must include Simplified BSD License text as described in 44 Section 4.e of the Trust Legal Provisions and are provided without 45 warranty as described in the Simplified BSD License. 47 Abstract 49 This document describes Bundle-in-Bundle Encapsulation (BIBE), a 50 Delay-Tolerant Networking (DTN) Bundle Protocol (BP) "convergence 51 layer" protocol that tunnels BP "bundles" through encapsulating 52 bundles. The services provided by the BIBE convergence-layer 53 protocol adapter encapsulate an outbound BP "bundle" in a BIBE 54 convergence-layer protocol data unit for transmission as the payload 55 of a bundle. Security measures applied to the encapsulating bundle 56 may augment those applied to the encapsulated bundle. The protocol 57 includes a mechanism for recovery from loss of an encapsulating 58 bundle, called "custody transfer". This mechanism is adapted from 59 the custody transfer procedures described in the experimental Bundle 60 Protocol specification developed by the Delay-Tolerant Networking 61 Research group of the Internet Research Task Force and documented in 62 RFC 5050. 64 Table of Contents 66 1. Introduction...................................................2 67 2. Conventions used in this document..............................4 68 3. BIBE Design Elements...........................................4 69 3.1. BIBE Endpoints............................................4 70 3.2. BIBE Protocol Data Units..................................4 71 3.3. Custody Signals...........................................6 72 3.4. Custody Transfer Status Reports...........................7 73 4. BIBE Procedures................................................8 74 4.1. BPDU Transmission.........................................8 75 4.2. BPDU Reception............................................8 76 4.3. Retransmission Timer Expiration..........................10 77 4.4. Custody Signal Reception.................................10 78 5. Security Considerations.......................................11 79 6. IANA Considerations...........................................11 80 7. References....................................................11 81 7.1. Normative References.....................................11 82 7.2. Informative References...................................11 83 8. Acknowledgments...............................................11 84 Appendix A. For More Information.................................13 85 Appendix B. CDDL expression......................................14 87 1. Introduction 89 This document describes Bundle-in-Bundle Encapsulation (BIBE), a 90 Delay-Tolerant Networking (DTN) Bundle Protocol (BP) [RFC5050] 91 "convergence layer" protocol that tunnels BP "bundles" through 92 encapsulating bundles. 94 Conformance to the bundle-in-bundle encapsulation (BIBE) 95 specification is OPTIONAL for BP nodes. Each BP node that conforms 96 to the BIBE specification provides a BIBE convergence-layer adapter 97 (CLA) that is implemented within the administrative element of the 98 BP node's application agent. Like any convergence-layer adapter, 99 the BIBE CLA provides: 101 . A transmission service that sends an outbound bundle (from the 102 bundle protocol agent) to a peer CLA. In the case of BIBE, the 103 sending CLA and receiving peer CLA are both BP nodes. 104 . A reception service that delivers to the bundle protocol agent 105 an inbound bundle that was sent by a peer CLA (itself a BP 106 node) via the BIBE convergence layer protocol. 108 The BIBE CLA performs these services by: 110 . Encapsulating outbound bundles in BIBE protocol data units, 111 which take the form of Bundle Protocol administrative records 112 as described later. 113 . Requesting that the bundle protocol agent transmit bundles 114 whose payloads are BIBE protocol data units. 115 . Taking delivery of BIBE protocol data units that are the 116 payloads of bundles received by the bundle protocol agent. 117 . Delivering to the bundle protocol agent the bundles that are 118 encapsulated in delivered BIBE protocol data units. 120 Bundle-in-bundle encapsulation may have broad utility, but the 121 principal motivating use case is the deployment of "cross domain 122 solutions" in secure communications. Under some circumstances a 123 bundle may arrive at a node that is on the frontier of a sector of 124 network topology in which augmented security is required, from which 125 the bundle must egress at some other designated node. In that case, 126 the bundle may be encapsulated within a bundle to which the 127 requisite additional BP Security (BPSEC) [bpsec] extension block(s) 128 can be attached, whose source is the point of entry into the 129 insecure region (the "security source") and whose destination is the 130 point of egress from the insecure region (the "security 131 destination"). 133 Note that: 135 . If the payload of the encapsulating bundle is protected by a 136 Bundle Confidentiality Block (BCB), then the source and 137 destination of the encapsulated bundle are encrypted, providing 138 defense against traffic analysis that BPSEC alone cannot offer. 139 . Bundles whose payloads are BIBE protocol data units may 140 themselves be forwarded via a BIBE convergence-layer adapter, 141 enabling nested bundle encapsulation to arbitrary depth as 142 required by security policy. 143 . Moreover, in the event that no single point of egress from an 144 insecure region of network topology can be determined at the 145 moment a bundle is to be encapsulated, multiple copies of the 146 bundle may be encapsulated individually and forwarded to all 147 candidate points of egress. 149 The protocol includes a mechanism for recovery from loss of an 150 encapsulating bundle, called "custody transfer". This mechanism is 151 adapted from the custody transfer procedures described in the 152 experimental Bundle Protocol specification developed by the Delay- 153 Tolerant Networking Research group of the Internet Research Task 154 Force and documented in RFC 5050. Custody transfer is a convention 155 by which the loss or corruption of BIBE encapsulating bundles can be 156 mitigated by the exchange of other bundles, which are termed 157 "custody signals". 159 2. Conventions used in this document 161 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 162 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 163 document are to be interpreted as described in RFC-2119 [RFC2119]. 165 In this document, these words will appear with that interpretation 166 only when in ALL CAPS. Lower case uses of these words are not to be 167 interpreted as carrying RFC-2119 significance. 169 3. BIBE Design Elements 171 3.1. BIBE Endpoints 173 BIBE convergence-layer protocol endpoints, also known as BIBE 174 convergence-layer adapters (BCLAs), are the Administrative Elements 175 of Bundle Protocol nodes that conform to the BIBE protocol 176 specification. The node of which a given BCLA is one component is 177 termed the BCLA's "local node". 179 3.2. BIBE Protocol Data Units 181 Notionally, a BCLA is assumed to implement in some way, for each 182 neighboring node to which the local node issues Bundle Protocol Data 183 Units (BPDUs), the following two data resources: 185 1. A "custodial transmission count" (CTC). A CTC is a 186 monotonically increasing integer indicating the number of 187 "custodial" BPDUs - that is, BPDUs for which custody transfer 188 was requested - that have been issued to the neighboring node 189 by the local node since instantiation of the local node. 190 2. A "custodial transmission database" (CTDB), a notional array of 191 "custodial transmission items" (CTIs). The CTDB contains one 192 CTI for each custodial BPDU issued to the neighboring node, by 193 the local node, for which (a) no custody disposition has yet 194 been received in any custody signal (as discussed later) and 195 (b) the bundle encapsulated in that BPDU has not yet been 196 destroyed due to, e.g., time-to-live expiration. Each CTI 197 notionally contains: 198 a. A reference to the bundle encapsulated in the 199 corresponding BPDU. 200 b. The "transmission ID" of the corresponding BPDU, as 201 discussed below. 202 c. A "retransmission time" indicating the time by which 203 custody disposition for the corresponding BDPU is 204 expected. 206 A BIBE protocol data unit is a Bundle Protocol administrative record 207 whose record type code is 3 (i.e., bit pattern 0011), constructed as 208 follows. 210 Each BPDU SHALL be represented as a CBOR array. The number of 211 elements in the array SHALL be 3. 213 The first item of the BPDU array SHALL be the "transmission ID" for 214 the BPDU, represented as a CBOR unsigned integer. The transmission 215 ID for a BPDU for which custody transfer is NOT requested SHALL be 216 zero. The transmission ID for a BPDU for which custody transfer IS 217 requested SHALL be the current value of the local node's custodial 218 transmission count, plus 1. 220 The second item of the BPDU array SHALL be the BPDU's retransmission 221 time (i.e., the time by which custody disposition for this BPDU is 222 expected), represented as a CBOR unsigned integer. Retransmission 223 time for a BPDU for which custody transfer is NOT requested SHALL be 224 zero. Retransmission time for a BPDU for which custody transfer IS 225 requested SHALL take the form of a "DTN Time" as defined in the 226 Bundle Protocol specification; determination of the value of 227 retransmission time is an implementation matter that is beyond the 228 scope of this specification and may be dynamically responsive to 229 changes in connectivity. 231 The third item of the BPDU array SHALL be a single BP bundle, termed 232 the "encapsulated bundle", represented as a CBOR byte string. 234 3.3. Custody Signals 236 A "custody signal" is defined as a Bundle Protocol administrative 237 record whose record type code is 4 (i.e., bit pattern 0100) and 238 whose content is constructed as follows. 240 The content of each custody signal SHALL be represented as a CBOR 241 array. The number of elements in the array SHALL be 2. 243 The first item of the custody signal content array SHALL be a 244 disposition code represented as a CBOR unsigned integer. Valid 245 disposition codes are defined as follows: 247 +---------+--------------------------------------------+ 249 | Value | Meaning | 251 +=========+============================================+ 253 | 0 | Custody accepted. | 255 +---------+--------------------------------------------+ 257 | 1 | No further information. | 259 +---------+--------------------------------------------+ 261 | 2 | Reserved for future use. | 263 +---------+--------------------------------------------+ 265 | 3 | Redundant (reception by a node that | 267 | | already has a copy of this bundle). | 269 +---------+--------------------------------------------+ 271 | 4 | Depleted storage. | 273 +---------+--------------------------------------------+ 275 | 5 | Destination endpoint ID unintelligible. | 277 +---------+--------------------------------------------+ 279 | 6 | No known route destination from here. | 280 +---------+--------------------------------------------+ 282 | 7 | No timely contact with next node on route. | 284 +---------+--------------------------------------------+ 286 | 8 | Block unintelligible. | 288 +---------+--------------------------------------------+ 290 | (other) | Reserved for future use. | 292 +---------+--------------------------------------------+ 294 Figure 1: Disposition Codes 296 The second item of the custody signal content array SHALL be a 297 "disposition scope report", represented as a CBOR indefinite-length 298 array. Each item of the disposition scope report array SHALL be a 299 "disposition scope sequence", represented as a CBOR array of two 300 elements. The first element of each disposition scope sequence 301 array SHALL be the first transmission ID in a sequence of 1 or more 302 consecutive transmission IDs corresponding to BPDUs to which the 303 custody signal's disposition is declared to apply; the second 304 element of each disposition scope sequence array SHALL be the number 305 of transmission IDs in that sequence. Both are represented as CBOR 306 unsigned integers. 308 A custody signal constitutes an assertion by the source of that 309 administrative bundle that the indicated disposition code applies to 310 all BPDUs identified by the transmission IDs enumerated in the 311 custody signal's disposition scope report. If the disposition code 312 is zero, then the source of the custody signal has accepted custody 313 of all bundles that were encapsulated in the indicated BPDUs. 314 Otherwise the source of the custody signal has refused custody of 315 all bundles that were encapsulated in the indicated BPDUs, for the 316 indicated reason. 318 3.4. Custody Transfer Status Reports 320 A "custody transfer status report" is a bundle status report with 321 the "reporting node attempted custody transfer" flag set to 1. 323 4. BIBE Procedures 325 4.1. BPDU Transmission 327 When a BCLA is requested by the bundle protocol agent to send a 328 bundle to the peer BCLA(s) included in the BP endpoint identified by 329 a specified BP endpoint ID: 331 . The BCLA SHALL generate, as defined in Section 6.2 of the 332 Bundle Protocol specification (a work in progress), a BPDU for 333 which the third element of the content array is the bundle that 334 is to be transmitted. The destination of the bundle whose 335 payload is the BPDU (termed the "encapsulating bundle") SHALL 336 be the specified BP endpoint. Selection of the values of the 337 parameters governing the forwarding of the encapsulating 338 bundle, other than the destination endpoint ID, is an 339 implementation matter. The parameter values governing the 340 forwarding of the BPDU's encapsulated bundle MAY be consulted 341 for this purpose. 342 . Note that any transmission request presented to a BCLA MAY 343 request that the transmission be subject to Custody Transfer, 344 provided that the destination EID of the request identifies a 345 singleton endpoint. 346 . If Custody Transfer is requested: 347 o The first element of the BPDU's content array MUST be the 348 BPDU's transmission ID, which SHALL be 1 more than the 349 current value of the BCLA's CTC for the node that is the 350 sole occupant of the BPDU's destination endpoint. 351 o The second element of the BPDU's content array MUST be the 352 BPDU's retransmission time as discussed in 3.2 above. 353 o The bundle protocol agent MUST add the retention constraint 354 "Custody accepted" to the encapsulated bundle. 355 o The BCLA MAY establish a retransmission timer for the 356 encapsulated bundle. If a retransmission timer is 357 established, it MUST be set to expire at the BPDU's 358 retransmission time. 359 . Otherwise, the first two elements of the BPDU's content array 360 MUST both be zero. 362 Note that the custody transfer retransmission timer mechanism 363 provides a means of recovering from loss of an encapsulating bundle 364 as indicated by non-arrival of a responding custody signal. 366 4.2. BPDU Reception 368 When a BCLA receives a BPDU from the bundle protocol agent (that is, 369 upon delivery of the payload of an encapsulating bundle): 371 . If Custody Transfer was requested for this BPDU (as indicated 372 by a non-zero value of transmission ID): 373 o If the encapsulated bundle has the same source node ID, 374 creation timestamp, and (if that bundle is a fragment) 375 fragment offset and payload length as another bundle that 376 is currently retained at the BCLA's local node, then 377 custody transfer redundancy MUST be handled as follows: 378 . The BCLA SHALL add the BPDU's transmission ID to the 379 disposition scope report of a pending outbound 380 custody signal, destined for the node that was the 381 source of the encapsulating bundle, whose disposition 382 is the reason code from Figure 1 for "Redundant 383 reception"., 384 o Otherwise, if the BCLA determines that its local node can 385 neither deliver nor forward the encapsulated bundle for 386 any of the reasons listed in Figure 1, then custody 387 transfer has failed. Custody transfer failure SHALL be 388 handled as follows: 389 . The BCLA SHALL add the BPDU's transmission ID to the 390 disposition scope report of a pending outbound 391 custody signal, destined for the node that was the 392 source of the encapsulating bundle, whose disposition 393 is the reason code from Figure 2 that indicates the 394 reason for the custody transfer failure. 395 o Otherwise, custody transfer has succeeded: 396 . The BCLA SHALL add the BPDU's transmission ID to the 397 disposition scope report of a pending outbound 398 custody signal, destined for the node that was the 399 source of the encapsulating bundle, whose disposition 400 is zero (indicating that custody was accepted). 401 o In each of these three cases: 402 . The pending outbound custody signal MAY then be 403 issued immediately, but alternatively it MAY be 404 issued at some time in the future, possibly enabling 405 additional BPDUs' transmission IDs to be added to the 406 same disposition scope report. 407 . If the "request reporting of custody transfer 408 attempted" flag in the encapsulating bundle's status 409 report request field is set to 1, and status 410 reporting is enabled, a custody transfer status 411 report whose reason code is the same as the pending 412 outbound custody signal's disposition SHOULD be 413 generated, destined for the report-to endpoint of the 414 encapsulating bundle. 415 . If Custody Transfer was NOT requested for this BPDU, or if 416 Custody Transfer was requested for this BPDU and custody 417 transfer succeeded, then the encapsulated bundle SHALL be 418 delivered from the convergence layer adapter to the bundle 419 protocol agent, whereupon bundle reception SHALL be performed 420 as defined in section 5.6 of the Bundle Protocol specification 421 (a work in progress) as usual: the encapsulated bundle may be 422 forwarded, delivered, etc. 424 Note that the manner in which pending outbound custody signals are 425 managed, disposition scope reports are aggregated, and custody 426 signal transmission is initiated is an implementation matter that 427 is beyond the scope of this specification. Note, however, that 428 failure to deliver a custody signal prior to the earliest value of 429 retransmission time among all BPDUs enumerated in the custody 430 signal's disposition scope report may result in unnecessary 431 retransmission of one or more BPDUs. 433 4.3. Retransmission Timer Expiration 435 Upon expiration of a retransmission timer, the BCLA SHOULD remove 436 the corresponding CTI from the CTDB (destroying the associated 437 retransmission timer, if any) and notify the bundle protocol agent 438 that custodial transmission of the indicated bundle failed. This 439 notification may cause the indicated bundle to be re-forwarded 440 (possibly on a different route). 442 4.4. Custody Signal Reception 444 When a BCLA receives a custody signal from the bundle protocol agent 445 (that is, upon delivery of the payload of a custody-signal-bearing 446 bundle): 448 . If the custody signal's disposition is 0 (custody acceptance), 449 then for each transmission ID in the custody signal's 450 disposition scope report: 451 o The bundle protocol agent MUST remove the retention 452 constraint "Custody accepted" on the bundle referenced by 453 the corresponding CTI. 454 o The corresponding CTI MUST be removed from the CTDB 455 (destroying the associated retransmission timer, if any). 456 . Otherwise (custody refusal), for each transmission ID in the 457 custody signal's disposition scope report: 458 o The corresponding CTI MUST be removed from the CTDB 459 (destroying the associated retransmission timer, if any). 460 o Any further action taken by the BCLA is implementation- 461 specific and may depend on the reason code cited for the 462 refusal. For example, if the custody signal's reason code 463 was "Depleted storage", the BCLA might choose to notify 464 the bundle protocol agent that custodial transmission of 465 the indicated bundle failed. If the reason code was 466 "Redundant reception", on the other hand, this might cause 467 the BCLA simply to instruct the bundle protocol agent to 468 remove the retention constraint "Custody accepted" on the 469 bundle referenced by the corresponding CTI and to revise 470 its algorithm for computing retransmission time. 472 5. Security Considerations 474 An adversary on a DTN-based network that can delete bundles could 475 delete a BIBE custody signal in transit. This could result in 476 unnecessary custodial retransmission, degrading network performance. 478 Alternatively, an adversary on a DTN-based network that can reorder 479 bundles could cause bundles to be delivered to a BCLA in an order 480 that complicates the efficient construction of disposition scope 481 reports in pending outbound custody signals. This could result in 482 inefficient custody transfer communications, again degrading network 483 performance. 485 Custody transfer in BIBE may be contraindicated in environments 486 characterized by such attacks. 488 6. IANA Considerations 490 The BIBE specification requires IANA registration of the new BIBE 491 administrative records (type codes 3 and 4) defined above. 493 7. References 495 7.1. Normative References 497 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 498 Requirement Levels", BCP 14, RFC 2119, March 1997. 500 7.2. Informative References 502 [RFC5050] Scott, M. and S. Burleigh, "Bundle Protocol 503 Specification", RFC 5050, November 2007. 505 8. Acknowledgments 507 This work is freely adapted from [RFC5050], which was an effort of 508 the Delay Tolerant Networking Research Group. The following DTNRG 509 participants contributed significant technical material and/or 510 inputs to that document: Dr. Vinton Cerf of Google, Scott Burleigh, 511 Adrian Hooke, and Leigh Torgerson of the Jet Propulsion Laboratory, 512 Michael Demmer of the University of California at Berkeley, Robert 513 Durst, Keith Scott, and Susan Symington of The MITRE Corporation, 514 Kevin Fall of Carnegie Mellon University, Stephen Farrell of Trinity 515 College Dublin, Peter Lovell of SPARTA, Inc., Manikantan Ramadas of 516 Ohio University, and Howard Weiss of SPARTA, Inc. 518 The custody transfer procedures defined in this specification are 519 adapted from the Aggregate Custody Signals draft specification 520 authored in 2010-2012 by Sebastian Kuzminsky and Andrew Jenkins, 521 then of the University of Colorado at Boulder. 523 Although the BIBE specification diverges in some ways from the 524 original Bundle-in-Bundle Encapsulation Internet Draft authored by 525 Susan Symington, Bob Durst, and Keith Scott of The MITRE Corporation 526 (draft-irtf-dtnrg-bundle-encapsulation-06, 2009), the influence of 527 that earlier document is gratefully acknowledged. 529 This document was prepared using 2-Word-v2.0.template.dot. 531 Appendix A. For More Information 533 Please refer comments to dtn@ietf.org. The Delay Tolerant Networking 534 Research Group (DTNRG) Web site is located at http://www.dtnrg.org. 536 Copyright (c) 2018 IETF Trust and the persons identified as authors 537 of the code. All rights reserved. 539 Redistribution and use in source and binary forms, with or without 540 modification, is permitted pursuant to, and subject to the license 541 terms contained in, the Simplified BSD License set forth in Section 542 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents 543 (http://trustee.ietf.org/license-info). 545 Appendix B. CDDL expression 547 For informational purposes, Carsten Bormann has kindly provided an 548 expression of the Bundle Protocol specification in the CBOR Data 549 Definition Language (CDDL). Portions of CDDL expression that bear 550 on the custody transfer extension are presented below, somewhat 551 edited by the authors. Note that wherever the CDDL expression is in 552 disagreement with the textual representation of the BP specification 553 presented in the earlier sections of this document, the textual 554 representation rules. 556 admin-record-choice /= BIBE-PDU 558 BIBE-PDU = [3, [transmission-ID: uint, 560 retransmission-time: uint, 562 encapsulated-bundle: bytes, 564 admin-common]] 566 admin-record-choice /= custody-signal 568 custody-signal = [4, [disposition-code: uint, 570 disposition-scope-report, 572 admin-common]] 574 disposition-scope-report = *disposition-scope-sequence 576 disposition-scope-sequence = [first-transmission-ID: uint, 578 number-of-transmission-IDs: uint] 580 Authors' Address 582 Scott Burleigh 583 Jet Propulsion Laboratory, California Institute of Technology 584 4800 Oak Grove Dr. 585 Pasadena, CA 91109-8099 586 US 587 Phone: +1 818 393 3353 588 Email: Scott.Burleigh@jpl.nasa.gov