DTN Research Group S. Farrell Internet-Draft Trinity College Dublin Expires: August 27, 2008 S. Symington The MITRE Corporation H. Weiss P. Lovell SPARTA, Inc. February 24, 2008 Delay-Tolerant Networking Security Overview draft-irtf-dtnrg-sec-overview-04 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on August 27, 2008. Copyright Notice Copyright (C) The IETF Trust (2008). Farrell, et al. Expires August 27, 2008 [Page 1] Internet-Draft DTN Security Overview February 2008 Abstract This document provides an overview of the security requirements and mechanisms considered for delay tolerant networking security. It discusses the options for protecting such networks and describes reasons why specific security mechanisms were (or were not) chosen for the relevant protocols. The entire document is informative, given its purpose is mainly to document design decisions. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. This document . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Background . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Threats . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1. Non DTN node threats . . . . . . . . . . . . . . . . . . . 5 2.2. Resource consumption . . . . . . . . . . . . . . . . . . . 5 2.3. Denial of service . . . . . . . . . . . . . . . . . . . . 6 2.4. Confidentiality and integrity . . . . . . . . . . . . . . 6 2.5. Traffic storms . . . . . . . . . . . . . . . . . . . . . . 7 2.6. Partial protection is just that. . . . . . . . . . . . . . 7 3. Security Requirements . . . . . . . . . . . . . . . . . . . . 9 3.1. End-to-end-ish-ness . . . . . . . . . . . . . . . . . . . 9 3.2. Confidentiality and integrity . . . . . . . . . . . . . . 10 3.3. Policy based routing . . . . . . . . . . . . . . . . . . . 11 4. Security Design considerations . . . . . . . . . . . . . . . . 14 4.1. Only DTN-friendly schemes need apply . . . . . . . . . . . 14 4.2. TLS is a good model . . . . . . . . . . . . . . . . . . . 14 4.3. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 15 4.4. Naming and identities . . . . . . . . . . . . . . . . . . 16 4.5. Placement of checksums . . . . . . . . . . . . . . . . . . 17 4.6. Hop-by-hop-ish-ness . . . . . . . . . . . . . . . . . . . 17 5. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 19 5.1. Key management . . . . . . . . . . . . . . . . . . . . . . 19 5.2. Handling replays . . . . . . . . . . . . . . . . . . . . . 19 5.3. Traffic analysis . . . . . . . . . . . . . . . . . . . . . 21 5.4. Routing protocol security . . . . . . . . . . . . . . . . 21 5.5. Multicast security . . . . . . . . . . . . . . . . . . . . 21 5.6. Performance Issues . . . . . . . . . . . . . . . . . . . . 23 6. Security Considerations . . . . . . . . . . . . . . . . . . . 24 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 8. Informative References . . . . . . . . . . . . . . . . . . . . 26 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28 Intellectual Property and Copyright Statements . . . . . . . . . . 29 Farrell, et al. Expires August 27, 2008 [Page 2] Internet-Draft DTN Security Overview February 2008 1. Introduction This section places this document in its current context as one of a series of DTN documents. 1.1. This document This document is a product of the IRTF (http://www.irtf.org/) Delay Tolerant Networking Research Group (DTRNG) and is being discussed on the dtn-security mailing list. See the DRNRG site (http://www.dtnrg.org/) for details of the various DTN mailing lists. The intent is for this document to present a snapshot of the security analysis which has been carried out in the DTNRG. The document is not normative in any sense but is intended to be a companion document which explains further the reasons for the design choices which are documented elsewhere. The discussion includes updates based upon experience gained during implementation of the security protocol. The structure of the document is as follows: We first present a selection of threats which were considered during the analysis carried out so far. We then present some security requirements derived from that analysis or elsewhere. We next present some of the design considerations which were applied during the design of the security mechanisms. And we finally discuss some of the remaining open issues in DTN security. Given that this is simply an informative snapshot document, none of the above are intended to be exhaustive, nor should other documents be criticized because something is mentioned here, but not countered there. While this document is being prepared in parallel with the various protocol and security specifications, we will generally try not to refer to the specific fields used in those documents since the details may change and maintaining consistency at that level is not a goal here. Where we do refer to such details, of course, the specification documents are normative. Farrell, et al. Expires August 27, 2008 [Page 3] Internet-Draft DTN Security Overview February 2008 1.2. Background The overall delay tolerant networking (DTN) architecture is described in [1]. A DTN is an overlay network on top of lower layer networks, which may vary from node to node. Some of these are challenged by limitations such as intermittent loss of connectivity, long or variable delay, asymmetric data rates, or high error rates. The purpose of a DTN protocol is to support interoperability across such potentially stressed lower layer networks. The DTN overlay network specifies a bundle protocol which is layered on top of a "convergence layer", which is itself on top of other lower layers. The DTN Bundle Protocol [2] describes the format of the messages (called bundles) passed between DTN bundle agents that participate in bundle communications to form the DTN store-and-forward overlay network. The Bundle Security Protocol Specification [3] defines the integrity and confidentiality mechanisms for use with the Bundle protocol together with associated policy options. Two other documents exists which are now somewhat outdated but remain worthwhile reading: A tutorial [4] about DTNs and an early DTN security model document [5]. There is also a related lower layer protocol specifically designed for very long delay environments, called the Licklider Transmission Protocol (LTP), [6] and which is also being developed by the same group. Even though the LTP protocol shares some security features [7] with the bundle protocol, we will mainly reference the bundle protocol here since its environment is much more complex and there is also a separate LTP motivation document [8]. In this document we may refer to "messages" to mean either a bundle from the bundle protocol or a segment from the LTP protocol. The context should make the meaning clear in each case. Farrell, et al. Expires August 27, 2008 [Page 4] Internet-Draft DTN Security Overview February 2008 2. Threats This section describes some of the threats considered during the design process of the DTN security mechanisms. In this discussion,and throughout the document, we try to highlight DTN- specific aspects, assuming the reader is generally familiar with basic networking security concepts. 2.1. Non DTN node threats The first set of threats considered were those coming from network elements which aren't directly part of the DTN. As an overlay network, bundles typically traverse multiple underlying network elements on each DTN "hop". Any vulnerability in the bundle protocol can be exploited at any of those network elements. DTN security must take into account the usual range of such potential exploits (masquerading, bit flips, etc.) but in contrast to most network protocols, as an overlay protocol, the bundle protocol is possibly an easier target. In particular, if it is possible to insert new bundles at such lower-layer "hops", then DTN nodes have to be capable of countering such insertions by where possible, detecting and quickly deleting such spurious bundles. Conversely, it is equally possible to take advantage of lower layer network security services, but this isn't be visible from the DTN layer, and requires coordinated administration in order to be really effective. 2.2. Resource consumption Due to the resource-scarcity that characterizes DTNs, unauthorized access and use of DTN resources is a serious concern. Specifically, the following can consume DTN resources and be considered threats against a DTN infrastructure: 1. access by unauthorized entities, 2. unauthorized applications controlling the DTN infrastructure, 3. authorized applications sending bundles at a rate or class of service for which they lack permission, 4. unauthorised bundle content modification, 5. compromised network elements, be they DTN nodes or not. In addition to these threats, DTN nodes can act to assist or amplify Farrell, et al. Expires August 27, 2008 [Page 5] Internet-Draft DTN Security Overview February 2008 such resource consuming behavior as follows: 1. forwarding bundles that were not sent by authorized DTN nodes 2. generating reports not originally requested (e.g. if a bundle has been modified). 3. not detecting unplanned replays or other mis-behaviors 2.3. Denial of service In addition to the basic resource consumption threats mentioned above there is also a range of denial of service (DoS) attacks which must be considered in the DTN context. DTNs are in this respect, in more- or-less the same position as other MANETs so all the problems with secure routing in ad-hoc networks [9] exist for many DTNs too! DoS attacks can be mounted at any layer, from physical to application. Generally when developing a new protocol we should attempt two things:- - Make it hard to launch an "off-path" DoS attacks by making it hard to "guess" valid values for messages, e.g. through using random values instead of counters for identifying messages. - Make it easier to withstand "on-path" DoS attacks by providing a way to choke-off DoS traffic, e.g. by changing to a mode of operation where only fresh, authenticated messages are accepted and all others are dropped. In a DTN environment, the generally longer latencies involved will probably act to make DoS attempts more effective, so protocol developers and deployments should explicitly consider DoS at all times. As with all networks, security mechanisms will themselves create new DoS opportunities. Therefore whatever services and mechanisms are defined for DTN security should explicitly consider DoS. For example, mechanisms which involve certificate status checking (via some protocol to a key server) based on received messages create new DoS opportunities since such lookups consume resources on both the receiving node and the key server. 2.4. Confidentiality and integrity In addition to resource consuming threats, DTN applications can also be vulnerable to threats against confidentiality and integrity, such as: Farrell, et al. Expires August 27, 2008 [Page 6] Internet-Draft DTN Security Overview February 2008 1. falsifying a bundle's source, 2. changing the intended destination, 3. changing a bundle's control fields, 4. changing other block or payload fields, 5. replay of bundles 6. copying or disclosing bundle data as it passes. 2.5. Traffic storms Since DTN protocols generate traffic as an artifact of other traffic, manipulation of bundle content, genuine, forged or modified, can be used to create unwanted traffic. In a DTN operating sufficiently "close to the wire", such traffic can have serious affects. The Bundle Protocol includes various messages containing administrative records (e.g. bundle status reports, custody signals) produced in response to original traffic. The protocol specification, however, includes a constraint that the status report request flags must be zero on all bundles containing administrative records. Although a bundle that is not a custody signal or status report may cause the generation of custody signals and/or status reports, bundles that are themselves custody signals or status reports are not permitted to cause the generation of custody signals or status reports. This constraint is designed to prevent bundle storms and it does in the case when bundles can not be modified. If a DTN node (or other network element) could modify a "forwarding report" by resetting its "Application Data Unit is an Administrative Record" bundle flag and setting its "forwarding report" request flag, then this could cause the forwarding of an additional status reports, and so on. Traffic could continue to be generated in this manner for as long as the values of the bundle processing flags and the status report request flags can be modified. While the constraint prohibiting bundles containing administrative records from generating other bundles containing administrative records helps prevent traffic storms, it may be best to entirely remove some of status reporting capabilities from the Bundle Protocol. 2.6. Partial protection is just that. Not all DTN nodes need to protect all parts of all bundles. Fr example, some DTN nodes won't be able to protect the integrity of the entire bundle including its payload. Reasons range from lack of computing power to application (or lower) layer protection mechanisms Farrell, et al. Expires August 27, 2008 [Page 7] Internet-Draft DTN Security Overview February 2008 already applying integrity. Alternatively, some DTN nodes may choose not to protect all parts of all bundles in order to permit reactive fragmentation. There are also cases when bundle blocks will be modified in transit (e.g. the dictionary in the primary block), or a "via" block which captures the route a bundle has followed. As a result, integrity checking on anything more than a hop-by-hop basis becomes unwieldy other than for the payload. So it is possible that some fields of a bundle are strongly protected whilst others are effectively unprotected. Whenever such a situation occurs, it will be still possible for network elements to use the bundle protocol as a communications channel, perhaps covert or perhaps overt. Where such misuse is a concern, the DTN should either use different security options which cover the fields of concern, or else administrators must ensure that the bundles only traverse lower layers where the probability of such misuse is sufficiently small. Farrell, et al. Expires August 27, 2008 [Page 8] Internet-Draft DTN Security Overview February 2008 3. Security Requirements This section describes some of the high-priority DTN security requirements. 3.1. End-to-end-ish-ness Traditionally, protocols tend to provide security services which are used either (or both) on a hop-by-hop or end-to-end basis. For DTN security though, we require that these services be usable also between nodes which are not endpoints but which can be in the middle of a route. For example, if a sensor network employs lower layer security and has some gateway sensor node which is more capable and is periodically connected to the Internet, we may use DTN security services to protect messages between that gateway node and the other DTN sources and destinations on the Internet-side of the gateway. In the case of a confidentiality service, this is clearly useful since bundles which leave the sensor network could be encrypted (by the gateway node) for the final destination. In the case of say a software download, new code might be integrity protected from the origin to the gateway which is able to check some relevant white or black lists or use some other software authorisation scheme which cannot practically be used from a sensor node. In order to define services which can be used in these ways we distinguish between the sender of a bundle and the security-sender for an application of one of these services. Similarly, we can distinguish between the bundle recipient and the security-recipient (or security-destination) for a given application of a security service. Basically, the security-sender is the DTN node that applied the security service, and the security-recipient (or security- destination) is the DTN node which is the target for the security service - say the node expected to decrypt or do integrity checking. The extent to which the various security services can be combined for the same or different security senders and destinations needs to be made clear in the relevant protocol definition. However, this should be kept as simple as possible since unwanted complexity is highly likely to make a DTN harder to manage, and thereby less secure. Experience with fragmentation issues has shown that there is good reason to distinguish (at the protocol field level) between uses of these services which are intended to be hop-by-hop (i.e. between this and the next DTN node), as opposed to end-to-end, at least for integrity checking. Equally, a protocol might not need to make this distinction and might only define e.g. one confidentiality service Farrell, et al. Expires August 27, 2008 [Page 9] Internet-Draft DTN Security Overview February 2008 which can be applied multiple times for a single bundle with different combinations of security-sender and security-recipient. There is another example in which DTN security services differ from more "normal" network security services. (Indeed this mode of operation might be useful in non-DTNs too!). When a message is authenticated using a digital signature, in principle any network element on the path can do some checking of that signature. If the message contains sufficient information (the supposed signer's public key or a resolvable reference thereto) then any node can at least check the cryptographic correctness of the signature. Although useful, this is typically insufficient to decide how to process the message, since in many environments basically anyone could insert a public key and a signature, producing a message which passes this test. In most real cases, there are some additional checks that the signer is authorised, either explicitly by checking that the signer's name or key is authorised for the purpose, or implicitly by using a PKI (e.g. via an extended key usage extension). It turns out that all practical ways to perform such authorisation checks are problematic in some DTN cases due either to the lack of an authorisation server (e.g. due to latency to/from from the verifier to the relevant authorisation server) or to restricted node capabilities, such as the case of a sensor node. In such cases, it may be sensible for some "bastion" node along the route to do the authorisation check and then to (again explicitly or implicitly) attest that the authorisation test has passed. Subsequent nodes, may however, for either data integrity or accountability reasons wish to also validate the cryptographic correctness of the signature. The end result might be a mechanism whereby the message has a signature plus some meta-data which are fully processed by the "bastion" node, whereas the signature is only partly processed by all subsequent nodes. (Note: The role of the "security-destination" concept in such cases is not yet clear.) These issues are not addressed by the current series of DTN specfications and it is likely that a new document [10] will be required to deal with them. 3.2. Confidentiality and integrity Since most protocol designs use common elements to deal with all cryptographic based security services and mechanisms, they will all be dealt with in this section. DTN protocols should provide a means to encrypt protocol elements so that messages in transit cannot practically be read. The bundle Farrell, et al. Expires August 27, 2008 [Page 10] Internet-Draft DTN Security Overview February 2008 protocol itself provides no confidentiality for the source or destination endpoint addresses, or any other endpoints included in the dictionary. This can be achieved using bundle-in-bundle encapsulation (BiB) if necessary. Clearly, calling for a confidentiality service implies a need for key management. However, DTN key management remains an open issue, so we presently expect DTN protocols to support pre-shared-keys (and/or known irrevocable certificates). Similarly, DTN protocols should provide a means to apply an integrity check to a bundle so that the identity of the security-sender can be established and changes in sensitive parts of the message can be detected. The bundle authentication block (BAB) and payload security block (PSB) have been specified to provide these services on a hop- by-hop and end-to-end basis respectively. Again, this implies a need for key management which is not met so far. Clearly a protocol should allow a fairly flexible combination of applications of the confidentiality and integrity services, though hopefully disallowing insecure combinations (e.g. a plaintext signature which is out of scope of a confidentiality service allowing plaintext guesses to be verified). These services should allow sensible combinations of a range of standard cryptographic algorithms to be used and should also allow changes to be made over time to the set of acceptable algorithms. 3.3. Policy based routing Since the DTN, as a piece of infrastructure, may be quite fragile, we require protocols to be cautious regarding their consumption of network resources. We require that DTN protocols and implementations support mechanisms for policy-based routing. In other words each DTN protocol specification should state the security-relevant policy variables upon which routing and forwarding decisions can be made. While this is still a little vague, the expectation is that each DTN specification should, in its security considerations text, say which security issues may exist which require a routing or forwarding policy decision to be made. In particular, since forwarding even a single bundle will consume some network resources, every DTN node must implicitly incorporate some element of policy-based routing. We do not expect that every DTN node will be able to handle complex policy decisions. A DTN node can be programmed to forward all bundles received in a deterministic Farrell, et al. Expires August 27, 2008 [Page 11] Internet-Draft DTN Security Overview February 2008 manner, (e.g. flooding the bundle to all peers other than then one from which it was received). Even such a simple minded node is however, implicitly implementing a policy - in this case a simple flooding policy. So, though we require all nodes to implement some policy, that policy can be very simple. Regardless of how simple or complex a node's support for policy based routing/forwarding might be, DTN implementers should document the relevant aspects of the implementation. In the absence of such documentation a node might be deployed in an inappropriate context, potentially damaging an entire network. Some DTN nodes will however be on boundaries of various sorts, whether they be network topology related, administrative, networking technology related or simply a case where this node is the first which is capable of handling complex policy decisions. At one stage these nodes were termed security policy routers, and were considered to be "special" nodes. Our current view though, is that all nodes are in fact policy routers with some implementing policies which are more complex than others. All nodes implement policy to some extent but not all will be security-aware. Setting a security-destination other than the bundle destination imposes a routing requirement which is expressed only in security extension blocks. Some nodes will be unable to process these and might route bundles to their destination bypassing the security-destination(s). The result would be that the bundle integrity cannot be verified or that the payload is unreadable because it had not been decrypted at the security-destination. We do not, at this stage, require that there be an interoperable way to transfer policy settings between DTN nodes. Such a system could perhaps be developed (though it is an extremely complex task), but pragmatically, for now we consider the development of a DTN specific policy language and distribution framework out of scope. DTNs themselves do not appear to generate many new types of policy based controls - the usual ingress, egress and forwarding types of control can all be applied in DTNs. For example, some "bastion" node might insist that all inbound bundles be authenticated and might add an authentication element to all outbound elements. So all the usual forms of control can, and should be, available for use in DTN nodes. The DTN specific policy controls identified thus far, and for which we would recommend support include: Farrell, et al. Expires August 27, 2008 [Page 12] Internet-Draft DTN Security Overview February 2008 - time-to-live (TTL) type controls where we consider the amount of time for which a bundle has been "in-flight" - controls to do with "strange" routes, such as those that loop - controls handling local or global information about resource constraints in the DTN (e.g. knowledge of a peer's storage capacity) - controls related to special types of fragmentation (e.g. reactive fragmentation) which are defined in a DTN No doubt, more will be identified as DTN implementation and deployment experience is gained. DTN node implementations will also be required to control access to whatever DTN interface they provide so that only authorized entities can act as the source (or destination) of bundles. Clearly this aspect of access control is an implementation, rather than a protocol issue. It must be noted that policy based routing, if not deployed appropriately, may inadvertently create bundle "sinkholes". Consider the case in which a bundle is fragmented and one fragment of the bundle reaches a router whose policy requires it to see the entire bundle. All fragments of that bundle must also pass through that same router and, if they do not, then eventually the fragment at our paranoid router will expire. Ultimately the entire bundle never arrives at the intended destination. This is clearly a case to avoid - doing so, may be difficult to arrange without good route control. Farrell, et al. Expires August 27, 2008 [Page 13] Internet-Draft DTN Security Overview February 2008 4. Security Design considerations This section discusses some of the security design considerations used during the development of the DTN security mechanisms 4.1. Only DTN-friendly schemes need apply The high round-trip times and frequent and unpredictable disconnections that are characteristic of DTNs mean that security solutions which depend on ubiquitous online security services cannot generally be applied. Therefore solutions requiring ubiquitous access to servers (e.g. Kerberos, XKMS) are problematic. This is more-or-less analogous to the way that TCP won't work in DTNs. Such solutions might be usable from a range of DTN nodes within some security domain, although in that case what happens when a route spans more than one such domain remains to be researched. The long delays that may be inherent in DTNs mean that data may be valid (even in-transit) for days or weeks, so depending on message expiration alone to rid the network of unwanted messages will also be problematic. How long is "too long" and how short is "too short", and how well are the clocks synchronized? The impact of this design consideration most obviously applies to key management, but it will also apply to other aspects of security including distribution of new policy settings. 4.2. TLS is a good model The Transport Layer Security (TLS) specification [11] provides us with some useful design ideas, especially in its use of "ciphersuites". In TLS, a ciphersuite is a single number that defines how all of the various cryptographic algorithms are to be used. The ciphersuite number is used in TLS negotiation. One of the more common ciphersuites is usually called "TLS_RSA_WITH_3DES_EDE_CBC_SHA" indicating that the TLS protocol is being used with RSA based key transport and with a variant of triple- DES as its bulk encryption algorithm and SHA-1 for various digesting tasks. DTN can use a ciphersuite value in the same way - to indicate which cryptographic algorithms are in use for what purpose. This is how we can support both symmetric and asymmetric mechanisms for our cryptographic security services, and also allows us to extend DTN security in the future (e.g. use of identity based cryptography schemes). In DTNs, we won't be doing negotiations of the sort done in TLS that Farrell, et al. Expires August 27, 2008 [Page 14] Internet-Draft DTN Security Overview February 2008 require multiple round-trips, but we can still use the ciphersuite idea. In fact, we extend it a little more to use the ciphersuite to also indicate which services are being applied (integrity or confidentiality) and also the set of input bits for the service. In this way we can distinguish between an integrity service which only protects the blocks from one that also protects the payload. The DTN concept of ciphersuite also encompasses the idea of having different parts of the bundle protected by the relevant security service, as described in the next section. 4.3. Fragmentation Fragmentation of a bundle is one of the more difficult DTN problems. There are many scenarios and what may work well for some may be useless for others. The two major issues are: - some DTN networks may have extraordinary long propagation delays, which may look more like two one-way links - the bundle payload is a single block and not a sequence of packets The one-way-link issue is a severe handicap to the sending node, as it has little or no feedback on the progress or status of the transmission. Cooperation between the sender and receiver is difficult or impossible. The payload is a single block but it can be split into smaller pieces as long as each becomes its own bundle, sometimes called a "fragment bundle". These are treated individualy after the fragmentation event and can be sent separately to the destination, and with varying levels of security depending upon the paths taken. Fragmentation in DTN can happen in two ways. "Proactive fragmentation" is the deliberate action of a node, which has an entire bundle, to break it into smaller pieces. So-called "reactive fragmentation" is where we try to optimize retransmission after a connection failure of some kind. It assumes some level of interaction between the sender and receiver, so that the sender can restart from the point of failure or thereabouts. In this way, even very large bundles can be sent across intermittent or episodic links, piece by piece, and the fragments reassembled later. Proactive fragmentation is reasonably interoperable with security processing but reactive fragmentation does not work well. As an example, consider the case of a node that has received the first 10 MB of a 20 MB bundle when the link fails and cannot be recovered by the underlying transport layer. The node has to decide whether to Farrell, et al. Expires August 27, 2008 [Page 15] Internet-Draft DTN Security Overview February 2008 forward the 10 MB fragment as a fragment-bundle. However, it cannot be integrity checked since not all bytes are present, which clearly is a breach of integrity. The receiving node might request the sender to create and send a signature for the amount received, which would be faster than a complete bundle retransmission. The first fragment with its integrity check could be forwarded, and the original sender could create another fragment-bundle containing the remainder of the initial bundle data. This approach presupposes a high level of coordination, and also that a suitable link can be reestablished. An alternative discussed for handling this is to associate a number of checksums with the bundle - say one for every 100k in this case, so that the entire bundle would use 20 checksums to provide end-to- end integrity. If the reactively forwarded fragment has the first 10 checksums its integrity can be checked. This comes at the expense of complexity and additional bytes of overhead (in this case perhaps 400 or more bytes), so it won't be desirable in most cases. Since each checksum protects a part of the payload, this scheme has been referred to as the "toilet paper" scheme - each forwardable fragment consisting of a number of sheets of payload-paper with its associated checksum. In order to support this type of fragmentation, we would have to define the relevant toilet paper ciphersuites in the security protocol specification. (At the time of writing, hopefully these schemes can be deprecated since they are clumsy and overly-complex for the benefit achieved.) In summary the DTN concept of ciphersuite is borrowed from TLS and slightly extended to allow different parts of the bundle to be protected by the relevant security service. However, in general DTNs cannot support the use of the TLS handshake protocol as used in the terrestrial Internet. One additional problem has recently become apparent and is currently under investigation. Various actions change the payload and the specific problem is that the payload length changes when encrypted using a block-mode cipher. This creates ambiguity for custody- transfer and for fragment-reassembly. 4.4. Naming and identities Most security mechanisms work well with only certain kinds of identity. For example, Kerberos style security tends to go with domain-specific login names, PKI tends to work best with X.500 or LDAP-style names, and to a lesser extent with RFC822 addresses. In bundles, endpoint identifiers are represented as URIs. However, there is no well-defined URI scheme specifically required to be Farrell, et al. Expires August 27, 2008 [Page 16] Internet-Draft DTN Security Overview February 2008 supported. As a result, there is work to be done to map URIs to the types of identity which are easily supported by whatever mechanisms being considered. In LTP, identities are flat octet strings, so again there is work to be done to map from these to e.g. user identities in a specific security mechanism. 4.5. Placement of checksums As currently specified, the bundle protocol requires that the last block in the bundle be identified as such by setting its "Last block" block processing flag. This bit enables security blocks to be placed either before or after the bundle payload block. The ability to place a signature after the bundle payload block, at the end of the bundle, is important for integrity-protecting some bundles at nodes that have limited buffer space. For example, if a node wishes to sign a 10Mb bundle, but it only has 1Mb of usable buffer, then creating a digital signature over the 10Mb and sending that out before the end of the payload is simply impossible. However, due to the properties of most hash functions, were the signature to be placed at the end of the bundle, then such a constrained node could in fact send out the signed bundle. This is due to the fact that hash functions have a continuation property which allows the to-be-hashed data to be fed through the function in blocks with only a small amount of state information required to be stored. For this reason, DTN security protocols have the option of placing either a single block in the message or placing correlated blocks in the message, for example one at the start of the message which specifies the signature/hashing to be used (the ciphersuite in our case), and one (that contains the actual signature or MAC) at the end of the entire bundle. The ability to place such correlated security blocks in the message allows even very memory-constrained nodes to be able to process the bundle and verify its security result. 4.6. Hop-by-hop-ish-ness In the above we discussed how security services can be applied which are not "truly" end-to-end. In the limit of course, we can use such a scheme to apply security just between this DTN node and the next hop. In particular there is clearly benefit in many cases from applying integrity checks on such a hop-by-hop basis. There are two things worth noting about this particular case: Farrell, et al. Expires August 27, 2008 [Page 17] Internet-Draft DTN Security Overview February 2008 - Even though the protocol data units involved in end-to-end-ish and hop-by-hop-ish applications of security services may be almost identical, there may be benefit in artificially distinguishing between them since one could imagine many nodes which would only ever require (and thus properly support) hop-by-hop security. In fact, one could reasonably define ciphersuites which are only useful in such a hop-by-hop fashion. - There doesn't seem to be much interest in making such an artificial distinction for confidentiality services, perhaps since the ability to use lower layer security is presumed to be much more common when the DTN nodes are "close" like this. In any case, the current version of the bundle security protocol does use different blocks for hop-by-hop vs. end-to-end integrity. Farrell, et al. Expires August 27, 2008 [Page 18] Internet-Draft DTN Security Overview February 2008 5. Open Issues This section discusses some of the issues which are still very open, either due to a lack of consensus in the DTNRG, or due to there being areas (like DTN key management) where much basic research remains to be done. Where an issue has been discussed previously (e.g. source confidentiality), we will not include it here again. 5.1. Key management The major open issue in DTN security is the lack of a delay-tolerant method for key management. We are at the stage where we only really know how to use existing schemes, which ultimately require an on-line status checking service or key distribution service which is not practical in a high delay or highly disrupted environment. Note that even though some identity based cryptography (IBC) schemes superficially appear to solve this problem (once we assume that the originator has a name for the destination endpoint), this is in fact not the case. The problem is that current IBC schemes effectively act only as a kind of "group certificate" where all of the nodes using a given private key generator can use a single "certificate", but the problem of validity for that "certificate" (which will contain the generator's parameters) is the same problem as verifying a CA certificate in a standard PKI. So, the only generally applicable schemes we currently have are basically equivalent to shared secrets or else irrevocable public key (or certificate based) schemes. Clearly, this is an area where more research work could produce interesting results. 5.2. Handling replays In most networking scenarios, we either wish to eliminate or else dramatically reduce the probability of messages being replayed. In some DTN contexts this will also be the case - particularly as replaying a (e.g. authenticated, authorized) message can be a fairly straightforward way to consume scarce network resources. However, there are also DTN scenarios where we wish to deliberately replay messages, even to the extent of routing messages around a loop. For example, if Bob is willing to act as a data mule for Alice, who has limited storage, then Bob might pick up a bundle as he passes Alice on his outbound journey from his Internet-connected home location. As he goes on however, Bob also runs into storage problems, so he temporarily deposits the bundle with Charlie, who Farrell, et al. Expires August 27, 2008 [Page 19] Internet-Draft DTN Security Overview February 2008 he's passing now, and who he'll also pass on his way back home, in say, a week's time. After a week, Bob indeed passes Charlie again and picks up that bundle for the second time, after which he goes on to successfully deliver the bundle via the Internet-connected node at home. Now in this scenario, the same bundle is received by Bob twice, and so would likely trigger any replay detection algorithm that Bob is running, but of course, the behavior as described is nominal for the circumstances presented. In addition, there are some routing schemes which involve duplicating messages. For example, a node might flood all its peers with a copy of a message to increase the probability that it will arrive at the destination before it expires. Clearly such routing schemes are likely to result in nodes seeing the same message more than once, but it's not clear whether any such node would be correct to delete such apparent "duplicates". The element of delay in DTNs also complicates handling replays. Replay detection schemes generally depend on noting some unique aspect of messages (via digesting of some message fields) and then keeping a list of (the digests of) recently seen messages. The problem in the DTN context is the "recently seen" part of such replay detection algorithms, since maintaining a list for say 30 days would be fairly resource intensive, but might be required if latencies are of that size. So the most obvious ways to protect against replays are problematic. The result is that the extent to which we can, or should, define a generic DTN replay detection scheme is hard to determine and at this point remains an open DTN security issue. It may be that this means that schemes need to be specified as part of a bundle routing algorithm. One aspect of replay handling where security can be enforced is setting the final destination bundle node to deliver each bundle only once to its application. In this way, even though replays can consume network resources, they are less likely cause application layer damage. An example of such damage would be a protocol which used a bundle to represent "Move the telescope 10 degrees left" - repeated replays of this message could result in damage if the telescope is pointed at the Sun. Of course, the application layer in this case ought also be detecting replays, e.g. by including a command number, but the example does demonstrate the point. Additional discussion relevant to at-most-once-delivery and a way to handle intentional resending of a bundle can be found in the DTN Retransmission Block specification [12]. Farrell, et al. Expires August 27, 2008 [Page 20] Internet-Draft DTN Security Overview February 2008 5.3. Traffic analysis We do not currently define any security services for protecting against traffic analysis. A general traffic analysis protection scheme is probably not, in any case, a realistic goal for DTNs, given their tendency to be resource-scarce and there have been no calls for a generic approach to this problem. However, for some disruption tolerant networks, hiding traffic (e.g. the existence of a signal from a sensor net) may be a very important security requirement. So, the first open issue here is the extent to which there is a real need for a generic scheme for protection against traffic analysis. If there were, then the second open issue is how to define such a scheme to be delay and disruption tolerant and which also doesn't consume too many resources. Finally, traffic analysis protection may be left as a local matter for the underlying network layers, e.g. if a particular radio link were of concern, then total obscuration of that link may be required, and may in fact be the only way to hide such radio traffic. 5.4. Routing protocol security Clearly whenever DTN routing protocols are defined they will introduce new security requirements, or at least change the emphasis to be properly placed on meeting the various requirements posited above. For example, one could expect that a robust and scalable origin-authentication scheme would become more important. At the time of writing there are no well-documented DTN routing protocols, so DTN routing protocol security must clearly be in our list of open issues. However, if a putative DTN routing protocol were to use either the Bundle protocol or LTP, it could clearly make use of their existing security features. 5.5. Multicast security In a DTN, bundles are sent to destination endpoints, and any given endpoint consists of a set of zero or more bundle nodes. A bundle that is sent to a given destination endpoint must be sent to all of the nodes that are in the minimum reception group of that endpoint. If an endpoint may contain multiple nodes and its minimum reception group is all of the nodes registered in that endpoint, then a bundle sent to that endpoint is functionally similar to "multicast" operations in the Internet. If an endpoint may contain multiple nodes and its minimum reception group is any given number of the nodes registered in that endpoint, then a bundle sent to that endpoint is functionally similar to "anycast" operations in the Farrell, et al. Expires August 27, 2008 [Page 21] Internet-Draft DTN Security Overview February 2008 Internet. Extensions to the bundle protocol for providing custodial transfer of bundles sent to multicast endpoints have been defined in [13]. Within DTN, there is currently no mechanism defined for restricting which nodes may register in a "multicast" or "anycast" endpoint. The security architecture currently does not address the security aspects of enabling a node to register with a particular mutlicast or anycast EID. Without a capability to restrict the registration of nodes in multicast or anycast endpoints, any node may register in such an endpoint and thereby receive traffic sent to that endpoint. In addition, even though an endpoint may be a singleton endpoint, meaning that it is not permitted to contain more than one node, it may be possible for a second (or more) node to register in a singleton endpoint and receive bundles that are sent to that endpoint if the bundles are routed in such a way that they are forwarded to that node (e.g. using flood routing). The mandatory end-to-end(ish) confidentiality and authentication ciphersuites that are defined in the Bundle Security Protocol require that all destination nodes use the same key material to decrypt and authenticate the received bundle. Modifications to the mandatory end-to-end(ish) ciphersuites or additional ciphersuites would need to be defined to provide the possibility that a bundle could be encrypted or authenticated differently for different nodes in its multicast or anycast endpoint. In addition, there are some new aspects to multicast endpoint membership security, given that most work to date has implicitly assumed that the signaling traffic (e.g. registering in the multicast endpoint) can occur in more-or-less "real" time. In a DTN, registering in a multicast endpoint may be more akin to signing up to a mailing list, so that bundles that originated before the registration occurred may be received afterwards. In principle, such a late registering node might get sent the entire mailing list archive either by design or in error. Even if some sort of mechanism to authenticate registering nodes were to be defined, there are still issues that arise out of the fact that the endpoint registration process may itself be lengthy. For example, if a registering node authenticates with some credential that has a notBefore time of January 1, 2007 (as an X.509 public key certificate might have), and some bundle created before that time is still to be delivered, should the notBefore time of the credential be part of the decision as to whether to route a given bundle to the registering node? In this case, probably the answer is "no", but in some contexts that could be the wrong answer, allowing new (cheap) identities access to old (expensively accrued) materials. Farrell, et al. Expires August 27, 2008 [Page 22] Internet-Draft DTN Security Overview February 2008 5.6. Performance Issues Provision of security within a DTN imposes both bandwidth utilization costs on the DTN links and computational costs on the DTN nodes. The provision of DTN security will consume additional bandwidth. The amount consumed depends on the way optional parameters are encoded, or not, and on thecryptographic algorithms used. In addition, if more than one security service is used for the same bundle (e.g. a MAC to be removed by the next hop and a signature for the final destination) more of the possibly limited amount of bandwidth available for security purposes will be used. The use of DTN security also imposes computational costs on DTN nodes. There may be limits regarding how much CPU can be devoted to security and the amount of computation will depend on the algorithms used and their parameters. Farrell, et al. Expires August 27, 2008 [Page 23] Internet-Draft DTN Security Overview February 2008 6. Security Considerations Since this entire document is an informative description of how the DTNRG are approaching security, there is little to say in this section. However, implementers of DTN protocols must not take text here to be normative, in the case of conflict the relevant protocol specification takes precedence. Farrell, et al. Expires August 27, 2008 [Page 24] Internet-Draft DTN Security Overview February 2008 7. IANA Considerations None. Farrell, et al. Expires August 27, 2008 [Page 25] Internet-Draft DTN Security Overview February 2008 8. Informative References [1] Cerf, V., Burleigh, S., Durst, R., Fall, K., Hooke, A., Scott, K., Torgerson, L., and H. Weiss, "Delay-Tolerant Network Architecture", RFC 4838, April 2007. [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-05.txt, work-in-progress, February 2008. [4] Warthman, F., "Delay-Tolerant Networks (DTNs) A Tutorial", http://www.dtnrg.org/ , March 2003. [5] Durst, R., "An Infrastructure Security Model for Delay Tolerant Networks", http://www.dtnrg.org/ , July 2002. [6] Ramadas, M., Burleigh, S., and S. Farrell, "Licklider Transmission Protocol", draft-irtf-dtnrg-ltp-09.txt, work-in-progress, January 2008. [7] Farrell, S., Ramadas, M., and S. Burleigh, "Licklider Transmission Protocol - Extensions", draft-irtf-dtnrg-ltp-extensions-06.txt, work-in-progress, October 2007. [8] Burleigh, S., Ramadas, M., and S. Farrell, "Licklider Transmission Protocol - Motivation", draft-irtf-dtnrg-ltp-motivation-05.txt, work-in-progress, October 2007. [9] Zhou, L. and Z. Haas, "Securing Ad-Hoc Networks", IEEE network vol 13, no. 6, Nov-Dec 1999, pp 24-30. [10] Farrell, S., "DTN Authentication, Authorization and Accounting", draft-irtf-dtnrg-bundle-aaa.-00.txt, work-in-progress. [11] Dierks, T. and E. Rescorla, "The TLS Protocol - Version 1.1", RFC 4346 , April 2006. [12] Symington, S., "Delay-Tolerant Network Retransmission Block", draft-irtf-dtnrg-bundle-retrans-00.txt, work-in-progress, April 2007. Farrell, et al. Expires August 27, 2008 [Page 26] Internet-Draft DTN Security Overview February 2008 [13] Symington, S., "Delay-Tolerant Network Multicast Custodial Transfer", draft-irtf-dtnrg-bundle-multicast-custodial- 00.txt, work-in-progress, May 2007. Farrell, et al. Expires August 27, 2008 [Page 27] Internet-Draft DTN Security Overview February 2008 Authors' Addresses Stephen Farrell Trinity College Dublin Distributed Systems Group Department of Computer Science Trinity College Dublin Ireland Phone: +353-1-608-1539 Email: stephen.farrell@cs.tcd.ie Susan Flynn Symington The MITRE Corporation 7515 Colshire Drive McLean, VA 22102 US Phone: 703 983 7209 Email: susan@mitre.org URI: http://mitre.org/ Howard Weiss SPARTA, Inc. 7110 Samuel Morse Drive Columbia, MD 21046 US Phone: +1-443-430-8089 Email: hsw@sparta.com Peter Lovell SPARTA, Inc. 7110 Samuel Morse Drive Columbia, MD 21046 US Phone: +1-443-430-8052 Email: peter.lovell@sparta.com Farrell, et al. Expires August 27, 2008 [Page 28] Internet-Draft DTN Security Overview February 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). Farrell, et al. Expires August 27, 2008 [Page 29]