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