IETF DTN Working Group Minutes July 26th, 2019 IETF105, Montreal Chairs: Marc Blanchet & Rick Taylor ================================================================================ Administrativia -------------------------------------------------------------------------------- - Notewell noted. - Ed Birrane, Adam Wiethuechter, and Ron in 't Velt will take notes. - Reviewed status of WG documents: * 3 major items in the review pipeline (BpBis, BPSec, TCPCLv4) * BPBis and BPSec reviewed by AD. TCPCLv4 reviewed by next week. - Some new documents need to be moved to WG Last Call * Minimal TCP CL, BPSec Security Contexts, Bundle-in-Bundle Encapsulation Agenda Bashing -------------------------------------------------------------------------------- - No changes. YouTube link to proceedings: -------------------------------------------------------------------------------- https://www.youtube.com/watch?v=UqO7P72jOQQ ACTIONS -------------------------------------------------------------------------------- 0. Chairs to schedule interim meeting to discuss milestones, recharter, etc. 1. DTNWG to review all changes to BpBis on mailing list. 2. M. Wsterlund to provide normative reference for time. 3. S. Burleigh to post to mailing list discussion on max hop count limit. 4. M. Westerlund to review TCPCLv4 next week. 5. S. Burleigh to post request on SHOULD vs MUST on BPSec implementation and SHOULD vs MUST on BPSec usage. 6. S. Burleigh to bring IANA registries from RFC6255 into Bpbis document. 7. S. burleigh to discuss whether CRC is optional on the mailing list. Questions (Q), Answers (A), and Comments (C): Presentation 1: BpBis AD comments (Scott Burleigh) ------------------------------------------------------------------------------- Review of individual comments received for BpBis from AD review. === DTN URI Scheme === (Q) R. Taylor: DTN URI scheme useful to let external tooling (e.g., Safari) know it is using a DTN protocol stack. Less useful if this is just a way to distinguish endpoint names in a DTN only network. Is URI the right thing to do here? (A) S. Burleigh: Schemes need to be defined somewhere. No strong opinion on whether needs to be a registered URI scheme. We have IPN in the registry now and DTN defined in this draft. Maybe that is sufficient. (C) M.Blanchet: Two are registered and deployed. (Q) R. Taylor: Is this a public definition supported by external devices? (C) M. Westerlund: Good question. If you use formatted URI, you should keep the registration, even if used primarily by DTN. Large freedom for placing items in registry. (Q) R. Taylor: Agree to register DTN as a top level URI. Is IPN also a top-level URI or is it kept under the DTN scheme instead? (C) E. Kline: No harm in keeping DTN, it will not be recycled for something else. Don't know enough about IPN. (C) S. Burleigh: IPN exclusive to current implementation and deployments of DTN to identify endpoints. Running on space station. (Q) E. Kline: Do we need a mapping between them? (C) R. Taylor: Naming and addressing is a future charter item. If you had a single DTN scheme it would be dtn:free-text, such as dtn:ipn:... (C) S. Burleigh: People are deploying what we currently have specified. (C) M. Westerlund: You need to decide. There are instructions in the protocol. (C) R. Taylor: Retract my suggestion - the status quo will work for us. (Q) S. Burleigh: Does section 10.3 satisfy need to define DTN scheme? (A) M. Westerlund: yes. === Time Representation === (C) M. Westerlund: Inserted text is fine. No intention to override WG consensus. (C) S. Burleigh: Request for Normative Ref to use for time. === Lifetime === - no comments === Report-To EID === - no comments === Maximum Hop Count Upper Limit === (Q) S. Burleigh: This is out of scope. We can jam a number, but what number? (C) M. Blanchet: Hop count useful to detect routing loops. Setting a large number helpful: if you reach a large number, you are in a loop. (C) Ron in 't Velt: Sometimes a routing loop can be a good thing. (C) S. Burleigh: How about 255? (Q) R. Taylor: Can intermediate nodes replace the extension block? Is so, then a lower number makes sense. If this is immutable a larger number makes sense. (A) S. Burleigh: Extension blocks can be added, changed, or removed. (C) R. Taylor: Take to the mailing list. === Congestion From Status Report === (C) S. Burleigh: Added text that policy mst exist to reduce extra traffic. This requires management mechanism to defend against that. Cannot legislate that in this spec. (C) M. Westerlund: Ok. === Node Disavowal === - no comments === Incorrect section reference === - no comments === Definition of unintelligibile === - no comments === Service Description === (C) M. Westerlund: Comments for this may come back in review of CL documents. === Mandating BPSEC === (C) S. Burleigh: Agnostic on whether BPSec is required. (C) M. Blanchet: Important use case is space where DTN is both network protocol and layer down. Just as trying to force IPSec with IP failed, forcing BPSec in this case may also fail. Deploy security services higher in stack closer to application level. Also BPSec heavy duty and forcing all implementations may be too much. Strongly against requiring it in all implementations. (C) M. Westerlund: Understand argument - choices for particular deployments. Try recommending BPSec and make it clear this is a deployment consideration. This is up the stack anyway and not wasting store-forward resources is relevant. (C) S. Burleigh: Spaceflight increasingly needing security. End-to-end for BP will be good for that. Recognize processing overhead. Inclination is to say BPSEc strongly recommended not required. (C) R. Taylor: Say implementation is required but not required to use it. (Q) M. Blanchet: If I am a relay in space why do I need BPSec? (A) E. Birrane: Multiple ways to achieve security. BPSec only if you need block level security. If relay needs to do inspection to throw out bad data, then yes, relays need BPSec. Relays should filter. (C) E. Birrane: I vote for strongly recommend. (C) M. Westerlund: If this is required you need to say which context(s) are required. Think this should be recommended. (C) M. Blanchet: In IETF we woudl say SHOULD instead of MUST. (C) R. Taylor: We should hum on the issue. Those in favor of SHOULD: (many hums) Those in favor of MUST: (no hums) (Q) Ron in 't Velt: Does MUST mean must implement or must use? (A) R. Taylor: Consensus here is SHOULD implement. Take to the list. === Encryption on CL === - no comments === Reason code for bundle storms === - no comments === Guidance for Setting lifetime and Max Hops === (C) S. Burleigh: Still research topics. Ought to emerge from course of operations and deployment and research. Prefer to not say more. === IANA Considerations === (C) E. Kline: RFC7116: title is "LTP CBHE and BP IANA registries" (C) M. Westerlund: Bring registration rules for registries (including RFC6255) into the BPbis document. Thenobsolete RFC6255. === Registries === (C) R. Taylor: Developers look to registries for enumeration sizing, etc... If they might mix we should separate them. (C) S. Burleigh: We don't need new registires for BPv7 because it is a superset of BPv6. (Q) M. Westerlund: Can anyone extend BPv6 registries? (A) R. Taylor: Not in the IETF. Bpbis obsoletes RFC5050. If others take ownership they maintain their own. === CRC References === - no comments === Normative References === (Q) S. Burleigh: Can we treat information references as normative? (A) M. Westerlund: Need to check. It is possible to reference informative documents, but need to specify that during last calls. -- this is overcome by events, pull RFC6255 into BpBis and obsolete 6255 --- === Primary Block Immutability === - no comments === Optional CRCs === (C) S. Burleigh: CRCs optional. Don't need them if you have BIB. (C) M. Blanchet: Source may not use BPsec and not know that some downstream node will use BPSec. If you ar eunsure, you should use CRCs. (C) S. Burleigh: If source does use BIB, then it does not need CRC. (C) M. Westerlund: Might be easier to always use CRC. May be an unnecessary optimization to try and remove it. (C) E. Birrane: If we have a bundle with 100 blocks and each block carries a CRC the size and processing of each one is going to add up. Mandating CRC doesn't scale. (C) Ron in 't Velt: We must also consider when a bundle is corrupted at rest. (C) R. Taylor: CRC on the primary block is important - primary block is immutable. (C) M. Westerlund: No strong opinion. Might require CRC only for certain blocks. Use should be based on deployment. Implementation mandaotry and deployment optional. (C) S. Burleigh: Discuss on list. Recommend CRC mandatory on the primary block and optional for others. (C) M. Blanchet: Let's hum. MUST have CRC on primary block? Some hums. Don't need CRC: no hums. === Obsoleting RFC5050 === (C) M. Blanchet: Like IP there concurrently exist multiple versions of the protocols. When you say one obsoletes the other, it just signals that there is a new version, bot that you cannot use the older version. (C) S. Burleigh: Obsoleting has to do with RFC standards track and 5050 was experimental. (C) M. Westerlund: Since RFC5050 is IRTF need to consult on them, but probably fine. IESG is also working a new set of labels to be clearer. (C) E. Kline: Note that IPv6 does not obsolete IPv4 - they are not the same thing. If not obsoleted, move 5050 to historic draft document. (Q) M. Westerlund: What is the intention for BPv7? (A) S. Burleigh: Intention is for BPv7 to become the standard. (C) R. Taylor: Hearing consensus: BPv7 is lessons learned from BPv6. Presentation 2: BPSec AD comments (Ed Birrane) ------------------------------------------------------------------------------- BPsec : Ed - just got commetns two days ago - give some recommendations slide 1: - 11 comments - 6 minor changes - nothing changes really, just cleanup and clarification - will pause and move on slide 2: - security context description - create second doc - can site in section 1.2 slide 3: - term for security souce - no defintation for peer of such (security dst) - there was a concept - difficult - conflated routing and security - could tunnel - spec does not mandate - can give name, - will return to concept as whole sldie 4: - BIB over BCB? - if have blocks end-to-end in nature, cant use encrypted payload - if bundle has two security context - 1st for payload - 2nd for signature - create two security users - those who have keys - those who can check integrity slide 5: - concept of security context - provide additional service on blocks - blocks refencing eachother is not recommended - security could define additional results captured by bcb - no contraints as part of security context - check section 7 - larger issue is circular deps and ambaguity with those kind of blocks - happy to provide more calrify text and example magnus: - point to encapsulation? ed: - elegant way to do it - totally resaonable magnus: - foward refence to it - despirtre limitations rick: - analogy to ipsec - tunnel mode or transport mode slide 6: - uniquiness of security serivce in bundle - only target block and security service or aslo context itself? - multiexcruption - multikey/algo - rather than with multi bcb and have discussion over how it works - push into sec context - bcb -> sec context (1:1) slide 7: - use of reserved bits flag on sec ctx - done for backwards compatability - no issue with reordering bits slide 8: - AEAD cipher req? - bpsec 06 for review, strongest comment was (from sec area) mandate for AEAD - bibs are plaintext - bcb are ciphertext - should be gen sig slide 9: - policy guideline for removed blocks along way - can happen - we did consider it sldie 10: - security src or bundle src - manifest blocks - they must exist in bundle - can be signed - destination check for it and if missing questionable - many other ways to handle - 8.2.2 discusses this - must be a bib that signs primary block - if not, not within policy (from out of band) - not appropiate to define in bpsec doc slide 11: - clarify moving sigs sldie 12: - what does this mean? - existing cipher suite ids, why make our own? - would that cause confusion? - came to understand enumarting sec ctx no cipher suites - strike all text as it does not apply slide 13: - how sec dst determined? - its unclear who should process secuiryt block - if bundle has been at rest long time, things have changed - waypoints for sec processinf - boundries between sec and dst are dynamic - policy can determine if you should be evaluation security service - policy to add sec service and policy to use - encap with bundle to bundle slide 14: - registry for iana for context ids - will add Presentation 3: Asynchronous Management Protocol (Andrew Haberman) ------------------------------------------------------------------------------- Andrew went through AMP-07 updates and converter utilities. === AMP-07 CBOR Encoding Updates === (Q) R. Taylor: You have removed implicite structure not using CBOR encoding, to remove TLVs. So, present entire command as an OCTET string. Does this mean you are adding whitespace sensitivity to these? Or preparsing into a canonical form? (A) A. Haberman: Removed array headers for some (not all) structures. Do some preparsing. (Q) R. Taylor: So, unpack, concat, and then encode? (A) A. Haberman: Yes. (Q) R. Taylor: As DTN Chair: AMA/ADM/AMP work has been shopped to find a home in OPs area (netmod, anima, etc...). That area not interested but this is because mostly relevant to DTNs. The work is far down the line and would like to see it taken on in DTN. Will that cause a problem at the AD level since DTN is in transport area? (A) M. Westerlund: Will require a recharter, so discussion will happen at next meeting. We should discuss offline. (C) M. Blanchet: Spent 2 years shopping for a place. Concern is that the new OPs ADs will cause reboot to shopping this. It has been shown in the WG that people are working on this. When any network management work goes into last call we can do a cross-area review with OPs. Presentation 4: Future Work Items (Scott Burleigh) ------------------------------------------------------------------------------- === BIBE === (C) S. Burleigh: Urgently needed for 2 reasons: First, custody transfer taken out of BPv7 and need to reatin feature and BIBE does that. Second, BPSec removed security destinations and BIBE is one way to get security-destination-like behvior. Can also prevent traffic analysis to obscure primary block. Also useful for source-path routing. Initial draft posted in January that has no major issues. Needs review. (C) M. Blanchet: Agreed to add BIBE. === Quality of Service === (C) S. Burleigh: QoS taken out of BPv7. Customers want it. Customers using it in implementation. === Key Management === (C) S. Burleigh: Draft exists and should be discussed in WG. === Network Management === (C) S. Burleigh: important to manage these networks. (C) M. Blanchet: Also convergence layers (LTP? SMTP?), addressing, naming, routing, neighbor discovery, NM, key management, quality of service. (C) M. Westerlund: No issues. Submit new milestones were needed.