Delay Tolerant Networking Research                             S. Parikh
Group                                                       S. Symington
Internet-Draft                                                  K. Scott
Intended status: Experimental                                   R. Durst
Expires: October 17, 2011                                       R. Edell
                                                   The MITRE Corporation
                                                          April 15, 2011


      Delay-Tolerant Networking Superseding Bundle Extension Block
           draft-parikh-bundle-superseding-extension-block-01

Abstract

   This document defines an optional Bundle Protocol block called the
   Superseding Bundle Extension Block (SBEB) for use with the Bundle
   Protocol in the context of the Delay-Tolerant Networking
   Architecture.  Applications use this block to call for the removal of
   previously sent bundles that are rendered obsolete by more recent
   bundles.  Upon receiving a bundle with an SBEB, a node will search
   its bundle store (and outbound queues) for bundles that are obsoleted
   by other related bundles according to their source and destination
   EID, and the SBEB cookie (if present), and may delete some or all of
   them.  Discarding obsolete bundles helps conserve storage space and
   prevents expending resources in further forwarding bundles that are
   no longer relevant.  The bundle protocol already uses expiration
   times to remove bundles that are no longer useful to applications.
   The SBEB is a way for applications to mark bundles that a node may
   delete prior to their expiration times.

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any



Parikh, et al.          Expires October 17, 2011                [Page 1]


Internet-Draft                  DTN SBEB                      April 2011


   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on October 17, 2011.

Copyright Notice

   Copyright (c) 2011 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.
































Parikh, et al.          Expires October 17, 2011                [Page 2]


Internet-Draft                  DTN SBEB                      April 2011


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Motivation . . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Superseding Bundle Extension Block Format  . . . . . . . . . .  6
   4.  Superseding Bundle Block Processing  . . . . . . . . . . . . . 10
     4.1.  Bundle Transmission  . . . . . . . . . . . . . . . . . . . 10
     4.2.  Bundle Forwarding  . . . . . . . . . . . . . . . . . . . . 10
     4.3.  Bundle Reception . . . . . . . . . . . . . . . . . . . . . 11
       4.3.1.  SBEB Type 0  . . . . . . . . . . . . . . . . . . . . . 11
       4.3.2.  SBEB Type 1  . . . . . . . . . . . . . . . . . . . . . 12
       4.3.3.  SBEB Type 2  . . . . . . . . . . . . . . . . . . . . . 12
   5.  Interactions with Bundle Protocol Features . . . . . . . . . . 12
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 12
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 13
   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
     9.1.  Normative References (Note: the IDs listed here are in
           the RFC editor's queue; this document depends on them;
           replace with appropriate RFC references.)  . . . . . . . . 13
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 14
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14





























Parikh, et al.          Expires October 17, 2011                [Page 3]


Internet-Draft                  DTN SBEB                      April 2011


1.  Introduction

   This document defines an optional Bundle Protocol block called the
   Superseding Bundle Extension Block (SBEB) for use with the Bundle
   Protocol [RFC5050] in the context of the DTN Architecture [RFC4838].
   Applications use this block to call for the removal of previously
   sent bundles that are rendered obsolete by more recent bundles.  Upon
   receiving a bundle with an SBEB, a node will search its bundle store
   (and outbound queues) for bundles that are obsoleted by other related
   bundles according to their source and destination EID and the SBEB
   cookie (if present), and may delete some or all of them.  Thus, a
   bundle with an SBEB can trigger the flushing of bundles from nodes as
   it traverses the network.  A newly arriving bundle might render
   obsolete an older bundle that is currently in the store, and the node
   may delete it.  If an older bundle arrives after a newer bundle
   (possible because of out-of- sequence arrivals), then the node may
   delete the older (but most recently arrived) bundle.  The SBEB
   includes a retention count that instructs the node to retain a number
   (not just one) of the newest bundles according to their timestamp.
   Discarding obsolete bundles helps conserve storage space and prevents
   expending resources in further forwarding bundles that are no longer
   relevant.  The bundle protocol already uses expiration times to
   remove bundles that are no longer useful to applications.  The SBEB
   is a way for applications to mark bundles that a node may delete
   prior to their expiration times.  However, this extension is not
   intended as a reliable mechanism for applications to eliminate
   bundles in the network; it is intended to assist in reducing the load
   on DTN nodes and the network.  The capabilities described in this
   document are optional for deployment with the Bundle Protocol.  The
   use of this extension block is voluntary by applications, and even
   bundle nodes that support it can choose to ignore it.  To support
   this extension, a bundle protocol agent must be capable of receiving
   bundles with this extension block and processing them as described in
   this document.


