idnits 2.17.1 draft-irtf-dtnrg-sec-overview-02.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 1002. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1009. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1015. ** 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 issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the 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 (October 4, 2006) is 6408 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-08) exists of draft-irtf-dtnrg-arch-06 == Outdated reference: A later version (-10) exists of draft-irtf-dtnrg-bundle-spec-06 == Outdated reference: A later version (-19) exists of draft-irtf-dtnrg-bundle-security-02 == Outdated reference: A later version (-10) exists of draft-irtf-dtnrg-ltp-05 == Outdated reference: A later version (-08) exists of draft-irtf-dtnrg-ltp-extensions-04 == Outdated reference: A later version (-07) exists of draft-irtf-dtnrg-ltp-motivation-03 -- Obsolete informational reference (is this intentional?): RFC 2246 (ref. '10') (Obsoleted by RFC 4346) Summary: 3 errors (**), 0 flaws (~~), 7 warnings (==), 8 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 Intended status: Informational S. Symington 5 Expires: April 7, 2007 The MITRE Corporation 6 H. Weiss 7 SPARTA, Inc. 8 October 4, 2006 10 Delay-Tolerant Networking Security Overview 11 draft-irtf-dtnrg-sec-overview-02 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 April 7, 2007. 38 Copyright Notice 40 Copyright (C) The Internet Society (2006). 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. . . . . . . . . . . . . . 8 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 . . . . . . . . . . . . . . . . . . . . 24 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 84 Intellectual Property and Copyright Statements . . . . . . . . . . 26 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 criticized 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 throughout 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 coordinated 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 behavior 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-behaviors 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 278 unwanted traffic. Given a DTN operating sufficiently "close to the 279 wire", such traffic could have serious affects. 281 In particular, the current bundle protocol includes various messages 282 containing administrative records (bundle status reports and custody 283 signals) that are produced in response to original traffic. The 284 Bundle Protocol, however, includes a constraint that the status 285 report request flags on all bundles containing administrative records 286 must be zero. So, although a bundle that is not a custody signal or 287 status report may cause the generation of custody signals and/or 288 status reports, bundles that are themselves custody signals or status 289 reports are not permitted to cause the generation of custody signals 290 or status reports. This constraint is designed to prevent bundle 291 storms, and it does so in the case in which bundles can not be 292 modified. If a DTN node (or other network element) could modify a 293 single "forwarding report" by both resetting its "Application Data 294 Unit is an Administrative Record" bundle processing flag and setting 295 its "forwarding report" status report request flag, then the 296 forwarding of a bundle status report could cause the forwarding of an 297 additional status report, and so on. Traffic could continue to be 298 generated in this manner for as long as the values of the bundle 299 processing flags and the status report request flags can be modified. 300 So, while the constraint that bundles containing administrative 301 records are not permitted to generate other bundles containing 302 administrative records goes a long way toward preventing traffic 303 storms, it may be best to entirely remove some of status reporting 304 capabilities from the Bundle Protocol.) 306 2.6. Partial protection is just that. 308 Some DTN nodes won't need to protect all parts of all bundles. Some 309 DTN nodes won't be able to properly protect the integrity of the 310 entire bundle including its payload. Potential reasons range from 311 lack of computing power to application (or lower) layer protection 312 applying integrity, with the result that there's no benefit in 313 repeating this work in the bundle layer. Alternatively, some DTN 314 nodes may choose not to protect all parts of all bundles in return 315 for being able to perform reactive fragmentation. 317 There are also cases where bundle headers should be modified in 318 transit (e.g. the dictionary header in some versions of the bundle 319 protocol), or a "via" header which captures the route a bundle has 320 followed, so that integrity checking on anything more than a hop-by- 321 hop basis becomes unwieldy since the to-be-protected bytes are a 322 moving target. 324 The result is that it is possible that some fields of a bundle are 325 strongly protected whilst others are effectively unprotected. 326 Whenever such a situation occurs then it will be possible for network 327 elements to at least use the bundle protocol as a communications 328 channel, perhaps covert or perhaps overt. Where such misuse is a 329 concern, then the DTN should either use different security options 330 which do cover the fields of concern, or else administrators (if they 331 exist!) must ensure that the bundles only traverse lower layers where 332 the probability of such misuse is sufficiently small. 334 3. Security Requirements 336 This section lists some of the security requirements which were 337 agreed as priorities during the development of the DTN security 338 mechanisms. 340 3.1. End-to-end-ish-ness 342 Traditionally, protocols tend to provide security services which are 343 used either (or both) on a hop-by-hop or end-to-end basis. For DTN 344 security though, we require that these services be usable also 345 between nodes which are not endpoints, but which can be in the middle 346 of a route. 348 For example, if a sensor network uses some satisfactory lower layer 349 security, and has some gateway sensor node, which is more capable and 350 also say periodically connected to the Internet, then we may wish to 351 use DTN security services to protect messages between that gateway 352 node and the other DTN sources and destinations on the Internet-side 353 of the gateway. In the case of a confidentiality service, this is 354 clearly useful since bundles which leave the sensor network could be 355 encrypted (by the gateway node) for the final destination. In the 356 case of say a software download, new code might be integrity 357 protected from the origin to the gateway which is able to check some 358 relevant white or black lists or use some other software 359 authorisation scheme which cannot practically be used from a sensor 360 node. 362 In order to define services which can be used in these ways we 363 distinguish between the sender of a bundle and the security-sender 364 for an application of one of these services. Similarly, we can 365 distinguish between the bundle recipient and the security-recipient 366 (or security-destination) for a given application of a security 367 service. Basically, the security-sender is the DTN node that applied 368 the security service, and the security-recipient (or security- 369 destination) is the DTN node which is the target for the security 370 service - say the node expected to decrypt or do integrity checking. 372 The extent to which the various services can be combined for the 373 same, or different security senders and destinations is something 374 which has to be made clear in the relevant protocol definition. 375 However, we can state a requirement that this should be kept as 376 simple as possible since unwanted complexity in this respect is 377 highly likely to make a DTN harder to manage, and thus less secure. 379 Having said that, there may still be good reason to distinguish (at 380 the protocol field level) between uses of these services which are 381 intended to be hop-by-hop (i.e. between this and the next DTN node), 382 as opposed to uses of these services which are intended to be applied 383 across multiple nodes. Equally, a protocol might not need to make 384 this distinction and might only define e.g. one confidentiality 385 service which can be applied multiple times for a single bundle with 386 different combinations of security-sender and security-recipient. 388 There is one more example of the ways in which DTN security services 389 seem to differ from more "normal" network security services, that is 390 worth mentioning here. (Indeed this mode of operation might be 391 useful in non-DTNs too!). When a message is authenticated using a 392 digital signature, then in principle any network element on the path 393 can do some checking of that signature. If the message contains 394 sufficient information (the supposed signer's public key or a 395 resolvable reference thereto) then any node can at least check the 396 cryptographic correctness of the signature. 398 However, this is typically insufficient to decide how to process the 399 message, since in many environments basically anyone could insert a 400 public key and a signature thus producing a message which passes this 401 test. So in most real cases, there is some additional check that the 402 signer is authorised, either explicitly by checking the signer's name 403 or key is authorised for the purpose, or else implicitly by for 404 example using a PKI for this purpose (say via an extended key usage 405 extension). It turns out that all practical ways to perform this 406 authorisation check are problematic in at least some DTN cases, 407 either due to the lack of availability of an authorisation server 408 (say due to simple latency back from the verifier to the relevant 409 authorisation server) or due to restricted node capabilities (say in 410 the case of a sensor node). 412 In such cases, it may be sensible for some "bastion" node along the 413 route to do the authorisation check and then to (again explicitly or 414 implicitly) attest that the authorisation test has passed. 415 Subsequent nodes, may however, for either data integrity or 416 accountability reasons wish to also validate the cryptographic 417 correctness of the signature. The end result might be a mechanism 418 whereby the message has a signature plus some meta-data which are 419 fully processed by the "bastion" node, whereas the signature is only 420 partly processed by all subsequent nodes. (Note: The role of the 421 "security-destination" concept in such cases is not yet clear.) 423 3.2. Confidentiality and integrity 425 Since most protocol designs use common elements to deal with all 426 cryptographic based security services and mechanisms, we will deal 427 with all of these in this section. 429 DTN protocols should provide a way to encrypt protocol elements so 430 that messages in transit cannot practically be read. The extent to 431 which a confidentiality service should be able to be applied to any 432 or all protocol elements is a somewhat open issue. In particular, 433 whether or not source confidentiality should be provided is still 434 under discussion. Clearly, calling for a confidentiality service 435 implies a need for key management. However, a proper DTN key 436 management scheme is still an open issue, so we would expect DTN 437 protocols, to support pre-shared-keys (and/or known irrevocable 438 certificates) in the meantime. 440 Similarly, DTN protocols should provide a way to apply an integrity 441 check to a message so that the identity of the security-sender can be 442 established and so that changes in sensitive parts of the message can 443 be detected. Again, this implies a need for key management which is 444 not, so far, really met. 446 Clearly a protocol should allow for fairly flexible combinations of 447 applications of the confidentiality and integrity services, though 448 hopefully disallowing insecure combinations e.g. a plaintext 449 signature which is out of scope of a confidentiality service allows 450 plaintext guesses to be verified. 452 However these services are provided they should allow for sensible 453 combinations of a range of standard cryptographic algorithms to be 454 used and should also allow for changes to the set of acceptable 455 algorithms to be made over time. 457 3.3. Policy based routing 459 Since the DTN, as a piece of infrastructure, may be quite fragile, we 460 require protocols to be cautious in how they consume network 461 resources. While the intent of this is fairly clear, it is of course 462 not testable so we need to be a little more prescriptive in order to 463 state a testable requirement. 465 We require that DTN protocols and implementations support mechanisms 466 for policy-based routing, in other words each DTN protocol 467 specification should state the security-relevant policy variables 468 based upon which it is reasonable to expect an implementation should 469 be able to make routing and forwarding decisions. While this is 470 still a little vague, the expectation is that each DTN specification 471 should, in its security considerations text, say which security 472 issues may exist which require a routing or forwarding policy 473 decision to be made. 475 In particular, since forwarding even a single bundle will consume 476 some network resources, every single DTN node must implicitly 477 incorporate some element of policy-based routing. Of course, we do 478 not expect that every single DTN node will be able to handle complex 479 policy decisions. In fact, a DTN node can be programmed to forward 480 all bundles received in a deterministic manner, say flooding the 481 bundle to all peers other than then one from which it was received. 482 Even such a simple minded node is however, implicitly implementing a 483 policy - in this case a simple flooding policy. So, though we 484 require all nodes to implement some policy, that policy can be very 485 simple. 487 Regardless of how simple, or complex, a node's support for policy 488 based routing/forwarding might be, DTN implementers should document 489 the relevant aspects of the implementation. In the absence of such 490 documentation a node might be deployed in an inappropriate context, 491 potentially damaging an entire network. 493 Some DTN nodes will however be on boundaries of various sorts, 494 whether they be network topology related, administrative, networking 495 technology related or simply a case where this node is the first 496 which is capable of handling complex policy decisions. At one stage 497 these nodes were termed security policy routers, and were considered 498 to be "special" nodes. Our current view though, is that all nodes 499 are in fact policy routers with some implementing policies which are 500 more complex than others. 502 We do not, at this stage, require that there be an interoperable way 503 to transfer policy settings between DTN nodes. Such a system could 504 perhaps be developed (though it is an extremely complex task), but 505 pragmatically, for now we consider the development of a DTN specific 506 policy language and distribution framework out of scope. 508 DTNs themselves do not appear to generate many new types of policy 509 based controls - the usual ingress, egress and forwarding types of 510 control can all be applied in DTNs. For example, some "bastion" node 511 might insist on all inbound bundles being authenticated, and might 512 add an authentication element to all outbound elements. So all the 513 usual forms of control can and should be available for use in DTN 514 nodes. 516 The DTN specific policy controls identified thus far, and for which 517 we would recommend support include: 519 TTL type controls where we consider the amount of time for which a 520 bundle has been "in-flight" 522 controls to do with "strange" routes, such as those that loop 524 controls handling local or global information about resource 525 constraints in the DTN (e.g. knowledge of a peer's storage 526 capacity) 528 controls related to special types of fragmentation (e.g. reactive 529 fragmentation) which are defined in a DTN 531 No doubt more will be identified as DTN deployment experience is 532 gained. 534 DTN node implementations will also be required to control access to 535 whatever DTN interface they provide so that only authorized entities 536 can act as the source (or destination) of bundles. Clearly this 537 aspect of access control is an implementation, rather than a protocol 538 issue. 540 It must be noted that policy based routing, if not deployed 541 appropriately, may inadvertently create bundle sinkholes. Consider 542 the case in which a bundle is fragmented, and if one fragment of the 543 bundle reaches a router who's policy requires it to see the entire 544 bundle, then all fragments of that bundle must also pass through that 545 same router. If they do not, then eventually the fragment at our 546 paranoid router will expire and ultimately the entire bundle never 547 arrives at the intended destination. This is clearly a case to avoid 548 - doing so, may however be difficult to arrange without good control 549 over routes. 551 4. Security Design considerations 553 This section lists some of the security design considerations which 554 were used during the development of the DTN security mechanisms 556 4.1. Only DTN-friendly schemes need apply 558 The high round-trip times and frequent and unpredictable 559 disconnections that are characteristic of DTNs mean that security 560 solutions which depend on ubiquitous online security services cannot 561 generally be applied. So solutions requiring ubiquitous access to 562 such servers (e.g. Kerberos, XKMS) are problematic. This is more- 563 or-less analogous to the way that TCP doesn't work in DTNs. However, 564 such solutions might be usable from a range of DTN nodes within some 565 security domain, though in that case what happens when a route spans 566 more than one such domain is an interesting question. 568 The long delays that may be inherent in DTNs mean that data may be 569 valid (even in-transit) for days or weeks, so depending on message 570 expiration alone to rid the network of unwanted messages will also 571 not work in general. 573 The impact of this design consideration most obviously applies to key 574 management, but it will also apply to other aspects of security, for 575 example, distribution of new policy settings. 577 4.2. TLS is a good model 579 The Transport Layer Security (TLS) specification [10] provides us 580 with some useful design ideas, especially in its use of what it calls 581 "ciphersuites". In TLS a ciphersuite is a single number that defines 582 how all of the various cryptographic algorithms are to be used. The 583 ciphersuite number is used in TLS during negotiation. One of the 584 more common ciphersuites is usually called 585 "TLS_RSA_WITH_3DES_EDE_CBC_SHA" indicating that the TLS protocol 586 (rather than an earlier SSL version) is being used with RSA based key 587 transport and with a variant of triple-DES as its bulk encryption 588 algorithm and SHA-1 for various digesting tasks. 590 So we can obviously use a ciphersuite value in the same way - to 591 indicate which cryptographic algorithms are in use for what purpose. 592 This is how we can support both symmetric and asymmetric mechanisms 593 for our cryptographic security services, and also allows us to extend 594 DTN security in the future, e.g. if identity based cryptography 595 schemes become usable. 597 In DTNs of course we won't be doing negotiations of the sort done in 598 TLS but we can still use the ciphersuite idea, and in fact, we extend 599 it a little more to use the ciphersuite to also indicate which 600 services are being applied (integrity or confidentiality) and also 601 the set of input bits for the service. In this way we can 602 distinguish between say an integrity service which only protects the 603 headers, from one which also protects the payload. 605 This allows us to address one of the trickier problems which was 606 considered for DTN security - combining integrity checking with 607 fragmentation. So-called reactive fragmentation is where we try to 608 optimize retransmission on the basis that we're fairly sure that some 609 bytes were sent before a link dropped out unexpectedly. What we do 610 is basically start from where we left off (or from where we are 611 confident that the recipient had received) in order to reduce the 612 number of bytes re-transmitted. Clearly though the recipient of such 613 a fragment has a problem checking integrity - say if I've gotten the 614 first 1MB of a 2MB bundle and then the link goes down. I (the 615 recipient) now have to decide whether to forward this fragment, but 616 if I do forward it - it cannot be integrity checked in an end-to- 617 end(-ish) fashion, since not all bytes are present, which clearly is 618 a breach of integrity. 620 One of the ways we've discussed for handling this is to associated a 621 number of checksums with the bundle - say one for every 100k in this 622 case, so that the entire bundle would use 20 checksums to provide 623 end-to-end integrity. The trick is that if the reactively forwarded 624 fragment has the first 10 of those, then its integrity can be 625 checked. Of course this comes at the expense of complexity and 626 additional bytes of overhead (in this case perhaps 400 or more 627 bytes), so it won't be desirable in most cases. Since each checksum 628 protects a part of the payload, this scheme has been referred to as 629 the "toilet paper" scheme - each forwardable fragment consisting of a 630 number of sheets of payload-paper with its associated checksum. In 631 order to support this type of fragmentation, we therefore have to 632 define the relevant toilet paper ciphersuites, which is done in the 633 security protocol specification. (At the time of writing anyway - 634 hopefully, these schemes can be deprecated since they are clumsy and 635 overly-complex for the benefit accruing.) 637 In summary the DTN concept of ciphersuite is borrowed from TLS and 638 slightly extended to also encompass the idea of having different 639 parts of the bundle being protected by the relevant security service. 640 However, in general DTNs cannot support the use of the TLS handshake 641 protocol as used in the terrestrial Internet. 643 4.3. Naming and identities 645 Most security mechanisms work well, or at least work obviously well, 646 with only some kinds of identity. For example, Kerberos style 647 security tends to go with domain-specific login names, PKI tends to 648 work best with X.500 or ldap style names (and well-ish with RFC822 649 addresses). In bundles the current scheme for endpoint identifiers 650 is to represent them as URIs. However, there is currently no well- 651 defined URI scheme which is specifically required to be supported. 652 This means that there is work to be done to map from these URIs to 653 the types of identity which are easily supported by whatever 654 mechanisms we're considering. 656 In LTP, identities are flat octet strings, so again there is work to 657 be done to map from these to e.g. user identities in your favorite 658 security mechanism. 660 4.4. Placement of checksums 662 As currently specified, the bundle protocol requires that the last 663 header in the bundle be identified as such by setting its "Last 664 header" header processing flag. This bit enables security headers to 665 be placed either before or after the bundle payload header. The 666 ability to place a signature after the bundle payload header, at the 667 end of the bundle, is important for integrity-protecting some bundles 668 at nodes that have limited buffer space. For example, if a node 669 wishes to sign a 10Mb bundle, but it only has 1Mb of usable buffer, 670 then creating a digital signature over the 10Mb and sending that out 671 before the end of the payload is simply impossible. 673 However, due to the properties of most hash functions, were the 674 signature to be placed at the end of the bundle, then such a 675 constrained node could in fact send out the signed bundle. This is 676 due to the fact that hash functions have a continuation property 677 which allows the to-be-hashed data to be fed through the function in 678 blocks with only a small amount of state information required to be 679 stored. 681 For this reason, DTN security protocols have the option of placing 682 either a single header in the message or placing correlated headers 683 in the message, for example one at the start of the message which 684 specifies the signature/hashing to be used (the ciphersuite in our 685 case), and one (that contains the actual signature or MAC) at the end 686 of the entire bundle. The ability to place such correlated security 687 headers in the message allows even very memory-constrained nodes to 688 be able to process the bundle and verify its security result. 690 4.5. Hop-by-hop-ish-ness 692 In the above we discussed how security services can be applied which 693 are not "truly" end-to-end. In the limit of course, we can use such 694 a scheme to apply security just between this DTN node and the next 695 hop. In particular there is clearly benefit in many cases from 696 applying integrity checks on such a hop-by-hop basis. 698 There are two things worth noting about this particular case: 700 Even though the protocol data units involved in end-to-end-ish and 701 hop-by-hop-ish applications of security services may be almost 702 identical, there may be benefit in artificially distinguishing 703 between them since one could imagine many nodes which would only 704 ever require (and thus properly support) hop-by-hop security - and 705 in fact one could reasonably define ciphersuites which are only 706 useful in such a hop-by-hop fashion. 708 There doesn't seem to be much interest in making such an 709 artificial distinction for confidentiality services, perhaps since 710 the ability to use lower layer security is presumed to be much 711 more common when the DTN nodes are "close" like this. 713 In any case, the current version of the bundle security protocol does 714 use a different header for this sort of hop-by-hop integrity. 715 Whether this remains, or changes in future drafts, is an open issue. 717 5. Open Issues 719 This section discusses some of the issues which are still very open, 720 either due to a current lack of consensus in the DTNRG, or else due 721 to their being areas (like DTN key management) where much basic 722 research remains to be done. 724 Where an issue has been discussed previously (e.g. source 725 confidentiality), we will not include it here again. 727 5.1. Key management 729 The main open issue in DTN security is the lack of a delay-tolerant 730 method for key management. It seems that we are at the stage where 731 we only really know how to use existing schemes, which ultimately 732 require an on-line status checking service or key distribution 733 service which is not practical in a high delay or highly disrupted 734 environment. 736 Note that even though some identity based cryptography (IBC) schemes 737 superficially appear to solve this problem (once we assume that the 738 originator has a name for the destination endpoint), this is in fact 739 not the case. The problem is that current IBC schemes effectively 740 act only as a kind of "group certificate" where all of the nodes 741 using a given private key generator can use a single "certificate", 742 but the problem of validity for that "certificate" (which will 743 contain the generator's parameters) is the same problem as verifying 744 a CA certificate in a standard PKI. 746 So, the only generally applicable schemes we currently have are 747 basically equivalent to shared secrets or else irrevocable public key 748 (or certificate based) schemes. Clearly, this is an area where more 749 research work could produce interesting results. 751 5.2. Handling replays 753 In most networking scenarios, we either wish to eliminate or else 754 dramatically reduce the probability of messages being replayed. In 755 some DTN contexts this will also be the case - particularly as 756 replaying a (say authenticated, authorized) message can be a fairly 757 straightforward way to consume scarce network resources. 759 However, there are also DTN scenarios where we wish to deliberately 760 replay messages, even to the extent of routing messages around a 761 loop. For example, if Bob is willing to act as a data mule for 762 Alice, who has limited storage, then Bob might pick up a bundle as he 763 passes Alice on his outbound journey from his Internet-connected home 764 location. As he goes on however, Bob also runs into storage 765 problems, and so he temporarily deposits the bundle with Charlie, who 766 he's passing now, and who he'll also pass on his way back home, in 767 say, a week's time. After a week, Bob indeed passes Charlie again 768 and picks up that bundle for the second time, after which he goes on 769 to successfully deliver the bundle via the Internet-connected node at 770 home. Now in this scenario, the same bundle is received by Bob 771 twice, and so would likely trigger any replay detection algorithm 772 that Bob is running, but of course, the behavior as described, is the 773 nominal behavior for the circumstances presented. 775 In addition to the example above, there are some routing schemes 776 which involve duplicating messages, for example, a node might flood 777 all its peers with a copy of a message to increase the probability 778 that the message will arrive at the destination before it (the 779 message) expires. Clearly such routing schemes are likely to result 780 in nodes seeing the same message more than once, but it's not clear 781 whether any such node would be correct to delete such apparent 782 "duplicates". 784 The element of delay in DTNs also complicates handling replays. 785 Replay detection schemes generally depend on noting some unique 786 aspect of messages (via digesting of some message fields) and then 787 keeping a list of (the digests of) recently seen messages. The 788 problem in the DTN context is however, the "recently seen" part of 789 such replay detection algorithms, since maintaining such a list for 790 say 30 days would be fairly resource intensive, but might be required 791 if latencies are of that size. So the most obvious ways to protect 792 against replays are problematic. 794 The result is that the extent to which we can or should define a 795 generic DTN replay detection scheme is hard to determine, and at this 796 point this remains an open issue in DTN security. It may well be 797 that this means that replay detection schemes really need to be 798 specified as part of a bundle routing algorithm. 800 There is one aspect of replay handling where we can however enforce 801 some security - the bundle node which is the final destination can be 802 set to only deliver each bundle once to its application. In this 803 way, even though replays can consume network resources, they are less 804 likely cause application layer damage. (An example of such damage 805 would be a protocol which used a bundle to represent "Move the 806 telescope 10 degrees left" - repeated replays of this message could 807 result in damage if the telescope is pointed at the Sun. Of course, 808 the application layer in this case ought also be detecting replays, 809 e.g. by including a command number, but the example does demonstrate 810 the point.) 812 5.3. Traffic analysis 814 We do not currently define any security services for protecting 815 against traffic analysis. A general traffic analysis protection 816 scheme is probably not in any case a realistic goal for DTNs, given 817 their tendency to be resource-scarce and in addition there have been 818 no calls for a generic approach to this problem. However, for some 819 disruption tolerant networks, hiding traffic (e.g. the existence of a 820 signal from a sensor net) may be a very important security 821 requirement. 823 So, the first open issue here is the extent to which there is a real 824 need for a generic scheme for protection against traffic analysis. 825 If there were, then the second open issue is how to define such a 826 scheme to be delay and disruption tolerant and which also doesn't 827 consume too many resources. 829 Finally, traffic analysis protection may be left as a local matter 830 for the underlying network layers, e.g. if a particular radio link 831 were of concern, then total obscuration of that link may be required, 832 and may in fact be the only way to hide such radio traffic. 834 5.4. Routing protocol security 836 Clearly whenever DTN routing protocols are defined they will 837 introduce new security requirements, or at least change the emphasis 838 to be properly placed on meeting the various requirements posited 839 above. For example, one could expect that a robust and scalable 840 origin-authentication scheme would become more important. 842 At the time of writing there are no well-documented DTN routing 843 protocols, so DTN routing protocol security must clearly be in our 844 list of open issues. However, if a putative DTN routing protocol 845 were to use either the Bundle protocol or LTP, it could clearly make 846 use of their existing security features. 848 5.5. Multicast security 850 Work on what it means to use modes of operation like multicast, 851 nearcast, anycast etc. in a DTN is really only beginning. However, 852 it is clear that there are some new aspects to this work, since most 853 work to date has implicitly assumed that the signalling traffic (e.g. 854 joining a group) can occur in more-or-less "real" time. In a DTN, 855 joining a multicast group may be more akin to signing up to a mailing 856 list, so that messages originated before the join may be received 857 afterwards - in principle such a DTN "joiner" might get sent the 858 entire mailing list archive either by design or in error. 860 So, given that there are differences between "traditional" multicast 861 and DTN "multicast", then we clearly have no real idea about the 862 threats or security requirements which may apply. Just to give an 863 example of the type of issue to be considered: when joining if I 864 authenticate with some credential which has a notBefore time of Jan 1 865 2005, (as an X.509 public key certificate might have), and some 866 message created before that time is still to be delivered, should the 867 notBefore time of the credential be part of the decision as to 868 whether to route the message to the "joiner"? In this case, probably 869 the answer is "no", but in some contexts that could be the wrong 870 answer, allowing new (cheap) identities access to old (expensively 871 accrued) materials. 873 5.6. Performance Issues 875 Provision of security within a DTN imposes both bandwidth utilization 876 costs on the DTN links and computational costs on the DTN nodes. 878 The provision of DTN security consumes additional bandwidth which 879 will depend on the way optional parameters are encoded (or not) and 880 also on the cryptographic algorithms being used. In addition, if 881 more than one security service is used for the same bundle (say a MAC 882 to be removed by the next hop and a signature for the final 883 destination) then we are again chewing into the possibly limited 884 amount of bandwidth available for security purposes. 886 The use of DTN security also imposes computational costs on DTN 887 nodes. Again there may be limits as to how much CPU is worth 888 devoting to security and the amount of computation will depend on the 889 algorithms used and their parameters. 891 6. Security Considerations 893 Since this entire document is an informative description of how the 894 DTNRG are approaching security, there is little to say in this 895 section. 897 However, implementers of DTN protocols must not take text here to be 898 normative, in the case of conflict the relevant protocol 899 specification takes precedence. 901 7. IANA Considerations 903 None. 905 8. Informative References 907 [1] Cerf, V., "Delay-Tolerant Network Architecture", 908 draft-irtf-dtnrg-arch-06.txt, work-in-progress, September 2006. 910 [2] Scott, K. and S. Burleigh, "Bundle Protocol Specification", 911 draft-irtf-dtnrg-bundle-spec-06.txt, work-in-progress, 912 August 2006. 914 [3] Symington, S., Farrell, S., and H. Weiss, "Bundle Security 915 Protocol Specification", 916 draft-irtf-dtnrg-bundle-security-02.txt, work-in-progress, 917 October 2006. 919 [4] Warthman, F., "Delay-Tolerant Networks (DTNs) A Tutorial", 920 http://www.dtnrg.org/ , March 2003. 922 [5] Durst, R., "An Infrastructure Security Model for Delay Tolerant 923 Networks", http://www.dtnrg.org/ , July 2002. 925 [6] Ramadas, M., Burleigh, S., and S. Farrell, "Licklider 926 Transmission Protocol", 927 draft-irtf-dtnrg-ltp-05.txt, work-in-progress, September 2006. 929 [7] Farrell, S., Ramadas, M., and S. Burleigh, "Licklider 930 Transmission Protocol - Extensions", 931 draft-irtf-dtnrg-ltp-extensions-04.txt, work-in-progress, 932 September 2006. 934 [8] Burleigh, S., Ramadas, M., and S. Farrell, "Licklider 935 Transmission Protocol - Motivation", 936 draft-irtf-dtnrg-ltp-motivation-03.txt, work-in-progress, 937 September 2006. 939 [9] Zhou, L. and Z. Haas, "Securing Ad-Hoc Networks", IEEE 940 network vol 13, no. 6, Nov-Dec 1999, pp 24-30. 942 [10] Dierks, T. and C. Allen, "The TLS Protocol - Version 1.0", RFC 943 2246 , January 1999. 945 Authors' Addresses 947 Stephen Farrell 948 Trinity College Dublin 949 Distributed Systems Group 950 Department of Computer Science 951 Trinity College 952 Dublin 953 Ireland 955 Phone: +353-1-608-1539 956 Email: stephen.farrell@cs.tcd.ie 958 Susan Flynn Symington 959 The MITRE Corporation 960 7515 Colshire Drive 961 McLean, VA 22102 962 US 964 Phone: 703 983 7209 965 Email: susan@mitre.org 966 URI: http://mitre.org/ 968 Howard Weiss 969 SPARTA, Inc. 970 7075 Samuel Morse Drive 971 Columbia, MD 21046 972 US 974 Phone: +1-410-872-1515 x201 975 Email: hsw@sparta.com 977 Full Copyright Statement 979 Copyright (C) The Internet Society (2006). 981 This document is subject to the rights, licenses and restrictions 982 contained in BCP 78, and except as set forth therein, the authors 983 retain all their rights. 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 Intellectual Property 995 The IETF takes no position regarding the validity or scope of any 996 Intellectual Property Rights or other rights that might be claimed to 997 pertain to the implementation or use of the technology described in 998 this document or the extent to which any license under such rights 999 might or might not be available; nor does it represent that it has 1000 made any independent effort to identify any such rights. Information 1001 on the procedures with respect to rights in RFC documents can be 1002 found in BCP 78 and BCP 79. 1004 Copies of IPR disclosures made to the IETF Secretariat and any 1005 assurances of licenses to be made available, or the result of an 1006 attempt made to obtain a general license or permission for the use of 1007 such proprietary rights by implementers or users of this 1008 specification can be obtained from the IETF on-line IPR repository at 1009 http://www.ietf.org/ipr. 1011 The IETF invites any interested party to bring to its attention any 1012 copyrights, patents or patent applications, or other proprietary 1013 rights that may cover technology that may be required to implement 1014 this standard. Please address the information to the IETF at 1015 ietf-ipr@ietf.org. 1017 Acknowledgment 1019 Funding for the RFC Editor function is provided by the IETF 1020 Administrative Support Activity (IASA).