Re: [dtn-interest] Draft DTNRG Philly Agenda...

[Lloyd Wood <[e-mail]>]

At Saturday 01/03/2008 18:24 +0000, Stephen Farrell wrote:
>Lloyd Wood wrote:
>> At Saturday 01/03/2008 12:23 +0000, Stephen Farrell wrote:
>>> I was assuming we'd just have the chat without PPT since we
>>> already had a presentation on this before - has it changed
>>> significantly?
>> 
>> http://tools.ietf.org/id/draft-irtf-dtnrg-bundle-checksum-01.txt
>> 
>> Yes, this draft has changed significantly. Good you asked, otherwise the chairs and others might not be aware of this and might not think to read this working group 
>
>This is not an IETF working group. Rather basic differences exist between IRTF RGs and IETF WGs.

Sorry, slip of the tongue. 'the -irtf- in the title indicates it's been adopted as a *research* group... draft, which is what I meant to indicate.

You asked if this draft has changed. It has. My announcement of the draft in:
http://maillists.intel-research.net/pipermail/dtn-interest/2008-February/003020.html
did not call out those changes. As I said below, my fault. I didn't attempt to draw any attention to its content to attract interest. So, here's a summary of the important bits.

Even using the 'rework existing ciphersuites to add new ciphersuites for reliability only' method that we've now carefully explored in a couple of different ways before writing:
http://tools.ietf.org/id/draft-irtf-dtnrg-bundle-checksum-01.txt
we've found a couple of problems that this approach cannot solve, which the draft talks about:

1. We've identified a problem with the concept of Custody Transfer, in that unless the (nth) recipient along can be sure it has the bundle unaltered and unerrored, its custody receipt back to the n-1th node really isn't worth much. As it stands in the existing Bundle Protocol, Custody Transfer ignores errors creeping in, because it can't detect them. We think Custody Transfer needs to have protection against errors to be at all meaningful; a node can't detect errors with encrypted bundles that it is relaying but doesn't have the keys for.

2. We've identified cases where resends across the network are possible much faster for reliability-only clear-ciphersuite bundles than secured encrypted bundles, because a node along the path can perform a end-to-end reliability check on the clear bundle using the checksum, detect errors introduced earlier, and get a resend of the bundle earlier with a tighter and faster control loop. With encrypted payloads where intermediate nodes don't have the keys, this check of the payload is only possible at a node with the key, leading to a longer control loop as the now-errored payload still has to be forwarded to its security destination before the error can be picked up. In disconnected DTNs, lengthening this loop is far more significant than it is in the terrestrial internet where added hops only add milliseconds (say, comparing the IPv4 at-every-node and IPv6-at-destination-only header checks). Use of secured bundles can lead to a network performance problem that discourages use of security or of third-party untrusted-node relaying of secured bundles in DTNs. 

So, in the approach in the draft, introducing reliability without security to the Bundle Protocol for reliable, unencrypted, payloads, brings benefits that security alone in the BP can't have for encrypted payloads (meaningful Custody Transfer, shortened control loops).

We have identified two approaches to avoiding these two problems:

A. End-to-end bundle security within an outer end-to-end reliability wrapper for intermediate nodes use to to check bundles and detect errors before forwarding is one way around this performance problem, and it also makes for meaningful Custody Transfer. This would be a major change in how the bundle protocol is structured (analogous to the push/pop stuff discussed with Peter on this list a while back, pushing an outer e2e reliability checksum around an encrypted-e2e bundle payload.) We haven't attempted to look at an implementation that would do this in more detail.

B. The other way around these two issues is to only ever forward through trusted nodes which have all the keys, so that those nodes can check the content for introduced errors (or tampering) and where Custody Transfer becomes meaningful again as bundles can be checked for errors before being relayed on, with early resends requested in tighter control loops if errors are detected.


>And the sarcasm is neither welcome nor effective. It just makes
>you look silly and IMO makes it less likely your ideas will gain
>ready (or any) acceptance.

The ideas should stand on their own merit - once they're clearly presented and understood by the group. Our written conclusions in this draft form the starting point for any discussion at the meeting, and we can summarise them neatly and concisely in pictures in five minutes before the discussion. Believe me, the stuff you've just waded through reading above, which took us months to be able to even articulate, is better in pictures...

L.