2.  Motivation

   This extension is motivated by applications that send "cyclic
   telemetry", that is, bundles containing information that supplants
   information in previously sent bundles.

   The primary example comes from applications that distribute status
   updates.  Consider a server that tracks the location of vehicles and
   distributes that information to clients over a network of DTN nodes.
   The server sends a bundle containing the location of a particular
   vehicle when that vehicle reports its position to the server.  The
   clients only want the most recent location of each vehicle; the



Parikh, et al.          Expires October 17, 2011                [Page 4]


Internet-Draft                  DTN SBEB                      April 2011


   history of the vehicle's location is not useful information (in this
   particular example).  Therefore, if multiple location updates are
   present in a node's bundle store, the node need only forward the most
   recent one.  By using SBEB, the server can send bundles that will
   replace older bundles along the path to the destination.  In this
   example, the application may use an EID that only identifies the
   source application, not the vehicle to which the bundle pertains
   (that is, it uses the same source EID regardless of the particular
   vehicle).  The payload will contain an identifier of the vehicle and
   its location; thus, a node will need additional information to
   identify bundles that pertain to a particular vehicle, because nodes
   do not examine bundle payloads.  The cookie field in the extension
   block can contain an identifier for the vehicle, and the node can
   search the bundle store for bundles with that cookie (in addition to
   the source and destination).

   A motivating case for retaining more than one matching bundle comes
   from a camera system that monitors highway traffic, intended for
   commuters to check roadways that are prone to gridlock or accidents,
   so they can plan their trip accordingly.  The camera sends a snapshot
   bundle once every minute to a collecting server over a network of DTN
   nodes.  The server then posts that image on a website which commuters
   check over the Internet (the cameras are not on the Internet).  The
   expiration time of bundles containing the snapshots are
   conservatively set to 10 minutes to give the image sufficient
   lifetime to traverse the challenged network of DTN nodes.  Suppose
   that an intermittent link in the challenged network results in
   snapshot bundles accumulating at a node.  Only the five (for the sake
   of example) most recent photos are useful; previous photos in the
   bundle store are not.  This gives an observer enough pictures to
   gauge the flow of traffic (something that might be difficult for the
   camera to compute), but a complete historical record of all images is
   not needed.  The SBEB instructs the node to retain only the freshest
   images and delete the others, thereby releasing storage resources and
   preventing the further transmittal of out-of-date bundles.  In this
   scenario (in contrast to the previous example), since each camera
   would have a unique source EID, the tuple of source EID, destination
   EID, and timestamp would be sufficient to identify obsolete bundles
   in a node's bundle store; no additional cookie is needed.

   Note that DTN nodes do not guarantee that bundles arrive at a node in
   order of timestamp.  Therefore, a node might discard the newly
   arrived bundle if a more recent one is already present in the bundle
   store.  The search only applies to bundles that are currently in the
   bundle store when the node acts in response to the SBEB.  The node
   does not track or consider the timestamps of bundles that have
   already departed the node.




Parikh, et al.          Expires October 17, 2011                [Page 5]


Internet-Draft                  DTN SBEB                      April 2011


   In some ways, the SBEB serves as a congestion control guidance
   mechanism for DTN nodes.  It provides applications a way to advise
   which bundles a node can remove to help conserve storage, and in this
   respect it supplements the bundle expiration time.  However, the goal
   of the SBEB is not to provide applications a way to reliably rid the
   network of stale bundles.  If storage and link resources are
   plentiful, nodes may choose to ignore the SBEB; applications should
   not depend on nodes to respond to the SBEB.


