DTN Research Group S. Symington Internet-Draft The MITRE Corporation Intended status: Experimental March 24, 2009 Expires: September 25, 2009 Delay-Tolerant Networking Previous Hop Insertion Block draft-irtf-dtnrg-bundle-previous-hop-block-06 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. 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 September 25, 2009. Copyright Notice Copyright (c) 2009 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 in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Symington Expires September 25, 2009 [Page 1] Internet-Draft DTN Previous Hop Insertion Block March 2009 Abstract This document defines an extension block that may be used with the Bundle Protocol [refs.DTNBP] within the context of a Delay-Tolerant Network architecture [refs.DTNarch]. This Previous Hop Insertion Block is designed to be inserted by a forwarding node to provide its endpoint ID (EID) to the next-hop receiving node. Knowledge of the EID of a previous-hop node may be required in some circumstances to support certain routing protocols (e.g., flood routing). The Previous Hop Insertion block is always removed from the bundle by the receiving node so that it's duration within the bundle lasts for exactly one hop. This document defines the format and processing of this Previous Hop Insertion Block. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Previous Hop Insertion Block Format . . . . . . . . . . . . . 5 3. Previous Hop Insertion Block Processing . . . . . . . . . . . 7 3.1. Bundle Transmission . . . . . . . . . . . . . . . . . . . 7 3.2. Bundle Forwarding . . . . . . . . . . . . . . . . . . . . 7 3.3. Bundle Reception . . . . . . . . . . . . . . . . . . . . . 7 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 6.1. Normative References . . . . . . . . . . . . . . . . . . . 10 6.2. Informative References . . . . . . . . . . . . . . . . . . 10 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11 Symington Expires September 25, 2009 [Page 2] Internet-Draft DTN Previous Hop Insertion Block March 2009 1. Introduction 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 [refs.RFC2119]. The DTN bundle protocol [refs.DTNBP] defines the bundle as its protocol data unit. This document defines an optional bundle block called a Previous Hop Insertion Block. This Previous Hop Insertion Block is designed to be inserted by a forwarding node to provide its endpoint ID (EID) to the next-hop receiving node. This previous-hop EID information may be required in some circumstances to support various routing protocols (e.g., flood routing). Although there may be some situations in which a node that receives a bundle may be able to infer the EID of the node that forwarded the bundle to it, there are other situations in which the EID of the forwarding node will not be able to be inferred by the receiving node. In these situations, if there is a requirement that the receiving node be able to determine the EID of the forwarding node, the forwarding node must provide this information in the bundle. This specification defines a mechanism, i.e. the Previous Hop Insertion Block, whereby a node can insert its EID into a bundle before forwarding it. If the EID of the inserting node is already in the dictionary field of the bundle's Primary Bundle Block, the Previous Hop Block MAY identify this EID using its Block EID reference count and EID references field. Otherwise, the Previous Hop Block MUST identify this EID by providing it in its block-type-specific data field. The lifetime of the Previous Hop Insertion Block is always exactly one hop in the DTN. If a bundle containing a Previous Hop Insertion Block is received, the receiving node is assured that this block was inserted by the previous node, assuming all nodes are operating correctly; likewise, this block is not retained with the bundle when the bundle is forwarded. If the bundle is forwarded with a Previous Hop Insertion Block, this block must identify the EID of the new forwarding node. This document defines the format and processing of the Previous Hop Insertion Block. The capabilities described in this document are OPTIONAL for deployment with the Bundle Protocol. Bundle Protocol implementations claiming to support Previous Hop Insertion Blocks MUST be capable of: -Generating a Previous Hop Insertion Block and inserting it into a bundle, Symington Expires September 25, 2009 [Page 3] Internet-Draft DTN Previous Hop Insertion Block March 2009 -Receiving bundles containing a Previous Hop Insertion Block and making the information contained in this Previous Hop Insertion Block available for use, e.g., in forwarding decisions. -Deleting a Previous Hop Insertion Block from a bundle as defined in this document. Symington Expires September 25, 2009 [Page 4] Internet-Draft DTN Previous Hop Insertion Block March 2009 2. Previous Hop Insertion Block Format The Previous Hop Insertion Block uses the Canonical Bundle Block Format as defined in the bundle protocol [refs.DTNBP]. That is, it is comprised of the following elements: -Block-type code (one byte) - defined as in all bundle protocol blocks except the primary bundle block (as described in the Bundle Protocol). The block type code for the Previous Hop Insertion Block is 0x05. -Block processing control flags (SDNV) - defined as 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: -Discard block if it can't be processed. -Block EID reference count and EID references (optional) - composite field defined in [refs.DTNBP] containing a count of EID references (expressed as an SDNV) followed by an EID reference (expressed as a pair of SDNVs). Whether or not this field may be present in the block is determined by whether or not the EID of the node inserting the block is already in the Dictionary Field of the Primary Bundle Block (e.g., whether this EID is the EID of the bundle's source, current custodian, or report-to endpoint, or of some other endpoint in the dictionary that is referenced by another block in the bundle). If the EID of the inserting node is already in the dictionary, this field MAY be present in the block. If this field is present in the block, the value of the EID reference count MUST be one, meaning that the field contains exactly one EID reference, which MUST be a reference to the inserting node's EID. Presence of this field is indicated by a set "block contains an EID reference field" flag in the block processing control flags. If the EID of the inserting node is not already in the dictionary, this field MUST NOT be present in the block, which MUST be indicated by an unset "block contains an EID reference field" flag in the block processing control flags -Block data length (SDNV) - defined as in all bundle protocol blocks except the primary bundle block. SDNV encoding is described in the Bundle Protocol. If this value is zero, there are no block-type-specific data fields. In this case, the inserting node's EID must have already been in the dictionary and it MUST be referenced in the Block EID reference count and EID references field as described above. Symington Expires September 25, 2009 [Page 5] Internet-Draft DTN Previous Hop Insertion Block March 2009 -Block-type-specific data fields (optional) as follows: -Inserting Node's EID Scheme Name - A null-terminated array of bytes that comprises the scheme name of the EID of the node inserting this Previous Hop Insertion Block. -Inserting Node's EID SSP - A null-terminated array of bytes that comprises the scheme-specific part (SSP) of the EID of the node inserting this Previous Hop Insertion Block. If the Block EID reference count and EID references field is not present in the block, the above two EID scheme name and SSP data fields MUST BE present. Otherwise, these fields MAY be present. The Structure of a Previous Hop Insertion Block is as follows: Previous Hop Insertion Block Format: +----+------------+--------------------------------- -+-------------+ |type|flags (SDNV)|EID ref count and list (comp) (opt)|length (SDNV)| +----+------------+-----------------------------------+-------------+ | Inserting Node EID Scheme Name (opt)| Inserting Node EID SSP (opt)| +-------------------------------------------------------------------+ Figure 1 Symington Expires September 25, 2009 [Page 6] Internet-Draft DTN Previous Hop Insertion Block March 2009 3. Previous Hop Insertion Block Processing The following are the processing steps that a bundle node must take relative to generation, reception, and processing of Previous Hop Insertion Blocks. 3.1. Bundle Transmission When an outbound bundle is created per the parameters of the bundle transmission request, this bundle MAY (as influenced by local policy) include a Previous Hop Insertion Block (as defined in this specification). 3.2. Bundle Forwarding Before forwarding a bundle, the node SHALL delete the Previous Hop Insertion Block that was in the bundle when it was received (if any). As described in the Bundle Protocol, the node MAY delete all strings (scheme names and scheme-specific parts--SSPs) in the bundle's dictionary to which no endpoint ID references in the bundle currently refer (if any). The node MAY insert a Previous Hop Insertion Block into the bundle before forwarding it, as dictated by local policy. If there are already strings (scheme names and SSPs) in the bundle's dictionary that denote the inserting node's EID, the Previous Hop Insertion Block MAY reference these strings and, if it does, it need not include any block-type-specific data fields. Otherwise, the inserting node MUST include its EID's scheme name and SSP as the block's block-type-specific data fields. The inserting node MUST NOT insert strings into the bundle's dictionary in order that they may be referenced by only the Previous Hop Insertion Block. 3.3. Bundle Reception If the bundle includes a Previous Hop Insertion Block, the EID identified in these blocks SHALL be made available for use at this node (e.g., in forwarding decisions). If the EID is identified both by a reference in the block's Block EID reference count and EID references field and by a scheme name and SSP in the block-type- specific fields, the receiving node may use either mechanism to determine the EID being identified. Symington Expires September 25, 2009 [Page 7] Internet-Draft DTN Previous Hop Insertion Block March 2009 4. Security Considerations The DTN Bundle Security Protocol [refs.DTNBPsec] defines security- related blocks to provide hop-by-hop authentication, end-to-end authentication, and end-to-end confidentiality of bundles or parts of bundles, as well as a set of ciphersuites that may be used to calculate security results carried in these security blocks. All ciphersuites that use the strict canonicalisation algorithm [refs.DTNBPsec] to calculate and verify security results (e.g., many hop-by-hop authentication ciphersuites) apply to all blocks in the bundle, and so would apply to bundles that include an optional Previous Hop Insertion Block and would include that block in the calculation of their security result. In particular, bundles including the optional Previous Hop Insertion Block would be protected in their entirety for the duration of a single hop, from a forwarding node to an adjacent receiving node (but not from source to destination), using the BAH-HMAC ciphersuite defined in the Bundle Security Protocol. Ciphersuites that use the mutable canonicalisation algorithm to calculate and verify security results (e.g., the PSH-RSA-SHA256 ciphersuite and most end-to-end authentication ciphersuites) will (correctly) omit the Previous Hop Insertion Block from their calculation. The fact that several different instantiations of this block may be added to and deleted from the bundle as the bundle transits the network will not interfere with end-to-end security protection when using ciphersuites that use mutable canonicalisation. Lastly, the Previous Hop Insertion Block will not be encrypted by the CH-RSA-AES-PAYLOAD-PSH end-to-end confidentiality ciphersuite, which only allows for payload and PSH encryption. If encryption of this block is desired, the Extension Security Block (ESB) could be used for this purpose. Nodes receiving bundles with Previous Hop Insertion Blocks should be aware that forwarding nodes that insert Previous Hop Insertion Blocks might lie about their EIDs. Lying in this way could provide a mechanism for subverting routing strategies that base routing decisions on EID information in the Previous Hop Insertion Block. Note that if some Bundle Protocol implementation does not support the Previous Hop Insertion Block but does not properly implement the "Discard block if it can't be processed" flag, then a Previous Hop Insertion Block may unexpectedly persist for longer than a single hop. Symington Expires September 25, 2009 [Page 8] Internet-Draft DTN Previous Hop Insertion Block March 2009 5. IANA Considerations If the bundle protocol becomes a standards track protocol, then we may want to consider having IANA establish a register of block types, of which the Previous Hop Insertion Block would be one. Symington Expires September 25, 2009 [Page 9] Internet-Draft DTN Previous Hop Insertion Block March 2009 6. References 6.1. Normative References [refs.RFC2119] Bradner, S. and J. Reynolds, "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, October 1997. [refs.DTNBP] Scott, K. and S. Burleigh, "Bundle Protocol Specification", RFC 5050, November 2007. [refs.DTNBPsec] Symington, S., Farrell, S., Weiss, H., and P. Lovell, "Bundle Security Protocol Specification", draft-irtf-dtnrg-bundle-security-09.txt, work-in-progress, March 2008. 6.2. Informative References [refs.DTNarch] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst, R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant Network Architecture", RFC 4838, April 2007. Symington Expires September 25, 2009 [Page 10] Internet-Draft DTN Previous Hop Insertion Block March 2009 Author's Address Susan Flynn Symington The MITRE Corporation 7515 Colshire Drive McLean, VA 22102 US Phone: +1 (703) 983-7209 Email: susan@mitre.org URI: http://mitre.org/ Symington Expires September 25, 2009 [Page 11]