* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Dtn Status Pages

Delay/Disruption Tolerant Networking (Active WG)
Tsv Area: Mirja Kühlewind, Spencer Dawkins | 2014-Nov-07 —  
Chairs
 
 


IETF-99 dtn minutes

Session 2017-07-17 0930-1200: Athens/Barcelona - Audio stream - dtn chatroom

Minutes

minutes-99-dtn-01 minutes



          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 :)
          
          



Generated from PyHt script /wg/dtn/minutes.pyht Latest update: 24 Oct 2012 16:51 GMT -