[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]

Versions: 00

DTN Research Group                                            S. Farrell
Internet-Draft                                               A. Mc Mahon
Intended status: Experimental                     Trinity College Dublin
Expires: May 27, 2010                                             J. Ott
                                       Helsinki University of Technology
                                                       November 23, 2009

         Handling Issues with Real Time in the Bundle Protocol


   The Bundle Protocol (RFC 5050) requires the use of real time clocks
   to handle bundle expiry.  This sometimes has some drawbacks; this
   specification explains some such situations, briefly considers
   generic ways to ameliorate those, and defines some alternative
   approaches for handling bundle expiry that do not require real time

Status of this Memo

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

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-

   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 May 27, 2010.

Copyright Notice

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

Farrell, et al.           Expires May 27, 2010                  [Page 1]

Internet-Draft           Handling BP RTC Issues            November 2009

   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 BSD License.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Issues Addressed . . . . . . . . . . . . . . . . . . . . . . .  5
   3.  AltTime Mechanisms . . . . . . . . . . . . . . . . . . . . . .  6
   4.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 10
   6.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
     7.1.  Normative References . . . . . . . . . . . . . . . . . . . 12
     7.2.  Informative References . . . . . . . . . . . . . . . . . . 12
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13

Farrell, et al.           Expires May 27, 2010                  [Page 2]

Internet-Draft           Handling BP RTC Issues            November 2009

1.  Introduction

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in [RFC2119].

   [[Editorial and other comments to be resolved are noted in double
   square brackets thusly.]]

   The Bundle Protocol (BP) specified in RFC 5050 [BP] implements the
   delay tolerant networking (DTN) architecture specified in RFC 4838
   [DTNARCH] The BP has a creation time field in its primary block.
   This field, together with a lifetime field is used to determine when
   a bundle should be expired, after which it is considered safe to
   delete the bundle.  The creation time field contains the wall-clock
   time at which the bundle was created.  Some experiments with the BP
   have shown that there are nodes for which maintaining an accurate
   real time clock (RTC) is either hard or impractical.  Other
   experiments have shown that managing expiry using a time window is
   problematic since it can be hard to know how large a window to use.
   This specification briefly outlines those problems and defines some
   new mechanisms for handling bundle expiry that do not require an RTC.

   It is worth noting that even though the above problems are real, they
   nonetheless have not prevented real experiments with the BP, which
   though using an RTC, is actually a very undemanding user.

   The "model" DTN node assumed here is a device that:

      may or may not have a battery-backed RTC, in general we may assume

      operates within a reboot cycle, i.e. it reboots occasionally,

      can keep some notion of (strictly) monotonically increasing sense
      of time across reboots, i.e. has some form of non-volatile
      storage, (it is, after all implementing RFC 5050), and,

      so that the node's sense of time may bear some relation to real
      time even though the skew may be significant.

   So we can speak of the device having a "clock," even if that is not
   an RTC.

   In such a device if malfunctioning or malicious software overwrites
   the clock, then the node's bundles may be dropped by other nodes due
   to the presence of the bad value in the bundle creation time.

Farrell, et al.           Expires May 27, 2010                  [Page 3]

