idnits 2.17.1 draft-farrell-dtnrg-alt-time-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 23, 2009) is 5258 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-19) exists of draft-irtf-dtnrg-bundle-security-12 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DTN Research Group S. Farrell 3 Internet-Draft A. Mc Mahon 4 Intended status: Experimental Trinity College Dublin 5 Expires: May 27, 2010 J. Ott 6 Helsinki University of Technology 7 November 23, 2009 9 Handling Issues with Real Time in the Bundle Protocol 10 draft-farrell-dtnrg-alt-time-00 12 Abstract 14 The Bundle Protocol (RFC 5050) requires the use of real time clocks 15 to handle bundle expiry. This sometimes has some drawbacks; this 16 specification explains some such situations, briefly considers 17 generic ways to ameliorate those, and defines some alternative 18 approaches for handling bundle expiry that do not require real time 19 clocks. 21 Status of this Memo 23 This Internet-Draft is submitted to IETF in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as Internet- 29 Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt. 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html. 42 This Internet-Draft will expire on May 27, 2010. 44 Copyright Notice 46 Copyright (c) 2009 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Issues Addressed . . . . . . . . . . . . . . . . . . . . . . . 5 63 3. AltTime Mechanisms . . . . . . . . . . . . . . . . . . . . . . 6 64 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 65 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 66 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 67 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 68 7.1. Normative References . . . . . . . . . . . . . . . . . . . 12 69 7.2. Informative References . . . . . . . . . . . . . . . . . . 12 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 72 1. Introduction 74 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 75 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 76 document are to be interpreted as described in [RFC2119]. 78 [[Editorial and other comments to be resolved are noted in double 79 square brackets thusly.]] 81 The Bundle Protocol (BP) specified in RFC 5050 [BP] implements the 82 delay tolerant networking (DTN) architecture specified in RFC 4838 83 [DTNARCH] The BP has a creation time field in its primary block. 84 This field, together with a lifetime field is used to determine when 85 a bundle should be expired, after which it is considered safe to 86 delete the bundle. The creation time field contains the wall-clock 87 time at which the bundle was created. Some experiments with the BP 88 have shown that there are nodes for which maintaining an accurate 89 real time clock (RTC) is either hard or impractical. Other 90 experiments have shown that managing expiry using a time window is 91 problematic since it can be hard to know how large a window to use. 92 This specification briefly outlines those problems and defines some 93 new mechanisms for handling bundle expiry that do not require an RTC. 95 It is worth noting that even though the above problems are real, they 96 nonetheless have not prevented real experiments with the BP, which 97 though using an RTC, is actually a very undemanding user. 99 The "model" DTN node assumed here is a device that: 101 may or may not have a battery-backed RTC, in general we may assume 102 not, 104 operates within a reboot cycle, i.e. it reboots occasionally, 106 can keep some notion of (strictly) monotonically increasing sense 107 of time across reboots, i.e. has some form of non-volatile 108 storage, (it is, after all implementing RFC 5050), and, 110 so that the node's sense of time may bear some relation to real 111 time even though the skew may be significant. 113 So we can speak of the device having a "clock," even if that is not 114 an RTC. 116 In such a device if malfunctioning or malicious software overwrites 117 the clock, then the node's bundles may be dropped by other nodes due 118 to the presence of the bad value in the bundle creation time. 120 Clocks may also vary randomly due to users changing timezones or 121 (rarely) manipulating their clocks for other reasons (or having some 122 semi-broken wannabe smart software running that does it for them). 123 If you try to rely on operator-supplied time on your mobile and you 124 will sometimes find it jumping back and forth, e.g., by one hour as 125 happened to one of the authors recently. 127 This specification defines extensions to the BP that can be used even 128 in scenarios where a DTN node's clock is not sufficiently accurate so 129 that other DTN nodes will forward its bundles. 131 [[Future versions of this I-D could specify: 133 some general rules defining how a node is supposed to operate if 134 it has no assured notion of time; 136 maybe some text on how other nodes should deal with this, i.e., 137 accept that they may talk to people who are out of sync; 139 some procedures to assess if someone you are talking to is way off 140 (or you are); we could have an evil-style bit in a handshake 141 indicating that "I may not have a good clue of time"; but I am not 142 so sure what one could imply if this bit was not set; 144 an NTP-like scheme for setting your clock based on values seen in 145 the BP. 147 Depending on the final scope of this draft, we may change the title 148 to "Handling Bundle Expiry without Real Time Clocks" or something 149 else that reflects consensus within the DTNRG. 151 ]] 153 2. Issues Addressed 155 The issues below have been noted in experiments using the BP, and are 156 addressed by this specification. Other issues may well exist, but 157 are not [[yet]] tackled here. 159 There are some DTN nodes that have no RTC. [[need a citation if 160 that's not just theory]] In such a case, the node cannot determine a 161 good value to place in the creation time field of the bundle primary 162 block. 164 Similar to the above, but much more common, is the case where a 165 node's RTC has never been properly set, (e.g. the first time the node 166 is powered on), or where the RTC has a bad time, due to one form of 167 error or another. This can happen due to software bugs (scribbling 168 on a memory mapped RTC) or if the node's power is "dirty," 169 fluctuating voltages can corrupt an RTC. 171 We expect that both issues above are much more common at the extreme 172 periphery of networks, since nodes that are reasonably well 173 connected, even for short periods, can easily synchronise their 174 clocks to a level sufficient for the BP. 176 Separately from the above, the requirement that bundles expire a 177 fixed number of seconds after their creation time has also 178 occasionally proven problematic. In this case, the issue is how to 179 select a sensible value for a particular bundle. In some DTNs that 180 can be a difficult task, leading either to bundles that consume 181 storage for too long (e.g. if multi-copy routing is in use), or 182 bundles that expire for no good reason, sometimes just before they 183 would otherwise have been successfully delivered. 185 3. AltTime Mechanisms 187 We define two new mechanisms for handling bundle expiry. The first 188 uses a hop count and the second, called the deferred window scheme, 189 uses a time window where the clock only starts ticking after the 190 bundle has reached some node that does know the wall-clock time. 192 In both cases, since we do not want to modify the primary block (to 193 retain interoperability), we define some specific time values that 194 act as indicators that one or other of the new schemes is intended to 195 be used. Note however, that a BP agent that implements RFC 5050 196 strictly might drop all such bundles, if it considers that the time 197 window defined in the primary block is too large, so the use of these 198 new schemes requires some co-ordination. 200 Both of the new schemes require that some bytes in the bundle are 201 changed en-route. In order to allow for data-integrity we therefore 202 use two new extension blocks, one that is fixed when the bundle is 203 created, (the AltTime block) and one that may be modified en-route, 204 (the CurAltTime block). 206 The AltTime block specifies which scheme(s) are to be used to expire 207 the bundle and contains associated parameters, i.e. the max hop count 208 and/or the window size. The CurAltTime block can contain the hops- 209 remaining value and/or the window start time value (and an EID for 210 the source of time used). 212 [[This is just a sketch to be filled in after the RG discusses things 213 for a bit. (Not a lot...a bit:-)]] 215 An AltTime block has a domination rule, specifying which expiry 216 schemes the sender wishes be applied to this bundle. There are three 217 schemes (the one from RFC 5050 and the two defined here). This field 218 is an SDNV containing a bit mask with a one value meaning that the 219 scheme applies. In the case where more than one scheme applies, then 220 the bundle MAY be expired (and hence possibly deleted) when any of 221 the schemes indicates that the bundle has expired. 223 [[The domination rule could be more complex, e.g. specifying other 224 combinatorics, or could be simpler, e.g. only allowing one scheme to 225 apply. We're not sure which is better.]] 227 If the domination rule indicates that the RFC 5050 expiry scheme does 228 not apply then the primary block MUST contain special values [[TBD]] 229 indicating that the bundle creation timestamp and lifetime fields do 230 not contain real values. 232 [[Are there any values that'd be easier or harder to handle in 233 existing RFC 5050 implementations? We suspect not, in which case 234 just some creation time sufficiently far in the past and some 235 sufficiently long lifetime should be ok.]] 237 If the domination rule indicates that the hop count scheme applies 238 then the AtlTime extension block MUST contain a hop count value which 239 is a non-zero SDNV. 241 [[A fixed width field here could be ok. Zero could mean infinity, 242 but would we want that?]] 244 If the domination rule indicates that the deferred window scheme 245 applies, then the AltTime block MUST contain a window size field that 246 contains the number of seconds (as an SDNV) for which the bundle 247 should be considered non-expired, after some RTC-capable node has 248 added a window start time to the CurAltTime block. 250 [[Is seconds the right granularity?]] 252 Nodes that implement this specification MUST ensure that the 253 CurAltTime block is present (it may have to be added by the first 254 such node) and contains values that reflect the correct operation of 255 the scheme(s) that apply. 257 For the hop count scheme this means ensuring that the CurAltTime 258 block contains the hops-remaining count, which is the number of hops 259 that remain before this bundle will be considered to be expired. 261 When the hop-count scheme is being enforced and the bundle has one 262 hop remaining (hops-remaining in CurAltTime has the value one) then 263 the bundle MAY be considered expired if it is not delivered directly 264 to the destination EID. 266 [[Is the above correct?]] 268 For the deferred window scheme, the first node implementing this 269 specification that considers that it has a good RTC MUST add the 270 current value at the time of arrival of the bundle to the window 271 start time field. 273 [[Any issue here with when to start the window? Could be the time of 274 arrival, time of departure or something in between.]] 276 Once a window start time value is present in the CurAltTime block, 277 then it MUST NOT be changed by subsequent nodes. 279 When the deferred window scheme is in operation, once the current 280 time is later than the sum of the window start time from the 281 CurAltTime block and the lifetime in the AltTime block, then the 282 bundle MAY be considered to be expired. 284 4. Security Considerations 286 These schemes could allow a bad actor attempting a DoS attack to more 287 easily consume resources in a DTN, for example, if all paths in a 288 particular network under attack were less than N hops, then setting a 289 hop count of N+1 would maximise the damage done by DoS bundles in an 290 efficient manner (for the bad actor). 292 Since DoS-mitigation in DTNs is still a research area, one can only 293 recommend requiring authentication of bundles [BPsec] as a way of at 294 least making the bad actor accountable. 296 The CurAltTime block MAY be authenticated, and not authenticating 297 that allows any node to easily cause another node to incorrectly 298 expire a bundle. 300 [[Do we have a suitable ESB ciphersuite in the BSP for this?]] 302 If a node adds a window start time with a bad value (e.g. with the 303 time significantly in the past), then that might act as an 304 inadvertent DoS. 306 [[More TBD]] 308 5. IANA Considerations 310 For now, there are none. If an IANA registry is established for BP 311 block types then entries in that registry would be required. 313 6. Acknowledgements 315 [[Whoever discusses this. Kevin Fall already dislikes the fact that 316 this conflates the schemes:-)]] 318 7. References 320 7.1. Normative References 322 [BP] Scott, K. and S. Burleigh, "Bundle Protocol 323 Specification", RFC 5050 , April 2007. 325 [BPsec] Symington, S., Farrell, S., Weiss, H., and P. Lovell, 326 "Bundle Security Protocol Specification", 327 draft-irtf-dtnrg-bundle-security-12.txt, work-in-progress, 328 November 2009. 330 [RFC2119] Bradner, S. and J. Reynolds, "Key words for use in RFCs to 331 Indicate Requirement Levels", RFC 2119, October 1997. 333 7.2. Informative References 335 [DTNARCH] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst, 336 R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant 337 Networking Architecture", RFC 4838 , April 2007. 339 Authors' Addresses 341 Stephen Farrell 342 Trinity College Dublin 343 Distributed Systems Group 344 Department of Computer Science 345 Trinity College 346 Dublin 2 347 Ireland 349 Phone: +353-1-896-2354 350 Email: stephen.farrell@cs.tcd.ie 352 Alex Mc Mahon 353 Trinity College Dublin 354 Distributed Systems Group 355 Department of Computer Science 356 Trinity College 357 Dublin 2 358 Ireland 360 Phone: +353-1-896-2354 361 Email: alex.mcmahon@cs.tcd.ie 363 Joerg Ott 364 Helsinki University of Technology 365 Otakaari 5 A 366 Espoo FIN 02150 367 Finland 369 Email: jo@netlab.hut.fi