Subject: [dtn] Roman Danyliw's Discuss on draft-ietf-dtn-bpbis-22: (with DISCUSS and COMMENT)

From: Roman Danyliw via Datatracker <[email-masked]>
Date: Wed, 05 Feb 2020 17:01:05 -0800

Roman Danyliw has entered the following ballot position for
draft-ietf-dtn-bpbis-22: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dtn-bpbis/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

** Section 4.1.5.1. Can the permissible schemes for the Endpoint ID URL be
clarified.

Initially the text says:

The scheme identified by the < scheme name > in an endpoint ID is a
   set of syntactic and semantic rules that fully explain how to parse
   and interpret the SSP. The set of allowable schemes is effectively
   unlimited. Any scheme conforming to [URIREG] may be used in a bundle
   protocol endpoint ID.

[URIREG] would suggest that any schema in IANA "Uniform Resource Identifier
(URI) Schemes" Registry’ is valid.  However, later, the text says:

The first item of the array SHALL be the code number identifying the
   endpoint's URI scheme [URI], as defined in the registry of URI
   scheme code numbers for Bundle Protocol maintained by IANA as
   described in Section 10. [URIREG].

This text suggests that the new Bundle Protocol URI Scheme Type registry should
govern the EID schemes.  However, then the text again cites URIREG.  Perhaps
the intent is that URI's valid per [URIREG] would be registered in the new
bundle protocol registry and values in this new registry would be used.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

** Figure 1.  Does the second from the left column running “T1/T2” and “N1/N2”
mean that this node has a dual stack of N1+T1 and N2+T2?

** Section 3.1.  Can a node be part of multiple bundle endpoints?  I would
assume yes, but don't see that said anywhere?

** Section 3.1.  Per the definition of Bundle endpoint, there is a reference to
Section 4.4.1 but that section doesn’t exist.  Did you mean Section 4.1.5?

** Section 3.1.  Per the definition of Registration, and registrations having
two states (active and passive), could you please clarify why one would choose
to be in either state.

** Section 3.3. Per this list of BPA services, please add clarifying language
to the effect that the details of this registration functionality is out of
scope.

** Section 4.
   (Note that, while CBOR permits considerable flexibility in the
   encoding of bundles, this flexibility must not be interpreted as
   inviting increased complexity in protocol data unit structure.)

What is practical guidance should an implementer take from this text?

** Section 4.1.5.2  Per “A node's membership in a given singleton endpoint MUST
be sustained at least until the nominal operation of the Bundle Protocol no
longer depends on the identification of that node using that endpoint's ID.” --
what does it mean to “sustain” the membership? -- how would a node know that
the "nominal operation of the BP no longer depends" of this address binding?

** Section 4.2.2.  Per “Note that, in general, the creation of two distinct
bundles with the same source node ID    and bundle creation timestamp may
result in unexpected network behavior and/or suboptimal performance”, where is
that behavior described?

** Section 5.1.  Per “When the generation of status reports is enabled, the
decision on whether or not to generate a requested status report is left to the
discretion of the bundle protocol agent.”, can way points also choose not for
forward these reports based on configuration?

** Section 6.1.1.
   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.

Shouldn’t the text point to the associated IANA sub-registry (“Bundle Status
Report Reason Codes” sub-registry) as the canonical place to understand
semantics of future values?

** Section 9.  Recommend being clearer on the scope of the protections.

OLD:
Because the security mechanisms are extension blocks that are
   themselves inserted into the bundle, the integrity and
   confidentiality of bundle blocks are protected while the bundle is
   at rest, awaiting transmission at the next forwarding opportunity,
   as well as in transit.

NEW:
Because the security mechanisms are extension blocks that are
   themselves inserted into the bundle, the protections they afford
   apply when while the bundle is at rest, awaiting transmission at
   the next forwarding opportunity,
   as well as in transit.

** Section 9.  How is an implementor supposed to use the guidance in “Note
that, while the primary block must remain in the clear for routing purposes,
the Bundle protocol could be protected against    traffic analysis to some
extent by using bundle-in-bundle encapsulation … [which] is a current research
topic”?  There is no actionable guidance or pointers to more information.

