IETF DTN Working Group Meeting July 17th Prague, CZ Chairs: Marc Blanchet & Rick Taylor Minutes taken by Victoria Pritchard & Ed Birrane Rick Taylor: Reviewed schedule and where we are behind. Milestones - 5050bis and TCPCLv4 were due to be finished December 2016, Custody (split out from 5050bis) and Bundle Security Protocol due May 2017. We are slipping. These are key items and we need to make progress. We have other items which are waiting. Please review (even a light review)! BPSec is critical. Needs better review because it's security-related, especially requires reviews as it goes up through IETF. Look through next charter items: * Opinions on neighbor discovery and drafts. * We need BPBis finished so we can build upon them. * Work not visibly in progress slide - need the basic building blocks done. Any comments on fact that we are delayed? Scott Burleigh - BIBE and BPSec are not alternatives. BIBE depends on BPSec existing. It doesn’t supplant it in any way. Scott Burleigh - Bundle Protocol Status presentation ---------------------------------------------------- * Overview of -07: 7th draft was posted June 22nd 2017. Removes custody transfer and reflects consensus on all comments received on draft 06 (except a couple of small items, and a couple of comments in the last few weeks on the mailing list). * Custody transfer split - one way is to retain as an extension block. Another way is to combine with BIBE (internet draft posted) and make an optional feature of BIBE. * Overview of custody transfer in BIBE: Turn BIBE into reliable CL protocol like TCPCL, able to operate over disrupted links. Key benefit of custody transfer is preserved. Retransmissions after timeouts. 5050 will always re-transmit too early or too late. Prefer to use reliable CL protocol. Use cases where Custody Transfer is necessary for reliability. Jorg Ott: Semantic question: It occurs to me that TCP end-to-end model secures bytes on the wire, but not how they are handled at receiver side. Reliable transfer not pick-up-storage-and-what-not. Comparing CT which also talks about durability in receiver side storage may be different than transport semantics. Are you taking those two semantic aspects apart or mingling them? Scott: BIBE approach unifies those concepts. Depending on implementation, it provides security on a hop-by-hop basis and reliable transmission compatible with that security, Jorg: Guarantee also enough space to rx something reliable and keep it. Not worried about security, worried about reliability and storage. If you take custody you can’t evict it because you have taken custody. Otherwise, if you rx something reliably you can drop it if you have not taken custody. Do we need to spell this out? Scott: Gives security hop by hop and reliability. Need to spell out clearly what the implications are here. Advantages: Reliability over sections which dont use a reliable CL. Simplifies Bundle Protocol. BIBE is self contained well structured specification. Fits neatly. Additional layer of security. Encapsulated bundle can be encrypted, defense against traffic analysis. Simplifies Custody Transfer - no partial custody transfer. RFC5050 issue with multi-point delivery. This is compatible with multi-point delivery. Custody acknowledgements from multiple places hard to track. With this, each neighbor you forward the bundle to is a custodian, each one is a separate transaction. Tracked individually in implementation. Multicast tree. Previous work on Bundle Delivery Time Estimation by researcher at JPL. This is a way to estimate the round trip time, and therefore retransmission timeout interval. Reasonably efficient retransmissions. Disadvantages: Overhead of encapsulation. Additional overhead is tolerable unless bundle is tiny. Next custodian must be known. Important use cases where that is not the case. In realistic operational uses you usually know who the next custodian is. If you don't know, you have no way of knowing when to retransmit. Potential impact on network performance is unacceptable. In opportunistic forwarding, the next custodian is likely the neighbor you just discovered. Marc: Within DTN network, say Node 1,2,3,4 Node 4 is dest, N1 source I know that from N1 perspective, N2, N3 are custodians. And there possible additional nodesin between. When N1 does that, it will address to N2 as custodian. Right? Scott: If it knows N2, N3 are custodians, it could address to N3 and not expect custody to N2. Marc: If I want to use many custodians, node2 will decapsulate and re-encapsulate. How does node2 know node3 is the next one? Or it doesn’t know? Scott: 2 answers: 1: It can be argued that N1 should not tell N2 that because it is source routing. Otherwise, if we want it to happen, you can do that because N1 could encap bundle in another bundle. Marc: Hop by hop custody. Scott: Consistent with 5050. Difference is you need to determine in advance who the custodians at each hop will be. John Dowdell: Thanks Scott. Interesting. Initial reaction to separation from 5050 was great, put it in BIBE, not convinced, but make interesting arguments. In world of opportunistic, move custody in more than 1 direction, multi-path. Does this support multi-path? Scott: Yes. Because you can send 4 different copies. Hold bundle and send to next discovered neighbor. To each neighbor you do custodial to that node. That node, in itself would extract bundle and could determine on its own whether it needed to go over BIBE or not. John: Said that all nodes in network must support custody xfer. You can send more than 1 bundle hop away. Is that correct. Intervening bundle hops are not custodial. Custody signal wouldn’t come from encapbundle. Scott: Custody signals come from destination of encapsulated bundle. Rick Taylor: Like it for 2 reasons: 1, 5050bis with CT came close to routing. 5050bis should be about transport and not routing. Happy with separation. Also likes that BIBE is definitely happening. Let's define it. In favour of this combination with BIBE. Ed Birrane on Jabber: In BPSec there were issues with destinations, as it implied routing - will we have the same problem? Scott: Fair question, think we do not because we do this at the convergence layer, the route from the current custodian and the next custodian can be entirely defined by the routing protocol. The route from A-D with nodes in between, convergence layer protocol does not need to know specific nodes along the route. So, it is a little brain -bending since it is BP at both levels, but it avoids the problem that we properly identified in bpsec. CL transmission is something that we already have in the architecture and makes a clean separation for what is end-to-end at the CL. Rick: During the BPSec discussion - we decided we can do this with BIBE, self fulfilling prophecy. Rick: Are you asking for BIBE-CT to be accepted as a WG document? Scott: If sense of room is that we are ready to go, would like this adopted. Or we can discuss further. Believe this idea is mature. Ready for adoption. Not many in the room have read it. Of those who have, none object. Take decision to list. John Dowdell: Point of order: as mentioned, someone will want to do BIBE anyway. Personally think it is worthy of WG adoption. Does it have to be perfect before adopted. Suggest not. Rick: Question isn’t “is this perfect” it is “can we adopt it”. Ed Birrane - BPSec Updates presentation --------------------------------------- 05 version of BPSec. Talked about 04 last time, received some comments and some got rolled in, will address those that didn't. 4 people in room have read a recent version. Summary of BPSec Motivation - in-bundle security mechanism, because different blocks may need different security. Classic example, payload block encrypted, but other extension block only integrity-signed. If you don't want in-bundle: You can protect at application layer, or use secure CL. Scott: An additional motivation is protection of data at rest, not just while in transmission. Use extension blocks, offering confidentiality (BCB) and integrity (BIB). List targets to which they apply (avoids redundant information). Processing rules and Security Considerations (see slide Summary (2/3) and Summary (3/3)) Covered updates since 04 as in slides. Primary block now immutable so doesn't need canonicalization. Discuss current comments - request that these are sent to the mailing list. At last WG meeting, noted that BPSec could go forward but needs an interoperability cipher suite - posted a draft with recommendations for integrity and for confidentiality to use for interoperability. These have COSE definitions. Needs review and updates. Should be ready for Last Call by next WG meeting. Spencer Dawkins: Need a registry because these are specific for BPSec? Ed: Yes, DTNs may need new cipher suites. Would point to existing in cases. In security considerations, should include DTN specific notes, especially regarding security at rest, and define new cipher suites. Spencer: When do you expect to send this to IETF Last Call? Rick: Do we think it is ready? Needs some more public review. Show of hands - 4 have read. John Dowdell: Worth an early security AD review? Rick: Yes, they do that. We can certainly request that, as it goes into last call. Spencer: They do. And as an advert for this: all review teams and directorates will do reviews as requested. You don’t have to wait until close. Even seen one review before adoption. Transport is doing review now. Review teams are becoming a lot more helpful and less source of late surprises. Rick: Will take final question on Last Call to list - general consensus seems it is good to go. Security people like to see more comments on the list. Marc: Need to wait until BpBis is out – changes to BPBis would cause a problem, and BPSec would drop out of Last Call. Scott: Do not anticipate significant changes to BPbis. Brian Sipos - TCPCLv4 presentation ---------------------------------- Few changes since last IETF. Not making major changes. Resolved questions: TLS mandatory to implement but optional to use. Negotiated per session. New IANA registries to separate from TCPCLv3. Extensions added to contact header. Message content headers modified to be octet-aligned. All comments to date have been incorporated. No open issues - but also no concurrence. A working implementation exists and is available for interoperability testing. Up-to-date to current Internet Draft. Only CL behavior. John Dowdell: TLS - why mandatory to implement but not use? Brian: Strong objection at previous IETF to make mandatory to use. Rick: Viewed as standard IETF practise to mandate to implement. A good compromise. Brian: Endpoint can say it does support or not. Rick: Request to post a link to the implementation. John Dowdell: Have read the security considerations - because this is based on another protocol (TCP), it should be referencing the TCP security considerations, and note any further considerations based on the usage in TCPCL. Offering text. Rick: Due to the time of year, holidays etc., 2 week Last Call is not long enough. Suggest end of August for end of Last Call. This applies to BPbis, TCPCLv4. Time for final reviews. Scott: If list decides BPSec is ready for last call, can it be included in the same time scale? Rick: Yes, they will end up in sync. Ed Birrane - Asynchronous Management Architecture presentation -------------------------------------------------------------- Draft not updated from 05 at last WG, since no additional comments. Few emails this week about additions. How network management is different in a DTN - needs some automation and autonomy. Does this draft satisfy requirements for management in a DTN? Is something missing, can we add to this document as a WG item? Most people in room are familiar with this draft. Cover requirements, assumptions, constraints. There was an IRTF management document we could draw from? Rick (not as chair): think this is very interesting. Could spend a LOT of time wordsmithing, would prefer to see it concise, general. Think a lot is there already. Supporting this. Adopt, finesse if required. It is a useful asset for the WG. Marc: Target is Informational document. John: This as arch and informational. What's the roadmap for this topic? Marc: Charter does not have room for a protocol. Scott: Support of Rick's idea and that we adopt this as a WG item. Spencer: Text for NM req: Would not go into business for ourselves and replace NETCONF - Would it be good do an applicability statement, not proposing standards, based on the architecture document? Rick: Ed, myself, others have been talking with netconf, netmod groups, and cbor-lightweight mgmt. group. The point of this document is to say here are the arch specific to DTN with applicability outside of traditional DTN community. Some interest from data-center guys: async is useful when data is moving so fast. Rick (personal): multi-disciplinary effort, not a re-invention for DTN. Relevant even if not on charter. Spencer: Would be supportive if WG want to work on this. Marc: To me, answer to this is having some draft of what that would be. Jéferson Nobre: Think there are some specific parts of the old draft (IRTF DTN NM Req) that maybe should be merged to this one. Other option is to leave this work as a new draft for DTNRG. Rick: Please suggest on mailing list. Discuss where this should be done and how much time to spend on it. Rick: Who says no: Rick: Who supports: Show of hands: no one thinks it shouldn't be worked on - most people willing to help work on this. Spencer: This is not what DTN does particularly - it can be chartered, more people may come to DTN to work on this, not just people in the room and on the DTN mailing list. Mention to IESG at afternoon session. Rick: Ed and I talking to Benoit, netmod groups. Yang-push and async-notifiction. This document described DTN perspective of mgmt.. How that is addressed may happen out of this group. Spencer: put the work forward and it will find a home. Marc: summarizing: Aim for end August to be finishing Last Call. Love to get feedback if agreement. Ask for WG adoption for Custody Transfer. BPSec WG Last Call AMA - ask for WG adoption. Rick: Draft for recommendations for cipher suites - should this be rolled in, or separate draft which needs to be adopted? Take to list. Ed on Jabber: Last WG, Ran seemed OK with these as separate documents. Rick: Benefit is that we can up-rev the recommendations without touching the protocol. Thank you all :)