idnits 2.17.1 draft-wyllie-dtnrg-badisc-01.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 22. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 913. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 924. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 931. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 937. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust 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 (November 18, 2007) is 5975 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-10) exists of draft-irtf-dtnrg-ltp-07 == Outdated reference: A later version (-09) exists of draft-irtf-dtnrg-sdnv-00 == Outdated reference: A later version (-09) exists of draft-irtf-dtnrg-tcp-clayer-00 == Outdated reference: A later version (-22) exists of draft-wood-tsvwg-saratoga-00 -- Obsolete informational reference (is this intentional?): RFC 3926 (Obsoleted by RFC 6726) Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Wyllie 3 Internet-Draft Ohio University 4 Intended status: Experimental W. Eddy 5 Expires: May 21, 2008 Verizon 6 J. Ishac 7 W. Ivancic 8 NASA 9 S. Ostermann 10 Ohio University 11 November 18, 2007 13 Automated Bundle Agent Discovery for Delay/Disruption-Tolerant 14 Networking 15 draft-wyllie-dtnrg-badisc-01 17 Status of this Memo 19 By submitting this Internet-Draft, each author represents that any 20 applicable patent or other IPR claims of which he or she is aware 21 have been or will be disclosed, and any of which he or she becomes 22 aware will be disclosed, in accordance with Section 6 of BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt. 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 This Internet-Draft will expire on May 21, 2008. 42 Copyright Notice 44 Copyright (C) The IETF Trust (2007). 46 Abstract 48 In Delay/Disruption-Tolerant Networking (DTN), Bundle Agents form an 49 overlay network that forwards DTN bundles between their source and 50 destination applications. This document describes a mechanism that 51 Bundle Agents can use to discover when they are in contact with one 52 another and optionally provide information on the additional 53 properties of current or future contacts, such as duration and 54 capabilities. This information can be used to trigger bundle 55 forwarding or make future bundle scheduling decisions. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 61 1.2. Protocol Overview . . . . . . . . . . . . . . . . . . . . 5 62 2. Message Format . . . . . . . . . . . . . . . . . . . . . . . . 6 63 2.1. Bundle Processing Control Flags . . . . . . . . . . . . . 6 64 2.2. Autodiscovery Message Format . . . . . . . . . . . . . . . 7 65 2.3. Autodiscovery Flags . . . . . . . . . . . . . . . . . . . 8 66 2.4. Capabilities . . . . . . . . . . . . . . . . . . . . . . . 8 67 2.4.1. Convergence Layers Supported . . . . . . . . . . . . . 9 68 2.4.2. Grokability of Schemes . . . . . . . . . . . . . . . . 9 69 2.4.3. Structure of the Capabilities SDNVs . . . . . . . . . 9 70 2.5. Autodiscovery Protocol Type . . . . . . . . . . . . . . . 10 71 3. Convergence Layer Behavior . . . . . . . . . . . . . . . . . . 11 72 4. Processing Behavior . . . . . . . . . . . . . . . . . . . . . 12 73 4.1. Exported Bundling Agent Interface . . . . . . . . . . . . 12 74 4.2. Bundling Daemon Autodiscovery Request Handling . . . . . . 12 75 4.3. Processing of Received Autodiscovery Bundles . . . . . . . 13 76 4.4. Adding and Overwriting Contact Times . . . . . . . . . . . 13 77 4.5. Bundle Status Reports . . . . . . . . . . . . . . . . . . 14 78 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 79 5.1. Sensor Node to Sensor Node . . . . . . . . . . . . . . . . 15 80 5.2. Deep-Space Probe to Earth Discovery . . . . . . . . . . . 15 81 5.3. LEO Satellites to Terrestrial Center . . . . . . . . . . . 15 82 5.4. Updating and Overwriting Contacts . . . . . . . . . . . . 16 83 5.5. A Note on Flexibility . . . . . . . . . . . . . . . . . . 17 84 6. Security Considerations . . . . . . . . . . . . . . . . . . . 18 85 6.1. Security in a Trusted Network . . . . . . . . . . . . . . 18 86 6.2. Security in an Untrusted Network . . . . . . . . . . . . . 18 87 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 88 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21 89 9. Informative References . . . . . . . . . . . . . . . . . . . . 22 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 91 Intellectual Property and Copyright Statements . . . . . . . . . . 26 93 1. Introduction 95 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 96 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 97 document are to be interpreted as described in [RFC2119]. 99 The Delay/Disruption-Tolerant Networking (DTN) architecture [RFC4838] 100 describes an overlay network of Bundle Agents (BAs). Each BA manages 101 the forwarding of bundles during contacts with other BAs and queues 102 bundles between contacts. As the bundle format and basic forwarding 103 operations were designed, it became clear that an automated means for 104 BAs to discover neighboring nodes, their neighbors' capabilities, and 105 contact times was needed. This document describes such a mechanism 106 as well as the mechanism's relationship to potential DTN routing 107 protocols. 109 While the mechanism described within this document is specifically 110 designed to convey peer-to-peer contact information between two BAs 111 that are adjacent in the overlay topology, it also can be used as one 112 of the building blocks to enable multi-hop routing decisions between 113 BAs. To clarify, consider a typical Internet routing protocol (e.g. 114 OSPF [RFC2328]) which has two main types of messages: (1) "Hello" 115 messages used to automatically discover connectivity with other 116 directly-reachable peers, and (2) messages used to update databases 117 of connectivity information for further hops. The mechanism 118 described in this document satisfies the first function ("Hello" 119 messaging) within a DTN overlay by allowing Bundle Agents to 120 automatically discover other nodes to which they can directly forward 121 bundles. 123 Previously, implementations of DTN Bundle Agents provided these 124 functions using either static, manual configuration or ad-hoc, custom 125 advertisement mechanisms that were neither formally defined nor 126 independent of convergence layers. This document provides a means 127 that will interoperate between differing BA implementations and allow 128 them to exchange contact information over any shared convergence 129 layers. 131 This exchange of contact information can be useful even when contact 132 properties are known in advance. It can be used to verify the pre- 133 configured information or reveal discrepancies in contact properties 134 (expected duration, expected future contact times, etc.). 136 The remainder of this document contains a high-level overview of the 137 discovery mechanism's design in Section 1.2, a specification of the 138 message formats used in Section 3 and Section 2, and a description of 139 the rules for generating and processing these messages in Section 4. 140 In addition, Section 5 contains example message exchanges to clarify 141 the protocol's operation. 143 1.1. Terminology 145 Defining neighboring nodes on a typical network is fairly 146 straightforward. However, the overlay nature of a DTN complicates 147 the definition of neighboring DTN BAs. Furthermore, communication 148 may be unidirectional in DTNs: for example, DTN node A may be able to 149 send to DTN node B, but not vice versa. We therefore define the 150 following terms: 152 Neighbor: Two nodes are said to be 'neighbors' over a convergence 153 layer if and only if the nodes can communicate symmetrically 154 directly over that convergence layer. For example, assume A, B, 155 and C are all DTN BAs, and A is connected to B over one TCP 156 convergence layer adapter while B is connected to C over another 157 TCP convergence layer adapter, but TCP segments between A and C 158 are blocked by a firewall, so no direct contact between them is 159 possible. A and C are not neighbors while B is a neighbor to both 160 A and C, regardless of how many IP-layer hops exist between them. 161 The convergence layers here imply connection symmetry: if B were 162 connected to C over a convergence layer which only permitted 163 unidirectional transmission (e.g. FLUTE), B may not be a neighbor 164 to C, and instead might be one of the following: 166 Pitcher: When a contact exists between two nodes, but they are not 167 neighbors because they lack bidirectional connectivity, one is 168 called a "pitcher", and the other a "catcher". The node that can 169 only send over the convergence layer takes the role of the 170 pitcher. A pitcher meets the definition of "neighbor" in every 171 other way. As an example, A is a pitcher to B over a particular 172 convergence layer adapter if A can directly send and B can 173 directly receive using that convergence layer. 175 Catcher: A node that can only receive over a convergence layer 176 adapter fills the role of catcher. A catcher meets the definition 177 of "neighbor" in every other way. As an example, A is a catcher 178 to B over a particular convergence layer adapter if A can directly 179 receive and B can directly send using that convergence layer. 181 In-Contact: A node X is said to be 'in-contact' to another node Y 182 if X is either a neighbor, pitcher, or catcher to node Y. 184 The terms 'pitcher' and 'catcher' were borrowed from JPL's 185 implementation of the Asynchronous Message Service. 187 1.2. Protocol Overview 189 BA autodiscovery is complicated by the diverse set of deployment 190 environments in which DTN may be used. As stated in [RFC4838], 191 deployment environments may include networks with any combination of: 193 o Delays which are orders of magnitude larger than terrestrial 194 networks 196 o 'High' bit-error rates, either overall or bursty in nature 198 o Relatively high asymmetry in network properties compared to the 199 terrestrial Internet 201 To adequately accommodate all of these environments, the protocol in 202 this document provides two levels of information: (1) domain-specific 203 and (2) domain-independent, where a domain refers to a particular 204 class of deployment environment. Domain-specific information 205 typically is needed to determine the expected duration and other 206 properties that are clearly determined by different factors. For 207 instance, deep-space networks have known and stable orbital 208 properties while terrestrial vehicular ad-hoc networks have unknown 209 and fairly random motion and link fading. Domain-independent 210 information directly specifies contact properties that can be 211 determined and communicated independently of any particular 212 deployment environment. As a result, it contains only basic 213 information that is consistently useful across environments such as 214 the remaining amount of storage space and EIDs in use. 216 This dual-level design provides flexibility in determining 217 information about other BAs. For example, DTN-enabled nodes on a 218 local sensor network may send domain-specific bundles including both 219 power levels and received signal strengths to a central point that 220 determines contact times and durations. In contrast, DTN-enabled 221 deep-space probes may send no domain-specific information at all, 222 instead relying on preconfigured schedules or internal ephemeris data 223 to determine contacts, and using autodiscovery only as a status and 224 sanity check of the DTN-level networking configuration. 226 The protocol also allows for third-party configuration of contact 227 information (a third DTN node may inform two other nodes about their 228 expected contact times). This can facilitate remote configuration. 229 For instance, 'dumb' sensor network nodes may not have complete 230 information to determine optimal contact times on their own. 231 However, a single, more sophisticated node can communicate this 232 information to the entire sensor network. The potential for misuse 233 of this capability raises some security concerns that are discussed 234 in Section 6. 236 2. Message Format 238 2.1. Bundle Processing Control Flags 240 Bundle Processing Control Flags MUST adhere to the following 241 guidelines: 243 o Bundle Fragment -- Nominally, autodiscovery bundles will be small 244 enough that fragmentation is never needed. However, unless 245 fragmentation is forbidden by a domain-specific application, 246 autodiscovery bundles may be fragmented. This bit MUST be set 247 according to the fragmentation guidelines in [SB07]. 249 o Administrative Record -- Autodiscovery bundles are not 250 administrative records; this bit MUST be clear. 252 o Fragmentation Allowed -- As stated above, autodiscovery bundles 253 may be fragmented at the discretion of the domain-specific rules. 255 o Custody Transfer Required -- Since the autodiscovery information 256 is advisory by nature, it does not require reliable transmission 257 and custody transfer should never be required; this bit SHOULD 258 always be clear. Furthermore, since bundles used for 259 autodiscovery move over only a single overlay-hop, a Bundle Status 260 Report is sufficient for acknowledgement without invoking custody 261 transfer semantics. 263 o Destination Endpoint is a Singleton -- In certain scenarios, it 264 may make sense to define contact timings for large sets of nodes. 265 Therefore, autodiscovery may take place between non-singleton 266 endpoints, and autodiscovery messages may be multicast at the 267 bundle layer and/or below. 269 o Acknowledgement by application is requested -- As there is no 270 'application' associated with autodiscovery, this should not be 271 necessary and the bit SHOULD be cleared. 273 Therefore, the low-order Bundle Processing Control Flags SHOULD be 274 set to: 276 000Z0Y0X 278 where the value of X is determined by whether the current bundle is a 279 fragment, the value of Y is determined by whether the domain-specific 280 case allows for fragmentation, and the value of Z is determined by 281 the number of intended destinations. 283 2.2. Autodiscovery Message Format 285 In order to work regardless of the convergence layer adapters that 286 are available, BA autodiscovery uses DTN bundles to communicate its 287 data. More specifically, all autodiscovery data is encoded in the 288 payload block of the bundle. Some of the autodiscovery fields use 289 Self-Delimiting Numeric Values (SDNVs) [I-D.irtf-dtnrg-sdnv] within 290 the messaging format, as in several other parts of the Bundle 291 Protocol and its extensions. 293 Any bundles related to autodiscovery MUST contain the domain- 294 independent portion of the autodiscovery bundle, followed optionally 295 by the domain-specific portion. The fields should be ordered as 296 follows: 298 o Version -- 16-bit value specifying the autodiscovery version to 299 which this bundle adheres. This document defines version 0. A 300 daemon MUST drop any bundle with any other version number. 302 o Autodiscovery Flags -- SDNV-encoded field describing the contents 303 of the autodiscovery header. The meanings of the individual bits 304 within this field are defined in Section 2.3. 306 o Contact Start Time -- An optionally included field indicating the 307 beginning point of a contact. The time is encoded as a DTN 308 timestamp as specified in [SB07]. 310 o Contact End Time -- An optionally included field indicating the 311 ending point of a contact, encoded as a DTN timestamp as specified 312 in [SB07]. 314 o Pitcher -- An endpoint ID reference as specified in [SB07] 315 referring to the node designated as the 'pitcher' in the 316 connection. 318 o Catcher -- An endpoint ID reference as specified in [SB07] 319 referring to the node designated as the 'catcher in the 320 connection. 322 o Capabilities -- SDNV-encoded field describing the capabilities of 323 the node referred to by this block. This is described in 324 Section 2.4. 326 o Autodiscovery Protocol Type -- A 16-bit field that indicates the 327 format of the domain-specific data and domain-specific procedures. 328 This is described in Section 2.5. 330 2.3. Autodiscovery Flags 332 The bits of the Autodiscovery Flags indicate which optional fields of 333 the Autodiscovery Block are present, and are explained in detail 334 below: 336 Bit 0 -- Start Time Present 337 Bit 1 -- End Time Present 338 Bit 2 -- Connection is bidirectional 339 Bit 3-7 -- Reserved 341 o Start Time Present -- If this bit is set, then the autodiscovery 342 message includes the Contact Start Time field. A sender can 343 either indicate a specific time when a predicted future contact 344 may start, or this bit can be clear (and the corresponding field 345 omitted) to indicate an immediate contact (or, put differently, 346 that the nodes can commence communication upon processing of the 347 autodiscovery bundle). If this bit is set, then a Contact Start 348 Time field MUST be included in the autodiscovery message; if the 349 bit is cleared, then that field MUST NOT be present. 351 o End Time Present -- If this bit is set, then the autodiscovery 352 message includes the Contact End Time field. If the field is 353 omitted, this means that the nodes will remain in contact for the 354 indefinite future. If this bit is set, then a Contact End Time 355 field MUST be included in the autodiscovery message; if the bit is 356 cleared, then that field MUST NOT be present. 358 o Connection is bidirectional -- If this bit is set, it signifies 359 that not only can the pitcher send to the catcher, but vice versa 360 as well. This establishes the two nodes as neighbors. 362 2.4. Capabilities 364 Though many capabilities could be considered domain-specific, some 365 capabilities are nearly ubiquitous in utility and relevance. Those 366 capabilities are defined here. To reduce bit overhead when not all 367 capabilities are relevant or desired, the capabilities are set as a 368 two-level SDNV. The top-level SDNV specifies which second-level 369 SDNVs are present in the bundle. Each second-level is a categorized 370 SDNV with flags signifying the presence or absence of some 371 capability. 373 Currently, two second-level SDNVs are defined. Therefore, the top- 374 level capabilities SDNV has the following values: 376 o Convergence Layers Supported -- Setting this bit signifies the 377 presence of the convergence layer capabilities SDNV. 379 o Grokability of Schemes -- Setting this bit signifies the presence 380 of the schemes capabilities SDNV. Clearing this bit signifies 381 that the SDNV is absent from this bundle. 383 For any capabilities that are not defined, default values may be 384 chosen by the BA in an implementation-specific manner. 386 2.4.1. Convergence Layers Supported 388 This capabilities SDNV defines over which convergence layers the BA 389 can communicate. Setting the convergence layer bit indicates that 390 the convergence layer is understood; clearing indicates that it is 391 not. Currently, the SDNV is defined as follows: 393 o Bit 0 -- Single-packet UDP (one bundle per UDP packet) 395 o Bit 1 -- TCPCL, defined in [I-D.irtf-dtnrg-tcp-clayer] 397 o Bit 2 -- LTP, defined in [I-D.irtf-dtnrg-ltp] 399 o Bit 3 -- Saratoga, defined in [I-D.wood-tsvwg-saratoga] 401 o Bit 4 -- FLUTE, defined in [RFC3926] 403 o Bit 5-7 -- Reserved 405 2.4.2. Grokability of Schemes 407 This capabilities SDNV defines which EID schemes the BA can 408 understand. Currently, the SDNV defines the following: 410 o Bit 0 -- The BA understands the "dtn" scheme 412 o Bit 1 -- The BA understands the "ipn" scheme 414 2.4.3. Structure of the Capabilities SDNVs 416 All capabilities information is included as part of the 417 "capabilities" section of the discovery header. The top-level SDNV 418 MUST be present. If any of its bits are set, the accompanying SDNV 419 MUST be concatenated immediately following the top-level SDNV. If 420 multiple second-level SDNVs are indicated, they MUST be concatenated 421 together in the order in which they are indicated in the top-level 422 SDNV. 424 2.5. Autodiscovery Protocol Type 426 If an autodiscovery bundle contains domain-specific information, this 427 field indicates the structure of the payload data. Effectively, this 428 field defines the "domain" of the domain-specific portion. 429 Currently, the following fields are defined: 431 o 0x00 -- Basic - no domain-specific information; payload MUST be 432 empty 434 o 0x01 -- DMC-like Satellites - payload format defined in a separate 435 document 437 o 0x02 through 0xEF -- Currently undefined; can be defined in later 438 documents 440 o 0xF0 through 0xFF -- Experimental 442 Domain-specific information, in a bundle which has any, immediately 443 follows the payload of the autodiscovery message. 445 3. Convergence Layer Behavior 447 Due to the nature of an overlay network, autodiscovery may take place 448 over many different convergence layers. In addition, depending on 449 the convergence layer used, convergence layer discovery might be 450 necessary prior to bundling discovery. For instance, when using 451 Bluetooth as a convergence layer, paired devices must undergo device 452 discovery and service discovery before encapsulated data (such as the 453 autodiscovery bundle) can be sent. Therefore, initiating 454 autodiscovery over Bluetooth for previously unknown devices will 455 require cooperation between device/service discovery and the bundling 456 layer [BTSPEC]. If any data obtained in service discovery is 457 relevant, it could be communicated as domain-specific information in 458 the discovery bundle. For the common terrestrial Internet protocols 459 TCP and UDP, discovery over TCP implies that the devices have 460 bidirectional communication where discovery over UDP can use 461 unidirectional communication and multicast. TCP requires handshaking 462 prior to bundle communication; UDP does not. 464 Certain capabilities of a convergence layer node may be relevant in 465 the bundling autodiscovery process. For instance, when using TCP, it 466 may be relevant to communicate the round-trip time (RTT) to the 467 bundle layer as it may impact routing decisions. Extra features like 468 this can be included as part of a domain-specific protocol. 470 The capabilities as described in are explicitly for the bundle layer. 471 Convergence layer-specific information (aside from their existence) 472 is purposefully not included there. Communicating relevant 473 convergence layer-specific information can be done in a domain- 474 specific protocol. 476 Due to the myriad convergence layers over which bundles are expected 477 to travel, exact mechanisms for executing bundle-layer autodiscovery 478 over convergence layers are outside the scope of this document and 479 are left as future work. 481 4. Processing Behavior 483 Due to the domain-specific portions of autodiscovery, exact 484 processing of autodiscovery bundles can vary widely between domains. 485 Therefore, only a general framework for autodiscovery bundle 486 processing is given in this document while exact autodiscovery 487 procedures for particular domains is defined separately. 489 Autodiscovery functions can either be implemented within a BA, or as 490 one or more external 'helper' applications. An interface supporting 491 both types of implementation are outlined below. Although a helper 492 application may assist in interpreting autodiscovery payloads, 493 autodiscovery is not itself a DTN application. Autodiscovery bundles 494 are addressed to the administrative endpoints of BAs themselves, 495 whose EIDs are not suffixed with an application de-muxing token, or 496 otherwise altered. In this way, autodiscovery works for all EID 497 schemes regardless of how EIDs are constructed within them. 499 4.1. Exported Bundling Agent Interface 501 In addition to providing the basic bundling API as defined in [SB07], 502 the daemon SHOULD allow for explicit values specified for the 503 following fields in an outgoing bundle: 505 o Local Convergence Layer Adapter for transmission 507 o Destination EID -- SHOULD be set to dtn:discovery for discovery of 508 BAs with unknown EIDs; may be set to an actual EID if it is known 510 o Bundle Payload -- to include the autodiscovery message 512 o Lifetime -- A lifetime of 0 squelches forwarding of discovery 513 bundles. 515 Exactly how this interface is supplied (e.g. via IPC, RPC, etc) is an 516 implementation-specific consideration. 518 A BA SHOULD use the "expedited" priority for all autodiscovery 519 bundles, given that they may affect immediate decisions and are 520 typically small bundles, although this interface MAY be extended in 521 some implementations to allow the priority to be specified. 523 4.2. Bundling Daemon Autodiscovery Request Handling 525 Requests for autodiscovery will be honored as long as the supplied 526 parameters are valid and the requested convergence layer adapter 527 exists and is capable of sending bundles. 529 Upon receiving a request to initiate autodiscovery, the BA MUST 530 initiate this procedure regardless of its current knowledge of 531 contacts. It will, however, maintain its current contact information 532 base entries at least until autodiscovery completes. 534 4.3. Processing of Received Autodiscovery Bundles 536 Processing of incoming autodiscovery responses proceeds differently 537 depending on the Autodiscovery Type field: 539 Zero (fully domain-independent): A domain-independent bundle can be 540 processed entirely within any bundle agent capable of 541 autodiscovery. The contact information given in the autodiscovery 542 message can be used to update the contact information base at the 543 bundle agent's discretion. 545 Non-Zero (domain-specific): Upon reception of an Autodiscovery 546 Bundle with a domain-specific payload (indicated by a non-zero 547 Autodiscovery Type code), the bundle agent can either process the 548 domain-specific payload itself (if it understands the 549 autodiscovery protocol used) or may hand the entire payload block 550 to external autodiscovery code that can suggest changes to the 551 bundle agent's contact information base after processing. 553 It is possible that after receiving an Autodiscovery Bundle, a bundle 554 agent will wish to advertise its own view of contact information in 555 response. This is fully at the discretion of the bundle agent or 556 external autodiscovery code. 558 4.4. Adding and Overwriting Contact Times 560 When a valid new contact is received, it will be updated according to 561 the following rules: 563 More recently-received and valid updates will always be added to the 564 BA. Only the contact window, pitcher EID, and catcher EID are 565 considered in decisions to keep or eliminate older discovery entries. 567 If no contact information about the pitcher and catcher currently 568 exists, or if contact information exists but does not overlap with 569 the time period specified in the received bundle, then the contact 570 information will be added to the BA without modification to existing 571 entries. 573 If contact information about the pitcher and catcher currently exists 574 and overlaps the time period specified in the received bundle at any 575 point in time, the now "outdated" entry should be deleted in its 576 entirety, including the part which does not overlap with the newly- 577 received bundle. Other entries pertaining to the pitcher and catcher 578 which have no time overlap with the newly received bundles SHOULD be 579 retained. 581 More examples to illustrate the updating procedure can be found in 582 Section 5.4. 584 4.5. Bundle Status Reports 586 As any bundle sender can request a Bundle Status Report (a Bundle 587 Reception Status Report in this case), Autodiscovery Bundles may also 588 be acknowledged using this mechanism, if desired. These could be 589 utilized by a bundle agent or external autodiscovery code in order to 590 suppress retransmission of autodiscovery information, for instance, 591 when sending over unreliable convergence layer adapters that lack 592 feedback of their own (e.g. single-packet UDP). This is not 593 necessary in all domains, and since information gained through 594 autodiscovery is generally advisory, it is assumed that Bundle Status 595 Reports will not be frequently requested for Autodiscovery Bundles. 597 5. Examples 599 5.1. Sensor Node to Sensor Node 601 In this example, dozens of sensor nodes are deployed in an area 602 without any infrastructure and must discover one another in order to 603 communicate at the bundle layer. All nodes are connected on the same 604 network. Exact discovery would depend on the domain-specific 605 protocol used, but it could look similar to the the diagram below: 607 Sensor node Sensor node 608 (s) MULTICAST HELLO -----------------> 610 <----------------- HELLO / BATTERY LIFE (s) 612 (consults signal power level) 613 (consults battery life) 615 (i) CALCULATED 616 CONTACT TIME -----------------> 617 <----------------- BUNDLE RECEIVED 619 5.2. Deep-Space Probe to Earth Discovery 621 In this example, a deep-space node has a set contact schedule with 622 Earth nodes established prior to each window of communication. Due 623 to some event that causes re-allocation of ground-station resources, 624 changing the space probe's schedule may be necessary. 626 Deep-Space Satellite Earth Node 627 (i) <----------------------------- CONTACT TIME 629 5.3. LEO Satellites to Terrestrial Center 631 Many LEO satellites are particularly concerned with optimizing link 632 utilization, and primarly send data downwards. Contacts with ground 633 stations can be brief, on the order of several minutes, so 634 synchronizing clocks and getting the BA onboard a satellite to be 635 ready to forward at the correct time can be accomplished through 636 autodiscovery. The authoritative timing figure would be the 637 terrestrial station, which would asynchronously send contact time 638 information to the satellite on some schedule that let it optimize 639 its forwarding decisions to avoid reactive fragmentation due to 640 interrupted transfers and possibly to ensure that transmission 641 preconditions are met before the contact (transmitter powered up, on 642 correct frequency, using correct modulation and coding, etc.). 644 LEO Satellite Earth Node 645 (consults ephemeris data) 646 <-------------------- CONTACT TIME (i) 647 (time a1, time a2) 648 ASYNC. DATA --------------------> 649 <-------------------- CONTACT TIME (i) 650 (time b1, time b2) 651 <-------------------- CONTACT TIME (i) 652 (time c1, time c2) 653 ASYNC. DATA --------------------> 655 5.4. Updating and Overwriting Contacts 657 This section provides examples for updating and overwriting contact 658 information depending on discovery bundles received. 660 Existing contact windows are numbered 1...n: the received bundle is 661 labeled X. 663 -------------------------- time ---------------------------> 665 -------- ------------------------------ 666 | 1 | | X | 667 -------- ------------------------------ 669 -------------------------- time ---------------------------> 671 Procedure: 1 is kept; X is added 673 -------------------------- time ---------------------------> 675 -------- --- 676 | 1 | | 2 | 677 -------- --- 679 --------------------------------- 680 | X | 681 --------------------------------- 683 -------------------------- time ---------------------------> 684 Procedure: 1 is kept, 2 is removed, and X is added 686 -------------------------- time ---------------------------> 688 -------- --- ------------ ----------- 689 | 1 | | 2 | | 3 | | 4 | 690 -------- --- ------------ ----------- 692 ----------------------- 693 | X | 694 ----------------------- 696 -------------------------- time ---------------------------> 698 Procedure: 1 is kept, 2 and 3 are removed, 4 is kept, and X is added. 700 5.5. A Note on Flexibility 702 The lack of structure in the protocol is due to the necessary 703 flexibility in deployment. The domain-independent timing packets are 704 meant to give a universal way to apply discovery and timing 705 principles to any DTN environment that does not currently exist. The 706 domain-dependent part is meant to add the needed flexibility to 707 adhere to all DTN environments. Consequently, there is no 'typical' 708 example that generalizes all DTN neighbor discovery. 710 More specific examples of neighbor discovery can be found in 711 documentation describing domain-specific exchanges. 713 6. Security Considerations 715 Nearly all threats that apply to other neighbor discovery protocols 716 apply to DTN neighbor discovery. As suggested in [RFC3756], many of 717 these are solved by ensuring a 'trusted' network. Networks that are 718 not trusted are subject to different limitations (and expectations), 719 so we deal with probable attacks and mitigations for each network 720 separately. 722 6.1. Security in a Trusted Network 724 Unlike general networking in the Internet, in DTN scenarios, there 725 are many cases where a 'stranger' on the network is an unexpected 726 condition. For example, sensor networks in poorly-connected 727 environments are often controlled by a single organization which 728 grants connection to only approved nodes. This may be implemented 729 through link-layer encryption, keying of spreading sequences, or 730 other means. Currently, as these two deployment environments are the 731 two major proposed uses for DTN, securing the 'trusted' network 732 against attack deserves further consideration. 734 The most likely attack on a trusted network is an attack where a node 735 infiltrates a closed network, masquerading as a trusted node using a 736 trusted address. To mitigate this attack, one could pre-share 737 symmetric keys and use encryption with nodes that are allowed on the 738 closed network. Blocks to accomplish this are defined in [DTNSEC]. 739 All aspects of neighbor discovery, therefore, could be encrypted 740 using these keys. In this manner, no nodes lacking the pre-shared 741 key (and, by extension, permission to use the network) can 742 communicate on the network. 744 In nodes that can afford the overhead of public-key cryptography, 745 [DTNSEC] also supports X.509 certificate processing. This would be 746 more desirable for nodes that may communicate with many entities 747 (such as the international space station) that each require separate 748 keys (such as member nations with varying levels of cooperation). If 749 necessary, this would also help protect the system from a single 750 point of failure as in the pre-shared key system, only one pre-shared 751 key needs to be compromised to compromise an entire system. 753 6.2. Security in an Untrusted Network 755 Though many currently proposed deployments of DTN involve closed 756 networks, future DTN networks may include untrusted public networks 757 [haggle]. For example, a DTN node on a public transportation system 758 may send a bundle to a curbside receiver which would then forward it 759 through the network. As part of public transportation, it is 760 impossible to guarantee trust to nodes on the network, so the above 761 system will not work. 763 In this environment, likely attacks generally are some variation of 764 man-in-the-middle attacks. For instance, a PDA on the public 765 transportation system may masquerade as a router and sniff traffic or 766 deny it altogether. As stated in [RFC4251], there is no known way to 767 prevent these attacks outright. 769 To help mitigate these attacks, we propose a 'fingerprint' system 770 combined with public-key cryptography. If a node considers the above 771 attack serious enough, it can require public-key cryptography as 772 provided in [DTNSEC], storing the fingerprint of the server's public 773 key. In a man-in-the-middle attack, the fingerprint would change, 774 and the user could be notified in an appropriate way. This system is 775 very similar to the fingerprinting system currently in widespread use 776 in SSHv2 [RFC4251]. 778 Due to the potentially severe limitations on processing power and 779 bandwidth of DTN nodes, all of the above security is optional with 780 respect to neighbor discovery. In many deployments, the costs may 781 simply outweigh the benefits. 783 7. IANA Considerations 785 This document does not update or create any IANA registries. 787 8. Acknowledgements 789 Some of the work on this document was performed at NASA's Glenn 790 Research Center with funding provided by NASA's Earth Science 791 Technology Office. 793 9. Informative References 795 [BTSPEC] "Specification of the Bluetooth System", July 2007. 797 [DTNSEC] Symington, S. and S. Farrell, "Bundle Security Protocol 798 Specification", draft-irtf-dtnrg-bundle-security (work in 799 progress), April 24 2007. 801 [I-D.irtf-dtnrg-ltp] 802 Ramadas, M., Burleigh, S., and S. Farrell, "Licklider 803 Transmission Protocol - Specification", 804 draft-irtf-dtnrg-ltp-07 (work in progress), October 2007. 806 [I-D.irtf-dtnrg-sdnv] 807 Eddy, W., "Using Self-Delimiting Numeric Values in 808 Protocols", draft-irtf-dtnrg-sdnv-00 (work in progress), 809 September 2007. 811 [I-D.irtf-dtnrg-tcp-clayer] 812 Demmer, M. and J. Ott, "Delay Tolerant Networking TCP 813 Convergence Layer Protocol", 814 draft-irtf-dtnrg-tcp-clayer-00 (work in progress), 815 July 2007. 817 [I-D.wood-tsvwg-saratoga] 818 Wood, L., McKim, J., Eddy, W., Ivancic, W., and C. 819 Jackson, "Saratoga: A Scalable File Transfer Protocol", 820 draft-wood-tsvwg-saratoga-00 (work in progress), 821 October 2007. 823 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 824 Requirement Levels", BCP 14, RFC 2119, March 1997. 826 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 828 [RFC3756] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor 829 Discovery (ND) Trust Models and Threats", RFC 3756, 830 May 2004. 832 [RFC3926] Paila, T., Luby, M., Lehtonen, R., Roca, V., and R. Walsh, 833 "FLUTE - File Delivery over Unidirectional Transport", 834 RFC 3926, October 2004. 836 [RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 837 Protocol Architecture", RFC 4251, January 2006. 839 [RFC4838] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst, 840 R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant 841 Networking Architecture", RFC 4838, April 2007. 843 [SB07] Scott, K. and S. Burleigh, "Bundle Protocol 844 Specification", draft-irtf-dtnrg-bundle-spec-10 (work in 845 progress), April 2007. 847 [haggle] Scott, J., Hui, P., Crowcroft, J., and C. Diot, "Haggle: A 848 Networking Architecture Designed Around Mobile Users", 849 IFIP WONS, Les Menuires, France, January 2006. 851 Authors' Addresses 853 Jim Wyllie 854 Ohio University 855 EECS Department #18 856 Stocker Center 857 Athens, OH 45701 859 Phone: +1-740-593-1562 860 Email: jw280601@ohiou.edu 862 Wesley M. Eddy 863 Verizon Federal Network Systems 864 NASA Glenn Research Center 865 21000 Brookpark Rd, MS 54-5 866 Cleveland, OH 44135 868 Phone: 216-433-6682 869 Email: weddy@grc.nasa.gov 871 Joseph Ishac 872 NASA Glenn Research Center 873 21000 Brookpark Road 874 Cleveland, Ohio 44135 875 USA 877 Phone: +1-216-433-6587 878 Fax: +1-216-433-8705 879 Email: jishac@nasa.gov 881 Will Ivancic 882 NASA Glenn Research Center 883 21000 Brookpark Road 884 Cleveland, Ohio 44135 885 USA 887 Phone: +1-216-433-3494 888 Fax: +1-216-433-8705 889 Email: William.D.Ivancic@nasa.gov 890 Shawn Ostermann 891 Ohio University 892 Department of Computer Science 893 322b Stocker Center 894 Athens, Ohio 45701 896 Phone: +1-740-593-1234 897 Email: ostermann@cs.ohiou.edu 899 Full Copyright Statement 901 Copyright (C) The IETF Trust (2007). 903 This document is subject to the rights, licenses and restrictions 904 contained in BCP 78, and except as set forth therein, the authors 905 retain all their rights. 907 This document and the information contained herein are provided on an 908 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 909 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 910 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 911 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 912 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 913 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 915 Intellectual Property 917 The IETF takes no position regarding the validity or scope of any 918 Intellectual Property Rights or other rights that might be claimed to 919 pertain to the implementation or use of the technology described in 920 this document or the extent to which any license under such rights 921 might or might not be available; nor does it represent that it has 922 made any independent effort to identify any such rights. Information 923 on the procedures with respect to rights in RFC documents can be 924 found in BCP 78 and BCP 79. 926 Copies of IPR disclosures made to the IETF Secretariat and any 927 assurances of licenses to be made available, or the result of an 928 attempt made to obtain a general license or permission for the use of 929 such proprietary rights by implementers or users of this 930 specification can be obtained from the IETF on-line IPR repository at 931 http://www.ietf.org/ipr. 933 The IETF invites any interested party to bring to its attention any 934 copyrights, patents or patent applications, or other proprietary 935 rights that may cover technology that may be required to implement 936 this standard. Please address the information to the IETF at 937 ietf-ipr@ietf.org. 939 Acknowledgment 941 Funding for the RFC Editor function is provided by the IETF 942 Administrative Support Activity (IASA).