Application Techniques for Checking and Transformation of Names
draft-klensin-name-filters-03

< M. Note that fragments may themselves be fragmented,
  so fragmentation may in effect replace the original bundle with more
  than two fragments. (However, there is only one 'level' of
  fragmentation, as in IP fragmentation.)

  Any bundle whose primary block's bundle processing flags do NOT
  indicate that it must not be fragmented MAY be fragmented at any
  time, for any purpose, at the discretion of the bundle protocol
  agent.  NOTE, however, that some combinations of bundle
  fragmentation, replication, and routing might result in unexpected
  traffic patterns.

Burleigh                Expires February 2020                [Page 32]
Internet-Draft        Bundle Protocol Version 7            August 2019

  Fragmentation SHALL be constrained as follows:

    . The concatenation of the payloads of all fragments produced by
        fragmentation MUST always be identical to the payload of the
        fragmented bundle (that is, the bundle that is being
        fragmented). Note that the payloads of fragments resulting from
        different fragmentation episodes, in different parts of the
        network, may be overlapping subsets of the fragmented bundle's
        payload.
    . The primary block of each fragment MUST differ from that of the
        fragmented bundle, in that the bundle processing flags of the
        fragment MUST indicate that the bundle is a fragment and both
        fragment offset and total application data unit length must be
        provided.  Additionally, the CRC of the primary block of the
        fragmented bundle, if any, MUST be replaced in each fragment by
        a new CRC computed for the primary block of that fragment.
    . The payload blocks of fragments will differ from that of the
        fragmented bundle as noted above.
    . If the fragmented bundle is not a fragment or is the fragment
        with offset zero, then all extension blocks of the fragmented
        bundle MUST be replicated in the fragment whose offset is zero.
    . Each of the fragmented bundle's extension blocks whose "Block
        must be replicated in every fragment" flag is set to 1 MUST be
        replicated in every fragment.
    . Beyond these rules, replication of extension blocks in the
        fragments is an implementation matter.

5.9. Application Data Unit Reassembly

  If the concatenation -- as informed by fragment offsets and payload
  lengths -- of the payloads of all previously received fragments with
  the same source node ID and creation timestamp as this fragment,
  together with the payload of this fragment, forms a byte array whose
  length is equal to the total application data unit length in the
  fragment's primary block, then:

    . This byte array -- the reassembled application data unit --
        MUST replace the payload of this fragment.
    . The "Reassembly pending" retention constraint MUST be removed
        from every other fragment whose payload is a subset of the
        reassembled application data unit.

  Note: reassembly of application data units from fragments occurs at
  the nodes that are members of destination endpoints as necessary; an
  application data unit MAY also be reassembled at some other node on
  the path to the destination.

Burleigh                Expires February 2020                [Page 33]
Internet-Draft        Bundle Protocol Version 7            August 2019

5.10. Bundle Deletion

  The steps in deleting a bundle are:

  Step 1: If the "request reporting of bundle deletion" flag in the
  bundle's status report request field is set to 1, and if status
  reporting is enabled, then a bundle deletion status report citing
  the reason for deletion SHOULD be generated, destined for the
  bundle's report-to endpoint ID.

  Step 2: All of the bundle's retention constraints MUST be removed.

5.11. Discarding a Bundle

  As soon as a bundle has no remaining retention constraints it MAY be
  discarded, thereby releasing any persistent storage that may have
  been allocated to it.

5.12. Canceling a Transmission

  When requested to cancel a specified transmission, where the bundle
  created upon initiation of the indicated transmission has not yet
  been discarded, the bundle protocol agent MUST delete that bundle
  for the reason "transmission cancelled". For this purpose, the
  procedure defined in Section 5.10 MUST be followed.

6. Administrative Record Processing

