Minutes IETF103: dtn
minutes-103-dtn-00

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:  <no hums>
Minimal TCPC as the only TCPCL: <no hums>
Both: <lots of hums>



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.