[Search] [txt|pdf|bibtex] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06                                          
DTN Research Group                                            S. Farrell
Internet-Draft                                    Trinity College Dublin
Expires: September 2, 2006                                  S. Symington
                                                   The MITRE Corporation
                                                                H. Weiss
                                                            SPARTA, Inc.
                                                           March 1, 2006

              Delay-Tolerant Networking Security Overview

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-

   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

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on September 2, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2006).


   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,

Farrell, et al.         Expires September 2, 2006               [Page 1]

Internet-Draft            DTN Security Overview               March 2006

   given it's purpose is mainly to document design decisions.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  This document  . . . . . . . . . . . . . . . . . . . . . .  3
     1.2.  Background . . . . . . . . . . . . . . . . . . . . . . . .  3
   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.  Naming and identities  . . . . . . . . . . . . . . . . . . 15
     4.4.  Placement of checksums . . . . . . . . . . . . . . . . . . 16
     4.5.  Hop-by-hop-ish-ness  . . . . . . . . . . . . . . . . . . . 16
   5.  Open Issues  . . . . . . . . . . . . . . . . . . . . . . . . . 18
     5.1.  Key management . . . . . . . . . . . . . . . . . . . . . . 18
     5.2.  Handling replays . . . . . . . . . . . . . . . . . . . . . 18
     5.3.  Traffic analysis . . . . . . . . . . . . . . . . . . . . . 20
     5.4.  Routing protocol security  . . . . . . . . . . . . . . . . 20
     5.5.  Multicast security . . . . . . . . . . . . . . . . . . . . 20
     5.6.  Performance Issues . . . . . . . . . . . . . . . . . . . . 21
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 22
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 23
   8.  Informative References . . . . . . . . . . . . . . . . . . . . 23
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24
   Intellectual Property and Copyright Statements . . . . . . . . . . 25

Farrell, et al.         Expires September 2, 2006               [Page 2]

Internet-Draft            DTN Security Overview               March 2006

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 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

   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

   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.

1.2.  Background

   The overall delay tolerant networking (DTN) architecture is described
   in [1].  A DTN is an overlay network on top of multiple lower layer

Farrell, et al.         Expires September 2, 2006               [Page 3]