3.  Superseding Bundle Extension Block Format

   The SBEB Block uses the Canonical Bundle Block Format as defined in
   the Bundle Protocol [2], using the block layout without an EID
   Reference List.  That is, it is comprised of the following elements:

   1.  Block-type code (1 byte): Defined as in all bundle protocol
       blocks except the primary bundle block (as described in the
       Bundle Protocol).  The extension block type for SBEBs is
       [XXX_TO_BE_ASSIGNED_BY_IANA_XXX -- see Section 6]:

   2.  Block processing control flags (SDNV): Defined as in all bundle
       protocol blocks except the primary bundle block.  SDNV encoding
       is described in the Bundle Protocol.

       *  Bit 0 ("Block must be replicated in every fragment") SHOULD be
          set.

       *  Bit 2 ("Delete bundle if block can't be processed") MUST NOT
          be set.

       *  Bit 4 ("Discard block if it can't be processed") MUST NOT be
          set.

       *  Bit 6 ("Block contains an EID-reference field") MUST NOT be
          set.

   3.  Block EID references count and EID references: This field MUST
       NOT be present.

   4.  Block data length (SDNV): defined as in all bundle protocol
       blocks except the primary bundle block.  SDNV encoding is
       described in the bundle protocol.

   5.  Block-type-specific data fields as follows:






Parikh, et al.          Expires October 17, 2011                [Page 6]


Internet-Draft                  DTN SBEB                      April 2011


       SBEB Flags (SFLAGS, byte)  A byte of flags indicating whether or
          not an SBEB Cookie is preent, and the type of SBEB:

          Bit 0: Cookie Present:  Indicates the presence and type of
             SBEB cookie field contained in the current block:

             0: No cookie field present

             1: Cookie field present

          Bit 1: IsSigned  Indicates whether or not this SBEB contains a
             signature of the canonicalized version of the primary
             bundle block plus the SBEB.

             0: No hash present

             1: Hash present

          Bits 3-2: SBEB Type  Indicates the type operation to be done
             to determine which bundles to keep / discard:

             0  Supersede by freshness -- keep the most recent N
                bundles.

             1  Keep fixed time window -- keep all bundles with creation
                timestamps >= the creation timestamp of the current
                bundle minus N seconds.

             2  Supersede by sequence vector

             3  Reserved for future use

          Bits 7-3: Reserved  Reserved for future use.; these bits
             SHOULD b set to 0 on send and ignored on receipt.

       SBEB Cookie (SDNV)  If the Cookie Present bit of the SBEB flags
          indicates that an SBEB Cookie is present, then the SBEB Cookie
          MUST be included and MUST follow the SBEB Flags.  The SBEB
          Cookie is an opaque token used by forwarders to match the SBEB
          against those of other bundles the routers hold.  If the
          Cookie Present value is 0 (No cookie field present) then the
          SBEB Cookie MUST NOT be present.

       SBEB SigLen (SDNV)  If the 'IsSigned' bit of the SBEB Flags
          indicates that a signed hash is present, the length of that
          signed hash (the following field) appears here, encoded as an
          SDNV.




Parikh, et al.          Expires October 17, 2011                [Page 7]


Internet-Draft                  DTN SBEB                      April 2011


       SBEBSignature:  If the 'IsSigned' bit of the SBEB Flags indicates
          that a signed hash is present, that signed hash appears here.
          The signing mechanism used is RSA with SHA256 as specified for
          the id-sha256 PKCSv2.1 signature scheme in [RFC4055].  The
          hash is computed over the following fields of the Primary
          Bundle Block, in the order below with no padding in between:

          +  Version

          +  Source scheme

          +  Source scheme-specific part

          +  Creation timestamp time

          +  Creation timestamp sequence number

          +  Destination scheme

          +  Destination scheme specific part

          followed by the SBEB block (this block) itself, with the
          signature-related fields (SBEB SigLength and SBEBSignatures)
          fields of the SBEB omitted, followed by any required padding
          bytes as zeros; the hash is then signed and the result of the
          signing process becomes this field.  Nodes that process SBEBs
          are expected to be able to determine the correct signing key
          from the other fields of the bundle (such as the source EID).

   An alternate way to compute the hash could be to compute it over the
   concatenation of the mutable canonicalization of the bundle's Primary
   Bundle Block as defined in [I-D.irtf-dtnrg-bundle-security] section
   3.4.2, followed by the SBEB block (this block) itself, with the
   signature-related fields (SBEB SigLength and SBEBSignatures) fields
   of the SBEB omitted; the result of the signing process becomes this
   field.  Nodes that process SBEBs are expected to be able to determine
   the correct signing key from the other fields of the bundle (such as
   the source EID).  Using only the fields listed above doesn't allow
   for reuse of other code to manage mutable cononicalization of PBBs,
   but should be simpler.

      The rest of the fields of an SBEB differ depending on the value of
      the SBEB Type field.

      If the SBEB Type is 0 or 1, the last field of the SBEB is:






