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.