Network Working Group F. Templin, Ed. Internet-Draft Boeing Research & Technology Intended status: Informational March 12, 2014 Expires: September 13, 2014 Delay Tolerant Networking Time Synchronization - Problem Statement draft-templin-dtntsync-00.txt Abstract Delay/Disruption Tolerant Networking (DTN) introduces a network model in which communications may be subject to long delays and/or intermittent connectivity. DTN nodes include timestamps in the bundles of data they send so that correspondents can identify the bundles and determine the length of time they have been in the system. However, there is currently no specified strategy for synchronizing the clocks between DTN nodes. This document therefore presents a problem statement for time synchronization in DTNs. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on September 13, 2014. Copyright Notice Copyright (c) 2014 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 Templin Expires September 13, 2014 [Page 1] Internet-Draft DTNTSYNC March 2014 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 4 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 4 6.1. Normative References . . . . . . . . . . . . . . . . . . . 4 6.2. Informative References . . . . . . . . . . . . . . . . . . 5 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 5 Templin Expires September 13, 2014 [Page 2] Internet-Draft DTNTSYNC March 2014 1. Introduction The Delay/Disruption Tolerant Network (DTN) architecture [RFC4838] introduces a data communications concept in which "bundles" of data are exchanged in store-and-forward fashion between endpoints that may be separated by long-delay or intermittently-connected paths. The Bundle Protocol Specification [RFC5050] provides the bundle message format and operations, including convergence layer transmission, fragmentation and custody transfer. Each bundle further may include extensions, among which may be security parameters designed to ensure confidentiality, integrity and authorization [RFC6257][I-D.irtf-dtnrg-sbsp]. [WOOD08], Sections 4.2 - 4.4 has shown that time synchronization is an important aspect of correct operation. In particular, the study points out that Bundle Protocol agents that obey [RFC5050] require a tightly-synchronized notion of Coordinated Universal Time (UTC). However, there may be operational use cases in which time synchronization without reliance on the Bundle Protocol itself may be difficult or impossible to achieve. This document therefore discusses problematic aspects of the Bundle Protocol time synchronization requirement as motivation for solution proposals. 2. Discussion Time synchronization in the Bundle Protocol serves three purposes: 1. Bundle lifetimes keep bundles from looping continuously due to routing loops 2. The lifetime allows the network to purge expired bundles 3. The creation timestamp is used to uniquely identify each bundle. However, the creation timestamp applied to each bundle is relative to the clock of the DTN source node that produced the bundle. If the source node's clock is sufficiently drifted from UTC, this could result in several failure modes. First, if a forwarding DTN node on the path to the final destination(s) receives a bundle whose timestamp appears to be in the future, the forwarding node may drop the bundle unconditionally and thereby deny service to the source node. This can be due to either a time advancement in the source node's clock or a time lag in the forwarding node's clock. Second, if the timestamp applied by the source node is sufficiently advanced into the future and the bundle is not rejected by forwarding nodes, the bundle could spin continuously in a routing loop that is Templin Expires September 13, 2014 [Page 3] Internet-Draft DTNTSYNC March 2014 sustained longer than would be indicated by the bundle lifetime (thereby wasting network resources). Finally, if the source node's clock has drifted sufficiently into the past, any forwarding nodes might discard the bundle based on the lifetime at a time that is earlier than the source node intended. Clearly, the current Bundle Protocol specification is dependent on closely synchronized clocks for proper operation, while clock synchronization may be difficult or impossible to achieve in some applications. Also clearly, there may be other methods than strict clock synchronization that can address the purposes listed above. This document does not speculate as to alternate methods, but rather outlines the problems and invites solution proposals. 3. IANA Considerations There are no IANA considerations for this document. 4. Security Considerations Timestamps are an integral aspect of security, since mistaken notions of time may result in resource consumtion denial of service attack vectors.. Bundle Protocol security considerations are discussed in [RFC6257][I-D.irtf-dtnrg-sbsp]. 5. Acknowledgments Time synchronization has been discussed broadly in DTN mailing list discussions as well as in many of the documents cited in this publication. 6. References 6.1. Normative References [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [RFC4838] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst, Templin Expires September 13, 2014 [Page 4] Internet-Draft DTNTSYNC March 2014 R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant Networking Architecture", RFC 4838, April 2007. [RFC5050] Scott, K. and S. Burleigh, "Bundle Protocol Specification", RFC 5050, November 2007. 6.2. Informative References [I-D.irtf-dtnrg-sbsp] Birrane, E., "Streamlined Bundle Security Protocol Specification", draft-irtf-dtnrg-sbsp-00 (work in progress), July 2013. [RFC6257] Symington, S., Farrell, S., Weiss, H., and P. Lovell, "Bundle Security Protocol Specification", RFC 6257, May 2011. [WOOD08] Wood, L., Eddy, W., and P. Holliday, "A Bundle of Problems", December 2008. Author's Address Fred L. Templin (editor) Boeing Research & Technology P.O. Box 3707 Seattle, WA 98124 USA Email: fltemplin@acm.org Templin Expires September 13, 2014 [Page 5]