DTN Research Group S. Symington
Internet-Draft The MITRE Corporation
Intended status: Experimental October 8, 2009
Expires: April 11, 2010
Delay-Tolerant Networking Retransmission Block
draft-irtf-dtnrg-bundle-retrans-block-06
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 April 11, 2010.
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 in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Symington Expires April 11, 2010 [Page 1]
Internet-Draft DTN Retransmission Block October 2009
Abstract
This document defines an optional extension block, called a
Retransmission Block (RB), that may be used with the Bundle Protocol
[refs.DTNBP] within the context of a Delay-Tolerant Network
architecture [refs.DTNarch]. The Retransmission Block (RB) is
designed to be used within a DTN that, as a matter of policy, deletes
all replayed bundles from the network. It is designed to be used in
a network that permits duplicate bundles to be forwarded if those
bundles have been retransmitted by a custodian, that may (if
possible) permit duplicate bundles to be forwarded if those bundles
are in intentional or unintentional routing loops (contingent on the
availability of mechanisms to distinguish looping bundles from other
bundles), but that will consider all other duplicate bundles to be
maliciously replayed bundles and delete them as such. The
Retransmission Block is designed to be inserted into a bundle by a
custodian when the custodian is retransmitting that bundle. The
purpose of the RB is to mark the bundle as a custody-based
retransmission so that it can be distinguished from other types of
duplicate bundles and thereby be spared from deletion. This document
defines the format and processing of this new Retransmission Block.
Symington Expires April 11, 2010 [Page 2]
Internet-Draft DTN Retransmission Block October 2009
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Applicability Statement . . . . . . . . . . . . . . . . . . . 7
2.1. Bundle Authentication Requirement . . . . . . . . . . . . 7
2.2. Deletion of All Replays, including Bundles in Routing
Loops . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.3. Universal Support for Replay Suppression . . . . . . . . . 8
2.4. Universal Support for the Retransmission Block . . . . . . 8
3. Retransmission Block Format . . . . . . . . . . . . . . . . . 9
4. Retransmission Block Processing . . . . . . . . . . . . . . . 10
4.1. Bundle Reception . . . . . . . . . . . . . . . . . . . . . 10
4.2. Detecting Duplicates and Determining which ones are
Custodial Retransmissions . . . . . . . . . . . . . . . . 10
4.3. Keeping Track of Bundles Received . . . . . . . . . . . . 11
4.4. Purging stored bundle information . . . . . . . . . . . . 11
4.5. Bundle Forwarding . . . . . . . . . . . . . . . . . . . . 11
4.6. Custodial Retransmission . . . . . . . . . . . . . . . . . 11
5. Non-Uniform Support for the Retransmission Block . . . . . . . 12
6. Security Considerations . . . . . . . . . . . . . . . . . . . 14
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
8.1. Normative References . . . . . . . . . . . . . . . . . . . 17
8.2. Informative References . . . . . . . . . . . . . . . . . . 17
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 18
Symington Expires April 11, 2010 [Page 3]
Internet-Draft DTN Retransmission Block October 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. As discussed in the DTN Security Overview
[refs.DTNsecOver], due to the resource-scarcity that characterizes
DTNs, unauthorized access and use of DTNs is a serious concern. As
described in the Bundle Security Protocol [refs.DTNBPsec], use of the
Bundle Authentication Block (BAB) at every node in the DTN can be
used to thwart an attacker wanting to launch a denial of service
attack by injecting bogus or modified bundles into the network. Use
of the BAB enables bogus or modified bundles to be detected and
deleted at the very first node at which they are received. Use of
the BAB, however, does not enable maliciously replayed bundles to be
detected, because such replayed bundles will contain valid
authenticators. 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 maliciously replayed bundles.
The detection and deletion of maliciously replayed bundles at any
given node is not simply a matter of configuring the node to maintain
a record of every bundle it receives, comparing each new bundle
received against the list of already-received bundles, and deleting
all duplicates. While such an approach would result in the deletion
of maliciously replayed bundles, it could also result in the deletion
of other types of duplicate bundles that are not replays and that
shouldn't be deleted.
Indiscriminate deletion of all duplicates could result in the
deletion of bundles that are in intentional or unintentional routing
loops. Such bundles may legitimately be found in DTNs and their
deletion may not be desirable. Unfortunately, there are currently no
mechanisms available to enable a DTN node to distinguish bundles that
are in loops from maliciously replayed bundles; suppression of
replays currently requires suppression of looping bundles. If replay
suppression is needed in a DTN that employs routing strategies that
result in routing loops, the routing protocols will need to provide a
mechanism for distinguishing looping bundles from maliciously
replayed bundles. If such a mechanism is provided, it can be used in
conjunction with the Retransmission Block as defined in this
Symington Expires April 11, 2010 [Page 4]
Internet-Draft DTN Retransmission Block October 2009
document.
Indiscriminate deletion of all duplicates could also result in the
deletion of bundles that have been retransmitted by a custodian as
part of the custody transfer process. The Bundle Protocol includes a
custody-based retransmission mechanism that may result in a custodian
retransmitting a stored bundle when the bundle's retransmission timer
expires or when the custodian receives a "failed" custody signal for
the bundle. Such retransmitted bundles are duplicates of previously
forwarded bundles. A DTN node that is configured to simply delete
all duplicates received would delete such custodial retransmissions,
thereby rendering custody transfer ineffective. In order to be able
to enable custody transfer to operate correctly while also detecting
and deleting malicious replays, DTN nodes need a way to determine
whether or not a duplicate bundle received is a custodial
retransmission so that custodial retransmissions can be spared from
deletion.
This document defines an optional bundle block called a
Retransmission Block (RB) that is intended to be used in DTNs that,
as a matter of policy, delete all replayed bundles from the network.
Such a DTN may be configured to permit duplicate bundles to be
forwarded only if those duplicate bundles are bundles that have been
retransmitted by a custodian. In this case, the DTN would be one in
which not only replayed bundles, but also bundles resulting from
intentional or unintentional routing loops would also be deleted.
If, on the other hand, the routing protocols being used in the DTN
enable bundles that are in loops to be distinguished from replayed
bundles, then the DTN could be configured such that only those
duplicate bundles that are replayed bundles are deleted.
In either case, the RB is designed to be inserted into a bundle by a
custodian when the custodian is retransmitting that bundle in
response to a custody transfer failure or retransmission timer
expiration. The intent of the RB is to mark a custodially
retransmitted 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 custody-based
retransmission that should be preserved rather than another type of
duplicate that may (according to network policy) be deleted.
The RB is intended to enable custodially retransmitted bundles to be
distinguished from other duplicates. Other mechanisms would need to
be defined in order to be able to distinguish looping bundles from
other duplicates. If the RB is used with duplicate suppression in
the absence of these other mechanisms, then it will result in the
deletion of all looping bundles in addition to all replays.
Symington Expires April 11, 2010 [Page 5]
Internet-Draft DTN Retransmission Block October 2009
This document defines the format and processing of this new
Retransmission Block. 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,
-Calculating a checksum or digest (as determined by local policy)
of the payload block of a bundle,
-Receiving bundles containing a Retransmission Block and using the
information contained in this Retransmission Block (in conjunction
with information from logged bundles and with a mechanism, if
available, for determining whether a bundle is in a routing loop)
to make duplicate deletion decisions, and
-Deleting a Retransmission Block from a bundle
as defined in this document.
Symington Expires April 11, 2010 [Page 6]
Internet-Draft DTN Retransmission Block October 2009
2. Applicability Statement
The objective of the Retransmission Block (RB) is to make
custodially-retransmitted bundles distinguishable from other
duplicate bundles. As such, the RB is designed to be used within a
DTN that does not, as a matter of policy, permit replayed bundles to
be forwarded and that is willing to enforce the detection and
deletion of replayed bundles by having every node
-Authenticate all bundles
-Keep track of bundles that have been received to identify which
newly-received bundles are duplicates
-Implement and use the RB as a way to enable nodes to determine
which duplicate bundles are custodial retransmissions
-Spare from deletion those duplicate bundles that are custodial
retransmissions
2.1. Bundle Authentication Requirement
Use of the RB to distinguish custodial retransmissions from replayed
bundles requires that bundles be authenticated in order to ensure
that the RB was in fact inserted by a legitimate node and that the RB
has not been modified since its insertion. There is no point in
using the RB within a DTN that does not perform bundle authentication
because DTNs that do not perform bundle authentication are
susceptible to denial of service attacks caused by all types of
bundles that can be modified or inserted by an adversary, not just
replays; in such an environment, detecting and deleting replays does
little to protect against denial of service attacks.
2.2. Deletion of All Replays, including Bundles in Routing Loops
Note that the RB is intended to be used only in DTNs that do not
permit the forwarding of replayed bundles. If a DTN does permit
replayed bundles to be forwarded, there is no point in using the RB.
Use of the RB makes it possible to distinguish which duplicate
bundles are custodial retransmissions so that they can be spared from
deletion. The RB may be used in DTNs that are configured to delete
all duplicates that are not custodial retransmissions. In this case,
duplicates that are the result of intentional or unintentional
routing loops will also be deleted along with replayed bundles. In
order to be able to suppress replays in a DTN that employs routing
strategies that result in routing loops, a mechanism for
distinguishing a bundle that is in a routing loop from a replayed
bundle will need to be provided for use in conjunction with the RB.
Symington Expires April 11, 2010 [Page 7]
Internet-Draft DTN Retransmission Block October 2009
Currently, no such mechanisms are known to exist, so replay deletion
will also result in the deletion of bundles that are in routing
loops.
2.3. Universal Support for Replay Suppression
One component of a DTN node's security policy should be whether or
not replays are allowed to be forwarded by that node. A node that is
not allowed to forward replays should delete all duplicate bundles
that are not custodial retransmissions and that cannot be determined
to be the result of routing loops. In order to be applied
consistently, correctly, and effectively, replay detection and
deletion is something that should be enforced at all nodes in the DTN
rather than something that is enforced on a node-by-node basis. If
not every node supports replay detection and deletion then some
replays will be allowed to remain in the network. The RB is designed
to be used within a DTN in which every node is configured to detect
and delete replays.
2.4. Universal Support for the Retransmission Block
While implementation of and support for the RB is optional, the RB is
designed to be used within a DTN in which every node supports the RB.
Failure to support the RB at one or more nodes in a DTN that, as a
matter of policy, deletes replays may result in the erroneous
deletion of custodially retransmitted bundles. Section 5 further
discusses the ramifications of non-uniform support of the RB.
Symington Expires April 11, 2010 [Page 8]
Internet-Draft DTN Retransmission Block October 2009
3. Retransmission Block Format
The Retransmission Block (RB) MAY be included in a bundle. A RB 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. 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. 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
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.
-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 Retransmission Block format is as follows:
+------+--------------+------------------------------+--------------+
|type |flags (SDNV) |EID ref count and list (comp) |length (SDNV) |
+------+--------------+------------------------------+--------------+
| Retransmission Sequence Number (SDNV) |
+-------------------------------------------------------------------+
Figure 1
Symington Expires April 11, 2010 [Page 9]
Internet-Draft DTN Retransmission Block October 2009
4. Retransmission Block Processing
The following are the processing steps that a bundle node must take
relative to generation, reception, and processing of Retransmission
Blocks, assuming that the node is configured to detect and discard
replays.
4.1. Bundle Reception
According to the Bundle Protocol, if a node receives a bundle that it
currently has in custody as custodian, the received bundle will be
discarded.
Upon receipt of any other type of bundle, the node SHALL delete the
bundle's Retransmission Block if the custodian EID referenced in the
RB is not the same as the custodian EID referenced in the Primary
Bundle Block.
4.2. Detecting Duplicates and Determining which ones are Custodial
Retransmissions
We define a duplicate to be a bundle that has the same source
endpoint ID, creation timestamp, fragment offset and payload length
(if the bundle is a fragment), and checksum or digest of the payload
block as another bundle. (Whether to use a checksum or a digest of
the payload block is determined by local policy.)
If a bundle is received that is a duplicate of a previously received
bundle, then
-If the received bundle does not include a Retransmission Block,
the bundle is not a custodial retransmission.
-If the received bundle does include a Retransmission Block and
the RB's 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 is not a
custodial retransmission.
-Otherwise, the received bundle is a custodial retransmission.
The receiving node MUST delete this bundle if it is a duplicate, if
it is not a custodial retransmission, and if it cannot be determined
(by some mechanism that may be defined elsewhere) to be a result of a
routing loop.
Symington Expires April 11, 2010 [Page 10]
Internet-Draft DTN Retransmission Block October 2009
4.3. Keeping Track of Bundles Received
If the bundle is not deleted as a replay, the node must store at
least the following information from or about the bundle for
comparison with future received bundles: source EID; creation
timestamp; fragment offset and payload length (if the bundle is a
fragment); checksum or digest of the payload block; custodian EID (if
the bundle does not include a Retransmission Block) and
Retransmission Block EID reference and retransmission sequence number
(if the bundle does include a Retransmission Block).
4.4. Purging stored bundle information
The stored information for all bundles whose creation timestamp +
lifetime is less than the current time MAY be deleted.
4.5. Bundle Forwarding
As part of the custody acceptance procedures, the accepting node MUST
delete the bundle's Retransmission Block (if it has one).
4.6. Custodial Retransmission
Upon deciding to re-forward a bundle as a result of custody transfer
failure, the re-forwarding custodian MUST:
- insert a RB with a retransmission sequence number value of 0
into the bundle if the bundle does not already include a RB, or
- increment the retransmission sequence number value in the
Retransmission Block if the bundle does already include a RB.
- Store the inserted/modified retransmission block values along
with the other information from the bundle as part of its custody
storage procedures.
The EID reference in the Retransmission Block MUST refer to the re-
forwarding custodian.
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 April 11, 2010 [Page 11]
Internet-Draft DTN Retransmission Block October 2009
5. Non-Uniform Support for the Retransmission Block
Failure to support the RB at one or more nodes in a DTN in which, as
a matter of policy, all nodes are configured to delete replayed
bundles may result in the erroneous deletion of custodially
retransmitted bundles in the following cases:
A node that does not support the RB but that is configured to
delete replays could delete duplicate bundles even if they include
RBs that mark them as being custodial retransmissions.
A custodial node that does not support the RB but that retransmits
a bundle would not include a RB to mark the bundle as a custodial
retransmission, so that when the bundle is received at a
downstream node that is configured to suppress replays, the bundle
would be deleted by that downstream node (even if that downstream
node supports the RB).
Consequently, the RB SHOULD be supported at all nodes in a DTN that,
as a matter of policy, deletes replayed bundles. If not all nodes in
the DTN support the RB, then to preserve support for custodial
retransmission while maximizing replay suppression, the security
policies of the nodes and the Block Processing Flags in the RB 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 RB should be configured to delete
duplicates that are not custodial retransmissions,
-Nodes that do not support the RB should be configured to forward
duplicates (so that they don't inadvertently delete custodial
retransmissions), and
-Nodes that do not support the RB should be configured not to take
custody of bundles (to ensure that custodial retransmissions will
always include RBs).
The above configuration ensures that custodial retransmissions will
not be erroneously deleted, and that all duplicate that are received
at nodes that support the RB will be deleted. Only duplicates that
are received at nodes that do not support the RB will be forwarded
and allowed to remain in the network. If these are forwarded to a
node that supports the RB, however, they will be deleted at that
Symington Expires April 11, 2010 [Page 12]
Internet-Draft DTN Retransmission Block October 2009
node. Therefore, a network configured in this way is vulnerable to a
denial-of-service attack only from duplicate bundles that circulate
exclusively among nodes that do not support the RB.
Symington Expires April 11, 2010 [Page 13]
Internet-Draft DTN Retransmission Block October 2009
6. Security Considerations
As mentioned in the Applicability Statement Section, it does not make
sense to detect and suppress replayed bundles without first
authenticating that those bundles have not been modified. Without
authentication that a bundle has been forwarded intact, 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, nodes that support the RB and that are
configured to suppress replays should also be required to
authenticate bundles. Furthermore, all nodes in the DTN should be
configured in the same way, to ensure that replays will be suppressed
consistently without also resulting in the erroneous deletion of
custodial retransmissions.
If the integrity of the RB is not protected, an adversary could
inject many replayed bundles into the network yet include an RB in
each that makes these bundles appear to be legitimate
retransmissions. Integrity protection for the entire bundle,
including the RB, MUST be provided by using the BAB with a
ciphersuite, such as the BAB-HMAC ciphersuite defined in the Bundle
Security Protocol, that uses a strict canonicalisation algorithm to
protect the entire bundle between one hop and the next. Because of
the hop-by-hop nature of the protection provided by the BAB, every
node in the network would need to require all bundles to be protected
with the BAB in order to ensure bundle authentication across the
network. If, instead, integrity protection were to be provided using
the PIB, with a ciphersuite that uses mutable canonicalization, the
DTN would still be vulnerable to a replay attack in which an
adversary modifies the fragment offset information of a previously-
transmitted, valid bundle, and injects this modified bundle into the
network. Such a bundle would not be deleted as a replay because its
offset information is unique, but it would authenticate using the PIB
because ciphersuites using mutable canonicalization do not calculate
their security results over the fragment offset information (due to
the fact that this information may change as the bundle traverses the
network).
If a node or BAB key is compromised, authentication provided through
use of the BAB does not help to protect against replays, but in this
case the network's vulnerability to denial-of-service attacks is much
larger than just a vulnerability to replays. If a node is
compromised, any bundle could be created and injected into the
network.
Symington Expires April 11, 2010 [Page 14]
Internet-Draft DTN Retransmission Block October 2009
If a node or key is compromised, however, payload content must be
taken into consideration in order to protect the DTN from insertion
attacks that may be possible as a result of the RB being used. In
some cases it might be possible for an adversary to know or guess
that a specific source will emit a bundle at a specific time. In
this case, the adversary could send out its own bundle that purports
to be from that source and that contains correctly-guessed timestamp
information, with the intent that this bundle be received at a
forwarding node before the authentic bundle from the actual source.
If the adversary that is injecting the spurious bundle is in
possession of a compromised BAB key, this spurious bundle would
appear to be valid when received by a forwarding node. If the
forwarding node were to use only bundle source, creation timestamp,
and fragment information (and not a checksum or digest of the payload
block, as is required) to identify duplicates, then when the
forwarding node receives the second bundle, it would delete this
bundle as a duplicate even though this second bundle is actually the
authentic bundle from the actual source. If payload block content is
being used to identify duplicates, on the other hand, then the two
bundles would not appear to be duplicates and the second one would
not be deleted. The fact that the bundle source, creation timestamp,
and fragment information of the bundles match whereas the payloads do
not, however, would serve as a red flag that something is amiss and
needs to be investigated. If an adversary launching this kind of
insertion attack is in possession of a compromised BAB key, then
insertion of a PIB into the bundle by the bundle's source would
enable the forwarding node to determine which of the bundles is
legitimate and which is not (assuming the forwarding node is in
possession of the keying material necessary to authenticate the PIB
security result). If the adversary launching this attack is in
possession of the source's PIB key, however, then determining which
bundle is legitimate would be impossible. Still, the presence of two
bundles with identical bundle source, creation timestamp, and
fragment information but different payloads would serve as a red
flag.
Symington Expires April 11, 2010 [Page 15]
Internet-Draft DTN Retransmission Block October 2009
7. 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 April 11, 2010 [Page 16]
Internet-Draft DTN Retransmission Block October 2009
8. References
8.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-08.txt, work-in-progress,
March 2009.
8.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-06.txt, work-in-progress,
March 2009.
Symington Expires April 11, 2010 [Page 17]
Internet-Draft DTN Retransmission Block October 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 April 11, 2010 [Page 18]
