Re(5): [dtn-interest] block-sequencing issue

["Peter Lovell" <[e-mail]>]

We've had discussions recently about interactions between bundle
protocol specifications and those for bundle security.

One thing which has become clear is that we have a difference of opinion
with regard to the "ordering" or "sequencing" of the blocks in a bundle
as it travels through various dtn nodes. The purpose of the rather
lengthy email is set out the issues as best I can and ask for
suggestions from the dtn community.


Problem
-------

The bundle protocol specification [BP] <draft-irtf-dtnrg-bundle-
spec-08.txt> specifies that a bundle is a sequence of blocks but, beyond
that, doesn't really address the issue. In that way, the specification
implicitly allows reordering at various points. The only requirements
seem to be that
(1)the primary block MUST be first, and
(2)the last block in the sequence MUST have the "last block" flag set.

On the other hand, the bundle security protocol specification [BSP]
<draft-irtf-dtnrg-bundle-security-03.txt> has a very strong sense of
block ordering. 

We need to reconcile these two positions and ensure that BSP relies only
upon the services and facilities which BP provides. If it expects more
then it is certain to fail.


Scenarios
---------

BSP's current definition makes use of ordering in two ways. 

The first is to know what data has been processed (protected) and in
what order. For example, bundle authentication generates a digest of the
entire bundle (with very minor exceptions) so the receiver can verify
that it is correct and complete. The ordering defined for this operation
is the sequence in which the blocks are transmitted "on the wire". BSP
therefore requires that the block sequence be maintained in the sending
node from the time the digest is calculated until actual transmission
occurs, and also in the receiving node from reception of the blocks
until they are presented to the bundle security process there.

The second use is to know the order of the processing steps which have
been applied to the bundle so that processing at the various destination
points can be performed in the correct, reverse order. In some cases,
several steps happen within one node while in other scenarios steps
occur at several nodes along the bundle's path. BSP operation handles
these like envelopes or onion-layers, so that the reverse ordering is
obtained by removing successive layers one at a time. Obviously, any
rearrangement of the blocks completely destroys any chance to correctly
process the bundle.

The diagram attached shows these two usages. Scenario 1 shows a bundle
being sent, having "payload security" (digest of bundle content) added
at a nearby gateway, a second layer being added to confirm node 2's
signature, and then delivery to the destination. Without integrity of
the envelopes, it's impossible to verify any of the signatures.

Scenario 2 shows a different last-hop in which node 3 not only adds
payload security, but bundle authentication as well. Bundle
authentication always processes all the message blocks into the digest
but in this case there's no way for the destination to determine the
order in which that was done.

There are additional problem scenarios but these two show the problem in
a simple way. Many real-world instances will also involve
confidentiality ciphersuites to encrypt the information, but adding that
here would not help us in thinking about the problem.


Options
-------

Bundle authentication is always hop-by-hop so, if it is used on a
particular link, then it must be present at both ends. There are no
intermediate points at which reordering can occur. So BSP can solve the
bundle authentication scenario by imposing a requirement that nodes
implementing BSP must preserve block ordering.

This is unfortunately not a solution for payload security and
confidentiality ciphersuites. These are end-to-end, or perhaps gateway-
to-gateway, and in gereral there will be intermediate nodes which do not
support BSP and are therefore not bound by its requirements. These nodes
might re-order the blocks in a bundle as part of their forwarding
process, for example.

BSP can partially solve this problem by adding a layering identifier to
each of the security blocks. This would solve BSP's own processing issue
but could not help with security for other extension blocks. It would
also add to the size of all security blocks in the bundle.

Another option is for BP to add the requirement to the specification, so
that all nodes would have to maintain block ordering. This is somewhat
problematic since BP spec is currently on track towards becoming an RFC.


Please think about this issue and let me know your thoughts.

Regards.....Peter