Network Working Group J. Wyllie
Internet-Draft Ohio University
Intended status: Experimental W. Eddy
Expires: May 21, 2008 Verizon
J. Ishac
W. Ivancic
NASA
S. Ostermann
Ohio University
November 18, 2007
Automated Bundle Agent Discovery for Delay/Disruption-Tolerant
Networking
draft-wyllie-dtnrg-badisc-01
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 May 21, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Wyllie, et al. Expires May 21, 2008 [Page 1]
Internet-Draft DTN Bundle Agent Discovery November 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 . . . . . . . . . . . . . 6
2.2. Autodiscovery Message Format . . . . . . . . . . . . . . . 7
2.3. Autodiscovery Flags . . . . . . . . . . . . . . . . . . . 8
2.4. Capabilities . . . . . . . . . . . . . . . . . . . . . . . 8
2.4.1. Convergence Layers Supported . . . . . . . . . . . . . 9
2.4.2. Grokability of Schemes . . . . . . . . . . . . . . . . 9
2.4.3. Structure of the Capabilities SDNVs . . . . . . . . . 9
2.5. Autodiscovery Protocol Type . . . . . . . . . . . . . . . 10
3. Convergence Layer Behavior . . . . . . . . . . . . . . . . . . 11
4. Processing Behavior . . . . . . . . . . . . . . . . . . . . . 12
4.1. Exported Bundling Agent Interface . . . . . . . . . . . . 12
4.2. Bundling Daemon Autodiscovery Request Handling . . . . . . 12
4.3. Processing of Received Autodiscovery Bundles . . . . . . . 13
4.4. Adding and Overwriting Contact Times . . . . . . . . . . . 13
4.5. Bundle Status Reports . . . . . . . . . . . . . . . . . . 14
5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
5.1. Sensor Node to Sensor Node . . . . . . . . . . . . . . . . 15
5.2. Deep-Space Probe to Earth Discovery . . . . . . . . . . . 15
5.3. LEO Satellites to Terrestrial Center . . . . . . . . . . . 15
5.4. Updating and Overwriting Contacts . . . . . . . . . . . . 16
5.5. A Note on Flexibility . . . . . . . . . . . . . . . . . . 17
6. Security Considerations . . . . . . . . . . . . . . . . . . . 18
6.1. Security in a Trusted Network . . . . . . . . . . . . . . 18
6.2. Security in an Untrusted Network . . . . . . . . . . . . . 18
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21
9. Informative References . . . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24
Intellectual Property and Copyright Statements . . . . . . . . . . 26
Wyllie, et al. Expires May 21, 2008 [Page 2]
Internet-Draft DTN Bundle Agent Discovery November 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 3 and Section 2, and a description of
the rules for generating and processing these messages in Section 4.
In addition, Section 5 contains example message exchanges to clarify
Wyllie, et al. Expires May 21, 2008 [Page 3]
Internet-Draft DTN Bundle Agent Discovery November 2007
the 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: for example, 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 JPL's
implementation of the Asynchronous Message Service.
Wyllie, et al. Expires May 21, 2008 [Page 4]
Internet-Draft DTN Bundle Agent Discovery November 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 schedules 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 6.
Wyllie, et al. Expires May 21, 2008 [Page 5]
Internet-Draft DTN Bundle Agent Discovery November 2007
2. Message Format
2.1. Bundle Processing Control Flags
Bundle Processing Control Flags MUST adhere to the following
guidelines:
o Bundle Fragment -- Nominally, autodiscovery bundles will be small
enough that fragmentation is never needed. However, 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
the number of intended destinations.
Wyllie, et al. Expires May 21, 2008 [Page 6]
Internet-Draft DTN Bundle Agent Discovery November 2007
2.2. Autodiscovery Message Format
In order to work regardless of the convergence layer adapters that
are available, BA autodiscovery uses DTN bundles to communicate its
data. More specifically, all autodiscovery data is encoded in the
payload block of the bundle. Some of the autodiscovery fields use
Self-Delimiting Numeric Values (SDNVs) [I-D.irtf-dtnrg-sdnv] within
the messaging format, as in several other parts of the Bundle
Protocol and its extensions.
Any bundles related to autodiscovery MUST contain the domain-
independent portion of the autodiscovery bundle, followed optionally
by the domain-specific portion. The fields should be ordered as
follows:
o Version -- 16-bit value specifying the autodiscovery version to
which this bundle adheres. This document defines version 0. A
daemon MUST drop any bundle with any other version number.
o Autodiscovery Flags -- SDNV-encoded field describing the contents
of the autodiscovery header. The meanings of the individual bits
within this field are defined in Section 2.3.
o Contact Start Time -- An optionally included field indicating the
beginning point of a contact. The time is encoded as a DTN
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 as specified
in [SB07].
o Pitcher -- An endpoint ID reference as specified in [SB07]
referring to the node designated as the 'pitcher' in the
connection.
o Catcher -- An endpoint ID reference as specified in [SB07]
referring to the node designated as the 'catcher in the
connection.
o Capabilities -- SDNV-encoded field describing the capabilities of
the node referred to by this block. This is described in
Section 2.4.
o Autodiscovery Protocol Type -- A 16-bit field that indicates the
format of the domain-specific data and domain-specific procedures.
This is described in Section 2.5.
Wyllie, et al. Expires May 21, 2008 [Page 7]
Internet-Draft DTN Bundle Agent Discovery November 2007
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 -- Start Time Present
Bit 1 -- End Time Present
Bit 2 -- Connection is bidirectional
Bit 3-7 -- Reserved
o Start Time Present -- If this bit is set, then the autodiscovery
message includes the 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 (or, put differently,
that the nodes can commence communication upon processing of the
autodiscovery bundle). If this bit is set, then a Contact Start
Time field MUST be included in the autodiscovery message; if the
bit is cleared, then that field MUST NOT be present.
o End Time Present -- If this bit is set, then the autodiscovery
message includes the Contact End Time field. If the field is
omitted, this means that the nodes will remain in contact for the
indefinite future. If this bit is set, then a Contact End Time
field MUST be included in the autodiscovery message; if the bit is
cleared, then that field MUST NOT be present.
o Connection is bidirectional -- If this bit is set, it signifies
that not only can the pitcher send to the catcher, but vice versa
as well. This establishes the two nodes as neighbors.
2.4. Capabilities
Though many capabilities could be considered domain-specific, some
capabilities are nearly ubiquitous in utility and relevance. Those
capabilities are defined here. To reduce bit overhead when not all
capabilities are relevant or desired, the capabilities are set as a
two-level SDNV. The top-level SDNV specifies which second-level
SDNVs are present in the bundle. Each second-level is a categorized
SDNV with flags signifying the presence or absence of some
capability.
Currently, two second-level SDNVs are defined. Therefore, the top-
level capabilities SDNV has the following values:
Wyllie, et al. Expires May 21, 2008 [Page 8]
Internet-Draft DTN Bundle Agent Discovery November 2007
o Convergence Layers Supported -- Setting this bit signifies the
presence of the convergence layer capabilities SDNV.
o Grokability of Schemes -- Setting this bit signifies the presence
of the schemes capabilities SDNV. Clearing this bit signifies
that the SDNV is absent from this bundle.
For any capabilities that are not defined, default values may be
chosen by the BA in an implementation-specific manner.
2.4.1. Convergence Layers Supported
This capabilities SDNV defines over which convergence layers the BA
can communicate. Setting the convergence layer bit indicates that
the convergence layer is understood; clearing indicates that it is
not. Currently, the SDNV is defined as follows:
o Bit 0 -- Single-packet UDP (one bundle per UDP packet)
o Bit 1 -- TCPCL, defined in [I-D.irtf-dtnrg-tcp-clayer]
o Bit 2 -- LTP, defined in [I-D.irtf-dtnrg-ltp]
o Bit 3 -- Saratoga, defined in [I-D.wood-tsvwg-saratoga]
o Bit 4 -- FLUTE, defined in [RFC3926]
o Bit 5-7 -- Reserved
2.4.2. Grokability of Schemes
This capabilities SDNV defines which EID schemes the BA can
understand. Currently, the SDNV defines the following:
o Bit 0 -- The BA understands the "dtn" scheme
o Bit 1 -- The BA understands the "ipn" scheme
2.4.3. Structure of the Capabilities SDNVs
All capabilities information is included as part of the
"capabilities" section of the discovery header. The top-level SDNV
MUST be present. If any of its bits are set, the accompanying SDNV
MUST be concatenated immediately following the top-level SDNV. If
multiple second-level SDNVs are indicated, they MUST be concatenated
together in the order in which they are indicated in the top-level
SDNV.
Wyllie, et al. Expires May 21, 2008 [Page 9]
Internet-Draft DTN Bundle Agent Discovery November 2007
2.5. Autodiscovery Protocol Type
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
Domain-specific information, in a bundle which has any, immediately
follows the payload of the autodiscovery message.
Wyllie, et al. Expires May 21, 2008 [Page 10]
Internet-Draft DTN Bundle Agent Discovery November 2007
3. Convergence Layer Behavior
Due to the nature of an overlay network, autodiscovery may take place
over many different convergence layers. In addition, depending on
the convergence layer used, convergence layer discovery might be
necessary prior to bundling discovery. For instance, when using
Bluetooth as a convergence layer, paired devices must undergo device
discovery and service discovery before encapsulated data (such as the
autodiscovery bundle) can be sent. Therefore, initiating
autodiscovery over Bluetooth for previously unknown devices will
require cooperation between device/service discovery and the bundling
layer [BTSPEC]. If any data obtained in service discovery is
relevant, it could be communicated as domain-specific information in
the discovery bundle. For the common terrestrial Internet protocols
TCP and UDP, discovery over TCP implies that the devices have
bidirectional communication where discovery over UDP can use
unidirectional communication and multicast. TCP requires handshaking
prior to bundle communication; UDP does not.
Certain capabilities of a convergence layer node may be relevant in
the bundling autodiscovery process. For instance, when using TCP, it
may be relevant to communicate the round-trip time (RTT) to the
bundle layer as it may impact routing decisions. Extra features like
this can be included as part of a domain-specific protocol.
The capabilities as described in are explicitly for the bundle layer.
Convergence layer-specific information (aside from their existence)
is purposefully not included there. Communicating relevant
convergence layer-specific information can be done in a domain-
specific protocol.
Due to the myriad convergence layers over which bundles are expected
to travel, exact mechanisms for executing bundle-layer autodiscovery
over convergence layers are outside the scope of this document and
are left as future work.
Wyllie, et al. Expires May 21, 2008 [Page 11]
Internet-Draft DTN Bundle Agent Discovery November 2007
4. 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 EIDs are constructed within them.
4.1. Exported Bundling Agent Interface
In addition to providing the basic bundling API as defined in [SB07],
the daemon SHOULD allow for explicit values specified for the
following fields in an outgoing bundle:
o Local Convergence Layer Adapter for transmission
o Destination EID -- SHOULD be set to dtn:discovery for discovery of
BAs with unknown EIDs; may be set to an actual EID if it is known
o Bundle Payload -- to include the autodiscovery message
o Lifetime -- A lifetime of 0 squelches forwarding of discovery
bundles.
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.
4.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.
Wyllie, et al. Expires May 21, 2008 [Page 12]
Internet-Draft DTN Bundle Agent Discovery November 2007
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.
4.3. Processing of Received Autodiscovery Bundles
Processing of incoming autodiscovery responses proceeds differently
depending on the Autodiscovery Type field:
Zero (fully domain-independent): A domain-independent bundle can be
processed entirely within any bundle agent capable of
autodiscovery. The contact information given in the autodiscovery
message 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
domain-specific payload itself (if it understands the
autodiscovery protocol used) or may hand the entire payload block
to external autodiscovery code that can suggest changes to the
bundle agent's contact information base after processing.
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.
4.4. Adding and Overwriting Contact Times
When a valid new contact is received, it will be updated according to
the following rules:
More recently-received and valid updates will always be added to the
BA. Only the contact window, pitcher EID, and catcher EID are
considered in decisions to keep or eliminate older discovery entries.
If no contact information about the pitcher and catcher currently
exists, or if contact information exists but does not overlap with
the time period specified in the received bundle, then the contact
information will be added to the BA without modification to existing
entries.
If contact information about the pitcher and catcher currently exists
and overlaps the time period specified in the received bundle at any
point in time, the now "outdated" entry should be deleted in its
entirety, including the part which does not overlap with the newly-
Wyllie, et al. Expires May 21, 2008 [Page 13]
Internet-Draft DTN Bundle Agent Discovery November 2007
received bundle. Other entries pertaining to the pitcher and catcher
which have no time overlap with the newly received bundles SHOULD be
retained.
More examples to illustrate the updating procedure can be found in
Section 5.4.
4.5. 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 May 21, 2008 [Page 14]
Internet-Draft DTN Bundle Agent Discovery November 2007
5. Examples
5.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
5.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
5.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
Wyllie, et al. Expires May 21, 2008 [Page 15]
Internet-Draft DTN Bundle Agent Discovery November 2007
preconditions are met before the contact (transmitter powered up, on
correct frequency, using correct modulation and coding, etc.).
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 -------------------->
5.4. Updating and Overwriting Contacts
This section provides examples for updating and overwriting contact
information depending on discovery bundles received.
Existing contact windows are numbered 1...n: the received bundle is
labeled X.
-------------------------- time --------------------------->
-------- ------------------------------
| 1 | | X |
-------- ------------------------------
-------------------------- time --------------------------->
Procedure: 1 is kept; X is added
-------------------------- time --------------------------->
-------- ---
| 1 | | 2 |
-------- ---
---------------------------------
| X |
---------------------------------
-------------------------- time --------------------------->
Wyllie, et al. Expires May 21, 2008 [Page 16]
Internet-Draft DTN Bundle Agent Discovery November 2007
Procedure: 1 is kept, 2 is removed, and X is added
-------------------------- time --------------------------->
-------- --- ------------ -----------
| 1 | | 2 | | 3 | | 4 |
-------- --- ------------ -----------
-----------------------
| X |
-----------------------
-------------------------- time --------------------------->
Procedure: 1 is kept, 2 and 3 are removed, 4 is kept, and X is added.
5.5. 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 May 21, 2008 [Page 17]
Internet-Draft DTN Bundle Agent Discovery November 2007
6. 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.
6.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.
6.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 May 21, 2008 [Page 18]
Internet-Draft DTN Bundle Agent Discovery November 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 May 21, 2008 [Page 19]
Internet-Draft DTN Bundle Agent Discovery November 2007
7. IANA Considerations
This document does not update or create any IANA registries.
Wyllie, et al. Expires May 21, 2008 [Page 20]
Internet-Draft DTN Bundle Agent Discovery November 2007
8. 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 May 21, 2008 [Page 21]
Internet-Draft DTN Bundle Agent Discovery November 2007
9. Informative References
[BTSPEC] "Specification of the Bluetooth System", July 2007.
[DTNSEC] Symington, S. and S. Farrell, "Bundle Security Protocol
Specification", draft-irtf-dtnrg-bundle-security (work in
progress), April 24 2007.
[I-D.irtf-dtnrg-ltp]
Ramadas, M., Burleigh, S., and S. Farrell, "Licklider
Transmission Protocol - Specification",
draft-irtf-dtnrg-ltp-07 (work in progress), October 2007.
[I-D.irtf-dtnrg-sdnv]
Eddy, W., "Using Self-Delimiting Numeric Values in
Protocols", draft-irtf-dtnrg-sdnv-00 (work in progress),
September 2007.
[I-D.irtf-dtnrg-tcp-clayer]
Demmer, M. and J. Ott, "Delay Tolerant Networking TCP
Convergence Layer Protocol",
draft-irtf-dtnrg-tcp-clayer-00 (work in progress),
July 2007.
[I-D.wood-tsvwg-saratoga]
Wood, L., McKim, J., Eddy, W., Ivancic, W., and C.
Jackson, "Saratoga: A Scalable File Transfer Protocol",
draft-wood-tsvwg-saratoga-00 (work in progress),
October 2007.
[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.
[RFC3926] Paila, T., Luby, M., Lehtonen, R., Roca, V., and R. Walsh,
"FLUTE - File Delivery over Unidirectional Transport",
RFC 3926, October 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
Wyllie, et al. Expires May 21, 2008 [Page 22]
Internet-Draft DTN Bundle Agent Discovery November 2007
Networking Architecture", RFC 4838, April 2007.
[SB07] Scott, K. and S. Burleigh, "Bundle Protocol
Specification", draft-irtf-dtnrg-bundle-spec-10 (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 May 21, 2008 [Page 23]
Internet-Draft DTN Bundle Agent Discovery November 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 May 21, 2008 [Page 24]
Internet-Draft DTN Bundle Agent Discovery November 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 May 21, 2008 [Page 25]
Internet-Draft DTN Bundle Agent Discovery November 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 May 21, 2008 [Page 26]