DTN Research Group S. Symington Internet-Draft R. Durst Intended status: Experimental K. Scott Expires: August 6, 2009 The MITRE Corporation February 2, 2009 Delay-Tolerant Networking Bundle-in-Bundle Encapsulation draft-irtf-dtnrg-bundle-encapsulation-05 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on August 6, 2009. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Symington, et al. Expires August 6, 2009 [Page 1] Internet-Draft DTN Bundle-in-Bundle Encapsulation February 2009 Abstract This document defines an encapsulation-specific application agent capability and a bundle payload format for use with the Bundle Protocol [refs.DTNBP] within the context of a Delay-Tolerant Network architecture [refs.DTNarch]. It defines the capability and format for placing one or more bundles inside of the payload field of an encapsulating bundle's Bundle Payload Block. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Motivating Use Cases . . . . . . . . . . . . . . . . . . . . . 4 3. Payload Field Format for Bundle-in-Bundle Encapsulation . . . 6 4. Encapsulation Requirements . . . . . . . . . . . . . . . . . . 7 4.1. Diversion of Bundles for Encapsulation . . . . . . . . . . 7 4.2. Encapsulation Processing Steps . . . . . . . . . . . . . . 7 5. De-encapsulation Requirements . . . . . . . . . . . . . . . . 9 5.1. Injection of De-encapsulated Bundles . . . . . . . . . . . 9 5.2. De-encapsulation Processing . . . . . . . . . . . . . . . 9 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 8.1. Normative References . . . . . . . . . . . . . . . . . . . 12 8.2. Informative References . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 Symington, et al. Expires August 6, 2009 [Page 2] Internet-Draft DTN Bundle-in-Bundle Encapsulation February 2009 1. Introduction The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [refs.RFC2119]. This document defines an encapsulation-specific application agent capability and a bundle payload format for use with the Bundle Protocol [refs.DTNBP] within the context of a Delay-Tolerant Network architecture [refs.DTNarch]. It defines the capability and format for placing one or more bundles inside of the payload field of an encapsulating bundle's Bundle Payload Block. The capabilities described in this document are OPTIONAL for deployment with the Bundle Protocol. Application agents claiming to support bundle-in-bundle encapsulation MUST be capable of both: -generating and transmitting bundles that have Bundle Payload Blocks whose payload fields are formatted to contain one or more bundles (encapsulation), and -receiving and processing bundles that have Bundle Payload Blocks whose payload fields are formatted to contain one or more bundles (de-encapsulation) as defined in this document. Bundle protocol agents claiming to support this document MUST be capable of diverting and inserting bundles as described in [refs.DTNdivert], and must provide a raw bundle interface to the encapsulating/de-encapsulating application agents across which bundles may be passed. Symington, et al. Expires August 6, 2009 [Page 3] Internet-Draft DTN Bundle-in-Bundle Encapsulation February 2009 2. Motivating Use Cases The bundle-in-bundle encapsulation mechanism is expected to be of general utility in DTN. So far, three use cases have been identified for this capability: Content-based dissemination of data from a DTN node's storage cache - A caching bundle node may have a bundle store that contains bundles with content-based metadata extension blocks [refs.Metadata]. If this caching bundle node receives a request for bundles having data of a certain content type from a particular requesting node, the caching bundle node will want to retrieve the bundle(s) matching that content type from its bundle store and send those bundle(s) to the requesting node. If the endpoint of which the requesting node is a member is different from the destination endpoint of the stored bundle(s), in order to send the bundle(s), the caching node either has to replace the destination EID of the stored bundle(s) with the EID of the requesting node or place the stored bundle(s) into one or more encapsulating bundles that have as their destination EID the EID of the requesting node. If the stored bundles are protected with a Payload Integrity Block (PIB), the caching node has no choice but to send these bundles using encapsulation, because if the destination EIDs of the stored bundles are changed, the security results in their PIB(s) will not compute to the correct value at the security destination and they will fail their integrity check. Efficient custodial retransmission of a multicast bundle - As defined in [refs.DTNcustMC], if a custodian of a multicast bundle receives a failed custody signal from a specific downstream node, the custodian will want to get that multicast bundle to that downstream node so that it can be forwarded on from that downstream node. However, the custodian may not want to simply retransmit the multicast bundle because this may cause the bundle to be resent to many other nodes on the multicast distribution path that have already received the bundle, in addition to the node that the custodian wants the bundle to reach. As an alternative, the custodian may want to place the multicast bundle inside of an encapsulating unicast bundle and send the encapsulating bundle to the downstream node that generated the failed custody signal so that the downstream node can de- encapsulate the multicast bundle and forward it on from there. Tunneling - Bundle-in-bundle encapsulation is a method of tunneling bundles across some portion of a network. As mentioned in [refs.DTNBPsec], in the security case, one or more bundles can be placed inside of the payload of another bundle and then the payload of the encapsulating bundle can be encrypted. The Symington, et al. Expires August 6, 2009 [Page 4] Internet-Draft DTN Bundle-in-Bundle Encapsulation February 2009 encapsulating bundle is then sent from the encapsulating security gateway to the de-encapsulating security gateway which, in effect, form the ends of a security tunnel. This security tunnel protects the entire contents of the encapsulated bundle(s) from being disclosed, so that even the confidentiality of each bundle's source EID and destination EID are maintained on the portion of the network that is spanned by the tunnel. Symington, et al. Expires August 6, 2009 [Page 5] Internet-Draft DTN Bundle-in-Bundle Encapsulation February 2009 3. Payload Field Format for Bundle-in-Bundle Encapsulation Bundle-in-bundle encapsulation is accomplished by placing the bundle(s) to be encapsulated into the payload field of an encapsulating bundle's Bundle Payload Block. The elements that must be placed in the payload field of the Bundle Payload Block and their format are as follows: - Number of Encapsulated Bundles field (SDNV) - indicates the number N of bundles that are present in the Encapsulated Bundle List field (defined below), where N MUST be greater than 0. - Bundle Offsets List (optional) - contains the list of N-1 offsets (each of which is an SDNV) of the beginning of each bundle that is located in the Encapsulated Bundle List field after the first bundle in that field. (The offset of the first bundle in the Encapsulated Bundle List is understood to be 0.) If only 1 bundle is present in the Encapsulated Bundle List (i.e., if the value in the Number of Encapsulated Bundles field is 1), the Bundle Offsets List field MUST NOT be present. - Encapsulated Bundle List - contains the list of N bundles that are encapsulated. The format of the payload field of the Bundle Payload Block of an encapsulating bundle is as follows: Payload Field Format of the Bundle Payload Block of an Encapsulating Bundle: +------------------------+-----------------+--------------+ | Number of Encapsulated | Bundle Offsets | Encapsulated | | Bundles(SDNV) | List (opt.) | Bundle List | +------------------------+-----------------+--------------+ Figure 1 Symington, et al. Expires August 6, 2009 [Page 6] Internet-Draft DTN Bundle-in-Bundle Encapsulation February 2009 4. Encapsulation Requirements 4.1. Diversion of Bundles for Encapsulation Bundles that are diverted to a bundle-in-bundle encapsulation application agent (AA) as described in [refs.DTNdivert] MUST be diverted at the following point in bundle processing, relative to the bundle processing procedures defined in [refs.DTNBP] and to the procedures required to process any extension blocks (e.g. security blocks, Previous Hop Insertion Block, Metadata Extension Block, etc.) in the bundle: -after the bundle has been processed for reception (if it was received from another node), including the processing of all of its extension blocks (if any), e.g. after verifying the security result in the Bundle Authentication Block (BAB) [refs.DTNBPsec] (if present) and deleting the BAB, after verifying the security result in the Payload Security Block (PSB) if the node is the security destination, after using and deleting the Previous Hop Insertion Block (if present), etc., and -after the bundle has been prepared for forwarding, having been given all necessary extension blocks, e.g. a new BAB (if appropriate), a new Previous Hop Insertion Block (if appropriate), etc., but -before the bundle is actually forwarded or delivered. Note that, as described in [refs.DTNdivert], if, as part of the procedures for preparing the bundle for forwarding, the bundle is given a BAB, the EID of the node that is creating this BAB MUST be identified within the bundle, either through an EID reference to the BAB security-source or using another mechanism, such as the Previous Hop Insertion Block [refs.PrevHopExt] because it will not be possible for the bundle protocol agent that is responsible for validating the security result in the BAB to determine the EID of this BAB-creating node through implementation-specific means (such as from the convergence layer). 4.2. Encapsulation Processing Steps Upon receipt of one or more such diverted bundles, the bundle-in- bundle encapsulation AA MUST place the bundle or bundles that have been diverted to it into the Encapsulated Bundle List field of an application data unit that is formatted as described above and request transmission of a bundle containing this application data unit as the payload field of its Bundle Payload Block. If more than one bundle has been placed in the Encapsulated Bundle List field, the Symington, et al. Expires August 6, 2009 [Page 7] Internet-Draft DTN Bundle-in-Bundle Encapsulation February 2009 value of the Number of Encapsulated Bundles field MUST have as its value the number of bundles that have been placed in the Encapsulated Bundle List and the value of the Bundle Offsets List field MUST be the list of offsets of each of the encapsulated bundles, after the first encapsulated bundle, in the payload field. If exactly one bundle has been placed in the Encapsulated Bundle List field, the value of the Number of Encapsulated Bundles field MUST have as its value the number 1 and the Bundle Offsets List field MUST NOT be present. The parameters of the bundle transmission request for this encapsulating bundle must result in the following: If any of the diverted bundles that were placed in the Encapsulated Bundle List has its "Custody transfer is requested" Bundle Processing Control Flag [refs.DTNBP] set, the encapsulating bundle must have its "Custody transfer is requested" Bundle Processing Control Flag set. The value of the destination EID in the new, encapsulating bundle MUST identify an endpoint of which the node(s) that will be de- encapsulating the bundle is/are a member. The value of the source EID of the encapsulating bundle MUST be set to an endpoint ID of which the bundle-in-bundle encapsulation AA is a member. The value of the Creation Timestamp of the encapsulating bundle MUST be set to the time at which the node began constructing the encapsulating bundle, and the value of the Lifetime of the encapsulating bundle MUST be set such that the encapsulating bundle will expire at or later than the expiration time of all of its encapsulated bundle(s). That is, the creation time plus the lifetime of the encapsulating bundle must be greater than or equal to the creation time plus the lifetime of each of the bundles that have been placed in the Encapsulated Bundle List field. Note that there is currently no Bundle Status Report Status Flag [refs.DTNBP] defined to indicate that the "Reporting node is encapsulating a bundle". Such a status report could possibly be helpful and perhaps should be defined in the future. If such a status report were to be sent to the current custodian (if any) of the encapsulated bundle upon its encapsulation, for example, the status report would indicate to the custodian that custody signals for the encapsulated bundle will not be received until some time after the encapsulated bundle has been de-encapsulated. Symington, et al. Expires August 6, 2009 [Page 8] Internet-Draft DTN Bundle-in-Bundle Encapsulation February 2009 5. De-encapsulation Requirements 5.1. Injection of De-encapsulated Bundles Upon delivery of a bundle at a de-encapsulation AA, the de- encapsulation AA MUST extract the encapsulated bundle(s) from the Encapsulated Bundle List item of the payload field of the encapsulating bundle's Bundle Payload Block and inject these de- encapsulated bundles into the bundle protocol agent at the following point in bundle processing, relative to the bundle processing procedures defined in [refs.DTNBP] and to the procedures required to process any extension blocks (e.g. security blocks, Previous Hop Insertion Block, Metadata Extension Block, etc.) in the bundle: -after the bundle has been received from another node, but -before it has been processed for reception, including before the processing of all of its extension blocks (if any), e.g. before reporting bundle reception, before verifying the security result in the Bundle Authentication Block (BAB) (if present) and deleting the BAB, before verifying the security result in the Payload Security Block (PSB) and/or the Payload Confidentiality Block (PCB) if the node is the security destination, before using and deleting the Previous Hop Insertion Block (if present), etc. 5.2. De-encapsulation Processing As discussed in [refs.DTNdivert], when processing the injected bundles for reception, it will not be possible for the bundle protocol agent to determine the EID of the previous hop node of these de-encapsulated, injected bundles through implementation-specific means (such as from the convergence layer), because the previous hop node was the node that diverted the bundles to the encapsulation AA, which is not necessarily a neighboring node in the DTN overlay. Therefore, if the EID of the previous hop node is needed by the bundle protocol agent, this EID MUST be present in the de- encapsulated bundle, for example, in a Previous Hop Insertion Block [refs.PrevHopExt] or in the EID reference to the security-source of a BAB [refs.DTNBPsec], if the bundle contains a BAB. If the EID of the previous hop node is needed but is not present in the de-encapsulated bundle, the bundle MUST be discarded and processed no further. Symington, et al. Expires August 6, 2009 [Page 9] Internet-Draft DTN Bundle-in-Bundle Encapsulation February 2009 6. Security Considerations Bundle-in-bundle encapsulation is an application protocol; it does not require an extension block. All encapsulated bundles and associated information needed to perform de-encapsulation are carried in the payload field of the Bundle Payload Block. Therefore, encapsulated bundles are protected, for security purposes, by all three mandatory ciphersuites defined in the Bundle Security Protocol, just as any bundle payload is. It should be noted that when a bundle is encapsulated, the encapsulated bundle itself may be protected by one or more security blocks. In particular, it may contain a Bundle Authentication Block (BAB), which is designed to be processed by a next-hop neighboring DTN node. If a bundle with a BAB is encapsulated by one node and received and de-encapsulated by a non-neighboring node, the bundle protocol agent into which the de-encapsulated bundle is injected for processing must be capable of validating the security result in the BAB if its security policy requires such validation. Therefore, as explained in [refs.DTNdivert], encapsulation of bundles protected by BABs may require that keys that are normally only shared between neighbors be distributed further in the DTN so that they are shared by the encapsulating and de-encapsulating nodes. Furthermore, because it is not possible for the bundle protocol agent into which the de-encapsulated bundle is injected to determine the EID of the diverting node that inserted the BAB into the encapsulated bundle through implementation-specific means (such as from the convergence layer), if the EID of this diverting node is not identified elsewhere in the encapsulated bundle (e.g. in the Previous Hop Insertion Block), this EID must be referenced as the security-source field of the BAB. Symington, et al. Expires August 6, 2009 [Page 10] Internet-Draft DTN Bundle-in-Bundle Encapsulation February 2009 7. IANA Considerations None at this time. Symington, et al. Expires August 6, 2009 [Page 11] Internet-Draft DTN Bundle-in-Bundle Encapsulation February 2009 8. References 8.1. Normative References [refs.RFC2119] Bradner, S. and J. Reynolds, "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, October 1997. [refs.DTNBP] Scott, K. and S. Burleigh, "Bundle Protocol Specification", RFC, 5050, November 2007. [refs.DTNdivert] Symington, S., Durst, R., and K. Scott, "Delay-Tolerant Networking Bundle Diversion", draft-irtf-dtnrg-bundle-divert-00.txt, work-in-progress, February 2009. [refs.DTNcustMC] Symington, S., Durst, R., and K. Scott, "Delay-Tolerant Networking Custodial Multicast Extensions", draft-irtf- dtnrg-bundle-multicast-custodial-05.txt, work-in-progress, October 2008. [refs.PrevHopExt] Symington, S., "Delay-Tolerant Networking Previous Hop Insertion Block", draft-irtf-dtnrg-bundle-previous-hop- block-04.txt, work-in-progress, September 2008. [refs.Metadata] Symington, S., "Delay-Tolerant Networking Metadata Extension Block", draft-irtf-dtnrg-bundle-metadata-block- 00.txt, work-in-progress, September 2008. [refs.DTNBPsec] Symington, S., Farrell, S., Weiss, H., and P. Lovell, "Bundle Security Protocol Specification", draft-irtf-dtnrg-bundle-security-06.txt, work-in-progress, November 2008. 8.2. Informative References [refs.DTNarch] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst, R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant Network Architecture", RFC 4838, April 2007. Symington, et al. Expires August 6, 2009 [Page 12] Internet-Draft DTN Bundle-in-Bundle Encapsulation February 2009 Authors' Addresses Susan Flynn Symington The MITRE Corporation 7515 Colshire Drive McLean, VA 22102 US Phone: +1 (703) 983-7209 Email: susan@mitre.org URI: http://mitre.org/ Robert C. Durst The MITRE Corporation 7515 Colshire Drive McLean, VA 22102 US Phone: +1 (703) 983-7535 Email: durst@mitre.org URI: http://mitre.org/ Keith L. Scott The MITRE Corporation 7515 Colshire Drive McLean, VA 22102 US Phone: +1 (703) 983-6547 Email: kscott@mitre.org URI: http://mitre.org/ Symington, et al. Expires August 6, 2009 [Page 13]