Parikh, et al.          Expires October 17, 2011                [Page 8]


Internet-Draft                  DTN SBEB                      April 2011


      Retention Field (SDNV)  For SBEB Type 0 (keep the most recent N
         bundles) this indicates the number of newest (by creation
         timestamp) matching bundles that a node MUST retain (if as many
         bundles are indeed available).  The value must be at least one
         for a node to search for and discard bundles in response to the
         SBEB; thus, a value greater than zero serves to activate an
         SBEB.  An application uses a value of zero on bundles that
         might later be subject to removal by a future bundle, but that
         do not themselves trigger the removal of bundles; this allows
         the application control over when to activate the discarding of
         older bundles.

         For SBEB Type 1 (keep bundles from the most recent N seconds)
         the retention field in conjunction with the bundle creation
         time indicates the threshold beyond which bundles should be
         retained.  Thus a router processing a bundle with an SBEB-2
         extension, a creation timestamp of M, and a Retention Field of
         N MUST retain all bundles with creation timestamps >= M-N.  The
         value must be at least one for a node to search for and discard
         bundles in response to the SBEB; thus, a value greater than
         zero serves to activate an SBEB.  An application uses a value
         of zero on bundles that might later be subject to removal by a
         future bundle, but that do not themselves trigger the removal
         of bundles; this allows the application control over when to
         activate the discarding of older bundles.

      If the SBEB Type is 2, the remainder of the SBEB contains a
      sequence number for this bundle together with a list of sequence
      numbers that this bundle obsoletes:



      SBEB Sequence Number (SDNV)  The SBEB sequence number of this
         bundle as assigned by the application.  Bundles with a
         particular (source, destination) pair SHOULD use monotonic non-
         decreasing values for their SBEB sequence numbers.

      Obsoletes Up To  A cumulative watermark sequence number of
         obsoleted bundles.  This bundle obsoletes all matching bundles
         with SBEB sequence numbers up to and including this value.
         This value MUST be less than the SBEB sequence number of this
         bundle.

      Obsoletes Vector Count (OVC, an SDNV)  Count of the number of
         sequence numbers in the obsoletes vector.






Parikh, et al.          Expires October 17, 2011                [Page 9]


Internet-Draft                  DTN SBEB                      April 2011


      Obsoletes List (sequence of SDNVs)  Vector of obsoleted sequence
         numbers.  Each element of the vector is a single sequence
         number that is obsoleted by this bundle.  Each value in the
         obsoletes vector MUST be less than the SBEB sequence number of
         this bundle.

   The Structure of a Superseding Bundle Extension Block is shown in
   Figure 1:

  +--------+--------------+--------------+--------+--------------------+
  |  Type  | Flags (SDNV) |Length (SDNV) | SFLAGS | Cookie (SDNV, opt) |
  +--------+--------------+-------+------+--------+--------------------+
  |                             SBEB Signature (if present)            |
  +-------------------------------+------------------------------------+
  | Retention field (SDNV)        |
  +-------------------------------+
               Figure 1: SBEB Format for SBEBS of type 0, 1

   The structure of a Superseding Bundle Extension Block of type 2 is
   shown in Figure 2:
  +--------+--------------+--------------+--------+--------------------+
  |  Type  | Flags (SDNV) |Length (SDNV) | SFLAGS | Cookie (SDNV, opt) |
  +--------+--------------+-------+------+--------+--------------------+
  |                             SBEB Signature (if present)            |
  +-------------------------------+------------------------------------+
  | SBEB Sequence Number (SDNV)   | Obsoletes Up To (SDNV)             |
  +------------+---------------+--+------------+-----------------------+
  | OVC (SDNV) | entry1 (SDNV) | entry2 (SDNV) | ...
  +------------+---------------+---------------+
               Figure 2: SBEB Format for SBEBS of type 2


