DTN Research Group S. Symington
Internet-Draft The MITRE Corporation
Intended status: Experimental February 17, 2009
Expires: August 21, 2009
Delay-Tolerant Networking Previous Hop Insertion Block
draft-irtf-dtnrg-bundle-previous-hop-block-05
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and 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 August 21, 2009.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document.
Symington Expires August 21, 2009 [Page 1]
Internet-Draft DTN Previous Hop Insertion Block February 2009
Abstract
This document defines an extension block that may be used with the
Bundle Protocol [refs.DTNBP] within the context of a Delay-Tolerant
Network architecture [refs.DTNarch]. This Previous Hop Insertion
Block is designed to be inserted by a forwarding node to provide
information to its next-hop receiving node. This block is always
removed from the bundle by the receiving node so that it's duration
within the bundle lasts for exactly one hop. It provides a general
insertion capability to enable any node that forwards a bundle to
insert an arbitrary record (or records) of information into the
bundle. While this block is defined to provide an arbitrary
insertion capability, this specification also defines two specific,
mandatory, information record formats for the information that may be
carried in the Previous Hop Insertion block. Using these mandatory
information record formats, an insertion block may be used to
indicate the inserting/forwarding node's endpoint ID (EID), which may
be required in some circumstances to support certain routing
protocols (e.g., flood routing). This document defines the format
and processing of this Previous Hop Insertion Block.
Symington Expires August 21, 2009 [Page 2]
Internet-Draft DTN Previous Hop Insertion Block February 2009
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Previous Hop Insertion Block Format . . . . . . . . . . . . . 6
3. Previous Hop Insertion Block Processing . . . . . . . . . . . 8
3.1. Bundle Transmission . . . . . . . . . . . . . . . . . . . 8
3.2. Bundle Forwarding . . . . . . . . . . . . . . . . . . . . 8
3.3. Bundle Reception . . . . . . . . . . . . . . . . . . . . . 8
4. Mandatory Information Record Formats . . . . . . . . . . . . . 9
4.1. EID-only . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.2. EID-with-Timestamp . . . . . . . . . . . . . . . . . . . . 9
5. Security Considerations . . . . . . . . . . . . . . . . . . . 10
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
7.1. Normative References . . . . . . . . . . . . . . . . . . . 12
7.2. Informative References . . . . . . . . . . . . . . . . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13
Symington Expires August 21, 2009 [Page 3]
Internet-Draft DTN Previous Hop Insertion Block February 2009
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 RFC 2119
[refs.RFC2119].
The DTN bundle protocol [refs.DTNBP] defines the bundle as its
protocol data unit. A bundle consists of a primary bundle block,
which is defined in the Bundle Protocol, followed by at least one
other type of bundle block. The Bundle Protocol defines a single
other type of bundle block, called a Bundle Payload block. This
document defines an additional, optional, bundle block called a
Previous Hop Insertion Block. This block is designed to be used by a
forwarding node to insert information into a bundle before forwarding
that bundle. The intent of this Previous Hop Insertion Block is to
provide a general insertion mechanism such that an arbitrary record
of information may be inserted into the bundle by a forwarding node
for consumption by the next-hop receiving node. The lifetime of the
Previous Hop Insertion Block is always exactly one hop in the DTN, so
if a bundle containing a Previous Hop Insertion Block is received,
the receiving node is assured that the information in this block was
inserted by the previous node; likewise, the information in this
block is not retained with the bundle when the bundle is forwarded.
The information record(s) to be inserted into the block may have any
content and format, providing the content and format have been
defined and documented in order to enable the information to be
understood. In this specification we define two specific information
record formats for use in the insertion block that MUST be supported.
Each of these formats includes a reference to the endpoint ID
information of the inserting node in the bundle's dictionary.
Insertion of a node's EID strings into the bundle dictionary (if not
already there) and insertion of a reference to those strings in a
bundle's Previous Hop Insertion Block enables the inserting/
forwarding node to provide its EID to its next-hop receiving node.
This previous-hop EID information may be required in some
circumstances to support various routing protocols (e.g., flood
routing). Although there may be some situations in which a node that
receives a bundle may be able to infer the EID of the node that
forwarded the bundle to it, there are other situations in which the
EID of the forwarding node will not be able to be inferred by the
receiving node. In these situations, if there is a requirement that
the receiving node be able to determine the EID of the forwarding
node, the forwarding node must provide this information in the
bundle. This specification defines a mechanism, i.e. the Previous
Hop Insertion Block, used in conjunction with either an EID-only or
an EID-with-timestamp information record format, whereby a node can
Symington Expires August 21, 2009 [Page 4]
Internet-Draft DTN Previous Hop Insertion Block February 2009
insert its EID (and possibly other information) into a bundle before
forwarding it.
Using the information record formats that are defined in this
document, the information that is provided in the insertion blocks at
each node may include not only the EID of the inserting/forwarding
node, but also a time stamp. This information may be further
expanded or altered through the future definition of additional
information record formats to provide an arbitrary information record
insertion capability. This document defines the format and
processing of the Previous Hop Insertion Block. It also defines two
mandatory information record formats.
The capabilities described in this document are OPTIONAL for
deployment with the Bundle Protocol. Bundle Protocol implementations
claiming to support Previous Hop Insertion Blocks MUST be capable of:
-Generating a Previous Hop Insertion Block and inserting it into a
bundle,
-Receiving bundles containing a Previous Hop Insertion Block and
making the information contained in this Previous Hop Insertion
Block available for use, e.g., in forwarding decisions.
-Deleting a Previous Hop Insertion Block from a bundle
-Adding strings to a bundle's dictionary, and references to those
strings to the bundle's Previous Hop Insertion Block.
as defined in this document.
Symington Expires August 21, 2009 [Page 5]
Internet-Draft DTN Previous Hop Insertion Block February 2009
2. Previous Hop Insertion Block Format
The Previous Hop Insertion Block uses the Canonical Bundle Block
Format as defined in the bundle protocol [refs.DTNBP]. That is, it
is comprised of the following elements:
-Block-type code (one byte) - defined as in all bundle protocol
blocks except the primary bundle block (as described in the Bundle
Protocol). The block type code for the Previous Hop Insertion
Block is 0x05.
-Block processing control flags (SDNV) - defined as in all bundle
protocol blocks except the primary bundle block (SDNV encoding is
described in the Bundle Protocol). The following block processing
control flag MUST be set:
-Discard block if it can't be processed.
- Block EID reference count and EID reference (optional) -
composite field defined in [refs.DTNBP] containing a count of EID
references (expressed as an SDNV) followed by one or more EID
references (each of which is expressed as a pair of SDNVs).
Whether or not this field must be present in the block is
determined by the information record format (see Section 4) being
used by the block. Presence of this field is indicated by the
setting of the "block contains an EID reference field" flag in the
block processing control flags.
-Block data length (SDNV) - defined as in all bundle protocol
blocks except the primary bundle block. SDNV encoding is
described in the Bundle Protocol.
-Block-type-specific data field as follows:
-Information Record Format ID (SDNV) - Its value identifies the
format of the information record that comes later in the block.
Some mandatory information record formats are specified in
Section 4. Additional information record formats MAY be
defined in separate specifications.
-Information Record (optional) - Contains the data being
inserted by the forwarding node, formatted as identified by the
value of the Information Record Format ID field. Whether or
not this field must be present in the block is determined by
the information record format (see Section 4) being used by the
block.
The Structure of a Previous Hop Insertion Block is as follows:
Symington Expires August 21, 2009 [Page 6]
Internet-Draft DTN Previous Hop Insertion Block February 2009
Previous Hop Insertion Block Format:
+------+--------------+------------------------------+--------------+
|type |flags (SDNV) |EID ref count and list (comp) |length (SDNV) |
+------+--------------+------------------------------+--------------+
| Information Record Format ID (SDNV)| Information Record (optional)|
+-------------------------------------------------------------------+
Figure 1
Symington Expires August 21, 2009 [Page 7]
Internet-Draft DTN Previous Hop Insertion Block February 2009
3. Previous Hop Insertion Block Processing
The following are the processing steps that a bundle node must take
relative to generation, reception, and processing of Previous Hop
Insertion Blocks.
3.1. Bundle Transmission
When an outbound bundle is created per the parameters of the bundle
transmission request, this bundle MAY (as influenced by local policy)
include one or more Previous Hop Insertion Blocks (as defined in this
specification).
3.2. Bundle Forwarding
Before forwarding a bundle, the node SHALL delete all of the Previous
Hop Insertion Blocks that were in the bundle when it was received.
The node MAY delete all strings (scheme names and scheme-specific
parts--SSPs) in the bundle's dictionary to which no endpoint ID
references in the bundle currently refer (if any).
The node MAY insert one or more Previous Hop Insertion Blocks into
the bundle before forwarding it, as dictated by local policy. The
node MAY insert strings into the bundle's dictionary (if needed) that
are referenced by the Previous Hop Insertion Block.
3.3. Bundle Reception
If the bundle includes one or more Previous Hop Insertion Blocks, the
information records in these blocks SHALL be made available for use
at this node (e.g., in forwarding decisions).
Symington Expires August 21, 2009 [Page 8]
Internet-Draft DTN Previous Hop Insertion Block February 2009
4. Mandatory Information Record Formats
This section defines the mandatory information record formats for
this specification. Additional formats may be defined elsewhere.
4.1. EID-only
The EID-only record format has information record-format ID
0x00000001.
When the EID-only record format is being used, the "Block contains an
EID-reference field" block processing control flag MUST be set,
indicating that the Block EID reference count and EID references
field is present in the block. The count of EID references in this
field MUST have a value of 1, and this count MUST be followed by a
single EID reference (expressed as a pair of SDNVs). This EID
reference must be that of the node that is forwarding the bundle.
The EID-only record format does not contain an information record
field.
4.2. EID-with-Timestamp
The EID-with-Timestamp record format has record-format ID 0x00000002.
When the EID-with-Timestamp record format is being used, the "Block
contains an EID-reference field" block processing control flag MUST
be set, indicating that the Block EID reference count and EID
references field is present in the block. The count of EID
references in this field MUST have a value of 1, and this count MUST
be followed by a single EID reference (expressed as a pair of SDNVs).
This EID reference must be that of the node that is forwarding the
bundle.
The EID-with-Timestamp record format information record field
consists of a single "Elapsed Time" field, which is expressed as an
SDNV. The value in the elapsed time field indicates the time at
which the bundle is being processed by the forwarding node, encoded
as a number of seconds past the bundle's creation time.
Symington Expires August 21, 2009 [Page 9]
Internet-Draft DTN Previous Hop Insertion Block February 2009
5. Security Considerations
The DTN Bundle Security Protocol [refs.DTNBPsec] and the DTN Security
Overview [refs.DTNsecOver] define three security-related blocks to
provide hop-by-hop authentication, end-to-end authentication, and
end-to-end confidentiality of bundles or parts of bundles, as well as
a set of mandatory ciphersuites that may be used to calculate
security results carried in these security blocks. All ciphersuites
that use the strict canonicalisation algorithm [refs.DTNBPsec] to
calculate and verify security results (e.g., many hop-by-hop
authentication ciphersuites) apply to all blocks in the bundle, and
so would apply to bundles that include an optional Previous Hop
Insertion Block and would include that block in the calculation of
their security result. In particular, bundles including the optional
Previous Hop Insertion Block would be protected in their entirety for
the duration of a single hop, from a forwarding node to an adjacent
receiving node (but not from source to destination), using the
mandatory BAH-HMAC ciphersuite defined in the Bundle Security
Protocol. Ciphersuites that use the mutable canonicalisation
algorithm to calculate and verify security results (e.g., the
mandatory PSH-RSA-SHA256 ciphersuite and most end-to-end
authentication ciphersuites) will (correctly) omit the Previous Hop
Insertion Block from their calculation. The fact that several
different instantiations of this block may be present in the bundle
as the bundle transits the network will not interfere with end-to-end
security protection when using ciphersuites that use mutable
canonicalisation. Lastly, the Previous Hop Insertion Block will not
be encrypted by the mandatory CH-RSA-AES-PAYLOAD-PSH end-to-end
confidentiality ciphersuite, which only allows for payload and PSH
encryption. If encryption of this block is desired, a ciphersuite
would need to be defined for this purpose.
Symington Expires August 21, 2009 [Page 10]
Internet-Draft DTN Previous Hop Insertion Block February 2009
6. IANA Considerations
If the bundle protocol becomes a standards track protocol, then we
may want to consider having IANA establish a register of block types,
of which the Previous Hop Insertion Block would be one. In addition,
we may want IANA to establish a separate register of information
record formats specific to the Previous Hop Insertion Block.
Symington Expires August 21, 2009 [Page 11]
Internet-Draft DTN Previous Hop Insertion Block February 2009
7. References
7.1. Normative References
[refs.RFC2119]
Bradner, S. and J. Reynolds, "Key words for use in RFCs to
Indicate Requirement Levels", RFC 2119, October 1997.
[refs.DTNBP]
Scott, K. and S. Burleigh, "Bundle Protocol
Specification", RFC 5050, November 2007.
[refs.DTNBPsec]
Symington, S., Farrell, S., Weiss, H., and P. Lovell,
"Bundle Security Protocol Specification",
draft-irtf-dtnrg-bundle-security-06.txt, work-in-progress,
November 2008.
7.2. Informative References
[refs.DTNarch]
Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst,
R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant
Network Architecture", RFC 4838, April 2007.
[refs.DTNsecOver]
Farrell, S., Symington, S., Weiss, H., and P. Lovell,
"Delay-Tolerant Network Security Overview",
draft-irtf-dtnrg-sec-overview-05.txt, work-in-progress,
November 2008.
Symington Expires August 21, 2009 [Page 12]
Internet-Draft DTN Previous Hop Insertion Block February 2009
Author's Address
Susan Flynn Symington
The MITRE Corporation
7515 Colshire Drive
McLean, VA 22102
US
Phone: +1 (703) 983-7209
Email: susan@mitre.org
URI: http://mitre.org/
Symington Expires August 21, 2009 [Page 13]
