Re: [dtn] BPv7 bundle flags

["Burleigh, Scott C (312B)" <[e-mail]>]

Hi, Brian.  I think we are covered here: the last sentence of the second bullet of 4.2.3 of the bpbis I-D says that the block number of the payload block is always zero.

Scott

From: Brian Sipos <[e-mail]>
Sent: Thursday, April 18, 2019 1:42 PM
To: Burleigh, Scott C (312B) <[e-mail]>; [e-mail]
Subject: [EXTERNAL] Re: BPv7 bundle flags

Ok thank you; this makes sense. There does seem to be a discrepancy between what you've stated (which matches [1]) and the fact that the primary block does not have an explicit "block number" associated with it. It seems that currently there is no way for a BIB to apply to the primary block (how is it identified as a target?)

Should there be an implicit psedudo-block-number assigned to the primary block? Or should there be some mechanism specified in [1] on how to target the primary block? Is applying a BIB to the primary block something that has already been accommodated for in BPSEC?
Unfortunately, the examples in [2] do not actually show an encoded form, so there is no way to see how BIB-covering-primary-block is intended to be encoded...

Thanks,
Brian S.

[1]: https://tools.ietf.org/html/draft-ietf-dtn-bpsec-10#section-3.6
[2]: https://tools.ietf.org/html/draft-ietf-dtn-bpsec-10#section-3.11.1
________________________________
From: Burleigh, Scott C (312B) <[e-mail]<mailto:[e-mail]>>
Sent: Monday, April 15, 2019 11:23
To: Brian Sipos; [e-mail]<mailto:[e-mail]>
Subject: RE: BPv7 bundle flags

Hi, Brian.  People have been asking for something like a Manifest block for several years, but there has never been quite enough energy to get one defined.  So that flag is intended to support a notional future capability.

As I recall, the intent of this capability was to ensure that a certain type of bundle tampering - removal of one or more extension blocks - would be detectable; only a Manifest extension block, protected by a BIB signed by the source node, could accomplish this.  But the one bit of tampering that a signed Manifest block could not detect would be removal of the Manifest block itself.  [Replacement of the Manifest block with a bogus manifest would be detectable due to lack of a BIB signed by the source node.]  The way to make this detectable would be to set a flag in the primary block and (as usual) protect the primary block with a BIB signed by the source node.

So I think a good case can be made for retaining that flag and adding definition of the Manifest block to the charter of the DTN WG once our first round of document are well on their way.  But if the consensus of the WG is otherwise then I will happily revise the BPbis spec.

Scott

-----Original Message-----
From: Brian Sipos <[e-mail]<mailto:[e-mail]>>
Sent: Saturday, April 13, 2019 9:14 AM
To: Burleigh, Scott C (312B) <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: [EXTERNAL] BPv7 bundle flags

Scott,
As of BPbis -12 draft, there is a bundle flag "bundle contains a Manifest block" which seems to not really serve any purpose, especially because the block type is not defined in the draft. The other flags indicate how the bundle is to be handled or reported-about, but I don't see what this flag is supposed to influence. If the bundle does in fact contain a manifest block then that should be evident from the presence of that block type itself.

Should this flag really be defined in bpbis, or just reserved for later use? And is there really a use for a flag even when the block type is defined?
Thanks,
Brian S.