4.  Superseding Bundle Block Processing

   The following are the processing steps that a bundle node must take
   relative to generation, reception, and processing of SBEB blocks.

4.1.  Bundle Transmission

   When an outbound bundle is created per the parameters of the bundle
   transmission request, this bundle MAY (as influenced by local policy)
   include one SBEB (as defined in this specification).

4.2.  Bundle Forwarding

   The node MUST NOT insert an SBEB into the bundle before forwarding
   it.  The node MUST NOT modify any part of the SBEB.  The node MUST
   NOT remove the SBEB before forwarding it.



Parikh, et al.          Expires October 17, 2011               [Page 10]


Internet-Draft                  DTN SBEB                      April 2011


4.3.  Bundle Reception

   SBEB processing is optional and may be controlled by policy at a
   node.

   If a received bundle is complete (i.e. is not a fragment) and
   includes an SBEB or upon reassembly of fragments into a complete
   bundle that includes an SBEB, and if the receiving node chooses to
   process the SBEB, the node MUST process it as follows.  Upon receipt
   of a bundle with an SBEB, the node searches for other bundles
   awaiting forwarding that match the current bundle SBEB criteria.
   Matching bundles are those that:

   o  do not have the current node as their current custodian,

   o  themselves contain SBEBs with identical SBEB Flags fields as the
      one being processed, and

   o  are members of the same source endpoint as the current bundle, and

   o  are members of the same destination endpoint as the current
      bundle, and

   o  either contain no cookie if the current SBEB does not contain a
      cookie or else contain the same SBEB cookie as the present bundle,
      and

   o  either contain no signature if the current SBEB does not have a
      signature or else contains a valid SBEB Signature.

   Determining which of the matching bundles are retained and which are
   discarded depends on the SBEB type:

4.3.1.  SBEB Type 0

   The value of the SBEB Retention field identifies the number of
   matching bundles, including the current one, that the router should
   retain.  The value N used is that of the most recent (by creation
   timestamp and timestamp sequence number) matching bundle's SBEB
   retention field value.  The most recent N (by creation timestamp and
   creation timestamp sequence number) complete bundles MUST be
   retained.  Other matching bundles that are complete SHOULD be
   discarded.  Matching fragments SHOULD be discarded if their creation
   timestamps and creation timestamp sequence numbers are such that they
   would have been discarded had they been complete at the time of SBEB
   processing.  Matching bundle fragments with (creation timestamp,
   creation timestamp sequence number) values more recent that the
   oldest retained complete bundle MUST be retained.



Parikh, et al.          Expires October 17, 2011               [Page 11]


Internet-Draft                  DTN SBEB                      April 2011


4.3.2.  SBEB Type 1

   The value of the SBEB Retention field identifies a time threshold
   equal to the value of the current bundle's creation timestamp minus
   the SBEB Retention field value.  The value N used is that of the most
   recent (by creating timestamp and timestamp sequence number) matching
   bundle's SBEB retention field value.  Matching bundles (complete or
   fragments) with creation timestamps equal to or after this threshould
   MUST be retained; bundles with creation timestamps before the
   threshold SHOULD be discarded.

4.3.3.  SBEB Type 2

   Bundles are retained based on their SBEB sequence numbers as follows.
   Bundles (complete or fragments) with sequence numbers less than or
   equal to the value of the 'Obsoletes Up To' field SHOULD be
   discarded.  Bundles with SBEB sequence numbers that are in the
   'Obsoletes List' SHOULD be discarded.  All other bundles MUST be
   retained.


5.  Interactions with Bundle Protocol Features

   When the SBEB results in a node deleting a bundle, the node MAY
   generate a bundle deletion status report, as described in the Bundle
   Protocol specification.

   If the node implements sequenced outbound queing and if SBEB
   processing obsoletes a bundle that is queued for transmission, the
   obsoleting bundle MUST take the obsoleted bundle's place in the
   queue.  This prevents the situation where replacing bundles are
   always sent to the tail of the queue, causing a condition where
   bundles never depart from a node.


