DTN Research Group S. Symington Internet-Draft R. Durst Expires: October 6, 2006 K. Scott The MITRE Corporation April 4, 2006 Delay-Tolerant Networking Previous Hop Extension Header draft-irtf-dtnrg-bundle-previous-hop-extension-header-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of 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 October 6, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document defines an additional header to be used with the Bundle Protocol [2] within the context of a Delay-Tolerant Network architecture [4]. This new header, called a Previous Hop Endpoint ID Header, is designed to be used by a forwarding node to identify itself in a bundle that it forwards. When a forwarding node includes a Previous Hop Endpoint ID header in a bundle that it forwards, this header provides a mechanism for transmitting the ID of an endpoint of Symington, et al. Expires October 6, 2006 [Page 1] Internet-Draft DTN Previous Hop Extension Header April 2006 which the forwarding node is a member to the node that receives the bundle. This Previous Hop Endpoint ID Header is expected to be of general use in DTN. By enabling a receiving node to identify the node from which a bundle has been received, this header can be used in support of various routing protocols. This document defines the format and processing of this new Previous Hope Endpoint ID extension header. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Previous Hop Endpoint ID Extension Header Format . . . . . . . 5 3. Security Considerations . . . . . . . . . . . . . . . . . . . 7 4. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.1. Normative References . . . . . . . . . . . . . . . . . . . 8 4.2. Informative References . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 Intellectual Property and Copyright Statements . . . . . . . . . . 10 Symington, et al. Expires October 6, 2006 [Page 2] Internet-Draft DTN Previous Hop Extension Header April 2006 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 [1]. The DTN bundle protocol [2] defines the bundle as its protocol data unit. A bundle consists of a primary bundle header, which is defined in the Bundle Protocol, followed by at least one other type of bundle header. The Bundle Protocol defines a single other type of bundle header, called a Bundle Payload Header. This document defines an additional bundle header. This new header, called a Previous Hop Endpoint ID Header, is designed to be used by a forwarding node to identify itself in a bundle that it forwards. When a forwarding node includes a Previous Hop Endpoint ID header in a bundle that it forwards, this header provides a mechanism for transmitting the ID of an endpoint of which the forwarding node is a member to the node that receives the bundle. The Bundle Protocol does not include any bundle fields for carrying previous hop endpoint ID information. Relying on the convergence layer alone to enable a receiving node to determine the sender of a bundle is not expected to be sufficient because a node cannot necessarily determine the identity of a previous-hop node using just the knowledge of the convergence layer service access point on which a bundle was received. There may be more than one convergence layer protocol service access point pair over which the sending and receiving nodes can exchange messages. Receipt of a bundle at one convergence layer protocol service access point does not necessarily enable identification of the node that sent the bundle. Bundles received on one convergence layer protocol service access point do not necessarily have a different sending node than bundles received on a different convergence layer protocol service access point. The actual node ID of the previous hop node, which is a bundle layer construct, needs to be used to identify the previous-hop node uniquely. The Previous Hop Endpoint ID Header defined in this document is expected to be of general use in DTN. The ability of a receiving node to identify the node from which a bundle has been received is a mechanisms that may be used in support of various routing protocols. This document defines the format and processing of this new Previous Hope Endpoint ID extension header. The capabilities described in this document are OPTIONAL for deployment with the Bundle Protocol. Bundle Protocol implementations claiming to support previous-hop endpoint identification MUST be capable of both: Symington, et al. Expires October 6, 2006 [Page 3] Internet-Draft DTN Previous Hop Extension Header April 2006 -generating and sending bundles containing a Previous-Hop Endpoint ID extension header, and -receiving and processing bundles containing a Previous-Hop Endpoint ID extension header as defined in this document. Symington, et al. Expires October 6, 2006 [Page 4] Internet-Draft DTN Previous Hop Extension Header April 2006 2. Previous Hop Endpoint ID Extension Header Format The Previous Hop Endpoint ID header uses the Canonical Bundle Header Format as defined in the bundle protocol [2]. That is, it is comprised of the following elements: - Header type code - Header processing control flags - Header data length - Header-type-specific data fields - Header-type code (one byte) - as in all bundle protocol headers except the primary bundle header. The header type code for the Previous Hop Endpoint ID header is 0x05 - Header processing control flags (one byte) - as in all bundle protocol headers except the primary bundle header. There are no major constraints on the use of the header processing flags, however, we would expect that the Previous Hop Endpoint ID header would not have the "transmit status report" bit set since it is only present on a hop-by-hop basis. - Header data length (SDNV) - as in all bundle protocol headers except the primary bundle header. SDNV encoding is described in the bundle protocol. - Header-type-specific data fields as follows: -EID-length - contains the length of the next field (EID) and is encoded as an SDNV. -EID - contains the endpoint ID of the sending node which, when the bundle is received at its next-hop node, will be the EID of the previous-hop node. The Structure of a Previous Hop EID Header: +------+-------+--------+------------+-----+ | Type | Flags | Length | EID-length | EID | +------+-------+--------+------------+-----+ Figure 1 Upon receipt of a multicast bundle that includes a Previous Hop EID Symington, et al. Expires October 6, 2006 [Page 5] Internet-Draft DTN Previous Hop Extension Header April 2006 header: -the bundle protocol agent SHALL remove the Previous Hop EID header before forwarding the bundle, and -the EID in the header SHALL be made available for use (e.g., in forwarding decisions). Symington, et al. Expires October 6, 2006 [Page 6] Internet-Draft DTN Previous Hop Extension Header April 2006 3. Security Considerations There are two documents that pertain to providing security within DTN: the DTN Security Overview [5] and the Bundle Security Protocol [3]. These documents define extension headers 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 mandatory ciphersuites that may be used to calculate security results carried in these security headers. All ciphersuites that use the strict canonicalisation algorithm [3] to calculate and verify security results (e.g., many BAH ciphersuites) apply to all headers in the bundle, and so would apply to bundles that include a new Previous Hop Endpoint ID extension header. In particular, bundles including the new Previous Hop Endpoint ID header would be protected using the mandatory 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 mandatory PSH-RSA-SHA256 ciphersuite and most PSH ciphersuites) will (correctly) ignore the new Previous Hop Endpoint ID extension header, so the fact that this header changes as the bundle transits the network will not interfere with end-to-end security protection when using ciphersuites that use mutable canonicalisation. The Previous Hop Endpoint ID extension header will not be encrypted by the mandatory CH-RSA-AES-PAYLOAD-PSH ciphersuite, which only allows for payload and PSH encryption. Symington, et al. Expires October 6, 2006 [Page 7] Internet-Draft DTN Previous Hop Extension Header April 2006 4. References 4.1. Normative References [1] Bradner, S. and J. Reynolds, "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, October 1997. [2] Scott, K. and S. Burleigh, "Bundle Protocol Specification", draft-irtf-dtnrg-bundle-spec-04.txt , December 2005. [3] Symington, S., Farrell, S., and H. Weiss, "Bundle Security Protocol Specification", draft-irtf-dtnrg-bundle-security-01.txt, work-in-progress, March 2006. 4.2. Informative References [4] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst, R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant Network Architecture", draft-irtf-dtnrg-arch-04.txt , December 2005, . [5] Farrell, S., Symington, S., and H. Weiss, "Delay-Tolerant Network Security Overview", draft-irtf-dtnrg-sec-overview-01.txt , March 2005. Symington, et al. Expires October 6, 2006 [Page 8] Internet-Draft DTN Previous Hop Extension Header April 2006 Authors' Addresses 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/ Robert C. Durst The MITRE Corporation 7515 Colshire Drive McLean, VA 22102 US Phone: +1 (703) 983-7535 Email: durst@mitre.org URI: http://mitre.org/ Keith L. Scott The MITRE Corporation 7515 Colshire Drive McLean, VA 22102 US Phone: +1 (703) 983-6547 Email: kscott@mitre.org URI: http://mitre.org/ Symington, et al. Expires October 6, 2006 [Page 9] Internet-Draft DTN Previous Hop Extension Header April 2006 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Symington, et al. Expires October 6, 2006 [Page 10]