idnits 2.17.1 draft-irtf-dtnrg-sec-overview-00.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 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 991. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 968. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 975. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 981. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. 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 RFC 3978 Section 5.4 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 (September 22, 2005) is 6791 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 (-08) exists of draft-irtf-dtnrg-arch-03 == Outdated reference: A later version (-10) exists of draft-irtf-dtnrg-bundle-spec-03 == Outdated reference: A later version (-19) exists of draft-irtf-dtnrg-bundle-security-00 == Outdated reference: A later version (-10) exists of draft-irtf-dtnrg-ltp-03 == Outdated reference: A later version (-10) exists of draft-irtf-dtnrg-ltp-03 -- Duplicate reference: draft-irtf-dtnrg-ltp, mentioned in '7', was also mentioned in '6'. == Outdated reference: A later version (-10) exists of draft-irtf-dtnrg-ltp-03 -- Duplicate reference: draft-irtf-dtnrg-ltp, mentioned in '8', was also mentioned in '7'. -- Obsolete informational reference (is this intentional?): RFC 2246 (ref. '10') (Obsoleted by RFC 4346) Summary: 3 errors (**), 0 flaws (~~), 8 warnings (==), 10 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: March 26, 2006 S. Symington 5 The MITRE Corporation 6 H. Weiss 7 SPARTA, Inc. 8 September 22, 2005 10 Delay-Tolerant Networking Security Overview 11 draft-irtf-dtnrg-sec-overview-00 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on March 26, 2006. 38 Copyright Notice 40 Copyright (C) The Internet Society (2005). 42 Abstract 44 This document provides an overview of the security requirements and 45 mechanisms considered for delay tolerant networking security. It 46 discusses the options for protecting such networks and describes 47 reasons why specific security mechanisms were (or were not) chosen 48 for the relevant protocols. The entire document is informative, 49 given it's purpose is mainly to document design decisions. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 1.1. This document . . . . . . . . . . . . . . . . . . . . . . 3 55 1.2. Background . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Threats . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 57 2.1. Non DTN node threats . . . . . . . . . . . . . . . . . . . 5 58 2.2. Resource consumption . . . . . . . . . . . . . . . . . . . 5 59 2.3. Denial of service . . . . . . . . . . . . . . . . . . . . 6 60 2.4. Confidentiality and integrity . . . . . . . . . . . . . . 6 61 2.5. Traffic storms . . . . . . . . . . . . . . . . . . . . . . 7 62 2.6. Partial protection is just that. . . . . . . . . . . . . . 7 63 3. Security Requirements . . . . . . . . . . . . . . . . . . . . 9 64 3.1. End-to-end-ish-ness . . . . . . . . . . . . . . . . . . . 9 65 3.2. Confidentiality and integrity . . . . . . . . . . . . . . 10 66 3.3. Policy based routing . . . . . . . . . . . . . . . . . . . 11 67 4. Security Design considerations . . . . . . . . . . . . . . . . 14 68 4.1. Only DTN-friendly schemes need apply . . . . . . . . . . . 14 69 4.2. TLS is a good model . . . . . . . . . . . . . . . . . . . 14 70 4.3. Naming and identities . . . . . . . . . . . . . . . . . . 15 71 4.4. Placement of checksums . . . . . . . . . . . . . . . . . . 16 72 4.5. Hop-by-hop-ish-ness . . . . . . . . . . . . . . . . . . . 16 73 5. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 18 74 5.1. Key management . . . . . . . . . . . . . . . . . . . . . . 18 75 5.2. Handling replays . . . . . . . . . . . . . . . . . . . . . 18 76 5.3. Traffic analysis . . . . . . . . . . . . . . . . . . . . . 20 77 5.4. Routing protocol security . . . . . . . . . . . . . . . . 20 78 5.5. Multicast security . . . . . . . . . . . . . . . . . . . . 20 79 5.6. Performance Issues . . . . . . . . . . . . . . . . . . . . 21 80 6. Security Considerations . . . . . . . . . . . . . . . . . . . 22 81 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 82 8. Informative References . . . . . . . . . . . . . . . . . . . . 23 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 84 Intellectual Property and Copyright Statements . . . . . . . . . . 25 86 1. Introduction 88 This section places this document in its current context as one of a 89 series of DTN documents. 91 1.1. This document 93 This document is a product of the IRTF (http://www.irtf.org/) Delay 94 Tolerant Networking Research Group (DTRNG) and is being discussed on 95 the dtn-security mailing list. See the DRNRG site 96 (http://www.dtnrg.org/) for details of the various DTN mailing lists. 98 The intent is for this document to present a snapshot of the security 99 analysis which has been carried out in the DTNRG. The document is 100 not normative in any sense but is intended to be a companion document 101 which explains further the reasons for the design choices which are 102 documented elsewhere. 104 The structure of the document is as follows: 106 We first present a selection of threats which were considered 107 during the analysis carried out so far. 109 We then present some security requirements derived from that 110 analysis or elsewhere. 112 We next present some of the design considerations which were 113 applied during the design of the security mechanisms. 115 And we finally discuss some of the remaining open issues in DTN 116 security. 118 Given that this is simply an informative snapshot document, none of 119 the above are intended to be exhaustive, nor should other documents 120 be criticised because something is mentioned here, but not countered 121 there. 123 While this document is being prepared in parallel with the various 124 protocol and security specifications, we will generally try not to 125 refer to the specific fields used in those documents since the 126 details may change and maintaining consistency at that level is not a 127 goal here. Where we do refer to such details, of course, the 128 specification documents are normative. 130 1.2. Background 132 The overall delay tolerant networking (DTN) architecture is described 133 in [1]. A DTN is an overlay network on top of multiple lower layer 134 networks, some of which may be challenged by limitations such as 135 intermittent loss of connectivity, long or variable delay, asymmetric 136 data rates, or high error rates. The purpose of a DTN protocol is to 137 support interoperability across such potentially stressed lower layer 138 networks. The DTN overlay network specifies a bundle protocol which 139 is layered on top of a so-called convergence layer, (probably on top 140 of even lower layers). The DTN Bundle Protocol [2] describes the 141 format of the messages (called bundles) passed between DTN bundle 142 agents that participate in bundle communications to form the DTN 143 store-and-forward overlay network. 145 The Bundle Security Protocol Specification [3] defines the integrity 146 and confidentiality mechanisms for use with the Bundle protocol 147 together with associated policy options. 149 Two other documents exists which are now somewhat outdated but remain 150 worthwhile reading: A tutorial [4] about DTNs generally and an early 151 DTN security model document [5]. 153 There is also a related lower layer protocol specifically designed 154 for very long delay environments, called the Licklider Transmission 155 Protocol (LTP), [6] and which is also being developed by the same 156 group. Even though the LTP protocol shares some security features 157 [7] with the bundle protocol, we will mainly reference the bundle 158 protocol here since its environment is much more complex and there is 159 also a separate LTP motivation document [8]. 161 In this document we may refer to messages to mean either a bundle 162 from the bundle protocol, or else a segment from the LTP protocol. 163 The context should make the meaning clear in each case. 165 2. Threats 167 This section describes some of the threats which were considered 168 during the process of designing the DTN security mechanisms. In this 169 discussion (and throughtout the document), we will try to highlight 170 DTN-specific aspects and generally assume the reader is familiar with 171 basic networking security concepts. 173 2.1. Non DTN node threats 175 The first set of threats to consider are those coming from network 176 elements which aren't directly part of the DTN. As an overlay 177 network, bundles may traverse multiple underlying network elements on 178 each DTN "hop". Of course, any vulnerability in the bundle protocol 179 can be exploited at any of those network elements. 181 DTN security must take into account the usual range of such potential 182 exploits (masquerading, bit flips etc.) but in contrast to most 183 network protocols, as an overlay protocol, the bundle protocol is 184 possibly an easier target. In particular if it is possible to insert 185 new bundles at such lower-layer "hops" then many DTN nodes will have 186 to be capable of countering such insertions by where possible, 187 detecting and quickly deleting such spurious bundles. 189 Conversely, it is equally possible to take advantage of lower layer 190 security services, but this won't be visible from the DTN layer, and 191 requires co-ordinated administration in order to be really effective. 193 2.2. Resource consumption 195 Due to the resource-scarcity that characterizes DTNs, unauthorized 196 access and use of DTN resources is a serious concern. Specifically, 197 the following consume DTN resources and can be considered as threats 198 against the DTN as an infrastructure: 200 1. access by unauthorized entities, 202 2. unauthorized applications controlling the DTN infrastructure, 204 3. authorized applications sending bundles at a rate or class of 205 service for which they lack permission, 207 4. modifying bundle content, 209 5. compromised network elements, be they DTN nodes or not. 211 In addition to these threats, DTN nodes can act to assist or amplify 212 such resource consuming behaviour as follows: 214 1. forwarding bundles that were not sent by authorized DTN nodes 216 2. generating reports which weren't originally requested (say if a 217 bundle has been modified). 219 3. not detecting unplanned replays or other mis-behaviours 221 2.3. Denial of service 223 In addition to the basic resource consumption threats mentioned above 224 there are also a range of denial of service (DoS) attacks which must 225 be considered in the DTN context. DTNs are in this respect, in more- 226 or-less the same position as other MANETs, so all the problems with 227 secure routing in ad-hoc networks [9] exist for many DTNs too! 229 While DoS attacks can be mounted at any layer, from physical to 230 application, generally when developing a new protocol we should be 231 attempting to do two things:- 233 Make it hard to launch an "off-path" DoS attacks by making it hard 234 to "guess" valid values for messages, e.g. through using random 235 values instead of counters for identifying messages. 237 Make it easier to withstand "on-path" DoS attacks, by providing a 238 way to choke-off DoS traffic, e.g. by changing to a mode of 239 operation where only fresh, authenticated messages are accepted 240 and all others are dropped. 242 In a DTN environment, the generally longer latencies involved will 243 probably act to make DoS attempts more effective, so protocol 244 developers and deployments should explicitly consider DoS at all 245 times. 247 As with all networks, security mechanisms will themselves create new 248 DoS opportunities so whatever services and mechanisms are defined for 249 DTN security should also explicitly consider DoS, e.g. mechanisms 250 which involve certificate status checking (via some protocol to a key 251 server) based on received messages create new DoS opportunities since 252 such lookups consume resources on both the receiving node and the key 253 server. 255 2.4. Confidentiality and integrity 257 In addition to the resource consuming threats, DTN applications can 258 also be vulnerable to the usual threats against confidentiality and 259 integrity, in particular the following: 261 1. falsifying a bundle's source, 263 2. changing the intended destination, 265 3. changing the bundle's control fields, 267 4. changing other header or payload fields, 269 5. replay of bundles 271 6. copying or disclosing bundle data as it passes 273 2.5. Traffic storms 275 So long as DTN protocols include traffic generated as an artifact of 276 other traffic, then the possibility exists that manipulation of 277 (genuine, forged or modified) bundle content can be used to create a 278 storm of unwanted traffic. Given a DTN operating sufficiently "close 279 to the wire", such traffic could have serious affects. 281 In particular, the current bundle protocol includes various messages 282 (bundle status reports and custody signals) which can be produced in 283 greater numbers than the original traffic. For example, if a DTN 284 node (or other network element) could modify a single "forwarding 285 report" such that the forwarding of that report bundle will generate 286 another bundle, and if the first bundles' forwarding report bit will 287 also be set, and if the route that these bundles will take includes a 288 loop, then an infinite bundle storm results. (Note: a requirement 289 that no report should generate another report would, modulo 290 implementation bugs, remove this threat. However, it may be wiser to 291 entirely remove some of these supposedly useful reporting 292 "capabilities".) 294 2.6. Partial protection is just that. 296 Some DTN nodes won't need to protect all parts of all bundles. Some 297 DTN nodes won't be able to properly protect the integrity of the 298 entire bundle including its payload. Potential reasons range from 299 lack of computing power to application (or lower) layer protection 300 applying integrity, with the result that there's no benefit in 301 repeating this work in the bundle layer. Alternatively, some DTN 302 nodes may choose not to protect all parts of all bundles in return 303 for being able to perform reactive fragmentation. 305 There are also cases where bundle headers should be modified in 306 transit (e.g. the dictionary header in some versions of the bundle 307 protocol), or a "via" header which captures the route a bundle has 308 followed, so that integrity checking on anything more than a hop-by- 309 hop basis becomes unwieldy since the to-be-protected bytes are a 310 moving target. 312 The result is that it is possible that some fields of a bundle are 313 strongly protected whilst others are effectively unprotected. 314 Whenever such a situation occurs then it will be possible for network 315 elements to at least use the bundle protocol as a communications 316 channel, perhaps covert or perhaps overt. Where such misuse is a 317 concern, then the DTN should either use different security options 318 which do cover the fields of concern, or else administrators (if they 319 exist!) must ensure that the bundles only traverse lower layers where 320 the probability of such misuse is sufficiently small. 322 3. Security Requirements 324 This section lists some of the security requirements which were 325 agreed as priorities during the development of the DTN security 326 mechanisms. 328 3.1. End-to-end-ish-ness 330 Traditionally, protocols tend to provide security services which are 331 used either (or both) on a hop-by-hop or end-to-end basis. For DTN 332 security though, we require that these services be usable also 333 between nodes which are not endpoints, but which can be in the middle 334 of a route. 336 For example, if a sensor network uses some satisfactory lower layer 337 security, and has some gateway sensor node, which is more capable and 338 also say periodically connected to the Internet, then we may wish to 339 use DTN security services to protect messages between that gateway 340 node and the other DTN sources and destinations on the Internet-side 341 of the gateway. In the case of a confidentiality service, this is 342 clearly useful since bundles which leave the sensor network could be 343 encrypted (by the gateway node) for the final destination. In the 344 case of say a software download, new code might be integrity 345 protected from the origin to the gateway which is able to check some 346 relevant white or black lists or use some other software 347 authorisation scheme which cannot practically be used from a sensor 348 node. 350 In order to define services which can be used in these ways we 351 distinguish between the sender of a bundle and the security-sender 352 for an application of one of these services. Similarly, we can 353 distinguish between the bundle recipient and the security-recipient 354 (or security-destination) for a given application of a security 355 service. Basically, the security-sender is the DTN node that applied 356 the security service, and the security-recipient (or security- 357 destination) is the DTN node which is the target for the security 358 service - say the node expected to decrypt or do integrity checking. 360 The extent to which the various services can be combined for the 361 same, or different security senders and destinations is something 362 which has to be made clear in the relevant protocol definition. 363 However, we can state a requirement that this should be kept as 364 simple as possible since unwanted complexity in this respect is 365 highly likely to make a DTN harder to manage, and thus less secure. 367 Having said that, there may still be good reason to distinguish (at 368 the protocol field level) between uses of these services which are 369 intended to be hop-by-hop (i.e. between this and the next DTN node), 370 as opposed to uses of these services which are more intended to be 371 applied across multiple nodes. Equally, a protocol might not need to 372 make this distinction and might only define e.g. one confidentiality 373 service which can be applied multiple times for a single bundle with 374 different combinations of security-sender and security-recipient. 376 There is one more example of the ways in which DTN security services 377 seem to differ from more "normal" network security services, that is 378 worth mentioning here. (Indeed this mode of operation might be 379 useful in non-DTNs too!). When a message is authenticated using a 380 digital signature, then in principle any network element on the path 381 can do some checking of that signature. If the message contains 382 sufficient information (the supposed signer's public key or a 383 resolvable reference thereto) then any node can at least check the 384 cryptographic correctness of the signature. 386 However, this is typically insufficient to decide how to process the 387 message, since in many environments basically anyone could insert a 388 public key and a signature thus producing a message which passes this 389 test. So in most real cases, there is some additional check that the 390 signer is authorised, either explicitly by checking the signer's name 391 or key is authorised for the purpose, or else implicitly by for 392 example using a PKI for this purpose (say via an extended key usage 393 extension). It turns out that all practical ways to perform this 394 authorisation check are problematic in at least some DTN cases, 395 either due to the lack of availability of an authorisation server 396 (say due to simple latency back from the verifier to the relevant 397 authorisation server) or due to restricted node capabilities (say in 398 the case of a sensor node). 400 In such cases, it may be sensible for some "bastion" node along the 401 route to do the authorisation check and then to (again explicitly or 402 implicitly) attest that the authorisation test has passed. 403 Subsequent nodes, may however, for either data integrity or 404 accountability reasons wish to also validate the cryptographic 405 correctness of the signature. The end result might be a mechanism 406 whereby the message has a signature plus some meta-data which are 407 fully processed by the "bastion" node, whereas the signature is only 408 partly processed by all subsequent nodes. (Note: The role of the 409 "security-destination" concept in such cases is not yet clear.) 411 3.2. Confidentiality and integrity 413 Since most protocol designs use common elements to deal with all 414 cryptographic based security services and mechanisms, we will deal 415 with all of these in this section. 417 DTN protocols should provide a way to encrypt protocol elements so 418 that messages in transit cannot practically be read. The extent to 419 which a confidentiality service should be able to be applied to any 420 or all protocol elements is a somewhat open issue. In particular, 421 whether or not source confidentiality should be provided is still 422 under discussion. Clearly, calling for a confidentiality service 423 implies a need for key management. However, a proper DTN key 424 management scheme is still an open issue, so we would expect DTN 425 protocols, to support pre-shared-keys (and/or known irrevocable 426 certificates) in the meantime. 428 Similarly, DTN protocols should provide a way to apply an integrity 429 check to a message so that the identity of the security-sender can be 430 established and so that changes in sensitive parts of the message can 431 be detected. Again, this implies a need for key management which is 432 not, so far, really met. 434 Clearly a protocol should allow for fairly flexible combinations of 435 applications of the confidentiality and integrity services, though 436 hopefully disallowing insecure combinations e.g. a plaintext 437 signature which is out of scope of a confidentiality service allows 438 plaintext guesses to be verified. 440 However these services are provided they should allow for sensible 441 combinations of a range of standard cryptographic algorithms to be 442 used and should also allow for changes to the set of acceptable 443 algorithms to be made over time. 445 3.3. Policy based routing 447 Since the DTN, as a piece of infrastructure, may be quite fragile, we 448 require protocols to be cautious in how they consume network 449 resources. While the intent of this is fairly clear, it is of course 450 not testable so we need to be a little more prescriptive in order to 451 state a testable requirement. 453 We require that DTN protocols and implementations support mechanisms 454 for policy-based routing, in other words each DTN protocol 455 specification should state the security-relevant policy variables 456 based upon which it is reasonable to expect an implementation should 457 be able to make routing and forwarding decisions. While this is 458 still a little vague, the expectation is that each DTN specification 459 should, in its security considerations text, say which security 460 issues may exist which require a routing or forwarding policy 461 decision to be made. 463 In particular, since forwarding even a single bundle will consume 464 some network resources, every single DTN node must implicitly 465 incorporate some element of policy-based routing. Of course, we do 466 not expect that every single DTN node will be able to handle complex 467 policy decisions. In fact, a DTN node can be programmed to forward 468 all bundles received in a deterministic manner, say flooding the 469 bundle to all peers other than then one from which it was received. 470 Even such a simple minded node is however, implicitly implementing a 471 policy - in this case a simple flooding policy. So, though we 472 require all nodes to implement some policy, that policy can be very 473 simple. 475 Regardless of how simple, or complex, a node's support for policy 476 based routing/forwarding might be, DTN implementers should document 477 the relevant aspects of the implementation. In the absence of such 478 documentation a node might be deployed in an inappropriate context, 479 potentially damaging an entire network. 481 Some DTN nodes will however be on boundaries of various sorts, 482 whether they be network topology related, administrative, networking 483 technology related or simply a case where this node is the first 484 which is capable of handling complex policy decisions. At one stage 485 these nodes were termed security policy routers, and were considered 486 to be "special" nodes. Our current view though, is that all nodes 487 are in fact policy routers with some implementing policies which are 488 more complex than others. 490 We do not, at this stage, require that there be an interoperable way 491 to transfer policy settings between DTN nodes. Such a system could 492 perhaps be developed (though it is an extremely complex task), but 493 pragmatically, for now we consider the development of a DTN specific 494 policy language and distribution framework out of scope. 496 DTNs themselves do not appear to generate many new types of policy 497 based controls - the usual ingress, egress and forwarding types of 498 control can all be applied in DTNs. For example, some "bastion" node 499 might insist on all inbound bundles being authenticated, and might 500 add an authentication element to all outbound elements. So all the 501 usual forms of control can and should be available for use in DTN 502 nodes. 504 The DTN specific policy controls identified thus far, and for which 505 we would recommend support include: 507 TTL type controls where we consider the amount of time for which a 508 bundle has been "in-flight" 510 controls to do with "strange" routes, such as those that loop 512 controls handling local or global information about resource 513 constraints in the DTN (e.g. knowledge of a peer's storage 514 capacity) 516 controls related to special types of fragmentation (e.g. reactive 517 fragmentation) which are defined in a DTN 519 No doubt more will be identified as DTN deployment experience is 520 gained. 522 DTN node implementations will also be required to control access to 523 whatever DTN interface they provide so that only authorized entities 524 can act as the source (or destination) of bundles. Clearly this 525 aspect of access control is an implementation, rather than a protocol 526 issue. 528 It must be noted that policy based routing, if not deployed 529 appropriately, may inadvertently create bundle sinkholes. Consider 530 the case in which a bundle is fragmented, and if one fragment of the 531 bundle reaches a router who's policy requires it to see the entire 532 bundle, then all fragments of that bundle must also pass through that 533 same router. If they do not, then eventually the fragment at our 534 paranoid router will expire and ultimately the entire bundle never 535 arrives at the intended destination. This is clearly a case to avoid 536 - doing so, may however be difficult to arrange without good control 537 over routes. 539 4. Security Design considerations 541 This section lists some of the security design considerations which 542 were used during the development of the DTN security mechanisms 544 4.1. Only DTN-friendly schemes need apply 546 The high round-trip times and frequent and unpredictable 547 disconnections that are characteristic of DTNs mean that security 548 solutions which depend on ubiquitous online security services cannot 549 generally be applied. So solutions requiring ubiquitous access to 550 such servers (e.g. Kerberos, XKMS) are problematic. This is more- 551 or-less analogous to the way that TCP doesn't work in DTNs. However, 552 such solutions might be usable from a range of DTN nodes within some 553 security domain, though in that case what happens when a route spans 554 more than one such domain is an interesting question. 556 The long delays that may be inherent in DTNs mean that data may be 557 valid (even in-transit) for days or weeks, so depending on message 558 expiration alone to rid the network of unwanted messages will also 559 not work in general. 561 The impact of this design consideration most obviously applies to key 562 management, but it will also apply to other aspects of security, for 563 example, distribution of new policy settings. 565 4.2. TLS is a good model 567 The Transport Layer Security (TLS) specification [10] provides us 568 with some useful design ideas, especially in its use of what it calls 569 "ciphersuites". In TLS a ciphersuite is a single number that defines 570 how all of the various cryptographic algorithms are to be used. The 571 ciphersuite number is used in TLS during negotiation. One of the 572 more common ciphersuites is usually called 573 "TLS_RSA_WITH_3DES_EDE_CBC_SHA" indicating that the TLS protocol 574 (rather than an earlier SSL version) is being used with RSA based key 575 transport and with a variant of triple-DES as its bulk encryption 576 algorithm and SHA-1 for various digesting tasks. 578 So we can obviously use a ciphersuite value in the same way - to 579 indicate which cryptographic algorithms are in use for what purpose. 580 This is how we can support both symmetric and asymmetric mechanisms 581 for our cryptographic security services, and also allows us to extend 582 DTN security in the future, e.g. if identity based cryptography 583 schemes become usable. 585 In DTNs of course we won't be doing negotiations of the sort done in 586 TLS but we can still use the ciphersuite idea, and in fact, we extend 587 it a little more to use the ciphersuite to also indicate which 588 services are being applied (integrity or confidentiality) and also 589 the set of input bits for the service. In this way we can 590 distinguish between say an integrity service which only protects the 591 headers, from one which also protects the payload. 593 This allows us to address one of the trickier problems which was 594 considered for DTN security - combining integrity checking with 595 fragmentation. So-called reactive fragmentation is where we try to 596 optimise retransmission on the basis that we're fairly sure that some 597 bytes were sent before a link dropped out unexpectedly. What we do 598 is basically start from where we left off (or from where we are 599 confident that the recipient had received) in order to reduce the 600 number of bytes re-transmitted. Clearly though the recipient of such 601 a fragment has a problem checking integrity - say if I've gotten the 602 first 1MB of a 2MB bundle and then the link goes down. I (the 603 recipient) now have to decide whether to forward this fragment, but 604 if I do forward it - it cannot be integrity checked in an end-to- 605 end(-ish) fashion, since not all bytes are present, which clearly is 606 a breach of integrity. 608 One of the ways we've discussed for handling this is to associated a 609 number of checksums with the bundle - say one for every 100k in this 610 case, so that the entire bundle would use 20 checksums to provide 611 end-to-end integrity. The trick is that if the reactively forwarded 612 fragment has the first 10 of those, then its integrity can be 613 checked. Of course this comes at the expense of complexity and 614 additional bytes of overhead (in this case perhaps 400 or more 615 bytes), so it won't be desirable in most cases. Since each checksum 616 protects a part of the payload, this scheme has been referred to as 617 the "toilet paper" scheme - each forwardable fragment consisting of a 618 number of sheets of payload-paper with its associated checksum. In 619 order to support this type of fragmentation, we therefore have to 620 define the relevant toilet paper ciphersuites, which is done in the 621 security protocol specification. (At the time of writing anyway - 622 hopefully, these schemes can be deprecated since they are clumsy and 623 overly-complex for the benefit accruing.) 625 In summary the DTN concept of ciphersuite is borrowed from TLS and 626 slightly extended to also encompass the idea of having different 627 parts of the bundle being protected by the relevant security service. 628 However, in general DTNs cannot support the use of the TLS handshake 629 protocol as used in the terrestrial Internet. 631 4.3. Naming and identities 633 Most security mechanisms work well, or at least work obviously well, 634 with only some kinds of identity. For example, Kerberos style 635 security tends to go with domain-specific login names, PKI tends to 636 work best with X.500 or ldap style names (and well-ish with RFC822 637 addresses). In bundles the current scheme for endpoint identifiers 638 is to represent them as URIs. However, there is currently no well- 639 defined URI scheme which is specifically required to be supported. 640 This means that there is work to be done to map from these URIs to 641 the types of identity which are easily supported by whatever 642 mechanisms we're considering. 644 In LTP, identities are flat octet strings, so again there is work to 645 be done to map from these to e.g. user identities in your favorite 646 security mechanism. 648 4.4. Placement of checksums 650 As currently specified the bundle protocol requires that security 651 headers be placed before the payload in the bundle (due to a 652 requirement that the payload be the final header in the bundle). 653 This can be problematic for nodes which have limited buffer space and 654 which need to integrity protect some bundles. Say if the node wishes 655 to sign a 10Mb bundle, but it only has 1Mb of usable buffer, then 656 creating a digital signature over the 10Mb and sending that out 657 before the end of the payload is simply impossible. 659 However, due to the properties of most hash functions, were the 660 signature to be placed at the end of the bundle, then such a 661 constrained node could in fact send out the signed bundle. This is 662 due to the fact that hash functions have a continuation property 663 which allows the to-be-hashed data to be fed through the function in 664 blocks with only a small amount of state information required to be 665 stored. 667 For this reason most security protocols (like S/MIME) place a header 668 at the start of the message which specifies the signature/hashing to 669 be used (the ciphersuite in our case), and place the actual signature 670 or MAC at the end of the entire bundle. Discussions as to whether or 671 not to change the bundle protocol to operate in this way are on-going 672 at the time of writing. 674 4.5. Hop-by-hop-ish-ness 676 In the above we discussed how security services can be applied which 677 are not "truly" end-to-end. In the limit of course, we can use such 678 a scheme to apply security just between this DTN node and the next 679 hop. In particular there is clearly benefit in many cases from 680 applying integrity checks on such a hop-by-hop basis. 682 There are two things worth noting about this particular case: 684 Even though the protocol data units involved in end-to-end-ish and 685 hop-by-hop-ish applications of security services may be almost 686 identical, there may be benefit in artificially distinguishing 687 between them since one could imagine many nodes which would only 688 ever require (and thus properly support) hop-by-hop security - and 689 in fact one could reasonably define ciphersuites which are only 690 useful in such a hop-by-hop fashion. 692 There doesn't seem to be much interest in making such an 693 artificial distinction for confidentiality services, perhaps since 694 the ability to use lower layer security is presumed to be much 695 more common when the DTN nodes are "close" like this. 697 In any case, the current version of the bundle security protocol does 698 use a different header for this sort of hop-by-hop integrity. 699 Whether this remains, or changes in future drafts, is an open issue. 701 5. Open Issues 703 This section discusses some of the issues which are still very open, 704 either due to a current lack of consensus in the DTNRG, or else due 705 to their being areas (like DTN key management) where much basic 706 research remains to be done. 708 Where an issue has been discussed previously (e.g. source 709 confidentiality), we will not include it here again. 711 5.1. Key management 713 The main open issue in DTN security is the lack of a delay-tolerant 714 method for key management. It seems that we are at the stage where 715 we only really know how to use existing schemes, which ultimately 716 require an on-line status checking service or key distribution 717 service which is not practical in a high delay or highly disrupted 718 environment. 720 Note that even though some identity based cryptography (IBC) schemes 721 superficially appear to solve this problem (once we assume that the 722 originator has a name for the destination endpoint), this is in fact 723 not the case. The problem is that current IBC schemes effectively 724 act only as a kind of "group certificate" where all of the nodes 725 using a given private key generator can use a single "certificate", 726 but the problem of validity for that "certificate" (which will 727 contain the generator's parameters) is the same problem as verifying 728 a CA certificate in a standard PKI. 730 So, the only generally applicable schemes we currently have are 731 basically equivalent to shared secrets or else irrevocable public key 732 (or certificate based) schemes. Clearly, this is an area where more 733 research work could produce interesting results. 735 5.2. Handling replays 737 In most networking scenarios, we either wish to eliminate or else 738 dramatically reduce the probability of messages being replayed. In 739 some DTN contexts this will also be the case - particularly as 740 replaying a (say authenticated, authorized) message can be a fairly 741 straightforward way to consume scarce network resources. 743 However, there are also DTN scenarios where we wish to deliberately 744 replay messages, even to the extent of routing messages around a 745 loop. For example, if Bob is willing to act as a data mule for 746 Alice, who has limited storage, then Bob might pick up a bundle as he 747 passes Alice on his outbound journey from his Internet-connected home 748 location. As he goes on however, Bob also runs into storage 749 problems, and so he temporarily deposits the bundle with Charlie, who 750 he's passing now, and who he'll also pass on his way back home, in 751 say, a week's time. After a week, Bob indeed passes Charlie again 752 and picks up that bundle for the second time, after which he goes on 753 to successfully deliver the bundle via the Internet-connected node at 754 home. Now in this scenario, the same bundle is received by Bob 755 twice, and so would likely trigger any replay detection algorithm 756 that Bob is running, but of course, the behaviour as described, is 757 the nominal behaviour for the circumstances presented. 759 In addition to the example above, there are some routing schemes 760 which involve duplicating messages, for example, a node might flood 761 all its peers with a copy of a message to increase the probability 762 that the message will arrive at the destination before it (the 763 message) expires. Clearly such routing schemes are likely to result 764 in nodes seeing the same message more than once, but its not clear 765 whether any such node would be correct to delete such apparent 766 "duplicates". 768 The element of delay in DTNs also complicates handling replays. 769 Replay detection schemes generally depend on noting some unique 770 aspect of messages (via digesting of some message fields) and then 771 keeping a list of (the digests of) recently seen messages. The 772 problem in the DTN context is however, the "recently seen" part of 773 such replay detection algorithms, since maintaining such a list for 774 say 30 days would be fairly resource intensive, but might be required 775 if latencies are of that size. So the most obvious ways to protect 776 against replays are problematic. 778 The result is that the extent to which we can or should define a 779 generic DTN replay detection scheme is hard to determine, and at this 780 point this remains an open issue in DTN security. It may well be 781 that this means, that replay detection schemes, really need to be 782 specified as part of a bundle routing algorithm. 784 There is one aspect of replay handling where we can however enforce 785 some security - the bundle node which is the final destination can be 786 set to only deliver each bundle once to its application. In this 787 way, even though replays can consume network resources, they are less 788 likely cause application layer damage. (An example of such damage 789 would be a protocol which used a bundle to represent "Move the 790 telescope 10 degrees left" - repeated replays of this message could 791 result in damage if the telescope is pointed at the Sun. Of course, 792 the application layer in this case ought also be detecting replays, 793 e.g. by including a command number, but the example does demonstrate 794 the point.) 796 5.3. Traffic analysis 798 We do not currently define any security services for protecting 799 against traffic analysis. A general traffic analysis protection 800 scheme is probably not in any case a realistic goal for DTNs, given 801 their tendency to be resource-scarce and in addition there have been 802 no calls for a generic approach to this problem. However, for some 803 disruption tolerant networks, hiding traffic (e.g. the existence of a 804 signal from a sensor net) may be a very important security 805 requirement. 807 So, the first open issue here is the extent to which there is a real 808 need for a generic scheme for protection against traffic analysis. 809 If there were, then the second open issue is how to define such a 810 scheme to be delay and disruption tolerant and which also doesn't 811 consume too many resources. 813 Finally, traffic analysis protection may be left as a local matter 814 for the underlying network layers, e.g. if a particular radio link 815 were of concern, then total obscuration of that link may be required, 816 and may in fact be the only way to hide such radio traffic. 818 5.4. Routing protocol security 820 Clearly whenever DTN routing protocols are defined they will 821 introduce new security requirements, or at least change the emphasis 822 to be properly placed on meeting the various requirements posited 823 above. For example, one could expect that a robust and scalable 824 origin-authentication scheme would become more important. 826 At the time of writing there are no well-documented DTN routing 827 protocols, so DTN routing protocol security must clearly be in our 828 list of open issues. However, if a putative DTN routing protocol 829 were to use either the Bundle protocol or LTP, it could clearly make 830 use of their existing security features. 832 5.5. Multicast security 834 Work on what it means to use modes of operation like multicast, 835 nearcast, anycast etc. in a DTN is really only beginning. However, 836 it is clear that there are some new aspects to this work, since most 837 work to date has implicitly assumed that the signalling traffic (e.g. 838 joining a group) can occur in more-or-less "real" time. In a DTN, 839 joining a multicast group may be more akin to signing up to a mailing 840 list, so that messages originated before the join may be received 841 afterwards - in principle such a DTN "joiner" might get sent the 842 entire mailing list archive either by design or in error. 844 So, given that there are differences between "traditional" multicast 845 and DTN "multicast" (if it is still called that as you're reading 846 this), then we clearly have no real idea about the threats or 847 security requirements which may apply. Just to give an example of 848 the type of issue to be considered: when joining if I authenticate 849 with some credential which has a notBefore time of Jan 1 2005, (as an 850 X.509 public key certificate might have), and some message created 851 before that time is still to be delivered, should the notBefore time 852 of the credential be part of the decision as to whether to route the 853 message to the "joiner"? In this case, probably the answer is "no", 854 but in some contexts that could be the wrong answer, allowing new 855 (cheap) identities access to old (expensively accrued) materials. 857 5.6. Performance Issues 859 Provision of security within a DTN imposes both bandwidth utilization 860 costs on the DTN links and computational costs on the DTN nodes. 862 The provision of DTN security consumes additional bandwidth which 863 will depend on the way optional parameters are encoded (or not) and 864 also on the cryptographic algorithms being used. In addition, if 865 more than one security service is used for the same bundle (say a MAC 866 to be removed by the next hop and a signature for the final 867 destination) then we are again chewing into the possibly limited 868 amount of bandwidth available for security purposes. 870 The use of DTN security also imposes computational costs on DTN 871 nodes. Again there may be limits as to how much CPU is worth 872 devoting to security and the amount of computation will depend on the 873 algorithms used and their parameters. 875 6. Security Considerations 877 Since this entire document is an informative description of how the 878 DTNRG are approaching security, there is little to say in this 879 section. 881 However, implementers of DTN protocols must not take text here to be 882 normative, in the case of conflict the relevant protocol 883 specification takes precedence. 885 7. IANA Considerations 887 None. 889 8. Informative References 891 [1] Cerf, V., "Delay-Tolerant Network Architecture", 892 draft-irtf-dtnrg-arch-03.txt, work-in-progress, July 2005. 894 [2] Scott, K. and S. Burleigh, "Bundle Protocol Specification", 895 draft-irtf-dtnrg-bundle-spec-03.txt, work-in-progress, 896 July 2005. 898 [3] Symington, S., Farrell, S., and H. Weiss, "Bundle Security 899 Protocol Specification", 900 draft-irtf-dtnrg-bundle-security-00.txt, work-in-progress, 901 June 2005. 903 [4] Warthman, F., "Delay-Tolerant Networks (DTNs) A Tutorial", 904 http://www.dtnrg.org/ , March 2003. 906 [5] Durst, R., "An Infrastructure Security Model for Delay Tolerant 907 Networks", http://www.dtnrg.org/ , July 2002. 909 [6] Ramadas, M., Burleigh, S., and S. Farrell, "Licklider 910 Transmission Protocol", 911 draft-irtf-dtnrg-ltp-03.txt, work-in-progress, July 2005. 913 [7] Farrell, S., Ramadas, M., and S. Burleigh, "Licklider 914 Transmission Protocol - Extensions", 915 draft-irtf-dtnrg-ltp-03.txt, work-in-progress, July 2005. 917 [8] Burleigh, S., Ramadas, M., and S. Farrell, "Licklider 918 Transmission Protocol - Motivation", 919 draft-irtf-dtnrg-ltp-03.txt, work-in-progress, July 2005. 921 [9] Zhou, L. and Z. Haas, "Securing Ad-Hoc Networks", IEEE 922 network vol 13, no. 6, Nov-Dec 1999, pp 24-30. 924 [10] Dierks, T. and C. Allen, "The TLS Protocol - Version 1.0", RFC 925 2246 , January 1999. 927 Authors' Addresses 929 Stephen Farrell 930 Trinity College Dublin 931 Distributed Systems Group 932 Department of Computer Science 933 Trinity College 934 Dublin 935 Ireland 937 Phone: +353-1-608-1539 938 Email: stephen.farrell@cs.tcd.ie 940 Susan Flynn Symington 941 The MITRE Corporation 942 7515 Colshire Drive 943 McLean, VA 22102 944 US 946 Phone: 703 883 7209 947 Email: susan@mitre.org 948 URI: http://mitre.org/ 950 Howard Weiss 951 SPARTA, Inc. 952 7075 Samuel Morse Drive 953 Columbia, MD 21046 954 US 956 Phone: +1-410-872-1515 x201 957 Email: hsw@sparta.com 959 Intellectual Property Statement 961 The IETF takes no position regarding the validity or scope of any 962 Intellectual Property Rights or other rights that might be claimed to 963 pertain to the implementation or use of the technology described in 964 this document or the extent to which any license under such rights 965 might or might not be available; nor does it represent that it has 966 made any independent effort to identify any such rights. Information 967 on the procedures with respect to rights in RFC documents can be 968 found in BCP 78 and BCP 79. 970 Copies of IPR disclosures made to the IETF Secretariat and any 971 assurances of licenses to be made available, or the result of an 972 attempt made to obtain a general license or permission for the use of 973 such proprietary rights by implementers or users of this 974 specification can be obtained from the IETF on-line IPR repository at 975 http://www.ietf.org/ipr. 977 The IETF invites any interested party to bring to its attention any 978 copyrights, patents or patent applications, or other proprietary 979 rights that may cover technology that may be required to implement 980 this standard. Please address the information to the IETF at 981 ietf-ipr@ietf.org. 983 Disclaimer of Validity 985 This document and the information contained herein are provided on an 986 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 987 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 988 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 989 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 990 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 991 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 993 Copyright Statement 995 Copyright (C) The Internet Society (2005). This document is subject 996 to the rights, licenses and restrictions contained in BCP 78, and 997 except as set forth therein, the authors retain all their rights. 999 Acknowledgment 1001 Funding for the RFC Editor function is currently provided by the 1002 Internet Society.