idnits 2.17.1 draft-irtf-dtnrg-sec-overview-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 19. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1092. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1103. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1110. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1116. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 1, 2008) is 5647 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-19) exists of draft-irtf-dtnrg-bundle-security-05 == Outdated reference: A later version (-10) exists of draft-irtf-dtnrg-ltp-09 == Outdated reference: A later version (-08) exists of draft-irtf-dtnrg-ltp-extensions-06 == Outdated reference: A later version (-07) exists of draft-irtf-dtnrg-ltp-motivation-05 -- No information found for draft-irtf-dtnrg-bundle-aaa - is the name correct? -- Obsolete informational reference (is this intentional?): RFC 4346 (ref. '11') (Obsoleted by RFC 5246) -- No information found for draft-irtf-dtnrg-bundle-retrans - is the name correct? -- No information found for draft-irtf-dtnrg-bundle-multicast-custodial - is the name correct? Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DTN Research Group S. Farrell 3 Internet-Draft Trinity College Dublin 4 Expires: May 5, 2009 S. Symington 5 The MITRE Corporation 6 H. Weiss 7 P. Lovell 8 SPARTA, Inc. 9 November 1, 2008 11 Delay-Tolerant Networking Security Overview 12 draft-irtf-dtnrg-sec-overview-05 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on May 5, 2009. 39 Copyright Notice 41 Copyright (C) The IETF Trust (2008). 43 Abstract 45 This document provides an overview of the security requirements and 46 mechanisms considered for delay tolerant networking security. It 47 discusses the options for protecting such networks and describes 48 reasons why specific security mechanisms were (or were not) chosen 49 for the relevant protocols. The entire document is informative, 50 given its purpose is mainly to document design decisions. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 1.1. This document . . . . . . . . . . . . . . . . . . . . . . 3 56 1.2. Background . . . . . . . . . . . . . . . . . . . . . . . . 4 57 2. Threats . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 2.1. Non DTN node threats . . . . . . . . . . . . . . . . . . . 5 59 2.2. Resource consumption . . . . . . . . . . . . . . . . . . . 5 60 2.3. Denial of service . . . . . . . . . . . . . . . . . . . . 6 61 2.4. Confidentiality and integrity . . . . . . . . . . . . . . 6 62 2.5. Traffic storms . . . . . . . . . . . . . . . . . . . . . . 7 63 2.6. Partial protection is just that. . . . . . . . . . . . . . 7 64 3. Security Requirements . . . . . . . . . . . . . . . . . . . . 9 65 3.1. End-to-end-ish-ness . . . . . . . . . . . . . . . . . . . 9 66 3.2. Confidentiality and integrity . . . . . . . . . . . . . . 10 67 3.3. Policy based routing . . . . . . . . . . . . . . . . . . . 11 68 4. Security Design considerations . . . . . . . . . . . . . . . . 14 69 4.1. Only DTN-friendly schemes need apply . . . . . . . . . . . 14 70 4.2. TLS is a good model . . . . . . . . . . . . . . . . . . . 14 71 4.3. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 15 72 4.4. Naming and identities . . . . . . . . . . . . . . . . . . 16 73 4.5. Placement of checksums . . . . . . . . . . . . . . . . . . 17 74 4.6. Hop-by-hop-ish-ness . . . . . . . . . . . . . . . . . . . 17 75 5. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 19 76 5.1. Key management . . . . . . . . . . . . . . . . . . . . . . 19 77 5.2. Handling replays . . . . . . . . . . . . . . . . . . . . . 19 78 5.3. Traffic analysis . . . . . . . . . . . . . . . . . . . . . 21 79 5.4. Routing protocol security . . . . . . . . . . . . . . . . 21 80 5.5. Multicast security . . . . . . . . . . . . . . . . . . . . 21 81 5.6. Performance Issues . . . . . . . . . . . . . . . . . . . . 23 82 6. Security Considerations . . . . . . . . . . . . . . . . . . . 24 83 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 84 8. Informative References . . . . . . . . . . . . . . . . . . . . 26 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28 86 Intellectual Property and Copyright Statements . . . . . . . . . . 29 88 1. Introduction 90 This section places this document in its current context as one of a 91 series of DTN documents. 93 1.1. This document 95 This document is a product of the IRTF (http://www.irtf.org/) Delay 96 Tolerant Networking Research Group (DTRNG) and is being discussed on 97 the dtn-security mailing list. See the DRNRG site 98 (http://www.dtnrg.org/) for details of the various DTN mailing lists. 100 The intent is for this document to present a snapshot of the security 101 analysis which has been carried out in the DTNRG. The document is 102 not normative in any sense but is intended to be a companion document 103 which explains further the reasons for the design choices which are 104 documented elsewhere. The discussion includes updates based upon 105 experience gained during implementation of the security protocol. 107 The structure of the document is as follows: 109 We first present a selection of threats which were considered 110 during the analysis carried out so far. 112 We then present some security requirements derived from that 113 analysis or elsewhere. 115 We next present some of the design considerations which were 116 applied during the design of the security mechanisms. 118 And we finally discuss some of the remaining open issues in DTN 119 security. 121 Given that this is simply an informative snapshot document, none of 122 the above are intended to be exhaustive, nor should other documents 123 be criticized because something is mentioned here, but not countered 124 there. 126 While this document is being prepared in parallel with the various 127 protocol and security specifications, we will generally try not to 128 refer to the specific fields used in those documents since the 129 details may change and maintaining consistency at that level is not a 130 goal here. Where we do refer to such details, of course, the 131 specification documents are normative. 133 1.2. Background 135 The overall delay tolerant networking (DTN) architecture is described 136 in [1]. A DTN is an overlay network on top of lower layer networks, 137 which may vary from node to node. Some of these are challenged by 138 limitations such as intermittent loss of connectivity, long or 139 variable delay, asymmetric data rates, or high error rates. The 140 purpose of a DTN protocol is to support interoperability across such 141 potentially stressed lower layer networks. The DTN overlay network 142 specifies a bundle protocol which is layered on top of a "convergence 143 layer", which is itself on top of other lower layers. The DTN Bundle 144 Protocol [2] describes the format of the messages (called bundles) 145 passed between DTN bundle agents that participate in bundle 146 communications to form the DTN store-and-forward overlay network. 148 The Bundle Security Protocol Specification [3] defines the integrity 149 and confidentiality mechanisms for use with the Bundle protocol 150 together with associated policy options. 152 Two other documents exists which are now somewhat outdated but remain 153 worthwhile reading: A tutorial [4] about DTNs and an early DTN 154 security model document [5]. 156 There is also a related lower layer protocol specifically designed 157 for very long delay environments, called the Licklider Transmission 158 Protocol (LTP), [6] and which is also being developed by the same 159 group. Even though the LTP protocol shares some security features 160 [7] with the bundle protocol, we will mainly reference the bundle 161 protocol here since its environment is much more complex and there is 162 also a separate LTP motivation document [8]. 164 In this document we may refer to "messages" to mean either a bundle 165 from the bundle protocol or a segment from the LTP protocol. The 166 context should make the meaning clear in each case. 168 2. Threats 170 This section describes some of the threats considered during the 171 design process of the DTN security mechanisms. In this 172 discussion,and throughout the document, we try to highlight DTN- 173 specific aspects, assuming the reader is generally familiar with 174 basic networking security concepts. 176 2.1. Non DTN node threats 178 The first set of threats considered were those coming from network 179 elements which aren't directly part of the DTN. As an overlay 180 network, bundles typically traverse multiple underlying network 181 elements on each DTN "hop". Any vulnerability in the bundle protocol 182 can be exploited at any of those network elements. 184 DTN security must take into account the usual range of such potential 185 exploits (masquerading, bit flips, etc.) but in contrast to most 186 network protocols, as an overlay protocol, the bundle protocol is 187 possibly an easier target. In particular, if it is possible to 188 insert new bundles at such lower-layer "hops", then DTN nodes have to 189 be capable of countering such insertions by where possible, detecting 190 and quickly deleting such spurious bundles. 192 Conversely, it is equally possible to take advantage of lower layer 193 network security services, but this isn't be visible from the DTN 194 layer, and requires coordinated administration in order to be really 195 effective. 197 2.2. Resource consumption 199 Due to the resource-scarcity that characterizes DTNs, unauthorized 200 access and use of DTN resources is a serious concern. Specifically, 201 the following can consume DTN resources and be considered threats 202 against a DTN infrastructure: 204 1. access by unauthorized entities, 206 2. unauthorized applications controlling the DTN infrastructure, 208 3. authorized applications sending bundles at a rate or class of 209 service for which they lack permission, 211 4. unauthorised bundle content modification, 213 5. compromised network elements, be they DTN nodes or not. 215 In addition to these threats, DTN nodes can act to assist or amplify 216 such resource consuming behavior as follows: 218 1. forwarding bundles that were not sent by authorized DTN nodes 220 2. generating reports not originally requested (e.g. if a bundle has 221 been modified). 223 3. not detecting unplanned replays or other mis-behaviors 225 2.3. Denial of service 227 In addition to the basic resource consumption threats mentioned above 228 there is also a range of denial of service (DoS) attacks which must 229 be considered in the DTN context. DTNs are in this respect, in more- 230 or-less the same position as other MANETs so all the problems with 231 secure routing in ad-hoc networks [9] exist for many DTNs too! 233 DoS attacks can be mounted at any layer, from physical to 234 application. Generally when developing a new protocol we should 235 attempt two things:- 237 - Make it hard to launch an "off-path" DoS attacks by making it hard 238 to "guess" valid values for messages, e.g. through using random 239 values instead of counters for identifying messages. 241 - Make it easier to withstand "on-path" DoS attacks by providing a 242 way to choke-off DoS traffic, e.g. by changing to a mode of 243 operation where only fresh, authenticated messages are accepted 244 and all others are dropped. 246 In a DTN environment, the generally longer latencies involved will 247 probably act to make DoS attempts more effective, so protocol 248 developers and deployments should explicitly consider DoS at all 249 times. 251 As with all networks, security mechanisms will themselves create new 252 DoS opportunities. Therefore whatever services and mechanisms are 253 defined for DTN security should explicitly consider DoS. For 254 example, mechanisms which involve certificate status checking (via 255 some protocol to a key server) based on received messages create new 256 DoS opportunities since such lookups consume resources on both the 257 receiving node and the key server. 259 2.4. Confidentiality and integrity 261 In addition to resource consuming threats, DTN applications can also 262 be vulnerable to threats against confidentiality and integrity, such 263 as: 265 1. falsifying a bundle's source, 267 2. changing the intended destination, 269 3. changing a bundle's control fields, 271 4. changing other block or payload fields, 273 5. replay of bundles 275 6. copying or disclosing bundle data as it passes. 277 2.5. Traffic storms 279 Since DTN protocols generate traffic as an artifact of other traffic, 280 manipulation of bundle content, genuine, forged or modified, can be 281 used to create unwanted traffic. In a DTN operating sufficiently 282 "close to the wire", such traffic can have serious affects. 284 The Bundle Protocol includes various messages containing 285 administrative records (e.g. bundle status reports, custody signals) 286 produced in response to original traffic. The protocol 287 specification, however, includes a constraint that the status report 288 request flags must be zero on all bundles containing administrative 289 records. Although a bundle that is not a custody signal or status 290 report may cause the generation of custody signals and/or status 291 reports, bundles that are themselves custody signals or status 292 reports are not permitted to cause the generation of custody signals 293 or status reports. This constraint is designed to prevent bundle 294 storms and it does in the case when bundles can not be modified. If 295 a DTN node (or other network element) could modify a "forwarding 296 report" by resetting its "Application Data Unit is an Administrative 297 Record" bundle flag and setting its "forwarding report" request flag, 298 then this could cause the forwarding of an additional status reports, 299 and so on. Traffic could continue to be generated in this manner for 300 as long as the values of the bundle processing flags and the status 301 report request flags can be modified. While the constraint 302 prohibiting bundles containing administrative records from generating 303 other bundles containing administrative records helps prevent traffic 304 storms, it may be best to entirely remove some of status reporting 305 capabilities from the Bundle Protocol. 307 2.6. Partial protection is just that. 309 Not all DTN nodes need to protect all parts of all bundles. Fr 310 example, some DTN nodes won't be able to protect the integrity of the 311 entire bundle including its payload. Reasons range from lack of 312 computing power to application (or lower) layer protection mechanisms 313 already applying integrity. Alternatively, some DTN nodes may choose 314 not to protect all parts of all bundles in order to permit reactive 315 fragmentation. 317 There are also cases when bundle blocks will be modified in transit 318 (e.g. the dictionary in the primary block), or a "via" block which 319 captures the route a bundle has followed. As a result, integrity 320 checking on anything more than a hop-by-hop basis becomes unwieldy 321 other than for the payload. 323 So it is possible that some fields of a bundle are strongly protected 324 whilst others are effectively unprotected. Whenever such a situation 325 occurs, it will be still possible for network elements to use the 326 bundle protocol as a communications channel, perhaps covert or 327 perhaps overt. Where such misuse is a concern, the DTN should either 328 use different security options which cover the fields of concern, or 329 else administrators must ensure that the bundles only traverse lower 330 layers where the probability of such misuse is sufficiently small. 332 3. Security Requirements 334 This section describes some of the high-priority DTN security 335 requirements. 337 3.1. End-to-end-ish-ness 339 Traditionally, protocols tend to provide security services which are 340 used either (or both) on a hop-by-hop or end-to-end basis. For DTN 341 security though, we require that these services be usable also 342 between nodes which are not endpoints but which can be in the middle 343 of a route. 345 For example, if a sensor network employs lower layer security and has 346 some gateway sensor node which is more capable and is periodically 347 connected to the Internet, we may use DTN security services to 348 protect messages between that gateway node and the other DTN sources 349 and destinations on the Internet-side of the gateway. In the case of 350 a confidentiality service, this is clearly useful since bundles which 351 leave the sensor network could be encrypted (by the gateway node) for 352 the final destination. In the case of say a software download, new 353 code might be integrity protected from the origin to the gateway 354 which is able to check some relevant white or black lists or use some 355 other software authorisation scheme which cannot practically be used 356 from a sensor node. 358 In order to define services which can be used in these ways we 359 distinguish between the sender of a bundle and the security-sender 360 for an application of one of these services. Similarly, we can 361 distinguish between the bundle recipient and the security-recipient 362 (or security-destination) for a given application of a security 363 service. Basically, the security-sender is the DTN node that applied 364 the security service, and the security-recipient (or security- 365 destination) is the DTN node which is the target for the security 366 service - say the node expected to decrypt or do integrity checking. 368 The extent to which the various security services can be combined for 369 the same or different security senders and destinations needs to be 370 made clear in the relevant protocol definition. However, this should 371 be kept as simple as possible since unwanted complexity is highly 372 likely to make a DTN harder to manage, and thereby less secure. 374 Experience with fragmentation issues has shown that there is good 375 reason to distinguish (at the protocol field level) between uses of 376 these services which are intended to be hop-by-hop (i.e. between this 377 and the next DTN node), as opposed to end-to-end, at least for 378 integrity checking. Equally, a protocol might not need to make this 379 distinction and might only define e.g. one confidentiality service 380 which can be applied multiple times for a single bundle with 381 different combinations of security-sender and security-recipient. 383 There is another example in which DTN security services differ from 384 more "normal" network security services. (Indeed this mode of 385 operation might be useful in non-DTNs too!). When a message is 386 authenticated using a digital signature, in principle any network 387 element on the path can do some checking of that signature. If the 388 message contains sufficient information (the supposed signer's public 389 key or a resolvable reference thereto) then any node can at least 390 check the cryptographic correctness of the signature. 392 Although useful, this is typically insufficient to decide how to 393 process the message, since in many environments basically anyone 394 could insert a public key and a signature, producing a message which 395 passes this test. In most real cases, there are some additional 396 checks that the signer is authorised, either explicitly by checking 397 that the signer's name or key is authorised for the purpose, or 398 implicitly by using a PKI (e.g. via an extended key usage extension). 399 It turns out that all practical ways to perform such authorisation 400 checks are problematic in some DTN cases due either to the lack of an 401 authorisation server (e.g. due to latency to/from from the verifier 402 to the relevant authorisation server) or to restricted node 403 capabilities, such as the case of a sensor node. 405 In such cases, it may be sensible for some "bastion" node along the 406 route to do the authorisation check and then to (again explicitly or 407 implicitly) attest that the authorisation test has passed. 408 Subsequent nodes, may however, for either data integrity or 409 accountability reasons wish to also validate the cryptographic 410 correctness of the signature. The end result might be a mechanism 411 whereby the message has a signature plus some meta-data which are 412 fully processed by the "bastion" node, whereas the signature is only 413 partly processed by all subsequent nodes. (Note: The role of the 414 "security-destination" concept in such cases is not yet clear.) 416 These issues are not addressed by the current series of DTN 417 specfications and it is likely that a new document [10] will be 418 required to deal with them. 420 3.2. Confidentiality and integrity 422 Since most protocol designs use common elements to deal with all 423 cryptographic based security services and mechanisms, they will all 424 be dealt with in this section. 426 DTN protocols should provide a means to encrypt protocol elements so 427 that messages in transit cannot practically be read. The bundle 428 protocol itself provides no confidentiality for the source or 429 destination endpoint addresses, or any other endpoints included in 430 the dictionary. This can be achieved using bundle-in-bundle 431 encapsulation (BiB) if necessary. 433 Clearly, calling for a confidentiality service implies a need for key 434 management. However, DTN key management remains an open issue, so we 435 presently expect DTN protocols to support pre-shared-keys (and/or 436 known irrevocable certificates). 438 Similarly, DTN protocols should provide a means to apply an integrity 439 check to a bundle so that the identity of the security-sender can be 440 established and changes in sensitive parts of the message can be 441 detected. The bundle authentication block (BAB) and payload security 442 block (PSB) have been specified to provide these services on a hop- 443 by-hop and end-to-end basis respectively. Again, this implies a need 444 for key management which is not met so far. 446 Clearly a protocol should allow a fairly flexible combination of 447 applications of the confidentiality and integrity services, though 448 hopefully disallowing insecure combinations (e.g. a plaintext 449 signature which is out of scope of a confidentiality service allowing 450 plaintext guesses to be verified). 452 These services should allow sensible combinations of a range of 453 standard cryptographic algorithms to be used and should also allow 454 changes to be made over time to the set of acceptable algorithms. 456 3.3. Policy based routing 458 Since the DTN, as a piece of infrastructure, may be quite fragile, we 459 require protocols to be cautious regarding their consumption of 460 network resources. 462 We require that DTN protocols and implementations support mechanisms 463 for policy-based routing. In other words each DTN protocol 464 specification should state the security-relevant policy variables 465 upon which routing and forwarding decisions can be made. While this 466 is still a little vague, the expectation is that each DTN 467 specification should, in its security considerations text, say which 468 security issues may exist which require a routing or forwarding 469 policy decision to be made. 471 In particular, since forwarding even a single bundle will consume 472 some network resources, every DTN node must implicitly incorporate 473 some element of policy-based routing. We do not expect that every 474 DTN node will be able to handle complex policy decisions. A DTN node 475 can be programmed to forward all bundles received in a deterministic 476 manner, (e.g. flooding the bundle to all peers other than then one 477 from which it was received). Even such a simple minded node is 478 however, implicitly implementing a policy - in this case a simple 479 flooding policy. So, though we require all nodes to implement some 480 policy, that policy can be very simple. 482 Regardless of how simple or complex a node's support for policy based 483 routing/forwarding might be, DTN implementers should document the 484 relevant aspects of the implementation. In the absence of such 485 documentation a node might be deployed in an inappropriate context, 486 potentially damaging an entire network. 488 Some DTN nodes will however be on boundaries of various sorts, 489 whether they be network topology related, administrative, networking 490 technology related or simply a case where this node is the first 491 which is capable of handling complex policy decisions. At one stage 492 these nodes were termed security policy routers, and were considered 493 to be "special" nodes. Our current view though, is that all nodes 494 are in fact policy routers with some implementing policies which are 495 more complex than others. 497 All nodes implement policy to some extent but not all will be 498 security-aware. Setting a security-destination other than the bundle 499 destination imposes a routing requirement which is expressed only in 500 security extension blocks. Some nodes will be unable to process 501 these and might route bundles to their destination bypassing the 502 security-destination(s). The result would be that the bundle 503 integrity cannot be verified or that the payload is unreadable 504 because it had not been decrypted at the security-destination. 506 We do not, at this stage, require that there be an interoperable way 507 to transfer policy settings between DTN nodes. Such a system could 508 perhaps be developed (though it is an extremely complex task), but 509 pragmatically, for now we consider the development of a DTN specific 510 policy language and distribution framework out of scope. 512 DTNs themselves do not appear to generate many new types of policy 513 based controls - the usual ingress, egress and forwarding types of 514 control can all be applied in DTNs. For example, some "bastion" node 515 might insist that all inbound bundles be authenticated and might add 516 an authentication element to all outbound elements. So all the usual 517 forms of control can, and should be, available for use in DTN nodes. 519 The DTN specific policy controls identified thus far, and for which 520 we would recommend support include: 522 - time-to-live (TTL) type controls where we consider the amount of 523 time for which a bundle has been "in-flight" 525 - controls to do with "strange" routes, such as those that loop 527 - controls handling local or global information about resource 528 constraints in the DTN (e.g. knowledge of a peer's storage 529 capacity) 531 - controls related to special types of fragmentation (e.g. reactive 532 fragmentation) which are defined in a DTN 534 No doubt, more will be identified as DTN implementation and 535 deployment experience is gained. 537 DTN node implementations will also be required to control access to 538 whatever DTN interface they provide so that only authorized entities 539 can act as the source (or destination) of bundles. Clearly this 540 aspect of access control is an implementation, rather than a protocol 541 issue. 543 It must be noted that policy based routing, if not deployed 544 appropriately, may inadvertently create bundle "sinkholes". Consider 545 the case in which a bundle is fragmented and one fragment of the 546 bundle reaches a router whose policy requires it to see the entire 547 bundle. All fragments of that bundle must also pass through that 548 same router and, if they do not, then eventually the fragment at our 549 paranoid router will expire. Ultimately the entire bundle never 550 arrives at the intended destination. This is clearly a case to avoid 551 - doing so, may be difficult to arrange without good route control. 553 4. Security Design considerations 555 This section discusses some of the security design considerations 556 used during the development of the DTN security mechanisms 558 4.1. Only DTN-friendly schemes need apply 560 The high round-trip times and frequent and unpredictable 561 disconnections that are characteristic of DTNs mean that security 562 solutions which depend on ubiquitous online security services cannot 563 generally be applied. Therefore solutions requiring ubiquitous 564 access to servers (e.g. Kerberos, XKMS) are problematic. This is 565 more-or-less analogous to the way that TCP won't work in DTNs. Such 566 solutions might be usable from a range of DTN nodes within some 567 security domain, although in that case what happens when a route 568 spans more than one such domain remains to be researched. 570 The long delays that may be inherent in DTNs mean that data may be 571 valid (even in-transit) for days or weeks, so depending on message 572 expiration alone to rid the network of unwanted messages will also be 573 problematic. How long is "too long" and how short is "too short", 574 and how well are the clocks synchronized? 576 The impact of this design consideration most obviously applies to key 577 management, but it will also apply to other aspects of security 578 including distribution of new policy settings. 580 4.2. TLS is a good model 582 The Transport Layer Security (TLS) specification [11] provides us 583 with some useful design ideas, especially in its use of 584 "ciphersuites". In TLS, a ciphersuite is a single number that 585 defines how all of the various cryptographic algorithms are to be 586 used. The ciphersuite number is used in TLS negotiation. One of the 587 more common ciphersuites is usually called 588 "TLS_RSA_WITH_3DES_EDE_CBC_SHA" indicating that the TLS protocol is 589 being used with RSA based key transport and with a variant of triple- 590 DES as its bulk encryption algorithm and SHA-1 for various digesting 591 tasks. 593 DTN can use a ciphersuite value in the same way - to indicate which 594 cryptographic algorithms are in use for what purpose. This is how we 595 can support both symmetric and asymmetric mechanisms for our 596 cryptographic security services, and also allows us to extend DTN 597 security in the future (e.g. use of identity based cryptography 598 schemes). 600 In DTNs, we won't be doing negotiations of the sort done in TLS that 601 require multiple round-trips, but we can still use the ciphersuite 602 idea. In fact, we extend it a little more to use the ciphersuite to 603 also indicate which services are being applied (integrity or 604 confidentiality) and also the set of input bits for the service. In 605 this way we can distinguish between an integrity service which only 606 protects the blocks from one that also protects the payload. 608 The DTN concept of ciphersuite also encompasses the idea of having 609 different parts of the bundle protected by the relevant security 610 service, as described in the next section. 612 4.3. Fragmentation 614 Fragmentation of a bundle is one of the more difficult DTN problems. 615 There are many scenarios and what may work well for some may be 616 useless for others. The two major issues are: 618 - some DTN networks may have extraordinary long propagation delays, 619 which may look more like two one-way links 621 - the bundle payload is a single block and not a sequence of packets 623 The one-way-link issue is a severe handicap to the sending node, as 624 it has little or no feedback on the progress or status of the 625 transmission. Cooperation between the sender and receiver is 626 difficult or impossible. 628 The payload is a single block but it can be split into smaller pieces 629 as long as each becomes its own bundle, sometimes called a "fragment 630 bundle". These are treated individualy after the fragmentation event 631 and can be sent separately to the destination, and with varying 632 levels of security depending upon the paths taken. 634 Fragmentation in DTN can happen in two ways. "Proactive 635 fragmentation" is the deliberate action of a node, which has an 636 entire bundle, to break it into smaller pieces. So-called "reactive 637 fragmentation" is where we try to optimize retransmission after a 638 connection failure of some kind. It assumes some level of 639 interaction between the sender and receiver, so that the sender can 640 restart from the point of failure or thereabouts. In this way, even 641 very large bundles can be sent across intermittent or episodic links, 642 piece by piece, and the fragments reassembled later. 644 Proactive fragmentation is reasonably interoperable with security 645 processing but reactive fragmentation does not work well. As an 646 example, consider the case of a node that has received the first 10 647 MB of a 20 MB bundle when the link fails and cannot be recovered by 648 the underlying transport layer. The node has to decide whether to 649 forward the 10 MB fragment as a fragment-bundle. However, it cannot 650 be integrity checked since not all bytes are present, which clearly 651 is a breach of integrity. 653 The receiving node might request the sender to create and send a 654 signature for the amount received, which would be faster than a 655 complete bundle retransmission. The first fragment with its 656 integrity check could be forwarded, and the original sender could 657 create another fragment-bundle containing the remainder of the 658 initial bundle data. This approach presupposes a high level of 659 coordination, and also that a suitable link can be reestablished. 661 An alternative discussed for handling this is to associate a number 662 of checksums with the bundle - say one for every 100k in this case, 663 so that the entire bundle would use 20 checksums to provide end-to- 664 end integrity. If the reactively forwarded fragment has the first 10 665 checksums its integrity can be checked. This comes at the expense of 666 complexity and additional bytes of overhead (in this case perhaps 400 667 or more bytes), so it won't be desirable in most cases. Since each 668 checksum protects a part of the payload, this scheme has been 669 referred to as the "toilet paper" scheme - each forwardable fragment 670 consisting of a number of sheets of payload-paper with its associated 671 checksum. In order to support this type of fragmentation, we would 672 have to define the relevant toilet paper ciphersuites in the security 673 protocol specification. (At the time of writing, hopefully these 674 schemes can be deprecated since they are clumsy and overly-complex 675 for the benefit achieved.) 677 In summary the DTN concept of ciphersuite is borrowed from TLS and 678 slightly extended to allow different parts of the bundle to be 679 protected by the relevant security service. However, in general DTNs 680 cannot support the use of the TLS handshake protocol as used in the 681 terrestrial Internet. 683 One additional problem has recently become apparent and is currently 684 under investigation. Various actions change the payload and the 685 specific problem is that the payload length changes when encrypted 686 using a block-mode cipher. This creates ambiguity for custody- 687 transfer and for fragment-reassembly. 689 4.4. Naming and identities 691 Most security mechanisms work well with only certain kinds of 692 identity. For example, Kerberos style security tends to go with 693 domain-specific login names, PKI tends to work best with X.500 or 694 LDAP-style names, and to a lesser extent with RFC822 addresses. In 695 bundles, endpoint identifiers are represented as URIs. However, 696 there is no well-defined URI scheme specifically required to be 697 supported. As a result, there is work to be done to map URIs to the 698 types of identity which are easily supported by whatever mechanisms 699 being considered. 701 In LTP, identities are flat octet strings, so again there is work to 702 be done to map from these to e.g. user identities in a specific 703 security mechanism. 705 4.5. Placement of checksums 707 As currently specified, the bundle protocol requires that the last 708 block in the bundle be identified as such by setting its "Last block" 709 block processing flag. This bit enables security blocks to be placed 710 either before or after the bundle payload block. The ability to 711 place a signature after the bundle payload block, at the end of the 712 bundle, is important for integrity-protecting some bundles at nodes 713 that have limited buffer space. For example, if a node wishes to 714 sign a 10Mb bundle, but it only has 1Mb of usable buffer, then 715 creating a digital signature over the 10Mb and sending that out 716 before the end of the payload is simply impossible. 718 However, due to the properties of most hash functions, were the 719 signature to be placed at the end of the bundle, then such a 720 constrained node could in fact send out the signed bundle. This is 721 due to the fact that hash functions have a continuation property 722 which allows the to-be-hashed data to be fed through the function in 723 blocks with only a small amount of state information required to be 724 stored. 726 For this reason, DTN security protocols have the option of placing 727 either a single block in the message or placing correlated blocks in 728 the message, for example one at the start of the message which 729 specifies the signature/hashing to be used (the ciphersuite in our 730 case), and one (that contains the actual signature or MAC) at the end 731 of the entire bundle. The ability to place such correlated security 732 blocks in the message allows even very memory-constrained nodes to be 733 able to process the bundle and verify its security result. 735 4.6. Hop-by-hop-ish-ness 737 In the above we discussed how security services can be applied which 738 are not "truly" end-to-end. In the limit of course, we can use such 739 a scheme to apply security just between this DTN node and the next 740 hop. In particular there is clearly benefit in many cases from 741 applying integrity checks on such a hop-by-hop basis. 743 There are two things worth noting about this particular case: 745 - Even though the protocol data units involved in end-to-end-ish and 746 hop-by-hop-ish applications of security services may be almost 747 identical, there may be benefit in artificially distinguishing 748 between them since one could imagine many nodes which would only 749 ever require (and thus properly support) hop-by-hop security. In 750 fact, one could reasonably define ciphersuites which are only 751 useful in such a hop-by-hop fashion. 753 - There doesn't seem to be much interest in making such an 754 artificial distinction for confidentiality services, perhaps since 755 the ability to use lower layer security is presumed to be much 756 more common when the DTN nodes are "close" like this. 758 In any case, the current version of the bundle security protocol does 759 use different blocks for hop-by-hop vs. end-to-end integrity. 761 5. Open Issues 763 This section discusses some of the issues which are still very open, 764 either due to a lack of consensus in the DTNRG, or due to there being 765 areas (like DTN key management) where much basic research remains to 766 be done. 768 Where an issue has been discussed previously (e.g. source 769 confidentiality), we will not include it here again. 771 5.1. Key management 773 The major open issue in DTN security is the lack of a delay-tolerant 774 method for key management. We are at the stage where we only really 775 know how to use existing schemes, which ultimately require an on-line 776 status checking service or key distribution service which is not 777 practical in a high delay or highly disrupted environment. 779 Note that even though some identity based cryptography (IBC) schemes 780 superficially appear to solve this problem (once we assume that the 781 originator has a name for the destination endpoint), this is in fact 782 not the case. The problem is that current IBC schemes effectively 783 act only as a kind of "group certificate" where all of the nodes 784 using a given private key generator can use a single "certificate", 785 but the problem of validity for that "certificate" (which will 786 contain the generator's parameters) is the same problem as verifying 787 a CA certificate in a standard PKI. 789 So, the only generally applicable schemes we currently have are 790 basically equivalent to shared secrets or else irrevocable public key 791 (or certificate based) schemes. Clearly, this is an area where more 792 research work could produce interesting results. 794 5.2. Handling replays 796 In most networking scenarios, we either wish to eliminate or else 797 dramatically reduce the probability of messages being replayed. In 798 some DTN contexts this will also be the case - particularly as 799 replaying a (e.g. authenticated, authorized) message can be a fairly 800 straightforward way to consume scarce network resources. 802 However, there are also DTN scenarios where we wish to deliberately 803 replay messages, even to the extent of routing messages around a 804 loop. For example, if Bob is willing to act as a data mule for 805 Alice, who has limited storage, then Bob might pick up a bundle as he 806 passes Alice on his outbound journey from his Internet-connected home 807 location. As he goes on however, Bob also runs into storage 808 problems, so he temporarily deposits the bundle with Charlie, who 809 he's passing now, and who he'll also pass on his way back home, in 810 say, a week's time. After a week, Bob indeed passes Charlie again 811 and picks up that bundle for the second time, after which he goes on 812 to successfully deliver the bundle via the Internet-connected node at 813 home. Now in this scenario, the same bundle is received by Bob 814 twice, and so would likely trigger any replay detection algorithm 815 that Bob is running, but of course, the behavior as described is 816 nominal for the circumstances presented. 818 In addition, there are some routing schemes which involve duplicating 819 messages. For example, a node might flood all its peers with a copy 820 of a message to increase the probability that it will arrive at the 821 destination before it expires. Clearly such routing schemes are 822 likely to result in nodes seeing the same message more than once, but 823 it's not clear whether any such node would be correct to delete such 824 apparent "duplicates". 826 The element of delay in DTNs also complicates handling replays. 827 Replay detection schemes generally depend on noting some unique 828 aspect of messages (via digesting of some message fields) and then 829 keeping a list of (the digests of) recently seen messages. The 830 problem in the DTN context is the "recently seen" part of such replay 831 detection algorithms, since maintaining a list for say 30 days would 832 be fairly resource intensive, but might be required if latencies are 833 of that size. So the most obvious ways to protect against replays 834 are problematic. 836 The result is that the extent to which we can, or should, define a 837 generic DTN replay detection scheme is hard to determine and at this 838 point remains an open DTN security issue. It may be that this means 839 that schemes need to be specified as part of a bundle routing 840 algorithm. 842 One aspect of replay handling where security can be enforced is 843 setting the final destination bundle node to deliver each bundle only 844 once to its application. In this way, even though replays can 845 consume network resources, they are less likely cause application 846 layer damage. An example of such damage would be a protocol which 847 used a bundle to represent "Move the telescope 10 degrees left" - 848 repeated replays of this message could result in damage if the 849 telescope is pointed at the Sun. Of course, the application layer in 850 this case ought also be detecting replays, e.g. by including a 851 command number, but the example does demonstrate the point. 853 Additional discussion relevant to at-most-once-delivery and a way to 854 handle intentional resending of a bundle can be found in the DTN 855 Retransmission Block specification [12]. 857 5.3. Traffic analysis 859 We do not currently define any security services for protecting 860 against traffic analysis. A general traffic analysis protection 861 scheme is probably not, in any case, a realistic goal for DTNs, given 862 their tendency to be resource-scarce and there have been no calls for 863 a generic approach to this problem. However, for some disruption 864 tolerant networks, hiding traffic (e.g. the existence of a signal 865 from a sensor net) may be a very important security requirement. 867 So, the first open issue here is the extent to which there is a real 868 need for a generic scheme for protection against traffic analysis. 869 If there were, then the second open issue is how to define such a 870 scheme to be delay and disruption tolerant and which also doesn't 871 consume too many resources. 873 Finally, traffic analysis protection may be left as a local matter 874 for the underlying network layers, e.g. if a particular radio link 875 were of concern, then total obscuration of that link may be required, 876 and may in fact be the only way to hide such radio traffic. 878 5.4. Routing protocol security 880 Clearly whenever DTN routing protocols are defined they will 881 introduce new security requirements, or at least change the emphasis 882 to be properly placed on meeting the various requirements posited 883 above. For example, one could expect that a robust and scalable 884 origin-authentication scheme would become more important. 886 At the time of writing there are no well-documented DTN routing 887 protocols, so DTN routing protocol security must clearly be in our 888 list of open issues. However, if a putative DTN routing protocol 889 were to use either the Bundle protocol or LTP, it could clearly make 890 use of their existing security features. 892 5.5. Multicast security 894 In a DTN, bundles are sent to destination endpoints, and any given 895 endpoint consists of a set of zero or more bundle nodes. A bundle 896 that is sent to a given destination endpoint must be sent to all of 897 the nodes that are in the minimum reception group of that endpoint. 898 If an endpoint may contain multiple nodes and its minimum reception 899 group is all of the nodes registered in that endpoint, then a bundle 900 sent to that endpoint is functionally similar to "multicast" 901 operations in the Internet. If an endpoint may contain multiple 902 nodes and its minimum reception group is any given number of the 903 nodes registered in that endpoint, then a bundle sent to that 904 endpoint is functionally similar to "anycast" operations in the 905 Internet. Extensions to the bundle protocol for providing custodial 906 transfer of bundles sent to multicast endpoints have been defined in 907 [13]. 909 Within DTN, there is currently no mechanism defined for restricting 910 which nodes may register in a "multicast" or "anycast" endpoint. The 911 security architecture currently does not address the security aspects 912 of enabling a node to register with a particular mutlicast or anycast 913 EID. Without a capability to restrict the registration of nodes in 914 multicast or anycast endpoints, any node may register in such an 915 endpoint and thereby receive traffic sent to that endpoint. In 916 addition, even though an endpoint may be a singleton endpoint, 917 meaning that it is not permitted to contain more than one node, it 918 may be possible for a second (or more) node to register in a 919 singleton endpoint and receive bundles that are sent to that endpoint 920 if the bundles are routed in such a way that they are forwarded to 921 that node (e.g. using flood routing). 923 The mandatory end-to-end(ish) confidentiality and authentication 924 ciphersuites that are defined in the Bundle Security Protocol require 925 that all destination nodes use the same key material to decrypt and 926 authenticate the received bundle. Modifications to the mandatory 927 end-to-end(ish) ciphersuites or additional ciphersuites would need to 928 be defined to provide the possibility that a bundle could be 929 encrypted or authenticated differently for different nodes in its 930 multicast or anycast endpoint. 932 In addition, there are some new aspects to multicast endpoint 933 membership security, given that most work to date has implicitly 934 assumed that the signaling traffic (e.g. registering in the multicast 935 endpoint) can occur in more-or-less "real" time. In a DTN, 936 registering in a multicast endpoint may be more akin to signing up to 937 a mailing list, so that bundles that originated before the 938 registration occurred may be received afterwards. In principle, such 939 a late registering node might get sent the entire mailing list 940 archive either by design or in error. Even if some sort of mechanism 941 to authenticate registering nodes were to be defined, there are still 942 issues that arise out of the fact that the endpoint registration 943 process may itself be lengthy. For example, if a registering node 944 authenticates with some credential that has a notBefore time of 945 January 1, 2007 (as an X.509 public key certificate might have), and 946 some bundle created before that time is still to be delivered, should 947 the notBefore time of the credential be part of the decision as to 948 whether to route a given bundle to the registering node? In this 949 case, probably the answer is "no", but in some contexts that could be 950 the wrong answer, allowing new (cheap) identities access to old 951 (expensively accrued) materials. 953 5.6. Performance Issues 955 Provision of security within a DTN imposes both bandwidth utilization 956 costs on the DTN links and computational costs on the DTN nodes. 958 The provision of DTN security will consume additional bandwidth. The 959 amount consumed depends on the way optional parameters are encoded, 960 or not, and on thecryptographic algorithms used. In addition, if 961 more than one security service is used for the same bundle (e.g. a 962 MAC to be removed by the next hop and a signature for the final 963 destination) more of the possibly limited amount of bandwidth 964 available for security purposes will be used. 966 The use of DTN security also imposes computational costs on DTN 967 nodes. There may be limits regarding how much CPU can be devoted to 968 security and the amount of computation will depend on the algorithms 969 used and their parameters. 971 6. Security Considerations 973 Since this entire document is an informative description of how the 974 DTNRG are approaching security, there is little to say in this 975 section. 977 However, implementers of DTN protocols must not take text here to be 978 normative, in the case of conflict the relevant protocol 979 specification takes precedence. 981 7. IANA Considerations 983 None. 985 8. Informative References 987 [1] Cerf, V., Burleigh, S., Durst, R., Fall, K., Hooke, A., Scott, 988 K., Torgerson, L., and H. Weiss, "Delay-Tolerant Network 989 Architecture", RFC 4838, April 2007. 991 [2] Scott, K. and S. Burleigh, "Bundle Protocol Specification", 992 RFC 5050, November 2007. 994 [3] Symington, S., Farrell, S., Weiss, H., and P. Lovell, "Bundle 995 Security Protocol Specification", 996 draft-irtf-dtnrg-bundle-security-05.txt, work-in-progress, 997 February 2008. 999 [4] Warthman, F., "Delay-Tolerant Networks (DTNs) A Tutorial", 1000 http://www.dtnrg.org/ , March 2003. 1002 [5] Durst, R., "An Infrastructure Security Model for Delay Tolerant 1003 Networks", http://www.dtnrg.org/ , July 2002. 1005 [6] Ramadas, M., Burleigh, S., and S. Farrell, "Licklider 1006 Transmission Protocol", 1007 draft-irtf-dtnrg-ltp-09.txt, work-in-progress, January 2008. 1009 [7] Farrell, S., Ramadas, M., and S. Burleigh, "Licklider 1010 Transmission Protocol - Extensions", 1011 draft-irtf-dtnrg-ltp-extensions-06.txt, work-in-progress, 1012 October 2007. 1014 [8] Burleigh, S., Ramadas, M., and S. Farrell, "Licklider 1015 Transmission Protocol - Motivation", 1016 draft-irtf-dtnrg-ltp-motivation-05.txt, work-in-progress, 1017 October 2007. 1019 [9] Zhou, L. and Z. Haas, "Securing Ad-Hoc Networks", IEEE 1020 network vol 13, no. 6, Nov-Dec 1999, pp 24-30. 1022 [10] Farrell, S., "DTN Authentication, Authorization and 1023 Accounting", 1024 draft-irtf-dtnrg-bundle-aaa.-00.txt, work-in-progress. 1026 [11] Dierks, T. and E. Rescorla, "The TLS Protocol - Version 1.1", 1027 RFC 4346 , April 2006. 1029 [12] Symington, S., "Delay-Tolerant Network Retransmission Block", 1030 draft-irtf-dtnrg-bundle-retrans-00.txt, work-in-progress, 1031 April 2007. 1033 [13] Symington, S., "Delay-Tolerant Network Multicast Custodial 1034 Transfer", draft-irtf-dtnrg-bundle-multicast-custodial- 1035 00.txt, work-in-progress, May 2007. 1037 Authors' Addresses 1039 Stephen Farrell 1040 Trinity College Dublin 1041 Distributed Systems Group 1042 Department of Computer Science 1043 Trinity College 1044 Dublin 1045 Ireland 1047 Phone: +353-1-608-1539 1048 Email: stephen.farrell@cs.tcd.ie 1050 Susan Flynn Symington 1051 The MITRE Corporation 1052 7515 Colshire Drive 1053 McLean, VA 22102 1054 US 1056 Phone: 703 983 7209 1057 Email: susan@mitre.org 1058 URI: http://mitre.org/ 1060 Howard Weiss 1061 SPARTA, Inc. 1062 7110 Samuel Morse Drive 1063 Columbia, MD 21046 1064 US 1066 Phone: +1-443-430-8089 1067 Email: hsw@sparta.com 1069 Peter Lovell 1070 SPARTA, Inc. 1071 7110 Samuel Morse Drive 1072 Columbia, MD 21046 1073 US 1075 Phone: +1-443-430-8052 1076 Email: peter.lovell@sparta.com 1078 Full Copyright Statement 1080 Copyright (C) The IETF Trust (2008). 1082 This document is subject to the rights, licenses and restrictions 1083 contained in BCP 78, and except as set forth therein, the authors 1084 retain all their rights. 1086 This document and the information contained herein are provided on an 1087 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1088 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1089 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1090 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1091 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1092 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1094 Intellectual Property 1096 The IETF takes no position regarding the validity or scope of any 1097 Intellectual Property Rights or other rights that might be claimed to 1098 pertain to the implementation or use of the technology described in 1099 this document or the extent to which any license under such rights 1100 might or might not be available; nor does it represent that it has 1101 made any independent effort to identify any such rights. Information 1102 on the procedures with respect to rights in RFC documents can be 1103 found in BCP 78 and BCP 79. 1105 Copies of IPR disclosures made to the IETF Secretariat and any 1106 assurances of licenses to be made available, or the result of an 1107 attempt made to obtain a general license or permission for the use of 1108 such proprietary rights by implementers or users of this 1109 specification can be obtained from the IETF on-line IPR repository at 1110 http://www.ietf.org/ipr. 1112 The IETF invites any interested party to bring to its attention any 1113 copyrights, patents or patent applications, or other proprietary 1114 rights that may cover technology that may be required to implement 1115 this standard. Please address the information to the IETF at 1116 ietf-ipr@ietf.org. 1118 Acknowledgment 1120 Funding for the RFC Editor function is provided by the IETF 1121 Administrative Support Activity (IASA).