6.1. Administrative Records

  Administrative records are standard application data units that are
  used in providing some of the features of the Bundle Protocol. One
  type of administrative record has been defined to date: bundle
  status reports.  Note that additional types of administrative
  records may be defined by supplementary DTN protocol specification
  documents.

  Every administrative record consists of:

      . Record type code (an unsigned integer for which valid values
        are as defined below).
      . Record content in type-specific format.

Burleigh                Expires February 2020                [Page 34]
Internet-Draft        Bundle Protocol Version 7            August 2019

  Valid administrative record type codes are defined as follows:

  +---------+--------------------------------------------+

  |  Value  |                  Meaning                  |

  +=========+============================================+

  |    1  | Bundle status report.                      |

  +---------+--------------------------------------------+

  | (other) | Reserved for future use.                  |

  +---------+--------------------------------------------+

                Figure 3: Administrative Record Type Codes

  Each BP administrative record SHALL be represented as a CBOR array
  comprising a 2-tuple.

  The first item of the array SHALL be a record type code, which SHALL
  be represented as a CBOR unsigned integer.

  The second element of this array SHALL be the applicable CBOR
  representation of the content of the record.  Details of the CBOR
  representation of administrative record type 1 are provided below.
  Details of the CBOR representation of other types of administrative
  record type are included in the specifications defining those
  records.

6.1.1. Bundle Status Reports

  The transmission of "bundle status reports" under specified
  conditions is an option that can be invoked when transmission of a
  bundle is requested. These reports are intended to provide
  information about how bundles are progressing through the system,
  including notices of receipt, forwarding, final delivery, and
  deletion. They are transmitted to the Report-to endpoints of
  bundles.

  Each bundle status report SHALL be represented as a CBOR array.  The
  number of elements in the array SHALL be either 6 (if the subject
  bundle is a fragment) or 4 (otherwise).

  The first item of the bundle status report array SHALL be bundle
  status information represented as a CBOR array of at least 4

Burleigh                Expires February 2020                [Page 35]
Internet-Draft        Bundle Protocol Version 7            August 2019

  elements.  The first four items of the bundle status information
  array shall provide information on the following four status
  assertions, in this order:

    . Reporting node received bundle.
    . Reporting node forwarded the bundle.
    . Reporting node delivered the bundle.
    . Reporting node deleted the bundle.

  Each item of the bundle status information array SHALL be a bundle
  status item represented as a CBOR array; the number of elements in
  each such array SHALL be either 2 (if the value of the first item of
  this bundle status item is 1 AND the "Report status time" flag was
  set to 1 in the bundle processing flags of the bundle whose status
  is being reported) or 1 (otherwise).  The first item of the bundle
  status item array SHALL be a status indicator, a Boolean value
  indicating whether or not the corresponding bundle status is
  asserted, represented as a CBOR Boolean value.  The second item of
  the bundle status item array, if present, SHALL indicate the time
  (as reported by the local system clock, an implementation matter) at
  which the indicated status was asserted for this bundle, represented
  as a DTN time as described in Section 4.1.6. above.

  The second item of the bundle status report array SHALL be the
  bundle status report reason code explaining the value of the status
  indicator, represented as a CBOR unsigned integer. Valid status
  report reason codes are defined in Figure 4 below but the list of
  status report reason codes provided here is neither exhaustive nor
  exclusive; supplementary DTN protocol specifications (including, but
  not restricted to, the Bundle Security Protocol [BPSEC]) may define
  additional reason codes.

  +---------+--------------------------------------------+

  | Value  |                  Meaning                  |

  +=========+============================================+

  |    0    | No additional information.                |

  +---------+--------------------------------------------+

  |    1    | Lifetime expired.                          |

  +---------+--------------------------------------------+

  |    2    | Forwarded over unidirectional link.        |