Internet-Draft            DTN Security Overview               March 2006

   networks, some of which may be 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 so-called convergence layer, (probably on top
   of even 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 generally 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 else a segment from the LTP protocol.
   The context should make the meaning clear in each case.

Farrell, et al.         Expires September 2, 2006               [Page 4]

Internet-Draft            DTN Security Overview               March 2006

2.  Threats

   This section describes some of the threats which were considered
   during the process of designing the DTN security mechanisms.  In this
   discussion (and throughout the document), we will try to highlight
   DTN-specific aspects and generally assume the reader is familiar with
   basic networking security concepts.

2.1.  Non DTN node threats

   The first set of threats to consider are those coming from network
   elements which aren't directly part of the DTN.  As an overlay
   network, bundles may traverse multiple underlying network elements on
   each DTN "hop".  Of course, 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 many DTN nodes will 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
   security services, but this won'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 consume DTN resources and can be considered as threats
   against the DTN as an 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.  modifying bundle content,

   5.  compromised network elements, be they DTN nodes or not.

   In addition to these threats, DTN nodes can act to assist or amplify
   such resource consuming behavior as follows:

Farrell, et al.         Expires September 2, 2006               [Page 5]

Internet-Draft            DTN Security Overview               March 2006

   1.  forwarding bundles that were not sent by authorized DTN nodes

   2.  generating reports which weren't originally requested (say 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 are 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!

   While DoS attacks can be mounted at any layer, from physical to
   application, generally when developing a new protocol we should be
   attempting to do 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

   As with all networks, security mechanisms will themselves create new
   DoS opportunities so whatever services and mechanisms are defined for
   DTN security should also explicitly consider DoS, e.g. 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

2.4.  Confidentiality and integrity

   In addition to the resource consuming threats, DTN applications can
   also be vulnerable to the usual threats against confidentiality and
   integrity, in particular the following:

Farrell, et al.         Expires September 2, 2006               [Page 6]

Internet-Draft            DTN Security Overview               March 2006

   1.  falsifying a bundle's source,

   2.  changing the intended destination,

   3.  changing the bundle's control fields,

   4.  changing other header or payload fields,

   5.  replay of bundles

   6.  copying or disclosing bundle data as it passes

2.5.  Traffic storms

   So long as DTN protocols include traffic generated as an artifact of
   other traffic, then the possibility exists that manipulation of
   (genuine, forged or modified) bundle content can be used to create
   unwanted traffic.  Given a DTN operating sufficiently "close to the
   wire", such traffic could have serious affects.

   In particular, the current bundle protocol includes various messages
   containing administrative records (bundle status reports and custody
   signals) that are produced in response to original traffic.  The
   Bundle Protocol, however, includes a constraint that the status
   report request flags on all bundles containing administrative records
   must be zero.  So, 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 so in the case in which bundles can not be
   modified.  If a DTN node (or other network element) could modify a
   single "forwarding report" by both resetting its "Application Data
   Unit is an Administrative Record" bundle processing flag and setting
   its "forwarding report" status report request flag, then the
   forwarding of a bundle status report could cause the forwarding of an
   additional status report, 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.
   So, while the constraint that bundles containing administrative
   records are not permitted to generate other bundles containing
   administrative records goes a long way toward preventing 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.

   Some DTN nodes won't need to protect all parts of all bundles.  Some

Farrell, et al.         Expires September 2, 2006               [Page 7]

Internet-Draft            DTN Security Overview               March 2006

   DTN nodes won't be able to properly protect the integrity of the
   entire bundle including its payload.  Potential reasons range from
   lack of computing power to application (or lower) layer protection
   applying integrity, with the result that there's no benefit in
   repeating this work in the bundle layer.  Alternatively, some DTN
   nodes may choose not to protect all parts of all bundles in return
   for being able to perform reactive fragmentation.

   There are also cases where bundle headers should be modified in
   transit (e.g. the dictionary header in some versions of the bundle
   protocol), or a "via" header which captures the route a bundle has
   followed, so that integrity checking on anything more than a hop-by-
   hop basis becomes unwieldy since the to-be-protected bytes are a
   moving target.

   The result is that it is possible that some fields of a bundle are
   strongly protected whilst others are effectively unprotected.
   Whenever such a situation occurs then it will be possible for network
   elements to at least use the bundle protocol as a communications
   channel, perhaps covert or perhaps overt.  Where such misuse is a
   concern, then the DTN should either use different security options
   which do cover the fields of concern, or else administrators (if they
   exist!) must ensure that the bundles only traverse lower layers where
   the probability of such misuse is sufficiently small.

Farrell, et al.         Expires September 2, 2006               [Page 8]

Internet-Draft            DTN Security Overview               March 2006

3.  Security Requirements

   This section lists some of the security requirements which were
   agreed as priorities during the development of the DTN security

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 uses some satisfactory lower layer
   security, and has some gateway sensor node, which is more capable and
   also say periodically connected to the Internet, then we may wish to
   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

   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 services can be combined for the
   same, or different security senders and destinations is something
   which has to be made clear in the relevant protocol definition.
   However, we can state a requirement that this should be kept as
   simple as possible since unwanted complexity in this respect is
   highly likely to make a DTN harder to manage, and thus less secure.

   Having said that, there may still be 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),

Farrell, et al.         Expires September 2, 2006               [Page 9]

Internet-Draft            DTN Security Overview               March 2006

   as opposed to uses of these services which are intended to be applied
   across multiple nodes.  Equally, a protocol might not need to make
   this distinction and might only define e.g. one confidentiality
   service which can be applied multiple times for a single bundle with
   different combinations of security-sender and security-recipient.

   There is one more example of the ways in which DTN security services
   seem to differ from more "normal" network security services, that is
   worth mentioning here.  (Indeed this mode of operation might be
   useful in non-DTNs too!).  When a message is authenticated using a
   digital signature, then 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.

   However, 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 thus producing a message which passes this
   test.  So in most real cases, there is some additional check that the
   signer is authorised, either explicitly by checking the signer's name
   or key is authorised for the purpose, or else implicitly by for
   example using a PKI for this purpose (say via an extended key usage
   extension).  It turns out that all practical ways to perform this
   authorisation check are problematic in at least some DTN cases,
   either due to the lack of availability of an authorisation server
   (say due to simple latency back from the verifier to the relevant
   authorisation server) or due to restricted node capabilities (say in
   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.)

