Minutes for DTN at interim-2016-dtn-1
minutes-interim-2016-dtn-1-1

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.