IETF DTN Working Group Minutes April 4th, 2016 IETF95, Buenos Aires, Argentina ======================================== Administrativia ---------------------------------------- - Brian Haberman is in two meetings at same time, will attend DTNWG in person and remote to other. - Ed Birrane and Rick Taylor to take notes. - Notewell noted. Agenda Bashing ---------------------------------------- - None Summary ---------------------------------------- - Agreed to put BPBIS in to last call, starting 2 weeks from today and having a 4 week review period. - Agreed to remove BABs, security destinations, and First/Last blocks from BPSEC. Will take removal of CMS blocks to mailing list. - Discussion of key management protocol design is premature without key management requirements and assumptions. Requirements must not encode/mask design (e.g. PKDN or identity-based schemes). - AMA document will be sent to the OPS area for review and comment. - A neighbor discovery architecture, independent of CLA, is needed to put other discovery protocols in context. Looking for volunteers to write this. - Work on an addressing architecture is necessary in general, and most recently to help explain the nature of routing table entries in the static routing drafts. Questions (Q), Answers (A), and Comments (C): Presentation 0 : DTNWG Charter Review (Marc Blanchet) ---------------------------------------- Marc presented an overview of the working group charter. Including standards track revision to RFC5050, architecture documents, security protocol, node neighbor discovery, service registry, informational document on static routing, investigations on enhanced neighbor discovery, key management, and network management. Presentation 1 : BPBIS (Scott Burleigh) ---------------------------------------- Scott summarized changes to BPBIS to include: - All blocks, not just primary, could include CRCs. - Considering removing one clause of the spec having to do with the status report on forwarding over unidirectional links. - Propose to move ahead into last call and get an RFC out this year. Q: Kevin Fall: If all blocks have a CRC and in the future I wish to define a block that did not have a CRC, I could not do that without additional overhead, correct? I would still need an indicator that the block did not contain a CRC. Can we encode CRC type in the block type? A: Scott Burleigh: We could do that. Q: Ed Birrane: Could we add a CRC type bit to block flags A: Scott Burleigh: Yes, but we don’t have block flags we just have flags. Q: Brian Haberman: Any object to moving to last call and having this discussion as part of last call? C: Ronald in ’t Velt: If we go for last call: would like it to be a long period, not just two weeks. C: Brian Haberman: 4 weeks of last call, starting 2 weeks from today, so we have 6 weeks total. Start reviewing it now. C: Scott Burleigh: An initial draft of a CBOR encoding is posted as well. Current discussion on the mailing list seemed reasonable and will drive some revisions to the document. Otherwise, the CBOR spec is likely close to being finished, too. Presentation 2 : BPSEC (Ed Birrane) ---------------------------------------- Ed summarized changes to BPSEC to include: - Continued discussion of the removal of authentication blocks and 5 alternatives to authentication absent these blocks. - Remove of security destinations and having block processing be a matter of policy. - Removal of first/last block types and stating that a security operation will have at most 1 security block. - Removal of CMS. Q: Kevin Fall: You presented several options for authentication absent a BAB. How does someone pick from amongst them?” A: Ed Birrane: It depends on the requirements, and we plan to put the decision criteria in a security practices document separate from the BPSEC document. C: Scott Burleigh: In BPBIS, the payload is always the last block, which also supports the concept of not having “first/last” blocks for items targeting the payload. C: Marc Banchet: Perhaps make the CMS a separate document, so as to simplify implementations. Presentation 3: Public Key Management (Kapali Viswanathan) ---------------------------------------- Kapali presented the requirements and design of a public key management system. This system relies on a reliable, public DTN multicast and validators chosen by configuration or discovery. Q: Ed Birrane : Several assumptions encoded in this approach. Can you capture the assumptions and constraints along with requirements for this system A: Kapali Viswanathan: Yes, we can add bootstrapping assumptions. Q: Ed Birrane: How do you validate yourself to (and from) the validator? A: Kapali Viswanathan: Validation occurs out of band. Q: Ed Birrane: PKDN would be used to communicate long-term keys, not session keys, correct? A: Kapali Viswanathan: Correct. Long-term keys only. C: Kevin Fall: Your depiction of full operation depends on a reliable, multi-cast DTN protocol - which is an unsolved research problem. Let’s assume that exists. We do have reliable multi-cast that might work in non-DTN environments. Q: Kevin Fall: If validators get different information over time, your choice of validator will give you different behavior. (ties back to routing again). How do you account for that? A: Kapali Viswanathan: I heard 2 questions: (1) reliable multi-cast to validators and (2) different validators have different states with respect to CRL. For reliable multi-cast you can also use a publish/subscribe mechanism. So you can go unicast to the certificate revocation manager and unicast the same message multiple times, if you do not have a reliable DTN multi-cast. For validators we different state, we can only guarantee eventual consistency. certificate validations will have a finite time (say valid for 8 hours) after that the session must be re-initiated. Q: Kevin Fall: It seems like endpoint needs to be cognizant to periodicity and engagement with validators. How do endpoints know this, because it is path dependent. A: Kapali Viswanathan: Session has a finite duration. C: Marc Blanchet: The purpose of this presentation was to discuss requirements. This conversation is more concerns with a solution than with requirements. Q: Kevin Fall: What is the charter item for this? A: Marc Blanchet: Requirements, not a mechanism. In general, to pull requirements that are well known and then modify based on what is special about the DTN environment. C: Ed Birrane: With assumptions and constraints added to requirements. C: Kevin Fall: There is a significant amount of existing work on key management using identity-based encryption which has different properties than what was presented here and could be written down in requirements document and melded together. Consider identify-based management as well, and some special items implied by DTN environment. C: Marc Blanchet: Agree with that approach. Process is to focus only on requirements and assumptions. C: Rick Taylor: Appreciate what this work is trying to do and what is trying to solve. Get feeling that assumptions section is big (of the solution) and possibly the requirements. Work is valuable but delayed until we are settled. C: Brian Haberman: Agree we need to understand what we are trying to do and agree with Rick that it is premature to talk about specifics right now. Presentation 4: Asynchronous Network Management (Ed Birrane) ---------------------------------------- Ed discussed an architecture document for open-loop network management. This includes the need for autonomy in network management and renaming associated protocol AMP not DTNMP to distinguish the work from DTN. C: Nalini Elkins: Consider taking this work to LMAP to see if there is any crossover. Q: Ed Birrane: If the AMA work sufficient to capture use-cases and act as requirements? A: Marc Blanchet: It is time to discuss with the OPs area. Particularly if you are going to write ADMs in YANG. C: Ed Birrane: Yes, AMA is probably ready for such review. AMP will be after the next set of updates. Presentation 5: IP Neighbor Discovery (Ronald in ’t Velt) ---------------------------------------- Discussion of neighbor discovery for IP. C: Kevin Fall: Previous work in this area talked through discovery options. There should be a neighbor discovery architecture that sits over all CLAs. Should be able to tell someone else I have other endpoints you can reach me on. Discovery may also include things like clock sync, time, and other capabilities. Hesitant to go down an IP-only route. C: Ron in ’t Velt: Put in request for port number. Need a registry of hash functions as well. C: Brian Haberman: If there are issues related to neighbor discovery architecture then asking IANA for multi-cast addresses is premature. IPv6 muticast addresses have lots of scopes that you can take advantage of without asking for an IANA registry. C: Rick Taylor: You would still need to register a port number. C: Rick Taylor: I see three types of discovery: 1. CLA-specific neighbor discovery 2. Generic-for-CLA considerations requirements, tips and trick 3. Endpoint discovery principles. Q Rick Taylor: Given that, do we need multiple documents? A: Marc Blanchet: We need direction from WG on where to go in terms of neighbor discovery. If there are other approaches on the table, we need people to work on those. C: Kevin Fall: There are lots of applicable things here, but it all must be done in context of the discovery architecture which needs some meat on it. Q: Will Ivancic: What is a neighbor definition in the sense of a bundle architecture? A: Ron in ’t Velt: A neighbor is another BP speaker C: Kevin Fall: Concrete recommendation: We need an architecture document for neighbor discovery. C: Ron in ’t Velt: CLAs inherited from DTNRG are IP-based and LTP. TCP and UDP CLA use IP. Would be fine to have neighbor discovery based on that. C: Kevin Fall: Fine for now, but must be defined so that we can add new CLAs later. C: Marc Blanchet: Need to find someone to tackle neighbor discovery architecture. Presentation 6: Static Routing (Nabil Benamar) ---------------------------------------- Presentation of static routing approach, including discussion of what would be present in a routing table entry. C: Kevin Fall: Recommend string matching for EID addresses. C: Ed Birrane: Consider data rate information in the routing table. Q: Rick Taylor: What do we put into these EIDs? Say I have 100,000 EIDs in my static routing table? Can I do some kind of compression on this? Can we subnet these things? A: Kevin: Compression like that doesn’t exist, but that doesn’t mean we can’t make progress. Idea is that you could choose to have different addressing structures per scheme name. If you do string matching in the EID you do not need to develop here a mechanism to understand all such current and future structures. Q: Rick Taylor: Should Nabil and John treat the EID as an opaque string and work on what goes in the entries, or should they capture some address stuff in here. Otherwise, how do we actually use the table entries? C: Brian Haberman: We have a work item for addressing architecture and making straw proposals. Need someone to work this.