idnits 2.17.1 draft-li-dtn-hybrid-integrity-04.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 : ---------------------------------------------------------------------------- ** There are 9 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 27, 2017) is 2396 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-27) exists of draft-ietf-dtn-bpsec-05 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Delay-Tolerant Networking Taixin Li 2 Internet Draft Guanwen Li 3 Intended status: Informational Huachun Zhou 4 Expires: March 27, 2018 Beijing Jiaotong University 5 September 27, 2017 7 A Hybrid Integrity Assurance Strategy for Bundle Protocol 8 draft-li-dtn-hybrid-integrity-04.txt 10 Status of this Memo 12 This Internet-Draft is submitted in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 This document may contain material from IETF Documents or IETF 16 Contributions published or made publicly available before November 10, 17 2008. The person(s) controlling the copyright in some of this 18 material may not have granted the IETF Trust the right to allow 19 modifications of such material outside the IETF Standards Process. 20 Without obtaining an adequate license from the person(s) controlling 21 the copyright in such materials, this document may not be modified 22 outside the IETF Standards Process, and derivative works of it may 23 not be created outside the IETF Standards Process, except to format 24 it for publication as an RFC or to translate it into languages other 25 than English. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF), its areas, and its working groups. Note that 29 other groups may also distribute working documents as Internet-Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html 42 This Internet-Draft will expire on March 27, 2018. 44 Copyright Notice 46 Copyright (c) 2017 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents carefully, 53 as they describe your rights and restrictions with respect to this 54 document. Code Components extracted from this document must include 55 Simplified BSD License text as described in Section 4.e of the Trust 56 Legal Provisions and are provided without warranty as described in 57 the Simplified BSD License. 59 Abstract 61 Delay/Disruption Tolerant Networking (DTN) is designed for a severe 62 environment where communication quality is not guaranteed. It works 63 as an overlay network associated with Bundle Protocol (BP) and some 64 convergence layer protocols like Licklider Transmission Protocol 65 (LTP). However, there is no mechanism in both BP and LTP Protocol to 66 ensure integrity of a packet with the granularity of bit. Since the 67 integrity is crucial for packet transmission and necessary metadata 68 consumes extra costs, there should be a strategy to decide which 69 packets and how the packets are required to conduct integrity 70 assurance based on network resources and user requirements. Hence, in 71 this document, a hybrid integrity assurance strategy is proposed to 72 ensure the different levels of integrity of bundles based on the 73 status of network resources and the need of users. 75 Table of Contents 77 1. Introduction ................................................ 3 78 2. Conventions used in this document ............................ 3 79 3. Checksum Block Format ........................................ 4 80 4. Processing Rules of Integrity Detection ...................... 5 81 4.1. Processing Rules in Source Nodes ........................ 6 82 4.2. Processing Rules in Intermediate Nodes .................. 8 83 4.3. Processing Rules in Destination Nodes ................... 9 84 5. Error correcting code-based detecting mechanism ............. 10 85 6. Security Considerations ..................................... 11 86 7. IANA Considerations ........................................ 11 87 8. Conclusions ................................................ 11 88 9. References ................................................. 12 89 9.1. Normative References ................................... 12 90 9.2. Informative References ................................. 12 91 10. Acknowledgments ........................................... 13 93 1. Introduction 95 Delay/Disruption Tolerant Networking (DTN) [RFC4838] is designed for 96 a severe environment where connectivity of network is intermittent 97 and communication quality is not guaranteed. It works as an overlay 98 network associated with Bundle Protocol (BP) [RFC5050] and 99 convergence layer protocols like Licklider Transmission Protocol (LTP) 100 [RFC5325] [RFC5326]. BP, which is an application layer protocol, is 101 based on a custody transfer mechanism and defines how to forward 102 bundles in DTN, while LTP ensures the reliability of bundle 103 transmission with the granularity of packet. However, there is no 104 mechanism in both BP and LTP Protocol to ensure integrity of a packet 105 with the granularity of bit. Integrity is crucial for packet 106 transmission since errors in the header leads to some unexpected 107 results while errors in the payload results in end-to-end 108 retransmission and waste of limited storing and link resources. 110 BPSEC [I-D.ietf-dtn-bpsec-02] defines a security protocol providing 111 end to end data integrity and confidentiality services for the Bundle 112 Protocol. However, necessary checksum metadata consumes costs, so 113 there should be a strategy to decide which packets and how the 114 packets are required to conduct integrity assurance based on the 115 network resources, such as buffer utilization rate, bandwidth, and 116 packet loss rate. 118 In this document, we define a new type of extension block to carry 119 the checksum field. Furthermore, we propose a hybrid integrity 120 assurance strategy to ensure the different levels of integrity of 121 bundles based on the status of network resources and the need of 122 users. The intermediate nodes make a hop-by-hop integrity detection 123 strategy according to network status while the end user makes an end- 124 to-end integrity detection strategy. 126 2. Conventions used in this document 128 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 129 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 130 document are to be interpreted as described in RFC 2119 [RFC2119]. 132 3. Checksum Block Format 134 There are three parts in the bundle packet, primary block, payload 135 block, and extension block. Extension Block is designed to carry 136 additional information that DTN nodes can use to make processing 137 decisions that are related to bundles. 139 We define a new type of extension block and use it to carry the 140 checksum information in this document, and the basic format is based 141 on [RFC6258], which defines DTN metadata extension block. 143 The format of checksum block is as follows: 145 Checksum Block Format: 147 +------+-------+--------------------------------------------+ 148 | Type | Flags | Length |Class of Detection|Type of Checksum| 149 | | (SDNV)| (SDNV) | (SDNV) | (SDNV) | 150 +------+----------------+------------------+----------------+ 151 | Checksum | 152 | | 153 +-----------------------------------------------------------+ 155 Figure 1 Checksum Block Format 157 o Block type code (1 byte) - defined in all bundle protocol blocks 158 except the primary bundle block (as described in the Bundle 159 Protocol). The block-type code for checksum is 0x20. 161 o Block processing control flags (SDNV) - defined in all bundle 162 protocol blocks except the primary bundle block. SDNV encoding is 163 described in the Bundle Protocol. The following block processing 164 control flag MUST be set "4 - Discard block if it can't be 165 processed", which means that if a bundle node receives a bundle 166 with a checksum block and it is not capable of supporting the 167 checksum block, it just discards this block without processing it. 169 o Block data length (SDNV) - defined in all bundle protocol blocks 170 except the primary bundle block. SDNV encoding is described in the 171 Bundle Protocol. 173 o Class of detection (SDNV) - (CoD) indicates the bundle's class of 174 detection, which decides whether a bundle packet should conduct an 175 integrity assurance and which part should be detected. CoD is 176 decided by two factors, network resources status and user 177 requirements. For now, it contains three types: 00 = inadequate 178 resources, 01 = adequate resources, 10 = mandatory detection. Here, 179 00 and 01 are determined by the network status, and 10 is decided 180 by the user. The users have a higher priority, which means that if 181 CoD = 10, the bundle packets should be detected no matter what the 182 network status is. 184 o Type of Checksum (SDNV) - (ToC) indicates the type of checksum 185 data. For now, it contains four types: 00 = checksum of primary 186 block, 01 = checksum of payload block, 10 = checksum of primary 187 block and payload block, 11 = no checksum of either primary block 188 or payload block. 190 o Checksum data - contains the raw checksum data itself, which is 191 generated by some algorithms. 193 4. Processing Rules of Integrity Detection 195 As is discussed in [WOOD09] and [I-D.templin-dtnhiaps-00], integrity 196 detection is required on intermediate nodes in addition to 197 destination nodes. In order to make full use of the limited resources 198 in the severe environments, both the source nodes and the 199 intermediate nodes should monitor the usage rate of their resources 200 such as the storage and link. Then different integrity assurance 201 strategies will be made according to network resources status and 202 user requirements. The integrity detection is called if the network 203 resources are inadequate, the custody is needed, or it is demanded by 204 end users. Besides, intermediate nodes detect the header/primary 205 block or the payload block according to the Type of Checksum field 206 carried in the checksum block. If there are errors in the packet data, 207 forwarding process is stopped and retransmission is called. When the 208 destination nodes receive packets, they detect the checksum block and 209 if there are errors in the packet data, retransmission will be called. 211 4.1. Processing Rules in Source Nodes 213 +--------------+ 214 +-----+Create new CoD+-----+ 215 | +-------+------+ | 216 | | | 217 +----v----+ +-----v----+ +----v----+ 218 | CoD=00 | | CoD=10 | | CoD=01 | 219 +----+----+ +--+-------+ +----+----+ 220 | | | 221 +----v----+ | +----v----+ 222 +--+ Custody +--+ | +--+ Custody +--+ 223 | +---------+ | | | +---------+ | 224 v v | v v 225 YES NO | YES NO 226 + + | + + 227 | | | | | 228 +----v-----+ +------+--v+ +---v------+ +-----v----+ 229 |SET ToC=00| |SET ToC=10| |SET ToC=01| |SET ToC=11| 230 +----+-----+ +------+---+ +---+------+ +-----+----+ 231 | | | | 232 +------v----+ +--------v-----+ +--v--------+ | 233 |Compute | |Compute header| |Compute | | 234 |header | |and payload | |payload | | 235 |checksum | |checksum | |checksum | | 236 +------+----+ +--------+-----+ +--+--------+ | 237 | | | | 238 | +---------v----------v----------+ | 239 +-----> Queuing to be forwarded <----+ 240 +-------------------------------+ 242 Figure 2 Processing Rules in Source Nodes 244 The processing rules in source nodes are shown in Figure 2. The 245 source nodes collect the network link status, such as bandwidth and 246 packet loss rate, and create Class of Resource (CoD). The algorithm 247 of creating CoD is not discussed here. 249 If CoD=00 (inadequate resources), it means the network environment is 250 severe and error prone. The source nodes read Bundle Processing 251 Control Flags (defined in RFC5050). If custody is needed, Type of 252 Checksum (ToC) will be set 10 (checksum of primary block and payload 253 block), and the checksum of primary block and payload block will be 254 computed by a designated algorithm. The algorithm is not discussed 255 here. Then the Checksum data field will be filled. If custody is not 256 needed, ToC will be set 00 (checksum of primary block), and the 257 checksum of primary block will be computed. Then the Checksum data 258 field will be filled. 260 If CoD=01 (adequate resources), it means the network resources are 261 relatively adequate. If custody is needed, ToC will be set 01 262 (checksum of payload block), and the checksum of payload block will 263 be computed. Then the Checksum data field will be filled. If custody 264 is not needed, ToC will be set 11 (no checksum of either primary 265 block or payload block), no checksum calculation actions will be 266 triggered. At last, the processed packets will queue and wait to be 267 forwarded. 269 If CoD=10 (mandatory detection), it means that end users at the 270 source node want their packets to be detected no matter what the 271 network status is. So ToC is set 10 (checksum of primary block and 272 payload block), and the checksum of primary block and payload block 273 will be computed. Then the checksum data field will be filled. At 274 last, the processed packets will queue and wait to be forwarded. 276 4.2. Processing Rules in Intermediate Nodes 278 +---------------+ 279 +------------------->Receive packets| 280 | +-------+-------+ 281 | | 282 | +---------v---------+ 283 | +------+Read Checksum Block+------+ 284 | | +---+-----------+---+ | 285 | | | | | 286 | +--v---+ +---v--+ +--v---+ +---v--+ 287 | |ToC=00| |ToC=10| |ToC=01| |ToC=11| 288 | +--+---+ +---+--+ +--+---+ +---+--+ 289 | | | | | 290 | | +--------v----+ +----v--------+ | 291 | | |Check storage| |Check storage| | 292 | | +--------+----+ +----+--------+ | 293 | | | | | 294 | | +-----v--+ +--v-----+ | 295 | | +--+Free>50%| |Free>50%+--+ | 296 | | | +-----+--+ +--+-----+ | | 297 + | v v v v | 298 YES | YES NO NO YES | 299 ^ | + + + + | 300 | | | +-----+----+ +---+-----+ | | 301 | | | |Header and| |payload | | | 302 | | | |payload | |detection| | | 303 | | | |detection | | | | | 304 | | | +-----+----+ +---+-----+ | | 305 | +--------v-v-----+ | | | | 306 | |header detection| | | | | 307 | +----------+-----+ | | | | 308 | | | | | | 309 | +-v--------v-----------v-+ | | 310 +----------+ Retransmission +---+ | | 311 +------------------------+ v | | 312 NO | | 313 + | | 314 +---------------v--v-v-------+ 315 |repeat the steps in Figure 2| 316 +----------------------------+ 318 Figure 3 Processing Rules in intermediate nodes 320 The processing rules in intermediate nodes are shown in Figure 3. 321 When intermediate nodes receive packets, they first read Checksum 322 Block. 324 If ToC = 00 (checksum of primary block), the primary block (header) 325 will be checked. If ToC = 10(checksum of primary block and payload 326 block), storage space will be detected and if free storage is more 327 than 50%, the primary block will be checked. If free storage is less 328 than 50%, both the primary block and the payload block will be 329 checked. If ToC = 01 (checksum of payload block), storage space will 330 be detected and if free storage is less than 50%, the payload block 331 will be checked. If errors are detected, retransmission will be 332 called. If no errors are detected, or ToC = 11 (no checksum of either 333 primary block or payload block), or free storage is more than 50% 334 when ToC = 01, the following processing steps will be the same as the 335 source nodes in Figure 2. However, if the CoD of received packets is 336 10, there is no need to collect the network status and calculate new 337 CoD. In other words, the decision of mandatory detection at the 338 source node by the end users should not be modified by the 339 intermediate nodes. 341 4.3. Processing Rules in Destination Nodes 343 +---------------+ 344 ^--------------->Receive packets| 345 | +-------+-------+ 346 | | 347 | +---------+---------+ 348 | +------+Read Checksum Block+-+ 349 | | +--+---------+------+ | 350 | | | | | 351 | +--v---+ +---v--+ +---v--+ +---v--+ 352 | |ToC=00| |ToC=01| |ToC=10| |ToC=11| 353 | +----+-+ +---+--+ +--+---+ +---+--+ 354 | | | | | 355 | +-v-------v--------v-+ | 356 | | Checksum detection | | 357 | +----------+---------+ | 358 | | | 359 | +-------v------+ | 360 +-+Yes<---+Retransmission| | 361 +-------+------+ | 362 | | 363 | +----------v------+ 364 +>No+-->Cache in the node| 365 +-----------------+ 367 Figure 4 Processing Rules in Destination Nodes 369 The processing rules in destination nodes are shown in Figure 4. When 370 destination nodes receive packets, they will read the checksum block. 371 If ToC is 00 (checksum of primary block), or 01 (checksum of payload 372 block), or 10 (checksum of primary block and payload block), the 373 related blocks will be checked by a designated algorithm. If errors 374 are detected, retransmission will be called. If no errors are 375 detected, or ToC is 11, the received packets will be regarded as 376 acceptable and be cached and stored in local. 378 5. Error correcting code-based detecting mechanism 380 In this section, we introduce a detecting mechanism that based on the 381 idea of error correcting code. This mechanism is designed to reduce 382 the checksum computing times. 384 hash +--+ hash +---+ 385 x1+x2+x4+---->+h1| x1'+x2'+x4'+---->+h1'| 386 | | | | 387 hash | +------------> hash | | 388 x1+x3+x4+---->+h2|transmission x1'+x3'+x4'+---->+h2'| 389 | +------------> | | 390 hash | | hash | | 391 x2+x3+x4+---->+h3| x2'+x3'+x4'+---->+h3'| 392 +-++ +-+-+ 393 | | 394 +---------------------------------+ 395 compare 397 Figure 5 Error Correcting Code-based Detecting Mechanism 399 We introduce the mechanism taking hamming code as an example. As is 400 shown in Figure 5, we suppose that a file is transmitted in the form 401 of four packets, x1, x2, x3, and x4. The source node and the 402 destination node will compute the checksum for each of the four 403 packet in the traditional way. But in our design, the source node 404 conducts the hash operation for data (x1+x2+x4) and get h1. Then the 405 source node conducts the same operation for data (x1+x3+x4) and 406 (x2+x3+x4), and get h2 and h3. h1, h2 and h3 are carried along with 407 the packets. The destination node just need to conducts hash 408 operation three times, for (x1+x2+x4), (x1+x3+x4) and (x2+x3+x4), and 409 get h1', h2', and h3'. Then the destination node should compare h1, 410 h2 and h3 with h1', h2', and h3'. If h1, h2 and h3 are the same as 411 h1', h2', and h3', then, there are no wrong data in the four packets. 412 If one or several of h1, h2 and h3 is different from h1', h2', and 413 h3', then the packet that carries wrong data can be located and 414 retransmission will be called to retransmit the wrong packet. 416 In this way, the checksum computing times can be reduced. 418 6. Security Considerations 420 The Multi-strategy Based Payload Integrity Assurance method provides 421 data integrity service for the Bundle Protocol, which is a necessary 422 aspect of security problems. 424 The proposed method can suit with the Payload Integrity Block (PIB) 425 and Bundle Authentication Block (BAB) in Bundle Security Protocol 426 [RFC6257]. 428 7. IANA Considerations 430 This specification allocates a codepoint from the "Bundle Block 431 Types" registry defined in [RFC6255]. 433 Additional Entry for the Bundle Block Type Codes Registry: 435 +-------+---------------+--------------+ 436 | Value | Description | Reference | 437 +--------------------------------------+ 438 | 20 |Checksum Block | This document| 439 +-----------------------+--------------+ 441 Figure 6 Additional Entry for the Bundle Block Type Codes Registry 443 8. Conclusions 445 The hybrid integrity assurance strategy proposed in this document 446 describes how to ensure the different levels of integrity of bundles 447 based on different environments. 449 An effective checksum computing method that can improve effective 450 load ratio will be proposed in the future work. 452 9. References 454 9.1. Normative References 456 [RFC4838] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst, R., 457 Scott, K., Fall, K., and Weiss, H., "Delay-Tolerant 458 Networking Architecture", RFC 4838, April 2007. 460 [RFC5050] Scott, K., and Burleigh, S., "Bundle Protocol 461 Specification", RFC 5050, RFC5050, November 2007. 463 [RFC5325] Burleigh, S., Ramadas, M., and Farrell, S., "Licklider 464 Transmission Protocol - Motivation", RFC 5325, September 465 2008. 467 [RFC5326] Ramadas, M., Burleigh, S., and Farrell, S., "Licklider 468 Transmission Protocol - Specification", RFC 5326, September 469 2008. 471 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 472 Requirement Levels", BCP 14, RFC 2119, March 1997. 474 [RFC6258] Symington, S., "Delay-Tolerant Networking Metadata 475 Extension Block", RFC 6258, May 2011. 477 [RFC6255] Blanchet, M., "Delay-Tolerant Networking (DTN) Bundle 478 Protocol IANA Registries", RFC 6255, May 2011. 480 [RFC6257] Symington, S., Farrell, S., Weiss, H., Lovell, P., "Bundle 481 Security Protocol Specification ", RFC 6257, May 2011. 483 9.2. Informative References 485 [WOOD09] Wood, L., Eddy, W., and Holliday, P., "A Bundle of Problems", 486 Proc. Aerospace conference 2009 pp. 1-17. 488 [I-D.templin-dtnhiaps-00] Templin, F., "Delay Tolerant Networking 489 Header Integrity Assurance-Problem Statement", draft- 490 templin-dtnhiaps-00 (Expires), March 2014. 492 [I-D.ietf-dtn-bpsec-02] Birrane, E., "Bundle Protocol Security 493 Specification", draft-ietf-dtn-bpsec-05, July 2017. 495 10. Acknowledgments 497 The work in this document was supported by National High Technology 498 of China ("863 program") under Grant No.2015AA015702. 500 Authors' Addresses 502 Taixin Li 503 Beijing Jiaotong University 504 Beijing, 100044, P.R. China 506 Email: 14111040@bjtu.edu.cn 508 Guanwen Li 509 Beijing Jiaotong University 510 Beijing 100044, P.R. China 512 Email: 14120079@bjtu.edu.cn 514 Huachun Zhou 515 Beijing Jiaotong University 516 Beijing 100044, P.R. China 518 Email: hchzhou@bjtu.edu.cn