Minutes IETF108: dtn
minutes-108-dtn-00

IETF DTN Working Group Minutes
July 27th, 2020
IETF108, Virtual
Chairs: Marc Blanchet & Rick Taylor
================================================================================

Administrativia
--------------------------------------------------------------------------------
- Notewell noted.


Agenda Bashing
--------------------------------------------------------------------------------
- No changes.


YouTube link to proceedings:
--------------------------------------------------------------------------------
https://www.youtube.com/watch?v=Wg7lSRtgOlc



ACTIONS
--------------------------------------------------------------------------------

0. Chairs to ask mailing list what to do with MTCP-CL.
1. S. Burleigh will update BPbis and post individual items to list as questions.
2. E. Birrane to post new version of BPSec and post individual items to the
  list as questions.
3. B. Sipos to post any TCPCLv4 questions to the mailing list.
4. E. Birrane to post an updated "default" security context to the list.




Questions (Q), Answers (A), and Comments (C):


Presentation 1: BPbis Changes Overview (Scott Burleigh)
-------------------------------------------------------------------------------
- Scott walked through remaining DISCUSS/COMMENTS for BPbis.

1. Alvaro's Discuss (registry status with IRTF)
==========
(C) R. Taylor: Consensus is item #2. The IRTF AD-equivalent happy to yield
               control of IANA registration to "spec required". Take to list
               and say point 2 is where we were with consensus.

2. Alexy's Discuss (is TCPCLv4 mandatory to implement?)
==========
(C) R. Tayloy/Chair: TCPCLv4 is canonical example and preferred interop for
                     testing, not mandatory to implement.

(C) S. Burleigh: Added because BP has no congestion control - if BP is not
                 used on the Internet, requiring TCPCLv4 seems Draconian.

(Q) S. Card: I run BP over one-way links. How would we implement this?

(A) S. Burleigh: Agreed. TCP is not the only convergence layer.

(C) B. Sipos: We can handle the same was as TLS in TCPCLv4: if you can support
              it, then it is mandatory.

(C) S. Burleigh: I will draft text and post to list.


3. Mirja's Discuss (Status report storms)
==========
Do we implement mechanism to smoothly enable a node to discard a bundle that
seems to be possible damaging. So to override bundle lifetime so bundle expires.

(Q) R. Taylor: What is being proposed is text to state "for administrative or
               operational reasons, a BPA may ignore the bundle lifetime and
               just throw it away"?

(A) S. Burleigh: Revise/shorten lifetime and process with normal lifetime
                 expiration processing. Do not change the primary block of the
                 bundle.

(Q) E. Birrane: Do we need a new reason code?
(A) S. Burleigh: We would use the existing "lifetime expired" or
                 "contraindicated" reason codes.

(C) R. Taylor: Disagree - If a bundle is valid for 100 years but after 26
               seconds an internal BPA threw it away for other reasons, that is
               a different reason code.

(C) S. Burleigh: In that case another existing reason code should be used
                 instead of "lifetime expired".


4. Benjamin Discuss: BPSec extensions (When/where is BPSec MTI)
==========

(C) R. Taylor/Chair: No record of consensus - should ask the list. Also,
                     end-to-end key exchange is not "DTN". Happy to put on the
                     TODO list for later.

(C) S. Burleigh: Delay-tolerant key exchange is proposed for the
                 rechartering discussion.

(C) M. Westerlund: To be an RFC in IETF automated key exchange is required. The
                   Security AD will not stick to that requirement for this
                   case on the expectation that the DTNWG will eventually
                   provide this in the future.

5. Benjamin's Discuss: (How do you know an endpoint is a singleton?)
==========

(C) R. Taylor: We should not block BPbis on details of the addressing scheme.
               We have the abstract interface that a naming scheme needs to
               have. It seems a URI scheme for DTN must have some way of
               indicating if an EID if unique or not. For example, in the IPN
               scheme you know :0 is the node ID.

(C) S. Burleigh: I can propose a mechanism for this and put in the next draft.

(C) R. Taylor: When done, please raise the question on the list.

6. Benjamin discuss (Allocation in scheme codes)
==========

