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
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.




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.

本RFC不适用于任何级别的互联网标准。它代表了互联网研究任务组(IRTF)的延迟容忍网络(DTN)研究小组的共识。IETF将来可能会考虑将其标准化,但IETF不承认该RFC适用于任何目的,并特别指出,发布决定并非基于IETF对安全、拥塞控制或与已部署协议的不当交互等事项的审查。有关更多信息,请参阅RFC 3932。



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.


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 ....................................................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
1. 介绍

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
2. 安全扩展

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.


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.


If LTP were deployed layered on top of UDP, it might be possible to use IPsec or other existing security mechanisms. However, in general DTN, IPsec's key exchange (IKE) cannot work (e.g., where link delays are measured in minutes).


2.1. LTP Authentication
2.1. LTP认证

The LTP authentication mechanism provides cryptographic authentication of the segment.


Implementations MAY support this extension field. If they do not support this header, then they MUST ignore it.


The LTP authentication extension field has the extension tag value 0x00.


LTP authentication requires three new fields, the first two of which are carried as the value of the Extensions field of the LTP segment header, and the third of which is carried in the segment trailer.


The fields that are carried in the header extensions field are catenated together to form the extension value (with the leftmost octet representing the ciphersuite and the remaining octets the KeyID). The KeyID field is optional, and is determined to be absent if the extension value consists of a single octet.

header extensions字段中携带的字段被链接在一起以形成扩展值(最左边的八位字节表示密码套件,其余的八位字节表示KeyID)。KeyID字段是可选的,如果扩展值由单个八位字节组成,则确定不存在该字段。

Ciphersuite: an 8-bit integer value with values defined below.


KeyID: An optional key identifier, the interpretation of which is out of scope for this specification (that is, implementers MUST treat these KeyID fields as raw octets, even if they contained an ASN.1 DER encoding of an X.509 IssuerSerial construct [PKIXPROF], for example).

KeyID:可选的密钥标识符,其解释超出了本规范的范围(即,实现者必须将这些KeyID字段视为原始八位字节,即使它们包含X.509发行者串行构造[PKIXPROF]的ASN.1 DER编码)。

The LTP-auth header extension MUST be present in the first segment from any LTP session that uses LTP authentication, but MAY be omitted from subsequent segments in that session. To guard against additional problems arising from lost segments, implementations SHOULD, where bandwidth allows, include these fields in a number of segments in the LTP session. If the first segment (or any part thereof) is retransmitted, then the LTP-auth header extension MUST be included in the retransmission.

LTP auth头扩展必须出现在使用LTP身份验证的任何LTP会话的第一个段中,但可以从该会话的后续段中省略。为了防止由于丢失段而引起的额外问题,在带宽允许的情况下,实现应该在LTP会话的多个段中包括这些字段。如果第一段(或其任何部分)被重新传输,那么LTP auth头扩展必须包括在重新传输中。

The field carried as a trailer extension is the AuthVal field. It contains the authentication value, which is either a message authentication code (MAC) or a digital signature. This is itself a structured field whose length and formatting depend on the ciphersuite.


If for some reason the sender includes two instances of LTP-auth headers, then there is a potential problem for the receiver in that presumably at least one of the AuthVal fields will not verify. There are very few situations where it would make sense to include more than one LTP-auth extension in a single segment, since LTP is a peer-to-peer protocol. If however, keys are being upgraded, then the sender might protect the segment with both the new and old keys. In such cases, the receiver MUST search and can consider the LTP authentication valid so long as one AuthVal is correct.

如果出于某种原因,发送方包含两个LTP auth头实例,则接收方可能存在一个潜在问题,即至少有一个AuthVal字段无法验证。由于LTP是一种对等协议,因此在很少的情况下,在单个段中包含多个LTP auth扩展是有意义的。但是,如果密钥正在升级,则发送方可能会使用新密钥和旧密钥保护该段。在这种情况下,接收方必须搜索,并且可以考虑LTP认证有效,只要一个AuthVar是正确的。

For all ciphersuites, the input to the calculation is the entire encoded segment including the AuthVal extension tag and length, but not of course, including the AuthVal value.


We define three ciphersuites in this specification. Our approach is to follow the precedent set by TLS [TLS], and to "hardcode" all algorithm options in a single ciphersuite number. This means that there are 256 potential ciphersuites supported by this version of LTP-auth. Since this is a limited space, IANA has established a registry for LTP Ciphersuites as described in the IANA Considerations section below. Current ciphersuite assignments are:

我们在本规范中定义了三种密码套件。我们的方法是遵循TLS[TLS]的先例,将所有算法选项“硬编码”在一个密码套件编号中。这意味着此版本的LTP auth支持256个潜在密码套件。由于篇幅有限,IANA为LTP密码套件建立了一个注册表,如下面IANA注意事项部分所述。当前的ciphersuite分配为:

      Ciphersuite                        Value
      -----------                        -----
      HMAC-SHA1-80                          0
      RSA-SHA256                            1
      Unassigned                          2-127
      Reserved                           128-191
      Private/Experimental Use           192-254
      NULL                                 255
      Ciphersuite                        Value
      -----------                        -----
      HMAC-SHA1-80                          0
      RSA-SHA256                            1
      Unassigned                          2-127
      Reserved                           128-191
      Private/Experimental Use           192-254
      NULL                                 255

1. HMAC-SHA1-80 Ciphersuite

1. HMAC-SHA1-80密码套件

The HMAC-SHA1-80 ciphersuite involves generating a MAC over the LTP segment and appending the resulting AuthVal field to the end of the segment. There is only one MACing algorithm defined for this, which is HMAC-SHA1-80 [HMAC]. The AuthVal field in this case contains just the output of the HMAC-SHA1-80 algorithm, which is a fixed-width field (10 octets).


2. RSA-SHA256 Ciphersuite

2. RSA-SHA256密码套件

The RSA-SHA256 ciphersuite involves generating a digital signature of the LTP segment and appending the resulting AuthVal field to the end of the segment. There is only one signature algorithm currently defined for this, which is RSA with SHA256 as defined in [RSA], Section 8.2. The AuthVal field in this case is simply the signature value, where the signature value occupies the minimum number of octets, e.g., 128 octets for a 1024-bit signature).


3. NULL Ciphersuite

3. 空密码套件

The NULL ciphersuite is basically the same as the HMAC-SHA1-80 ciphersuite, but with a hardcoded key. This ciphersuite effectively provides only a strong checksum without authentication, and thus is subject to active attacks and is the equivalent of providing a Cyclic Redundancy Check (CRC).


The hardcoded key to be used with this ciphersuite is the following:


HMAC_KEY : c37b7e64 92584340 : bed12207 80894115 : 5068f738 (The above is the test vector from RFC 3537 [WRAP].)

HMAC_键:c37b7e64 92584340:bed12207 80894115:5068f738(以上是来自RFC 3537[WRAP]的测试向量。)

In each case, the bytes that are input to the cryptographic algorithm consist of the entire LTP segment except the AuthVal. In particular, the header extensions field that may contain the ciphersuite number and the KeyID field is part of the input.


The output bytes of the cryptographic operation are the payload of the AuthVal field.


The following shows an example LTP-auth header, starting from and including the Extensions field.

下面显示了一个示例LTP auth头,从Extensions字段开始,包括Extensions字段。

       ext  tag  sdnv  c-s  k-id
       ext  tag  sdnv  c-s  k-id

The Extensions field has the value 0x11 with the most significant and least significant nibble value 1, indicating the presence of one header and one trailer extension, respectively. The next octet is the extension tag (0x00 for LTP-auth), followed by the Self-Delimiting Numeric Value (SDNV) encoded length of the ensuing data: a one-octet ciphersuite (0x00 meaning HMAC-SHA1-80) and the KeyID (in this case with a short value of 0x24). The trailer extension (not shown above) should contain the AuthVal.

Extensions字段的值0x11具有最高有效位值1和最低有效位值1,分别表示存在一个标头和一个尾部扩展。下一个八位字节是扩展标记(对于LTP auth为0x00),后面是后续数据的自定界数值(SDNV)编码长度:一个八位字节的密码套件(0x00表示HMAC-SHA1-80)和密钥ID(在本例中,短值为0x24)。拖车扩展(上面未显示)应包含AuthVal。

2.2. A Cookie Mechanism
2.2. 曲奇机制

The use of cookies is a well-known way to make Denial of Service (DoS) attacks harder to mount. We define the cookie extension for use in environments where an LTP implementation is liable to such attacks.


The cookie is placed in a header extension field, and has no related trailer extension field. It has the extension tag value 0x01.


The cookie value can essentially be viewed as a sufficiently long random number, where the length can be determined by the implementation (longer cookies are harder to guess and therefore better, though using more bandwidth). Note that cookie values can be derived using lots of different schemes so long as they produce random-looking and hard-to-predict values.