3.2.  Confidentiality and integrity

   Since most protocol designs use common elements to deal with all
   cryptographic based security services and mechanisms, we will deal
   with all of these in this section.

   DTN protocols should provide a way to encrypt protocol elements so

Farrell, et al.         Expires September 2, 2006              [Page 10]

Internet-Draft            DTN Security Overview               March 2006

   that messages in transit cannot practically be read.  The extent to
   which a confidentiality service should be able to be applied to any
   or all protocol elements is a somewhat open issue.  In particular,
   whether or not source confidentiality should be provided is still
   under discussion.  Clearly, calling for a confidentiality service
   implies a need for key management.  However, a proper DTN key
   management scheme is still an open issue, so we would expect DTN
   protocols, to support pre-shared-keys (and/or known irrevocable
   certificates) in the meantime.

   Similarly, DTN protocols should provide a way to apply an integrity
   check to a message so that the identity of the security-sender can be
   established and so that changes in sensitive parts of the message can
   be detected.  Again, this implies a need for key management which is
   not, so far, really met.

   Clearly a protocol should allow for fairly flexible combinations 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 allows
   plaintext guesses to be verified.

   However these services are provided they should allow for sensible
   combinations of a range of standard cryptographic algorithms to be
   used and should also allow for changes to the set of acceptable
   algorithms to be made over time.

3.3.  Policy based routing

   Since the DTN, as a piece of infrastructure, may be quite fragile, we
   require protocols to be cautious in how they consume network
   resources.  While the intent of this is fairly clear, it is of course
   not testable so we need to be a little more prescriptive in order to
   state a testable requirement.

   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
   based upon which it is reasonable to expect an implementation should
   be able to make routing and forwarding decisions.  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 single DTN node must implicitly
   incorporate some element of policy-based routing.  Of course, we do

Farrell, et al.         Expires September 2, 2006              [Page 11]

Internet-Draft            DTN Security Overview               March 2006

   not expect that every single DTN node will be able to handle complex
   policy decisions.  In fact, a DTN node can be programmed to forward
   all bundles received in a deterministic manner, say 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

   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.

   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 on all inbound bundles being 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

   The DTN specific policy controls identified thus far, and for which
   we would recommend support include:

      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

Farrell, et al.         Expires September 2, 2006              [Page 12]

Internet-Draft            DTN Security Overview               March 2006


      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 deployment experience is

   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

   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 if one fragment of the
   bundle reaches a router who's policy requires it to see the entire
   bundle, then all fragments of that bundle must also pass through that
   same router.  If they do not, then eventually the fragment at our
   paranoid router will expire and ultimately the entire bundle never
   arrives at the intended destination.  This is clearly a case to avoid
   - doing so, may however be difficult to arrange without good control
   over routes.

Farrell, et al.         Expires September 2, 2006              [Page 13]

Internet-Draft            DTN Security Overview               March 2006

4.  Security Design considerations

   This section lists some of the security design considerations which
   were 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.  So solutions requiring ubiquitous access to
   such servers (e.g.  Kerberos, XKMS) are problematic.  This is more-
   or-less analogous to the way that TCP doesn't work in DTNs.  However,
   such solutions might be usable from a range of DTN nodes within some
   security domain, though in that case what happens when a route spans
   more than one such domain is an interesting question.

   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
   not work in general.

   The impact of this design consideration most obviously applies to key
   management, but it will also apply to other aspects of security, for
   example, distribution of new policy settings.

4.2.  TLS is a good model

   The Transport Layer Security (TLS) specification [10] provides us
   with some useful design ideas, especially in its use of what it calls
   "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 during negotiation.  One of the
   more common ciphersuites is usually called
   "TLS_RSA_WITH_3DES_EDE_CBC_SHA" indicating that the TLS protocol
   (rather than an earlier SSL version) 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.

   So we can obviously 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. if identity based cryptography
   schemes become usable.

   In DTNs of course we won't be doing negotiations of the sort done in
   TLS but we can still use the ciphersuite idea, and in fact, we extend

Farrell, et al.         Expires September 2, 2006              [Page 14]