>Stephen.
>
>> draft before the meeting. (My fault for assuming you'd read the draft. We had to read your latest security drafts to write it!) There's an important control loop/network performance argument that needs to be presented and discussed.
>
>> 
>> I include a copy of your latest agenda below, along with drafts where I know them, which are always worth including in the agendas. Reading the drafts before the talks increases understanding immensely. A discussion without a talk on the issues first, by those who have actually studied the issues closely enough to write them down coherently, to attempt to bring those who haven't up to speed and set the topics for discussion is really not worth having. Well-thought-out written arguments are the starting point for discussion here.
>> 
>> (The previous presentation in Chicago was on the very different
>>  http://tools.ietf.org/html/draft-eddy-dtnrg-checksum-00
>> different name, different approach, completely rewritten since.)
>> 
>> L.
>> 
>> DTNRG IETF-71 Meeting
>> 
>> Last changed on 20080301
>> 
>> Our meeting slot is THURSDAY 0900-1130, March 13, 2008, in the Franklin 5 room.
>> 
>> We're planning to do some BP/LTP interop starting on Thursday after the meeting slot and continuing into Friday morning.
>> Agenda
>> Time    Topic   Who (link to slides)
>> 0900-0905       Welcome & agenda bash   Chairs
>> 0905-0930       DTNRG document status/news/interop plans        Chairs & others
>> 0940-1000       Security/Integrity chat         Howard Weiss (tbc)
>>                       http://tools.ietf.org/html/draft-irtf-dtnrg-bundle-checksum-01 needs presenting first
>> 1000-1010       DTN reference code      Mike Demmer
>> 1010-1020       Future reference implementation(s)      Chris Small
>> 1020-1030       N4C project     Elwyn Davies/Avri Doria
>>                       (related to http://tools.ietf.org/html/draft-irtf-dtnrg-prophet-00 I'm guessing.)
>> 1030-1040       UK-DMC  Will Ivancic
>>                       (results from implementing http://tools.ietf.org/html/draft-wood-dtnrg-saratoga-03 from orbit)
>> 1040-1050       Intentional Naming      Pritwish Basu
>> 1050-1100       Using HTTP      Lloyd Wood
>>                       http://tools.ietf.org/html/draft-wood-dtrng-http-dtn-delivery-01
>> 1100-1110       Telemetry Control Protocol      Mike Petkevich
>> 1110-1130       DARPA DTN work  Preston Marshall
>> 
>>> S.
>>>
>>> PS: the 20 minutes left over was notional - I'd of course
>>> forgotten a couple of slots that'd been requested earlier.
>>> Now fixed. [1]
>>>
>>> [1] http://www.ietf.org/proceedings/08mar/agenda/DTNRG.html
>>>
>>> Lloyd Wood wrote:
>>>> Stephen,
>>>>
>>>> A presentation on the bundle reliability and performance issues described in
>>>> http://tools.ietf.org/html/draft-irtf-dtnrg-bundle-checksum-01
>>>> now it's been written up since the last RG meet as an actual research group item, would be a very good idea. This is important, and needs to be before Howie's tbc discussion. Wes and/or I will present this.
>>>>
>>>> There is a spare 20 minutes in the agenda below, so this can easily be accommodated.
>>>>
>>>> (and 'Bill' is Will Ivancic.)
>>>>
>>>> thanks,
>>>>
>>>> L.
>>>>
>>>> Draft agenda of 29 February:
>>>> http://www.ietf.org/proceedings/08mar/agenda/DTNRG.html
>>>>
>>>> Last changed on 20080229
>>>> Our meeting slot is THURSDAY 0900-1130, March 13, 2008, in the Franklin 5 room.
>>>> We're planning to do some BP/LTP interop starting on Thursday after the meeting slot and continuing into Friday morning.
>>>>
>>>> 0900-0905 Welcome & agenda bash Chairs 
>>>> 0905-0930 DTNRG document status/news/interop plans Chairs & others 
>>>> 0940-1000 Security/Integrity chat Howard Weiss (tbc) 
>>>> 1000-1010 DTN reference code Mike Demmer 
>>>> 1010-1020 Future reference implementation(s) Chris Small 
>>>> 1020-1030 N4C project Elwyn Davies/Avri Doria 
>>>> 1030-1040 UK-DMC Bill Ivancic 
>>>> 1040-1055 Intentional Naming Pritwish Basu 
>>>> 1055-1110 Using HTTP Lloyd Wood
>>>>
>>>> At Friday 29/02/2008 18:05 +0000, Stephen Farrell wrote:
>>>>
>>>>> ...now posted. [1]
>>>>>
>>>>> Let Kevin & I know if you'd like any changes/additions.
>>>>>
>>>>> Cheers,
>>>>> Stephen.
>>>>>
>>>>> [1] http://www.ietf.org/proceedings/08mar/agenda/DTNRG.html
>>>>
>>>> Saratoga: http://www.ee.surrey.ac.uk/Personal/L.Wood/dtn/
>>>>
>>>> <http://www.ee.surrey.ac.uk/Personal/L.Wood/><[e-mail]> 
>>>>
>>>> _______________________________________________
>>>> dtn-interest mailing list
>>>> [e-mail]
>>>> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>>>>
>>> _______________________________________________
>>> dtn-interest mailing list
>>> [e-mail]
>>> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>> 
>> <http://info.ee.surrey.ac.uk/Personal/L.Wood/><[e-mail]> 
>> 
>> _______________________________________________
>> dtn-interest mailing list
>> [e-mail]
>> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>> 
>_______________________________________________
>dtn-interest mailing list
>[e-mail]
>http://maillists.intel-research.net/mailman/listinfo/dtn-interest

<http://info.ee.surrey.ac.uk/Personal/L.Wood/><[e-mail]>