One document matched: draft-irtf-dtnrg-ltp-extensions-01.txt
Differences from draft-irtf-dtnrg-ltp-extensions-00.txt
Delay Tolerant Networking Research Group S. Farrell
Internet Draft Trinity College Dublin
<draft-irtf-dtnrg-ltp-extensions-01.txt> M. Ramadas
July 2005 Ohio University
Expires January 2006 S. Burleigh
NASA/Jet Propulsion Laboratory
Licklider Transmission Protocol - Extensions
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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 a "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
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].
Discussions on this internet-draft are being made in the Delay
Tolerant Networking Research Group (DTNRG) mailing list. More
information can be found in the DTNRG web-site at
http://www.dtnrg.org
Abstract
In an Interplanetary Internet setting deploying the Bundling protocol
being developed by the Delay Tolerant Networking Research Group, the
Licklider Transmission Protocol (LTP), is intended to serve as a
Farrell et al. Expires - January 2006 [Page 1]
Internet Draft LTP - Extensions July 2005
reliable convergence layer over single hop deep-space RF links. LTP
does ARQ of data transmissions by soliciting selective-acknowledgment
reception reports. It is stateful and has no negotiation or
handshakes.
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 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.
Table of Contents
1. Introduction.................................................. 2
2. Security Extensions........................................... 3
2.1 LTP Authentication ...................................... 3
2.2 Cookie Mechanism......................................... 6
3. Security Considerations ...................................... 7
4. IANA Considerations .......................................... 7
5. Acknowledgments .............................................. 7
6. References ................................................... 8
6.1 Normative References ..................................... 8
6.2 Informative References ................................... 8
7. Author's Addresses ........................................... 8
8. Copyright Statement .......................................... 9
1. Introduction
This document describes extensions to the base LTP protocol [LTP].
The background to LTP is described in the "motivation" document
[LTPMOTIVE].
Currently the extensions defined all aim to provide additional
security for LTP.
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
Farrell et al. Expires - January 2006 [Page 2]
Internet Draft LTP - Extensions July 2005
defined below requires both header and trailer extensions, which both
use the same tag.
2. Security Extensions
2.1 LTP Authentication
<<Note : The LTP-Auth security mechanism defined here may in future
revisions be moved back to the main protocol specification [LTP] if
there is community consensus in having it as a critical feature that
ought to be included in all implementations of the protocol.>>
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.
<<TODO: Check that ignoring is ok for all cases of response
generation.>>
The LTP authentication extension field has 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 header,
and the third of which is carried in the segment trailer.
The fields which 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.
Ciphersuite: an eight 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).
The LTP-auth header extension MUST be present in the first segment
from any LTP session which 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.
Farrell et al. Expires - January 2006 [Page 3]
Internet Draft LTP - Extensions July 2005
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 depends on the
ciphersuite.
We define three ciphersuites in this specification. Our approach here
is to "hardcode" all algorithm options in a single ciphersuite value
so 256 potential ciphersuites are supported by this version of LTP.
Ciphersuite Value
----------- -----
OriginAuth 0
Signature 1
NULL 255
1. OriginAuth Ciphersuite
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).
<<Need to check if this is still the best HMAC variant to pick -
and whether to truncate and so allow the extra bits for key mgt.
later on.>>
2. Signature Ciphersuite
The Signature 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 SHA1 [RSA]. 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). <<Should we move to rsa
with sha256?>>
3. NULL Ciphersuite
<<It is probably debatable whether it is better to include this or
not. A purist crypto position would probably be "just allow a CRC
if that's what you want", a more code-centric position might be "I
have working HMAC code, why not use that?". So this ciphersuite
may well change or disappear as the document progresses.>>
Farrell et al. Expires - January 2006 [Page 4]
Internet Draft LTP - Extensions July 2005
The NULL ciphersuite is basically the same as the OriginAuth
ciphersuite, but with a hardcoded key. This ciphersuite
effectively provides only data integrity without authentication,
and thus is subject to active attacks and is the equivalent of
providing a 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, but who cares
anyway?>>
In each case the bytes which are input to the cryptographic
algorithm consist of the entire LTP segment except the AuthVal. In
particular the header extensions field which may contain the
ciphersuite number and the KeyID field are part of the input.
<<This causes a problem if somehow we get two separate LTP auth
headers. Two possible fixes - include the KeyID in the trailer in
that case, or else just require the originator to only include the
correspond header when calculating the trailer and then make the
recipient search when it happens, which'll be never, or nearly so.
I might want two LTP auth headers if I'm not sure about which
ciphersuite or public key will work for the LTP peer, which should
be rare but can happen (esp the "which public key" part). I think
that I favor making the recipient search for now.>>
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
ext tag sndv c-s k-id
+----+----+----+----+----+
|0x11|0x00|0x02|0x00|0x24|
+----+----+----+----+----+
The Extensions field has the value 0x11 meaning 1 header extension is
present (the LTP-auth one, denoted by the MS-nibble value of 1) and
one trailer extension (the AuthVal, not shown). The next octet is the
extension tag (0x00 for LTP-auth), followed by the SDNV encoded
length of the value which contains the one octet ciphersuite (0x00
meaning OriginAuth) and lastly the KeyID, in this case with a short
value of 0x24.
Farrell et al. Expires - January 2006 [Page 5]
Internet Draft LTP - Extensions July 2005
2.2 A Cookie mechanism
<<Note: this mechanism is not yet entirely worked-out and is included
at this stage mainly to get feedback as to whether or not it should
be included with LTP.>>
The use of cookies is a well known way to make denial-of-service
attacks harder to mount. We may define an extension field which can
contain a cookie value for use in cases where an implementation is
liable to such attacks.
The cookie is placed in the header in an extension field. The cookie
extension field has extension tag value 0x01. The cookie extension
requires no trailer field.
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 cookies values can
be derived using lots of different schemes so long as they produce
random looking and hard to guess values.
The first cookie inserted into a segment for this session is called
the initial cookie.
Cookies do not outlast an LTP session. <<Revisit this?? Could have a
TTL too?>>
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
which 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). <<Probably extending my own cookie is only useful if cookies
can outlast sessions.>>
It can happen that both sides emit segments containing an initial
Farrell et al. Expires - January 2006 [Page 6]
Internet Draft LTP - Extensions July 2005
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 recipt 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 which 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.
3. Security Considerations
<<TBS and will include consideration of cookie sizes as well as
combining LTP auth with cookies.>>
4. IANA Considerations
At present there are none known.
5. Acknowledgments
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.
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.
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.
Part of this work was carried out at Trinity College Dublin as part
of the Dev-SeNDT contract funded by Enterprise Ireland's technology
Farrell et al. Expires - January 2006 [Page 7]
Internet Draft LTP - Extensions July 2005
development programme.
6. References
6.1 Normative References
[LTP] Ramadas, M., Burleigh, S., and Farrell, S., "Licklider
Transmission Protocol - Specification", draft-irtf-dtnrg-ltp-03.txt
(Work in Progress), July 2005.
[B97] S. Bradner, "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[HMAC] Krawczyk, H. et al, "HMAC: Keyed-Hashing for Message
Authentication", RFC 2104, February 1997.
[RSA] Kaliski, B, Staddon J, "PKCS #1: RSA Cryptography
Specifications Version 2.0", RFC 2437, October 1998.
6.2 Informative References
[LTPMOTIVE] Burleigh, S., Ramadas, M., and Farrell, S., "Licklider
Transmission Protocol - Motivation", draft-irtf-dtnrg-ltp-
motivation-01.txt (Work in Progress), Jujly 2005.
[PKIXPROF] Housley, R. et al, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List (CRL)
Profile", RFC 3280, April 2002.
7. Author's Addresses
Stephen Farrell
Distributed Systems Group
Computer Science Department
Trinity College Dublin
Ireland
Telephone +353-1-608-3070
Email stephen.farrell@cs.tcd.ie
Manikantan Ramadas
Internetworking Research Group
301 Stocker Center
Ohio University
Athens, OH 45701
Telephone +1 (740) 593-1562
Email mramadas@irg.cs.ohiou.edu
Scott C. Burleigh
Farrell et al. Expires - January 2006 [Page 8]
Internet Draft LTP - Extensions July 2005
Jet Propulsion Laboratory
4800 Oak Grove Drive
M/S: 179-206
Pasadena, CA 91109-8099
Telephone +1 (818) 393-3353
FAX +1 (818) 354-1075
Email Scott.Burleigh@jpl.nasa.gov
8. Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights."
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Farrell et al. Expires - January 2006 [Page 9]
| PAFTECH AB 2003-2026 | 2026-04-24 03:24:24 |