IETF DTN Working Group Minutes November 8th, 2018 IETF103, Bangkok Chairs: Marc Blanchet & Rick Taylor ================================================================================ Administrativia -------------------------------------------------------------------------------- - Ed Birrane will take notes with help. - Notewell noted. - Review of milestones: Bpbis, TCPCLv4, BPSec. Agenda Bashing -------------------------------------------------------------------------------- - No changes. YouTube link to proceedings: -------------------------------------------------------------------------------- Https://www.youtube.com/watch?v=_zowxNBLRQ8 SUMMARY/ACTIONS -------------------------------------------------------------------------------- 1. Request to WG to adopt Minimal TCPCL. 2. Ed to update BPSec to change cipher suite ID to security context ID/Parms and roll back concept of security associations. 3. Jorge to make new pass at TCPCLv4 document. 4. Luciene to draft CLA-EID document. Questions (Q), Answers (A), and Comments (C): Presentation 1: Nicholas Kuhn -------------------------------------------------------------------------------- OVERVIEW: Reviewing routing research in satellite systems. Documents being published and requesting review. Presentation 2: Scott Burleigh: Simple TCP CL -------------------------------------------------------------------------------- OVERVIEW: Brief discussion of the simplified TCP CL posted a few months ago. It Is much less capable than TCPCL - 7 pages of spec with boilerplate. It functions as follows: (1) Open connection. Send bundles each preceded by length. (2) When connection breaks stop and re-establish. (3) Implementation operational for years. Used on Space Station. C: Jorg Ott: This is too simple without TLS. Might not get standardized without TLS. C: Scott Burleigh: TLS is important and spec says it can be done, but out of scope because people know how to do this. C: Spencer Dawkins: Truth telling is enough here. We want to put this out, it has heavy use in real-world environments where it is hard To repair the “other end”. Know it doesn’t do TLS and know This isn’t OK except in the most restricted and monitored environments. Saying that in shepherd write-up or in spec. Also, having 2 CLs will help show you have the correct CL semantics. C: Rick Taylor: This simple TCP does not need TLS. Bundles have their own security profiles. C: Spencer Dawkins: Nuance that needs to be part of conversation: I know where Sats are, and if I mis-point, that’s on me. It would be Great to ship something with TLS, if possible without Slowing things down. C: Marc Blanchet: DTN is not only for space; seeing adoption terrestrially. C: Spencer Dawkins: Put an applicability statement in the draft. C: Stephen Farrell: This is a TCP CL and only used where TCP makes sense, which are places you need crypto. If it is simpler it will be used more and will then need TLS. C: Scott Burleigh: Draft says parameters established by management and may include TLS. Can add language on how to do TCP and TLS. C: Stephen Farrell: Must be clear how to do this over TLS, not a normal TCP socket. Especially with TLS 1.3. There are things to say. It is not much and easy to do. If successful, cannot be a weak transport protocol. Q: Jorg Ott: Not good precedent for calling something “simple” in the title. Can we change this? A: Scott Burleigh: Yes. Q: Ed Birrane: Is this an interoperability/testing convergence layer? A: Scott Burleigh: No. It is a simple CL but used operationally. Prefer saying there are environments where this is the wrong thing to use, but this draft is not academic. Q: Stan Ratliff: What would this be adopted as? Experimental? Standards track? Informational? If this is informational, works well to tell story document is working and used for good but may not be used industrially. A: Scott Burleigh: Adding TLS language is easy because TLS is easy. C: Spencer Dawkins: Don’t get hung up on which kind of document; the IESG Has control over that. Saying this is how you do TLS And a more complete TCP/CL is coming later is a nice addition to the conversation. Q: Marc Blanchet: Should we merge these into the same document? A: Rick Taylor: Probably not because TCPCLv4 is a protocol over TCP. Presentation 3: Jorge Ott: TCPCLv4 Version 10 -------------------------------------------------------------------------------- OVERVIEW: Jorg an author on TCPCLv3. Providing some review over TCPCLv4 and Presenting Brian’s work on the document. This requires he presents Brian’s disposition to his own critiques so he will provide his thoughts on those in real time. - Do we allocate too many bits to account for extension points? C: Rick Taylor: Two open source implementations advertise neighbor discovery but neighbor discovery is undocumented. That is an example of a future extension to this CL. C: Jorg Ott: There have been many discussions about this topic over the years but don’t see how this would require so much space in an Extension ID. Q: Rick Taylor: Extensibility mechanism is good; do we really care about the Few extra bits given this is TCP and therefore used where TCP makes sense and can be omitted when not needed? A: Jorg Ott: That’s ok if you can remove them if there is no extension present. Do not feel strongly about it in this case. Q: Marc Blanchet: Any other comments on this from WG? (No additional comments from WG) - Can we combine the two parts of the XFER_NIT? (No additional comments from WG) - Can we return to the original, simple semantics of SESS_TERM? Just close Session and make SESS_TERM last thing transmitted. C: Rick Taylor: This may be used in multi-threaded TCP which may require these additional semantics. C: Jorg Ott: In that case you need to synchronize write access. C: Ed Birrane: Spec would need to defend the more complex semantics and If not, the simpler semantics should be used. - Do we care that the spec defines term it never uses? (No additional comments from WG) C: Jorg Ott: We can do a version 11 at some point. C: Marc Blanchet: The co-authors of TCPCLv4 should converse and answer some of these questions. Can we get something in the Next few weeks? C: Jorg Ott: Ok. Presentation 4: Working Group Discussion on TCPCL standards -------------------------------------------------------------------------------- OVERVIEW: TCPCLv4 took a long time to get to this point, partly because complexity more than anticipated. BPbis + BpSec + CL must go forward together to IESG and we have 2 out of 3. There is urgency to have a CL to demonstrate interop and for those to test that their laboratory implementations are suitable to mature and operate. C: Jorg Ott: Need to differentiate the two: different ports, or magic cookies. If they co-exist, how do they work? TCPCLv4 is almost done. C: Spencer Dawkins: It is helpful to re-use ports for IANA. Helpful to have two CLs. Also maybe call this “minimal TCP” and not simple. C: Rick Taylor: Not proposing Minimal TCP and TCPCLv4 run on same port. Too much complexity. We can add use cases to help implementers pick. C: Spencer Dawkins: Applicability statements make some people bristle. Use cases are considered worse. Just say “this is where this applies”. C: Stephen Farrell: TCPCLv4 is within weeks of being done. The chances of a new -00 draft getting ahead of it is unlikely. There are Functional differences between them: minimal TCP is uni- directional, for example. Suggest finish TCPCL before moving to minimal TCP. If someone has implemented Minimal TCPCL and it’s working, that’s fine. C: Jorg Ott: If minimal TCPCL is uni-directional and the one who connects also sends, this isn’t applicable to terrestrial versions of DTN because of NATs and firewalls, etc. C: Stephen Farrell: Scenarios where you want is outbound: send packets and stop. Lots of sensor stuff, whereas actuators are more complex and need inbound connections, too. Q: Marc Blanchet: Would like to poll the room: TCPCLv4 as the only TCPCL: Minimal TCPC as the only TCPCL: Both: Presentation 5: Lucien Loiseau: RightMesh implementation of Terrestrial DTN. -------------------------------------------------------------------------------- OVERVIEW: RightMesh has done an implementation of BPBis with some routing And security. In doing so, they ran into some implementation Recommendations and lessons learned which were presented. - Discussion of the CLA-EID concept of binding a CLA channel to an EID. Q: Rick Taylor: Does this break late binding concepts? A: Luciene Loiseau: No; this is a 1 hop id. C: Scott Burleigh: This seems like a useful optimization for some environments And would not supersede what we do with EIDs in other environments. Q: Stephen Farrell: What do you do with an IPv6 address? A: Luciene Loiseau: We would find a way to encode it. C: Rick Taylor: Agreed. A CL service can hand out names it knows how to parse. C: Scott Burleigh: Best if not required to be a singleton EID. We have use cases where we send from node A to node B and multiple CL paths handle that. ION has something called a CL manager that figures out which CL paths to use. C: Luciene Loiseau: Did not mean to say a singleton EID, just something unique per channel. -- Discussion of routing logic priority Scott Burleigh: Encourage thinking of routing concepts, but they do not belong in the BP document itself. — BPSec implementation C: Ed Birrane: Hold comments on security associations until the BPSec presentation next. Presentation 6: Ed Birrane: BPSec Updates -------------------------------------------------------------------------------- OVERVIEW: Ed presented conceptual draft of adding security associations to BPSec and asked working group for input. C: Rick Taylor: There is no semantic difference between a cipher suite ID and a security association ID. C: Ed Birrane: Agreed and security association already has established meaning in IPSec. C: Luciene Loiseau: Separating out security parameters means that intervening nodes can’t verify the integrity of the bundle. C: Stephen Farrell: You can’t separate the parameters from the blocks, and even if you did you would need lots of lots of security association blocks in the bundle.