6.  IANA Considerations

   This document requests that IANA assign a Bundle Block Type Code for
   SBEB blocks from the unassigned pool of the Bundle Bock Type Codes
   DTN Registry [I-D.irtf-dtnrg-bundle-security] section 3.1.

   Note to RFC Editor: once the BP registry is established and a block
   type code has been assigned and its value inserted into Section 3 of
   this document, this section may be removed on publication as an RFC.







Parikh, et al.          Expires October 17, 2011               [Page 12]


Internet-Draft                  DTN SBEB                      April 2011


7.  Security Considerations

   Because the SBEB is not included in the Mutable Canonicalization of
   the bundle, its end-to-end integrity is not ensured by the use of the
   mandatory Payload Integrity Block ciphersuite defined in the BSP.
   Because the SBEB would be included in the Strict Canonicalization of
   the bundle, its integrity would be ensured between one bundle
   protocol agent and its adjacent bundle protocol agent, providing the
   Bundle Authentication Block is used to protect the bundle during that
   single DTN hop.

   SBEBs could be encrypted using the Extension Security Block mechanism
   of the BSP, but 1) the mandatory ciphersuite for ESBs is the
   symmetric RSA-AES-128-EXT ciphersuite which uses symmetric keys that
   would need to be known to large portions of the network if SBEBs were
   to be processed and 2) even without the ESB key, a bad actor with
   access to a single bundle containing an encrypted SBEB could (if it
   guessed the SBEB-containing ESB) copy the encrypted SBEB onto 'bogus'
   bundles and flood the network, crowding out real bundles.  This last
   attack could be prevented by having the source sign SBEBs.


8.  Acknowledgements


9.  References

9.1.  Normative References (Note: the IDs listed here are in the RFC
      editor's queue; this document depends on them; replace with
      appropriate RFC references.)

   [I-D.irtf-dtnrg-bundle-security]
              Symington, S., Farrell, S., Weiss, H., and P. Lovell,
              "Bundle Security Protocol Specification",
              draft-irtf-dtnrg-bundle-security-19 (work in progress),
              March 2011.

   [I-D.irtf-dtnrg-iana-bp-registries]
              Blanchet, M., "Delay-Tolerant Networks (DTN) Bundle
              Protocol IANA Registries",
              draft-irtf-dtnrg-iana-bp-registries-02 (work in progress),
              February 2011.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC4055]  Schaad, J., Kaliski, B., and R. Housley, "Additional
              Algorithms and Identifiers for RSA Cryptography for use in



Parikh, et al.          Expires October 17, 2011               [Page 13]


Internet-Draft                  DTN SBEB                      April 2011


              the Internet X.509 Public Key Infrastructure Certificate
              and Certificate Revocation List (CRL) Profile", RFC 4055,
              June 2005.

   [RFC5050]  Scott, K. and S. Burleigh, "Bundle Protocol
              Specification", RFC 5050, November 2007.

9.2.  Informative References

   [RFC4838]  Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst,
              R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant
              Networking Architecture", RFC 4838, April 2007.


Authors' Addresses

   Salil Parikh
   The MITRE Corporation
   7515 Colshire Drive
   McLean, Virginia  22102
   USA

   Phone: +1 (703) 983-3560
   Email: sparikh@mitre.org


   Susan Symington
   The MITRE Corporation
   7515 Colshire Drive
   McLean, Virginia  22102
   USA

   Phone: +1 (703) 983-7209
   Email: susan@mitre.org


   Keith Scott
   The MITRE Corporation
   7515 Colshire Drive
   McLean, Virginia  22102
   USA

   Phone: +1 (703) 983-6547
   Email: kscott@mitre.org







Parikh, et al.          Expires October 17, 2011               [Page 14]


Internet-Draft                  DTN SBEB                      April 2011


   Robert Durst
   The MITRE Corporation
   7515 Colshire Drive
   McLean, Virginia  22102
   USA

   Phone: +1 (703) 983-7535
   Email: durst@mitre.org


   Richard Edell
   The MITRE Corporation
   7515 Colshire Drive
   McLean, Virginia  22102
   USA

   Phone: +1 (703) 983-7535
   Email: redell@mitre.org

































Parikh, et al.          Expires October 17, 2011               [Page 15]