Internet-Draft            DTN Security Overview               March 2006

   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 say an integrity service which only protects the
   headers, from one which also protects the payload.

   This allows us to address one of the trickier problems which was
   considered for DTN security - combining integrity checking with
   fragmentation.  So-called reactive fragmentation is where we try to
   optimize retransmission on the basis that we're fairly sure that some
   bytes were sent before a link dropped out unexpectedly.  What we do
   is basically start from where we left off (or from where we are
   confident that the recipient had received) in order to reduce the
   number of bytes re-transmitted.  Clearly though the recipient of such
   a fragment has a problem checking integrity - say if I've gotten the
   first 1MB of a 2MB bundle and then the link goes down.  I (the
   recipient) now have to decide whether to forward this fragment, but
   if I do forward it - it cannot be integrity checked in an end-to-
   end(-ish) fashion, since not all bytes are present, which clearly is
   a breach of integrity.

   One of the ways we've discussed for handling this is to associated 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.  The trick is that if the reactively forwarded
   fragment has the first 10 of those, then its integrity can be
   checked.  Of course 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 therefore have to
   define the relevant toilet paper ciphersuites, which is done in the
   security protocol specification.  (At the time of writing anyway -
   hopefully, these schemes can be deprecated since they are clumsy and
   overly-complex for the benefit accruing.)

   In summary the DTN concept of ciphersuite is borrowed from TLS and
   slightly extended to also encompass the idea of having different
   parts of the bundle being 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.

4.3.  Naming and identities

   Most security mechanisms work well, or at least work obviously well,
   with only some kinds of identity.  For example, Kerberos style

Farrell, et al.         Expires September 2, 2006              [Page 15]

Internet-Draft            DTN Security Overview               March 2006

   security tends to go with domain-specific login names, PKI tends to
   work best with X.500 or ldap style names (and well-ish with RFC822
   addresses).  In bundles the current scheme for endpoint identifiers
   is to represent them as URIs.  However, there is currently no well-
   defined URI scheme which is specifically required to be supported.
   This means that there is work to be done to map from these URIs to
   the types of identity which are easily supported by whatever
   mechanisms we're considering.

   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 your favorite
   security mechanism.

4.4.  Placement of checksums

   As currently specified, the bundle protocol requires that the last
   header in the bundle be identified as such by setting its "Last
   header" header processing flag.  This bit enables security headers to
   be placed either before or after the bundle payload header.  The
   ability to place a signature after the bundle payload header, 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

   For this reason, DTN security protocols have the option of placing
   either a single header in the message or placing correlated headers
   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
   headers in the message allows even very memory-constrained nodes to
   be able to process the bundle and verify its security result.

4.5.  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

Farrell, et al.         Expires September 2, 2006              [Page 16]

Internet-Draft            DTN Security Overview               March 2006

   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:

      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 - and
      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 a different header for this sort of hop-by-hop integrity.
   Whether this remains, or changes in future drafts, is an open issue.

Farrell, et al.         Expires September 2, 2006              [Page 17]

Internet-Draft            DTN Security Overview               March 2006

5.  Open Issues

   This section discusses some of the issues which are still very open,
   either due to a current lack of consensus in the DTNRG, or else due
   to their 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 main open issue in DTN security is the lack of a delay-tolerant
   method for key management.  It seems that 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

   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 (say 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

Farrell, et al.         Expires September 2, 2006              [Page 18]

Internet-Draft            DTN Security Overview               March 2006

   problems, and so he temporarily deposits the bundle with Charlie, who
   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 the
   nominal behavior for the circumstances presented.

   In addition to the example above, 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 the message will arrive at the destination before it (the
   message) 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

   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 however, the "recently seen" part of
   such replay detection algorithms, since maintaining such 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 this remains an open issue in DTN security.  It may well be
   that this means that replay detection schemes really need to be
   specified as part of a bundle routing algorithm.

   There is one aspect of replay handling where we can however enforce
   some security - the bundle node which is the final destination can be
   set to only deliver each bundle 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.)

Farrell, et al.         Expires September 2, 2006              [Page 19]

