Delay-Tolerant Networking Working Group S. Burleigh
Internet Draft JPL, Calif. Inst. Of Technology
Intended status: Standards Track K. Fall
Expires: April 20, 2020 Roland Computing Services
E. Birrane
APL, Johns Hopkins University
October 18, 2019
Bundle Protocol Version 7
draft-ietf-dtn-bpbis-15.txt
…
Comments here are related to the following rationale. RFC5050 has many implementations and has many deployments. It is very likely that the same implementors will augment their implementation to support this new version, especially to provide gateway functionality between the two versions. Therefore, for values that have the same semantics for both versions, we conjecture that they should have the same value, which would really ease the implementations. The fact that the encoding of the bundles changed in fact is just the encoding: the actual values and structures inside an implementation remain the same. Therefore, the comments below try to achieve merged registries with common values shared and specific values defined for each protocol. Therefore, an implementation can share the common semantics, structures and dictionaries between the two versions.
10. IANA Considerations
The Bundle Protocol includes fields requiring registries managed by
IANA.
10.1. Bundle Block Types
IANA is requested to add values 2-9, as noted below, to the Bundle
Block Type registry. In addition, the value "0" was not defined in
that registry; as per consensus by the DTN working group, it is
reserved per this document.
+--------------+---------------------------------+---------------+
| Value | Description | Reference |
+--------------+---------------------------------+---------------+
| 0 | Reserved | This document |
| 2 | Block Integrity Block | [BPSEC] |
| 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 |
+--------------+---------------------------------+---------------+
The current IANA Bundle Block Types Registry is as follows:
Value,Description,Reference
0,Reserved,[RFC6255]
1,Bundle Payload Block,[RFC5050]
2,Bundle Authentication Block,[RFC6257]
3,Payload Integrity Block,[RFC6257]
4,Payload Confidentiality Block,[RFC6257]
5,Previous-Hop Insertion Block,[RFC6259]
6-7,Unassigned,
8,Metadata Extension Block,[RFC6258]
9,Extension Security Block,[RFC6257]
10-191,Unassigned,
192-255,Reserved for Private and/or Experimental Use,[RFC5050]
In the above text, we see value 2 and 3 from BPSEC. BPSEC document should be the one requesting the allocations, not this document.
As one can see, they both share some semantics. Here is a proposal to merge the two versions into a single registry, in CSV format and with corresponding text.
The current Bundle Block Types Registry is augmented by adding a column identifying the version of the Bundle protocol (Bundle Protocol Version) that applies to the new values, and by adding the following values, as described in section 4.3.1. The current values in the registry should have the Bundle Protocol Version set to the value “6”, as shown below.
Value,Description, Bundle Protocol Version, Reference
6, Previous node (proximate sender), 7, [this document]
7, Bundle age (in seconds), 7, [this document]
10, Hop count (#prior xmit attempts), 7, [this document]
Value,Description, Bundle Protocol Version, Reference
0,Reserved, None, [RFC6255]
1,Bundle Payload Block, 6, [RFC5050]
2,Bundle Authentication Block, 6, [RFC6257]
3,Payload Integrity Block,6, [RFC6257]
4,Payload Confidentiality Block,6, [RFC6257]
5,Previous-Hop Insertion Block, 6, [RFC6259]
8,Metadata Extension Block,6, [RFC6258]
9,Extension Security Block,6, [RFC6257]
11-191,Unassigned, None,
192-255,Reserved for Private and/or Experimental Use, 6-7, [RFC5050]
10.2. Primary Bundle Protocol Version
IANA is requested to add value 7, as noted below, to the Primary
Bundle Protocol Version registry. In addition, the values "0-5"
were not defined in that registry; as per consensus by the DTN
working group, they are reserved per this document.
+-------+-------------+---------------+
| Value | Description | Reference |
+-------+-------------+---------------+
| 0-5 | Reserved | This document |
| 7 | Assigned | section 4.2.2 |
+-------+-------------+---------------+
The current IANA Primary Bundle Protocol Version Registry is as follows:
Value,Description,Reference
0-5,Reserved,[RFC6255]
6,Assigned,[RFC5050]
7-255,Unassigned,
Here we should keep the same registry and add version 7 to it. Proposed new text:
The current Primary Bundle Protocol Version Registry is augmented by adding the following values:
Value,Description,Reference
7,Assigned,[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 nominated expert(s) verify that a specification
exists and is readily accessible. Specifications for new
registrations need to describe in detail the manner in which bundle
processing is affected by the new flag settings. Expert(s) are
encouraged to be biased towards approving registrations unless they
are abusive, frivolous, or actively harmful (not merely
aesthetically displeasing, or architecturally dubious).
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 |
| 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 | |
+--------------------+----------------------------------+----------+
The current IANA Bundle Processing Control Flags registry is as follows:
Bit Position (right to left),Description,Reference
0,Bundle is a fragment,[RFC5050]
1,Application data unit is an administrative record,[RFC5050]
2,Bundle must not be fragmented,[RFC5050]
3,Custody transfer is requested,[RFC5050]
4,Destination endpoint is a singleton,[RFC5050]
5,Acknowledgement by application is requested,[RFC5050]
6,Reserved,[RFC5050]
7-8,Class of service: priority,[RFC5050]
9-13,Class of service: reserved,[RFC5050]
14,Request reporting of bundle reception,[RFC5050]
15,Request reporting of custody acceptance,[RFC5050]
16,Request reporting of bundle forwarding,[RFC5050]
17,Request reporting of bundle delivery,[RFC5050]
18,Request reporting of bundle deletion,[RFC5050]
19,Reserved,[RFC5050]
20,Reserved,[RFC5050]
21-63,Unassigned,
As one can see, they both share some semantics. Here is a proposal to merge the two versions into a single registry, in CSV format and with corresponding text.
The current Bundle Processing Control Flags Registry is augmented by adding a column identifying the version of the Bundle protocol (Bundle Protocol Version) that applies to the new values, and by adding the following values, as described in section 4.1.3. The current values in the registry should have the Bundle Protocol Version set to the value 6 or “6, 7”, as shown below.
Bit Position (right to left),Description, Bundle Protocol Version, Reference
6,Status time requested in reports, 7, [this document]
Bit Position (right to left),Description, Bundle Protocol Version, Reference
0,Bundle is a fragment, 6-7, [RFC5050]
1,Application data unit is an administrative record, 6-7, [RFC5050]
2,Bundle must not be fragmented, 6-7, [RFC5050]
3,Custody transfer is requested, 6, [RFC5050]
4,Destination endpoint is a singleton, 6, [RFC5050]
5,Acknowledgement by application is requested, 6-7, [RFC5050]
7-8,Class of service: priority, 6, [RFC5050]
9-13,Class of service: reserved, 6, [RFC5050]
14,Request reporting of bundle reception, 6-7, [RFC5050]
15,Request reporting of custody acceptance,6, [RFC5050]
16,Request reporting of bundle forwarding, 6-7, [RFC5050]
17,Request reporting of bundle delivery,6-7, [RFC5050]
18,Request reporting of bundle deletion, 6-7, [RFC5050]
The registration policy is changed to “Expert Review”. Given the maximum number of bits available, the allocation should only be approved with a well-defined specification and proof of real usage.
if this is agreed, we ought to make sure that the maximum number of bits is coherent in the text and in the registry. I suggest we keep 64 as RFC5050.
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 nominated expert(s) verify that a specification
exists and is readily accessible. Specifications for new
registrations need to describe in detail the manner in which block
processing is affected by the new flag settings. Expert(s) are
encouraged to be biased towards approving registrations unless they
are abusive, frivolous, or actively harmful (not merely
aesthetically displeasing, or architecturally dubious).
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) | | |
+--------------------+----------------------------------+----------+
| 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 | |
+--------------------+----------------------------------+----------+
The current IANA Block Processing Control Flags Registry is as follows:
Bit Position (right to left),Description,Reference
0,Block must be replicated in every fragment,[RFC5050]
1,Transmit status report if block can't be processed,[RFC5050]
2,Delete bundle if block can't be processed,[RFC5050]
3,Last block,[RFC5050]
4,Discard block if it can't be processed,[RFC5050]
5,Block was forwarded without being processed,[RFC5050]
6,Block contains an EID-reference field,[RFC5050]
7-63,Unassigned,
As one can see, they both share some semantics. Here is a proposal to merge the two versions into a single registry, in CSV format and with corresponding text.
The current Block Processing Control Flags Registry is augmented by adding a column identifying the version of the Bundle protocol (Bundle Protocol Version) that applies to the related BP version. The current values in the registry should have the Bundle Protocol Version set to the value 6 or “6, 7”, as shown below.
Bit Position (right to left),Description, Bundle Protocol Version, Reference
0,Block must be replicated in every fragment, 6-7, [RFC5050]
1,Transmit status report if block can't be processed, 6-7, [RFC5050]
2,Delete bundle if block can't be processed, 6-7, [RFC5050]
3,Last block, 6, [RFC5050]
4,Discard block if it can't be processed, 6-7, [RFC5050]
5,Block was forwarded without being processed, 6, [RFC5050]
6,Block contains an EID-reference field, 6, [RFC5050]
7-63,Unassigned,
if this is agreed, we ought to make sure that the maximum number of bits is coherent in the text and in the registry. I suggest we keep 64 as RFC5050.
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 nominated expert(s) verify that a specification exists
and is readily accessible. Specifications for new registrations need
to describe in detail the conditions under which bundle processing
may result in the transmission of status reports annotated with the
new reason codes. Expert(s) are encouraged to be biased towards
approving registrations unless they are abusive, frivolous, or
actively harmful (not merely aesthetically displeasing, or
architecturally dubious).
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 |
| 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 |
| 10 | Traffic pared | 6.1.1 |
|11-254 | Unassigned | |
| 255 | Reserved | |
+-------+-------------------------------------------+--------------+
The current IANA Bundle Status Report Reason Codes Registry is as follows:
Value,Description,Reference
0,No additional information,[RFC5050]
1,Lifetime expired,[RFC5050]
2,Forwarded over unidirectional link,[RFC5050]
3,Transmission canceled,[RFC5050]
4,Depleted storage,[RFC5050]
5,Destination endpoint ID unavailable,[RFC5050]
6,No known route to destination from here,[RFC5050]
7,No timely contact with next node on route,[RFC5050]
8,Block unintelligible,[RFC5050]
9-254,Unassigned,
255,Reserved,[RFC6255]
As one can see, they both share some semantics. Here is a proposal to merge the two versions into a single registry, in CSV format and with corresponding text.
The current Bundle Status Report Reason Codes Registry is augmented by adding a column identifying the version of the Bundle protocol (Bundle Protocol Version) that applies to the new values, and by adding the following values, as described in section 6.1.1. The current values in the registry should have the Bundle Protocol Version set to the value 6 or “6, 7”, as shown below.
Value, Description, Bundle Protocol Version, Reference
9, Hop limit exceeded, 7, [this document]
10, Traffic pared, 7, [this document]
Value,Description,Bundle Protocol Version, Reference
0,No additional information, 6-7, [RFC5050]
1,Lifetime expired,6-7, [RFC5050]
2,Forwarded over unidirectional link,6-7, [RFC5050]
3,Transmission canceled,6-7, [RFC5050]
4,Depleted storage,6-7, [RFC5050]
5,Destination endpoint ID unavailable,6-7, [RFC5050]
6,No known route to destination from here,6-7, [RFC5050]
7,No timely contact with next node on route,6-7, [RFC5050]
8,Block unintelligible,6-7, [RFC5050]
10.6. URI scheme type codes
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 codes". Initial
values for the Bundle Protocol URI scheme type code registry are
given below.
The registration policy for this registry is: Specification
Required. The nominated expert(s) verify that a specification exists
and is readily accessible. Specifications for new registrations need
to reference the documents defining the URIs for which new codes are
being registered. Expert(s) are encouraged to be biased towards
approving registrations unless they are abusive, frivolous, or
actively harmful (not merely aesthetically displeasing, or
architecturally dubious).
The value range is: unsigned 8-bit integer.
Each assignment consists of a URI scheme type name and its
associated value.
URI Scheme Type Codes Registry
+--------------+-----------------------------+-------------------+
| Value | Description | Reference |
+--------------+-----------------------------+-------------------+
| 0 | Reserved | |
| 1 | dtn | section 10.7 |
| 2 | ipn | RFC6260, Section 4|
| 3-254 | Unassigned | |
| 255 | reserved | |
+--------------+-----------------------------+-------------------+
I don’t think we should have that registry. The URI Schemes are already defined in another registry (e.g. https://www.iana.org/assignments/uri-schemes).
Therefore, I suggest we delete this whole section.
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: permanent
URI scheme syntax:
This specification uses the Augmented Backus-Naur Form (ABNF)
notation of [RFC5234].
dtn-uri = "dtn:" dtn-hier-part
Burleigh Expires April 2020 [Page 48]
Internet-Draft Bundle Protocol Version 7 October 2019
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).
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
+1 (800) 393-3353
Author/Change controller:
Scott Burleigh
Jet Propulsion Laboratory,
California Institute of Technology
scott.c.burleigh@jpl.nasa.gov
I think this section should be deleted, because the dtn scheme is already registered in the IANA URI Schemes registry (https://www.iana.org/assignments/uri-schemes)
10.8. Change status of URI scheme "ipn"
IANA is requested to change to "permanent" the status of the URI
scheme named "ipn".
I think this section should be changed to request both dtn and ipn to be of permanent status.