Delay-Tolerant Networking Taixin Li Internet Draft Guanwen Li Intended status: Informational Bohao Feng Expires: April 14, 2016 Huachun Zhou Beijing Jiaotong University October 13, 2015 A Hybrid Integrity Assurance Strategy for Bundle Protocol draft-li-dtn-hybrid-integrity-00.txt Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on April 13,2016. Li Expires April 14, 2016 [Page 1] Internet-Draft Hybrid Integrity Assurance Strategy October 2015 Copyright Notice Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Abstract Delay/Disruption Tolerant Networking (DTN) is designed for a severe environment where communication quality is not guaranteed. It works as an overlay network associated with Bundle Protocol (BP) and some convergence layer protocols like Licklider Transmission Protocol (LTP). However, there is no mechanism in both BP and LTP Protocol to ensure integrity of a packet with the granularity of bit. Since the integrity is crucial for packet transmission and necessary metadata consumes extra costs, there should be a strategy to decide which packets and how the packets are required to conduct integrity assurance based on the network resources. Hence, in this document, a hybrid integrity assurance strategy is proposed to ensure the different levels of integrity of bundles based on different environments. Table of Contents 1. Introduction ................................................ 3 2. Conventions used in this document............................ 3 3. Checksum Block Format........................................ 4 4. Processing Rules of Integrity Detection...................... 5 4.1. Processing Rules in source nodes........................ 6 4.2. Processing Rules in intermediate nodes.................. 8 4.3. Processing Rules in destination nodes................... 9 5. Security Considerations..................................... 10 6. IANA Considerations ........................................ 10 7. Conclusions ................................................ 10 8. References ................................................. 11 Li Expires April 13, 2016 [Page 2] Internet-Draft Hybrid Integrity Assurance Strategy October 2015 8.1. Normative References................................... 11 8.2. Informative References................................. 11 9. Acknowledgments ............................................ 12 1. Introduction Delay/Disruption Tolerant Networking (DTN) [RFC4838] is designed for a severe environment where connectivity of network is intermittent and communication quality is not guaranteed. It works as an overlay network associated with Bundle Protocol (BP) [RFC5050] and convergence layer protocols like Licklider Transmission Protocol (LTP) [RFC5325] [RFC5326]. BP, which is an application layer protocol, is based on a custody transfer mechanism and defines how to forward bundles in DTN, while LTP ensures the reliability of bundle transmission with the granularity of packet. However, there is no mechanism in both BP and LTP Protocol to ensure integrity of a packet with the granularity of bit. Integrity is crucial for packet transmission since errors in the header leads to some unexpected results while errors in the payload results in end-to-end retransmission and waste of limited storing and link resources. SBSP [I-D.birrane-dtn-sbsp-00] defines a streamlined bundle security protocol, which provides data integrity, authentication, and confidentiality services for the Bundle Protocol. However, necessary checksum metadata consumes costs, so there should be a strategy to decide which packets and how the packets are required to conduct integrity assurance based on the network resources, such as buffer utilization rate, bandwidth, and packet loss rate. In this document, we define a new type of extension block to carry the checksum information. Furthermore, we propose a hybrid integrity assurance strategy to ensure the different levels of integrity of bundles based on different environments. 2. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Li Expires April 13, 2016 [Page 3] Internet-Draft Hybrid Integrity Assurance Strategy October 2015 3. Checksum Block Format There are three parts in bundle packet, primary block, payload block, and extension block. Extension Block is designed to carry additional information that DTN nodes can use to make processing decisions regarding bundles. We define a new type of extension block and use it to carry the checksum information in this document, and the basic format is based on [RFC6258], which defines DTN metadata extension block. The structure of checksum block is as follows: Checksum Block Format: +------+-------+-------------------------------------------+ | Type | Flags | Length |Class of Resource|Type of Checksum| | | (SDNV)| (SDNV) | (SDNV) | (SDNV) | +------+----------------+-----------------+----------------+ | Checksum | | | +----------------------------------------------------------+ Figure 1 o Block type code (1 byte) - defined in all bundle protocol blocks except the primary bundle block (as described in the Bundle Protocol). The block-type code for checksum is 0x20. o Block processing control flags (SDNV) - defined in all bundle protocol blocks except the primary bundle block. SDNV encoding is described in the Bundle Protocol. The following block processing control flag MUST be set "4 - Discard block if it can't be processed", which means that if a bundle node receives a bundle with a checksum block and it is not capable of supporting the checksum block, it just discards this block without processing it. o Block data length (SDNV) - defined in all bundle protocol blocks except the primary bundle block. SDNV encoding is described in the Bundle Protocol. o Bundle's class of resource (SDNV) - (CoR) indicates the bundle's class of resource, which decides whether a bundle packet should conduct an integrity assurance and which part should be detected. For now, it contains two types: 00 = inadequate, 01 = adequate, and will be extended in the future. Li Expires April 13, 2016 [Page 4] Internet-Draft Hybrid Integrity Assurance Strategy October 2015 o Type of Checksum (SDNV) - (ToC) indicates the type of checksum data. For now, it contains four types: 00 = checksum of primary block, 01 = checksum of payload block, 10 = checksum of primary block and payload block, 11 = no checksum of either primary block or payload block. o Checksum data - contains the raw checksum data itself, which is generated by some algorithms. 4. Processing Rules of Integrity Detection As is discussed in [WOOD08] and [I-D.templin-dtnhiaps-00], integrity detection is required on intermediate nodes in addition to destination nodes. In order to make full use of the limited resources in the severe environments, both the source nodes and the intermediate nodes should monitor the usage rate of their resources such as the storage and link. Then different integrity assurance strategies will be made according to resources. Besides, intermediate nodes detect the header/primary block or the payload block according to the Type of Checksum field carried in the checksum block. If there are errors in the packet data, forwarding is stopped and retransmission is called. When the destination nodes receive packets, they detect the checksum block and if there are errors in the packet data, retransmission will be called. Li Expires April 13, 2016 [Page 5] Internet-Draft Hybrid Integrity Assurance Strategy October 2015 4.1. Processing Rules in source nodes +--------------+ +-----+Create new CoR+-----+ | +--------------+ | +----v----+ +----v----+ | CoR=00 | | CoR=01 | +----+----+ +----+----+ | | +----v----+ +----v----+ +--+ Custody +--+ +--+ Custody +--+ | +---------+ | | +---------+ | v v v v YES NO YES NO + + + + | | | | +----v-----+ +------+---+ +---v------+ +-----v----+ |SET ToC=10| |SET ToC=00| |SET ToC=01| |SET ToC=11| +----+-----+ +------+---+ +---+------+ +-----+----+ | | | | +------v-------+ +-----v-----+ +--v--------+ | |Compute header| |Compute | |Compute | | |and payload | |header | |payload | | |checksum | |checksum | |checksum | | +------+-------+ +-----+-----+ +--+--------+ | | | | | | +---------v----------v----------+ | +-----> Queuing to be forwarded <----+ +-------------------------------+ Figure 2 The processing rules in source nodes are shown in Figure 2. The source nodes collect the network link status, such as bandwidth and packet loss rate, and create Class of Resource (CoR). The algorithm of creating CoR is not discussed here. If CoR=00 (inadequate), it means the network environment is severe and error prone. The source nodes read Bundle Processing Control Flags (defined in RFC5050). If custody is needed, Type of Checksum (ToC) will be set 10 (checksum of primary block and payload block), and the checksum of primary block and payload block will be computed by a designated algorithm. The algorithm is not discussed here. Then the Checksum data field will be filled. If custody is not needed, ToC will be set 00 (checksum of primary block), and the checksum of primary block will be computed. Then the Checksum data field will be filled. Li Expires April 13, 2016 [Page 6] Internet-Draft Hybrid Integrity Assurance Strategy October 2015 If CoR=01 (adequate), it means the network resources are relatively adequate. If custody is needed, ToC will be set 01 (checksum of payload block), and the checksum of payload block will be computed. Then the Checksum data field will be filled. If custody is not needed, ToC will be set 11 (no checksum of either primary block or payload block), no checksum calculation actions will be triggered. At last, the processed packets will queue and wait to be forwarded. Here, CoR is not only for describing the network resources, but also reserved for user-based strategies in the future work. Li Expires April 13, 2016 [Page 7] Internet-Draft Hybrid Integrity Assurance Strategy October 2015 4.2. Processing Rules in intermediate nodes +---------------+ +------------------->Receive packets| | +-------+-------+ | | | +---------v---------+ | +------+Read Checksum Block+------+ | | +---+-----------+---+ | | | | | | | +--v---+ +---v--+ +--v---+ +---v--+ | |ToC=00| |ToC=10| |ToC=01| |ToC=11| | +--+---+ +---+--+ +--+---+ +---+--+ | | | | | | | +--------v----+ +----v--------+ | | | |Check storage| |Check storage| | | | +--------+----+ +----+--------+ | | | | | | | | +-----v--+ +--v-----+ | | | +--+Free>50%| |Free>50%+--+ | | | | +-----+--+ +--+-----+ | | + | v v v v | YES | YES NO NO YES | ^ | + + + + | | | | +-----+----+ +---+-----+ | | | | | |Header and| |payload | | | | | | |payload | |detection| | | | | | |detection | | | | | | | | +-----+----+ +---+-----+ | | | +--------v-v-----+ | | | | | |header detection| | | | | | +----------+-----+ | | | | | | | | | | | +-v--------v-----------v-+ | | +----------+ Retransmission +---+ | | +------------------------+ v | | NO | | + | | +------------v--v-v------+ |Same as the source nodes| +------------------------+ Figure 3 The processing rules in intermediate nodes are shown in Figure 3. When intermediate nodes receive packets, they first read Checksum Block. Li Expires April 13, 2016 [Page 8] Internet-Draft Hybrid Integrity Assurance Strategy October 2015 If ToC = 00 (checksum of primary block), the primary block (header) will be checked. If ToC = 10(checksum of primary block and payload block), storage space will be detected and if free storage is more than 50%, the primary block will be checked. If free storage is less than 50%, both the primary block and the payload block will be checked. If ToC = 01 (checksum of payload block), storage space will be detected and if free storage is less than 50%, the payload block will be checked. If errors are detected, retransmission will be called. If no errors are detected, or ToC = 11 (no checksum of either primary block or payload block), or free storage is more than 50% when ToC = 01, the following processing steps will be the same as the source nodes in Figure 2. 4.3. Processing Rules in destination nodes +---------------+ ^--------------->Receive packets| | +-------+-------+ | | | +---------+---------+ | +------+Read Checksum Block+-+ | | +--+---------+------+ | | | | | | | +--v---+ +---v--+ +---v--+ +---v--+ | |ToC=00| |ToC=01| |ToC=10| |ToC=11| | +----+-+ +---+--+ +--+---+ +---+--+ | | | | | | +-v-------v--------v-+ | | | Checksum detection | | | +----------+---------+ | | | | | +-------v------+ | +-+Yes<---+Retransmission| | +-------+------+ | | | | +----------v------+ +>No+-->Cache in the node| +-----------------+ Figure 4 The processing rules in destination nodes are shown in Figure 4. When destination nodes receive packets, they will read the checksum block. If ToC is 00 (checksum of primary block), or 01 (checksum of payload block), or 10 (checksum of primary block and payload block), the Li Expires April 13, 2016 [Page 9] Internet-Draft Hybrid Integrity Assurance Strategy October 2015 related blocks will be checked by a designated algorithm. If errors are detected, retransmission will be called. If no errors are detected, or ToC is 11, the received packets will be regarded as acceptable and be cached and stored in local. 5. Security Considerations The Multi-strategy Based Payload Integrity Assurance method provides data integrity service for the Bundle Protocol, which is a necessary aspect of security problems. The proposed method can suit with the Payload Integrity Block (PIB) and Bundle Authentication Block (BAB) in Bundle Security Protocol [RFC6257]. 6. IANA Considerations This specification allocates a codepoint from the "Bundle Block Types" registry defined in [RFC6255]. Additional Entry for the Bundle Block Type Codes Registry: +-------+---------------+--------------+ | Value | Description | Reference | +--------------------------------------+ | 20 |Checksum Block | This document| +-----------------------+--------------+ Figure 5 7. Conclusions The hybrid integrity assurance strategy proposed in this document describes how to ensure the different levels of integrity of bundles based on different environments. User-based integrity detection strategies and an effective checksum computing method that can improve effective load ratio will be proposed in the future work. Li Expires April 13, 2016 [Page 10] Internet-Draft Hybrid Integrity Assurance Strategy October 2015 8. References 8.1. Normative References [RFC4838]Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst, R., Scott, K., Fall, K., and Weiss, H., "Delay-Tolerant Networking Architecture", RFC 4838, April 2007. [RFC5050] Scott, K., and Burleigh, S., "Bundle Protocol Specification", RFC 5050, RFC5050, November 2007. [RFC5325] Burleigh, S., Ramadas, M., and Farrell, S., "Licklider Transmission Protocol - Motivation", RFC 5325, September 2008. [RFC5326] Ramadas, M., Burleigh, S., and Farrell, S., "Licklider Transmission Protocol - Specification", RFC 5326, September 2008. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC6258] Symington, S., "Delay-Tolerant Networking Metadata Extension Block", RFC 6258, May 2011. [RFC6255] Blanchet, M., "Delay-Tolerant Networking (DTN) Bundle Protocol IANA Registries", RFC 6255, May 2011. [RFC6257] Symington, S., Farrell, S., Weiss, H., Lovell, P., "Bundle Security Protocol Specification ", RFC 6257, May 2011. 8.2. Informative References [WOOD08] Wood, L., Eddy, W., and Holliday, P., "A Bundle of Problems", Proc. Aerospace conference 2008 pp. 1-17. [I-D.templin-dtnhiaps-00] Templin, F., "Delay Tolerant Networking Header Integrity Assurance-Problem Statement", draft- templin-dtnhiaps-00 (Expires), March 2014. [I-D.birrane-dtn-sbsp-00] Birrane, E., "Streamlined Bundle Security Protocol Specification", draft-birrane-dtn-sbsp-00. (Expires), December 2014. Li Expires April 13, 2016 [Page 11] Internet-Draft Hybrid Integrity Assurance Strategy October 2015 9. Acknowledgments The work in this document was supported by National High Technology of China ("863 program") under Grant No.2015AA015702. Li Expires April 13, 2016 [Page 12] Internet-Draft Hybrid Integrity Assurance Strategy October 2015 Authors' Addresses Taixin Li Beijing Jiaotong University Beijing, 100044, P.R. China Email: 14111040@bjtu.edu.cn Guanwen Li Beijing Jiaotong University Beijing 100044, P.R. China Email: 14120079@bjtu.edu.cn Bohao Feng Beijing Jiaotong University Beijing 100044, P.R. China Email: 11111021@bjtu.edu.cn Huachun Zhou Beijing Jiaotong University Beijing 100044, P.R. China Email: hchzhou@bjtu.edu.cn Li Expires April 13, 2016 [Page 13]