Minutes IETF98: dtn
minutes-98-dtn-01

Meeting Minutes Delay/Disruption Tolerant Networking (dtn) WG
Title Minutes IETF98: dtn
State Active
Other versions plain text
Last updated 2017-03-30

Meeting Minutes
minutes-98-dtn

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.