**   Section 9.  .  How is an implementor supposed to use the guidance in
paragraph starting with “The bpsec extensions accommodate an open-ended range
...”.  If there is a concrete proposal for “to sign and/or encrypt blocks using
symmetric keys securely formed by Diffie-Hellman procedures”, BpSec suggest a
spec needs to be written to register a security context to realize this
approach.  Recommend removal.

Editorial Nit
-- Figure 2.  “CL1”, “CL2 …” is “Convergence Layer 1”, “2”?  “CL” is not
defined anywhere

-- Section 5.4.  s/adapter(s) in order to effect/adapter(s) in order to affect/

---

From: "Burleigh, Scott C (US 312B)" <[email-masked]>
Date: Thu, 6 Feb 2020 19:45:04 +0000

Excellent catch.  The next version of the BPv7 draft will contain modified language in section 4.1.5.1 that I hope will make more sense.  The intent is, just as you say, to register additional any number of URI schemes in that new URI scheme type code registry as needed, and to allow only URI schemes drawn from that registry in the formation of BP endpoint IDs.

On your COMMENTS:

	Yes, exactly.  That second node is bridging between an N1+T1 subnet and an N2+T2 subnet.

** Section 3.1.  Can a node be part of multiple bundle endpoints?  I would assume yes, but don't see that said anywhere?

	Yes.  I'll add a sentence to this effect in 3.1.

** Section 3.1.  Per the definition of Bundle endpoint, there is a reference to Section 4.4.1 but that section doesn’t exist.  Did you mean Section 4.1.5?

	Yes (actually 4.1.5.1).  Fixing that.

