Minutes IETF102: dtn
minutes-102-dtn-00

Meeting Minutes Delay/Disruption Tolerant Networking (dtn) WG
Title Minutes IETF102: dtn
State Active
Other versions plain text
Last updated 2018-07-21

Meeting Minutes
minutes-102-dtn

IETF DTN Working Group Minutes
July 19th, 2018
IETF102, Montreal
Chairs: Marc Blanchet & Rick Taylor
================================================================================

Administrativia
--------------------------------------------------------------------------------
- Ed Birrane and Victoria Pritchard will take notes.
- Rick Taylor will watch Jabber.
- Notewell noted.


Agenda Bashing
--------------------------------------------------------------------------------
- No changes.


SUMMARY/ACTIONS
--------------------------------------------------------------------------------
1. Comments need to be collected for TCPCLv4 over next 2 weeks. In particular
   Brian requests review of RFC2119 wording.
2. Scott Burleigh will be document shephard for BPSec. 
3. Chairs to poll for WG adoption of BIBE on DTNWG mailing list.
4. Chairs to request charter disposition on NM with IESG.




Questions (Q), Answers (A), and Comments (C):


Presentation 1: Working Group Milestones (Rick Taylor & Marc Blanchet) 5 min
--------------------------------------------------------------------------------

Rick Taylor discussed progress on BPBis, TCPCLv4, and BPSec. Focus is on TCPVLv4
with BPSec to follow.


C: Scott Burleigh: Original through was to send 3 documents together BPBis, 
                   TCPCLv4, and BPSec.

C: Marc Blanchet:  We should submit TCPCLv4 and BPBis first. If there are 
                   changes to those documents, that might impact BPSec.





Presentation 2: TCPCLv4 (Brian Sipos) 20min
--------------------------------------------------------------------------------

Brian Sipos presented working group dradft for TCPCLv4.

-	Reviewed motivations for the TCPCLv4, which generally follows workflow and 
    nomenclature of TCPCLv3.
    o   New motivation being added capability for future extensions.
-	Separate IANA registries are established for TCPCLv3 and TCPCLv4 items.
-	Walked through individual changes in -09. 
	o	Still have a single phase contact negotiation, but is split between 
	    pre-security and post-security.
	o	Still uni-directional in that once negotiated, you do not re-negotiate. 
	o	Only unsecured data is the CAN_TLS flag and magic octets that establish 
	    you are talking to a TCPCL node. This guarantees implementations cannot 
	    supply unsecured data if they do not want to. Can’t leak negotiated 
	    contact info.
    o   Added transfer extension capability similar to the session extension 
        capability.
-   Draft is complete and there is an up-to-date working implementation.


C: Rick Taylor: This work is vital. Must get done and to IESG as fast as 
                possible. This has been in Last Call for a while. Brian working 
                solo, but need more feedback and comments as soon as possible. 

Q: Stuart Card: Is there anything in this draft that would prohibit using 
                various TCP options? In same environemnts where BP might be
                handy, having robust TCP would also be handy. For example, 
                SCPS-TCP.

A: Brian Sipos: TCPCL assumes there is already a TCP connection. It leaves up 
                to the network implementation where and how the TCP connection 
                comes about. Believe there is nothing in TCPCL that prevents 
                underlying options.

C: Rick Taylor: If you feel there is more text needed, please review and
                propose.

C: Rick Taylor(chair): Desire of chairs is to make a 2 week “last last” call 
                     and then submit.

C: Rick Taylor: Spec has many authors. Chairs are trying to reach out to them to 
                assist Brian. Once in the IESG pipeline, there will be AD 
                reviews and editorial nits.

C: Brian Sipos: Last area for feedback: comments earlier on discussion in draft 
                with SHOULD and optional behaviors. Have not gone through and 
                scrubbed cases of SHOULD and MAY. If you review and RFC2119 
                language isn’t clear, please comment. 


Presentation 3: BPSec and Interop (Ed Birrane) 30min
--------------------------------------------------------------------------------

- BPSec has review comments back from security area. Additionally sent to other 
  standards bodies and received minor comment back. 