Internet-Draft            DTN Security Overview               March 2006

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 in addition 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

   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

   Work on what it means to use modes of operation like multicast,
   nearcast, anycast etc. in a DTN is really only beginning.  However,
   it is clear that there are some new aspects to this work, since most
   work to date has implicitly assumed that the signalling traffic (e.g.
   joining a group) can occur in more-or-less "real" time.  In a DTN,
   joining a multicast group may be more akin to signing up to a mailing
   list, so that messages originated before the join may be received
   afterwards - in principle such a DTN "joiner" might get sent the
   entire mailing list archive either by design or in error.

Farrell, et al.         Expires September 2, 2006              [Page 20]

Internet-Draft            DTN Security Overview               March 2006

   So, given that there are differences between "traditional" multicast
   and DTN "multicast", then we clearly have no real idea about the
   threats or security requirements which may apply.  Just to give an
   example of the type of issue to be considered: when joining if I
   authenticate with some credential which has a notBefore time of Jan 1
   2005, (as an X.509 public key certificate might have), and some
   message 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 the message to the "joiner"?  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.

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 consumes additional bandwidth which
   will depend on the way optional parameters are encoded (or not) and
   also on the cryptographic algorithms being used.  In addition, if
   more than one security service is used for the same bundle (say a MAC
   to be removed by the next hop and a signature for the final
   destination) then we are again chewing into the possibly limited
   amount of bandwidth available for security purposes.

   The use of DTN security also imposes computational costs on DTN
   nodes.  Again there may be limits as to how much CPU is worth
   devoting to security and the amount of computation will depend on the
   algorithms used and their parameters.

Farrell, et al.         Expires September 2, 2006              [Page 21]

Internet-Draft            DTN Security Overview               March 2006

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

   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 September 2, 2006              [Page 22]

Internet-Draft            DTN Security Overview               March 2006

7.  IANA Considerations


8.  Informative References

   [1]   Cerf, V., "Delay-Tolerant Network Architecture",
         draft-irtf-dtnrg-arch-04.txt, work-in-progress, December 2005.

   [2]   Scott, K. and S. Burleigh, "Bundle Protocol Specification",
         draft-irtf-dtnrg-bundle-spec-04.txt, work-in-progress,
         December 2005.

   [3]   Symington, S., Farrell, S., and H. Weiss, "Bundle Security
         Protocol Specification",
         draft-irtf-dtnrg-bundle-security-01.txt, work-in-progress,
         March 2006.

   [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-03.txt, work-in-progress, July 2005.

   [7]   Farrell, S., Ramadas, M., and S. Burleigh, "Licklider
         Transmission Protocol - Extensions",
         draft-irtf-dtnrg-ltp-03.txt, work-in-progress, July 2005.

   [8]   Burleigh, S., Ramadas, M., and S. Farrell, "Licklider
         Transmission Protocol - Motivation",
         draft-irtf-dtnrg-ltp-03.txt, work-in-progress, July 2005.

   [9]   Zhou, L. and Z. Haas, "Securing Ad-Hoc Networks", IEEE
         network vol 13, no. 6, Nov-Dec 1999, pp 24-30.

   [10]  Dierks, T. and C. Allen, "The TLS Protocol - Version 1.0", RFC
         2246 , January 1999.

Farrell, et al.         Expires September 2, 2006              [Page 23]

Internet-Draft            DTN Security Overview               March 2006

Authors' Addresses

   Stephen Farrell
   Trinity College Dublin
   Distributed Systems Group
   Department of Computer Science
   Trinity College

   Phone: +353-1-608-1539
   Email: stephen.farrell@cs.tcd.ie

   Susan Flynn Symington
   The MITRE Corporation
   7515 Colshire Drive
   McLean, VA  22102

   Phone: 703 983 7209
   Email: susan@mitre.org
   URI:   http://mitre.org/

   Howard Weiss
   SPARTA, Inc.
   7075 Samuel Morse Drive
   Columbia, MD  21046

   Phone: +1-410-872-1515 x201
   Email: hsw@sparta.com

Farrell, et al.         Expires September 2, 2006              [Page 24]

Internet-Draft            DTN Security Overview               March 2006

Intellectual Property Statement

   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

   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

Disclaimer of Validity

   This document and the information contained herein are provided on an

Copyright Statement

   Copyright (C) The Internet Society (2006).  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.


   Funding for the RFC Editor function is currently provided by the
   Internet Society.

Farrell, et al.         Expires September 2, 2006              [Page 25]