Interim Meeting Minutes DTN WG Minutes Interim Meeting January 18th, 2016 Administrativia -------------------------------------------------------------------------------- - Notewell noted Summary -------------------------------------------------------------------------------- 1. Yokohama meetings resolved all issues for BPBIS except CRC schemes and Inventory Block. 2. A mailing list thread will be started for CRC options in the primary block and an inventory/manifest feature for bundles. 3. A mailing list thread will be started for BPSEC changes related to removal of security destinations and removal of BAB block. Questions (Q), Answers (A), and Comments (C): Presentation: BPBIS, Scott Burleigh -------------------------------------------------------------------------------- Overview: Yokamahma meetings resolved all but 2 issues: CRC schemes and Inventory Block. - Someone take action item to decide CRC schemes. Form a committee. - In 00 draft, a list of blocks included in the bundle at the time it was created and issued by the source nodes. Elwyn has been asking for this for some time. Topic: Bundle Inventory Q: Ed Birrane: What about manifest of what must be in the bundle at destination. C: Marc Blanchet: This is a security feature. Q: Kevin Fall: Does it have to be in primary block or can the primary block have a bit saying the inventory exists somewhere else in the bundle? A: Scott Burleigh: Like the bit idea. Primary block should be nonvolatile. Q: Kevin Fall: Proposing a manifest that is immutable from source, and a block of some sort. C: Scott Burleigh: Yes, cannot be modified. At most, say “this is what should be in the block at time it arrives”. This is what source put in bundle when created. That can be immutable and protected end-to-end. C: Kevin Fall: To go down this path, you want something like a checksum. Enumeration of block type isn’t enough to see if information is added/removed. Q: Ed Birrane: Is this a checksum over all of the blocks. A: Scott Burleigh: Not a BIB because we need lots of them and BIB can be removed. C: Marc Blanchet: This capability should be in BPSEC. C: Scott Burleigh: Changing CRC in the primary block (or anything) is always possible unless protected by a BIB. Because BPSEC in extension blocks always exposes it to being deleted. C: Kapali I-Viswanathan: For this there is more value in a hash than a CRC. Primary block can have list of hash values as a manifest. If manifest is in an extension block, create a BIB for primary block and every other block inserted. Primary block can have a list of hash values of remaining blocks. The manifest will be in the primary block. C: Scott Burleigh: Extension blocks of a bundle are mutable. For example, current custodian which will change along the path. C: Kapali I-Viswanathan: Only value of this manifest in the primary block is to protect against deletion of blocks. If source doesn’t want certain blocks to be deleted, it has that capability. C: Ed Birrane: This still relies on a BIB to sign the primary block. C: Kapali I-Viswanathan: Or like how github works. Can be signed or unsigned. Unsigned can protect against accidental deletions. C: Ed Birrane: So, agreed to have a bit for a manifest in the primary block and push the actual contents to an extension block. C: Scott Burleigh: Like that approach a lot. Presentation: BPSEC, Ed Birrane -------------------------------------------------------------------------------- C: Kevin Fall: Considering a bundle originating in an enclave with a gateway at edge doing security processing, then through to other security gateway at a planet or something. Devices that are destination are impoverished nodes that don’t want to do all of this processing. Agreed that removing security destinations is more flexible. C: Kapali I-Viswanathan: BABs no longer part of the bundle processing agent, so we don’t need to signal end-to-end or link-by-link. For that simple reason, it is a good idea to remove concept of security destinations. C: Rick Taylor: Security destinations are not required because you can use BIBE to a security destination. So, meeting requirements of use case without requiring this information. C: Kevin Fall: On that particular point, you don’t have to do that. C: Rick Taylor: Agreed. Not a must, you can if you want, tunnel or something else. Other ways may be applicable. C: Scott Burleigh: We should not prescribe BIBE. Make people aware it is possible. C: Ed Birrane: Security practices could address that. Q: Kevin Fall: When moment comes, what are cases when BIBE is the best choice. A: Scott Burleigh: Don’t need to say that BIBE is the best choice under any particular circumstance. Let people figure that out themselves. Here are things you can do, don’t have to. C: Kevin Fall: Like to come up with reasons for one over the other and provide that as guidance.