|
1 |
|
2 |
|
3 |
|
4 DTN Research Group S. Symington |
|
5 Internet-Draft The MITRE Corporation |
|
6 Expires: April 16, 2007 October 13, 2006 |
|
7 |
|
8 |
|
9 Delay-Tolerant Networking Retransmission Block |
|
10 draft-symington-dtnrg-bundle-retrans-block-00 |
|
11 |
|
12 Status of this Memo |
|
13 |
|
14 By submitting this Internet-Draft, each author represents that any |
|
15 applicable patent or other IPR claims of which he or she is aware |
|
16 have been or will be disclosed, and any of which he or she becomes |
|
17 aware will be disclosed, in accordance with Section 6 of BCP 79. |
|
18 |
|
19 Internet-Drafts are working documents of the Internet Engineering |
|
20 Task Force (IETF), its areas, and its working groups. Note that |
|
21 other groups may also distribute working documents as Internet- |
|
22 Drafts. |
|
23 |
|
24 Internet-Drafts are draft documents valid for a maximum of six months |
|
25 and may be updated, replaced, or obsoleted by other documents at any |
|
26 time. It is inappropriate to use Internet-Drafts as reference |
|
27 material or to cite them other than as "work in progress." |
|
28 |
|
29 The list of current Internet-Drafts can be accessed at |
|
30 http://www.ietf.org/ietf/1id-abstracts.txt. |
|
31 |
|
32 The list of Internet-Draft Shadow Directories can be accessed at |
|
33 http://www.ietf.org/shadow.html. |
|
34 |
|
35 This Internet-Draft will expire on April 16, 2007. |
|
36 |
|
37 Copyright Notice |
|
38 |
|
39 Copyright (C) The Internet Society (2006). |
|
40 |
|
41 Abstract |
|
42 |
|
43 This document defines an optional extension block, called a |
|
44 Retransmission Block, that may be used with the Bundle Protocol [2] |
|
45 within the context of a Delay-Tolerant Network architecture [4]. The |
|
46 Retransmission Block (RB) is designed to be inserted by a custodian |
|
47 when re-forwarding a bundle, so as to mark the bundle as a legitimate |
|
48 custody-based retransmission rather than an unauthorized bundle |
|
49 duplicate. By providing a way for nodes that receive the re- |
|
50 forwarded bundle to distinguish it from an unauthorized duplicate, |
|
51 the RB enables those nodes whose local security policies do not |
|
52 |
|
53 |
|
54 |
|
55 Symington Expires April 16, 2007 [Page 1] |
|
56 |
|
57 Internet-Draft DTN Retransmission Block October 2006 |
|
58 |
|
59 |
|
60 permit them to forward replayed bundles to detect and delete |
|
61 unauthorized bundle replays but forward authorized custody-based |
|
62 bundle retransmissions. This document defines the format and |
|
63 processing of this new Retransmission Block. |
|
64 |
|
65 |
|
66 Table of Contents |
|
67 |
|
68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 |
|
69 2. Background and Motivation . . . . . . . . . . . . . . . . . . 4 |
|
70 2.1. Replay Detection as Currently Provided in the Bundle |
|
71 Protocol . . . . . . . . . . . . . . . . . . . . . . . . . 4 |
|
72 2.2. The Denial-of-Service Threat . . . . . . . . . . . . . . . 4 |
|
73 2.3. Detecting Duplicates is Largely a Matter of Local |
|
74 Policy . . . . . . . . . . . . . . . . . . . . . . . . . . 5 |
|
75 2.4. Not All Duplicates are Bad . . . . . . . . . . . . . . . . 5 |
|
76 2.5. A Mechanism for Distinguishing Legitimate Replays from |
|
77 Illegitimate Replays is Required . . . . . . . . . . . . . 6 |
|
78 3. The Treatment of Replays Must Be a Defined Aspect of |
|
79 Security Policy . . . . . . . . . . . . . . . . . . . . . . . 7 |
|
80 4. Replays versus Loops . . . . . . . . . . . . . . . . . . . . . 8 |
|
81 5. Ramifications of Allowing Support for the Retransmission |
|
82 Block to be Optional . . . . . . . . . . . . . . . . . . . . . 10 |
|
83 6. Retransmission Block Format . . . . . . . . . . . . . . . . . 12 |
|
84 7. Retransmission Block Processing . . . . . . . . . . . . . . . 13 |
|
85 7.1. Bundle Reception . . . . . . . . . . . . . . . . . . . . . 13 |
|
86 7.2. Replay Detection and Suppression . . . . . . . . . . . . . 13 |
|
87 7.3. Keeping Track of Bundles Received . . . . . . . . . . . . 13 |
|
88 7.4. Bundle Forwarding . . . . . . . . . . . . . . . . . . . . 14 |
|
89 7.5. Custodial Retransmission . . . . . . . . . . . . . . . . . 14 |
|
90 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 |
|
91 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 |
|
92 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 |
|
93 10.1. Normative References . . . . . . . . . . . . . . . . . . . 17 |
|
94 10.2. Informative References . . . . . . . . . . . . . . . . . . 17 |
|
95 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 18 |
|
96 Intellectual Property and Copyright Statements . . . . . . . . . . 19 |
|
97 |
|
98 |
|
99 |
|
100 |
|
101 |
|
102 |
|
103 |
|
104 |
|
105 |
|
106 |
|
107 |
|
108 |
|
109 |
|
110 |
|
111 Symington Expires April 16, 2007 [Page 2] |
|
112 |
|
113 Internet-Draft DTN Retransmission Block October 2006 |
|
114 |
|
115 |
|
116 1. Introduction |
|
117 |
|
118 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", |
|
119 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this |
|
120 document are to be interpreted as described in RFC 2119 [1]. |
|
121 |
|
122 The DTN bundle protocol [2] defines the bundle as its protocol data |
|
123 unit. A bundle consists of a primary bundle block, which is defined |
|
124 in the Bundle Protocol, followed by at least one other type of bundle |
|
125 block. The Bundle Protocol defines a single other type of bundle |
|
126 block, called a Bundle Payload block. This document defines an |
|
127 additional, optional, bundle block called a Retransmission Block. |
|
128 This block is designed to be inserted by a custodian node into a |
|
129 bundle that the custodian is re-forwarding in response to a custody |
|
130 transfer failure. The intent of this Retransmission Block is to mark |
|
131 a re-forwarded bundle as such, so that when the bundle is received at |
|
132 downstream nodes that detect it to be a duplicate of a previously- |
|
133 received bundle, those nodes can understand it to be a legitimate |
|
134 retransmission that should be preserved rather than an unauthorized |
|
135 replay that may (according to local policy) be deleted. |
|
136 |
|
137 The capabilities described in this document are OPTIONAL for |
|
138 deployment with the Bundle Protocol. Bundle Protocol implementations |
|
139 claiming to support Retransmission Blocks MUST be capable of: |
|
140 |
|
141 -Generating a Retransmission Block and inserting it into a bundle, |
|
142 |
|
143 -Logging the relevant fields of all bundles received until those |
|
144 bundles expire, |
|
145 |
|
146 -Receiving bundles containing a Retransmission Block and using the |
|
147 information contained in this Retransmission Block (in conjunction |
|
148 with the information from logged bundles) to make replay |
|
149 suppression decisions, |
|
150 |
|
151 -Deleting a Retransmission Block from a bundle |
|
152 |
|
153 as defined in this document. |
|
154 |
|
155 |
|
156 |
|
157 |
|
158 |
|
159 |
|
160 |
|
161 |
|
162 |
|
163 |
|
164 |
|
165 |
|
166 |
|
167 Symington Expires April 16, 2007 [Page 3] |
|
168 |
|
169 Internet-Draft DTN Retransmission Block October 2006 |
|
170 |
|
171 |
|
172 2. Background and Motivation |
|
173 |
|
174 2.1. Replay Detection as Currently Provided in the Bundle Protocol |
|
175 |
|
176 The Bundle Security Protocol defines an "at-most-once-delivery" |
|
177 registration option that, when used by a node that is registering in |
|
178 a particular endpoint, indicates that exactly one copy of each bundle |
|
179 destined for that endpoint that is received at that node shall be |
|
180 delivered at that node. If the at-most-once-delivery option is used |
|
181 with a given endpoint ID registration, the registering node is |
|
182 required to check all bundles that it receives with that destination |
|
183 endpoint ID to determine if the bundle has already been delivered at |
|
184 that node. If it has, the bundle must be discarded. This is a |
|
185 limited form of replay detection because it requires a node to keep |
|
186 track of only the bundles that have been delivered at that node; it |
|
187 does not apply to bundles that the node receives for forwarding. It |
|
188 is designed to protect applications from receiving duplicate bundles, |
|
189 but it is not intended to protect the network from denial of service |
|
190 attacks that can result from replayed bundles. |
|
191 |
|
192 2.2. The Denial-of-Service Threat |
|
193 |
|
194 As discussed in the DTN Security Overview [5], due to the resource- |
|
195 scarcity that characterizes DTNs, unauthorized access and use of DTNs |
|
196 is a serious concern. DTNs, by definition, may suffer from network |
|
197 disconnections, limited bandwidth, limited battery power, and other |
|
198 challenges, and the transmission of unauthorized bundles wastes |
|
199 precious network resources. The DTN security protocol already |
|
200 includes some mechanisms to protect against unauthorized use of the |
|
201 DTN. For example, an attacker wanting to launch a denial of service |
|
202 attack on a DTN by injecting a bogus bundle into the network or by |
|
203 copying a legitimate bundle from the network, modifying it, and |
|
204 injecting this modified copy into the network can be thwarted by the |
|
205 use of the Bundle Authentication Block (BAB). Use of the BAB enables |
|
206 each node that receives a bundle to check the validity of the |
|
207 security result in the BAB to determine whether the bundle is |
|
208 legitimate or not. Bogus or modified bundles will be detected at the |
|
209 very first node at which they are received, and thus will be deleted |
|
210 from the network at the earliest possible opportunity. Replayed |
|
211 bundles, on the other hand, can not be detected by checking the |
|
212 validity of the bundle's BAB because the value of the BAB will be |
|
213 correct. Replayed bundles will only be deleted from the network when |
|
214 they expire. Given the high latency typical in some DTNs, bundles |
|
215 may be valid for days or weeks. For those networks in which waiting |
|
216 for replayed bundles to expire is not an adequate form of protection |
|
217 against the unauthorized use of the network posed by replayed |
|
218 bundles, additional measures will be required to actively detect and |
|
219 delete replayed bundles. |
|
220 |
|
221 |
|
222 |
|
223 Symington Expires April 16, 2007 [Page 4] |
|
224 |
|
225 Internet-Draft DTN Retransmission Block October 2006 |
|
226 |
|
227 |
|
228 2.3. Detecting Duplicates is Largely a Matter of Local Policy |
|
229 |
|
230 Detecting duplicate bundles at any given node is largely a matter of |
|
231 local security policy and enforcement. A node could be configured to |
|
232 maintain a record of every bundle it receives, check every new bundle |
|
233 received against the list of bundles that have already been received, |
|
234 and delete any duplicates. A concern with this approach is the |
|
235 potentially large amount of state that could accumulate and use up |
|
236 storage at any given node. This state can be minimized by only |
|
237 storing those parts of the bundle needed to identify it uniquely |
|
238 (source EID, creation timestamp, and fragment offset-if present), and |
|
239 keeping this information only until the time that the bundle expires |
|
240 (creation timestamp added to lifetime). However, because bundles may |
|
241 be valid for long periods in a DTN, the amount of storage that may be |
|
242 required could still be substantial enough to pose a burden on the |
|
243 node. If the amount of information that needs to be stored exceeds |
|
244 the available storage, some duplicates could go undetected. |
|
245 |
|
246 2.4. Not All Duplicates are Bad |
|
247 |
|
248 Although detecting duplicates is a fairly straightforward local |
|
249 matter, detecting which of these duplicates are unauthorized and |
|
250 should therefore be deleted is more involved, and has protocol |
|
251 implications. Simply being able to detect and delete duplicate |
|
252 bundles is not sufficient in a DTN, because not all duplicate bundles |
|
253 are unwanted replays. As discussed in the security overview, there |
|
254 are instances within DTNs in which replayed messages are desirable |
|
255 and in fact necessary. As a first example, in some instances, the |
|
256 optimal path to a destination will involve routing loops, such that |
|
257 the nodes on this loop will receive the same bundle for forwarding |
|
258 more than once. As a second example, the DTN protocol includes a |
|
259 custody-based retransmission mechanism that may result in a custodian |
|
260 re-forwarding a bundle when the bundle's retransmission timer expires |
|
261 or when the custodian receives a "failed" custody signal for the |
|
262 bundle. These re-forwarded bundles are legitimate replays that are |
|
263 required in order to enable custody transfer to operate correctly. |
|
264 |
|
265 On the other hand, there are also illegitimate replays. Some |
|
266 illegitimate replays are introduced unintentionally by the routing |
|
267 protocols; these replays are not needed in order to deliver the |
|
268 bundle, but rather are the result of routing or forwarding mistakes. |
|
269 Other illegitimate replays are more pernicious, being introduced |
|
270 intentionally by malicious intruders. Ideally, a node would be able |
|
271 to distinguish illegitimate replays from legitimate ones so that it |
|
272 can know which duplicate bundles to delete and which to forward. |
|
273 |
|
274 |
|
275 |
|
276 |
|
277 |
|
278 |
|
279 Symington Expires April 16, 2007 [Page 5] |
|
280 |
|
281 Internet-Draft DTN Retransmission Block October 2006 |
|
282 |
|
283 |
|
284 2.5. A Mechanism for Distinguishing Legitimate Replays from |
|
285 Illegitimate Replays is Required |
|
286 |
|
287 When routing loops or custody transfer is being used in a DTN, replay |
|
288 detection cannot be handled merely as a matter of locally detecting |
|
289 and deleting duplicate bundles because there is no way for a local |
|
290 node to independently distinguish legitimate replays from |
|
291 illegitimate replays. Instead, a protocol mechanism is required to |
|
292 assist the local duplicate suppression mechanism in making this |
|
293 distinction. |
|
294 |
|
295 As discussed in the DTN Security Overview, to accommodate intentional |
|
296 replays that are part of the routing protocol but suppress replays |
|
297 that are the result of routing protocol errors, replay detection |
|
298 schemes may need to be specified and enforced as part of the bundle |
|
299 routing algorithm used. |
|
300 |
|
301 If the security requirements of a network are such that replays must |
|
302 not be allowed, then that network must either not use a routing |
|
303 protocol that allows routing loops or, if it does use a routing |
|
304 protocol that allows loops, this routing protocol must also include a |
|
305 mechanism for detecting and suppressing unintentional routing loops. |
|
306 The details of such a mechanism would most likely be specific to the |
|
307 routing protocol and as such they are not addressed in this document. |
|
308 |
|
309 In addition, if the security requirements of a network are such that |
|
310 replays must not be allowed, then that network must either not use |
|
311 custody transfer of bundles or, if it does use custody transfer of |
|
312 bundles, it must also include a mechanism for detecting and |
|
313 suppressing duplicate bundles that are not the result of custodial |
|
314 retransmissions. This paper defines the DTN Retransmission Block as |
|
315 an optional Bundle Protocol block that can be used to mark bundles |
|
316 that are the result of custodial retransmission, thereby enabling |
|
317 these bundles to be distinguished from both unintentional replays and |
|
318 replays that are the result of intentional, malicious attacks. |
|
319 |
|
320 |
|
321 |
|
322 |
|
323 |
|
324 |
|
325 |
|
326 |
|
327 |
|
328 |
|
329 |
|
330 |
|
331 |
|
332 |
|
333 |
|
334 |
|
335 Symington Expires April 16, 2007 [Page 6] |
|
336 |
|
337 Internet-Draft DTN Retransmission Block October 2006 |
|
338 |
|
339 |
|
340 3. The Treatment of Replays Must Be a Defined Aspect of Security Policy |
|
341 |
|
342 An additional component of a DTN node's security policy should be |
|
343 whether or not replays are allowed to be forwarded by that node. If |
|
344 replay forwarding is not allowed, the node must implement mechanisms |
|
345 to detect and delete replays. In the context of a node that does not |
|
346 implement the optional Retransmission Block defined in this document |
|
347 but at which replay forwarding is not allowed, all duplicate bundles |
|
348 must be deleted, where duplicate bundles are defined as bundles that |
|
349 have the same source EID, time stamp, and fragment offset (if |
|
350 present). In the context of a node that does implement the optional |
|
351 protocol extensions defined in this document, unauthorized replays |
|
352 can be distinguished from legitimate replays such that only |
|
353 unauthorized replays must be deleted. The processing steps with |
|
354 regard to replay protection at an arbitrary node are defined as |
|
355 follows: |
|
356 |
|
357 If replays are allowed, then no additional requirements are levied |
|
358 on that node. |
|
359 |
|
360 If replays are not allowed and if the node supports the optional |
|
361 Retransmission Block defined in this document, then the node MUST |
|
362 delete all duplicate bundles that it receives that can not be |
|
363 legitimate custodial retransmissions. A received duplicate bundle |
|
364 can not be a legitimate custodial retransmission if it: |
|
365 |
|
366 -Has the same custodian EID as the previously-received |
|
367 duplicate, but it does not also have a Retransmission Block |
|
368 that was inserted by that custodian, or |
|
369 |
|
370 -Has the same custodian and Retransmission Block as the |
|
371 previously-received duplicate. |
|
372 |
|
373 If replays are not allowed and if the node does not support the |
|
374 optional Retransmission Block defined in this document, then the |
|
375 node MUST delete all duplicate bundles that it receives (at the |
|
376 risk of also deleting all legitimate custodial retransmissions |
|
377 that it receives). |
|
378 |
|
379 |
|
380 |
|
381 |
|
382 |
|
383 |
|
384 |
|
385 |
|
386 |
|
387 |
|
388 |
|
389 |
|
390 |
|
391 Symington Expires April 16, 2007 [Page 7] |
|
392 |
|
393 Internet-Draft DTN Retransmission Block October 2006 |
|
394 |
|
395 |
|
396 4. Replays versus Loops |
|
397 |
|
398 The procedures for deleting all duplicate bundles that can not be |
|
399 legitimate custodial retransmissions above will result in the |
|
400 deletion of not only replays, but also of bundles that loop through |
|
401 the network multiple times. If the looping is unintentional, due to |
|
402 routing or forwarding errors, deletion of these bundles is desirable. |
|
403 If the looping is intentional, however, then the deletion of a bundle |
|
404 in such a loop is not desirable. For example, if a custodial node, |
|
405 C, needs to free up disk space by temporarily transferring custody |
|
406 and storage of a bundle to some sort of "auxiliary storage" node that |
|
407 is not on the path to the bundle's destination until the path to the |
|
408 destination becomes connected, then the path from the custodian C to |
|
409 the auxiliary storage node and back would constitute an intentional |
|
410 routing loop. In order to free up its storage space when sending the |
|
411 bundle to auxiliary storage, custody of the bundle would be |
|
412 transferred from node C to the auxiliary storage node. When the |
|
413 bundle is sent back to node C from auxiliary storage, the auxiliary |
|
414 storage node would be listed as the bundle's custodian. According to |
|
415 the procedures for deleting duplicate bundles that can not be |
|
416 legitimate custodial retransmissions described earlier in Section 3, |
|
417 this bundle would not be deleted by node C because it does not have |
|
418 the same custodian as it had when it was initially received by node |
|
419 C. If for some reason this storing of the bundle at the auxiliary |
|
420 storage node has to be performed a second time, however, then the |
|
421 procedures above will not suffice to spare this bundle from deletion. |
|
422 |
|
423 If node C receives the bundle from auxiliary storage and forwards it |
|
424 back to auxiliary storage without taking custody of it, auxiliary |
|
425 storage will delete this copy of the bundle, but it will still be |
|
426 custodian of the bundle and will still have it in storage. This case |
|
427 is not a problem. If, on the other hand, node C receives the bundle |
|
428 from auxiliary storage and takes custody of the bundle before |
|
429 forwarding it back to auxiliary storage, the auxiliary storage node |
|
430 will delete this bundle (but the auxiliary storage node will not |
|
431 still be custodian of the bundle and will not still have the bundle |
|
432 in storage) because the auxiliary storage node has already received |
|
433 this bundle with node C listed as its custodian and this bundle does |
|
434 not contain a retransmission block because node C did not forward it |
|
435 as a custodial retransmission. |
|
436 |
|
437 There are several possible approaches that may be taken to address |
|
438 this problem by attempting to process bundles that are in "desirable" |
|
439 loops and discard bundles that are in "undesirable" loops, while |
|
440 staying within the procedures defined above for deleting duplicate |
|
441 bundles that can not be legitimate custodial retransmissions. For |
|
442 example, custodial nodes that make use of auxiliary storage nodes |
|
443 might be configured to accept duplicate bundles received from |
|
444 |
|
445 |
|
446 |
|
447 Symington Expires April 16, 2007 [Page 8] |
|
448 |
|
449 Internet-Draft DTN Retransmission Block October 2006 |
|
450 |
|
451 |
|
452 auxiliary storage nodes, and vice versa. Alternatively, a special |
|
453 block might be defined to mark a bundle that a custodial node is |
|
454 sending to an auxiliary storage node for storage and custody |
|
455 transfer. As long as a bundle is marked such that it is intended for |
|
456 auxiliary storage, it could be accepted and stored at the auxiliary |
|
457 storage node, even if it is a duplicate of a previously-received |
|
458 bundle. If the auxiliary storage node treats all subsequent |
|
459 forwardings of a bundle after the first forwarding as though the |
|
460 forwarding were the result of a custodial retransmission by inserting |
|
461 a Retransmission Block into the bundle, bundles could be circulated |
|
462 between custodians and their auxiliary storage nodes multiple times |
|
463 without being summarily deleted. Using these solution approaches, |
|
464 there would be no limit to the number of times a bundle could be |
|
465 offloaded to auxiliary storage, if needed. A risk of implementing |
|
466 these approaches, however, is that bundles that unintentionally loop |
|
467 between a custodian and its auxiliary storage node may not be |
|
468 discarded. Furthermore, these approaches assume that all intentional |
|
469 loops can be known a priori, so that nodes can be configured to |
|
470 accept duplicate bundles looping through them or that at least one |
|
471 node in the loop can be configured to insert Retransmission Blocks |
|
472 into the looping bundles to protect them from being discarded. These |
|
473 approaches do not necessarily work for loops that arise |
|
474 opportunistically, being unplanned but useful, unless there is a |
|
475 mechanism within the loop for retransmission blocks to be inserted |
|
476 into the looping bundle as appropriate. |
|
477 |
|
478 |
|
479 |
|
480 |
|
481 |
|
482 |
|
483 |
|
484 |
|
485 |
|
486 |
|
487 |
|
488 |
|
489 |
|
490 |
|
491 |
|
492 |
|
493 |
|
494 |
|
495 |
|
496 |
|
497 |
|
498 |
|
499 |
|
500 |
|
501 |
|
502 |
|
503 Symington Expires April 16, 2007 [Page 9] |
|
504 |
|
505 Internet-Draft DTN Retransmission Block October 2006 |
|
506 |
|
507 |
|
508 5. Ramifications of Allowing Support for the Retransmission Block to be |
|
509 Optional |
|
510 |
|
511 The objective of the DTN Retransmission Block is to make custodially- |
|
512 retransmitted bundles distinguishable from unintentional and |
|
513 malicious replays. Because support for the Retransmission Block is |
|
514 optional, it may not be supported by all nodes in the DTN. Failure |
|
515 to support the Retransmission Block at one or more nodes in the DTN |
|
516 may result in the erroneous deletion of bundles that are legitimate |
|
517 retransmissions because: |
|
518 |
|
519 A node that does not support the Retransmission Block but that is |
|
520 configured to suppress replays will delete all duplicate bundles, |
|
521 whether or not they include Retransmission Blocks that mark them |
|
522 as being legitimate retransmissions. |
|
523 |
|
524 A custodial node that does not support the Retransmission Block |
|
525 but that legitimately retransmits a bundle will not include a |
|
526 Retransmission Block to mark the bundle as a legitimate |
|
527 retransmission, so that when the bundle is received at a |
|
528 downstream node that is configured to suppress replays, the bundle |
|
529 will be deleted by that downstream node (even if that downstream |
|
530 node supports the Retransmission Block). |
|
531 |
|
532 A DTN cannot completely support both replay suppression and custodial |
|
533 retransmission if some of its nodes do not support the Retransmission |
|
534 Block. If all unintentional replays must be suppressed and custodial |
|
535 retransmission must be supported, all nodes in the network must |
|
536 support the Retransmission Block. If one or more nodes does not |
|
537 support the Retransmission Block, then if these nodes are configured |
|
538 to suppress replays, they will delete custodial retransmissions that |
|
539 they receive and issue custodial retransmissions that are vulnerable |
|
540 to being deleted downstream; if they are configured to forward |
|
541 replays, then they will forward all replays, both intentional and |
|
542 malicious ones. |
|
543 |
|
544 Nodes that do not support the Retransmission Block cannot create, |
|
545 recognize, or process a Retransmission Block. If the Retransmission |
|
546 Block Processing Flags indicate that a bundle must be deleted if the |
|
547 Retransmission Block cannot be processed, then all nodes that do not |
|
548 support the Retransmission Block will delete all custodial |
|
549 retransmissions, even if these nodes are not configured to suppress |
|
550 replays. If the Retransmission Block Processing Flags indicate that |
|
551 the Retransmission Block must be deleted if it cannot be processed, |
|
552 then all nodes that do not support the Retransmission Block will |
|
553 strip the Retransmission Block out of every custodial retransmission |
|
554 that they forward, leaving these custodial retransmissions vulnerable |
|
555 to downstream deletion by nodes that suppress replays (even if those |
|
556 |
|
557 |
|
558 |
|
559 Symington Expires April 16, 2007 [Page 10] |
|
560 |
|
561 Internet-Draft DTN Retransmission Block October 2006 |
|
562 |
|
563 |
|
564 downstream nodes support the Retransmission Block). |
|
565 |
|
566 If not all nodes in the DTN support the Retransmission Block, then to |
|
567 preserve support for custodial retransmission while maximizing replay |
|
568 suppression, the security policies of the nodes and the Block |
|
569 Processing Flags in the Retransmission Block should be configured as |
|
570 follows: |
|
571 |
|
572 -The "Discard bundle if block can't be processed" Block Processing |
|
573 Flag SHOULD NOT be set, |
|
574 |
|
575 -The "Discard block if it can't be processed" Block Processing |
|
576 Flag SHOULD NOT be set, |
|
577 |
|
578 -Nodes that support the Retransmission Block should be configured |
|
579 to delete all replays that can not be custodial retransmissions, |
|
580 |
|
581 -Nodes that do not support the Retransmission Block should be |
|
582 configured to forward duplicates (so that they don't inadvertently |
|
583 delete custodial retransmissions), and |
|
584 |
|
585 -Nodes that do not support the Retransmission Block should be |
|
586 configured not to take custody of bundles (to ensure that |
|
587 custodial retransmissions will always include Retransmission |
|
588 Blocks). |
|
589 |
|
590 The above configuration ensures that custodial retransmissions will |
|
591 not be erroneously deleted, and that all illegitimate replays that |
|
592 are received at nodes that support the Retransmission Block will be |
|
593 deleted. Only replays that are received at nodes that do not support |
|
594 the Retransmission Block will be forwarded and allowed to remain in |
|
595 the network. If these are forwarded to a node that supports the |
|
596 Retransmission Block, however, they will be deleted at that node. |
|
597 Therefore, a network configured in this way is vulnerable to a |
|
598 denial-of-service attack only from replayed bundles that circulate |
|
599 exclusively among nodes that do not support the Retransmission Block. |
|
600 |
|
601 |
|
602 |
|
603 |
|
604 |
|
605 |
|
606 |
|
607 |
|
608 |
|
609 |
|
610 |
|
611 |
|
612 |
|
613 |
|
614 |
|
615 Symington Expires April 16, 2007 [Page 11] |
|
616 |
|
617 Internet-Draft DTN Retransmission Block October 2006 |
|
618 |
|
619 |
|
620 6. Retransmission Block Format |
|
621 |
|
622 The Retransmission Block (RB) is a new block that MAY be included in |
|
623 a bundle. A RB uses the Canonical Bundle Block Format as defined in |
|
624 the Bundle Protocol [2]. That is, it is comprised of the following |
|
625 elements: |
|
626 |
|
627 -Block-type code (one byte) - defined as in all bundle protocol |
|
628 blocks except the primary bundle block (as described in the Bundle |
|
629 Protocol). The block type code for the Retransmission Block is |
|
630 0x07. |
|
631 |
|
632 -Block processing control flags (one byte) - defined as in all |
|
633 bundle protocol blocks except the primary bundle block (as |
|
634 described in the Bundle Protocol). The following block processing |
|
635 control flag MUST NOT be set: |
|
636 |
|
637 -Block must be replicated in every fragment |
|
638 |
|
639 -Block data length (SDNV) - defined as in all bundle protocol |
|
640 blocks except the primary bundle block. SDNV encoding is |
|
641 described in the Bundle Protocol. |
|
642 |
|
643 -Block-type-specific data fields as follows: |
|
644 |
|
645 - EID Scheme Offset of retransmitting custodian - a 16-bit |
|
646 unsigned integer; its value is the offset within the dictionary |
|
647 byte array of the first character of the scheme name of the EID |
|
648 of the retransmitting custodian that inserted this block. |
|
649 |
|
650 -EID SSP Offset of retransmitting custodian - a 16-bit unsigned |
|
651 integer; its value is the offset within the dictionary byte |
|
652 array of the first character of the scheme-specific part of the |
|
653 EID of the retransmitting custodian that inserted this block. |
|
654 |
|
655 - Retransmission sequence number (one byte) - An unsigned |
|
656 integer indicating the number of times this bundle has been |
|
657 retransmitted by this custodian. |
|
658 |
|
659 The structure of a Retransmission Block is as follows: |
|
660 |
|
661 Retransmission Block Format: |
|
662 +-----+------+-------+-------------+------+----------------+ |
|
663 |Type |Flags |Length |EID Scheme |EID SSP | Retransmission | |
|
664 | | | | offset | offset | Sequence Num. | |
|
665 +-----+------+-------+-------------+------+----------------+ |
|
666 |
|
667 Figure 1 |
|
668 |
|
669 |
|
670 |
|
671 Symington Expires April 16, 2007 [Page 12] |
|
672 |
|
673 Internet-Draft DTN Retransmission Block October 2006 |
|
674 |
|
675 |
|
676 7. Retransmission Block Processing |
|
677 |
|
678 The following are the processing steps that a bundle node must take |
|
679 relative to generation, reception, and processing of Retransmission |
|
680 Blocks. |
|
681 |
|
682 7.1. Bundle Reception |
|
683 |
|
684 According to the Bundle Protocol, if a node receives a bundle that it |
|
685 currently has in custody as custodian, that node will send a "Failed" |
|
686 custody signal for this bundle to the bundle's listed current |
|
687 custodian, but receipt of this duplicate bundle will not cause the |
|
688 bundle to be either delivered at that node or forwarded to another |
|
689 node. |
|
690 |
|
691 Upon receipt of a bundle that the node does not currently have in |
|
692 custody, the node SHALL delete the bundle's Retransmission Block if |
|
693 the endpoint ID referred to by the EID Scheme and EID SSP offsets in |
|
694 the Retransmission Block is not the same as the endpoint ID referred |
|
695 to by the Custodian scheme and Custodian SSP offsets in the Primary |
|
696 Bundle Block. The node SHALL also delete all strings (scheme names |
|
697 and scheme-specific parts-SSPs) in the bundle's dictionary to which |
|
698 no endpoint ID references in the bundle currently refer (if any). |
|
699 |
|
700 7.2. Replay Detection and Suppression |
|
701 |
|
702 If a node's security policy indicates that replays are not allowed |
|
703 and if a bundle is received such that the bundle's source EID, |
|
704 timestamp, and fragment offset (if it has one) are identical to those |
|
705 in a bundle that the node had previously received, then |
|
706 |
|
707 -If the received bundle does not include a Retransmission Block |
|
708 and its custodian EID is the same as it was in a previously- |
|
709 received duplicate bundle, the bundle MUST be deleted. |
|
710 |
|
711 -If the received bundle does include a Retransmission Block and |
|
712 all the values in it are the same as all the values in the |
|
713 Retransmission Block of the previously-received, duplicate bundle, |
|
714 the bundle MUST be deleted. |
|
715 |
|
716 7.3. Keeping Track of Bundles Received |
|
717 |
|
718 If replays are not allowed at this node, and if a bundle will not be |
|
719 deleted as a replay, the source EID, timestamp, fragment offset (if |
|
720 any), custodian EID (if the bundle does not include a Retransmission |
|
721 Block) and Retransmission Block (if any) of the received bundle MUST |
|
722 be stored at this node for comparison with future received bundles. |
|
723 |
|
724 |
|
725 |
|
726 |
|
727 Symington Expires April 16, 2007 [Page 13] |
|
728 |
|
729 Internet-Draft DTN Retransmission Block October 2006 |
|
730 |
|
731 |
|
732 7.4. Bundle Forwarding |
|
733 |
|
734 As part of the custody acceptance procedures, the accepting node MUST |
|
735 delete the bundle's Retransmission Block (if it has one). |
|
736 |
|
737 7.5. Custodial Retransmission |
|
738 |
|
739 Upon deciding to re-forward a bundle as a result of custody transfer |
|
740 failure, the re-forwarding custodian MUST: |
|
741 |
|
742 - insert a Retransmission Block into the bundle if the bundle does |
|
743 not already include one, or |
|
744 |
|
745 - increment the retransmission sequence number in the |
|
746 Retransmission Block if the bundle does already include one |
|
747 |
|
748 In either case, the EID Scheme offset and the EID SSP offset in the |
|
749 Retransmission Block must refer to the EID of the re-forwarding |
|
750 custodian as it appears in the bundle. |
|
751 |
|
752 If a custodian decides to re-forward only a fragment of a bundle that |
|
753 it had previously forwarded, the re-forwarded fragment will not be a |
|
754 duplicate of any bundle that had previously been transmitted by this |
|
755 custodian. Therefore, the re-forwarded fragment SHALL NOT include a |
|
756 Retransmission Block. |
|
757 |
|
758 |
|
759 |
|
760 |
|
761 |
|
762 |
|
763 |
|
764 |
|
765 |
|
766 |
|
767 |
|
768 |
|
769 |
|
770 |
|
771 |
|
772 |
|
773 |
|
774 |
|
775 |
|
776 |
|
777 |
|
778 |
|
779 |
|
780 |
|
781 |
|
782 |
|
783 Symington Expires April 16, 2007 [Page 14] |
|
784 |
|
785 Internet-Draft DTN Retransmission Block October 2006 |
|
786 |
|
787 |
|
788 8. Security Considerations |
|
789 |
|
790 Each node's local security policy will determine whether replays will |
|
791 be detected and suppressed at that node or whether replays will be |
|
792 forwarded indiscriminately. When deciding upon a node's security |
|
793 policy, it is worth noting that in most networks, the Bundle |
|
794 Authentication Block (BAB) must be used in conjunction with replay |
|
795 detection and suppression. It does not make sense to detect and |
|
796 suppress replayed bundles without first authenticating that those |
|
797 bundles have not been modified. Without use of the BAB to |
|
798 authenticate that a bundle has been forwarded in tact, a network is |
|
799 vulnerable to denial of service attacks launched merely by the |
|
800 injection of any spurious bundles into the network or the |
|
801 modification of any authentic bundles. There seems little value in |
|
802 protecting against denial-of-service attacks resulting from replayed |
|
803 bundles if denial-of-service attacks resulting from such modified or |
|
804 spurious bundles will be permitted. Therefore, in determining the |
|
805 security policy of a node, it will usually be the case that nodes |
|
806 that do not allow replays must also require received bundles to |
|
807 include BABs. |
|
808 |
|
809 Because the RB may be inserted at any custodian in the network and |
|
810 deleted at any subsequent custodian, its integrity can't be protected |
|
811 by an end-to-end Payload Security Block (PSB) [3]. Its integrity |
|
812 must be protected by the BAB. If the integrity of the RB is not |
|
813 protected by the BAB, then a malicious intruder could modify the RB |
|
814 to inject many illegitimately replayed bundles, yet give the RB |
|
815 values such that these bundles appear to be legitimate |
|
816 retransmissions. As currently defined, protection for the RB will be |
|
817 included when using the mandatory BAH-HMAC ciphersuite defined in the |
|
818 Bundle Security Protocol, given that this ciphersuite uses the strict |
|
819 canonicalisation algorithm. |
|
820 |
|
821 If a node is compromised, this BAB doesn't help to protect against |
|
822 replays, but then the network has a lot more vulnerabilities than |
|
823 just a vulnerability to replays. If a node is compromised, any |
|
824 bundle could be created and injected into the network. The RB |
|
825 mechanism is no more vulnerable to misuse by a compromised node than |
|
826 are any of the other security mechanisms. |
|
827 |
|
828 |
|
829 |
|
830 |
|
831 |
|
832 |
|
833 |
|
834 |
|
835 |
|
836 |
|
837 |
|
838 |
|
839 Symington Expires April 16, 2007 [Page 15] |
|
840 |
|
841 Internet-Draft DTN Retransmission Block October 2006 |
|
842 |
|
843 |
|
844 9. IANA Considerations |
|
845 |
|
846 None at this time. If the bundle protocol becomes a standards track |
|
847 protocol, then we may want to consider having IANA establish a |
|
848 register of block types, of which the Retransmission Block would be |
|
849 one. |
|
850 |
|
851 |
|
852 |
|
853 |
|
854 |
|
855 |
|
856 |
|
857 |
|
858 |
|
859 |
|
860 |
|
861 |
|
862 |
|
863 |
|
864 |
|
865 |
|
866 |
|
867 |
|
868 |
|
869 |
|
870 |
|
871 |
|
872 |
|
873 |
|
874 |
|
875 |
|
876 |
|
877 |
|
878 |
|
879 |
|
880 |
|
881 |
|
882 |
|
883 |
|
884 |
|
885 |
|
886 |
|
887 |
|
888 |
|
889 |
|
890 |
|
891 |
|
892 |
|
893 |
|
894 |
|
895 Symington Expires April 16, 2007 [Page 16] |
|
896 |
|
897 Internet-Draft DTN Retransmission Block October 2006 |
|
898 |
|
899 |
|
900 10. References |
|
901 |
|
902 10.1. Normative References |
|
903 |
|
904 [1] Bradner, S. and J. Reynolds, "Key words for use in RFCs to |
|
905 Indicate Requirement Levels", RFC 2119, October 1997. |
|
906 |
|
907 [2] Scott, K. and S. Burleigh, "Bundle Protocol Specification", |
|
908 draft-irtf-dtnrg-bundle-spec-05.txt, work-in-progress, |
|
909 April 2006. |
|
910 |
|
911 [3] Symington, S., Farrell, S., and H. Weiss, "Bundle Security |
|
912 Protocol Specification", |
|
913 draft-irtf-dtnrg-bundle-security-01.txt, work-in-progress, |
|
914 March 2006. |
|
915 |
|
916 10.2. Informative References |
|
917 |
|
918 [4] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst, R., |
|
919 Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant Network |
|
920 Architecture", draft-irtf-dtnrg-arch-05.txt, work-in-progress, |
|
921 March 2006. |
|
922 |
|
923 [5] Farrell, S., Symington, S., and H. Weiss, "Delay-Tolerant |
|
924 Network Security Overview", |
|
925 draft-irtf-dtnrg-sec-overview-01.txt, work-in-progress, |
|
926 March 2006. |
|
927 |
|
928 |
|
929 |
|
930 |
|
931 |
|
932 |
|
933 |
|
934 |
|
935 |
|
936 |
|
937 |
|
938 |
|
939 |
|
940 |
|
941 |
|
942 |
|
943 |
|
944 |
|
945 |
|
946 |
|
947 |
|
948 |
|
949 |
|
950 |
|
951 Symington Expires April 16, 2007 [Page 17] |
|
952 |
|
953 Internet-Draft DTN Retransmission Block October 2006 |
|
954 |
|
955 |
|
956 Author's Address |
|
957 |
|
958 Susan Flynn Symington |
|
959 The MITRE Corporation |
|
960 7515 Colshire Drive |
|
961 McLean, VA 22102 |
|
962 US |
|
963 |
|
964 Phone: +1 (703) 983-7209 |
|
965 Email: susan@mitre.org |
|
966 URI: http://mitre.org/ |
|
967 |
|
968 |
|
969 |
|
970 |
|
971 |
|
972 |
|
973 |
|
974 |
|
975 |
|
976 |
|
977 |
|
978 |
|
979 |
|
980 |
|
981 |
|
982 |
|
983 |
|
984 |
|
985 |
|
986 |
|
987 |
|
988 |
|
989 |
|
990 |
|
991 |
|
992 |
|
993 |
|
994 |
|
995 |
|
996 |
|
997 |
|
998 |
|
999 |
|
1000 |
|
1001 |
|
1002 |
|
1003 |
|
1004 |
|
1005 |
|
1006 |
|
1007 Symington Expires April 16, 2007 [Page 18] |
|
1008 |
|
1009 Internet-Draft DTN Retransmission Block October 2006 |
|
1010 |
|
1011 |
|
1012 Intellectual Property Statement |
|
1013 |
|
1014 The IETF takes no position regarding the validity or scope of any |
|
1015 Intellectual Property Rights or other rights that might be claimed to |
|
1016 pertain to the implementation or use of the technology described in |
|
1017 this document or the extent to which any license under such rights |
|
1018 might or might not be available; nor does it represent that it has |
|
1019 made any independent effort to identify any such rights. Information |
|
1020 on the procedures with respect to rights in RFC documents can be |
|
1021 found in BCP 78 and BCP 79. |
|
1022 |
|
1023 Copies of IPR disclosures made to the IETF Secretariat and any |
|
1024 assurances of licenses to be made available, or the result of an |
|
1025 attempt made to obtain a general license or permission for the use of |
|
1026 such proprietary rights by implementers or users of this |
|
1027 specification can be obtained from the IETF on-line IPR repository at |
|
1028 http://www.ietf.org/ipr. |
|
1029 |
|
1030 The IETF invites any interested party to bring to its attention any |
|
1031 copyrights, patents or patent applications, or other proprietary |
|
1032 rights that may cover technology that may be required to implement |
|
1033 this standard. Please address the information to the IETF at |
|
1034 ietf-ipr@ietf.org. |
|
1035 |
|
1036 |
|
1037 Disclaimer of Validity |
|
1038 |
|
1039 This document and the information contained herein are provided on an |
|
1040 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS |
|
1041 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET |
|
1042 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, |
|
1043 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE |
|
1044 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED |
|
1045 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. |
|
1046 |
|
1047 |
|
1048 Copyright Statement |
|
1049 |
|
1050 Copyright (C) The Internet Society (2006). This document is subject |
|
1051 to the rights, licenses and restrictions contained in BCP 78, and |
|
1052 except as set forth therein, the authors retain all their rights. |
|
1053 |
|
1054 |
|
1055 Acknowledgment |
|
1056 |
|
1057 Funding for the RFC Editor function is currently provided by the |
|
1058 Internet Society. |
|
1059 |
|
1060 |
|
1061 |
|
1062 |
|
1063 Symington Expires April 16, 2007 [Page 19] |
|
1064 |