Re: [dtn-interest] New bundle internet draft and paper comparing protocols for reliability errored delivery.

Lloyd Wood <L.Wood@surrey.ac.uk> Tue, 24 July 2007 13:49 UTC

Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id l6ODnNJ07712 for <dtn-interest@mailman.dtnrg.org>; Tue, 24 Jul 2007 06:49:23 -0700
Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 24 Jul 2007 15:49:08 +0200
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ao8CAKKgpUaQ/uCLZmdsb2JhbACPWwsKJA
X-IronPort-AV: i="4.16,574,1175464800"; d="scan'208"; a="148869795:sNHT273424560"
Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l6ODn7QF001827; Tue, 24 Jul 2007 15:49:07 +0200
Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l6ODn7kt020242; Tue, 24 Jul 2007 13:49:07 GMT
Received: from lwood-wxp01.cisco.com (che-vpn-cluster-1-82.cisco.com [10.86.240.82]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id OAA14548; Tue, 24 Jul 2007 14:49:06 +0100 (BST)
Message-Id: <200707241349.OAA14548@cisco.com>
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Tue, 24 Jul 2007 14:48:34 +0100
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
From: Lloyd Wood <L.Wood@surrey.ac.uk>
Subject: Re: [dtn-interest] New bundle internet draft and paper comparing protocols for reliability errored delivery.
Cc: Scott Burleigh <Scott.Burleigh@jpl.nasa.gov>, dtn-interest@mailman.dtnrg.org
In-Reply-To: <46A5FC1A.8060107@cs.tcd.ie>
References: <200707172036.VAA19930@cisco.com> <469DC5D7.7030305@jpl.nasa.gov> <200707220903.KAA14503@cisco.com> <46A4C192.1020001@jpl.nasa.gov> <200707240512.GAA13446@cisco.com> <46A5FC1A.8060107@cs.tcd.ie>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Authentication-Results: ams-dkim-2; header.From=L.Wood@surrey.ac.uk; dkim=neutral
Sender: dtn-interest-admin@mailman.dtnrg.org
Errors-To: dtn-interest-admin@mailman.dtnrg.org
X-BeenThere: dtn-interest@mailman.dtnrg.org
X-Mailman-Version: 2.0.13
Precedence: bulk
List-Unsubscribe: <http://mailman.dtnrg.org/mailman/listinfo/dtn-interest>, <mailto:dtn-interest-request@mailman.dtnrg.org?subject=unsubscribe>
List-Id: Delay Tolerant Networking Interest List <dtn-interest.mailman.dtnrg.org>
List-Post: <mailto:dtn-interest@mailman.dtnrg.org>
List-Help: <mailto:dtn-interest-request@mailman.dtnrg.org?subject=help>
List-Subscribe: <http://mailman.dtnrg.org/mailman/listinfo/dtn-interest>, <mailto:dtn-interest-request@mailman.dtnrg.org?subject=subscribe>
List-Archive: <http://mailman.dtnrg.org/pipermail/dtn-interest/>

Stephen,

my full question to Scott, which you have edited down, was:
"Why isn't LTP being standardised in CCSDS, which specifies those space links?"
[..]
Again, if LTP is intended principally for deep space, why isn't it being specified in CCSDS, just as CFDP was?
[..]
Surely CCSDS is the best forum to make things clear to spacecraft communication engineers? Isn't LTP intended for more than just spacecraft?"

CCSDS is a subgroup of the ISO standards body, and produces eventual standards for the space communications community via a different route from the IETF/IRTF. That was not a comment on the IRTF/IETF experimental/standards process (and, incidentally, there's a well-worn path from experimental to standard in the IETF, though chartering an IETF wg to get something standards-track would be required eventually.). For example, CFDP is now a CCSDS blue book, or recommended CCSDS standard. LTP could easily follow that track if desired.

The scope of use of experimental RFCs can be specified based on the wording placed at the start - safe for use across the terrestrial Internet, or safe for use only in your own private networks. Saratoga and LTP can be expected to be the latter.

I agree that, for the current LTP specification, the LTP security extensions would likely need to be mandatory to get reliability in error-rejection as a side-effect.

For Saratoga's use of MD5 as a file/bundle integrity check, we've also discussed this - SHA1 is twice as slow as MD5 (important for low-end processors), and we're only using MD5 for an integrity check. Security attack concerns are separate. Also, because Saratoga runs over UDP/UDP-Lite and only over UDP/UDP-Lite, the full IPsec security suite is available for use by Saratoga, and can be leveraged to provide security. With link security, bundle security and IPsec, is another layer needed?

cheers,

L.

At Tuesday 24/07/2007 14:18 +0100, Stephen Farrell wrote:


>Lloyd Wood wrote:
>
>>Why isn't LTP being standardised...<elsewhere>
>
>Lloyd,
>
>The above is wrong. LTP, and presumably Saratoga, are being put
>forward as experimental RFCs. That is very different from being
>on the standards-track. Maybe you should re-read some of the IRTF
>and IETF process documents?
>
>IMO, as-is, neither protocol would pass muster for the standards
>track.
>
>For LTP, arguably the security extensions would have to be made
>mandatory to implement. I could well imagine that the red/green
>mechanism might change (e.g. to allow red segments to be
>interspersed anywhere in the block).
>
>For Saratoga, the use of MD5 would be a killer as would the lack
>of any security primitives.
>
>Both would fall over the lack of key management.
>
>Both would have to have a bunch of work done on fairness and
>all the other things that people care about for protocols that
>could be in widespread use over the Internet.
>
>I honestly don't see any value in a p*&&ing competition here,
>other than to raise the temperature at DTNRG meetings which
>IMO provides *very* limited amusement,
>
>S.