Burleigh                Expires February 2020                [Page 36]
Internet-Draft        Bundle Protocol Version 7            August 2019

  +---------+--------------------------------------------+

  |    3    | Transmission canceled.                    |

  +---------+--------------------------------------------+

  |    4    | Depleted storage.                          |

  +---------+--------------------------------------------+

  |    5    | Destination endpoint ID unintelligible.    |

  +---------+--------------------------------------------+

  |    6    | No known route to destination from here.  |

  +---------+--------------------------------------------+

  |    7    | No timely contact with next node on route. |

  +---------+--------------------------------------------+

  |    8    | Block unintelligible.                      |

  +---------+--------------------------------------------+

  |    9    | Hop limit exceeded.                        |

  +---------+--------------------------------------------+

  |    10  | Traffic pared (e.g., status reports).      |

  +---------+--------------------------------------------+

  | (other) | Reserved for future use.                  |

  +---------+--------------------------------------------+

                  Figure 4: Status Report Reason Codes

  The third item of the bundle status report array SHALL be the source
  node ID identifying the source of the bundle whose status is being
  reported, represented as described in Section 4.1.5.2. above.

  The fourth item of the bundle status report array SHALL be the
  creation timestamp of the bundle whose status is being reported,
  represented as described in Section 4.1.7. above.

Burleigh                Expires February 2020                [Page 37]
Internet-Draft        Bundle Protocol Version 7            August 2019

  The fifth item of the bundle status report array SHALL be present if
  and only if the bundle whose status is being reported contained a
  fragment offset.  If present, it SHALL be the subject bundle's
  fragment offset represented as a CBOR unsigned integer item.

  The sixth item of the bundle status report array SHALL be present if
  and only if the bundle whose status is being reported contained a
  fragment offset.  If present, it SHALL be the length of the subject
  bundle's payload represented as a CBOR unsigned integer item.

6.2. Generation of Administrative Records

  Whenever the application agent's administrative element is directed
  by the bundle protocol agent to generate an administrative record
  with reference to some bundle, the following procedure must be
  followed:

  Step 1: The administrative record must be constructed. If the
  administrative record references a bundle and the referenced bundle
  is a fragment, the administrative record MUST contain the fragment
  offset and fragment length.

  Step 2: A request for transmission of a bundle whose payload is this
  administrative record MUST be presented to the bundle protocol
  agent.

7. Services Required of the Convergence Layer

7.1. The Convergence Layer

  The successful operation of the end-to-end bundle protocol depends
  on the operation of underlying protocols at what is termed the
  "convergence layer"; these protocols accomplish communication
  between nodes. A wide variety of protocols may serve this purpose,
  so long as each convergence layer protocol adapter provides a
  defined minimal set of services to the bundle protocol agent. This
  convergence layer service specification enumerates those services.

7.2. Summary of Convergence Layer Services

  Each convergence layer protocol adapter is expected to provide the
  following services to the bundle protocol agent:

    . sending a bundle to a bundle node that is reachable via the
        convergence layer protocol;
    . notifying the bundle protocol agent when it has concluded its
        data sending procedures with regard to a bundle;

Burleigh                Expires February 2020                [Page 38]
Internet-Draft        Bundle Protocol Version 7            August 2019

    . delivering to the bundle protocol agent a bundle that was sent
        by a bundle node via the convergence layer protocol.

  The convergence layer service interface specified here is neither
  exhaustive nor exclusive. That is, supplementary DTN protocol
  specifications (including, but not restricted to, the Bundle
  Security Protocol [BPSEC]) may expect convergence layer adapters
  that serve BP implementations conforming to those protocols to
  provide additional services such as reporting on the transmission
  and/or reception progress of individual bundles (at completion
  and/or incrementally), retransmitting data that were lost in
  transit, discarding bundle-conveying data units that the convergence
  layer protocol determines are corrupt or inauthentic, or reporting
  on the integrity and/or authenticity of delivered bundles.

