Network Working Group W. Eddy Internet-Draft Verizon Federal Network Systems Expires: November 26, 2006 May 25, 2006 Architectural Considerations for the use of Endpoint Identifiers in Delay Tolerant Networking draft-eddy-dtnrg-eid-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 November 26, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract The architecture for Delay Tolerant Networking includes a type of address called an Endpoint Identifier. This document describes some of the remaining issues regarding Endpoint Indentifiers, and how they can be configured and used in bundle forwarding. These either imply directions for future work or highlight clarifications that should be made in the current architecture and protocol documents. Eddy Expires November 26, 2006 [Page 1] Internet-Draft EIDs in DTN May 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. EID Basics . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Bundling Node Configuration . . . . . . . . . . . . . . . . . 5 4. Application Registration . . . . . . . . . . . . . . . . . . . 6 5. Bundle Processing Rules . . . . . . . . . . . . . . . . . . . 8 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 7. Outstanding Issues . . . . . . . . . . . . . . . . . . . . . . 10 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 10. Informative References . . . . . . . . . . . . . . . . . . . 12 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 13 Intellectual Property and Copyright Statements . . . . . . . . 14 Eddy Expires November 26, 2006 [Page 2] Internet-Draft EIDs in DTN May 2006 1. Introduction The Delay Tolerant Networking (DTN) architecture is centered on the concept of "bundling" application data, and then exchanging bundles between nodes [CBH+06]. Endpoint Identifiers (EIDs) are variable- length strings used to refer to nodes that send, receive, or forward bundles. An EID may refer to one or more nodes, and an individual node may have more than one EID. Conceptually, EIDs are well motivated and explained in the DTN architecture description, and they are used in several places within the DTN Bundle Protocol header [SB05]. However, there is no document that explains how EIDs are assigned to nodes, how applications register with bundling agents, or how forwarding decisions can be made based on EIDs. There have been mailing list discussions on these topics, and the DTN2 Reference Implementation (RI) of the Bundle Protocol uses certain rules (we refer to the DTN2 RI version 2.2.0 in this document). In this document, we summarize some of the mailing list threads regarding these subjects, and describe how the DTN2 code operates. The configuration and processing rules contained in this document are not necessarily final or normative; this is only an informational snapshot of current thinking and practices in the DTNRG. Some of the issues brought to light in this document may cause future iterations that are considerably different. Section 2 contains a basic description of EIDs based on the DTN architecture and DTN2 RI. Some ways that a DTN bundle agent might configure an EID are discussed in Section 3, and methods for applications to register EIDs are described in Section 4. Security implications of EID usage are explained in Section 6. Finally, several outstanding issues that have been uncovered are listed in Section 7. Eddy Expires November 26, 2006 [Page 3] Internet-Draft EIDs in DTN May 2006 2. EID Basics The Uniform Resource Identifier (URI) standard [RFC3986] has been selected as the format for representing EIDs in the DTN architecture. URIs are used in several Internet protocols. For the purposes of the DTN protocols, the URI syntax is described as an EID scheme identifier followed by a scheme specific part (SSP). This allows multiple naming conventions (schemes) to be used in conjunction with the basic DTN protocols. The current DTN specifications do not fully define the use of any EID schemes. Interoperability between nodes using different schemes may be possible, but exact mechanisms for this have also not been described at this time. The use of EIDs has evolved from early DTN work that used the notion of regions. Each node address identified a region, and contained a portion which was unique within that region, but with no other restrictions on formating [CBH+03]. This is similar in principle to the EID definition, since assignment of EID schemes will be regulated by IANA, however a notable difference is that there are no stipulations in the current DTN architecture that SSPs be unique within a scheme. EIDs may be of unicast, anycast, or multicast types. The architecture states minimum reception group (MRG) of an EID can be determined by a node using the EID itself. This is not very clear in the current architecture. The way EIDs have been defined, it is more correct to say that at least "some" node can determine the MRG of an EID, rather than "a" node, which would seem to imply that any node could resolve an EID into an MRG. This clearly is not the case since there is no guarantee that every node even understands the EID scheme. The "dtn" EID scheme is discussed briefly in the current documentation, but its SSP and usage are not. The only concrete data on this scheme is that the special "none" SSP is set aside. The DTN2 RI classifies valid "dtn" bundle agent SSPs as consisting of alphanumeric characters, underscores, dashes, and periods. To identify applications, "service tags" are appended to the bundle agent SSPs. This does not seem to be driven by the bundle protocol specification or DTN architecture documents, although it certainly works well for the purposes of near-term experimentation and demonstration. The DTN2 RI also supports an "eth" scheme where the SSP is an Ethernet MAC address represented in a certain format. Eddy Expires November 26, 2006 [Page 4] Internet-Draft EIDs in DTN May 2006 3. Bundling Node Configuration The DTN2 RI uses a configuration file directive to set the local EID of a bundling agent. The default action is to use the "dtn" scheme, and create an EID of the form "hostname.dtn", where the "hostname" portion is substituted with the host operating system's configured hostname. The DTN specification documents do not codify that this is how EIDs in the "dtn" scheme are to be formatted or constructed. This method works well for demonstration purposes and small-scale deployments, but does not provide any expectation of uniqueness. Since autoconfiguration methods that guarantee global uniqueness may be difficult to make delay-insensitive, in order to be useful for small-scale experimentation and deployments in the short-term, the "dtn" scheme should probably be defined to preclude any such expectations. It should be encouraged that other schemes be developed with allow for uniqueness and that these be used in real- world deployments, outside of laboratory or demonstration use. One simple way to provide uniqueness is for bundle agents to be assigned EIDs from a central authority, similar to the way that DHCP assigns IP addresses, however pre-arranged manual assignment and configuration may be required in some DTN scenarios due to high- delays. If DTN bundling agents become used in multiple contexts, it is possible that certain agents may end up bridging DTNs that are not commonly administered. This could cause unforeseen issues if the DTNRG does not produce naming schemes that yield some expectation of uniqueness in a self-configured EID, or a guarantee of uniqueness in an assigned EID. Designing multiple naming schemes with different characteristics and use cases should be a primary focus area of the DTNRG's future efforts, as well as more fully explaining the intended format and use of the "dtn" scheme. In addition to uniqueness, another consideration in defining naming schemes is route aggregation. When routing protocols are adopted for DTNs, in order to limit the size of advertisements, memory required to hold tables, time to search tables, and power draw from all of these factors, EID SSP conventions should allow for aggregation in some way. Otherwise the scale and scope of DTNs might be artificially limited by the naming schemes available. Hierarchically structured EIDs are one means of acheiving aggregatability. EID schemes derived from fully-qualified domain names and/or IP addresses could serve as examples. Eddy Expires November 26, 2006 [Page 5] Internet-Draft EIDs in DTN May 2006 4. Application Registration The present architecture document is unclear on how exactly applications interface with bundling agents. It is stated that applications express an interest in receiving data for particular EIDs and send data to particular EIDs, but it is not stated whether portions of the EID SSP should identify applications (in addition to nodes), or whether the SSP merely identifies a node, and some other multiplexing and demultiplexing is used to deliver the correct data to the correct applications. This is a point that should be clarified, although the answer is fairly obvious based on the protocol specifications. One other point of clarification regards whether applications construct their own EIDs or are assigned EIDs by the bundle agent as part of the registration proceedure. Another cloudy topic is whether an application can register an EID with a bundle agent that does not understand the scheme portion of the requested EID. In the DTN2 RI, and the "dtnping" application as an example, node EIDs are constructed by applications themselves appending their a string consisting of the application name and operating system process ID to the bundle agent's EID. Registration of this application EID is requested of the bundle agent, and can either pass or fail. Before the application closes, it requests that the registration be closed. The topic of closing EID registrations is important, since applications may cease running without knowledge of the bundling agent. This is especially and issue when applications and bundling agents are not co-located on the same physical node, since network connectivity is assumed to be dynamic in DTNs. An application SHOULD try to reliably close registrations, and a bundling agent SHOULD have a way of polling existing registrations for liveliness and reaping them as deemed appropriate for specific environments. In some situations this will be more of an issue than in others, due to particular resource tradeoffs between persistent memory utilization, power and bandwidth needed to transmit and respond to registration keep-alives, etc. Application registration presents another interesting problem in that bundles must be addressed to remote application instances. Without naming schemes that allow for either wildcarding or indirection, it will be difficult to efficiently send data to remote peer application instances. In traditional Internet transports, this problem is reduced by the use of "well-known" port numbers, so DTN naming schemes may consider providing "well-known" SSP suffixes to help refer to application instances, along with other demultiplexing Eddy Expires November 26, 2006 [Page 6] Internet-Draft EIDs in DTN May 2006 tokens. Eddy Expires November 26, 2006 [Page 7] Internet-Draft EIDs in DTN May 2006 5. Bundle Processing Rules For the most part, the bundling protocol specification contains only a description of the bundle format and some rules for validity of bundles. Specifically, it does not specify (nor does any companion document, at this time) rules for a bundling agend to configure its own EID or make forwarding decisions regarding incoming bundles based on their destination EIDs. Of course, these are ancillary to the protocols wire-format and can be specified elsewhere, as has been done for IP. Nevertheless, these are holes that require filling to complete the DTN architecture. A natural set of processing rules for incoming bundles starts with ascertaining whether the destination EID scheme is understood by the bundle agent. If the destination EID is not understood, processing can no longer continue, but the action that should be taken is unclear. Should a failure report be sent back to the report-to EID? What if the reply-to EID's scheme is not understood? Perhaps, as a fall-back the bundle should be dropped. Or maybe it should be placed in storage until it can be handed off to either another agent (for instance, via a "default" route). Should support for the destination EID be evaluated before accepting custody of the bundle? Assuming the EID scheme is recognized and understood locally, there are still other failure modes when decoding the SSP. For instance, what if the SSP is malformed with respect to what the bundle agent thinks that the EID scheme rules are? This could arise if EID scheme definitions evolve in non-forwards or backwards-compatible ways. Should a similar action be taken in this case as if the EID scheme itself is not locally supported, or is a different response warranted? Should the SSP be parsed and evaluated before accepting bundle custody? There is a related case of what should be done when the SSP can be parsed, but for some other reason it is non-routable. For instance, if the SSP indicated an IPv4 private address space and the local bundle agent did not have a convergence layer adaptor capable of reaching that address space. Again, it should be considered whether this type of error results in behavior similar to other failures we have listed, or whether different actions are desirable. This may even require evaluation on a per-scheme or per-convergence layer basis. Eddy Expires November 26, 2006 [Page 8] Internet-Draft EIDs in DTN May 2006 6. Security Considerations The security considerations regarding EIDs are very similar to those regarding IP addreses as described in the context of routing and neighbor discover protocols [BMY04] [RFC3756]. The security threats are more relevent to the actual forwarding of bundles and routing exchanges that determine later forwarding decisions than the more general mechanics of how names are assigned and used. Fully exploring these issues and providing solutions is outside the context of this document. The security overview document [FSW06] describes a number of open issues in DTN security, some of which are related to naming and addressing. Eddy Expires November 26, 2006 [Page 9] Internet-Draft EIDs in DTN May 2006 7. Outstanding Issues In this document, we have identified a number of outstanding issues that are unclear in the DTN architecture, as currently described: o Should a base EID scheme be defined, perhaps utilizing the "dtn" identifier? This does not mean that all EIDs would use this scheme and would not prevent the definition and use of other schemes, but it would provide a basis for interoperability between differing implementations without parties pre-arranging EID rules outside of the specification documents. The use of hostnames in the DTN2 RI does not seem fully appropriate for this purpose. An understanding of what would be desirable in a minimally-supported EID scheme could be helpful, along the lines of work done in the NSRG [LD03]. o What are some methods that assignment and configuration of SSPs can be performed within various schemes in a way that is both collision-resistant and not prone to breakdown under high delay (among other typical factors in DTNs). o Should the function of mapping EIDs into MRGs be clarified to only be required to be possible by at least one node (identified as part of the EID), or by all nodes that can parse the EID scheme? This affects forwarding decisions o Does registration necessarily entail obtaining an extended version of the bundling agent's EID? Does an application request some portion of its EID, or is it fully assigned? Does a bundling node have to know how to parse all the schemes of application EIDs registered with it? o Do more formal guidelines regarding the removal, closing, and expiration of registrations need to be drafted? What are the security implications? o Exactly which operations with regards to parsing and resolving the various EIDs contained in a bundle must take place before accepting custody of the bundle? o What failure modes should a bundle agent be configured with in order to handle cases where it receives bundles with EID schemes or EID SSPs that it does not understand or is not capable of reaching even indirectly (e.g. IPv4 private address space from a public router)? Does the architecture need to define this, or what will be the result if different implementations support different behaviors in these types of failure modes? Eddy Expires November 26, 2006 [Page 10] Internet-Draft EIDs in DTN May 2006 8. IANA Considerations This document has no IANA considerations. Eddy Expires November 26, 2006 [Page 11] Internet-Draft EIDs in DTN May 2006 9. Acknowledgements Many others have participated in the DTNRG discussions on naming and contributed to the DTN2 RI. This document is only a synopsis of their work and conversations. Work on this document was performed at NASA's Glenn Research Center, in support of the NASA Space Communications Architecture Working Group (SCAWG), and the FAA/Eurocontrol Future Communications Study (FCS). 10. Informative References [BMY04] Barbir, A., Murphy, S., and Y. Yang, "Generic Threats to Routing Protocols", draft-ietf-rpsec-routing-threats-07 (work in progress), October 2004. [CBH+03] 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-00 (expired), March 2003. [CBH+06] 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-05 (work in progress), March 2006. [FSW06] Farrell, S., Symington, S., and H. Weiss, "Delay-Tolerant Networking Security Overview", draft-irtf-dtnrg-sec-overview-01 (work in progress), March 2006. [LD03] Lear, E. and R. Droms, "What's In A Name: Thoughts from the NSRG", draft-irtf-nsrg-report-10 (expired), September 2003. [RFC3756] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor Discovery (ND) Trust Models and Threats", RFC 3756, May 2004. [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005. [SB05] Scott, K. and S. Burleigh, "Bundle Protocol Specification", draft-irtf-dtnrg-bundle-spec-04 (work in progress), November 2005. Eddy Expires November 26, 2006 [Page 12] Internet-Draft EIDs in DTN May 2006 Author's Address Wesley M. Eddy Verizon Federal Network Systems NASA Glenn Research Center 21000 Brookpark Rd, MS 54-5 Cleveland, OH 44135 Phone: 216-433-6682 Email: weddy@grc.nasa.gov Eddy Expires November 26, 2006 [Page 13] Internet-Draft EIDs in DTN May 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. Eddy Expires November 26, 2006 [Page 14]