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

Meeting Minutes Delay/Disruption Tolerant Networking (dtn) WG
Title Minutes for DTN at interim-2016-dtn-1
State Active
Other versions plain text
Last updated 2016-03-25

Meeting Minutes
minutes-interim-2016-dtn-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.