8. Implementation Status

  [NOTE to the RFC Editor: please remove this section before
  publication, as well as the reference to RFC 7942.]

  This section records the status of known implementations of the
  protocol defined by this specification at the time of posting of
  this Internet-Draft, and is based on a proposal described in RFC
  7942.  The description of implementations in this section is
  intended to assist the IETF in its decision processes in progressing
  drafts to RFCs.  Please note that the listing of any individual
  implementation here does not imply endorsement by the IETF.
  Furthermore, no effort has been spent to verify the information
  presented here that was supplied by IETF contributors.  This is not
  intended as, and must not be construed to be, a catalog of available
  implementations or their features.  Readers are advised to note that
  other implementations may exist.

  According to RFC 7942, "this will allow reviewers and working groups
  to assign due consideration to documents that have the benefit of
  running code, which may serve as evidence of valuable
  experimentation and feedback that have made the implemented
  protocols more mature.  It is up to the individual working groups to
  use this information as they see fit".

  At the time of this writing, there are three known implementations
  of the current document.

  The first known implementation is microPCN (https://upcn.eu/).
  According to the developers:

Burleigh                Expires February 2020                [Page 39]
Internet-Draft        Bundle Protocol Version 7            August 2019

    The Micro Planetary Communication Network (uPCN) is a free
    software project intended to offer an implementation of Delay-
    tolerant Networking protocols for POSIX operating systems (well,
    and for Linux) plus for the ARM Cortex STM32F4 microcontroller
    series. More precisely it currently provides an implementation of

      . the Bundle Protocol (BP, RFC 5050),
      . the Bundle Protocol version 7 specification draft (version 6),
      . the DTN IP Neighbor Discovery (IPND) protocol, and
      . a routing approach optimized for message-ferry micro LEO
          satellites.

    uPCN is written in C and is built upon the real-time operating
    system FreeRTOS. The source code of uPCN is released under the
    "BSD 3-Clause License".

    The project depends on an execution environment offering link
    layer protocols such as AX.25. The source code uses the USB
    subsystem to interact with the environment.

  The second known implementation is PyDTN, developed by X-works,
  s.r.o (https://x-works.sk/).  The final third of the implementation
  was developed during the IETF 101 Hackathon.  According to the
  developers, PyDTN implements bundle coding/decoding and neighbor
  discovery.  PyDTN is written in Python and has been shown to be
  interoperable with uPCN.

  The third known implementation is "Terra"
  (https://github.com/RightMesh/Terra/), a Java implementation
  developed in the context of terrestrial DTN. It includes an
  implementation of a "minimal TCP" convergence layer adapter.

9. Security Considerations

  The bundle protocol security architecture and the available security
  services are specified in an accompanying document, the Bundle
  Security Protocol specification [BPSEC].

  The bpsec extensions to Bundle Protocol enable each block of a
  bundle (other than a bpsec extension block) to be individually
  authenticated by a signature block (Block Integrity Block, or BIB)
  and also enable each block of a bundle other than the primary block
  (and the bpsec extension blocks themselves) to be individually
  encrypted by a BCB.

  Because the security mechanisms are extension blocks that are
  themselves inserted into the bundle, the integrity and

Burleigh                Expires February 2020                [Page 40]
Internet-Draft        Bundle Protocol Version 7            August 2019

  confidentiality of bundle blocks are protected while the bundle is
  at rest, awaiting transmission at the next forwarding opportunity,
  as well as in transit.

  Additionally, convergence-layer protocols that ensure authenticity
  of communication between adjacent nodes in BP network topology
  SHOULD be used where available, to minimize the ability of
  unauthenticated nodes to introduce inauthentic traffic into the
  network.  Convergence-layer protocols that ensure confidentiality of
  communication between adjacent nodes in BP network topology SHOULD
  also be used where available, to minimize exposure of the bundle's
  primary block and other clear-text blocks, thereby offering some
  defense against traffic analysis.

  Note that, while the primary block must remain in the clear for
  routing purposes, the Bundle Protocol can be protected against
  traffic analysis to some extent by using bundle-in-bundle
  encapsulation to tunnel bundles to a safe forward distribution
  point: the encapsulated bundle forms the payload of an encapsulating
  bundle, and that payload block may be encrypted by a BCB.

  Note that the generation of bundle status reports is disabled by
  default because malicious initiation of bundle status reporting
  could result in the transmission of extremely large numbers of
  bundles, effecting a denial of service attack.

  The bpsec extensions accommodate an open-ended range of
  ciphersuites; different ciphersuites may be utilized to protect
  different blocks.  One possible variation is to sign and/or encrypt
  blocks using symmetric keys securely formed by Diffie-Hellman
  procedures (such as EKDH) using the public and private keys of the
  sending and receiving nodes.  For this purpose, the key distribution
  problem reduces to the problem of trustworthy delay-tolerant
  distribution of public keys, a current research topic.

  Bundle security MUST NOT be invalidated by forwarding nodes even
  though they themselves might not use the Bundle Security Protocol.

  In particular, while blocks MAY be added to bundles transiting
  intermediate nodes, removal of blocks with the "Discard block if it
  can't be processed" flag set in the block processing control flags
  may cause security to fail.

  Inclusion of the Bundle Security Protocol in any Bundle Protocol
  implementation is RECOMMENDED. Use of the Bundle Security Protocol
  in Bundle Protocol operations is OPTIONAL, subject to the following
  guidelines:

Burleigh                Expires February 2020                [Page 41]
Internet-Draft        Bundle Protocol Version 7            August 2019

    . Every block (that is not a bpsec extension block) of every
        bundle SHOULD be authenticated by a BIB citing the ID of the
        node that inserted that block.  (Note that a single BIB may
        authenticate multiple "target" blocks.)  BIB authentication MAY
        be omitted on (and only on) any initial end-to-end path
        segments on which it would impose unacceptable overhead,
        provided that satisfactory authentication is ensured at the
        convergence layer and that BIB authentication is asserted on
        the first path segment on which the resulting overhead is
        acceptable and on all subsequent path segments.
    . If any segment of the end-to-end path of a bundle will traverse
        the Internet or any other potentially insecure communication
        environment, then the payload block SHOULD be encrypted by a
        BCB on this path segment and all subsequent segments of the
        end-to-end path.

10. IANA Considerations

  The Bundle Protocol includes fields requiring registries managed by
  IANA.

10.1. Bundle Block Types

  The Bundle Protocol has a Bundle Block Type code field (Section
  4.2.3).  An IANA registry has been set up as follows.

  The registration policy for this registry is:

      0-191: Specification Required.

      192-255: Private or experimental use.  No assignment by IANA.

  The Value range is: unsigned 8-bit integer.

                        Bundle Block Type Registry

    +--------------+---------------------------------+---------------+

    |        Value | Description                    | Reference    |

    +--------------+---------------------------------+---------------+

    |            0 | Reserved                        | This document |

    |            1 | Bundle Payload Block            | section 4.2.3 |

    |            2 | Block Integrity Block          | [BPSEC]      |

Burleigh                Expires February 2020                [Page 42]
Internet-Draft        Bundle Protocol Version 7            August 2019

    |            3 | Block Confidentiality Block    | [BPSEC]      |

    |          4-6 | Reserved                        | section 4.3  |

    |            7 | Previous node (proximate sender)| section 4.3.1 |

    |            8 | Bundle age (in seconds)        | section 4.3.2 |

    |            9 | Hop count (#prior xmit attempts)| section 4.3.3 |

    |      10-191 | Unassigned                      |              |

    |      192-255 | Private and/or Experimental Use | This document |

    +--------------+---------------------------------+---------------+

  IANA is requested to add values 2-9, as noted above, to the existing
  registry.

  The value "0" was not defined in any document or in the ad hoc
  registry.  As per consensus by the DTNRG research group, it is
  reserved per this document.

10.2. Primary Bundle Protocol Version

  The Bundle Protocol has a version field (Section 4.2.2).  An IANA
  registry has been set up as follows.

  The registration policy for this registry is: RFC Required.

  The value range is: unsigned 8-bit integer.

                Primary Bundle Protocol Version Registry

                  +-------+-------------+---------------+

                  | Value | Description | Reference    |

                  +-------+-------------+---------------+

                  |  0-5 | Reserved    | This document |

                  |    6 | Assigned    | [RFC5050]    |

                  |    7 | Assigned    | section 4.2.2 |

                  | 8-255 | Unassigned  |              |

Burleigh                Expires February 2020                [Page 43]
Internet-Draft        Bundle Protocol Version 7            August 2019

                  +-------+-------------+---------------+

  The value "0-5" was not defined in any document or in the ad hoc
  registry.  As per consensus by the DTNRG research group, it is
  reserved per this document.

10.3. Bundle Processing Control Flags

  The Bundle Protocol has a Bundle Processing Control Flags field
  (Section 4.1.3) for which IANA is requested to create and maintain a
  new registry named "BPv7 Bundle Processing Control Flags".  Initial
  values for this registry are given below.

  The registration policy for this registry is: Specification
  Required.

  The value range is: variable length.  Maximum number of flag bit
  positions: 16.

                Bundle Processing Control Flags Registry

  +--------------------+----------------------------------+----------+

  |      Bit Position | Description                      | Reference|

  |    (right to left) |                                  |          |

  +--------------------+----------------------------------+----------+

  |                  0 | Bundle is a fragment            | 4.1.3    |

  |                  1 | Application data unit is an      | 4.1.3    |

  |                    |  administrative record          |          |

  |                  2 | Bundle must not be fragmented    | 4.1.3    |

  |                  3 | reserved                        | 4.1.3    |

  |                  4 | reserved                        | 4.1.3    |

  |                  5 | Acknowledgement by application  | 4.1.3    |

  |                    |  is requested                  |          |

  |                  6 | Status time requested in reports | 4.1.3    |

Burleigh                Expires February 2020                [Page 44]
Internet-Draft        Bundle Protocol Version 7            August 2019

  |                  7 | Reserved                        | 4.1.3    |

  |                  8 | Request reporting of bundle      | 4.1.3    |

  |                    |  reception                      |          |

  |                  9 | Reserved                        | 4.1.3    |

  |                10 | Request reporting of bundle      | 4.1.3    |

  |                    |  forwarding                    |          |

  |                11 | Request reporting of bundle      | 4.1.3    |

  |                    |  delivery                      |          |

  |                12 | Request reporting of bundle      | 4.1.3    |

  |                    |  deletion                      |          |

  |              13-15 | Unassigned                      |          |

  +--------------------+----------------------------------+----------+

10.4. Block Processing Control Flags

  The Bundle Protocol has a Block Processing Control Flags field
  (Section 4.1.4) for which IANA is requested to create and maintain a
  new registry named "BPv7 Block Processing Control Flags".  Initial
  values for this registry are given below.

  The registration policy for this registry is: Specification
  Required.

  The value range is: variable length.  Maximum number of flag bit
  positions: 8.

                  Block Processing Control Flags Registry

  +--------------------+----------------------------------+----------+

  |      Bit Position | Description                      | Reference|

  |    (right to left) |                                  |          |

  +--------------------+----------------------------------+----------+

Burleigh                Expires February 2020                [Page 45]
Internet-Draft        Bundle Protocol Version 7            August 2019

  |                  0 | Block must be replicated in      | 4.1.4    |

  |                    |  every fragment                |          |

  |                  1 | Discard block if it can't be    | 4.1.4    |

  |                    |  processed                      |          |

  |                  2 | Transmit status report if block  | 4.1.4    |

  |                    |  can't be processed            |          |

  |                  3 | Delete bundle if block can't be  | 4.1.4    |

  |                    |  processed                      |          |

  |                4-7 | Reserved                        |          |

  +--------------------+----------------------------------+----------+

10.5. Bundle Status Report Reason Codes

  The Bundle Protocol has a Bundle Status Report Reason Codes field
  (Section 6.1.1) for which IANA is requested to create and maintain a
  new registry named "BPv7 Bundle Status Report Reason Codes".
  Initial values for this registry are given below.

  The registration policy for this registry is: Specification
  Required.

  The value range is: unsigned 8-bit integer.

                Bundle Status Report Reason Codes Registry

  +-------+-------------------------------------------+--------------+

  | Value | Description                              | Reference    |

  +-------+-------------------------------------------+--------------+

  |    0 | No additional information                | 6.1.1        |

  |    1 | Lifetime expired                          | 6.1.1        |

  |    2 | Forwarded over unidirectional link        | 6.1.1        |

  |    3 | Transmission canceled                    | 6.1.1        |

Burleigh                Expires February 2020                [Page 46]
Internet-Draft        Bundle Protocol Version 7            August 2019

  |    4 | Depleted storage                          | 6.1.1        |

  |    5 | Destination endpoint ID unintelligible    | 6.1.1        |

  |    6 | No known route to destination from here  | 6.1.1        |

  |    7 | No timely contact with next node on route | 6.1.1        |

  |    8 | Block unintelligible                      | 6.1.1        |

  |    9 | Hop limit exceeded                        | 6.1.1        |

  |    8 | Traffic pared                            | 6.1.1        |

  | 9-254 | Unassigned                                |              |

  |  255 | Reserved                                  |              |

  +-------+-------------------------------------------+--------------+

10.6. URI scheme types

  The Bundle Protocol has a URI scheme type field - an unsigned
  integer of undefined length - for which IANA is requested to create
  and maintain a new registry named "URI scheme type values".  Initial
  values for the Bundle Protocol URI scheme type registry are given
  below.

  The registration policy for this registry is: RFC Required.

  The value range is: unsigned 8-bit integer.

  Each assignment consists of a URI scheme type name and its
  associated value.

                      Bundle Block Type Registry

    +--------------+-----------------------------+-------------------+

    |        Value | Description                | Reference        |

    +--------------+-----------------------------+-------------------+

    |            0 | Reserved                    |                  |

    |            1 | dtn                        | section 10.7      |

Burleigh                Expires February 2020                [Page 47]
Internet-Draft        Bundle Protocol Version 7            August 2019

    |            2 | ipn                        | RFC6260, Section 4|

    |        3-254 | Unassigned                  |                  |

    |          255 | reserved                    |                  |

    +--------------+-----------------------------+-------------------+

10.7. New URI scheme "dtn"

  IANA is requested to register a URI scheme with the string "dtn" as
  the scheme name, as follows:

  URI scheme name: "dtn"

  Status: provisional

  URI scheme syntax:

  This specification uses the Augmented Backus-Naur Form (ABNF)
  notation of [RFC5234].

  dtn-uri = "dtn:" dtn-hier-part

  dtn-hier-part = "//" node-name name-delim demux ; a path-rootless

  node-name = 1*VCHAR

  name-delim = "/"

  demux = *VCHAR

  None of the reserved characters defined in the generic URI syntax
  are used as delimiters within URIs of the DTN scheme.

  URI scheme semantics: URIs of the DTN scheme are used as endpoint
  identifiers in the Delay-Tolerant Networking (DTN) Bundle Protocol
  (BP) as described in Section 4.1.5.1.

  Encoding considerations: URIs of the DTN scheme are encoded
  exclusively in US-ASCII characters.

  Applications and/or protocols that use this URI scheme name: the
  Delay-Tolerant Networking (DTN) Bundle Protocol (BP).

Burleigh                Expires February 2020                [Page 48]
Internet-Draft        Bundle Protocol Version 7            August 2019

  Interoperability considerations: as noted above, URIs of the DTN
  scheme are encoded exclusively in US-ASCII characters.

  Security considerations:

    . Reliability and consistency: none of the BP endpoints
        identified by the URIs of the DTN scheme are guaranteed to be
        reachable at any time, and the identity of the processing
        entities operating on those endpoints is never guaranteed by
        the Bundle Protocol itself. Bundle authentication as defined by
        the Bundle Security Protocol is required for this purpose.
    . Malicious construction: malicious construction of a conformant
        DTN-scheme URI is limited to the malicious selection of node
        names and the malicious selection of demux strings.  That is, a
        maliciously constructed DTN-scheme URI could be used to direct
        a bundle to an endpoint that might be damaged by the arrival of
        that bundle or, alternatively, to declare a false source for a
        bundle and thereby cause incorrect processing at a node that
        receives the bundle.  In both cases (and indeed in all bundle
        processing), the node that receives a bundle should verify its
        authenticity and validity before operating on it in any way.
    . Back-end transcoding: the limited expressiveness of URIs of the
        DTN scheme effectively eliminates the possibility of threat due
        to errors in back-end transcoding.
    . Rare IP address formats: not relevant, as IP addresses do not
        appear anywhere in conformant DTN-scheme URIs.
    . Sensitive information: because DTN-scheme URIs are used only to
        represent the identities of Bundle Protocol endpoints, the risk
        of disclosure of sensitive information due to interception of
        these URIs is minimal.  Examination of DTN-scheme URIs could be
        used to support traffic analysis; where traffic analysis is a
        plausible danger, bundles should be conveyed by secure
        convergence-layer protocols that do not expose endpoint IDs.
    . Semantic attacks: the simplicity of DTN-scheme URI syntax
        minimizes the possibility of misinterpretation of a URI by a
        human user.

  Contact:

      Scott Burleigh

      Jet Propulsion Laboratory,

      California Institute of Technology

      scott.c.burleigh@jpl.nasa.gov

Burleigh                Expires February 2020                [Page 49]
Internet-Draft        Bundle Protocol Version 7            August 2019

      +1 (800) 393-3353

  Author/Change controller:

      Scott Burleigh

      Jet Propulsion Laboratory,

      California Institute of Technology

      scott.c.burleigh@jpl.nasa.gov

11. References

11.1. Normative References

  [BPSEC] Birrane, E., "Bundle Security Protocol Specification", Work
  In Progress, October 2015.

  [CRC16] ITU-T Recommendation X.25, p. 9, section 2.2.7.4,
  International Telecommunications Union, October 1996.

  [CRC32C] Castagnoli, G., Brauer, S., and M. Herrmann, "Optimization
  of Cyclic Redundancy-Check Codes with 24 and 32 Parity Bits", IEEE
  Transact. on Communications, Vol. 41, No. 6, June 1993.

  [EPOCH] Thompson, K. and D. M. Ritchie, "UNIX Programmer's Manual,
  Fifth Edition", Bell Telephone Laboratories Inc., June 1974.

  [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
  Requirement Levels", BCP 14, RFC 2119, March 1997.

  [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
  Specifications: ABNF", STD 68, RFC 5234, January 2008.

  [RFC7049] Borman, C. and P. Hoffman, "Concise Binary Object
  Representation (CBOR)", RFC 7049, October 2013.

  [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
  2119 Key Words", BCP 14, RFC 8174, May 2017.

  [URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
  Resource Identifier (URI): Generic Syntax", RFC 3986, STD 66,
  January 2005.

Burleigh                Expires February 2020                [Page 50]IESG state changed to Approved-announcement sent

Added agenda item to 10/2/2003 agenda for request to IAB to consider the question of validity tests.  If approved, response will be expected from the IAB on 11/7/2003