Minutes IETF100: dtn
minutes-100-dtn-00

Meeting Minutes Delay/Disruption Tolerant Networking (dtn) WG
Title Minutes IETF100: dtn
State Active
Other versions plain text
Last updated 2017-11-18

Meeting Minutes
minutes-100-dtn

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.