DTN Research Group S. Symington Internet-Draft R. Durst Intended status: Experimental K. Scott Expires: May 4, 2009 The MITRE Corporation October 31, 2008 Delay-Tolerant Networking Bundle-in-Bundle Encapsulation draft-irtf-dtnrg-bundle-encapsulation-04 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of 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 May 4, 2009. Copyright Notice Copyright (C) The IETF Trust (2008). Symington, et al. Expires May 4, 2009 [Page 1] Internet-Draft DTN Bundle-in-Bundle Encapsulation October 2008 Abstract This document defines an extension block that may be used with the Bundle Protocol [2] within the context of a Delay-Tolerant Network architecture [6]. When included as part of a given bundle B, this extension block, called a Bundle-in-Bundle Encapsulation Block, indicates that one or more other bundles have been placed inside of the payload field of B's Bundle Payload Block according to the format defined in this document. Hence, the Bundle-in-Bundle Encapsulation Block provides a mechanism for bundle-in-bundle encapsulation by indicating that one or more bundles are being transmitted as the payload of a bundle. This extension block is expected to be of general utility in DTN. It may be used, for example, to encapsulate a multicast bundle inside of a unicast bundle, or to encapsulate a bundle with one type of security protection inside of a bundle with a different type of security protection. This document defines the format and processing of this new Bundle-in-Bundle Encapsulation Block and the contents of the Bundle Payload Block accompanying it. Symington, et al. Expires May 4, 2009 [Page 2] Internet-Draft DTN Bundle-in-Bundle Encapsulation October 2008 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Bundle-in-Bundle Encapsulation Block Format . . . . . . . . . 5 3. Bundle-in-Bundle Encapsulation Block Processing . . . . . . . 7 3.1. Generation and Transmission of an Encapsulating Bundle . . 7 3.2. Receipt and Processing of an Encapsulating Bundle . . . . 9 4. Security Considerations . . . . . . . . . . . . . . . . . . . 11 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 6.1. Normative References . . . . . . . . . . . . . . . . . . . 14 6.2. Informative References . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 Intellectual Property and Copyright Statements . . . . . . . . . . 16 Symington, et al. Expires May 4, 2009 [Page 3] Internet-Draft DTN Bundle-in-Bundle Encapsulation October 2008 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 [1]. The DTN bundle protocol [2] defines the bundle as its protocol data unit. A bundle consists of a primary bundle block followed by at least one other type of bundle block. The Bundle Protocol currently defines a single other type of bundle block, called a Bundle Payload block. This document defines an additional, optional, bundle block called a Bundle-in-Bundle Encapsulation Block. The presence of this Bundle-in-Bundle Encapsulation Block in a bundle B indicates that one or more other bundles have been placed inside of the payload field of B's Bundle Payload Block according to the format defined in this document. Hence, the Bundle-in-Bundle Encapsulation Block provides a mechanism for bundle-in-bundle encapsulation by indicating that one or more bundles are being transmitted as the payload of a bundle. This extension block is expected to be of general utility in DTN. It may be used, for example, to encapsulate a multicast bundle inside of a unicast bundle, or to encapsulate a bundle with one type of security protection inside of a bundle with a different type of security protection. This document defines the format and processing of this new Bundle-in-Bundle Encapsulation Block and the contents of the Bundle Payload Block accompanying it. The capabilities described in this document are OPTIONAL for deployment with the Bundle Protocol. Bundle Protocol implementations claiming to support bundle-in-bundle encapsulation MUST be capable of both: -generating and transmitting bundles containing Bundle-in-Bundle Encapsulation Blocks, and -receiving and processing bundles containing Bundle-in-Bundle Encapsulation Blocks as defined in this document. Symington, et al. Expires May 4, 2009 [Page 4] Internet-Draft DTN Bundle-in-Bundle Encapsulation October 2008 2. Bundle-in-Bundle Encapsulation Block Format The Bundle-in-Bundle Encapsulation Block uses the Canonical Bundle Block Format as defined in the bundle protocol [2]. That is, it is comprised of the following elements: -Block-type code (1 byte) - defined as in all bundle protocol blocks except the primary bundle block (as described in the Bundle Protocol). The block type code for the Bundle-in-Bundle Encapsulation Block is 0x10. -Block processing control flags (SDNV) - defined as in all bundle protocol blocks except the primary bundle block. SDNV encoding is described in the Bundle Protocol. Constraints on the values of the Block Processing Control Flags are as follows: -The "Delete bundle if block can't be processed" flag MUST NOT be set. -The "Discard block if it can't be processed" flag MUST NOT be set. -The "Block contains and EID-reference field" flag MUST NOT be set. -EID references (optional) - This composite field defined in the bundle protocol MUST NOT be present. -Block data length (SDNV) - defined as in all bundle protocol blocks except the primary bundle block. SDNV encoding is described in the bundle protocol. If the value of the SDNV in this field is 0, there are no remaining fields in the block, which indicates that exactly one bundle is present in the payload field of the bundle's Bundle Payload Block. -Block-type-specific data fields as follows: - Number of Encapsulated Bundles field (SDNV) (optional) - indicates the number N of bundles that are present in the payload field of the bundle's Bundle Payload Block, where N MUST be greater than 1. (If only 1 bundle is present in the payload field of the Bundle Payload Block, the Number of Encapsulated Bundles field MUST NOT be present in the Bundle- in-Bundle Encapsulation block.) - 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 payload field of the Bundle Payload Symington, et al. Expires May 4, 2009 [Page 5] Internet-Draft DTN Bundle-in-Bundle Encapsulation October 2008 Block after the first bundle in that field. (The offset of the first bundle in the Bundle Payload Block is understood to be 0.) (If only 1 bundle is present in the payload field of the Bundle Payload Block, the Bundle Offsets List field MUST NOT be present in the Bundle-in-Bundle Encapsulation block.) The format of the bundle-in-bundle encapsulation block is as follows: Bundle-in-Bundle Encapsulation Block Format: +-----+------+------+------------------------+-----------------+ |Type |Flags |Len | Number of Encapsulated | Bundle Offsets | | |(SDNV)|(SDNV)| Bundles(SDNV)(opt.) | List (opt.) | +-----+------+------+------------------------+-----------------+ Figure 1 Symington, et al. Expires May 4, 2009 [Page 6] Internet-Draft DTN Bundle-in-Bundle Encapsulation October 2008 3. Bundle-in-Bundle Encapsulation Block Processing Instead of forwarding one or more bundles, a node MAY, according to local policy, encapsulate those bundle(s) by generating a new (encapsulating) bundle, placing the bundle(s) to be encapsulated into the payload field of the new bundle's Bundle Payload Block, creating a Bundle-in-Bundle Encapsulation block for the new bundle that includes the Number of Encapsulated Bundles (if greater than 1) and the offsets of the start of each encapsulated bundle (after the first bundle) in the payload field (if more than one bundle is encapsulated), and forwarding this new encapsulating bundle. The details of the processing steps that must occur and the values that must be placed in the fields of various blocks of the encapsulating bundle are described in section 3.1 below. Upon receipt of a bundle that has a Bundle-in-Bundle Encapsulation block at a node that is a member of the destination EID of the bundle, the bundle is delivered to the application-specific element of the destination node that is responsible for bundle de- encapsulation. This application-specific element extracts the bundle(s) from the encapsulating bundle's payload field and directs the bundle protocol agent to process each of these bundle(s) as if it had just been received from another node. Again, the details of the processing steps that must occur are described in section 3.2 below. 3.1. Generation and Transmission of an Encapsulating Bundle To take a bundle (or bundles) and forward this bundle(s) within the payload field of another bundle, a node must perform the following steps: The node SHALL process the bundle(s) for forwarding as if it were going to simply forward the bundle(s). Some of the processing steps include, for example: -Processing the security extension blocks [5] (if any) contained in the bundle, as appropriate (e.g., verifying the security result in the Bundle Authentication Block and deleting this block, verifying the security result in the Payload Security Block if the node is the security destination, etc.). -Deleting all Previous Hop Insertion Blocks from the bundle (if any). -If the bundle should (according to local policy) be given one or more Previous Hop Insertion Blocks [3], these blocks SHALL be inserted into the bundle. Symington, et al. Expires May 4, 2009 [Page 7] Internet-Draft DTN Bundle-in-Bundle Encapsulation October 2008 -Processing the Metadata Extension Blocks [4] (if any) contained in the bundle, as appropriate. -If the bundle should be given one or more security extension blocks such as a Bundle Authentication, Payload Security, or Confidentiality Block, the appropriate security blocks SHALL be inserted into the bundle. If the bundle is given a BAB [5], 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 [3]. This EID must be present in the bundle 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). Next, the node's bundle protocol agent MUST direct the administrative element of the node's application agent to construct a new, encapsulating bundle. The bundle or bundles to be encapsulated MUST be placed in the payload field of the encapsulating bundle's Bundle Payload Block. The encapsulating bundle must be given a Bundle-in-Bundle Encapsulation Block. If more than one bundle has been placed in the encapsulating bundle's payload field, the Bundle-in-Bundle Encapsulation Block must have a Number of Encapsulated Bundles field that has as its value the number of bundles that have been placed in the encapsulating bundle's payload field and the Bundle-in-Bundle Encapsulation Block must have a Bundle Offsets List field that has as its value the list of offsets of each of the encapsulated bundles, after the first encapsulated bundle, in the payload field. If more than one bundle is to be placed in the encapsulating bundle's payload field, all of these bundles must have the same value for their "Custody transfer is requested" Bundle Processing Control Flag [2]. The value of the encapsulating bundle's "Custody transfer is requested" Bundle Processing Control Flag must be set to the same value as that of the bundle(s) to be encapsulated. The value of the destination EID in the new, encapsulating bundle MUST be set to an endpoint ID 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 node that created the encapsulating bundle is a member. Symington, et al. Expires May 4, 2009 [Page 8] Internet-Draft DTN Bundle-in-Bundle Encapsulation October 2008 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 encapsulating bundle's payload field. Other fields of this new, encapsulating bundle (remaining Bundle Processing Control Flag values, Block Length, Dictionary byte array, etc.) must be given appropriate values. Once this new, encapsulating bundle has been constructed, it SHALL be processed for forwarding (i.e., given security blocks, given a Previous Hop Insertion Block, given a Metadata Extension Block, etc. as appropriate) and then forwarded. Note that there is currently no Bundle Status Report Status Flag [2] 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. 3.2. Receipt and Processing of an Encapsulating Bundle Upon delivery of a bundle that has a Bundle-in-Bundle Encapsulation Block and, therefore, a payload field that consists of one or more encapsulated bundles, the application-specific element of the application agent of the node at which the bundle was delivered SHALL perform the following processing steps: Extract the encapsulated bundle(s) from the encapsulating bundle's payload field. Pass each of these de-encapsulated bundles in their entirety to the node's bundle protocol agent. Upon receipt of each of these de-encapsulated bundles, the bundle protocol agent SHALL process each bundle as if it had just been received from another node. It will not be possible for the bundle protocol agent to determine the EID of the forwarding node of these de-encapsulated bundles through implementation-specific means (such Symington, et al. Expires May 4, 2009 [Page 9] Internet-Draft DTN Bundle-in-Bundle Encapsulation October 2008 as from the convergence layer), because the forwarding node was the node that provided the bundle for encapsulation, not necessarily the node from which the encapsulating bundle was received. Therefore, if the EID of the forwarding 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 [3] or in the EID reference to the security-source of a BAB [5], if the bundle contains a BAB. Some of the processing steps that the bundle protocol agent SHALL perform include, for example: -Processing the security extension blocks [5] (if any) contained in the bundle, as appropriate (e.g., verifying the security result in the Bundle Authentication Block and deleting this block, verifying the security result in the Payload Security Block if the node is the security destination, etc.). -Deleting all Previous Hop Insertion Blocks from the bundle (if any). -Processing the Metadata Extension Blocks [4](if any) contained in the bundle, as appropriate. -The bundle protocol agent SHALL deliver the bundle, if appropriate. -The bundle protocol agent SHALL perform custody transfer and/or status reporting procedures on the bundle as directed by the bundle's custody transfer and status report request flags. -If the bundle should (according to local policy) be given one or more Previous Hop Insertion Blocks [3], these blocks SHALL be inserted into the bundle. -If the bundle should be given one or more security extension blocks such as a Bundle Authentication, Payload Security, or Confidentiality Block, the appropriate security blocks SHALL be inserted into the bundle. -The bundle protocol agent SHALL forward the bundle to all appropriate endpoints. Symington, et al. Expires May 4, 2009 [Page 10] Internet-Draft DTN Bundle-in-Bundle Encapsulation October 2008 4. Security Considerations There are two documents that pertain to providing security within the DTN Bundle Protocol: [5] and [7]. The mandatory BAB-HMAC ciphersuite defined in [5], because it uses the strict canonicalization algorithm that calculates a security result over all blocks in the bundle, can be used to detect changes that occur in the Bundle-in-Bundle Encapsulation Block while in transit between neighboring DTN nodes. The mandatory PIB-RSA-SHA256 ciphersuite defined in [5], however, cannot be used to detect changes that occur in the Bundle-in-Bundle Encapsulation block as it traverses multiple neighboring DTN nodes, because this ciphersuite uses the mutable canonicalization algorithm, which does not include the Bundle-in-Bundle Encapsulation Block among the blocks over which it calculates a security result. In order to ensure the end-to-end integrity of the Bundle-in-Bundle Encapsulation Block, the mutable canonicalization algorithm would need to be modified to include the Bundle-in-Bundle Encapsulation Block among those blocks included in the mutable canonicalization of the bundle. The mandatory PCB-RSA_AES128-PAYLOAD-PIB-PCB ciphersuite defined in [5] will encrypt the encapsulated bundle(s) because these are stored in the payload field and this ciphersuite encrypts the payload field. However, this ciphersuite will not encrypt the Bundle-in-Bundle Encapsulation Block in the encapsulating bundle, so, using the available mandatory confidentiality ciphersuite, there is no way to keep confidential the fact that the bundle is an encapsulating bundle or the information regarding the number of bundles encapsulated and their offsets. To provide confidentiality protection of this sort, a new ciphersuite for the Payload Confidentiality Block would have to be defined that includes protection of the Bundle-in-Bundle Encapsulation Block. 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 node. If a bundle with a BAB is encapsulated by one node and it is received and de-encapsulated by a non-neighboring node, the bundle protocol agent to which the de-encapsulated bundle is passed for processing must be capable of validating the security result in the BAB if its security policy requires such validation. Therefore, 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 Symington, et al. Expires May 4, 2009 [Page 11] Internet-Draft DTN Bundle-in-Bundle Encapsulation October 2008 bundle protocol agent to which the de-encapsulated bundle is passed to determine the EID of the forwarding node that inserted the BAB into the encapsulated bundle through implementation-specific means (such as from the convergence layer), if the EID of this forwarding node is not identified elsewhere in the encapsulated bundle (e.g. in the Previous Hop Insertion Block), this EID must be present in the security-source field of the BAB. Symington, et al. Expires May 4, 2009 [Page 12] Internet-Draft DTN Bundle-in-Bundle Encapsulation October 2008 5. IANA Considerations None at this time. If the bundle protocol becomes a standards track protocol, then we may want to consider having IANA establish a register of extension block types, of which the Bundle-in-Bundle Encapsulation Block would be one. Symington, et al. Expires May 4, 2009 [Page 13] Internet-Draft DTN Bundle-in-Bundle Encapsulation October 2008 6. References 6.1. Normative References [1] Bradner, S. and J. Reynolds, "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, October 1997. [2] Scott, K. and S. Burleigh, "Bundle Protocol Specification", RFC, 5050, November 2007. [3] Symington, S., "Delay-Tolerant Networking Previous Hop Insertion Block", draft-irtf-dtnrg-bundle-previous-hop-block-04.txt, work- in-progress, September 2008. [4] Symington, S., "Delay-Tolerant Networking Metadata Extension Block", draft-irtf-dtnrg-bundle-metadata-block-00.txt, work-in-progress, September 2008. [5] 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. 6.2. Informative References [6] 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. [7] Farrell, S., Symington, S., Weiss, H., and P. Lovell, "Delay- Tolerant Network Security Overview", draft-irtf-dtnrg-sec-overview-05.txt, work-in-progress, November 2008. Symington, et al. Expires May 4, 2009 [Page 14] Internet-Draft DTN Bundle-in-Bundle Encapsulation October 2008 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 May 4, 2009 [Page 15] Internet-Draft DTN Bundle-in-Bundle Encapsulation October 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Symington, et al. Expires May 4, 2009 [Page 16]