The first cookie inserted into a segment for this session is called the initial cookie.


Note that cookies do not outlast an LTP session.


The basic mode of operation is that an LTP engine can include a cookie in a segment at any time. After that time, all segments corresponding to that LTP session MUST contain a good cookie value -- that is, all segments both to and from the engine MUST contain a good cookie. Clearly, there will be some delay before the cookie is seen in incoming segments -- implementations MUST determine an acceptable delay for these cases, and MUST only accept segments without a cookie until that time.


The cookie value can be extended at any time by catenating more random bits. This allows both LTP engines to contribute to the randomness of the cookie, where that is useful. It also allows a node that considers the cookie value too short (say due to changing circumstances) to add additional security. In this case, the extended cookie value becomes the "to-be-checked-against" cookie value for all future segments (modulo the communications delay as above).


It can happen that both sides emit segments containing an initial cookie before their peer has a chance to see any cookie. In that case, two cookie extension fields MUST be included in all segments subsequently (once the traffic has caught up). That is, the sender and recipient cookies are handled independently. In such cases, both cookie values MUST be "good" at all relevant times (i.e., modulo the delay). In this case, the peer's initial cookie MUST arrive before the calculated delay for receipt of segments containing this engine's cookie -- there is only a finite window during which a second cookie can be inserted into the session.


A "good" cookie is therefore one that starts with the currently stored cookie value, or else a new cookie where none has been seen in that session so far. Once a cookie value is seen and treated as "good" (e.g., an extended value), the previous value is no longer "good".


Modulo the communications delay, segments with an incorrect or missing cookie value MUST be silently discarded.


If a segment is to be retransmitted (e.g., as a result of a timer expiring), then it needs to contain the correct cookie value at the time of (re)transmission. Note that this may differ from what was the correct cookie value at the time of the original transmission.


3. Security Considerations
3. 安全考虑

The extensions specified above are generally intended to help thwart DoS attacks. For environments where lower layers provide neither integrity nor freshness, it makes sense to use both extensions together. For example, in the case where a node extends an existing cookie, the lack of origin authentication would allow a man in the middle to lock out the session.


While there are currently some concerns about using the SHA-1 algorithm, these appear to only make it easier to find collisions. In that case, the use of HMAC with SHA-1 can still be considered safe. However, we have changed to use SHA-256 for the signature ciphersuite.


4. IANA Considerations
4. IANA考虑

