DTN Research Group S. Symington Internet-Draft R. Durst Expires: October 6, 2006 K. Scott The MITRE Corporation April 4, 2006 Delay-Tolerant Networking Non-Custodial Multicast Extensions draft-irtf-dtnrg-bundle-multicast-noncustodial-00 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 October 6, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document defines the Bundle Protocol extensions and other mechanisms that may be required to enable a bundle node to support non-custodial multicast delivery of bundles within a Delay-Tolerant Network (DTN). This document lists all of the protocol extensions and mechanisms that a node must be capable of supporting in order for the node to be capable of supporting non-custodial multicast delivery regardless of the multicast routing protocol with which it is used. Symington, et al. Expires October 6, 2006 [Page 1] Internet-Draft DTN Non-Custodial Multicast Extensions April 2006 The exact profile of protocol extensions and other mechanisms that are required to support DTN multicast in any given situation depends on the multicast routing protocol being used and on the capabilities of the other nodes in the network--namely, whether they are all multicast-capable and are all participating in the same multicast routing protocol. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Related Documents . . . . . . . . . . . . . . . . . . . . 4 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 2. Mitigating the Impact of Status Reporting . . . . . . . . . . 6 3. Identifying the Previous Hop Node, and doing so Uniquely . . . 7 4. Tunneling Multicast Bundles Through Portions of the Network that do not Support the Multicast Routing Protocol Uniformly . . . . . . . . . . . . . . . . . . . . . . . . . . 9 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 6.1. Normative References . . . . . . . . . . . . . . . . . . . 11 6.2. Informative References . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 Intellectual Property and Copyright Statements . . . . . . . . . . 13 Symington, et al. Expires October 6, 2006 [Page 2] Internet-Draft DTN Non-Custodial Multicast Extensions April 2006 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 [1]. Multicasting will be an important capability in Delay-Tolerant Networks(DTNs) which, by definition, are stressed environments in which resources need to be used as efficiently as possible. Data transfer situations requiring a source that does not have multicast capability to transmit a bundle to multiple destinations can potentially be very wasteful of network bandwidth and persistent storage. The extent of the inefficiency depends on the number of destinations, their distribution throughout the DTN, and the amount of disconnection the network suffers [8]. This document defines the Bundle Protocol extensions and other mechanisms that may be required to enable a bundle node to support non-custodial multicast delivery of bundles within a Delay-Tolerant Network (DTN). It lists all of the protocol extensions and other mechanisms that may be needed for enabling a source node to use the Bundle Protocol to transmit a bundle non-custodially to multiple destination nodes without having to originate a separate bundle for each destination node. It does not address the capabilities that would be required to support custodial transfer of multicast bundles. Many different multicast routing strategies may be used to support multicast distribution of bundles, from the use of flooding to the use of source-based trees. DTN multicasting is not intended to be restricted to use of a single routing protocol. On the contrary, DTN multicasting is designed to support a variety of routing approaches, so that whatever multicast routing strategy best meets the requirements of the application may be used. The exact profile of protocol extensions and other mechanisms that are required to support DTN multicast in any given situation depends on the multicast routing protocol being used and on the capabilities of the other nodes in the network--namely, whether they are all multicast-capable and are all participating in the same multicast routing protocol. The multicast routing protocol that is being used establishes a set of prerequisite capabilities that each bundle node must support in order for the bundle node to be able to support multicast delivery when used with that routing protocol. Although the routing protocol will establish this set of pre- requisite capabilities, there is currently no mechanism for enabling the routing protocol to inform a node of the capabilities that it requires of it, nor is there a mechanism for enabling a node to inform a routing protocol whether its required capabilities are Symington, et al. Expires October 6, 2006 [Page 3] Internet-Draft DTN Non-Custodial Multicast Extensions April 2006 implemented. Ideally, there would be some sort of information exchange established such that, for example, if a node does not implement a given routing protocol's required prerequisites for supporting multicast, an error notice would be generated when the routing protocol is loaded. If a multicast-capable node supports the profile of protocol extensions and mechanisms required for use with a given multicast routing protocol, then the node may be used to support non-custodial multicast delivery when it is used with that routing protocol. For a node to be considered generally non-custodial multicast-capable, however, meaning that the node is capable of supporting non-custodial multicast delivery regardless of the multicast routing protocol with which it is used, the node must be capable of supporting all of the protocol extensions and mechanisms listed in this document. The capabilities described in this document are OPTIONAL for deployment with the Bundle Protocol. Bundle Protocol implementations claiming to support general (multicast routing protocol-agile) non- custodial multicast delivery MUST be capable of supporting all protocol extensions and mechanisms described in this document. 1.1. Related Documents This document is best read and understood within the context of the following other DTN documents: - The Delay-Tolerant Network Architecture [6] defines the architecture for delay-tolerant networks, but only briefly discusses multicasting. - The Bundle Protocol Specification [2] defines the format and processing of the headers used to implement the basic bundle protocol. This document does not explicitly discuss DTN multicast, but it does define two mechanisms that are important for supporting multicast: the concept of endpoints that contain multiple nodes, all of which are intended recipients of a bundle, and the concept that a node may both deliver and forward a bundle and, when forwarding a bundle, may forward it to multiple next- hop nodes. The Bundle Protocol also defines custody transfer procedures that apply to bundles that are destined for singleton endpoints; these custody transfer procedures, however, do not apply to multicast bundles. Symington, et al. Expires October 6, 2006 [Page 4] Internet-Draft DTN Non-Custodial Multicast Extensions April 2006 - Delay-Tolerant Networking Previous Hop Extension Header [3] defines the format and processing of the Previous Hop Endpoint ID Extension Header, which is applied to a bundle by a forwarding node in order to inform the next-hop receiving node of the forwarding node's endpoint ID (EID). - Delay-Tolerant Networking Bundle-in-Bundle Encapsulation [4] defines the format and processing of the Bundle-in-Bundle Encapsulation Administrative Record, which is used to enable the transmission of one or more bundles encapsulated in another bundle as part of that bundle's payload. - Delay-Tolerant Networking Security Overview [7] provides an informative overview of the security requirements and mechanisms considered for DTN security, discussing the protection options and describing reasons why specific mechanisms were (or were not) chosen. - Bundle Security Protocol [5] defines the Bundle Protocol extensions and other mechanisms for providing security protection within DTNs, in particular data integrity and confidentiality services. 1.2. Terminology Multicast Endpoint - an endpoint that may contain multiple bundle nodes and that has as its minimum reception group (see the Bundle Protocol [2]) all of the bundle nodes that are registered in that endpoint. Multicast Bundle - a Bundle that has a multicast endpoint as its destination. Node ID - Strictly speaking, nodes do not have IDs. Endpoints are sets of nodes, and endpoints, not nodes, have IDs. This document relaxes this terminology somewhat in the case of singleton endpoints, which are endpoints that have exactly one node in them. In this case, we refer to the endpoint ID of this singleton endpoint as the "node ID" of the node that is in the endpoint. According to the Bundle Protocol [2], every node must be a member of at least one singleton endpoint, but a node may also be a member of multiple endpoints (singleton or otherwise). Therefore, a given node always has at least one node ID, and it may have multiple node IDs. Symington, et al. Expires October 6, 2006 [Page 5] Internet-Draft DTN Non-Custodial Multicast Extensions April 2006 2. Mitigating the Impact of Status Reporting To mitigate the risk of status report implosion at the report-to endpoint, local policy for multicast-capable nodes MUST be able to override all requests for status reporting. Local policy MUST also be capable of causing the bundle node to reset the Status Report Request Flags for multicast bundles before the bundles are forwarded. That is, if dictated by local policy, the bundle protocol agent at a multicast-capable node MUST NOT generate specified types of status reports; if dictated by local policy, the bundle protocol agent at a multicast-capable node MUST reset the specified Status Report Request Flags to zero. Nodes that are not capable of having local policy override and reset bundle status report requests leave the report-to endpoints of multicast bundles vulnerable to implosion caused by the possible generation of an inordinately large number of status reports. A node MUST meet this requirement in order to support multicast delivery regardless of the routing protocol being used. Symington, et al. Expires October 6, 2006 [Page 6] Internet-Draft DTN Non-Custodial Multicast Extensions April 2006 3. Identifying the Previous Hop Node, and doing so Uniquely If the routing protocol being used to support multicast delivery of bundles requires each forwarding node to provide its EID to the next- hop receiving node (i.e., so that the receiving node can determine whether the forwarding node is on the reverse path back to the bundle's source), then every node participating in the delivery of a multicast bundle must support the capabilities defined in the Delay- Tolerant Networking Previous Hop Extension Header specification [3]. If the routing protocol being used to support multicast delivery of bundles requires each forwarding node to provide its EID to the next- hop receiving node, then the Previous Hop EID Header [3] MUST be included with every multicast bundle that is forwarded from one node to another, unless there is a mechanism whereby the previous hop EID can reasonably be inferred. Examples of when a previous hop EID may be able to be inferred include: - Scheduler policy - every day at 2:00 PM a node receives a transmission from a given other node - A physical wire connects two nodes; all bundles received on that wire may be inferred to come from the same node - A node is forwarding bundles to another node using a stateful convergence layer, and a previous-hop EID header was included with a bundle that was forwarded earlier from the forwarding convergence layer service access point to the receiving convergence layer service access point. It can be inferred that all subsequent bundles are being forwarded from the same forwarding node until a new Previous Hop EID header is included in a bundle to indicate otherwise. If the routing protocol being used to support multicast delivery of bundles requires each forwarding node to provide its EID to the next- hop receiving node, then when multicast bundles are encapsulated in unicast bundles (see [4]) for the purpose of tunneling multicast bundles across non-multicast-capable portions of the DTN, a Previous Hop EID header MUST be included as part of the encapsulated multicast bundle. The EID placed in the Previous Hop EID header MUST be the EID of the encapsulating node. If the routing protocol being used to support multicast delivery of bundles requires each forwarding node to provide its EID to the next- hop receiving node, then there is also a requirement that each node being used to support multicast MUST have a unique, designated node ID that is the only EID for that node that is used to support multicast routing. In particular, that EID is the only EID for that Symington, et al. Expires October 6, 2006 [Page 7] Internet-Draft DTN Non-Custodial Multicast Extensions April 2006 node that: -other nodes use to identify that node when making forwarding decisions, and -that node will ever put in a Previous HOP EID header that it creates. Unique identifiability is required because a given node may be identified by more than one endpoint ID. If the node provides one of these EIDs in a Previous Hop EID header of a bundle that it forwards but this EID is different from the EID that is used at the receiving node to identify the forwarding node, the receiving node may not know that the two different EIDs identify the same node. If the receiving node is using an RPF check [9] to determine whether or not to forward the multicast bundle, for example, the EID in the Previous Hop EID header may not match the EID that the receiving node has listed as identifying the next-hop node on the reverse path to the source. Because these EIDs do not match, the receiving node would erroneously drop the bundle when in fact the bundle should not be dropped because the node from which the bundle was received is in fact the next-hop node on the reverse path to the source. Requiring that a single, designated EID be used to uniquely identify each node for purposes of supporting multicast will prevent this problem. Unique identifiability ensures that when an RPF check is used, for example, if a node receives a multicast bundle with a Previous Hop EID Header and the EID in that header is not the same as the EID that the receiving node has listed as identifying the next-hop node on the reverse path to the source, the receiving node can drop the bundle because the bundle was not received from an upstream node in the multicast distribution tree. Note that RPF forwarding makes use of the existing unicast routing information to determine the upstream neighbors of a node. Unicast routing information is thereby used to support multicast delivery. Therefore, in RPF-check-based and other routing strategies that involve using unicast routing information to support multicast delivery, the requirement for unique identifiability of each multicast-capable node applies to the EIDs that are used to identify nodes for purposes of making unicast routing decisions as well as those EIDs used for making multicast routing decisions. Symington, et al. Expires October 6, 2006 [Page 8] Internet-Draft DTN Non-Custodial Multicast Extensions April 2006 4. Tunneling Multicast Bundles Through Portions of the Network that do not Support the Multicast Routing Protocol Uniformly Given that implementation of the bundle protocol extensions to support non-custodial multicast delivery is optional, and also that in order to support multicast delivery, each node participating in a multicast delivery tree must be using the same multicast routing protocol as its adjacent nodes, a DTN could be comprised of some nodes that do support multicast delivery and some nodes that do not; or, a DTN could be comprised of nodes that all support multicast delivery, but only some of which are participating in the same multicast routing protocol as their adjacent nodes. In order for multicast delivery to be supported in such network that does not provide homogenous support for multicast (assuming a multicast routing protocol is being used rather than some sort of general flooding algorithm or static routing), multicast routing must be defined as an overlay. In order to forward a multicast bundle from one multicast-capable node that is participating in a multicast routing protocol, via an adjacent node that is not participating in the same multicast routing protocol, to a third node (without using static or default routes), the forwarding and receiving nodes MUST implement DTN Bundle-in-Bundle Encapsulation as defined in [4]. If a flooding protocol is being used to support multicast delivery, then all nodes participate in this flooding protocol and the ability to perform bundle-in-bundle encapsulation is not a requirement for supporting multicast in this situation If a non-flooding multicast routing protocol is being used and all nodes in the DTN participate in the same multicast routing protocol as their adjacent nodes, then there is no need to tunnel multicast bundles over any portion of the DTN, so the ability to perform bundle-in-bundle encapsulation is not a requirement for supporting multicast in this situation either. Bundle-in-bundle encapsulation is only a requirement to support multicast delivery in a network in which a non-flooding multicast routing protocol is being used and some of the nodes do not participate in the same multicast routing protocol as their adjacent nodes. Symington, et al. Expires October 6, 2006 [Page 9] Internet-Draft DTN Non-Custodial Multicast Extensions April 2006 5. Security Considerations As mentioned earlier, there are two documents that pertain to providing security within DTN. Both of these documents, however, address the security of the Bundle Protocol when used to transmit bundles from a single source to a single destination. They do not explicitly address the security of multicast delivery within the bundle protocol. This document makes normative references to two other DTN specifications [3] [4]. The security considerations that apply to those specifications also apply to this one. Failure to use a single, designated EID for each node when using the Previous Hope Endpoint ID header to support multicast delivery could compromise multicast routing, making the network vulnerable to denial of service attacks. The Bundle Authentication Header (BAH) may be used to provide hop-by- hop security during the delivery of a multicast bundle. It is worth noting, however, that if the security destination field is included in a BAH that is inserted into a multicast bundle by a node that will forward the bundle to more than one neighboring next-hop node, the security destination field in the BAH will have a different value for each neighbor to which the bundle will be forwarded. Therefore, the security result in each of these BAHs must be calculated separately, with a different BAH being forwarded to each next-hop node. The Confidentiality Header (CH) and the Payload Security Header (PSH) may be used to provide end-to-end security for multicast bundles, but ideally they could benefit from some adaptation to make them better- suited to provide protection between a single source and multiple destinations. The PSH could be used to provide end-to-end authentication as it is defined now, providing that the PSH-dest field is not included in the PSH header and either a symmetric key is shared by the source and all destinations or an asymmetric ciphersuite is used to enable multiple destination nodes to validate the PSH security result. Similarly, the CH could be used to provide end-to-end confidentiality, providing that the CH-dest field is not included in the CH header and either a symmetric key is shared by the source and all destinations or an asymmetric ciphersuite is used to enable multiple destination nodes to decrypt the encrypted parts of the bundle. Ciphersuites to be used with the PSH and CH that are tailored to protecting multicast bundles will need to be defined. This document does not consider the security aspects of enabling or preventing a node from registering with a particular multicast endpoint ID, and thereby joining and leaving a particular multicast group, although we acknowledge that security considerations regarding joining and leaving groups are present and significant. Symington, et al. Expires October 6, 2006 [Page 10] Internet-Draft DTN Non-Custodial Multicast Extensions April 2006 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", draft-irtf-dtnrg-bundle-spec-04.txt , December 2005. [3] Symington, S., Durst, R., and K. Scott, "Delay-Tolerant Networking Previous Hop Extension Header", draft-irtf-dtnrg-bundle-previous-hop-extension-header-00.txt , April 2006. [4] Symington, S., Durst, R., and K. Scott, "Delay-Tolerant Networking Bundle-in-Bundle Encapsulation", draft-irtf-dtnrg-bundle-encapsulation-00.txt , April 2006. [5] Symington, S., Farrell, S., and H. Weiss, "Bundle Security Protocol Specification", draft-irtf-dtnrg-bundle-security-01.txt, work-in-progress, March 2006. 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", draft-irtf-dtnrg-arch-04.txt , December 2005, . [7] Farrell, S., Symington, S., and H. Weiss, "Delay-Tolerant Network Security Overview", draft-irtf-dtnrg-sec-overview-01.txt , March 2005. [8] Zhao, W., Ammar, M., and E. Zegura, "Multicasting in Delay Tolerant Networks: Semantic Models and Routing Algorithms", August 2005. [9] Fenner, B. and D. Meyer, "Multicast Source Discovery Protocol (MSDP)", RFC 3618, October 2003. Symington, et al. Expires October 6, 2006 [Page 11] Internet-Draft DTN Non-Custodial Multicast Extensions April 2006 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 October 6, 2006 [Page 12] Internet-Draft DTN Non-Custodial Multicast Extensions April 2006 Intellectual Property Statement 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. Disclaimer of Validity 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 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. Copyright Statement Copyright (C) The Internet Society (2006). 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Symington, et al. Expires October 6, 2006 [Page 13]