idnits 2.17.00 (12 Aug 2021) /tmp/idnits42588/draft-birrane-dtn-sec-practices-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' security considerations. Since the concept of resource sharing' ) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 29, 2015) is 2328 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: draft-ietf-dtn-bpsec has been published as RFC 9172 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Delay-Tolerant Networking E. Birrane 3 Internet-Draft Johns Hopkins Applied Physics Laboratory 4 Intended status: Experimental December 29, 2015 5 Expires: July 1, 2016 7 DTN Security Best Practices 8 draft-birrane-dtn-sec-practices-00 10 Abstract 12 This document describes best practices associated with achieving a 13 variety of security use cases with the set of DTN-related standards. 15 Status of This Memo 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF). Note that other groups may also distribute 22 working documents as Internet-Drafts. The list of current Internet- 23 Drafts is at http://datatracker.ietf.org/drafts/current/. 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 This Internet-Draft will expire on July 1, 2016. 32 Copyright Notice 34 Copyright (c) 2015 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents 39 (http://trustee.ietf.org/license-info) in effect on the date of 40 publication of this document. Please review these documents 41 carefully, as they describe your rights and restrictions with respect 42 to this document. Code Components extracted from this document must 43 include Simplified BSD License text as described in Section 4.e of 44 the Trust Legal Provisions and are provided without warranty as 45 described in the Simplified BSD License. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 50 1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 2 51 1.2. Motivation for Application-Layer Security . . . . . . . . 2 52 1.3. Scope of Security Information . . . . . . . . . . . . . . 3 53 1.4. Classes of Security Information . . . . . . . . . . . . . 4 54 1.5. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 5 55 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6 56 2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 6 57 2.2. Bundle Protocol Review . . . . . . . . . . . . . . . . . 6 58 2.3. Bundle Protocol Security (BPSEC) . . . . . . . . . . . . 6 59 2.4. Bundle-in-Bundle Encapsulation . . . . . . . . . . . . . 7 60 3. Policy Considerations . . . . . . . . . . . . . . . . . . . . 8 61 4. Best Practices . . . . . . . . . . . . . . . . . . . . . . . 9 62 4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 9 63 4.2. Bundle Source End-to-End Block Security . . . . . . . . . 9 64 4.3. Waypoint Block Security . . . . . . . . . . . . . . . . . 10 65 4.4. Security Destinations . . . . . . . . . . . . . . . . . . 10 66 4.5. Cascading Operations . . . . . . . . . . . . . . . . . . 11 67 4.6. Hop by Hop Authentication . . . . . . . . . . . . . . . . 13 68 4.7. Path Verification . . . . . . . . . . . . . . . . . . . . 14 69 4.8. Parallel Authenticators/Decrypters . . . . . . . . . . . 15 70 4.9. Primary Block Integrity . . . . . . . . . . . . . . . . . 16 71 4.10. Primary Block Privacy . . . . . . . . . . . . . . . . . . 16 72 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 73 6. Informative References . . . . . . . . . . . . . . . . . . . 17 74 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17 76 1. Introduction 78 1.1. Overview 80 This document outlines the motivation for an end-to-end, application 81 layer security capability as the collaborative effect of individual 82 capabilities. Such a mix-and-match model of applying services allows 83 for the more effective securing of a diverse set of disparate 84 challenged internetworking scenarios. 86 In the context of this document, security refers to providing for the 87 end-to-end integrity and confidentiality of application data. 89 1.2. Motivation for Application-Layer Security 91 Path diversity in a packetized, wireless internetwork increases 92 resiliency to loss of individual links. However, packetization and 93 multi-path, multi-hop communication severs the relationship between 94 user data and a communications link; it is no longer sufficient to 95 tightly control a single communication link to provide security for 96 data exchange. The packets that comprise user data, by definition, 97 may traverse multiple links as they traverse the network and 98 accumulate at some user destination. 100 Securing link layers is not a sufficient mechanism for securing end- 101 to-end data for two reasons, as follows. 103 Impractical Coordination of Multiple Links: 104 Every link and enclave participating in the message path must 105 coordinate to ensure that a particular data exchange retains all 106 necessary security services. This is intractable when thousands 107 of packets representing a single set of user data flow over 108 multiple links and through multiple enclaves. 110 Shared Security Access Over Shared Links: 111 Different users of an internetwork may require different 112 security considerations. Since the concept of resource sharing 113 drives the adoption of internetworking, multiple missions will 114 want to use individual links to amortize the cost of resilient 115 communications. If security is restricted to links only, then 116 every user sharing the link must use the same security services 117 of the link. In such a scenario, there is no mechanism to 118 finely tune per-user security settings. 120 1.3. Scope of Security Information 122 At least three scopes of security exist in a packetized internetwork: 123 Link, Enclave, and End-to-End. These are based, loosely and 124 conceptually, on the Unix file permission concept of "User", "Group", 125 and "Other". 127 +------------+------------------------------------------------------+ 128 | Layer | Responsibilities | 129 +------------+------------------------------------------------------+ 130 | Link | - point-to-point data exchange protected from data | 131 | | corruption. | 132 | | | 133 | | - link-specific security mechanisms at both the | 134 | | physical and data layers. | 135 | | | 136 | | - Ensures transmissions over the link are | 137 | | authenticated and preserve the integrity and | 138 | | confidentiality of the message. | 139 | | | 140 | | | 141 | | | 142 | Enclave | - Bound administrative and/or technical domains. | 143 | | | 144 | | - Abstract link details when links within one | 145 | | enclave behave differently than links in another. | 146 | | | 147 | | | 148 | | | 149 | End-to-End | - Ensure that application data is secured regardless | 150 | | of links or enclaves. | 151 | | | 152 | | - Remove assumptions based on a particular path of a | 153 | | packet in the network or other underlying security | 154 | | mechanisms. | 155 +------------+------------------------------------------------------+ 157 Logical Security Scopes 159 1.4. Classes of Security Information 161 Three types of security-related information are considered by this 162 document: Security-Related Protocols, Node Security Policy, and 163 Cipher Suite Support. 165 Security-Related Protocols: 166 Protocols identify the data models, model encodings, and control 167 information associated with the communication and application of 168 the data model across a network. 170 Node Security Policy: 171 Security policy describes how individual nodes within a network 172 populate the data models associated with the protocols providing 173 data security. It is possible for multiple nodes in an 174 internetwork to implement identical protocols but to use 175 different features of those protocols based on local or group 176 policy. This policy may be derived from data directly or 177 indirectly related to security and, therefore, policy drivers 178 must be considered separately from security protocols. 180 Cipher Suite Support: 181 Separate from protocol features and the policy that determines 182 what features to apply when, cipher suites generate the data 183 that is carried by security protocols. Since multiple cipher 184 suites can be used to generate the data used to populate the 185 data model of security-related protocols, cipher suite support 186 must be considered separately from protocols. 188 1.5. Scope 190 This document addresses how to achieve a series of application-layer, 191 end-to-end security functions via combinations of protocols, 192 policies, and cipher suites. This document does not provide the full 193 specification for any single protocol, policy, or cipher suite. 195 Specifically, this specification provides ways to achieve the 196 following kinds of behavior in an internetwork supporting certain 197 protocols and implementing certain policies and cipher suites. 199 Decoupled Routing and Security. 200 Original transmitters and forwarders of a bundle may wish to 201 apply security settings based on some envisioned end point for a 202 security service. However, it is unlikely in a general 203 internetworking deployment that a node will know the exact path 204 taken by a bundle through an internetwork. This is particularly 205 the case when the internetwork spans multiple enclaves with 206 different administrative policies. Therefore, security services 207 must be independent of individual message paths. 209 Make Common Cases Simple and Efficient. 210 There exists a common set of security services that are applied 211 to bundles, namely the end-to-end integrity and confidentiality 212 of message payloads. While there exist many exotic permutations 213 of security services for various internetworking use cases, this 214 simple and common case must remain effective and efficient so as 215 to not penalize simpler networks to accommodate complex 216 networks, whenever possible. 218 Provide Security Services Equally. 219 Messages exchanged within a DTN may have multiple security 220 services applied to different parts of them. For example, 221 security services applied to message headers separately from 222 secondary headers or payloads. To the extent possible, the 223 implementation of security functions should be agnostic to the 224 type of data being secured. 226 2. Protocol Overview 228 2.1. Overview 230 This section provides a brief overview of the protocols considered by 231 this best practice document. This section covers only those 232 significant functional aspects necessary to inform the discussion of 233 how to combine functions for security services. Protocols covered by 234 this document include the Bundle Protocol (BP) [RFC5050], Bundle 235 Protocol Security (BPSec) [BPSec], and Bundle-in-Bundle Encapsulation 236 (BIBE) [BIBE]. 238 2.2. Bundle Protocol Review 240 The Bundle Protocol (BP) is a packetized, overlay, store-and-forward 241 protocol proposed for the exchange of data in a variety of challenged 242 internetworking scenarios. A BP protocol data unit (PDU) is 243 characterized as a series of variable-length blocks, with two special 244 blocks required in the bundle and all other blocks optional. The two 245 required blocks are the primary block (which acts as a message 246 header) and the payload block, which is a standard payload area. 247 Additional blocks, called extension blocks and conceptually similar 248 to secondary headers, may also be added to the bundle. Extension 249 blocks may be added at any time, and by any node, as the bundle 250 traverses the internetwork. Bundles are addressed using End Point 251 Identifiers (EIDs), which identify an overlay destination (endpoint) 252 in the internetwork. The mapping between EIDs and nodes in the 253 network is many-to-many, so a node may be associated with several 254 EIDs, and one EID may be associated with multiple nodes to form a 255 multi-cast address. 257 2.3. Bundle Protocol Security (BPSEC) 259 The security standard currently proposed for BP and DTN is the Bundle 260 Protocol Security (BPSEC). BPSec defines security services captured 261 in extension blocks that may be applied to discrete portions of a 262 bundle. BPSec, as a protocol, operates at the "Group" and "World" 263 layer, without reliance on link security mechanisms. Policy 264 decisions on how BPSec services should or should not be applied to a 265 bundle may or may not choose to consider link layer mechanisms. 267 BPSec provides two extension blocks that capture integrity and 268 confidentiality services for other blocks within a bundle, as 269 follows. 271 Block Integrity Blocks (BIB): 272 BIBs provide an integrity signature over some other block in the 273 bundle, such that a chance to the contents of the protected 274 "target" block would be detected by comparing the signature 275 captured in the BIB with a signature directly computed from the 276 contents of the target block. 278 Block Confidentiality Blocks (BCB): 279 BCBs provide a confidentiality mechanism over some other block 280 in the bundle. A BCB captured annotative information as to how 281 a protected, "target" block has been encrypted and the content 282 of the target block is re-written with ciphertext. 284 Note, BPSec does not specify the cipher suites used to populate the 285 BIB and BCB blocks. The selection of cipher suites and keys to 286 generate necessary data is a matter of policy. 288 2.4. Bundle-in-Bundle Encapsulation 290 Typically, the payload of a bundle contains some user or application 291 data (or a fragmented portion of such data). The BIBE protocol 292 provides a mechanism by which one bundle can be set as the payload of 293 another bundle. This introduces the terminology of encapsulated and 294 encapsulating bundles, as follows. 296 Encapsulated Bundle: 297 An encapsulated bundle is a bundle that is serialized, in whole, 298 as the payload of some other bundle. Once encapsulated, the 299 bundle is indistinguishable from a block of application payload 300 on the wire and is not treated as a bundle until it is extracted 301 at the destination if its encapsulating bundle. At the 302 encapsulating bundle destination, the encapsulated bundle is 303 extracted and passed to the destination as if it had been 304 delivered there directly. 306 Encapsulating Bundle: 307 An encapsulating bundle is a bundle which has, as its payload, 308 an encapsulated bundle. Any extension blocks or policy 309 decisions made regarding this encapsulating bundle are separate 310 from the encapsulated bundle. The encapsulated bundle is 311 treated solely as a payload until the encapsulating bundle 312 reaches its destination, at which point the encapsulating bundle 313 is discarded and the encapsulated bundle is reconstituted and 314 given to the node for processing. 316 The BIBE mechanism is used to create tunnels with the BP 317 specification and is a useful way to maintain a separation between 318 security and routing while allowing some way to introduce required 319 security waypoints in a path. Namely, while it is not possible, in 320 the general case, to tell a single bundle to traverse multiple 321 specific nodes from end to end, it is possible to establish multiple 322 tunnels for the bundle to pass through using the BIBE mechanism. 324 3. Policy Considerations 326 Policies and configurations must be documented separately from both 327 implementing protocols and best practices. Since the primary value 328 of sharing policy and configuration information is to ensure the 329 interoperability of multiple security services this information 330 should be standardized whenever possible. Security policy documents 331 should identify what security services are required in given network 332 deployments and what actions should be taken when messages do not 333 adhere to these expectations. 335 The following policy scenarios are strongly recommended for 336 consideration in any such documentation relating to standards for DTN 337 security. 339 Less Security Than Required: 340 When the network requires a certain level of security, such as 341 encrypted payloads or authenticated message exchange and a 342 message is received without this information, the network must 343 handle this in a uniform way. Most policies require not 344 forwarding the message, but the level of logging, error 345 messaging, and updates to local configurations should be 346 discussed as a matter of policy. 348 More Security Than Required: 349 Similarly, when messages are received that contain 350 authentication, integrity, or confidentiality when they should 351 not, a decision must be made as to whether these services will 352 be honored by the network. 354 Security Evaluation In Transit: 355 Some security services may be evaluated at a node, even when the 356 node is not the bundle destination or a security destination. 357 For example, a node may choose to validate an integrity 358 signature of a bundle block. If an integrity check fails to 359 validate, the intermediate node may choose to ignore the error, 360 remove the offending block, or remove the entire bundle. 362 Fragmentation: 363 Policy must determine how security blocks are distributed 364 amongst the new bundle fragments, so as to allow received 365 fragments to be validated at downstream nodes 367 Block and Bundle Severability: 368 Distinct from fragmentation, nodes must decide whether a 369 security error associated with a block implies a larger security 370 error associated with the bundle. If blocks and bundles are 371 considered severable, then an offending block may be omitted 372 from the bundle. Otherwise, a bundle should be discarded 373 whenever any of its constituent blocks are discarded. 375 4. Best Practices 377 4.1. Overview 379 Complex security activities are achieved through the combination of 380 multiple discrete protocols rather than the creation of tightly- 381 coupled, highly-purposed protocols. Given a set of loosely coupled, 382 highly cohesive protocols, a set of best-practices can be provided to 383 implement security operations. 385 4.2. Bundle Source End-to-End Block Security 387 4.2.1. Need 389 This is the common case for block-level security services. In this 390 case, a bundle source wishes to apply integrity and/or 391 confidentiality to one or more blocks in a bundle and for these 392 services to persist until the bundle reaches its destination. 394 4.2.2. Recommended Practice 396 This is the common case supported directly by BPSec without 397 modification. In this case, each block being protected will have an 398 additional security block (BIB or BCB) added to the bundle. The BIB 399 and BCB blocks will contain all necessary security information based 400 on cipher suites which must be selected in accordance with some 401 policy at the node. Once the BIB and BCB blocks are added to the 402 bundle, the bundle may be sent through the network and no additional 403 operations are necessary until the bundle reaches the destination, at 404 which point BIBs and BCBs are verified and processed in accordance 405 with the BPSec specification. 407 4.2.3. Additional Policy Considerations 409 Transmit Rules: 410 The originating node must determine, by policy and 411 configuration, what services are necessary based on the 412 destination of the bundle. 414 Key and Cipher Suite Selection: 416 The originating node must determine which keys are used to 417 configure which cipher suites will populate the necessary 418 blocks. 420 4.3. Waypoint Block Security 422 4.3.1. Need 424 Certain network configurations may require that security services be 425 added to a bundle by a waypoint node rather than the originator of 426 the bundle. A motivating example of this need is a network where a 427 bundle requires only integrity services within an enclave but 428 requires confidentiality before the bundle leaves the enclave to 429 route over a more public network. In such cases, a gateway node at 430 the border of the enclave and the public network may add 431 confidentiality services to any bundle that does not already have 432 such services before allowing the bundle to leave the enclave. 434 4.3.2. Recommended Practice 436 This is a minor extension to the case where the bundle source adds a 437 security block. In this case, BPSec blocks (BIB and BCB) are also 438 added to the bundle, but the security source of these blocks is 439 listed as the waypoint node adding the block, rather than the bundle 440 source node. The processing and behavior of the block is, otherwise, 441 unchanged. 443 4.3.3. Additional Policy Considerations 445 The policy considerations for a waypoint adding a security service 446 are the same as when a bundle source adds a security service. 448 4.4. Security Destinations 450 4.4.1. Need 452 There may be times when a bundle is requested to go through a 453 specific waypoint node en-route to its destination. From a security 454 standpoint, this is typically done to ensure that some security 455 result is achieved, for example ensuring that a bundle goes through a 456 specific gateway for appending extra security services. 458 4.4.2. Recommended Practice 460 The current recommended practice for general networks to accomplish 461 security-related destinations is to use the BIBE to wrap a bundle 462 into an encapsulating bundle, and then use the security destination 463 as the destination of the encapsulating bundle. In this way, the 464 routing mechanism used in the network is not coupled to the security 465 system, and the encapsulated bundle is not burdened with tracking 466 multiple intermediate destinations. 468 This is the equivalent of creating a tunnel between the current node 469 and the security destination. If, at the security destination, a 470 subsequent security destination is necessary, the process may be 471 repeated. 473 4.4.3. Additional Policy Considerations 475 Security Destination Identification 476 To require security destinations, there must be some mechanism 477 by which security destinations are identified and some other 478 mechanism to associate bundles with those security destinations. 480 Extension Block Handling 481 Care must be taken to process, correctly, extension blocks both 482 in the encapsulated bundle and the encapsulating bundle. There 483 may exist extension blocks in the encapsulated bundle that wish 484 to be processed at every hop taken by the bundle, even while it 485 encapsulated. In such situations it might be possible to carry 486 these blocks in the encapsulating bundle and merge them back 487 into the encapsulated bundle at the security destination. Note, 488 however, there is no standard for this. 490 4.5. Cascading Operations 492 4.5.1. Need 494 Cascading operations are security services that are applied to the 495 same data multiple times, such as is the case when performing super- 496 encryption. The BPSec standard does not allow the same security 497 service to be applied to the same target data multiple times (for 498 example, a payload cannot be encrypted twice with two BCBs). 500 There are several reasons for wanting to replace or modify security 501 services found in a bundle. Policy may require a stronger security 502 service before a bundle is allowed to leave an enclave. 503 Alternatively, portions of the network may be configured with 504 different cipher suite support rendering in-situ integrity checking 505 impossible unless a new integrity signature in a supported cipher 506 suite is added. At times, encrypting parts of an existing BCB or BIB 507 to hide cipher suite details may be required. 509 4.5.2. Recommended Practice 511 When cascading operations are to be applied from the current node to 512 the bundle destination each of these practices can be applied 513 directly to the bundle. In cases where cascading operations are only 514 to be applied from the current node to someplace other than the 515 bundle destination then, first, Security Destination best practices 516 must be applied. 518 There are three recommended ways to satisfy this need in BP networks: 519 Bundle encapsulation, Block encapsulation, and custom blocks. 521 Bundle Encapsulation: 522 There have been many proposals relating to how to stack security 523 operations amongst blocks in a bundle. However, each of these 524 results in complex situations regarding the order in which 525 operations are applied and how to preserve meaning in the 526 presence of fragmentation. 528 This approach maintains the BPSec restriction of one security 529 service per target in a single bundle and use BIBE and 530 encapsulation. In such a scheme, the existing bundle becomes 531 the encapsulated bundle. The encapsulating bundle then applies 532 whatever additional security services are necessary to its 533 payload, thereby applying them to the encapsulated bundle. 535 Block Encapsulation 536 There is, currently, no standard for block encapsulation. 537 However, the target block and its associated security blocks 538 may, themselves, be packed into a single new block within the 539 bundle and new security services may be added to that 540 encapsulating block. 542 Custom Security 543 A set of custom security blocks can be defined by a particular 544 network that operate orthogonally from the BPSec security 545 blocks. This proves fine-grained control over security in 546 specific network deployments. This method is only practical in 547 closed, highly controlled networks where custom block definition 548 and processing is both technically feasible and economical. 550 4.5.3. Additional Policy Considerations 552 Security Service Identification: 553 Nodes in the network must be able to identify appropriate 554 security services and cipher suites to some understood 555 destination. 557 4.6. Hop by Hop Authentication 559 4.6.1. Need 561 Hop by hop authentication ensures that a received bundle's last hop 562 (i.e. most recent forwarder) matches what the bundle claims it's last 563 hop to be. Checking each hop along a path in the network is one way 564 to establish a chain of trust. More importantly, verifying the 565 appropriateness of the node who sent a received bundle is a way of 566 protecting networks against certain types of attacks. Specifically, 567 the internals of a network can be protected against resource- 568 consuming attacks if a gateway node can detect inappropriate traffic 569 and prevent its ingest into the rest of the network. 571 4.6.2. Recommended Practice 573 There are three recommended ways to satisfy this need in BP networks: 574 Reliable link layers, integrity on ephemeral blocks, and 575 canonicalized whole-bundle signatures. 577 Reliable Link Layers: 578 By definition, link-layer security secures the transmission 579 between two points (a link) in a network. Wherever hop-by-hop 580 authentication is required, the network might simply require the 581 use of a secure point-to-point link layer. In such a case, 582 there is no need for an application-layer mechanism for hop-by 583 hop security. 585 Ephemeral Block Integrity: 586 Assuming that secure link layers are not guaranteed to be 587 available, a second practice is to insert a short-lived 588 (ephemeral) block into a bundle just prior to transmission that 589 identifies the transmitter of the bundle, sign that block with a 590 BPSec BIB, and then transmit the bundle. 592 Such an ephemeral block is defined in the BP specification as a 593 Prior Hop Notification (PHN) Block and can be used for this 594 purpose. Alternatively, a user may define their own block type 595 which can hold any information they wish, to include a signature 596 calculated over the entire bundle rather than an assertion of 597 the previous bundle transmitter. 599 When the bundle is received at the next hop, this ephemeral 600 block can be verified to ensure that the node that signed the 601 block is the same as the node referenced in the block. At this 602 point, the ephemeral block and its associated BIB are no longer 603 necessary and can be either removed from the bundle or kept for 604 historical accounting with the bundle. 606 Canonicalized Whole-Bundle Signature: 607 The signing of an ephemeral block such as the PHN does not 608 provide a guarantee that the contents of the bundle remained 609 unchanged across the hop. in the extreme case where the entire 610 contents of the bundle must be authenticated at every hop in the 611 bundle, a canonicalized form of the bundle must be generated and 612 signed by the transmitting node and then check at the next hop 613 of the bundle. 615 The most straightforward way to achieve this is to use the BIBE 616 to encapsulate the entire bundle as the payload of an 617 encapsulating block, place a BIB on the encapsulating block 618 payload, and then make the next hop the destination of the 619 encapsulating block. 621 4.6.3. Additional Policy Considerations 623 Applicability: 624 By global policy or by next-hop, a transmitting node must have 625 some way of determining that hop-by-hop authentication is 626 necessary and that either a secure link layer, an ephemeral 627 block, or some other method is needed to protect the 628 transmission. 630 Link Layer Identification: 631 When using secure link layers, the BPA must have some mechanism 632 of determining if the link layer selected for transmission has 633 an appropriate security model. 635 4.7. Path Verification 637 4.7.1. Need 639 A common request in a secured internetwork is to provide a signed 640 listing of each node traversed by a bundle on its way from sender to 641 receiver. 643 4.7.2. Recommended Practice 645 There are three recommended practices for accomplishing this task: 646 Per-Hop Extension Blocks, a Signed Log, and an Encrypted Log. 648 Per-Hop Extension Blocks: 649 A new extension block can be added to the bundle at each node, 650 and that new block can be integrity signed by BPSec. In 651 networks using the Previous Hop Notification (PHN) block, the 652 PHNs can be signed and kept for each hop. 654 Signed Log: 655 A single extension block can be defined to act as a log book of 656 visited nodes, such that each node visited by the bundle adds a 657 new, signed data entry into the log. 659 Encrypted Log: 660 This approach works similarly to a Signed Log, except that the 661 extension block is encrypted with a BCB and only those nodes in 662 the network with the appropriate keys can decrypt and modify the 663 log. 665 4.7.3. Additional Policy Considerations 667 None. 669 4.8. Parallel Authenticators/Decrypters 671 4.8.1. Need 673 Security in the context of multicasting presents challenging 674 operational concepts for how to validate a received bundle that 675 carries multiple integrity signatures. In this case, a bundle should 676 validate a security service if any one of multiple security data 677 items is verified. 679 4.8.2. Recommended Practice 681 It is recommended that a multi-case cipher suite specification be 682 defined and used to generate multiple signatures (for integrity) or 683 multiple ciphertexts (for confidentiality). This approach allows 684 BPSec to operate without modification, as the cipher suite 685 implementation both generates and verifies security results. 687 Multiple signatures would be stored directly in the BIB as part of 688 cipher suite data. Such cipher suites could verify a signature if 689 any 1 signature matched, if N of M signatures matched, or if all 690 signatures match, based on policy. 692 Multiple encryptors could work by encrypted the plaintext multiple 693 times to generate multiple ciphertexts which, in total, would replace 694 the plain text in a specific block in the bundle. Additionally, the 695 bundle source or other identifying information could be encrypted 696 once per key and stored as additional authenticated data. On 697 decryption, a node could determine the appropriate ciphertext to use 698 by decrypting the bundle source from the additional authenticated 699 data and then decrypting the ciphertext associated with that key. 701 4.8.3. Additional Policy Considerations 703 Key Lists: 704 Each node that encrypts, decrypts, or authenticates based on a 705 multi-cast cipher suite would need to keep a list of each key 706 used. 708 4.9. Primary Block Integrity 710 4.9.1. Need 712 It may be necessary to ensure that the primary block in a bundle has 713 not changed since the bundle was first transmitted. 715 4.9.2. Recommended Practice 717 The BPSec allows the BIB to target the primary block, just as it can 718 target any other block in a bundle. As such, this capability can be 719 accomplished by inserting a BIB in the bundle whose target is the 720 primary block. 722 4.9.3. Additional Policy Considerations 724 None. 726 4.10. Primary Block Privacy 728 4.10.1. Need 730 It may be necessary in certain cases to hide the contents of a 731 primary block for portions of a bundle journey. 733 4.10.2. Recommended Practice 735 There are two recommended practices for accomplishing this task: 736 Encapsulation and Custom Extension Blocks. 738 Encapsulation: 739 The most straightforward way to hide portions of the primary 740 block is to use BIBE to encapsulate the entire bundle. Then, 741 the encapsulating block can have whatever primary block 742 information is necessary to get the bundle through the portions 743 of the network where the original primary block should be 744 hidden. In this case, the encapsulated bundle should be 745 encrypted with a BCB from the encapsulating block. 747 Custom Extension Block 748 A custom extension block may be defined to hold the contents of 749 the primary block. A temporary primary block can be constructed 750 at various points in the network as part of processing the 751 custom extension block. This temporary primary block would have 752 only that information necessary to get the bundle to some next 753 known node. 755 4.10.3. Policy Considerations 757 While there is no specific policy consideration, the concept of 758 performing surgery on the primary block of a bundle in transit must 759 be taken with great care. 761 5. IANA Considerations 763 This document has no fields registered by IANA. 765 6. Informative References 767 [BIBE] Burleigh, S., "Bundle-in-Bundle Encapsulation", draft- 768 irtf-burleigh-bibe-00 (work in progress), March 2013. 770 [BPSec] Birrane, E., Mayer, J., and D. Iannicca, "Bundle Protocol 771 Security", draft-ietf-dtn-bpsec-00 (work in progress), 772 December 2015. 774 [RFC5050] Scott, K. and S. Burleigh, "Bundle Protocol 775 Specification", RFC 5050, DOI 10.17487/RFC5050, November 776 2007, . 778 Author's Address 780 Edward J. Birrane 781 Johns Hopkins Applied Physics Laboratory 783 Email: Edward.Birrane@jhuapl.edu