** Section 3.1.  Per the definition of Registration, and registrations having two states (active and passive), could you please clarify why one would choose to be in either state.

	This needs to be inferred from the procedures in section 5.7.  The bundle protocol agent assumes that bundles can be delivered automatically and immediately to any registration that is in active state, but that registrations in passive state must be polled for their readiness for bundle delivery.  This has implications for implementation strategies, and in particular it has implications for the design of delivery failure actions (for example, the BPA may be required to run a script that starts the application that should consume the bundle's payload).

** Section 3.3. Per this list of BPA services, please add clarifying language to the effect that the details of this registration functionality is out of scope.

	Certainly.

** Section 4.

	This is intended as an admonition to designers of new BP extension blocks and administrative records, not as guidance to implementers.  Basically, we would prefer that extensions to the bundle protocol be made as simple as possible. 

** Section 4.1.5.2  Per “A node's membership in a given singleton endpoint MUST be sustained at least until the nominal operation of the Bundle Protocol no longer depends on the identification of that node using that endpoint's ID.” -- what does it mean to “sustain” the membership? -- how would a node know that the "nominal operation of the BP no longer depends" of this address binding?

	Sustaining a node's membership in an endpoint means refraining from terminating the applicable registration.  If a node terminates its registration is some endpoint, then it can no longer receive bundles destined for that endpoint.  If reception of those bundles -- the nominal operation of the Bundle Protocol with regard to that endpoint -- is important to that node, then that registration must not be terminated, even if the node remains a member of several other endpoints.

** Section 4.2.2.  Per “Note that, in general, the creation of two distinct
bundles with the same source node ID and bundle creation timestamp may
result in unexpected network behavior and/or suboptimal performance”, where is that behavior described?

	I think that behavior can be fairly readily guessed: fragments of different bundles might be reassembled into a Frankenstein bundle, status reports purporting to pertain to one bundle might actually pertain to a different bundle, etc.  Any BP procedure that relies on bundle ID could malfunction.

** Section 5.1.  Per “When the generation of status reports is enabled, the decision on whether or not to generate a requested status report is left to the discretion of the bundle protocol agent.”, can way points also choose not for forward these reports based on configuration?

	There's no explicit authorization for that in this specification.  In practice, any waypoint actually may be configured in ways that preclude the forwarding of any sort of bundle.
	A note on this: we expect network managers will configure their nodes to avoid forwarding through nodes that are known to be maliciously configured; the network management protocol to support these kinds of adjustments is under development (https://datatracker.ietf.org/doc/draft-ietf-dtn-ama/, https://datatracker.ietf.org/doc/draft-birrane-dtn-amp/).

** Section 6.1.1.
   Valid status

Shouldn’t the text point to the associated IANA sub-registry (“Bundle Status Report Reason Codes” sub-registry) as the canonical place to understand semantics of future values?

	Sure, have added that reference.

OLD:

NEW:

	Sure.

** Section 9.  How is an implementor supposed to use the guidance in “Note that, while the primary block must remain in the clear for routing purposes,
the Bundle protocol could be protected against    traffic analysis to some
extent by using bundle-in-bundle encapsulation … [which] is a current research topic”?  There is no actionable guidance or pointers to more information.

	I'll include a reference to BIBE in section 9.

**   Section 9.  .  How is an implementor supposed to use the guidance in
paragraph starting with “The bpsec extensions accommodate an open-ended range ...”.  If there is a concrete proposal for “to sign and/or encrypt blocks using symmetric keys securely formed by Diffie-Hellman procedures”, BpSec suggest a spec needs to be written to register a security context to realize this approach.  Recommend removal.

	Okay.

Editorial Nit
-- Figure 2.  “CL1”, “CL2 …” is “Convergence Layer 1”, “2”?  “CL” is not defined anywhere

	Adding some explanatory text.

	No, "effect" is used correctly here.

Scott

-----Original Message-----
From: Roman Danyliw via Datatracker <[email-masked]> 
Sent: Wednesday, February 5, 2020 5:01 PM
To: The IESG <[email-masked]>
Cc: [email-masked]; Fred Templin <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
Subject: [EXTERNAL] Roman Danyliw's Discuss on draft-ietf-dtn-bpbis-22: (with DISCUSS and COMMENT)

** Section 4.1.5.1. Can the permissible schemes for the Endpoint ID URL be clarified.

Initially the text says:

This text suggests that the new Bundle Protocol URI Scheme Type registry should govern the EID schemes.  However, then the text again cites URIREG.  Perhaps the intent is that URI's valid per [URIREG] would be registered in the new bundle protocol registry and values in this new registry would be used.

** Section 3.1.  Can a node be part of multiple bundle endpoints?  I would assume yes, but don't see that said anywhere?

** Section 3.1.  Per the definition of Bundle endpoint, there is a reference to Section 4.4.1 but that section doesn’t exist.  Did you mean Section 4.1.5?

** Section 3.1.  Per the definition of Registration, and registrations having two states (active and passive), could you please clarify why one would choose to be in either state.

** Section 3.3. Per this list of BPA services, please add clarifying language to the effect that the details of this registration functionality is out of scope.

** Section 4.

** Section 4.1.5.2  Per “A node's membership in a given singleton endpoint MUST be sustained at least until the nominal operation of the Bundle Protocol no longer depends on the identification of that node using that endpoint's ID.” -- what does it mean to “sustain” the membership? -- how would a node know that the "nominal operation of the BP no longer depends" of this address binding?

** Section 4.2.2.  Per “Note that, in general, the creation of two distinct
bundles with the same source node ID    and bundle creation timestamp may
result in unexpected network behavior and/or suboptimal performance”, where is that behavior described?

** Section 5.1.  Per “When the generation of status reports is enabled, the decision on whether or not to generate a requested status report is left to the discretion of the bundle protocol agent.”, can way points also choose not for forward these reports based on configuration?

** Section 6.1.1.
   Valid status

Shouldn’t the text point to the associated IANA sub-registry (“Bundle Status Report Reason Codes” sub-registry) as the canonical place to understand semantics of future values?

OLD:

NEW:

** Section 9.  How is an implementor supposed to use the guidance in “Note that, while the primary block must remain in the clear for routing purposes,
the Bundle protocol could be protected against    traffic analysis to some
extent by using bundle-in-bundle encapsulation … [which] is a current research topic”?  There is no actionable guidance or pointers to more information.

**   Section 9.  .  How is an implementor supposed to use the guidance in
paragraph starting with “The bpsec extensions accommodate an open-ended range ...”.  If there is a concrete proposal for “to sign and/or encrypt blocks using symmetric keys securely formed by Diffie-Hellman procedures”, BpSec suggest a spec needs to be written to register a security context to realize this approach.  Recommend removal.

Editorial Nit
-- Figure 2.  “CL1”, “CL2 …” is “Convergence Layer 1”, “2”?  “CL” is not defined anywhere