IANA has created and now maintains registry for known LTP ciphersuites (as defined in Section 2.1). The registry has been populated using the initial values given in Sections 2.1 and 2.2 above. IANA may assign LTP Extension Tag values from the range 2..127 (decimal, inclusive) using the Specification Required rule [GUIDE]. The specification concerned can be an RFC (whether


Standards Track, Experimental, or Informational), or a specification from any other standards development organization recognized by IANA or with a liaison with the IESG, specifically including CCSDS (


5. Acknowledgments
5. 致谢

Many thanks to Tim Ray, Vint Cerf, Bob Durst, Kevin Fall, Adrian Hooke, Keith Scott, Leigh Torgerson, Eric Travis, and Howie Weiss for their thoughts on this protocol and its role in Delay-Tolerant Networking architecture.

非常感谢Tim Ray、Vint Cerf、Bob Durst、Kevin Fall、Adrian Hooke、Keith Scott、Leigh Torgerson、Eric Travis和Howie Weiss对该协议及其在延迟容忍网络架构中的作用的思考。

Part of the research described in this document was carried out at the Jet Propulsion Laboratory, California Institute of Technology, under a contract with the National Aeronautics and Space Administration. This work was performed under DOD Contract DAA-B07- 00-CC201, DARPA AO H912; JPL Task Plan No. 80-5045, DARPA AO H870; and NASA Contract NAS7-1407.

本文件中描述的部分研究是在加利福尼亚理工学院喷气推进实验室根据与美国国家航空航天局签订的合同进行的。这项工作是根据国防部合同DAA-B07-00-CC201,DARPA AO H912执行的;JPL任务计划编号80-5045,DARPA AO H870;美国宇航局合同NAS7-1407。

Thanks are also due to Shawn Ostermann, Hans Kruse, and Dovel Myers at Ohio University for their suggestions and advice in making various design decisions. This work was done when Manikantan Ramadas was a graduate student at the EECS Dept., Ohio University, in the Internetworking Research Group Laboratory.

感谢俄亥俄大学的Shawn Ostermann、Hans Kruse和Dovel Myers在做出各种设计决策时提出的建议和建议。这项工作是在马尼坎坦·拉马达斯(Manikantan Ramadas)是俄亥俄大学电子工程系(EECS)的研究生时在互联网研究小组实验室完成的。

Part of this work was carried out at Trinity College Dublin as part of the Dev-SeNDT contract funded by Enterprise Ireland's technology development programme.

这项工作的一部分在都柏林三一学院进行,作为爱尔兰企业技术开发计划资助的Dev SeNDT合同的一部分。

6. References
6. 工具书类
6.1. Normative References
6.1. 规范性引用文件

[B97] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[B97]Bradner,S.,“RFC中用于表示需求水平的关键词”,BCP 14,RFC 2119,1997年3月。

[GUIDE] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.

[指南]Narten,T.和H.Alvestrand,“在RFCs中编写IANA注意事项部分的指南”,BCP 26,RFC 5226,2008年5月。

[HMAC] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.

[HMAC]Krawczyk,H.,Bellare,M.,和R.Canetti,“HMAC:用于消息身份验证的键控哈希”,RFC 2104,1997年2月。

[LTPSPEC] Ramadas, M., Burleigh, S., and S. Farrell, "Licklider Transmission Protocol - Specification", RFC 5326, September 2008.

[LTPSPEC]Ramadas,M.,Burleigh,S.,和S.Farrell,“利克利德传输协议-规范”,RFC 5326,2008年9月。

[RSA] Jonsson, J. and B. Kaliski, "Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1", RFC 3447, February 2003.

[RSA]Jonsson,J.和B.Kaliski,“公钥密码标准(PKCS)#1:RSA密码规范版本2.1”,RFC 3447,2003年2月。

6.2. Informative References
6.2. 资料性引用

[LTPMOTIVE] Burleigh, S., Ramadas, M., and S. Farrell, "Licklider Transmission Protocol - Motivation", RFC 5325, September 2008.

[LTPMOTIVE]Burleigh,S.,Ramadas,M.,和S.Farrell,“利克利德传输协议-动机”,RFC 53252008年9月。

[PKIXPROF] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008.

[PKIXPROF]Cooper,D.,Santesson,S.,Farrell,S.,Boeyen,S.,Housley,R.,和W.Polk,“Internet X.509公钥基础设施证书和证书撤销列表(CRL)配置文件”,RFC 52802008年5月。

[TLS] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.

[TLS]Dierks,T.和E.Rescorla,“传输层安全(TLS)协议版本1.2”,RFC 5246,2008年8月。

[WRAP] Schaad, J. and R. Housley, "Wrapping a Hashed Message Authentication Code (HMAC) key with a Triple-Data Encryption Standard (DES) Key or an Advanced Encryption Standard (AES) Key", RFC 3537, May 2003.

[WRAP]Schaad,J.和R.Housley,“用三重数据加密标准(DES)密钥或高级加密标准(AES)密钥包装散列消息认证码(HMAC)密钥”,RFC 3537,2003年5月。

Authors' Addresses


Stephen Farrell Computer Science Department Trinity College Dublin Ireland Telephone: +353-1-896-1761 EMail:


Manikantan Ramadas ISRO Telemetry Tracking and Command Network (ISTRAC) Indian Space Research Organization (ISRO) Plot # 12 & 13, 3rd Main, 2nd Phase Peenya Industrial Area Bangalore 560097 India Telephone: +91 80 2364 2602 EMail:

Manikantan Ramadas印度空间研究组织ISRO遥测跟踪和指挥网络(ISTRAC)印度空间研究组织(ISRO)班加罗尔喷丸工业区二期3号干线12号和13号地块560097印度电话:+91 80 2364 2602电子邮件

Scott C. Burleigh Jet Propulsion Laboratory 4800 Oak Grove Drive M/S: 301-485B Pasadena, CA 91109-8099 Telephone: +1 (818) 393-3353 Fax: +1 (818) 354-1075 EMail:


Full Copyright Statement


Copyright (C) The IETF Trust (2008).


This document is subject to the rights, licenses and restrictions contained in BCP 78 and at, and except as set forth therein, the authors retain all their rights.

本文件受BCP 78和,除本协议另有规定外,提交人保留其所有权利。



Intellectual Property


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.

IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围,或此类权利下的任何许可可能或可能不可用的程度,不采取任何立场;它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息,请参见BCP 78和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


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