(C) R. Taylor: Make a number higher than 255. CBOR gives you a practically
               infinite number space. If there is a vast amount of private use
               you get a propagation of private-use URI scheme codes that
               major manufacturers use as unofficial standards. If you force
               private values to be >= 3 byte encoding it nudges people to the
               IETF for standardization.

7. Comment: Should lifetime and age both be in microseconds?
==========

(C) A. Wiethuechter: Prefer seconds - DTNs are delayed.
(C) B. Sipos: Agree with seconds. Finer details can come from extension blocks.
(C) R. in `t Velt: HMilliseconds might be a middle-ground.
(C) R. Taylor: This should be a list discussion

8. Comment: Are extension blocks mandatory to implement? (not stated that now)
==========

(C) R. Taylor: "Extension" implies optional - otherwise it would be in the
               primary block.

(C) S. Burleigh: But primary block is immutable - other extension blocks are
                 mutable.

(Q) M. Westerlund: Does the protocol work without these extension blocks?

(A) S. Burleigh: Generally yes - you might need the Previous Node extension
                 block.

(C) M. Westerlund: You may need hop count for routing loops. I don't think we
                   can safely deploy without these blocks. The DTNWG should
                   assess.




Presentation 2: BPSec Changes Overview (Ed Birrane)
-------------------------------------------------------------------------------
Ed walked through remaining DISCUSS/COMMENTS for BPSec.

1. Is there a security context that is mandatory to implement?
==========

Discussion was that a default operational security context be provided.


2. Can we standardize BPSec without a key exchange protocol?
==========

(C) R. Taylor: Agreed.


3. Do we allow nested signatures?
==========

No comments.


4. Do we allow operations over multiple blocks?
==========

No comments.


5. Do we need security-related Bundle Protocol Reason Codes?
==========

(C) S. Burleigh: Advocate these new reason codes not be in the BPBis main
                 specification. Preference it to add them in the documentation
                 of the security contexts that cause the reason codes to be
                 raised.

(C) S. Card: Consider a reason code for "security prohibited by local policy".

(C) R. Taylor: Generic security-related reason codes that apply regardless of
               context should be put in BPSec.

6. Should BPSec use CBOR Map instead of CBOR Array for parameter encoding?
==========

(C) R. Taylor: Map matches the logical structure of "key/value".

(C) S. Burleigh: There is a benefit to supporting the fewest possible CBOR
                 structures for constrained implementations.

(C) B. Sipos: We may want to keep as an array to avoid potential issues with
              canonicalization.


7. Does BPSec force operations cover non-block-type-specific data?
==========

(C) R. Taylor: Recommend this be an update to text in the BPSec security
               considerations area.


8. Should BPSec reserve some common parm/result values?
==========

Take to the list.




Presentation 3: TCPCLv4 Changes Overview (Brian Sipos)
-------------------------------------------------------------------------------

(C) R. Taylor: Take the final page of items to the list. TCPCLv4 has come
               along nicely.


Presentation 4: Security Template (Ed Birrane)
-------------------------------------------------------------------------------

Ed presented the current interoperability security contexts.

(C) R. Taylor: Selected Integrity and Confidentiality algorithms are reasonable.

(C) B. Sipos: These are fine for testing, but should not be used in an
              operational manner.

(C) R. Taylor: The point of the interop security context is to be operationally
               usable. Not only for testing.

(C) M. Westerlund: This security context should be expected to work and be
                   deployed.

(C) E. Birrane: We can call it a default security context and update it.


Ed presented a draft security context template


Presentation 5: COSE Security Context (Brian Sipos)
-------------------------------------------------------------------------------

COSE security context proposed as a standard way to do security in a
constrained environment.

(Q) E. Birrane: Should this be the new default security context?

(A) R. Taylor: Take to the mailing list.




Wrap-Up (Rick Taylor)
-------------------------------------------------------------------------------

(Q) R. Taylor: Should we have longer sessions?

General consensus that meetings should be longer, and/or over multiple days.

(C) R. Taylor: IETF-109 may also be virtual. Will ask for longer slot. More work
               coming in the recharter.

(C) R. in `t Velt: Neighbor discovery should be in the re-charter.

(C) R. Taylor/Chair: Ron is the chair of MANET WG and looking for more
                     participation.