* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Dtn Status Pages

Delay/Disruption Tolerant Networking (Active WG)
Tsv Area: Mirja Kühlewind, Spencer Dawkins | 2014-Nov-07 —  

IETF-103 dtn minutes

Session 2018-11-08 0900-1100: Boromphimarn 3 - Audio stream - dtn chatroom


minutes-103-dtn-00 minute

          IETF DTN Working Group Minutes
          November 8th, 2018
          IETF103, Bangkok
          Chairs: Marc Blanchet & Rick Taylor
          - Ed Birrane will take notes with help.
          - Notewell noted.
          - Review of milestones: Bpbis, TCPCLv4, BPSec.
          Agenda Bashing
          - No changes.
          YouTube link to proceedings:
          1. Request to WG to adopt Minimal TCPCL.
          2. Ed to update BPSec to change cipher suite ID to security context
             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
                    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
                              environments. Saying that in shepherd write-up or
                              in spec.
                              Also, having 2 CLs will help show you have the
                              correct CL
          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
          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
                    Presenting Brian’s work on the document. This requires
                    he presents
                    Brian’s disposition to his own critiques so he will provide
                    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
                          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
                    implementations are suitable to mature and operate.
          C: Jorg Ott: Need to differentiate the two: different ports, or magic
                       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
          C: Spencer Dawkins: Applicability statements make some people bristle. Use
                              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:
          Presentation 5: Lucien Loiseau: RightMesh implementation of Terrestrial
          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
                             And would not supersede what we do with EIDs in other
          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
                              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
                         in IPSec.
          C: Luciene Loiseau: Separating out security parameters means that
                              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.

Generated from PyHt script /wg/dtn/minutes.pyht Latest update: 24 Oct 2012 16:51 GMT -