[dtn-security] Re(2): Bundle Security Protocol: one more item

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

Hi Susan,

>Now that I think about it, there may be more to consider with regard to
>how this bit works in relation to the security blocks.  It is all bound
>up in the issue of how security works if some nodes don't support it.
>
>Suppose for example there are nodes 1, 2, and 3 and only nodes 1 and 3
>implement the Bundle Security Protocol. This means that if node 1
>inserts a BAB and forwards the bundle to node 2, and node 2 doesn't
>understand the BAB and isn't configured to delete the BAB or delete the
>bundle, then node 2 will forward the bundle to node 3 with this "block
>was forwarde without being processed" bit set in the BAB. When node 3
>receives the bundle and tries to authenticate the security result in
>the BAB, it won't authenticate (because of this bit change). This may
>be okay for the BAB, but it would work the same for the PSH and I'm not
>sure that's okay.  
>
>If node 1 is a PSH-source, node 2 doesn't understand the PSH and node 3
>is a PSH-dest, then if node 2 forwards the bundle with this bit set in
>the PSH, then I think we either have to specify that this bit must be
>reset by a node before the node validates the security result in the
>PSH or that this bit must be masked out so that it is omitted from the
>mutable canonicalization form of the bundle. (same for CH I think.)
>
>Assuming this is true, does anyone have a preference for whether we
>should mandate that nodes processing the PSH reset this bit before
>calculating the security result or whether we should just leave this
>bit out of the mutable canoncial form?
>
>Any other thoughts?

in fact, yes :)  Two of them.

-----

First is that we need to better define what "processing" is. I mentioned
this the other day in a somewhat different context (intermediate
validation) but it certainly is a big issue here.

Do the various block-processors define what processing is, and what is
meant by "success" and "failure", or are these topics for the bundle spec? 

And when the bit can be turned on here and off there and on again in yet
a third place, what real meaning does it have??

With regard to processing, what does it mean, for example, for a PS
block if the current node is not the security destination? Does that
change if the current node does in fact have sufficient information to
verify the payload? If it does and the verification fails, does the
current node still forward the bad bundle?

Another example is to think of what it means to receive a bundle but not
have the extension necessary to interpret it, and then to receive a
bundle with a security block and have that block fail the validation
check. The latter is clearly a "failure" but what about the former? It's
not a success but is it a failure? If we mark it as "could not be
processed" then might other nodes interpret that to mean it really failed.

I'm sure we can't specify "processing" in particular detail but we
should define how it is specified, and the various limits.

-----

My second issue is less closely related to your original question. The
bundle spec at present refers to extensions but doesn't define them,
which is OK. But there are problems which arise because, as you
describe, a bundle may be processed differently at various nodes. Your
1-2-3 example in the second paragraph above is a good example.

I believe that the base bundle specification should contain a certain
minimum requirement with regard to extension blocks in order that
predictable processing can happen. For example, the bundle specification
describes extension blocks but does not specify that block types 2, 3
and 4 are used by and reserved for the security protocol. So an
implementation could define its own set of 2,3 and 4 and still be
conformant with the bundle protocol. What a mess that would be.

We need the base specification to require that extensions are
implemented in accord with the appropriate specification. The extensions
are optional and you can omit them and be in conformance, but you can't
be in conformance if your implementation + extensions violates the
various specifications. So, you don't have to do them, but you can't do
them differently.

Especially in the case of security, we might provide a small description
in the base spec which defines 2, 3 and 4 and specifies what a non-
security implementation should do if it encounters blocks of those
types. I suggest that this specify that 2 [BA] be discarded and 3 and 4
[PS and C] be forwarded unchanged for someone else to deal with. This
might override the "discard" flag setting, or might not. That's an open
question, and should be decided and specified [there are good arguments
for and against].

-----


Regards.....Peter