[dtn-interest] comments on draft-irtf-dtnrg-bundle-checksum-01

["Symington, Susan F." <[e-mail]>]

Wesley, Lloyd, and Will,

I've read through your bundle_checksum_01 draft.

I agree that it would be nice to have a mechanism that enables every
node in the network to  verify whether a bundle that it receives for
forwarding or delivery has had any errors  introduced into it. As you
point out, there is no point in wasting network resources  forwarding a
bundle across the network if it will only be discarded at its
destination  because it fails an integrity check. Furthermore, there is
no point in taking custody of a  bundle for storing and later
forwarding if it will only be discared at its destination  because it
fails an integrity check. This is basically the reasoning behind using
the Bundle  Authentication Block (BAB). The idea is to identify and
discard erroneous bundles at the  first node at which they are
received.

You assert that computing checksums on a hop-by-hop basis would be
inadequate because this  would allow errors that are introduced within
a bundle node's memory, storage, or forwarding  system to go unnoticed.
My first thought is that I wonder how much of a concern this really
is. I don't know; I'm just wondering. Defining a hop-by-hop "checksum"
(I'm using this term  as shorthand for any unkeyed or NULL-keyed
ciphersuite) for use in the BAB may not be ideal,  but it seems a lot
less fraught with complexities than defining an an end-to-end checksum
that has the property that it can be verified at any intermediate node.
An  end-to-end checksum could be used in conjunction with a BAB
checksum to ensure that errors  that are missed by use of the BAB
checksum are found at the destination. The use of both a  BAB checksum
and a PIB (end-to-end) checksum in combination would allow all errors
that were not introduced in the  nodes themselves to be discovered
immediately, and all other errors to be discovered at the  destination.
So, performing checksumming in the BAB may be something to reconsider.
(It also has  the added benefit of protecting all the mutable fields in
the bundle.) If you have already  considered this carefully, or if this
was already discussed and dismissed at the last DTNRG meeting, which I
missed, my apologies.

You want to use the Payload Integrity Block (PIB) to compute checksums
at the source and  verify them at the destination because this is the
only way to ensure integrity along the  entire path. While verifying at
the destination may be relatively easy, computing checksums  at the
source and being able to verify them at any node along the way to the
destination is much harder, as you have discovered. 

The main question that stands out for me as I read your draft is how it
will interact with  fragmentation, and I don't think the answer is
favorable. Suppose a bundle is generated  by an application and custody
transfer is requested. According to your draft, the bundle must have a
PIB checksum attached to it. Then suppose at some later node the bundle
is fragmented  into two parts. These two parts will themselves each be
a bundle, one having a payload block  with the first n bytes of the
original payload and the other having a payload block with the  last m
bytes of the original payload. The first fragment will have the PIB
checksum in it.  When these fragments are forwarded to separate
next-hop nodes, the node that receives the  first fragment will not be
able to verify the PIB checksum in it because the payload in that
fragment is not the payload over which the PIB checksum was calculated.
If this node tries to  perform the PIB checksum verification, it will
end up discarding the bundle. The PIB checksum  can only be verified at
a node that has all fragments and is able to reassemble them so as to
recover the entire original payload.

In Appendix A you list several problems that "are known to plague
mutable canonicalization".  I wish to address each of these: 

1. I can't find the first problem that you list (the claim that there
are 3 fields in the wrong  order) in the current (05) I-D. Perhaps this
was a problem in a previous draft that has since  been fixed. If not,
can you please point out the page?

2. The second problem you list is contrived. I don't think it is fair
to fault the mutable  canonicalization algorithm for zeroing out
reserved bits that aren't yet used because they  may someday be used
and will at that point need to be protected. Of course if the reserved
bit become defined and they won't be mutable, the algorithm will need
to be changed to  protect them. The BSP says this itself on page 30:
"We omit the reserved flags because we  cannot determine if they will
change in transit. The masks specified above may have to be  revised if
additional flags are defined and they need to be protected."

3. The third problem that you cite is a complaint that the "bundle is a
fragment" bit is  unprotected. This bit is mutable. It can't be
protected with an end-to-end ciphersuite. What  alternative do you
suggest?

4. The fourth problem that you cite is that the canonicalization
procedure is too complex. Well,  it is complex, but we didn't
deliberately try to make it that way. It would be great if you  could
come up with a simpler alternative. 

Again, I'm not sure what was discussed at the previous DTNRG meeting
with regard to the  previous version of this checksum ciphersuite
draft, but it seems that what you really want  and need to is to have
checksum ciphersuites for both the BAB and the PSB and use them in
combination. At intermediate nodes, only the BAB ciphersuite could be
guaranteed to be  verified. The PIB ciphersuite could only be
guaranteed to be verified at the destination,  assuming all fragments
have been delivered there, or at intermediate nodes that have all
fragments and that can reassemble. There are probably other issues that
need to be addressed if you take this approach and I'm not claiming to
have thought it through completely, but it seems that this might be a
good direction to explore to get a best-fit solution to the problem
that you are trying to solve.

Thank you for acknowledging me in your draft. I hope my comments
continue to be helpful.
-susan

*****************************************************************
Susan Symington
The MITRE Corporation
[e-mail]
703-983-7209 (voice)
703-983-7142 (fax)
******************************************************************
 

>-----Original Message-----
>From: [e-mail] 
>[mailto:[e-mail]] On Behalf Of Lloyd
Wood
>Sent: Saturday, March 01, 2008 4:52 PM
>To: Delay Tolerant Networking Interest List
>Subject: Re: [dtn-interest] Draft DTNRG Philly Agenda...
>
>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 us!
> e 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]> 
>
>
>_______________________________________________
>dtn-interest mailing list
>[e-mail]
>http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>