- Sec Area review: 3 comments.
  o   Confusion as to what we meant by integrity relating to encryption. Did 
      clarify some text. Put in stronger statement about when using encryption, 
      need to use AEAD cipher suite. Mandates authenticated encryption (MUST). 
      Also says "encrypt then authenticate". Reviewer belived BIB was meant to 
      provide security so we added text to clarify. BIB only meant to generate 
      signatures over plain text. Also a question about whether we could alter 
      the size of the payload.
  o   2119 wording questions. Again asking for WG to check on usage of these.
  o   Very large Security Considerations section. Moved a paragraph. Do need to 
      assume nodes in a DTN may be under the control of an attacker.

- CCSDS also looked at it. Their comments were similar. Some comments very 
  specific to CCSDS use cases. Minor text suggestions. We use "security target" 
  for the recvr of security service, the block. Use of word "target" was 
  questioned - suggestion to use "security recipient".
  o Fred Templin commented that IPv6 Neighbour Discovery uses the word target 
    heavily. It's not target like under attack.

- Multiple security sources: nodes in middle of network may add security service 
  to the bundle, when it is forwarded. May have a BIB then later add a BCB. 
  Security can come in along the way.

- Security blocks - clarifications. Corrected citations. Require BCB cipher 
  suites to be AEAD. Added text that if security source field is not set (as 
  it is optional) we determine source from other information. Sometimes the 
  source does not want to be specified. If I get a BIB i will assume it comes 
  from a particular person, and if it doesn't match then something bad happened.

- Removed text that BCB cant alter size of target block. Don't apply to bundles 
  where payload is a fragment. Can generate cipher suites that never alter size 
  of target. Deployments may not care if extension or payload block becomes   
  larger.

- Clarified processing in a corner case. Applying block integrity and encryption 
  at the same time. eg a BIB with 3 signatures. Later, a waypoint might want to 
  encrypt, eg target 2. By processing rules we must encrypt the signature on 
  that target. We have to be able to deal with that, not also encrypt the 
  signatures of target 1 and 3. Need to pull that BIB apart. Pull the signature 
  into its own BIB block, removing from the original BIB. 

- Added additional example to clarify BIBs can be added before BCBs. 

- When a BCB and a BIB share a target, the BCB must be processed first.

- No changes to key management. 

- Questions (slide)
  o   Not necessary to add graphic for multiple security sources.
  o   Altering target black data field size may be an issue for some networks 
      but not others.
  o   Cipher suites may remove blocks from a bundle - BPSec shouldnt disallow 
      this, it can be documented in a cipher suite.

- Interoperability Cipher Suites (02).
  o   Picked algorithms.
  o   Updates (see slide).
  o   Still some work left: How BPbis captures block type specific fields, 
      additional guidance on block size expansion.

- Type specific fields have no mandated CBOR encoding, so how to encode these? 
  o   2 options.
  o   A: If it's a byte string, length, data. Same size when encrypted.
  o   B: Can't do this if it's an array - will be larger.

- So can we always represent block type specific fields as byte strings as this 
  is easier? Is re-using the length field a violation? Open question to WG.

C: Scott Burleigh: Vote for option A.

Q: Rick Taylor (participant): How does this interact with block length field 
                              discussion going on?

A: Scott Burleigh: Same issue. Block type specific is CBOR encoded anyway so 
                   why have length before it? Mailing list discussion is that 
                   this is the best way to go.

Q: Marc Blanchet: Aware of any implementation?

A: Ed Birrane: Not full implementation, partial went into ION. We need updated 
               BPbis implementation first

C: Scott Burleigh: There are 2 partial BPbis implementations.

C: Marc Blanchet: complex spec, so feedback from implementers would be useful.

C: Ed Birrane: CBOR encoding is new, could be prototyped fairly quickly.

C: Scott Burleigh: this specification is complete and comprehensible. Working on 
                   policy, will introduce complexity.

Q: Rick Taylor (chair): will that policy doc impact BPSec as it currently stands?

A: Scott Burleigh: No

C: Ed Birrane: Security Policy Considerations section is included in BPSec and
               can serve as guidance for other policy work.

Q: Rick Taylor (chair): Marked as in WG Last Call. Who has read latest version?

(not many fully read it)

C: Rick Taylor (chair): BPSec likely to follow BPbis and TCPCLv4. Again, asking 
                        for feedback, think about it in terms of implementation.

Q: Marc Blanchet: Need a shepherd for BPSec document. Following process, 
                  filling in a form, has the doc been reviewed, WG LC etc.

C: Scott Burleigh: I volunteer. 



Presentation 4: BIBE (Scott Burleigh) 20min
--------------------------------------------------------------------------------

