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