Licklider Transmission Protocol - Security Extensions
RFC 5327
Document | Type |
RFC - Experimental
(September 2008; No errata)
Was draft-irtf-dtnrg-ltp-extensions (dtnrg RG)
|
|
---|---|---|---|
Last updated | 2018-12-20 | ||
Stream | IRTF | ||
Formats | plain text pdf htmlized bibtex | ||
Stream | IRTF state | (None) | |
Consensus Boilerplate | Unknown | ||
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 5327 (Experimental) | |
Telechat date | |||
Responsible AD | Russ Housley | ||
Send notices to | ipr@ietf.org., draft-irtf-dtnrg-ltp-motivation@ietf.org |
Network Working Group S. Farrell Request for Comments: 5327 Trinity College Dublin Category: Experimental M. Ramadas ISTRAC, ISRO S. Burleigh NASA/Jet Propulsion Laboratory September 2008 Licklider Transmission Protocol - Security Extensions Status of This Memo This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited. IESG Note This RFC is not a candidate for any level of Internet Standard. It represents the consensus of the Delay Tolerant Networking (DTN) Research Group of the Internet Research Task Force (IRTF). It may be considered for standardization by the IETF in the future, but the IETF disclaims any knowledge of the fitness of this RFC for any purpose and in particular notes that the decision to publish is not based on IETF review for such things as security, congestion control, or inappropriate interaction with deployed protocols. See RFC 3932 for more information. Abstract The Licklider Transmission Protocol (LTP) is intended to serve as a reliable convergence layer over single-hop deep-space radio frequency (RF) links. LTP does Automatic Repeat reQuest (ARQ) of data transmissions by soliciting selective-acknowledgment reception reports. It is stateful and has no negotiation or handshakes. This document describes security extensions to LTP, and is part of a series of related documents describing LTP. This document is a product of the Delay Tolerant Networking Research Group and has been reviewed by that group. No objections to its publication as an RFC were raised. Farrell, et al. Experimental [Page 1] RFC 5327 LTP - Extensions September 2008 Table of Contents 1. Introduction ....................................................2 2. Security Extensions .............................................2 2.1. LTP Authentication .........................................3 2.2. A Cookie Mechanism .........................................6 3. Security Considerations .........................................7 4. IANA Considerations .............................................7 5. Acknowledgments .................................................8 6. References ......................................................8 6.1. Normative References .......................................8 6.2. Informative References .....................................9 1. Introduction This document describes extensions to the base LTP protocol [LTPSPEC]. The background to LTP is described in the "motivation" document [LTPMOTIVE]. All the extensions defined in this document provide additional security features for LTP. LTP is designed to provide retransmission-based reliability over links characterized by extremely long message round-trip times (RTTs) and/or frequent interruptions in connectivity. Since communication across interplanetary space is the most prominent example of this sort of environment, LTP is principally aimed at supporting "long- haul" reliable transmission in interplanetary space, but has applications in other environments as well. This document describes security extensions to LTP, and is part of a series of related documents describing LTP. Other documents in this series cover the motivation for LTP and the main protocol specification. We recommend reading all the documents in the series before writing code based on 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 [B97]. 2. Security Extensions The syntactical layout of the extensions are defined in Section 3.1.4 of the base protocol specification [LTPSPEC]. Implementers should note that the LTP extension mechanism allows for multiple occurrences of any extension tag, in both (or either) the header or trailer. For example, the LTP authentication mechanism defined below requires both header and trailer extensions, which both use the same tag. Farrell, et al. Experimental [Page 2] RFC 5327 LTP - Extensions September 2008 This document defines new security extensions for LTP but does not address key management since key management in Delay-Tolerant Networking (DTN) remains an open research question.Show full document text