Scott’s BIBE Presentation
- History of BIBE and use for custody transfer. 
  o  Original spec in 2009. Motivation for content-centric networking (forwarding 
     cached bundles), custodial retransmission of multicast bundles, security 
     tunnelling (defence against traffic analysis). Never got used much. 
     Resurrected in 2013 in IRTF by Scott. Conceived as a convergence layer 
     protocol under BP. A way to disentangle routing from security. BIBE tunnel 
     does the security source and security destination features of the original 
     Bundle Security Protocol spec.
  o  2015-2016: much discussion on custody transfer. Issue with custody of 
     fragments. 
  o  Last year separating custody transfer from BP. Idea - do custody transfer 
     at the convergence layer. ie use BP as a convergence layer. Realised BIBE 
     already did that.
- Considerations for Aggregate Custody Signalling in BIBE.
- Merge posted as draft-burleigh-dtn-bibect-01
- May be encrypted, signed, further encapsulated, etc...
- BIBE becomes reliable CL layer. 
  o  BIBE also gives us source path routing, multicast.
  o  BIBE is being considered for adoption in DTN WG. It's a brief and simple 
     specification, shouldn't be hard to implement. It is powerful, many 
     applications.


C: Marc Blanchet: This was in 5050 and got removed in BPbis. It's within the 
                  charter. Should we adopt?
3 votes yes at the mic.
No opposition.

C: Marc Blanchet: Will confirm on mailing list.


Presentation 5: Network Management (Ed Birrane) 20min
--------------------------------------------------------------------------------

Ed's presentation
- Network management in DTN, split into Architecture (AMA), Template (data model) 
  and Protocol documents.
- AMA was approved to be adopted at last IETF.
- HotRFC meeting on Sunday where this was presented.
- Motivation: Address the fact that nodes are not always part of the network, so 
  can't use the current management approaches.
- Need an intersection between spacecraft fault management systems and terrestial 
  management. Stimulus/response systems, knowing how the spacecraft would react 
  in any situation. No standards. Lots of standards in network management but 
  nothing considering autonomy, or compressing protocol stack.
- AMA is the one that we initally want adopted.
  o AMA updates: minor. 
  o ADM Template: atomic elements (hard coded, would need firmware update if it 
    changed), dynamic elements (can be configured).

C: Marc Blanchet: Current charter doesn't have management milestones except 
                  collecting requirements. Trying to find home for this work. 
                  Asking IESG for help.

Q: Ron in t Velt: What reaction from HotRFC?

A: Rick Taylor: Positive - people were interested. Whether they had use cases 
                was harder to judge. Ed and Rick been looking at other groups 
                and overlap. There is intellectual interest but people are busy 
                with their own work. This work has broader reach than DTN. Think 
                DTN is the right place for this. Benefit in asking for 
                experienced people from OPS area to help, review etc. 8000 YANG 
                Models that cover terrestrial equipment. Need to work out how 
                we can re-use that rather than reinvent.

C: Ed Birrane: Agree, talked to other people. Lot of existing work. One of the 
               issues is how some of the data is represented and the state 
               models and protocols and how you update it. Static representation 
               is tightly coupled with protocols which don't work in DTN. Other 
               people that can't run NETCONF, some general groundswell. None of 
               that goes to autonomy. Still nothing matches our use case, 
               nothing considers the autonomy model for when a node can't connect 
               back. Data model vs conops.

C: Rick Taylor (participant): DTN is the right anchor for the moment and we
                              should revise charter. The expertise is in the 
                              room so keep work in the room, with general 
                              review.

C: Rick Taylor: (chair) If we keep it here, we still have to hit our other 
                charter items. Won't be primary work, needs charter update. OPS 
                ADs, are thinking about YANG next, try to revisitand separate. 
                We could get involved with that. Use the mailing list and talk 
                to Rick and Ed if interested. 



Other Business / Open Mic
--------------------------------------------------------------------------------


Q: Marc Blanchet: Any other items?

Q: Stu Card: Where are we on other convergence layers like NORM?

A: Marc Blanchet: Happy to receive new specs/documents. 

C: Scott Burleigh: Know there is a NORM prototype convergence layer in DTN2, 
                   but no one has written it up.

C: Rick Taylor: I have a prototype convergence layer using HTTP. TCPCL is not 
                "the" convergence layer, it is the first convergence layer.

No other comments.