Handling Issues with Real Time in the Bundle Protocol
Trinity College Dublin
Distributed Systems Group
Department of Computer Science
Trinity College
Dublin
2
Ireland
+353-1-896-2354
stephen.farrell@cs.tcd.ie
Trinity College Dublin
Distributed Systems Group
Department of Computer Science
Trinity College
Dublin
2
Ireland
+353-1-896-2354
alex.mcmahon@cs.tcd.ie
Helsinki University of Technology
Otakaari 5 A
Espoo
FIN 02150
Finland
jo@netlab.hut.fi
IRTF
DTN Research Group
RFC
Request for Comments
I-D
Internet-Draft
DTN
Delay-Tolerant Networking
Disruption-Tolerant Networking
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 clocks.
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 .
[[Editorial and other comments to be resolved are noted in double square
brackets thusly.]]
The Bundle Protocol (BP) specified in RFC 5050 implements the delay tolerant networking
(DTN) architecture specified in RFC 4838 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 not,
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.
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.
]]
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 block.
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.
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 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 CurAltTime block and the
lifetime in the AltTime block, then the bundle MAY be considered to be
expired.
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 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]]
For now, there are none. If an IANA registry is established for BP block
types then entries in that registry would be required.
[[Whoever discusses this. Kevin Fall already dislikes the fact that
this conflates the schemes:-)]]
Key words for use in RFCs to Indicate Requirement Levels
Harvard University
1350 Mass. Ave.
Cambridge
MA
02138
US
+1 617 495 3864
sob@harvard.edu
USC/Information Sciences Institute
4676 Admiralty Way
Marina del Rey
CA
90292
US
+1 310 822 1511
+1 310 823 6714
jkrey@isi.edu
Bundle Protocol Specification
Bundle Security Protocol Specification
The MITRE Corporation
7515 Colshire Drive
McLean
VA
22102
US
+1 703-983-7209
susan@mitre.org
Trinity College Dublin
Distributed Systems Group
Department of Computer Science
Trinity College
Dublin
2
Ireland
+353-1-608-1539
stephen.farrell@cs.tcd.ie
SPARTA, Inc.
7110 Samuel Morse Drive
Columbia
MD
21046
US
+1-443-430-8089
hsw@sparta.com
SPARTA, Inc.
7110 Samuel Morse Drive
Columbia
MD
21046
US
+1-443-430-8052
peter.lovell@sparta.com
Delay-Tolerant Networking Architecture