IETF DTN Working Group Minutes March 29th, 2017 IETF98, Chicago, USA ================================================================================ Administrativia -------------------------------------------------------------------------------- - Ed Birrane to take notes. - Stephen Farrell will be the Jabber scribe. - Notewell noted. - Chairs requested more review of BPbis and TCPCLv4 specifications. Agenda Bashing -------------------------------------------------------------------------------- - No changes. Summary -------------------------------------------------------------------------------- - BPbis drops out of last call and should enter again at next IETF. - Confirm on WG list removing custody transfer from BPbis and into separate WG document and having BPbis normatively reference that document. If done this way, Keith Scott will author the custody transfer document. - Remove content range as option from BPSec, fix primary block canonicalization, and potentially re-use COSI language for ciphersuite parameters and results. - Write interoperability cipher suite document for BIBs and BCBs. - Start list discussion on whether TCPCLv4 should mandate TLS. - Establish new registries for TCPCLv4 versus TCPCLv3. - TCPCLv4 drops out of last call and should enter again at next IETF. - Spencer to ask OPS AD for preliminary review of AMA document. Questions (Q), Answers (A), and Comments (C): Presentation 1 : BPBis (Scott Burleigh) -------------------------------------------------------------------------------- TOPIC: BPbis changes -------------------- Summarized changes to the specification over course of last call. Q: Marc Blanchet (As Chair): Text for custody transfer may need more work. A proposal was made to remove custody transfer from BPbis and handle as separate document. Does the WG agree with this approach? C: Rick Taylor (As Chair): This means making custody transfer a new WG document and worked as a primary charter item. C: Stephen Farrell: Agree. Also, leave the custody request flag in the current document so you can assign it. C: Jorge Ott: Agree. C: Keith Scott: Strongly opposed. C: Ran Atkinson: What problem is solved by doing this? C: Stephen Farrell: Corner cases involving custody transfer and fragmentation. If you get custody reports with fragmentation, current text unclear on what to do. May be impossible to fix. Custody transfer is useful but not everywhere, so move to separate document. C: Rick Taylor: Doing this keeps BPbis smaller and tighter and helps get through last call. Decouple the problem without losing custody transfer as a capability. C: Fred Templin: Agreed. IETF generally trending to smaller, modular documents. C: Keith Scott: Then nodes can implement BPbis without custody transfer. C: Jorge Ott: People may not choose to accept custody anyway. C: Scott Burleigh: The document says no node is required to take custody. In that sense it is optional. C: Spencer Dawkins: Anyone who sends modular documents up makes me a happy AD. Q: Rick Taylor: Any technical argument against this? A: Keith Scott: All it takes is 1 node in the path to not implement custody transfer to hamper source retransmit. Q: Brian Sipos: Is the intent to write custody transfer after Bpbis is approved or to work them concurrently? A: Scott Burleigh: Together, if possible, but do not hold up BPbis. A: Rick Taylor: Intent is to make custody transfer a normative reference in BPbis, push them through at the same time. Let them meet in the editor's queue. Happy for WG to say do this in a different way. C: Ron in 't Velt: Separate document for custody transfer is fine with me. I have not understood how to do custody transfer in a multi-routing capacity. C: Stephen Farrell: If a forwarding node fragments without taking custody, there is never a custody transfer signal back on the original bundle and it would be re-transmitted from the sender. There exist weird cases that should be addressed in the custody transfer spec. C: Rick Taylor: We will post on the list to give everyone a chance to chime in. Would like a prompt decision on this so Scott Burleigh and the editorial team can work on the document. Scott will work to produce a rought draft of custody transfer from the BPbis base document. Would like assistance for someone to act as main editor of the draft. C: Scott Burleigh: Agreed. Would like to get working on QoS draft. C: Keith Scott: I am willing to be the editor of the custody transfer document. TOPIC: CBOR performance -------------------- CBOR version of BPbis for uPCN (for cortex microcontrollers) written by Marius Feldmann. Performance numbers captured and presented. C: Rick Taylor: Would like to see Carston's comments on these numbers. C: Scott Burleigh: This was their own implementation, not ION. C: Stephen Farrell: Surprised to see such a big performance difference. C: Scott Burleigh: This is just in parsing, not overall bundle processing. You can characterize this as a significant slowdown in a tiny part of the code. C: Rick Taylor: CBOR is also about adding flexibility, not just performance. C: Scott Burleigh: Agreed. And more aligned with how IETF works. C: Rick Taylor: Somewhat suspect of statistics given differences shown for TinyCBOR and libcbor. Q: Fred Templin: Are there performance implications for small devices. A: Scott Burleigh: This is informational. Don't suggest altering BPbis. May be a heads up on implementation - if bundles are very small and parsing time is a significant fraction of overall time, this may explain it. C: Rick Taylor: I wrote my own CBOR parser - the open standards are geared mostly towards web uses. Likely able to write more efficient CBOR parsers. TOPIC: Discussion on BPSec and BPBis -------------------- Q: Marc Blanchet: Should we review BPbis with or without BPSec? Stephen feels pushing forward without BPSec would fail IESG review. A: Ran Atkinson: They need to go together. If not, I will personally object and am sure the security ADs will support that objection. A: Stephen Farrell: I agree. Just need BPSec to be a normative reference in BPbis. If one is delayed, they meet in editor queue. Q: Rick Taylor: Reasking the question: Does BPSec have to be a normative reference for BPbis? A: Scott Burleigh: Fine with that. A: Spencer Dawkins: Agree that normative reference likely sufficient for IESG review. I expect them to go forward together to avoid questions about referring to a not-done document that will slow the process. Presentation 2 : BPSec (Ed Birrane) -------------------------------------------------------------------------------- Overview and walk through of the specification. Outcomes: C: Stephen Farrell: Remove the content-range and always pass the entire block contents to the ciphersuite. C: Ed Birrane: Sure. Individual cipher suites could choose to operate on less then the entire block contents if they wish. C: Ran Atkinson: You must provide an interoperability cipher suite. This can be in a separate document and need not be a suite-b set of cipher suites. C: Ed Birrane: Yes. Stating one interoperability cipher suite for BIB and one interoperability cipher suite for BCB in a separate document is a useful and easy thing to do. C: Stephen Farrell: There has been COSI work to figure out the CBOR encoding of cipher suite parameters. Look through that document and re-use what you can from there rather than specifying parameter/result fields and encodings in BPSec. C: Ed Birrane: Yes. No need to re-invent the wheel here. C: Scott Burleigh: The primary block is immutable now and therefore the primary block canonicalization should not mask any flags. C: Ed Birrane: Agreed. Presentation 3 : TCPCLv4 (Brian Sipos) -------------------------------------------------------------------------------- Review of TCPCLv4 form slide deck. TOPIC: Should TLS be mandatory? -------------------- Q: Stephen Farrell: Does this mean only using this CL when running TLS? A: Brian Sipos: Yes. There is a connection upgrade procedure that is optional. Current draft is that if both sides can do TLS, you use TLS. If TLS would become mandatory, we would just drop the negotiation and after initial handshake/magic string there would be the start of a TLS section unconditionally. C: Stephen Farrell: I support that and think it is a good idea. Q: Stephen Farrell: Are we looking at Diffie-Hellman or pre-authenticated nodes? A: Brian Sipos: The spec calls out TLS 1.2 and believe it calls out 1 of the BCPs that define a minimum mandatory cipher suite. Beyond that, TLS suite has no other guidance. C: Stephen Farrell: You could allow anonymous Diffie-Hellman cipher suites and have less configuration. Or have server-authenticated one. For this protocol you could go with mutual authentication. Not sure server-authentication is useful in DTN. Support for anonymous cipher suites are not great in implementations. Mutual-authentication is quite doable if the number of nodes is smaller for DTN, not for the web. C: Rick Taylor: I can see updates to the use of TCPCL to say "start with mutual authentication and then someone may say to use ephemeral keying or anonymous Diffie-Hellman. C: Stephen Farrell: If there is no need for plaintext on the wire, don't need to. C: Brian Sipos: Leave this up to policy on the endpoints. C: Ran Atkinson: I sent a note to the list before the meeting started. Reference that for more detail on these comments. The IETF distinguishes between mandatory-to-implement and mandatory-to-use-operationally. Security should always be mandatory-to-implement. It is optional whether the user actually uses it based on their local circumstances. Should be able to use TLS for some sessions and not others. C: Brian Sipos: That is how the TCPCL as-written-today operates. There is a negotiation at start in plaintext. If either side says it does not support TLS the entire CL connection can be non-TLS. C: Stephen Farrell: A counter-example is WebRTC where TLS is not optional. How you key is a different issue. Think that approach would be OK here too. C: Rick Taylor: We could say TCPCLv4 mandates TLS and if you can't speak TLS use TCPCLv3. C: Ran Atkinson: You prevent interoperability where local policy might suggest some sessions need security and some do not. That outcome leads to non-interoperability and hosts must implement both and switch between them based on endpoints. C: Stephen Farrell: Practically, TLS is how you get interoperability. Added benefit: middle boxes can't screw up your stuff. Q: Rick Taylor: Where do people see TCPCL being used? On the internet or just at things like ground stations? A: Ran Atkinson: I may have the bundle implementation and TCPCL inside a small device that at different times is connected in different ways. Sometimes public Internet, sometimes not. In some cases, at least, bundle will be used over bandwidth constrained, lossy networks. It might be that one would have a deployment where sessions might use BPSec to protect data end-to-end at which point the TCPCL encryption underneath doesn’t add any value. It would force me to have 2 TCPCL implementations inside my raspberry pi with resource constraints. C: Brian Sipos: Even if handshake were started, nothing is preventing the use of a NULL ciphersuite. C: Stephen Farrell: Pis and other constrained devices are getting quite powerful. Still vote TCPCLv4 require TLS. C: Brian Sipos: Making TLS mandatory necessitates that endpoints have a TLS implementation. That seems to be the hurdle. C: Stan Ratliff: We had MANET deployments across Internet and a second deployment in a network with tightly-controlled physical access characteristics where TLS was optional. Consider deployment model when determining if TLS is mandatory. C: Stephen Farrell: NULL ciphersuites are a bad idea and I vote against them. Follow BCP 195. C: Stephen Farrell: TLS 1.3 has many improvements. Recommend saying to use TLS and follow BCP 195, and consider using the latest. C: Rick Taylor: Let's move discussion to list. Not clear we have consensus. TOPIC: Should TCPCLv4 use the same registries as TCPCLv3? -------------------- Q: Rick Taylor: If we re-use TCPCLv3 registry space and add code to it, does that imply those codes are valid for TCPCLv3? A: Ran Atkinson: Have an internet draft that says “these additional codes apply to v4” then as RFC say supercedes v3 draft. That scenario happens often. No issue with using same registry. Q: Rick Taylor: What if v3 lives as the v4 alternative and we have v3 and v4 live at same time in the registry. A: Ran Atkinson: Unlikely, but if so, spin v3 draft to ignore unrecognized code and that additional codes only apply to later versions. C: Rick Taylor: Finish on the list. Q: Jorge Ott: Will we need different port numbers for v3 and v4, especially if we run TLS all the time? Q: Rick Taylor: Is this a new protocol or an upgrade? C: Jorge Ott: If you require TLS, first item is a TLS record. A: Brian Sipos: Even in pure TLS, still have magic string at start in plaintext to capture version. C: Rick Taylor: Various looks in room say that is not going to wash. C: Brian Sipos: Sequencing and concepts are the same between v3 and v4. The payload is different. Header distinguishes v3 and v4. C: Spencer Dawkins: Strings in IANA registries are cheap. If these are vaguely similar, but known different and behavior is different, ask WG to do a different registry to not confuse people. If concepts are really close and we are just adding, then re-using is fine. C: Brian Sipos: No issue with new registry. Reasonable and avoids whole problem. If there happen to be alignment, that is a convenience. TOPIC: CL Protocol Extensibility -------------------- C: Ran Atkinson: I do not have an immediate use case that requires extensibility. Across the range of IETF protocols often someone identifies a new use case for a protocol. In that event, it can be useful to have Type-Length-Value (TLV) extensibility at that future time. C: Brian Sipos: Discussed with Rick ability to discover EIDs based on established contacts. Example of an extension use case, but not recommend writing it up now. TOPIC: Neighbor Discovery -------------------- C: Brian Sipos: Do not think there should be neighbor discovery at the CL. Not sure what is being discovered and from where. Possibly multiple EIDs. C: Rick Taylor: This was my suggestion and a reason for TLV extensibility in the protocol. C: Brian Sipos: The TLV header should have fixed-bit lengths. Type codes can have range for IANA approved and range for experimental. TOPIC: TCPCLv4 STATUS -------------------- C: Rick Taylor (As Chair): Can not put this forward without more review. It is in WG last call and still very much in last call if not bounced out. C: Brian Sipos: As of the last draft, the sequencing is greatly simplified. The only complex sequencing exists in v4 today has to do with the startTLS and whether you share ids outside of TLS. C: Rick Taylor (As Chair): TCPCL drops out of last call because we have review comments. Get it back in last call for Prague. If not ready by then, we aren’t doing our job as a WG. Presentation 4 : AMA (Ed Birrane) -------------------------------------------------------------------------------- Overview of AMA. C: Spencer Dawkins: I will take this to OPS ADs for preliminary review and comment.