Network Working Group J. Wyllie Internet-Draft Ohio University Intended status: Experimental W. Eddy Expires: October 3, 2007 Verizon J. Ishac W. Ivancic NASA S. Ostermann Ohio University April 2007 Automated Bundle Agent Discovery for Delay/Disruption-Tolerant Networking draft-wyllie-dtnrg-badisc-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 3, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Wyllie, et al. Expires October 3, 2007 [Page 1] Internet-Draft DTN Bundle Agent Discovery April 2007 Abstract In Delay/Disruption-Tolerant Networking (DTN), Bundle Agents form an overlay network that forwards DTN bundles between their source and destination applications. This document describes a mechanism that Bundle Agents can use to discover when they are in contact with one another and optionally provide information on the additional properties of current or future contacts, such as duration and capabilities. This information can be used to trigger bundle forwarding or make future bundle scheduling decisions. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Protocol Overview . . . . . . . . . . . . . . . . . . . . 5 2. Message Format . . . . . . . . . . . . . . . . . . . . . . . . 6 2.1. Bundle Processing Control Flags . . . . . . . . . . . . . 7 2.2. Block Processing Control Flags . . . . . . . . . . . . . . 8 2.3. Autodiscovery Flags . . . . . . . . . . . . . . . . . . . 8 2.4. Autodiscovery Protocol Type . . . . . . . . . . . . . . . 9 2.5. Capabilities Flags . . . . . . . . . . . . . . . . . . . . 9 3. Processing Behavior . . . . . . . . . . . . . . . . . . . . . 11 3.1. Exported Bundling Agent Interface . . . . . . . . . . . . 11 3.2. Bundling Daemon Autodiscovery Request Handling . . . . . . 12 3.3. Processing of Received Autodiscovery Bundles . . . . . . . 12 3.4. Bundle Status Reports . . . . . . . . . . . . . . . . . . 13 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 4.1. Sensor Node to Sensor Node . . . . . . . . . . . . . . . . 14 4.2. Deep-Space Probe to Earth Discovery . . . . . . . . . . . 14 4.3. LEO Satellites to Terrestrial Center . . . . . . . . . . . 14 4.4. A Note on Flexibility . . . . . . . . . . . . . . . . . . 15 5. Security Considerations . . . . . . . . . . . . . . . . . . . 16 5.1. Security in a Trusted Network . . . . . . . . . . . . . . 16 5.2. Security in an Untrusted Network . . . . . . . . . . . . . 16 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 8. Informative References . . . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 Intellectual Property and Copyright Statements . . . . . . . . . . 23 Wyllie, et al. Expires October 3, 2007 [Page 2] Internet-Draft DTN Bundle Agent Discovery April 2007 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 [RFC2119]. The Delay/Disruption-Tolerant Networking (DTN) architecture [RFC4838] describes an overlay network of Bundle Agents (BAs). Each BA manages the forwarding of bundles during contacts with other BAs and queues bundles between contacts. As the bundle format and basic forwarding operations were designed, it became clear that an automated means for BAs to discover neighboring nodes, their neighbors' capabilities, and contact times was needed. This document describes such a mechanism as well as the mechanism's relationship to potential DTN routing protocols. While the mechanism described within this document is specifically designed to convey peer-to-peer contact information between two BAs that are adjacent in the overlay topology, it also can be used as one of the building blocks to enable multi-hop routing decisions between BAs. To clarify, consider a typical Internet routing protocol (e.g. OSPF [RFC2328]) which has two main types of messages: (1) "Hello" messages used to automatically discover connectivity with other directly-reachable peers, and (2) messages used to update databases of connectivity information for further hops. The mechanism described in this document satisfies the first function ("Hello" messaging) within a DTN overlay by allowing Bundle Agents to automatically discover other nodes to which they can directly forward bundles. Previously, implementations of DTN Bundle Agents provided these functions using either static, manual configuration or ad-hoc, custom advertisement mechanisms that were neither formally defined nor independent of convergence layers. This document provides a means that will interoperate between differing BA implementations and allow them to exchange contact information over any shared convergence layers. This exchange of contact information can be useful even when contact properties are known in advance. It can be used to verify the pre- configured information or reveal discrepancies in contact properties (expected duration, expected future contact times, etc.). The remainder of this document contains a high-level overview of the discovery mechanism's design in Section 1.2, a specification of the message formats used in Section 2, and a description of the rules for generating and processing these messages in Section 3. In addition, Section 4 contains example message exchanges to clarify the Wyllie, et al. Expires October 3, 2007 [Page 3] Internet-Draft DTN Bundle Agent Discovery April 2007 protocol's operation. 1.1. Terminology Defining neighboring nodes on a typical network is fairly straightforward. However, the overlay nature of a DTN complicates the definition of neighboring DTN BAs. Furthermore, communication may be unidirectional in DTNs. DTN node A may be able to send to DTN node B, but not vice versa. We therefore define the following terms: Neighbor: Two nodes are said to be 'neighbors' over a convergence layer if and only if the nodes can communicate symmetrically directly over that convergence layer. For example, assume A, B, and C are all DTN BAs, and A is connected to B over one TCP convergence layer adapter while B is connected to C over another TCP convergence layer adapter, but TCP segments between A and C are blocked by a firewall, so no direct contact between them is possible. A and C are not neighbors while B is a neighbor to both A and C, regardless of how many IP-layer hops exist between them. The convergence layers here imply connection symmetry: if B were connected to C over a convergence layer which only permitted unidirectional transmission (e.g. FLUTE), B may not be a neighbor to C, and instead might be one of the following: Pitcher: When a contact exists between two nodes, but they are not neighbors because they lack bidirectional connectivity, one is called a "pitcher", and the other a "catcher". The node that can only send over the convergence layer takes the role of the pitcher. A pitcher meets the definition of "neighbor" in every other way. As an example, A is a pitcher to B over a particular convergence layer adapter if A can directly send and B can directly receive using that convergence layer. Catcher: A node that can only receive over a convergence layer adapter fills the role of catcher. A catcher meets the definition of "neighbor" in every other way. As an example, A is a catcher to B over a particular convergence layer adapter if A can directly receive and B can directly send using that convergence layer. In-Contact: A node X is said to be 'in-contact' to another node Y if X is either a neighbor, pitcher, or catcher to node Y. The terms 'pitcher' and 'catcher' were borrowed from function names used in JPL's ION implementation of a DTN BA. Wyllie, et al. Expires October 3, 2007 [Page 4] Internet-Draft DTN Bundle Agent Discovery April 2007 1.2. Protocol Overview BA autodiscovery is complicated by the diverse set of deployment environments in which DTN may be used. As stated in [RFC4838], deployment environments may include networks with any combination of: o Delays which are orders of magnitude larger than terrestrial networks o 'High' bit-error rates, either overall or bursty in nature o Relatively high asymmetry in network properties compared to the terrestrial Internet To adequately accommodate all of these environments, the protocol in this document provides two levels of information: (1) domain-specific and (2) domain-independent, where a domain refers to a particular class of deployment environment. Domain-specific information typically is needed to determine the expected duration and other properties that are clearly determined by different factors. For instance, deep-space networks have known and stable orbital properties while terrestrial vehicular ad-hoc networks have unknown and fairly random motion and link fading. Domain-independent information directly specifies contact properties that can be determined and communicated independently of any particular deployment environment. As a result, it contains only basic information that is consistently useful across environments such as the remaining amount of storage space and EIDs in use. This dual-level design provides flexibility in determining information about other BAs. For example, DTN-enabled nodes on a local sensor network may send domain-specific bundles including both power levels and received signal strengths to a central point that determines contact times and durations. In contrast, DTN-enabled deep-space probes may send no domain-specific information at all, instead relying on preconfigured scheduels or internal ephemeris data to determine contacts, and using autodiscovery only as a status and sanity check of the DTN-level networking configuration. The protocol also allows for third-party configuration of contact information (a third DTN node may inform two other nodes about their expected contact times). This can facilitate remote configuration. For instance, 'dumb' sensor network nodes may not have complete information to determine optimal contact times on their own. However, a single, more sophisticated node can communicate this information to the entire sensor network. The potential for misuse of this capability raises some security concerns that are discussed in Section 5. Wyllie, et al. Expires October 3, 2007 [Page 5] Internet-Draft DTN Bundle Agent Discovery April 2007 2. Message Format In order to work regardless of the convergence layer adapters that are available, BA autodiscovery uses DTN bundles to communicate its data. Receiving BAs understand how to process autodiscovery bundles through the addition of an Autodiscovery Block. The Autodiscovery Block utilizes Self-Delimiting Numeric Values (SDNVs) [I-D.eddy-dtn-sdnv] for various fields within the messaging format, as in several other parts of the Bundle Protocol and its extensions. Any bundles related to autodiscovery MUST contain an Autodiscovery Block, as defined here. The Autodiscovery Block has the following format: o Block Type Code -- Indicates that the block is an Autodiscovery Block, matching the format described within this document. Some experimental implementations use the value 192 (within the designated experimental range), with the intention of obtaining a non-experimental type code if the mechanism matures and is deployed. o Block Processing Control Flags -- Exact specifications of this field are present in Section 2.2. o Block Data Length -- Aggregate length of all remaining fields in the block, in SDNV format. o Autodiscovery Flags -- SDNV-encoded field describing the contents of the autodiscovery block. The meanings of the individual bits within this field are defined in Section 2.3. o Capabilities Flags -- SDNV-encoded field describing the capabilities of the node referred to by this block. This is described in Section 2.5. o Autodiscovery Protocol Type -- An SDNV that indicates the format of the domain-specific data and domain-specific procedures. This is described in Section 2.4. o Bundle Agent EID -- An optionally included field that conveys the bundle agent EID about which this autodiscovery message applies. To allow for third-party information, this may or may not be the same as the source EID. Like all DTN Bundle Protocol EIDs, this is a set of two offsets into the dictionary for the scheme and scheme-specific part of the EID in question. o Contact Start Time -- An optionally included field indicating the beginning point of a contact The time is encoded as a DTN Wyllie, et al. Expires October 3, 2007 [Page 6] Internet-Draft DTN Bundle Agent Discovery April 2007 timestamp as specified in [SB07]. o Contact End Time -- An optionally included field indicating the ending point of a contact, encoded as a DTN timestamp [SB07]. 2.1. Bundle Processing Control Flags The Bundle Processing Control Flags, outside the Autodiscovery Block itself, are to be set as follows: o Bundle Fragment -- Nominally, autodiscovery bundles will be small enough that fragmentation is never needed, but unless fragmentation is forbidden by a domain-specific application, autodiscovery bundles may be fragmented. This bit MUST be set according to the fragmentation guidelines in [SB07]. o Administrative Record -- Autodiscovery bundles are not administrative records; this bit MUST be clear. o Fragmentation Allowed -- As stated above, autodiscovery bundles may be fragmented at the discretion of the domain-specific rules. o Custody Transfer Required -- Since the autodiscovery information is advisory by nature, it does not require reliable transmission and custody transfer should never be required; this bit SHOULD always be clear. Furthermore, since bundles used for autodiscovery move over only a single overlay-hop, a Bundle Status Report is sufficient for acknowledgement without invoking custody transfer semantics. o Destination Endpoint is a Singleton -- In certain scenarios, it may make sense to define contact timings for large sets of nodes. Therefore, autodiscovery may take place between non-singleton endpoints, and autodiscovery messages may be multicast at the bundle layer and/or below. o Acknowledgement by application is requested -- As there is no 'application' associated with autodiscovery, this should not be necessary and the bit SHOULD be cleared. Therefore, the low-order Bundle Processing Control Flags SHOULD be set to: 000Z0Y0X where the value of X is determined by whether the current bundle is a fragment, the value of Y is determined by whether the domain-specific case allows for fragmentation, and the value of Z is determined by Wyllie, et al. Expires October 3, 2007 [Page 7] Internet-Draft DTN Bundle Agent Discovery April 2007 the number of intended destinations. 2.2. Block Processing Control Flags Block Processing Control Flags are defined for all block types in [SB07] and control how a bundling daemon should processes the block. The flags must be assigned as follows: o Block must be replicated in every fragment -- The Autodiscovery Block does not require replication in every fragment. As long as one Autodiscovery Block is present in the reassembled bundle, the payload can be parsed correctly. This bit SHOULD be clear. o Transmit status report if block can't be processed -- This bit can be set at the sender's discretion. o Delete bundle if block can't be processed -- As this block is the primary purpose of the bundle, it serves no use if it cannot be interpreted. This bit MUST be set. o Last block -- This may be set or cleared depending on block order. There is no reason why additional blocks could not follow this one (e.g. for security). o Discard block if it can't be processed -- The bundle will be discarded if the block cannot be processed; this bit MUST be clear. o Block was forwarded without being processed -- Autodiscovery bundles are never forwarded so this bit MUST be clear. o Block contains an EID-reference field -- This MUST be set for domain-independent bundles. Domain-specific payloads may contain EID-references, in which case this MUST be set. For other instances, this MUST be clear. 2.3. Autodiscovery Flags The bits of the Autodiscovery Flags indicate which optional fields of the Autodiscovery Block are present, and are explained in detail below: Bit 0 -- Bundle Agent EID Present Bit 1 -- Start Time Present Bit 2 -- End Time Present Bit 3-7 -- Reserved Wyllie, et al. Expires October 3, 2007 [Page 8] Internet-Draft DTN Bundle Agent Discovery April 2007 o Bundle Agent EID Present -- If this bit is set, then the Autodiscovery Block includes the Bundle Agent EID field. If this bit is clear, then the Source EID in the Primary Bundle Block is assumed. o Start Time Present -- If this bit is set, then the Autodiscovery Block includes a Contact Start Time field. A sender can either indicate a specific time when a predicted future contact may start, or this bit can be clear (and the corresponding field omitted) to indicate an immediate contact. If this bit is set, then a Contact Start Time field MUST be included in the Autodiscovery Block; if the bit is cleared, then that field MUST NOT be present. o End Time Present -- If this bit is set, then the Autodiscovery Block includes a Contact End Time field. A sender can either indicate a specific time when a contact will end between two nodes or it can be omitted to specify "indefinitely" or "unknown". If this bit is set, then a Contact End Time field MUST be included in the Autodiscovery Block; if the bit is cleared, then that field MUST NOT be present. 2.4. Autodiscovery Protocol Type Domain-specific information is contained solely within the payload of an autodiscovery bundle. The format of the payload varies by domain. If an autodiscovery bundle contains domain-specific information, this field indicates the structure of the payload data. Effectively, this field defines the "domain" of the domain-specific portion. Currently, the following fields are defined: o 0x00 -- Basic - no domain-specific information; payload MUST be empty o 0x01 -- DMC-like Satellites - payload format defined in a separate document o 0x02 through 0xEF -- Currently undefined; can be defined in later documents o 0xF0 through 0xFF -- Experimental 2.5. Capabilities Flags Two BAs in-contact may differ significantly in their respective capabilities. A node might refuse to take custody of bundles, run out of storage space, or be willing to route bundles elsewhere. These capabilities may impact scheduling and forwarding decisions. Wyllie, et al. Expires October 3, 2007 [Page 9] Internet-Draft DTN Bundle Agent Discovery April 2007 Only those features which are inherent to virtually all DTN nodes are listed here: additional features which are specific to a certain DTN domain should be communicated in a domain-specific bundle. The flags are listed as a SDNV as follows: Bit 0 -- Node is currently willing and able to take custody of bundles within the contact Bit 1 -- Node is currently willing and able to forward bundles within the contact Bit 2 -- Node can receive bundles within the contact Bit 3 -- Node can send bundles within the contact Bit 4 -- Node supports the "dtn:" EID scheme Bit 5 -- Node supports DTN Bundle Security with default algorithms Bit 6 -- Node supports single-datagram UDP convergence layer Bit 7 -- Node supports TCPCL Bit 8 -- Node supports Saratoga convergence layer Each of these bits, when set, indicates that the capability is present, and when clear indicates that it is not. Wyllie, et al. Expires October 3, 2007 [Page 10] Internet-Draft DTN Bundle Agent Discovery April 2007 3. Processing Behavior Due to the domain-specific portions of autodiscovery, exact processing of autodiscovery bundles can vary widely between domains. Therefore, only a general framework for autodiscovery bundle processing is given in this document while exact autodiscovery procedures for particular domains is defined separately. Autodiscovery functions can either be implemented within a BA, or as one or more external 'helper' applications. An interface supporting both types of implementation are outlined below. Although a helper application may assist in interpreting autodiscovery payloads, autodiscovery is not itself a DTN application. Autodiscovery bundles are addressed to the administrative endpoints of BAs themselves, whose EIDs are not suffixed with an application de-muxing token, or otherwise altered. In this way, autodiscovery works for all EID schemes regardless of how endpoint EIDs are constructed within them. 3.1. Exported Bundling Agent Interface When external autodiscovery code is being used, the cooperating BA MUST provide an API which, in addition to the basic bundling API as defined in [SB07], allows for the autodiscovery code to communicate to create bundles for transmission with explicit values specified for the following fields: o Local Convergence Layer Adapter for transmission o Destination EID o Bundle Processing Control Flags, conforming to Section 2.2 o Autodiscovery Block Processing Control Flags, conforming to Section 2.2 o Autodiscovery Flags, conforming to Section 2.3 o Autodiscovery protocol type o Bundle Agent EID o Contact Start Time as a DTN timestamp o Contact End Time as a DTN timestamp o Bundle Payload, containing domain-specific data in some number of opaque bytes Wyllie, et al. Expires October 3, 2007 [Page 11] Internet-Draft DTN Bundle Agent Discovery April 2007 Based on the Autodiscovery Flags, a BA usually constructs an Autodiscovery Block from the other parameters. Depending on the Autodiscovery Flags, some of these fields may be omitted. The Bundle Agent EID parameter may be optional, and filled in by the Bundle Agent itself, using its administrative EID, if not present. The generated bundle's Source EID is the administrative endpoint of the bundle agent servicing the request. A Bundle Lifetime of zero must be used to squelch DTN-level forwarding of the bundle. Exactly how this interface is supplied (e.g. via IPC, RPC, etc) is an implementation-specific consideration. A BA SHOULD use the "expedited" priority for all autodiscovery bundles, given that they may affect immediate decisions and are typically small bundles, although this interface MAY be extended in some implementations to allow the priority to be specified. 3.2. Bundling Daemon Autodiscovery Request Handling Requests for autodiscovery will be honored as long as the supplied parameters are valid and the requested convergence layer adapter exists and is capable of sending bundles. Upon receiving a request to initiate autodiscovery, the BA MUST initiate this procedure regardless of its current knowledge of contacts. It will, however, maintain its current contact information base entries at least until autodiscovery completes. 3.3. Processing of Received Autodiscovery Bundles Processing of incoming autodiscovery responses proceeds differently depending on the Autodiscovery Type field: Basic (fully domain-independent): A domain-independent bundle can be processed entirely within any bundle agent capable of autodiscovery. The bundle payload MUST be ignored (and should be empty), and the contact information given in the Autodiscovery Block can be used to update the contact information base at the bundle agent's discretion. Non-Zero (domain-specific): Upon reception of an Autodiscovery Bundle with a domain-specific payload (indicated by a non-zero Autodiscovery Type code), the bundle agent can either process the payload itself (if it understands the autodiscovery protocol used) or may hand the payload and Autodiscovery Block fields to external autodiscovery code that can suggest changes to the bundle agent's contact information base after processing. Wyllie, et al. Expires October 3, 2007 [Page 12] Internet-Draft DTN Bundle Agent Discovery April 2007 It is possible that after receiving an Autodiscovery Bundle, a bundle agent will wish to advertise its own view of contact information in response. This is fully at the discretion of the bundle agent or external autodiscovery code. 3.4. Bundle Status Reports As any bundle sender can request a Bundle Status Report (a Bundle Reception Status Report in this case), Autodiscovery Bundles may also be acknowledged using this mechanism, if desired. These could be utilized by a bundle agent or external autodiscovery code in order to suppress retransmission of autodiscovery information, for instance, when sending over unreliable convergence layer adapters that lack feedback of their own (e.g. single-packet UDP). This is not necessary in all domains, and since information gained through autodiscovery is generally advisory, it is assumed that Bundle Status Reports will not be frequently requested for Autodiscovery Bundles. Wyllie, et al. Expires October 3, 2007 [Page 13] Internet-Draft DTN Bundle Agent Discovery April 2007 4. Examples 4.1. Sensor Node to Sensor Node In this example, dozens of sensor nodes are deployed in an area without any infrastructure and must discover one another in order to communicate at the bundle layer. All nodes are connected on the same network. Exact discovery would depend on the domain-specific protocol used, but it could look similar to the the diagram below: Sensor node Sensor node (s) MULTICAST HELLO -----------------> <----------------- HELLO / BATTERY LIFE (s) (consults signal power level) (consults battery life) (i) CALCULATED CONTACT TIME ---------------> <----------------- BUNDLE RECEIVED 4.2. Deep-Space Probe to Earth Discovery In this example, a deep-space node has a set contact schedule with Earth nodes established prior to each window of communication. Due to some event that causes re-allocation of ground-station resources, changing the space probe's schedule may be necessary. Deep-Space Satellite Earth Node (i) <----------------------------- CONTACT TIME 4.3. LEO Satellites to Terrestrial Center Many LEO satellites are particularly concerned with optimizing link utilization, and primarly send data downwards. Contacts with ground stations can be brief, on the order of several minutes, so synchronizing clocks and getting the BA onboard a satellite to be ready to forward at the correct time can be accomplished through autodiscovery. The authoritative timing figure would be the terrestrial station, which would asynchronously send contact time information to the satellite on some schedule that let it optimize its forwarding decisions to avoid reactive fragmentation due to interrupted transfers and possibly to ensure that transmission preconditions are met before the contact (transmitter powered up, on correct frequency, using correct modulation and coding, etc.). Wyllie, et al. Expires October 3, 2007 [Page 14] Internet-Draft DTN Bundle Agent Discovery April 2007 LEO Satellite Earth Node (consults ephemeris data) <-------------------- CONTACT TIME (i) (time a1, time a2) ASYNC. DATA --------------------> <-------------------- CONTACT TIME (i) (time b1, time b2) <-------------------- CONTACT TIME (i) (time c1, time c2) ASYNC. DATA --------------------> 4.4. A Note on Flexibility The lack of structure in the protocol is due to the necessary flexibility in deployment. The domain-independent timing packets are meant to give a universal way to apply discovery and timing principles to any DTN environment that does not currently exist. The domain-dependent part is meant to add the needed flexibility to adhere to all DTN environments. Consequently, there is no 'typical' example that generalizes all DTN neighbor discovery. More specific examples of neighbor discovery can be found in documentation describing domain-specific exchanges. Wyllie, et al. Expires October 3, 2007 [Page 15] Internet-Draft DTN Bundle Agent Discovery April 2007 5. Security Considerations Nearly all threats that apply to other neighbor discovery protocols apply to DTN neighbor discovery. As suggested in [RFC3756], many of these are solved by ensuring a 'trusted' network. Networks that are not trusted are subject to different limitations (and expectations), so we deal with probable attacks and mitigations for each network separately. 5.1. Security in a Trusted Network Unlike general networking in the Internet, in DTN scenarios, there are many cases where a 'stranger' on the network is an unexpected condition. For example, sensor networks in poorly-connected environments are often controlled by a single organization which grants connection to only approved nodes. This may be implemented through link-layer encryption, keying of spreading sequences, or other means. Currently, as these two deployment environments are the two major proposed uses for DTN, securing the 'trusted' network against attack deserves further consideration. The most likely attack on a trusted network is an attack where a node infiltrates a closed network, masquerading as a trusted node using a trusted address. To mitigate this attack, one could pre-share symmetric keys and use encryption with nodes that are allowed on the closed network. Blocks to accomplish this are defined in [DTNSEC]. All aspects of neighbor discovery, therefore, could be encrypted using these keys. In this manner, no nodes lacking the pre-shared key (and, by extension, permission to use the network) can communicate on the network. In nodes that can afford the overhead of public-key cryptography, [DTNSEC] also supports X.509 certificate processing. This would be more desirable for nodes that may communicate with many entities (such as the international space station) that each require separate keys (such as member nations with varying levels of cooperation). If necessary, this would also help protect the system from a single point of failure as in the pre-shared key system, only one pre-shared key needs to be compromised to compromise an entire system. 5.2. Security in an Untrusted Network Though many currently proposed deployments of DTN involve closed networks, future DTN networks may include untrusted public networks [haggle]. For example, a DTN node on a public transportation system may send a bundle to a curbside receiver which would then forward it through the network. As part of public transportation, it is impossible to guarantee trust to nodes on the network, so the above Wyllie, et al. Expires October 3, 2007 [Page 16] Internet-Draft DTN Bundle Agent Discovery April 2007 system will not work. In this environment, likely attacks generally are some variation of man-in-the-middle attacks. For instance, a PDA on the public transportation system may masquerade as a router and sniff traffic or deny it altogether. As stated in [RFC4251], there is no known way to prevent these attacks outright. To help mitigate these attacks, we propose a 'fingerprint' system combined with public-key cryptography. If a node considers the above attack serious enough, it can require public-key cryptography as provided in [DTNSEC], storing the fingerprint of the server's public key. In a man-in-the-middle attack, the fingerprint would change, and the user could be notified in an appropriate way. This system is very similar to the fingerprinting system currently in widespread use in SSHv2 [RFC4251]. Due to the potentially severe limitations on processing power and bandwidth of DTN nodes, all of the above security is optional with respect to neighbor discovery. In many deployments, the costs may simply outweigh the benefits. Wyllie, et al. Expires October 3, 2007 [Page 17] Internet-Draft DTN Bundle Agent Discovery April 2007 6. IANA Considerations This document does not update or create any IANA registries. Wyllie, et al. Expires October 3, 2007 [Page 18] Internet-Draft DTN Bundle Agent Discovery April 2007 7. Acknowledgements Some of the work on this document was performed at NASA's Glenn Research Center with funding provided by NASA's Earth Science Technology Office. Wyllie, et al. Expires October 3, 2007 [Page 19] Internet-Draft DTN Bundle Agent Discovery April 2007 8. Informative References [DTNSEC] Symington, S. and S. Farrell, "Bundle Security Protocol Specification", draft-irtf-dtnrg-bundle-security (work in progress), April 24 2007. [I-D.eddy-dtn-sdnv] Eddy, W., "Using Self-Delimiting Numeric Values in Protocols", draft-eddy-dtn-sdnv-02 (work in progress), December 2006. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. [RFC3756] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor Discovery (ND) Trust Models and Threats", RFC 3756, May 2004. [RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Protocol Architecture", RFC 4251, January 2006. [RFC4838] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst, R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant Networking Architecture", RFC 4838, April 2007. [SB07] Scott, K. and S. Burleigh, "Bundle Protocol Specification", draft-irtf-dtnrg-bundle-spec-09 (work in progress), April 2007. [haggle] Scott, J., Hui, P., Crowcroft, J., and C. Diot, "Haggle: A Networking Architecture Designed Around Mobile Users", IFIP WONS, Les Menuires, France, January 2006. Wyllie, et al. Expires October 3, 2007 [Page 20] Internet-Draft DTN Bundle Agent Discovery April 2007 Authors' Addresses Jim Wyllie Ohio University EECS Department #18 Stocker Center Athens, OH 45701 Phone: +1-740-593-1562 Email: jw280601@ohiou.edu 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 Joseph Ishac NASA Glenn Research Center 21000 Brookpark Road Cleveland, Ohio 44135 USA Phone: +1-216-433-6587 Fax: +1-216-433-8705 Email: jishac@nasa.gov Will Ivancic NASA Glenn Research Center 21000 Brookpark Road Cleveland, Ohio 44135 USA Phone: +1-216-433-3494 Fax: +1-216-433-8705 Email: William.D.Ivancic@nasa.gov Wyllie, et al. Expires October 3, 2007 [Page 21] Internet-Draft DTN Bundle Agent Discovery April 2007 Shawn Ostermann Ohio University Department of Computer Science 322b Stocker Center Athens, Ohio 45701 Phone: +1-740-593-1234 Email: ostermann@cs.ohiou.edu Wyllie, et al. Expires October 3, 2007 [Page 22] Internet-Draft DTN Bundle Agent Discovery April 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Wyllie, et al. Expires October 3, 2007 [Page 23]