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]