Minutes IETF102: dtn
minutes-102-dtn-00
| Meeting Minutes | Delay/Disruption Tolerant Networking (dtn) WG | |
|---|---|---|
| Date and time | 2018-07-19 17:30 | |
| Title | Minutes IETF102: dtn | |
| State | Active | |
| Other versions | plain text | |
| Last updated | 2018-07-21 |
minutes-102-dtn-00
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.