idnits 2.17.00 (12 Aug 2021) /tmp/idnits61606/draft-eddy-dtnrg-eid-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 434. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 411. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 418. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 424. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 215: '...ynamic in DTNs. An application SHOULD...' RFC 2119 keyword, line 216: '...ions, and a bundling agent SHOULD have...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 25, 2006) is 5833 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: draft-ietf-rpsec-routing-threats has been published as RFC 4593 == Outdated reference: A later version (-06) exists of draft-irtf-dtnrg-sec-overview-01 == Outdated reference: draft-irtf-dtnrg-bundle-spec has been published as RFC 5050 Summary: 4 errors (**), 0 flaws (~~), 5 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group W. Eddy 3 Internet-Draft Verizon Federal Network Systems 4 Expires: November 26, 2006 May 25, 2006 6 Architectural Considerations for the use of Endpoint Identifiers in 7 Delay Tolerant Networking 8 draft-eddy-dtnrg-eid-00 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on November 26, 2006. 35 Copyright Notice 37 Copyright (C) The Internet Society (2006). 39 Abstract 41 The architecture for Delay Tolerant Networking includes a type of 42 address called an Endpoint Identifier. This document describes some 43 of the remaining issues regarding Endpoint Indentifiers, and how they 44 can be configured and used in bundle forwarding. These either imply 45 directions for future work or highlight clarifications that should be 46 made in the current architecture and protocol documents. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. EID Basics . . . . . . . . . . . . . . . . . . . . . . . . . . 4 52 3. Bundling Node Configuration . . . . . . . . . . . . . . . . . 5 53 4. Application Registration . . . . . . . . . . . . . . . . . . . 6 54 5. Bundle Processing Rules . . . . . . . . . . . . . . . . . . . 8 55 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 56 7. Outstanding Issues . . . . . . . . . . . . . . . . . . . . . . 10 57 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 58 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 59 10. Informative References . . . . . . . . . . . . . . . . . . . 12 60 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 13 61 Intellectual Property and Copyright Statements . . . . . . . . 14 63 1. Introduction 65 The Delay Tolerant Networking (DTN) architecture is centered on the 66 concept of "bundling" application data, and then exchanging bundles 67 between nodes [CBH+06]. Endpoint Identifiers (EIDs) are variable- 68 length strings used to refer to nodes that send, receive, or forward 69 bundles. An EID may refer to one or more nodes, and an individual 70 node may have more than one EID. 72 Conceptually, EIDs are well motivated and explained in the DTN 73 architecture description, and they are used in several places within 74 the DTN Bundle Protocol header [SB05]. However, there is no document 75 that explains how EIDs are assigned to nodes, how applications 76 register with bundling agents, or how forwarding decisions can be 77 made based on EIDs. There have been mailing list discussions on 78 these topics, and the DTN2 Reference Implementation (RI) of the 79 Bundle Protocol uses certain rules (we refer to the DTN2 RI version 80 2.2.0 in this document). In this document, we summarize some of the 81 mailing list threads regarding these subjects, and describe how the 82 DTN2 code operates. The configuration and processing rules contained 83 in this document are not necessarily final or normative; this is only 84 an informational snapshot of current thinking and practices in the 85 DTNRG. Some of the issues brought to light in this document may 86 cause future iterations that are considerably different. 88 Section 2 contains a basic description of EIDs based on the DTN 89 architecture and DTN2 RI. Some ways that a DTN bundle agent might 90 configure an EID are discussed in Section 3, and methods for 91 applications to register EIDs are described in Section 4. Security 92 implications of EID usage are explained in Section 6. Finally, 93 several outstanding issues that have been uncovered are listed in 94 Section 7. 96 2. EID Basics 98 The Uniform Resource Identifier (URI) standard [RFC3986] has been 99 selected as the format for representing EIDs in the DTN architecture. 100 URIs are used in several Internet protocols. For the purposes of the 101 DTN protocols, the URI syntax is described as an EID scheme 102 identifier followed by a scheme specific part (SSP). This allows 103 multiple naming conventions (schemes) to be used in conjunction with 104 the basic DTN protocols. The current DTN specifications do not fully 105 define the use of any EID schemes. Interoperability between nodes 106 using different schemes may be possible, but exact mechanisms for 107 this have also not been described at this time. 109 The use of EIDs has evolved from early DTN work that used the notion 110 of regions. Each node address identified a region, and contained a 111 portion which was unique within that region, but with no other 112 restrictions on formating [CBH+03]. This is similar in principle to 113 the EID definition, since assignment of EID schemes will be regulated 114 by IANA, however a notable difference is that there are no 115 stipulations in the current DTN architecture that SSPs be unique 116 within a scheme. 118 EIDs may be of unicast, anycast, or multicast types. The 119 architecture states minimum reception group (MRG) of an EID can be 120 determined by a node using the EID itself. This is not very clear in 121 the current architecture. The way EIDs have been defined, it is more 122 correct to say that at least "some" node can determine the MRG of an 123 EID, rather than "a" node, which would seem to imply that any node 124 could resolve an EID into an MRG. This clearly is not the case since 125 there is no guarantee that every node even understands the EID 126 scheme. 128 The "dtn" EID scheme is discussed briefly in the current 129 documentation, but its SSP and usage are not. The only concrete data 130 on this scheme is that the special "none" SSP is set aside. The DTN2 131 RI classifies valid "dtn" bundle agent SSPs as consisting of 132 alphanumeric characters, underscores, dashes, and periods. To 133 identify applications, "service tags" are appended to the bundle 134 agent SSPs. This does not seem to be driven by the bundle protocol 135 specification or DTN architecture documents, although it certainly 136 works well for the purposes of near-term experimentation and 137 demonstration. The DTN2 RI also supports an "eth" scheme where the 138 SSP is an Ethernet MAC address represented in a certain format. 140 3. Bundling Node Configuration 142 The DTN2 RI uses a configuration file directive to set the local EID 143 of a bundling agent. The default action is to use the "dtn" scheme, 144 and create an EID of the form "hostname.dtn", where the "hostname" 145 portion is substituted with the host operating system's configured 146 hostname. The DTN specification documents do not codify that this is 147 how EIDs in the "dtn" scheme are to be formatted or constructed. 148 This method works well for demonstration purposes and small-scale 149 deployments, but does not provide any expectation of uniqueness. 150 Since autoconfiguration methods that guarantee global uniqueness may 151 be difficult to make delay-insensitive, in order to be useful for 152 small-scale experimentation and deployments in the short-term, the 153 "dtn" scheme should probably be defined to preclude any such 154 expectations. It should be encouraged that other schemes be 155 developed with allow for uniqueness and that these be used in real- 156 world deployments, outside of laboratory or demonstration use. One 157 simple way to provide uniqueness is for bundle agents to be assigned 158 EIDs from a central authority, similar to the way that DHCP assigns 159 IP addresses, however pre-arranged manual assignment and 160 configuration may be required in some DTN scenarios due to high- 161 delays. 163 If DTN bundling agents become used in multiple contexts, it is 164 possible that certain agents may end up bridging DTNs that are not 165 commonly administered. This could cause unforeseen issues if the 166 DTNRG does not produce naming schemes that yield some expectation of 167 uniqueness in a self-configured EID, or a guarantee of uniqueness in 168 an assigned EID. Designing multiple naming schemes with different 169 characteristics and use cases should be a primary focus area of the 170 DTNRG's future efforts, as well as more fully explaining the intended 171 format and use of the "dtn" scheme. 173 In addition to uniqueness, another consideration in defining naming 174 schemes is route aggregation. When routing protocols are adopted for 175 DTNs, in order to limit the size of advertisements, memory required 176 to hold tables, time to search tables, and power draw from all of 177 these factors, EID SSP conventions should allow for aggregation in 178 some way. Otherwise the scale and scope of DTNs might be 179 artificially limited by the naming schemes available. Hierarchically 180 structured EIDs are one means of acheiving aggregatability. EID 181 schemes derived from fully-qualified domain names and/or IP addresses 182 could serve as examples. 184 4. Application Registration 186 The present architecture document is unclear on how exactly 187 applications interface with bundling agents. It is stated that 188 applications express an interest in receiving data for particular 189 EIDs and send data to particular EIDs, but it is not stated whether 190 portions of the EID SSP should identify applications (in addition to 191 nodes), or whether the SSP merely identifies a node, and some other 192 multiplexing and demultiplexing is used to deliver the correct data 193 to the correct applications. This is a point that should be 194 clarified, although the answer is fairly obvious based on the 195 protocol specifications. 197 One other point of clarification regards whether applications 198 construct their own EIDs or are assigned EIDs by the bundle agent as 199 part of the registration proceedure. Another cloudy topic is whether 200 an application can register an EID with a bundle agent that does not 201 understand the scheme portion of the requested EID. 203 In the DTN2 RI, and the "dtnping" application as an example, node 204 EIDs are constructed by applications themselves appending their a 205 string consisting of the application name and operating system 206 process ID to the bundle agent's EID. Registration of this 207 application EID is requested of the bundle agent, and can either pass 208 or fail. Before the application closes, it requests that the 209 registration be closed. 211 The topic of closing EID registrations is important, since 212 applications may cease running without knowledge of the bundling 213 agent. This is especially and issue when applications and bundling 214 agents are not co-located on the same physical node, since network 215 connectivity is assumed to be dynamic in DTNs. An application SHOULD 216 try to reliably close registrations, and a bundling agent SHOULD have 217 a way of polling existing registrations for liveliness and reaping 218 them as deemed appropriate for specific environments. In some 219 situations this will be more of an issue than in others, due to 220 particular resource tradeoffs between persistent memory utilization, 221 power and bandwidth needed to transmit and respond to registration 222 keep-alives, etc. 224 Application registration presents another interesting problem in that 225 bundles must be addressed to remote application instances. Without 226 naming schemes that allow for either wildcarding or indirection, it 227 will be difficult to efficiently send data to remote peer application 228 instances. In traditional Internet transports, this problem is 229 reduced by the use of "well-known" port numbers, so DTN naming 230 schemes may consider providing "well-known" SSP suffixes to help 231 refer to application instances, along with other demultiplexing 232 tokens. 234 5. Bundle Processing Rules 236 For the most part, the bundling protocol specification contains only 237 a description of the bundle format and some rules for validity of 238 bundles. Specifically, it does not specify (nor does any companion 239 document, at this time) rules for a bundling agend to configure its 240 own EID or make forwarding decisions regarding incoming bundles based 241 on their destination EIDs. Of course, these are ancillary to the 242 protocols wire-format and can be specified elsewhere, as has been 243 done for IP. Nevertheless, these are holes that require filling to 244 complete the DTN architecture. 246 A natural set of processing rules for incoming bundles starts with 247 ascertaining whether the destination EID scheme is understood by the 248 bundle agent. If the destination EID is not understood, processing 249 can no longer continue, but the action that should be taken is 250 unclear. Should a failure report be sent back to the report-to EID? 251 What if the reply-to EID's scheme is not understood? Perhaps, as a 252 fall-back the bundle should be dropped. Or maybe it should be placed 253 in storage until it can be handed off to either another agent (for 254 instance, via a "default" route). Should support for the destination 255 EID be evaluated before accepting custody of the bundle? 257 Assuming the EID scheme is recognized and understood locally, there 258 are still other failure modes when decoding the SSP. For instance, 259 what if the SSP is malformed with respect to what the bundle agent 260 thinks that the EID scheme rules are? This could arise if EID scheme 261 definitions evolve in non-forwards or backwards-compatible ways. 262 Should a similar action be taken in this case as if the EID scheme 263 itself is not locally supported, or is a different response 264 warranted? Should the SSP be parsed and evaluated before accepting 265 bundle custody? 267 There is a related case of what should be done when the SSP can be 268 parsed, but for some other reason it is non-routable. For instance, 269 if the SSP indicated an IPv4 private address space and the local 270 bundle agent did not have a convergence layer adaptor capable of 271 reaching that address space. Again, it should be considered whether 272 this type of error results in behavior similar to other failures we 273 have listed, or whether different actions are desirable. This may 274 even require evaluation on a per-scheme or per-convergence layer 275 basis. 277 6. Security Considerations 279 The security considerations regarding EIDs are very similar to those 280 regarding IP addreses as described in the context of routing and 281 neighbor discover protocols [BMY04] [RFC3756]. The security threats 282 are more relevent to the actual forwarding of bundles and routing 283 exchanges that determine later forwarding decisions than the more 284 general mechanics of how names are assigned and used. Fully 285 exploring these issues and providing solutions is outside the context 286 of this document. The security overview document [FSW06] describes a 287 number of open issues in DTN security, some of which are related to 288 naming and addressing. 290 7. Outstanding Issues 292 In this document, we have identified a number of outstanding issues 293 that are unclear in the DTN architecture, as currently described: 295 o Should a base EID scheme be defined, perhaps utilizing the "dtn" 296 identifier? This does not mean that all EIDs would use this 297 scheme and would not prevent the definition and use of other 298 schemes, but it would provide a basis for interoperability between 299 differing implementations without parties pre-arranging EID rules 300 outside of the specification documents. The use of hostnames in 301 the DTN2 RI does not seem fully appropriate for this purpose. An 302 understanding of what would be desirable in a minimally-supported 303 EID scheme could be helpful, along the lines of work done in the 304 NSRG [LD03]. 306 o What are some methods that assignment and configuration of SSPs 307 can be performed within various schemes in a way that is both 308 collision-resistant and not prone to breakdown under high delay 309 (among other typical factors in DTNs). 311 o Should the function of mapping EIDs into MRGs be clarified to only 312 be required to be possible by at least one node (identified as 313 part of the EID), or by all nodes that can parse the EID scheme? 314 This affects forwarding decisions 316 o Does registration necessarily entail obtaining an extended version 317 of the bundling agent's EID? Does an application request some 318 portion of its EID, or is it fully assigned? Does a bundling node 319 have to know how to parse all the schemes of application EIDs 320 registered with it? 322 o Do more formal guidelines regarding the removal, closing, and 323 expiration of registrations need to be drafted? What are the 324 security implications? 326 o Exactly which operations with regards to parsing and resolving the 327 various EIDs contained in a bundle must take place before 328 accepting custody of the bundle? 330 o What failure modes should a bundle agent be configured with in 331 order to handle cases where it receives bundles with EID schemes 332 or EID SSPs that it does not understand or is not capable of 333 reaching even indirectly (e.g. IPv4 private address space from a 334 public router)? Does the architecture need to define this, or 335 what will be the result if different implementations support 336 different behaviors in these types of failure modes? 338 8. IANA Considerations 340 This document has no IANA considerations. 342 9. Acknowledgements 344 Many others have participated in the DTNRG discussions on naming and 345 contributed to the DTN2 RI. This document is only a synopsis of 346 their work and conversations. 348 Work on this document was performed at NASA's Glenn Research Center, 349 in support of the NASA Space Communications Architecture Working 350 Group (SCAWG), and the FAA/Eurocontrol Future Communications Study 351 (FCS). 353 10. Informative References 355 [BMY04] Barbir, A., Murphy, S., and Y. Yang, "Generic Threats to 356 Routing Protocols", 357 draft-ietf-rpsec-routing-threats-07 (work in progress), 358 October 2004. 360 [CBH+03] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst, 361 R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant 362 Network Architecture", draft-irtf-dtnrg-arch-00 (expired), 363 March 2003. 365 [CBH+06] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst, 366 R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant 367 Network Architecture", draft-irtf-dtnrg-arch-05 (work in 368 progress), March 2006. 370 [FSW06] Farrell, S., Symington, S., and H. Weiss, "Delay-Tolerant 371 Networking Security Overview", 372 draft-irtf-dtnrg-sec-overview-01 (work in progress), 373 March 2006. 375 [LD03] Lear, E. and R. Droms, "What's In A Name: Thoughts from 376 the NSRG", draft-irtf-nsrg-report-10 (expired), 377 September 2003. 379 [RFC3756] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor 380 Discovery (ND) Trust Models and Threats", RFC 3756, 381 May 2004. 383 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 384 Resource Identifier (URI): Generic Syntax", STD 66, 385 RFC 3986, January 2005. 387 [SB05] Scott, K. and S. Burleigh, "Bundle Protocol 388 Specification", draft-irtf-dtnrg-bundle-spec-04 (work in 389 progress), November 2005. 391 Author's Address 393 Wesley M. Eddy 394 Verizon Federal Network Systems 395 NASA Glenn Research Center 396 21000 Brookpark Rd, MS 54-5 397 Cleveland, OH 44135 399 Phone: 216-433-6682 400 Email: weddy@grc.nasa.gov 402 Intellectual Property Statement 404 The IETF takes no position regarding the validity or scope of any 405 Intellectual Property Rights or other rights that might be claimed to 406 pertain to the implementation or use of the technology described in 407 this document or the extent to which any license under such rights 408 might or might not be available; nor does it represent that it has 409 made any independent effort to identify any such rights. Information 410 on the procedures with respect to rights in RFC documents can be 411 found in BCP 78 and BCP 79. 413 Copies of IPR disclosures made to the IETF Secretariat and any 414 assurances of licenses to be made available, or the result of an 415 attempt made to obtain a general license or permission for the use of 416 such proprietary rights by implementers or users of this 417 specification can be obtained from the IETF on-line IPR repository at 418 http://www.ietf.org/ipr. 420 The IETF invites any interested party to bring to its attention any 421 copyrights, patents or patent applications, or other proprietary 422 rights that may cover technology that may be required to implement 423 this standard. Please address the information to the IETF at 424 ietf-ipr@ietf.org. 426 Disclaimer of Validity 428 This document and the information contained herein are provided on an 429 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 430 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 431 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 432 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 433 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 434 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 436 Copyright Statement 438 Copyright (C) The Internet Society (2006). This document is subject 439 to the rights, licenses and restrictions contained in BCP 78, and 440 except as set forth therein, the authors retain all their rights. 442 Acknowledgment 444 Funding for the RFC Editor function is currently provided by the 445 Internet Society.