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

[Stephen Farrell <[e-mail]>]

Pete,

Those are really broader that the security spec. You should
raise these issues on dtn-interest/dtn-dev and see what
consensus emerges there. (And quickly would be good since we
want to finish the BP spec asap.)

S.

Peter Lovell wrote:
> 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
> 
>