Internet-Draft           Handling BP RTC Issues            November 2009

   Clocks may also vary randomly due to users changing timezones or
   (rarely) manipulating their clocks for other reasons (or having some
   semi-broken wannabe smart software running that does it for them).
   If you try to rely on operator-supplied time on your mobile and you
   will sometimes find it jumping back and forth, e.g., by one hour as
   happened to one of the authors recently.

   This specification defines extensions to the BP that can be used even
   in scenarios where a DTN node's clock is not sufficiently accurate so
   that other DTN nodes will forward its bundles.

   [[Future versions of this I-D could specify:

      some general rules defining how a node is supposed to operate if
      it has no assured notion of time;

      maybe some text on how other nodes should deal with this, i.e.,
      accept that they may talk to people who are out of sync;

      some procedures to assess if someone you are talking to is way off
      (or you are); we could have an evil-style bit in a handshake
      indicating that "I may not have a good clue of time"; but I am not
      so sure what one could imply if this bit was not set;

      an NTP-like scheme for setting your clock based on values seen in
      the BP.

   Depending on the final scope of this draft, we may change the title
   to "Handling Bundle Expiry without Real Time Clocks" or something
   else that reflects consensus within the DTNRG.


Farrell, et al.           Expires May 27, 2010                  [Page 4]

Internet-Draft           Handling BP RTC Issues            November 2009

2.  Issues Addressed

   The issues below have been noted in experiments using the BP, and are
   addressed by this specification.  Other issues may well exist, but
   are not [[yet]] tackled here.

   There are some DTN nodes that have no RTC. [[need a citation if
   that's not just theory]] In such a case, the node cannot determine a
   good value to place in the creation time field of the bundle primary

   Similar to the above, but much more common, is the case where a
   node's RTC has never been properly set, (e.g. the first time the node
   is powered on), or where the RTC has a bad time, due to one form of
   error or another.  This can happen due to software bugs (scribbling
   on a memory mapped RTC) or if the node's power is "dirty,"
   fluctuating voltages can corrupt an RTC.

   We expect that both issues above are much more common at the extreme
   periphery of networks, since nodes that are reasonably well
   connected, even for short periods, can easily synchronise their
   clocks to a level sufficient for the BP.

   Separately from the above, the requirement that bundles expire a
   fixed number of seconds after their creation time has also
   occasionally proven problematic.  In this case, the issue is how to
   select a sensible value for a particular bundle.  In some DTNs that
   can be a difficult task, leading either to bundles that consume
   storage for too long (e.g. if multi-copy routing is in use), or
   bundles that expire for no good reason, sometimes just before they
   would otherwise have been successfully delivered.

Farrell, et al.           Expires May 27, 2010                  [Page 5]

Internet-Draft           Handling BP RTC Issues            November 2009

3.  AltTime Mechanisms

   We define two new mechanisms for handling bundle expiry.  The first
   uses a hop count and the second, called the deferred window scheme,
   uses a time window where the clock only starts ticking after the
   bundle has reached some node that does know the wall-clock time.

   In both cases, since we do not want to modify the primary block (to
   retain interoperability), we define some specific time values that
   act as indicators that one or other of the new schemes is intended to
   be used.  Note however, that a BP agent that implements RFC 5050
   strictly might drop all such bundles, if it considers that the time
   window defined in the primary block is too large, so the use of these
   new schemes requires some co-ordination.

   Both of the new schemes require that some bytes in the bundle are
   changed en-route.  In order to allow for data-integrity we therefore
   use two new extension blocks, one that is fixed when the bundle is
   created, (the AltTime block) and one that may be modified en-route,
   (the CurAltTime block).

   The AltTime block specifies which scheme(s) are to be used to expire
   the bundle and contains associated parameters, i.e. the max hop count
   and/or the window size.  The CurAltTime block can contain the hops-
   remaining value and/or the window start time value (and an EID for
   the source of time used).

   [[This is just a sketch to be filled in after the RG discusses things
   for a bit.  (Not a lot...a bit:-)]]

   An AltTime block has a domination rule, specifying which expiry
   schemes the sender wishes be applied to this bundle.  There are three
   schemes (the one from RFC 5050 and the two defined here).  This field
   is an SDNV containing a bit mask with a one value meaning that the
   scheme applies.  In the case where more than one scheme applies, then
   the bundle MAY be expired (and hence possibly deleted) when any of
   the schemes indicates that the bundle has expired.

   [[The domination rule could be more complex, e.g. specifying other
   combinatorics, or could be simpler, e.g. only allowing one scheme to
   apply.  We're not sure which is better.]]

   If the domination rule indicates that the RFC 5050 expiry scheme does
   not apply then the primary block MUST contain special values [[TBD]]
   indicating that the bundle creation timestamp and lifetime fields do
   not contain real values.

   [[Are there any values that'd be easier or harder to handle in

Farrell, et al.           Expires May 27, 2010                  [Page 6]

Internet-Draft           Handling BP RTC Issues            November 2009

   existing RFC 5050 implementations?  We suspect not, in which case
   just some creation time sufficiently far in the past and some
   sufficiently long lifetime should be ok.]]

   If the domination rule indicates that the hop count scheme applies
   then the AtlTime extension block MUST contain a hop count value which
   is a non-zero SDNV.

   [[A fixed width field here could be ok.  Zero could mean infinity,
   but would we want that?]]

   If the domination rule indicates that the deferred window scheme
   applies, then the AltTime block MUST contain a window size field that
   contains the number of seconds (as an SDNV) for which the bundle
   should be considered non-expired, after some RTC-capable node has
   added a window start time to the CurAltTime block.

   [[Is seconds the right granularity?]]

   Nodes that implement this specification MUST ensure that the
   CurAltTime block is present (it may have to be added by the first
   such node) and contains values that reflect the correct operation of
   the scheme(s) that apply.

   For the hop count scheme this means ensuring that the CurAltTime
   block contains the hops-remaining count, which is the number of hops
   that remain before this bundle will be considered to be expired.

   When the hop-count scheme is being enforced and the bundle has one
   hop remaining (hops-remaining in CurAltTime has the value one) then
   the bundle MAY be considered expired if it is not delivered directly
   to the destination EID.

   [[Is the above correct?]]

   For the deferred window scheme, the first node implementing this
   specification that considers that it has a good RTC MUST add the
   current value at the time of arrival of the bundle to the window
   start time field.

   [[Any issue here with when to start the window?  Could be the time of
   arrival, time of departure or something in between.]]

   Once a window start time value is present in the CurAltTime block,
   then it MUST NOT be changed by subsequent nodes.

   When the deferred window scheme is in operation, once the current
   time is later than the sum of the window start time from the

Farrell, et al.           Expires May 27, 2010                  [Page 7]

Internet-Draft           Handling BP RTC Issues            November 2009

   CurAltTime block and the lifetime in the AltTime block, then the
   bundle MAY be considered to be expired.

Farrell, et al.           Expires May 27, 2010                  [Page 8]

Internet-Draft           Handling BP RTC Issues            November 2009

4.  Security Considerations

   These schemes could allow a bad actor attempting a DoS attack to more
   easily consume resources in a DTN, for example, if all paths in a
   particular network under attack were less than N hops, then setting a
   hop count of N+1 would maximise the damage done by DoS bundles in an
   efficient manner (for the bad actor).

   Since DoS-mitigation in DTNs is still a research area, one can only
   recommend requiring authentication of bundles [BPsec] as a way of at
   least making the bad actor accountable.

   The CurAltTime block MAY be authenticated, and not authenticating
   that allows any node to easily cause another node to incorrectly
   expire a bundle.

   [[Do we have a suitable ESB ciphersuite in the BSP for this?]]

   If a node adds a window start time with a bad value (e.g. with the
   time significantly in the past), then that might act as an
   inadvertent DoS.

   [[More TBD]]

Farrell, et al.           Expires May 27, 2010                  [Page 9]

Internet-Draft           Handling BP RTC Issues            November 2009

5.  IANA Considerations

   For now, there are none.  If an IANA registry is established for BP
   block types then entries in that registry would be required.

Farrell, et al.           Expires May 27, 2010                 [Page 10]

Internet-Draft           Handling BP RTC Issues            November 2009

6.  Acknowledgements

   [[Whoever discusses this.  Kevin Fall already dislikes the fact that
   this conflates the schemes:-)]]

Farrell, et al.           Expires May 27, 2010                 [Page 11]

Internet-Draft           Handling BP RTC Issues            November 2009

7.  References

7.1.  Normative References

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

   [BPsec]    Symington, S., Farrell, S., Weiss, H., and P. Lovell,
              "Bundle Security Protocol Specification",
              draft-irtf-dtnrg-bundle-security-12.txt, work-in-progress,
              November 2009.

   [RFC2119]  Bradner, S. and J. Reynolds, "Key words for use in RFCs to
              Indicate Requirement Levels", RFC 2119, October 1997.

7.2.  Informative References

   [DTNARCH]  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.

Farrell, et al.           Expires May 27, 2010                 [Page 12]

Internet-Draft           Handling BP RTC Issues            November 2009

Authors' Addresses

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

   Phone: +353-1-896-2354
   Email: stephen.farrell@cs.tcd.ie

   Alex Mc Mahon
   Trinity College Dublin
   Distributed Systems Group
   Department of Computer Science
   Trinity College
   Dublin  2

   Phone: +353-1-896-2354
   Email: alex.mcmahon@cs.tcd.ie

   Joerg Ott
   Helsinki University of Technology
   Otakaari 5 A
   Espoo  FIN  02150

   Email: jo@netlab.hut.fi

Farrell, et al.           Expires May 27, 2010                 [Page 13]

Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/