Re: [dtn] DTN BoF Proposal for IETF90

["Birrane, Edward J." <[e-mail]>]

Fred,

  I wanted to concur on the changes to the BOF agenda times. Some time discussing security, management, and 5050bis are good ways to prime the larger discussion for the charter of the proposed working group. I also think the updated working group charter goals and milestones are more appropriate. I have a few notes for security and management, which I will put forward in different messages to preserve threading.

-Ed
  
________________________________________
From: dtn [[e-mail]] On Behalf Of Templin, Fred L [[e-mail]]
Sent: Friday, June 06, 2014 2:44 PM
To: [e-mail]
Subject: Re: [dtn] DTN BoF Proposal for IETF90

See below for updated charter with pointer to new doc (diffs attached).

Thanks - Fred

---

Draft BoF Agenda (2.5hrs):
**************************
1) Problem statement (IETF wg motivation) - 30min

2) RFC5050(bis) - 15min

3) Streamlined Bundle Security Protocol (SBSP) - 15min

4) Bundle-in-Bundle Encapsulation - 10min

5) Security Key Management - 10min

6) Registry for Service Identifiers - 10min

7) Network Management - 10min

8) Open Discussion - 50min


Proposed working group charter:
*******************************
Working group name:

      Delay/Disruption Tolerant Networking Working Group (DTNWG)

Chair(s):

      TBD

Area and Area Director(s):

      Transport Area: ADs Spencer Dawkins <spencerdawkins.ietf at gmail.com>,
                          Martin Stiemerling <mls.ietf at gmail.com>

Responsible Area Director:

      TBD

Mailing list:

      General Discussion: dtn at ietf.org
      To Subscribe: https://www.ietf.org/mailman/listinfo/dtn
      Archive: http://www.ietf.org/mail-archive/web/dtn/current/maillist.html

Description of Working Group:

      The Delay/Disruption Tolerant Network Working Group (DTNWG) specifies
      mechanisms for data communications in the presence of long delays
      and/or intermittent connectivity. The work is motivated by well known
      limitations of standard Internet protocols that expect end-to-end
      connectivity between communicating endpoints, sub-second transmission
      delays and robust packet delivery ratios. In environments where these
      favorable conditions do not apply, existing mechanisms such as reliable
      transport protocols and routing protocols can fail to converge resulting
      in communication failures. Furthermore, classical end-to-end security
      associations cannot be coordinated when communicating endpoints cannot
      conduct multi-message keying exchanges in a timely fashion. These
      limitations suggest the need for a new approach.

      Delay-Tolerant Networking (DTN) protocols have been the subject of
      extensive research and development in the Delay-Tolerant Networking
      Research Group of the Internet Research Task Force since 2002.  In
      particular, the DTN Bundle Protocol (RFC 5050) and Licklider
      Transmission Protocol (RFC 5326) have been shown to address the
      issues identified above in substantial fielded deployments [1].

      The success of the BP/LTP protocol stack -- the core protocols of the
      "DTN Architecture" originally described in RFC 4838 -- may be attributed
      to the following fundamental design principles:

        - There is never any expectation of contemporaneous end-to-end
          connectivity between any two network nodes.

        - Because end-to-end connectivity can never be assumed, each node
          on the path between source and destination must be prepared to
          handle incoming "bundles" of data that cannot immediately be
          forwarded.

        - Again because end-to-end connectivity can never be assumed,
          end-to-end conversational data exchange can never be assumed to
          complete in a timely manner; protocol features that rely on
          timely conversational data exchange must be excluded from the
          architecture.

      The DTNWG believes that protocols adhering to these principles offer
      opportunities for enhancing the functionality of the Internet - in
      particular, for facilitating the extension of the Internet into
      environments such as the ocean floor and deep space in which the core
      Internet protocols operate sub-optimally for the reasons discussed
      earlier.  We believe that the extensive research, demonstration, and
      pilot operations performed to date using the DTNRG protocols provides
      a firm basis for publishing Internet standards derived from that work.

      Work items related to Delay/Disruption Tolerant Networking include:

      o A mechanism for the exchange of protocol data units, termed
        "bundles", that are designed to obviate conversational communications
        by containing values for all potentially relevant configuration
        parameters.  These protocol data units are typically larger than
        network-layer packets. We will derive this bundle exchange mechanism
        from the DTN Bundle Protocol (BP) documented in RFC 5050 by publishing
        a new document [2], where appendix A and B provide an update summary.

      o A security protocol for ensuring that the network in which bundles
        are exchanged is secured against unauthorized access and denial of
        service attacks, and to ensure data integrity and confidentiality
        in that network where necessary.  We will derive this security
        protocol from a "streamlined" adaptation of the DTN Bundle Security
        Protocol documented in RFC 6257.

      o An encapsulation protocol for "tunneling" BP traffic within bundles
        that are secured and/or routed in different way from the encapsulated
        bundles.

      o A delay-tolerant security key management scheme for ensuring that
        public keys are certified by a globally trusted authority to protect
        the integrity of the infrastructure.

      o A simple datagram convergence layer protocol for adaptation of the
        bundle protocol to underlying internetworks. We expect to derive
        this convergence layer protocol from the Datagram Convergence
        protocol documented in RFC 7122.

      o A delay-tolerant network management protocol for management of the
        infrastructure in the presence of long delays and/or intermittent
        connectivity.

      o A registry for DTN Service Identifiers

    The working group will consider extending the current milestones based on
    new information and knowledge gained while working on the initial charter,
    as well as to accommodate new work items beyond the scope of the initial
    phase.  For example, we expect that transport protocols such as LTP and
    the Saratoga protocol are among the candidates for work in this phase.

Goals and Milestones:
  start+3mos - Submit 'Bundle Protocol Specification (RFC5050bis)' as a
               working group document. To be Proposed Standard.
  Start+3mos - Submit 'Streamlined Bundle Security Protocol (SBSP)' as a
               working group document. To be Proposed Standard.
  start+6mos - Submit 'Bundle In Bundle Encapsulation (BIBE)' as a working
               group document. To be Proposed Standard.
  start+12mos - Submit 'Delay Tolerant Networking Security Key Management' as
                a working group document. To be Proposed Standard.
  start+18mos - WG determination for merging RFC5050bis, SBSP, BIBE and/or
                Key Mgmt into a combined draft or keep as separate drafts.
  start+18mos - Submit RFC5050bis, SBSP, BIBE and Key Mgmt to the IESG either
                as a combined draft or as separate drafts.
  start+18mos - Submit Network Management, Registry and Simple Convergence
                Layer as working group documents.
  start+20mos - Survey appropriate forums (e.g., DTNRG) for emerging
                technologies (e.g., convergence layer protocols, dynamic
                routing protocols, naming and addressing services, etc.)
                ready for transition into IETF DTN Working Group. Publish
                draft on survey results as independent submission related
                to the WG.
  start+24mos - Submit Network Management, Registry and Simple Convergence
                Layer to IESG
  start+24mos - Recharter to accommodate new work items or close Working Group


[1] "BP/LTP deployment on EPOXI spacecraft" [2008]
[2] "Proposed Revised Bundle Protocol" [2014],
    https://datatracker.ietf.org/doc/draft-burleigh-bpv7/