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]