IETF DTN Working Group Minutes November 17th, 2017 IETF100, Singapore Chairs: Marc Blanchet & Rick Taylor ================================================================================ Administrativia -------------------------------------------------------------------------------- - Ed Birrane and Victoria Pritchard will take notes. - No Jabber scribe identified. - Notewell noted. Agenda Bashing -------------------------------------------------------------------------------- - No changes. Milestones --------------------------------------------------------------------------------* - We are in Last Call for BPbis. - There is no TCPCL presentation scheduled for this meeting. - After presentation, will consider BPSec for last call. - As agreed at start of working group, BPbis first, everything else later. - Behind schedule, but keeping appropriate order for document submissions. SUMMARY -------------------------------------------------------------------------------- 1. Sending BPbis to IESG. Waiting for write-up of the document shepherd. 2. TCPCL will wait for review and final draft. Plan to send to IESG unless big changes encountered (which is unexpected) 3. Ask WG to adopt BIBE/Custody Transfer draft as a WG document 4. Ask WG to adopt BPSec Interoperability Cipher Suites draft as a WG document 5. Ask Security directorate to review BPSec 6. Ask WG to place BPSec in WG last call 7. Ask WG for adoption of the AMA draft Questions (Q), Answers (A), and Comments (C): Presentation 1: BPbis (Scott Burleigh) -------------------------------------------------------------------------------- - no slides for presentation (technical issues with Scott's laptop) - Review comments from mailing list, while few, were helpful. Q: Rick Taylor: Are there any comments or concerns with BPbis at this time? C: Rick Taylor: We should them move BPbis to the IESG queue. C: Scott Burleigh: As part of discussion on custody transfer at Prague, we were using BP as a reliable convergence layer protocol. Since that aligns with using BIBE as a CL for security purposes, it seemed reasonable to combine the two into a single document: BIBE with custody transfer. Q: Scott Burleigh: Suggest that BIBE with custody transfer be adopted as a WG document. Q: Rick Taylor: Has anyone in the room read this draft? C: Rick Taylor: Since much of this document was already in a WG document and extracted for expediancy of moving BPbis forward, it seems reasonable to accept this. We will need to ask for formal acceptance of this document on the list. Q: Rick Taylor: Are there any concerns in the room accepting this as a WG document? Presentation 2: BPSec (Ed Birrane) -------------------------------------------------------------------------------- - Specification not changed much in last few iterations. - Reviewed slides to recap motivation, properties, and changes. - Reviewed open comments not addressed in latest spec (and recommended not be addressed) Q. Spencer Dawkins: Is the open comment about not using key/value pairs that the document should not have MUST in the language for this? A: Ed Birrane: The comment was that key-value should not be a MUST. I think it should be a MUST but allow cipher suites to define what those keys and values will be. This includes allowing a cipher suite to define a value that is "opaque" if it would like. C: Spencer Dawkins: Concur. - BPSec defines interoperability Cipher Suites for Integrity and Confidentiality, but will publish as a separate doc in case of changes. Q: Spencer Dawkins: Are cipher suites separate from BPSec to allow them to more easily change? C: Rick Taylor: Intention of splitting was so that if a weakness was found in the recommended suite, we can uprev that without touching BPSec. Decoupling that which may change faster than the BPSec protocol. C: Spencer Dawkins: Good plan. C: Marc Blanchet: You need to implement 2 drafts to be compliant. C: Ed Birrane: Ran's point from a couple of IETFs ago was that they can come together in editor's queue even if submitted at different times. C: Marc Blanchet: I think they need to be sent together. Q: Spencer Dawkins: What is the goal of sending separately? Timeliness? C: Spencer Dawkins: People could look at the cipher suite recommendation draft as a WG document. Can put in Last Call text that there is this dependency and we're expecting BPSec draft to require a review where the selection of cipher suite is not necessary to be decided yet. C: Marc Blanchet: Disagree. C: Spencer Dawkins: We can ask for early security review of BPSec C: Ed Birrane: A cipher suite draft is required for implementation but the draft is not complex. The presence of the interoperability suite would not affect the review of BPSec. C: Rick Taylor: Ask for early security directorate review and put into last call if WG agrees and move to adopt the interoperability cipher suite as a WG document. C: Scott Burleigh: Agree with this. Q: Rick Taylor: Does anyone have substantive comments or believe BPSec not ready for Last Call? Q: Rick Taylor: Does anyone have objection to adopting cipher suite draft? Presentation 2.5: Sidebar on TCPCL (Rick Taylor) -------------------------------------------------------------------------------- C: Rick Taylor: BP, TCPCL, BPSec, and BPSec interoperability cipher suites form a working cluster of documents. All are needed to pass to standards. C: Rick Taylor: Request that we get a better review of TCPCL. C: V. Pritchard: I am half-way through a detailed review of TCPCL and will be posting comments shortly. Presentation 3: Asynchronous Management (Ed Birrane) -------------------------------------------------------------------------------- - Brief overview of AMA history, domain, scope - Separated into 3 layers: architecture (AMA), data model (ADM), and protocol (AMP). - DTNWG has charter item for network management - No significant AMA updates (spelling, added paragraph on tables) - New draft for ADM with a JSON files populating a YANG schema. - Two drafts (AMA and ADM) are out - is the level of information there sufficient to meet WG charter item? Both individual drafts at the moment. - Meeting with YANG doctor after meeting for advice to look at the encoding. - Asking for WG adoption of AMA. - Would like ADM adopted to but would happen after AMA. C: Rick Taylor: This might not be the only way to manage devices. This is one way. Other systems may use a more connected approach. C: Scott Burleigh: Agree, its also a potential way to manage networks other than DTNs. Applicability beyond this WG. C: Ed Birrane: If you make certain assumptions about your network, this is the approach you would end up with. People that aren't looking at DTN are still interested in the elements of automation. Presentation 4: SDN Management in DTN (Taixin Li) -------------------------------------------------------------------------------- - DTN supported by a national project in China. Build integrated space/terrestrial network. Our focus is on the space network. Proposed to use DTN for data transmission and SDN for the control. - Use GEO to distribute control plane to LEO/MEO objects. - Software Defined Datellite Networks (SDSN) - Updated ION to support IPv6 - Walked through several use cases and simulation models. - Using SDN/openflow tunneled inside of BP bundles on the space network side mapping to IPv6 addresses on the group for TCP/IP transmission. Q: Ashesh Mishra: How do you suggest GEO and LEO/MEO talk to each other. There is no inter-satellite link (ISL) between them. Not aware of any GEO and MEO that have an ISL that works. A: Taixin Li: We believe that this will happen one day, even if it is not happening now. C: Ashesh Mishra: OneWeb will not have ISLs. Neither will O3B. SpaceX announced they will, but only within LEO. No GEO for spaceX. Only two operators are known to do this now, governments (NASA) and SES (which currently owns the O3B assets). C: Taixin Li: We believe a Chinese system may do this. There is research on how to make these links work. C: Rick Taylor: Space architecture discussions, while very interesting and encouraged one-on-one, are outside of the scope of the DTNWG. Q: Jorg Ott: I am surprised to hear that SDN is happy to work over BP. Is that the case? A: Taixin Li: We do not store control data. We just store dat apackets on the nodes. You are correct, control is not stored there. GU and MU RTT is long, but it works OK. Q: Jorg Ott: If not stored and forwarded, why encapsulate in BP in the first place? A: Taixin Li: We use DTN in the whole satellite network. Don’t want other protocols because satellite nodes are limited in processing capabilities. Q: Marc Blanchet: Are you tunneling congtestion control of TCP, etc over BP? A: Taixin Li: We use TCP/IP terrestrially and BP in space, so there must be protocol translation/address mapping. For example, ipn:1.3 is mapped to another IPv6 or IPv4 address and then translation occurs. Q: Marc Blanchet: So the TCP payload goes into a bundle and you terminate the TCP connection there? A: Taixin Li: Yes. C: Adrian?: On topic of SDN and reliability, I think that the SDN architecture and application is delay-tolerant. So, the question about whether we need a 2 phase commit is really a choice of which SDN protocol is used. If you use an SDN protocol that is resilient because of an ACK, the network will not get out of phase and DTN is all you need. If you use an SDN protocol that makes assumptions (like write-only) then you will get synchronization issues. So there is some investigation on whether openflow is the correct sdn protocol to use. C: Scott Burleigh: Your concept of a space gateway will work, but propose that it will be easier to run BP underneath the application data from the ground up to the satellite rather than define and use a gateway. Let the gateway node just be a bundle forwarder rather than an address matcher. This is likely cleaner and easier to manager. C: Scott Burleigh: If you need to coordinate SDN config values across the network, the delay-tolerant way of doing that would be encapsulating SDN messages in time-tagged messages so that they would be distributed in advance of the time they need to be effective and held pending that effective time so that everything comes into alignment. Maybe that is beyond the scope of what can normally be done with SDN but seems a straightforward way of ensuring consistent configuration across the nwetwork. Q: Syu: Can this system be broken with fake forwarding switeches? How do you approach the security issues of SDN in your system. A: Taixin Li: Security is a very important research point. We have three GEO satellites all responsible for control. If all 3 break down, the system is broken, yes. For now the satellite communication systemis adjusted for 1 GEO. Need to do research on this. If 1 GEO breaks down, another will take up responsibility for the whole network. C: Scott Burleigh: The canonical way to address this protection is to use a BPSec signature on messages and ensure all forwarding nodes that pass data to a controller require payloads to pass an integrity signature verification. So the controller is shielded from inauthentic traffic. Should be able to do that with the protocols being designed/prototyped by DTNWG. Presentation 5: DTKA (Kapali Viswanathan) -------------------------------------------------------------------------------- - Reviewed DTKAA process from slides. - Assume all DTKA agents share a reliable link. Communications between authorities and between key owners and users can be delay-tolerant. - Public key of all authoirites are physically configured on each node, which are physically bootstrapped, like browsers that have keys when they are installed. - Reviewed how Key Authorities receive new key pairs from key owners and how they give new keys to key users. - Discussed hashing strategy for communicating bulletins of key information. Q: Rick Taylor: Why a bulletin hash? If you are using BPSec you already have that at the bundle layer. A: Kapali Viswanathan: We do not send the bulletin as-is. We code it and send. Multiple key agents will just send code blocks and not bulletin. C: Scott Burleigh: Before the list of authenticated node IDs and public keys is issued, that bulletin has to be developed as a consensus of agents of the KA. That single bulletin has to be bit-for-bit identical as distrubted by agents individually. C: Kapali Viswanathan: We assume 7+1 erasure coding. Assume 5/8 key authorities have to be received before bulletin is reconstructed. Now every received/key user knows consensus is reached. Q: Ed Birrane: That is for establishing a key. What about for revoking a key? A: Kapali Viswanathan: We could look into that if networks feel that different scenarios exist between assing and revoking a key. Q: Rick Taylor: You do not have temporal consistency checks. Maybe include hash of previous update (like a GIT tree). Have you considered that? A: Kapali Viswanathan: No because the bulletin hash is the minimal information set. We make the assumption that clocks are synchronized. Assuming that clocks are synchronous (within a few seconds) then the effective time is a future synchronization. Q: Rick Taylor: I understand that you can pin when it starts. If a node has been away from the system for a long time and then receives a batch of bulletin hashes, how can it know that it missed some intermediate bulletins that had revocations in them? If I have missed update 17, I should not be using updates 18, 19, 20, etc... yet. A previous hash value might solve that problem. A: Kapali Viswanathan: Today we assume that a bulletin that is sent will be received. You have a good point that we need to consider. C: Scott Burleigh. Synchronizing time across nodes is not necessary because the application of keys by effective time is based on the bundle creation time. Even if clocks are off, apply public key that matches creation time ofbundle. C: Ed Birrane: Key revocation and key addition may need different levels of confidence. Some networks may treat the error of prematurely revoking a key as less harmful than the error of accepting a key with less confidence. And vice-versa. C: Scott Burleigh: Key revocation can be just as michevious as key addition. It may be that a different level of scrutiny applies. That in itself seems dangerous. If we need it, a separate channel would need to exist. Maybe one channel for key addition versus another for key revocation. C: Rick Taylor: Could use same mechanism, but separate out of band channel from this. C: Scott Burleigh: They would be different multi-cast groups. Q: Rick Taylor: Are you asking for WG adoption of this standard? A: Kapali Viswanathan: We are not asking for WG adoption now, we will ask for that at some point in the future. For now we are asking for review.