DTN Research Group S. Symington
Internet-Draft The MITRE Corporation
Intended status: Experimental October 31, 2008
Expires: May 4, 2009
Delay-Tolerant Networking Retransmission Block
draft-irtf-dtnrg-bundle-retrans-block-03
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 Expires May 4, 2009 [Page 1]
Internet-Draft DTN Retransmission Block October 2008
Abstract
This document defines an optional extension block, called a
Retransmission Block, that may be used with the Bundle Protocol [2]
within the context of a Delay-Tolerant Network architecture [4]. The
Retransmission Block (RB) is designed to be inserted by a custodian
when re-forwarding a bundle, so as to mark the bundle as a legitimate
custody-based retransmission rather than an unauthorized bundle
duplicate. By providing a way for nodes that receive the re-
forwarded bundle to distinguish it from an unauthorized duplicate,
the RB enables those nodes whose local security policies do not
permit them to forward unauthorized duplicate bundles to detect and
delete unauthorized bundle duplicates but forward legitimate custody-
based bundle retransmissions. This document defines the format and
processing of this new Retransmission Block.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Background and Motivation . . . . . . . . . . . . . . . . . . 5
2.1. Replay Detection as Currently Provided in the Bundle
Protocol . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2. The Denial-of-Service Threat . . . . . . . . . . . . . . . 5
2.3. Detecting Duplicates is Largely a Matter of Local
Policy . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.4. Not All Duplicates are Bad . . . . . . . . . . . . . . . . 6
2.5. A Mechanism for Distinguishing Legitimate
Retransmissions from Replays is Required . . . . . . . . . 7
3. The Treatment of Replays Must Be a Defined Aspect of
Security Policy . . . . . . . . . . . . . . . . . . . . . . . 8
4. Replays versus Loops . . . . . . . . . . . . . . . . . . . . . 9
5. Ramifications of Allowing Support for the Retransmission
Block to be Optional . . . . . . . . . . . . . . . . . . . . . 11
6. Retransmission Block Format . . . . . . . . . . . . . . . . . 13
7. Retransmission Block Processing . . . . . . . . . . . . . . . 15
7.1. Bundle Reception . . . . . . . . . . . . . . . . . . . . . 15
7.2. Replay Detection and Suppression . . . . . . . . . . . . . 15
7.3. Keeping Track of Bundles Received . . . . . . . . . . . . 15
7.4. Purging stored bundle information . . . . . . . . . . . . 16
7.5. Bundle Forwarding . . . . . . . . . . . . . . . . . . . . 16
7.6. Custodial Retransmission . . . . . . . . . . . . . . . . . 16
8. Security Considerations . . . . . . . . . . . . . . . . . . . 17
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
10.1. Normative References . . . . . . . . . . . . . . . . . . . 19
10.2. Informative References . . . . . . . . . . . . . . . . . . 19
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 20
Symington Expires May 4, 2009 [Page 2]
Internet-Draft DTN Retransmission Block October 2008
Intellectual Property and Copyright Statements . . . . . . . . . . 21
Symington Expires May 4, 2009 [Page 3]
Internet-Draft DTN Retransmission Block 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, 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 Retransmission Block.
This block is designed to be inserted by a custodian node into a
bundle that the custodian is re-forwarding in response to a custody
transfer failure. The intent of this Retransmission Block is to mark
a re-forwarded bundle as such, so that when the bundle is received at
downstream nodes that detect it to be a duplicate of a previously-
received bundle, those nodes can understand it to be a legitimate
retransmission that should be preserved rather than an unauthorized
duplicate (aka a replay) that may (according to local policy) be
deleted.
The capabilities described in this document are OPTIONAL for
deployment with the Bundle Protocol. Bundle Protocol implementations
claiming to support Retransmission Blocks MUST be capable of:
-Generating a Retransmission Block and inserting it into a bundle,
-Logging the relevant fields of all bundles received until those
bundles expire,
-Receiving bundles containing a Retransmission Block and using the
information contained in this Retransmission Block (in conjunction
with the information from logged bundles) to make duplicate
deletion (aka replay suppression) decisions,
-Deleting a Retransmission Block from a bundle
as defined in this document.
Symington Expires May 4, 2009 [Page 4]
Internet-Draft DTN Retransmission Block October 2008
2. Background and Motivation
2.1. Replay Detection as Currently Provided in the Bundle Protocol
The Bundle Security Protocol defines an "at-most-once-delivery"
registration option that, when used by a node that is registering in
a particular endpoint, indicates that at most one copy of each bundle
destined for that endpoint that is received at that node shall be
delivered at that node. If the at-most-once-delivery option is used
with a given endpoint ID registration, the registering node is
required to check all bundles that it receives with that destination
endpoint ID to determine if the bundle has already been delivered at
that node. If it has, the bundle must be discarded. This is a
limited form of replay detection because it requires a node to keep
track of only the bundles that have been delivered at that node; it
does not apply to bundles that the node receives for forwarding. It
is designed to protect applications from receiving duplicate bundles,
but it is not intended to protect the network from denial of service
attacks that can result from replayed bundles.
2.2. The Denial-of-Service Threat
As discussed in the DTN Security Overview [5], due to the resource-
scarcity that characterizes DTNs, unauthorized access and use of DTNs
is a serious concern. DTNs, by definition, may suffer from network
disconnections, limited bandwidth, limited battery power, and other
challenges, and the transmission of unauthorized bundles wastes
precious network resources. The DTN security protocol already
includes some mechanisms to protect against unauthorized use of the
DTN. For example, an attacker wanting to launch a denial of service
attack on a DTN by injecting a bogus bundle into the network or by
copying a legitimate bundle from the network, modifying it, and
injecting this modified copy into the network can be thwarted by the
use of the Bundle Authentication Block (BAB). Use of the BAB enables
each node that receives a bundle to check the validity of the
security result in the BAB to determine whether the bundle is
legitimate or not. Bogus or modified bundles will be detected at the
very first node at which they are received, and thus will be deleted
from the network at the earliest possible opportunity. Replayed
bundles, on the other hand, can not be detected by checking the
validity of the bundle's BAB because the value of the BAB will be
correct. Replayed bundles will only be deleted from the network when
they expire. Given the high latency typical in some DTNs, bundles
may be valid for days or weeks. For those networks in which waiting
for replayed bundles to expire is not an adequate form of protection
against the unauthorized use of the network posed by replayed
bundles, additional measures will be required to actively detect and
delete replayed bundles.
Symington Expires May 4, 2009 [Page 5]
Internet-Draft DTN Retransmission Block October 2008
2.3. Detecting Duplicates is Largely a Matter of Local Policy
Detecting duplicate bundles at any given node is largely a matter of
local security policy and enforcement. A node could be configured to
maintain a record of every bundle it receives, check every new bundle
received against the list of bundles that have already been received,
and delete any duplicates. A concern with this approach is the
potentially large amount of state that could accumulate and use up
storage at any given node. This state can be minimized by only
storing those parts of the bundle needed to identify it uniquely
(source EID, creation timestamp, and fragment offset and length - if
present), and keeping this information only until the time that the
bundle expires (creation timestamp added to lifetime). The lifetime
of the bundle would also need to be stored in order to be able to
determine whether or not it has expired. Because bundles may be
valid for long periods in a DTN, however, the amount of storage that
may be required could still be substantial enough to pose a burden on
the node. If the amount of information that needs to be stored
exceeds the available storage and bundles are purged before they
expire, however, some duplicates could go undetected.
2.4. Not All Duplicates are Bad
Although detecting duplicates is a fairly straightforward local
matter (assuming sufficient storage is available), detecting which of
these duplicates are unauthorized and should therefore be deleted is
more involved, and has protocol implications. Simply being able to
detect and delete duplicate bundles is not sufficient in a DTN,
because not all duplicate bundles are unwanted replays. As discussed
in the security overview, there are instances within DTNs in which
replayed messages are desirable and in fact necessary. As a first
example, in some instances, the optimal path to a destination will
involve routing loops, such that the nodes on this loop will receive
the same bundle for forwarding more than once. As a second example,
the DTN protocol includes a custody-based retransmission mechanism
that may result in a custodian re-forwarding a bundle when the
bundle's retransmission timer expires or when the custodian receives
a "failed" custody signal for the bundle. These re-forwarded bundles
are legitimate retransmissions that are required in order to enable
custody transfer to operate correctly.
On the other hand, there are also illegitimate retransmissions, also
known as replays. Some replays are introduced unintentionally by the
routing protocols; these replays are not needed in order to deliver
the bundle, but rather are the result of routing or forwarding
mistakes. Other replays are more pernicious, being introduced
intentionally by malicious intruders. Ideally, a node would be able
to distinguish replays from legitimate retransmissions so that it can
Symington Expires May 4, 2009 [Page 6]
Internet-Draft DTN Retransmission Block October 2008
know which duplicate bundles to delete and which to forward.
2.5. A Mechanism for Distinguishing Legitimate Retransmissions from
Replays is Required
When routing loops or custody transfer is being used in a DTN, replay
detection cannot be handled merely as a matter of locally detecting
and deleting duplicate bundles because there is no way for a local
node to independently distinguish legitimate retransmissions from
illegitimate replays. Instead, a protocol mechanism is required to
assist the local duplicate suppression mechanism in making this
distinction.
As discussed in the DTN Security Overview, to accommodate intentional
retransmissions that are part of the routing protocol but suppress
replays that are the result of routing protocol errors, replay
detection schemes may need to be specified and enforced as part of
the bundle routing algorithm used.
If the security requirements of a network are such that replays must
not be allowed, then that network must either not use routing or
transport protocols that allow routing loops or, if it does use a
routing or transport protocol that allows loops, this protocol must
also include a mechanism for detecting and suppressing unintentional
loops. The details of such a mechanism would most likely be specific
to the routing or transport protocol and as such they are not
addressed in this document.
In addition, if the security requirements of a network are such that
replays must not be allowed, then that network must either not use
custody transfer of bundles or, if it does use custody transfer of
bundles, it must also include a mechanism for detecting and
suppressing duplicate bundles that are not the result of custodial
retransmissions. This paper defines the DTN Retransmission Block as
an optional Bundle Protocol block that can be used to mark bundles
that are the result of custodial retransmission, thereby enabling
these bundles to be distinguished from both unintentional replays and
replays that are the result of intentional, malicious attacks.
Symington Expires May 4, 2009 [Page 7]
Internet-Draft DTN Retransmission Block October 2008
3. The Treatment of Replays Must Be a Defined Aspect of Security Policy
An additional component of a DTN node's security policy should be
whether or not replays are allowed to be forwarded by that node. If
replay forwarding is not allowed, the node must implement mechanisms
to detect and delete replays. In the context of a node that does not
implement the optional Retransmission Block protocol extensions
defined in this document but at which replay forwarding is not
allowed, all duplicate bundles must be deleted, where duplicate
bundles are defined as bundles that have the same source EID, time
stamp, and fragment offset and length (if present). In the context
of a node that does implement the optional Retransmission Block
protocol extensions defined in this document, unauthorized replays
can be distinguished from legitimate retransmissions such that only
unauthorized replays must be deleted. The processing steps with
regard to replay protection at an arbitrary node are defined as
follows:
If replays are allowed, then no additional requirements are levied
on that node.
If replays are not allowed and if the node supports the optional
Retransmission Block defined in this document, then the node MUST
delete all duplicate bundles that it receives that are not
legitimate custodial retransmissions; when such a duplicate bundle
is deleted, the node MAY indicate this by generating a bundle
deletion status report (see [2]), as determined by local policy.
A received duplicate bundle is not a legitimate custodial
retransmission if it:
-Has the same custodian EID as the previously-received
duplicate, but it does not also have a Retransmission Block
that was inserted by that custodian, or
-Has the same custodian EID as the previously-received
duplicate, and also has a Retransmission Block with the same
EID reference and retransmission sequence number values as the
Retransmission Block in the previously-received duplicate.
If replays are not allowed and if the node does not support the
optional Retransmission Block defined in this document, then the
node MUST delete all duplicate bundles that it receives (at the
risk of also deleting all legitimate custodial retransmissions
that it receives).
Symington Expires May 4, 2009 [Page 8]
Internet-Draft DTN Retransmission Block October 2008
4. Replays versus Loops
The procedures for deleting all duplicate bundles that are not
legitimate custodial retransmissions above will result in the
deletion of not only replays, but also of bundles that loop through
the network multiple times. If the looping is unintentional, due to
routing or forwarding errors, deletion of these bundles is desirable.
If the looping is intentional, however, then the deletion of a bundle
in such a loop is not desirable. For example, if a custodial node,
C, needs to free up disk space by temporarily transferring custody
and storage of a bundle to some sort of "auxiliary storage" node that
is not on the path to the bundle's destination until the path to the
destination becomes connected, then the path from the custodian C to
the auxiliary storage node and back would constitute an intentional
routing loop. In order to free up its storage space when sending the
bundle to auxiliary storage, custody of the bundle would be
transferred from node C to the auxiliary storage node. When the
bundle is sent back to node C from auxiliary storage, the auxiliary
storage node would be listed as the bundle's custodian. According to
the procedures for deleting duplicate bundles that are not legitimate
custodial retransmissions as described in Section 3, this bundle
would not be deleted by node C because it does not have the same
custodian as it had when it was initially received by node C. If for
some reason this storing of the bundle at the auxiliary storage node
has to be performed a second time, however, then the procedures above
will not suffice to spare this bundle from deletion.
If node C receives the bundle from auxiliary storage and forwards it
back to auxiliary storage without taking custody of it, auxiliary
storage will delete this copy of the bundle, but it will still be
custodian of the bundle and will still have it in storage. This case
is not a problem. If, on the other hand, node C receives the bundle
from auxiliary storage and takes custody of the bundle before
forwarding it back to auxiliary storage, the auxiliary storage node
will delete this bundle (but the auxiliary storage node will not
still be custodian of the bundle and will not still have the bundle
in storage) because the auxiliary storage node has already received
this bundle with node C listed as its custodian and this bundle does
not contain a retransmission block because node C did not forward it
as a custodial retransmission.
There are several possible approaches that may be taken to address
this problem by attempting to process bundles that are in "desirable"
loops and discard bundles that are in "undesirable" loops, while
staying within the procedures defined above for deleting duplicate
bundles that are not legitimate custodial retransmissions. For
example, custodial nodes that make use of auxiliary storage nodes
might be configured to accept duplicate bundles received from
Symington Expires May 4, 2009 [Page 9]
Internet-Draft DTN Retransmission Block October 2008
auxiliary storage nodes, and vice versa. Alternatively, a special
block might be defined to mark a bundle that a custodial node is
sending to an auxiliary storage node for storage and custody
transfer. As long as a bundle is marked such that it is intended for
auxiliary storage, it could be accepted and stored at the auxiliary
storage node, even if it is a duplicate of a previously-received
bundle. If the auxiliary storage node treats all subsequent
forwardings of a bundle after the first forwarding as though the
forwarding were the result of a custodial retransmission by inserting
a Retransmission Block into the bundle, bundles could be circulated
between custodians and their auxiliary storage nodes multiple times
without being summarily deleted. Using these solution approaches,
there would be no limit to the number of times a bundle could be
offloaded to auxiliary storage, if needed. A risk of implementing
these approaches, however, is that bundles that unintentionally loop
between a custodian and its auxiliary storage node may not be
discarded. Furthermore, these approaches assume that all intentional
loops can be known a priori, so that nodes can be configured to
accept duplicate bundles looping through them or that at least one
node in the loop can be configured to insert Retransmission Blocks
into the looping bundles to protect them from being discarded. These
approaches do not necessarily work for loops that arise
opportunistically, being unplanned but useful, unless there is a
mechanism within the loop for retransmission blocks to be inserted
into the looping bundle as appropriate.
Symington Expires May 4, 2009 [Page 10]
Internet-Draft DTN Retransmission Block October 2008
5. Ramifications of Allowing Support for the Retransmission Block to be
Optional
The objective of the DTN Retransmission Block is to make custodially-
retransmitted bundles distinguishable from unintentional and
malicious replays. Because support for the Retransmission Block is
optional, it may not be supported by all nodes in the DTN. Failure
to support the Retransmission Block at one or more nodes in the DTN
may result in the erroneous deletion of bundles that are legitimate
retransmissions because:
A node that does not support the Retransmission Block but that is
configured to suppress replays will delete all duplicate bundles,
whether or not they include Retransmission Blocks that mark them
as being legitimate retransmissions.
A custodial node that does not support the Retransmission Block
but that legitimately retransmits a bundle will not include a
Retransmission Block to mark the bundle as a legitimate
retransmission, so that when the bundle is received at a
downstream node that is configured to suppress replays, the bundle
will be deleted by that downstream node (even if that downstream
node supports the Retransmission Block).
A DTN cannot completely support both replay suppression and custodial
retransmission if some of its nodes do not support the Retransmission
Block. If replays must be suppressed and custodial retransmission
must be supported, all nodes in the network must support the
Retransmission Block. If one or more nodes do not support the
Retransmission Block, then if those nodes are configured to suppress
replays, they will delete custodial retransmissions that they receive
and issue custodial retransmissions that are vulnerable to being
deleted downstream; if they are configured to forward replays, then
they will forward all replays, both intentional and malicious ones.
Nodes that do not support the Retransmission Block cannot create,
recognize, or process a Retransmission Block. If the Retransmission
Block Processing Flags indicate that a bundle must be deleted if the
Retransmission Block cannot be processed, then all nodes that do not
support the Retransmission Block will delete all custodial
retransmissions, even if these nodes are not configured to suppress
replays. If the Retransmission Block Processing Flags indicate that
the Retransmission Block must be deleted if it cannot be processed,
then all nodes that do not support the Retransmission Block will
strip the Retransmission Block out of every custodial retransmission
that they forward, leaving these custodial retransmissions vulnerable
to downstream deletion by nodes that suppress replays (even if those
downstream nodes support the Retransmission Block).
Symington Expires May 4, 2009 [Page 11]
Internet-Draft DTN Retransmission Block October 2008
If not all nodes in the DTN support the Retransmission Block, then to
preserve support for custodial retransmission while maximizing replay
suppression, the security policies of the nodes and the Block
Processing Flags in the Retransmission Block should be configured as
follows:
-The "Discard bundle if block can't be processed" Block Processing
Flag SHOULD NOT be set,
-The "Discard block if it can't be processed" Block Processing
Flag SHOULD NOT be set,
-Nodes that support the Retransmission Block should be configured
to delete all replays that are not legitimate custodial
retransmissions,
-Nodes that do not support the Retransmission Block should be
configured to forward duplicates (so that they don't inadvertently
delete custodial retransmissions), and
-Nodes that do not support the Retransmission Block should be
configured not to take custody of bundles (to ensure that
custodial retransmissions will always include Retransmission
Blocks).
The above configuration ensures that custodial retransmissions will
not be erroneously deleted, and that all replays that are received at
nodes that support the Retransmission Block will be deleted. Only
replays that are received at nodes that do not support the
Retransmission Block will be forwarded and allowed to remain in the
network. If these are forwarded to a node that supports the
Retransmission Block, however, they will be deleted at that node.
Therefore, a network configured in this way is vulnerable to a
denial-of-service attack only from replayed bundles that circulate
exclusively among nodes that do not support the Retransmission Block.
Symington Expires May 4, 2009 [Page 12]
Internet-Draft DTN Retransmission Block October 2008
6. Retransmission Block Format
The Retransmission Block (RB) is a new block that MAY be included in
a bundle. A RB 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 (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 Retransmission Block is
0x07.
-Block processing control flags (SDNV) - defined as in all bundle
protocol blocks except the primary bundle block (as described in
the Bundle Protocol). The following block processing control flag
MUST NOT be set:
-Block must be replicated in every fragment
The following block processing control flag MUST be set:
-Block contains an EID-reference field
- Block EID reference count and EID reference - composite field
defined in [2] containing a count of EID references with a value
of 1 (expressed as an SDNV) followed by a single EID reference
(expressed as a pair of SDNVs). Presence of this field is
indicated by the setting of the "block contains an EID reference
field" flag in the block processing control flags to 1. The EID
referenced MUST be that of the retransmitting custodian that
inserted this block.
-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:
- Retransmission sequence number (SDNV) - An unsigned integer
indicating the number of times this bundle has been
retransmitted by this custodian.
The structure of a Retransmission Block is as follows:
Symington Expires May 4, 2009 [Page 13]
Internet-Draft DTN Retransmission Block October 2008
Retransmission Block Format:
+------+--------------+------------------------------+--------------+
|type |flags (SDNV) |EID ref count and list (comp) |length (SDNV) |
+------+--------------+------------------------------+--------------+
| Retransmission Sequence Number (SDNV) |
+-------------------------------------------------------------------+
Figure 1
Symington Expires May 4, 2009 [Page 14]
Internet-Draft DTN Retransmission Block October 2008
7. Retransmission Block Processing
The following are the processing steps that a bundle node must take
relative to generation, reception, and processing of Retransmission
Blocks.
7.1. Bundle Reception
According to the Bundle Protocol, if a node receives a bundle that it
currently has in custody as custodian, that node will send a "Failed"
custody signal for this bundle to the bundle's listed current
custodian, but receipt of this duplicate bundle will not cause the
bundle to be either delivered at that node or forwarded to another
node.
Upon receipt of a bundle that the node does not currently have in
custody, the node SHALL delete the bundle's Retransmission Block if
the endpoint ID referred to by the EID reference field in the
Retransmission Block is not the same as the endpoint ID referred to
by the Custodian scheme and Custodian SSP offsets in the Primary
Bundle Block. The node MAY also 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).
7.2. Replay Detection and Suppression
If a node's security policy indicates that replays are not allowed
and if a bundle is received such that the bundle's source EID,
timestamp, and fragment offset and length (if it has one) are
identical to those in a bundle that the node had previously received,
then
-If the received bundle does not include a Retransmission Block
and the Custodian scheme and Custodian SSP offsets in its Primary
Bundle Block are the same as they were in the previously-received
duplicate bundle and the previously-received duplicate bundle also
did not include an RB, the bundle MUST be deleted.
-If the received bundle does include a Retransmission Block and
its EID reference and retransmission sequence number values are
the same as those in the Retransmission Block (if any) of the
previously-received, duplicate bundle, the bundle MUST be deleted.
7.3. Keeping Track of Bundles Received
If replays are not allowed at this node, and if a bundle will not be
deleted as a replay, the node must store at least the following
information from the bundle: source EID, creation timestamp,
Symington Expires May 4, 2009 [Page 15]
Internet-Draft DTN Retransmission Block October 2008
lifetime, fragment offset and length (if any), custodian EID (if the
bundle does not include a Retransmission Block) and Retransmission
Block (if any) EID reference and retransmission sequence number for
comparison with future received bundles.
7.4. Purging stored bundle information
The stored information for all bundles whose creation timestamp +
lifetime is less than the current time MAY be deleted.
7.5. Bundle Forwarding
As part of the custody acceptance procedures, the accepting node MUST
delete the bundle's Retransmission Block (if it has one).
7.6. Custodial Retransmission
Upon deciding to re-forward a bundle as a result of custody transfer
failure, the re-forwarding custodian MUST:
- insert a Retransmission Block with a retransmission sequence
number value of 0 into the bundle if the bundle does not already
include an RB, or
- increment the retransmission sequence number value in the
Retransmission Block if the bundle does already include an RB.
In either case, the EID reference in the Retransmission Block MUST
refer to the EID of the re-forwarding custodian as referenced by the
bundle's primary bundle block.
If a custodian decides to re-forward only a fragment of a bundle that
it had previously forwarded, the re-forwarded fragment will not be a
duplicate of any bundle that had previously been transmitted by this
custodian. Therefore, the re-forwarded fragment SHALL NOT include a
Retransmission Block.
Symington Expires May 4, 2009 [Page 16]
Internet-Draft DTN Retransmission Block October 2008
8. Security Considerations
Each node's local security policy will determine whether replays will
be detected and suppressed at that node or whether replays will be
forwarded indiscriminately. When deciding upon a node's security
policy, it is worth noting that in most networks, the Bundle
Authentication Block (BAB) must be used in conjunction with replay
detection and suppression. It does not make sense to detect and
suppress replayed bundles without first authenticating that those
bundles have not been modified. Without use of the BAB to
authenticate that a bundle has been forwarded in tact, a network is
vulnerable to denial of service attacks launched merely by the
injection of any spurious bundles into the network or the
modification of any authentic bundles. There seems little value in
protecting against denial-of-service attacks resulting from replayed
bundles if denial-of-service attacks resulting from such modified or
spurious bundles will be permitted. Therefore, in determining the
security policy of a node, it will usually be the case that nodes
that do not allow replays must also require received bundles to
include BABs.
Because the RB may be inserted at any custodian in the network and
deleted at any subsequent custodian, its integrity can't be protected
by an end-to-end Payload Security Block (PSB) [3]. Its integrity
must be protected by the BAB. If the integrity of the RB is not
protected by the BAB, then a malicious intruder could modify the RB
to inject many illegitimately replayed bundles, yet give the RB
values such that these bundles appear to be legitimate
retransmissions. As currently defined, protection for the RB will be
included when using the mandatory BAH-HMAC ciphersuite defined in the
Bundle Security Protocol, given that this ciphersuite uses the strict
canonicalisation algorithm.
If a node is compromised, this BAB doesn't help to protect against
replays, but then the network has a lot more vulnerabilities than
just a vulnerability to replays. If a node is compromised, any
bundle could be created and injected into the network. The RB
mechanism is no more vulnerable to misuse by a compromised node than
are any of the other security mechanisms.
Symington Expires May 4, 2009 [Page 17]
Internet-Draft DTN Retransmission Block October 2008
9. 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 Retransmission Block would be one.
Symington Expires May 4, 2009 [Page 18]
Internet-Draft DTN Retransmission Block October 2008
10. References
10.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., Farrell, S., Weiss, H., and P. Lovell, "Bundle
Security Protocol Specification",
draft-irtf-dtnrg-bundle-security-06.txt, work-in-progress,
November 2008.
10.2. Informative References
[4] 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.
[5] 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 May 4, 2009 [Page 19]
Internet-Draft DTN Retransmission Block October 2008
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 May 4, 2009 [Page 20]
Internet-Draft DTN Retransmission Block 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 Expires May 4, 2009 [Page 21]