One document matched: draft-irtf-dtnrg-bundle-encapsulation-04.txt
Differences from draft-irtf-dtnrg-bundle-encapsulation-03.txt
DTN Research Group S. Symington
Internet-Draft R. Durst
Intended status: Experimental K. Scott
Expires: May 4, 2009 The MITRE Corporation
October 31, 2008
Delay-Tolerant Networking Bundle-in-Bundle Encapsulation
draft-irtf-dtnrg-bundle-encapsulation-04
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 4, 2009.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Symington, et al. Expires May 4, 2009 [Page 1]
Internet-Draft DTN Bundle-in-Bundle Encapsulation October 2008
Abstract
This document defines an extension block that may be used with the
Bundle Protocol [2] within the context of a Delay-Tolerant Network
architecture [6]. When included as part of a given bundle B, this
extension block, called a Bundle-in-Bundle Encapsulation Block,
indicates that one or more other bundles have been placed inside of
the payload field of B's Bundle Payload Block according to the format
defined in this document. Hence, the Bundle-in-Bundle Encapsulation
Block provides a mechanism for bundle-in-bundle encapsulation by
indicating that one or more bundles are being transmitted as the
payload of a bundle. This extension block is expected to be of
general utility in DTN. It may be used, for example, to encapsulate
a multicast bundle inside of a unicast bundle, or to encapsulate a
bundle with one type of security protection inside of a bundle with a
different type of security protection. This document defines the
format and processing of this new Bundle-in-Bundle Encapsulation
Block and the contents of the Bundle Payload Block accompanying it.
Symington, et al. Expires May 4, 2009 [Page 2]
Internet-Draft DTN Bundle-in-Bundle Encapsulation October 2008
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Bundle-in-Bundle Encapsulation Block Format . . . . . . . . . 5
3. Bundle-in-Bundle Encapsulation Block Processing . . . . . . . 7
3.1. Generation and Transmission of an Encapsulating Bundle . . 7
3.2. Receipt and Processing of an Encapsulating Bundle . . . . 9
4. Security Considerations . . . . . . . . . . . . . . . . . . . 11
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
6.1. Normative References . . . . . . . . . . . . . . . . . . . 14
6.2. Informative References . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
Intellectual Property and Copyright Statements . . . . . . . . . . 16
Symington, et al. Expires May 4, 2009 [Page 3]
Internet-Draft DTN Bundle-in-Bundle Encapsulation October 2008
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 [1].
The DTN bundle protocol [2] defines the bundle as its protocol data
unit. A bundle consists of a primary bundle block followed by at
least one other type of bundle block. The Bundle Protocol currently
defines a single other type of bundle block, called a Bundle Payload
block. This document defines an additional, optional, bundle block
called a Bundle-in-Bundle Encapsulation Block. The presence of this
Bundle-in-Bundle Encapsulation Block in a bundle B indicates that one
or more other bundles have been placed inside of the payload field of
B's Bundle Payload Block according to the format defined in this
document. Hence, the Bundle-in-Bundle Encapsulation Block provides a
mechanism for bundle-in-bundle encapsulation by indicating that one
or more bundles are being transmitted as the payload of a bundle.
This extension block is expected to be of general utility in DTN. It
may be used, for example, to encapsulate a multicast bundle inside of
a unicast bundle, or to encapsulate a bundle with one type of
security protection inside of a bundle with a different type of
security protection. This document defines the format and processing
of this new Bundle-in-Bundle Encapsulation Block and the contents of
the Bundle Payload Block accompanying it.
The capabilities described in this document are OPTIONAL for
deployment with the Bundle Protocol. Bundle Protocol implementations
claiming to support bundle-in-bundle encapsulation MUST be capable of
both:
-generating and transmitting bundles containing Bundle-in-Bundle
Encapsulation Blocks, and
-receiving and processing bundles containing Bundle-in-Bundle
Encapsulation Blocks
as defined in this document.
Symington, et al. Expires May 4, 2009 [Page 4]
Internet-Draft DTN Bundle-in-Bundle Encapsulation October 2008
2. Bundle-in-Bundle Encapsulation Block Format
The Bundle-in-Bundle Encapsulation Block uses the Canonical Bundle
Block Format as defined in the bundle protocol [2]. That is, it is
comprised of the following elements:
-Block-type code (1 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 Bundle-in-Bundle
Encapsulation Block is 0x10.
-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. Constraints on the values of
the Block Processing Control Flags are as follows:
-The "Delete bundle if block can't be processed" flag MUST NOT
be set.
-The "Discard block if it can't be processed" flag MUST NOT be
set.
-The "Block contains and EID-reference field" flag MUST NOT be
set.
-EID references (optional) - This composite field defined in the
bundle protocol MUST NOT be present.
-Block data length (SDNV) - defined as in all bundle protocol
blocks except the primary bundle block. SDNV encoding is
described in the bundle protocol. If the value of the SDNV in
this field is 0, there are no remaining fields in the block, which
indicates that exactly one bundle is present in the payload field
of the bundle's Bundle Payload Block.
-Block-type-specific data fields as follows:
- Number of Encapsulated Bundles field (SDNV) (optional) -
indicates the number N of bundles that are present in the
payload field of the bundle's Bundle Payload Block, where N
MUST be greater than 1. (If only 1 bundle is present in the
payload field of the Bundle Payload Block, the Number of
Encapsulated Bundles field MUST NOT be present in the Bundle-
in-Bundle Encapsulation block.)
- Bundle Offsets List (optional) - contains the list of N-1
offsets (each of which is an SDNV) of the beginning of each
bundle that is located in payload field of the Bundle Payload
Symington, et al. Expires May 4, 2009 [Page 5]
Internet-Draft DTN Bundle-in-Bundle Encapsulation October 2008
Block after the first bundle in that field. (The offset of the
first bundle in the Bundle Payload Block is understood to be
0.) (If only 1 bundle is present in the payload field of the
Bundle Payload Block, the Bundle Offsets List field MUST NOT be
present in the Bundle-in-Bundle Encapsulation block.)
The format of the bundle-in-bundle encapsulation block is as follows:
Bundle-in-Bundle Encapsulation Block Format:
+-----+------+------+------------------------+-----------------+
|Type |Flags |Len | Number of Encapsulated | Bundle Offsets |
| |(SDNV)|(SDNV)| Bundles(SDNV)(opt.) | List (opt.) |
+-----+------+------+------------------------+-----------------+
Figure 1
Symington, et al. Expires May 4, 2009 [Page 6]
Internet-Draft DTN Bundle-in-Bundle Encapsulation October 2008
3. Bundle-in-Bundle Encapsulation Block Processing
Instead of forwarding one or more bundles, a node MAY, according to
local policy, encapsulate those bundle(s) by generating a new
(encapsulating) bundle, placing the bundle(s) to be encapsulated into
the payload field of the new bundle's Bundle Payload Block, creating
a Bundle-in-Bundle Encapsulation block for the new bundle that
includes the Number of Encapsulated Bundles (if greater than 1) and
the offsets of the start of each encapsulated bundle (after the first
bundle) in the payload field (if more than one bundle is
encapsulated), and forwarding this new encapsulating bundle. The
details of the processing steps that must occur and the values that
must be placed in the fields of various blocks of the encapsulating
bundle are described in section 3.1 below.
Upon receipt of a bundle that has a Bundle-in-Bundle Encapsulation
block at a node that is a member of the destination EID of the
bundle, the bundle is delivered to the application-specific element
of the destination node that is responsible for bundle de-
encapsulation. This application-specific element extracts the
bundle(s) from the encapsulating bundle's payload field and directs
the bundle protocol agent to process each of these bundle(s) as if it
had just been received from another node. Again, the details of the
processing steps that must occur are described in section 3.2 below.
3.1. Generation and Transmission of an Encapsulating Bundle
To take a bundle (or bundles) and forward this bundle(s) within the
payload field of another bundle, a node must perform the following
steps:
The node SHALL process the bundle(s) for forwarding as if it were
going to simply forward the bundle(s). Some of the processing
steps include, for example:
-Processing the security extension blocks [5] (if any)
contained in the bundle, as appropriate (e.g., verifying the
security result in the Bundle Authentication Block and deleting
this block, verifying the security result in the Payload
Security Block if the node is the security destination, etc.).
-Deleting all Previous Hop Insertion Blocks from the bundle (if
any).
-If the bundle should (according to local policy) be given one
or more Previous Hop Insertion Blocks [3], these blocks SHALL
be inserted into the bundle.
Symington, et al. Expires May 4, 2009 [Page 7]
Internet-Draft DTN Bundle-in-Bundle Encapsulation October 2008
-Processing the Metadata Extension Blocks [4] (if any)
contained in the bundle, as appropriate.
-If the bundle should be given one or more security extension
blocks such as a Bundle Authentication, Payload Security, or
Confidentiality Block, the appropriate security blocks SHALL be
inserted into the bundle. If the bundle is given a BAB [5],
the EID of the node that is creating this BAB MUST be
identified within the bundle, either through an EID reference
to the BAB security-source or using another mechanism, such as
the Previous Hop Insertion Block [3]. This EID must be present
in the bundle because it will not be possible for the bundle
protocol agent that is responsible for validating the security
result in the BAB to determine the EID of this BAB-creating
node through implementation-specific means (such as from the
convergence layer).
Next, the node's bundle protocol agent MUST direct the
administrative element of the node's application agent to
construct a new, encapsulating bundle. The bundle or bundles to
be encapsulated MUST be placed in the payload field of the
encapsulating bundle's Bundle Payload Block. The encapsulating
bundle must be given a Bundle-in-Bundle Encapsulation Block. If
more than one bundle has been placed in the encapsulating bundle's
payload field, the Bundle-in-Bundle Encapsulation Block must have
a Number of Encapsulated Bundles field that has as its value the
number of bundles that have been placed in the encapsulating
bundle's payload field and the Bundle-in-Bundle Encapsulation
Block must have a Bundle Offsets List field that has as its value
the list of offsets of each of the encapsulated bundles, after the
first encapsulated bundle, in the payload field.
If more than one bundle is to be placed in the encapsulating
bundle's payload field, all of these bundles must have the same
value for their "Custody transfer is requested" Bundle Processing
Control Flag [2]. The value of the encapsulating bundle's
"Custody transfer is requested" Bundle Processing Control Flag
must be set to the same value as that of the bundle(s) to be
encapsulated.
The value of the destination EID in the new, encapsulating bundle
MUST be set to an endpoint ID of which the node(s) that will be
de-encapsulating the bundle is/are a member.
The value of the source EID of the encapsulating bundle MUST be
set to an endpoint ID of which the node that created the
encapsulating bundle is a member.
Symington, et al. Expires May 4, 2009 [Page 8]
Internet-Draft DTN Bundle-in-Bundle Encapsulation October 2008
The value of the Creation Timestamp of the encapsulating bundle
MUST be set to the time at which the node began constructing the
encapsulating bundle, and the value of the Lifetime of the
encapsulating bundle MUST be set such that the encapsulating
bundle will expire at or later than the expiration time of all of
its encapsulated bundle(s). That is, the creation time plus the
lifetime of the encapsulating bundle must be greater than or equal
to the creation time plus the lifetime of each of the bundles that
have been placed in the encapsulating bundle's payload field.
Other fields of this new, encapsulating bundle (remaining Bundle
Processing Control Flag values, Block Length, Dictionary byte
array, etc.) must be given appropriate values.
Once this new, encapsulating bundle has been constructed, it SHALL
be processed for forwarding (i.e., given security blocks, given a
Previous Hop Insertion Block, given a Metadata Extension Block,
etc. as appropriate) and then forwarded.
Note that there is currently no Bundle Status Report Status Flag
[2] defined to indicate that the "Reporting node is encapsulating
a bundle". Such a status report could possibly be helpful and
perhaps should be defined in the future. If such a status report
were to be sent to the current custodian (if any) of the
encapsulated bundle upon its encapsulation, for example, the
status report would indicate to the custodian that custody signals
for the encapsulated bundle will not be received until some time
after the encapsulated bundle has been de-encapsulated.
3.2. Receipt and Processing of an Encapsulating Bundle
Upon delivery of a bundle that has a Bundle-in-Bundle Encapsulation
Block and, therefore, a payload field that consists of one or more
encapsulated bundles, the application-specific element of the
application agent of the node at which the bundle was delivered SHALL
perform the following processing steps:
Extract the encapsulated bundle(s) from the encapsulating bundle's
payload field.
Pass each of these de-encapsulated bundles in their entirety to
the node's bundle protocol agent.
Upon receipt of each of these de-encapsulated bundles, the bundle
protocol agent SHALL process each bundle as if it had just been
received from another node. It will not be possible for the bundle
protocol agent to determine the EID of the forwarding node of these
de-encapsulated bundles through implementation-specific means (such
Symington, et al. Expires May 4, 2009 [Page 9]
Internet-Draft DTN Bundle-in-Bundle Encapsulation October 2008
as from the convergence layer), because the forwarding node was the
node that provided the bundle for encapsulation, not necessarily the
node from which the encapsulating bundle was received. Therefore, if
the EID of the forwarding node is needed by the bundle protocol
agent, this EID MUST be present in the de-encapsulated bundle, for
example, in a Previous Hop Insertion Block [3] or in the EID
reference to the security-source of a BAB [5], if the bundle contains
a BAB. Some of the processing steps that the bundle protocol agent
SHALL perform include, for example:
-Processing the security extension blocks [5] (if any) contained
in the bundle, as appropriate (e.g., verifying the security result
in the Bundle Authentication Block and deleting this block,
verifying the security result in the Payload Security Block if the
node is the security destination, etc.).
-Deleting all Previous Hop Insertion Blocks from the bundle (if
any).
-Processing the Metadata Extension Blocks [4](if any) contained in
the bundle, as appropriate.
-The bundle protocol agent SHALL deliver the bundle, if
appropriate.
-The bundle protocol agent SHALL perform custody transfer and/or
status reporting procedures on the bundle as directed by the
bundle's custody transfer and status report request flags.
-If the bundle should (according to local policy) be given one or
more Previous Hop Insertion Blocks [3], these blocks SHALL be
inserted into the bundle.
-If the bundle should be given one or more security extension
blocks such as a Bundle Authentication, Payload Security, or
Confidentiality Block, the appropriate security blocks SHALL be
inserted into the bundle.
-The bundle protocol agent SHALL forward the bundle to all
appropriate endpoints.
Symington, et al. Expires May 4, 2009 [Page 10]
Internet-Draft DTN Bundle-in-Bundle Encapsulation October 2008
4. Security Considerations
There are two documents that pertain to providing security within the
DTN Bundle Protocol: [5] and [7].
The mandatory BAB-HMAC ciphersuite defined in [5], because it uses
the strict canonicalization algorithm that calculates a security
result over all blocks in the bundle, can be used to detect changes
that occur in the Bundle-in-Bundle Encapsulation Block while in
transit between neighboring DTN nodes.
The mandatory PIB-RSA-SHA256 ciphersuite defined in [5], however,
cannot be used to detect changes that occur in the Bundle-in-Bundle
Encapsulation block as it traverses multiple neighboring DTN nodes,
because this ciphersuite uses the mutable canonicalization algorithm,
which does not include the Bundle-in-Bundle Encapsulation Block among
the blocks over which it calculates a security result. In order to
ensure the end-to-end integrity of the Bundle-in-Bundle Encapsulation
Block, the mutable canonicalization algorithm would need to be
modified to include the Bundle-in-Bundle Encapsulation Block among
those blocks included in the mutable canonicalization of the bundle.
The mandatory PCB-RSA_AES128-PAYLOAD-PIB-PCB ciphersuite defined in
[5] will encrypt the encapsulated bundle(s) because these are stored
in the payload field and this ciphersuite encrypts the payload field.
However, this ciphersuite will not encrypt the Bundle-in-Bundle
Encapsulation Block in the encapsulating bundle, so, using the
available mandatory confidentiality ciphersuite, there is no way to
keep confidential the fact that the bundle is an encapsulating bundle
or the information regarding the number of bundles encapsulated and
their offsets. To provide confidentiality protection of this sort, a
new ciphersuite for the Payload Confidentiality Block would have to
be defined that includes protection of the Bundle-in-Bundle
Encapsulation Block.
It should be noted that when a bundle is encapsulated, the
encapsulated bundle itself may be protected by one or more security
blocks. In particular, it may contain a Bundle Authentication Block
(BAB), which is designed to be processed by a next-hop neighboring
node. If a bundle with a BAB is encapsulated by one node and it is
received and de-encapsulated by a non-neighboring node, the bundle
protocol agent to which the de-encapsulated bundle is passed for
processing must be capable of validating the security result in the
BAB if its security policy requires such validation. Therefore,
encapsulation of bundles protected by BABs may require that keys that
are normally only shared between neighbors be distributed further in
the DTN so that they are shared by the encapsulating and de-
encapsulating nodes. Furthermore, because it is not possible for the
Symington, et al. Expires May 4, 2009 [Page 11]
Internet-Draft DTN Bundle-in-Bundle Encapsulation October 2008
bundle protocol agent to which the de-encapsulated bundle is passed
to determine the EID of the forwarding node that inserted the BAB
into the encapsulated bundle through implementation-specific means
(such as from the convergence layer), if the EID of this forwarding
node is not identified elsewhere in the encapsulated bundle (e.g. in
the Previous Hop Insertion Block), this EID must be present in the
security-source field of the BAB.
Symington, et al. Expires May 4, 2009 [Page 12]
Internet-Draft DTN Bundle-in-Bundle Encapsulation October 2008
5. IANA Considerations
None at this time. If the bundle protocol becomes a standards track
protocol, then we may want to consider having IANA establish a
register of extension block types, of which the Bundle-in-Bundle
Encapsulation Block would be one.
Symington, et al. Expires May 4, 2009 [Page 13]
Internet-Draft DTN Bundle-in-Bundle Encapsulation October 2008
6. References
6.1. Normative References
[1] Bradner, S. and J. Reynolds, "Key words for use in RFCs to
Indicate Requirement Levels", RFC 2119, October 1997.
[2] Scott, K. and S. Burleigh, "Bundle Protocol Specification",
RFC, 5050, November 2007.
[3] Symington, S., "Delay-Tolerant Networking Previous Hop Insertion
Block", draft-irtf-dtnrg-bundle-previous-hop-block-04.txt, work-
in-progress, September 2008.
[4] Symington, S., "Delay-Tolerant Networking Metadata Extension
Block",
draft-irtf-dtnrg-bundle-metadata-block-00.txt, work-in-progress,
September 2008.
[5] 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.
6.2. Informative References
[6] 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.
[7] 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, et al. Expires May 4, 2009 [Page 14]
Internet-Draft DTN Bundle-in-Bundle Encapsulation October 2008
Authors' Addresses
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/
Robert C. Durst
The MITRE Corporation
7515 Colshire Drive
McLean, VA 22102
US
Phone: +1 (703) 983-7535
Email: durst@mitre.org
URI: http://mitre.org/
Keith L. Scott
The MITRE Corporation
7515 Colshire Drive
McLean, VA 22102
US
Phone: +1 (703) 983-6547
Email: kscott@mitre.org
URI: http://mitre.org/
Symington, et al. Expires May 4, 2009 [Page 15]
Internet-Draft DTN Bundle-in-Bundle Encapsulation October 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
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).
Symington, et al. Expires May 4, 2009 [Page 16]
| PAFTECH AB 2003-2026 | 2026-04-24 08:43:21 |