Licklider Transmission Protocol - Security Extensions
RFC 5327
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